January 2007 - address-policy-wg

Concerns on policy proposal 2005-08
by JORDI PALET MARTINEZ 12 Feb '07

12 Feb '07

Hi all, Preparing some text for another policy proposal, I just have the chance to review again 2005-08 and I will like to raise my concerns. To make it easier to follow, I'm looking at the comparison among existing policy and the proposal at http://ripe.net/ripe/draft-documents/2005-08-56s-2.html. Section 1.1. I think is wrong to take out the reference to RFC3177. This is the current recommendation and should not be ignored and keep as guidelines and is helpful for ISPs to know about it, regardless they want to follow it or not. I also don't agree with the text "This policy is considered to be an interim policy. It will be reviewed in the future, subject to greater experience in the administration of IPv6.", but I don't agree either in the one proposed by 2005-08. The complete paragraph should be simply removed (as I suggested in a previous policy proposal and a revised one being submitted), because otherwise, we should be fair and have something similar in all the policies. All them are subject to future review if there is more (or different) experience in the future, is the principle of the PDP process. Having such text can be taken as a negative thing for new people considering deploying IPv6. 2.7. If we suggest that the minimum assignment is /64 (as I understand in other parts of the proposal), there is no point in measuring the utilization in terms of /56. Either we measure the utilization in terms of /64, or we suggest that the minimum assignment is /56. My view in any case is that it should be kept as /48. 5.2.1. Same comment as for 2.7 5.4.1. I think is a mistake to change the existing text, but if we decide to go for it, I will never suggest a minimum value of /64. End-users need to have at least a prefix that allow to have several subnets. My view is still that /48 is the right size, but definitively I will accept in the *worst* case something such as /56, but never /64 should be suggested as a minimum value. I think if we go into this direction, definitively there is a need to clearly state that the end-users have the right to request extra size if needed, without any additional justification, otherwise we are creating a big barrier for deploying IPv6 and innovation, and this in turn is a barrier for making profitable services. I know this is not our "business" but we are pushing the creation of IPv6 with NAT at this way, and this is simply stupid and in that case is better that we just stop considering IPv6 at all. 5.4.2. I've already proposed to delete this section in a previous proposal and a revised one is being submitted. Regards, Jordi ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

4 8

RIPE NCC Announces New Membership Discussion List
by Paul Rendek 30 Jan '07

30 Jan '07

[Apologies for duplicate e-mails] Dear Colleagues, In response to requests from the membership, the RIPE NCC has created a members-only opt-in list where RIPE NCC members can discuss membership related issues. The new RIPE NCC Membership Discussion List (members-discuss(a)ripe.net) provides a useful, publicly archived way for members to discuss important membership issues. The RIPE NCC Membership Discussion List is one of several mailing lists for RIPE NCC members. For more information about these lists, including a description of the topics they cover and subscription details, go to: http://www.ripe.net/membership/lists.html RIPE NCC members can subscribe to this list through the RIPE NCC LIR Portal. Please note that an LIR login will be required. More information about setting up an LIR Portal account is available at: https://lirportal.ripe.net/lirportal/getting_started.html Regards, Paul Rendek Head of Communications RIPE NCC

1 0

(no subject)
by Mark Guz 30 Jan '07

30 Jan '07

[Apologies for duplicate e-mails] Dear Colleagues, On Tuesday 6 February, between 21:00 and 23:00 (UTC), the RIPE NCC will carry out planned maintenance work on our core network infrastructure. RIPE NCC services will be temporarily unavailable during this period. We apologise for any inconvenience that this may cause. This work is due to BGP load balancing issues between our NikHef and Telecity peering points. If you have any questions about this, please send an e-mail to: <ops(a)ripe.net>. Regards -- Mark Guz Senior Engineer RIPE NCC Singel 258 Amsterdam 1016 AB Tel: +31 (0) 20 535 4444 Fax: +31 (0) 20 535 4445 http://www.ripe.net

1 0

[Apnic-announce] New APNIC IPv4 address ranges
by Dominic Spratley 26 Jan '07

26 Jan '07

For our communities information: -------- Original Message -------- Subject: [Apnic-announce] New APNIC IPv4 address ranges Date: Thu, 18 Jan 2007 16:00:03 +1000 From: helpdesk(a)apnic.net Reply-To: apnic-talk(a)apnic.net To: apnic-announce(a)apnic.net Dear colleagues APNIC received the following IPv4 address blocks from IANA in Jan 2007 and will be making allocations from these ranges in the near future: 116/8 APNIC 117/8 APNIC 118/8 APNIC 119/8 APNIC 120/8 APNIC APNIC has made this announcement to enable the Internet community to update network configurations, such as routing filters, where required. Routability testing of new prefixes will commence on Friday January 19 2007. The daily report will be published at the usual URL: http://www.ris.ripe.net/debogon/debogon.html For more information on the resources administered by APNIC, please see: http://www.apnic.net/db/ranges.html For information on the minimum allocation sizes within address ranges administered by APNIC, please see: http://www.apnic.net/db/min-alloc.html Kind regards Guangliang ________________________________________________________________ Guangliang Pan email: helpdesk(a)apnic.net Resources Services Manager sip: helpdesk(a)voip.apnic.net APNIC phone: +61 7 3858 3188 http://www.apnic.net/ fax: +61 7 3858 3199 ________________________________________________________________

1 0

RE: [address-policy-wg] 2006-07 New Draft Document Published (FirstRaise in IPv4 Assignment Window Size)
by Dominic Spratley 23 Jan '07

23 Jan '07

Hi Eric, Just to clarify the procedure for requesting an IPv4 1st allocation: > > Hi, > > in general I support this proposal and this document as well, but I think > we > should consider one point: > > Due to the proposal the AW will raise automaticaly six months after the > new > LIR received their first allocation. > This means a LIR could become a LIR, wait six month without assigning > anything, and then they have the /21 AW > without proving they could handel their job. > A member must have sent in at least one PA (assignment) request before they are able to receive their first IPv4 allocation. This is usually for their own infra structure requirements. In addition, they may send a number of PA requests depending on their provisioning needs. Hope this helps Dominic Spratley Registration Services Manager RIPE NCC

1 0

2006-07 New Draft Document Published (First Raise in IPv4 Assignment Window Size)
by Erics 23 Jan '07

23 Jan '07

Hi, in general I support this proposal and this document as well, but I think we should consider one point: Due to the proposal the AW will raise automaticaly six months after the new LIR received their first allocation. This means a LIR could become a LIR, wait six month without assigning anything, and then they have the /21 AW without proving they could handel their job. I think there must be at least some RIPE-NCC approved requests before automaticaly raising the AW. My proposal is to update the draft text in chapter 7.0 like this > All new LIRs start with an AW of zero (0). > Their AW will automatically be set to a /21 (2048 addresses) six months after receiving their first allocation AND having at least five > smoothly approved requests within this six month period. > This means that all new LIRs need to request approval before making each assignment until their AW has been raised. kind regards Eric Schmidt LIR de.telekom

1 0

2006-07 New Draft Document Published (First Raise in IPv4 Assignment Window Size)
by Filiz Yilmaz 23 Jan '07

23 Jan '07

PDP Number: 2006-07 First Raise in IPv4 Assignment Window Size Dear Colleagues We have published a draft document for the proposal described in 2006-07. This proposal suggests the Assignment Window (AW) available to new LIRs should automatically be raised from zero (0) to /21 (2,048 IPv4 addresses) six months after they receive their first allocation. Because the sub-allocation policy references the AW policy, the sub-allocation policy also needs to be updated. This proposal suggests that the maximum sub-allocation should be kept at /20 (4,096 IPv4 addresses). You can find the full proposal at: http://ripe.net/ripe/policies/proposals/2006-07.html and the draft document at: http://ripe.net/ripe/draft-documents/2006-07-draft.html We encourage you to read the draft document text and send any comments to address-policy-wg(a)ripe.net before 20 February 2007. Regards Filiz Yilmaz RIPE NCC Policy Development Officer

1 0

2006-07 Draft Document will be produced (First Raise in IPv4 Assignment Window Size)
by Filiz Yilmaz 18 Jan '07

18 Jan '07

PDP Number: 2006-07 First Raise in IPv4 Assignment Window Size Dear Colleagues The discussion period for the proposal described in 2006-07 has ended. This proposal suggests the Assignment Window (AW) available to new LIRs should automatically be raised from zero (0) to /21 (2,048 IPv4 addresses) six months after they receive their first allocation. Because the sub-allocation policy references the AW policy, the sub-allocation policy also needs to be updated. This proposal suggests that the maximum sub-allocation should be kept at /20 (4,096 IPv4 addresses). A draft document will now be prepared for review. We will publish the document shortly and we will make an announcement. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2006-07.html Regards Filiz Yilmaz RIPE NCC Policy Development Officer

1 0

2006-02 Discussion Period extended until 14 February 2007 (IPv6 Address Allocation and Assignment Policy)
by Filiz Yilmaz 17 Jan '07

17 Jan '07

PDP Number: 2006-02 IPv6 Address Allocation and Assignment Policy Dear Colleagues The text of the policy proposal 2006-02 has changed. This proposal is to change the IPv6 Initial Allocation criteria and the End Site definition in the "IPv6 Address Allocation and Assignment Policy". We have published the new version today, as a result the discussion period for this proposal will end on 14 February 2007. You can find the full proposal at: http://ripe.net/ripe/policies/proposals/2006-02.html We encourage you to review this policy proposal and send your comments to <address-policy-wg(a)ripe.net>. Regards Filiz Yilmaz RIPE NCC Policy Development Officer

1 0

Routing policy for a costomer
by z.chy 17 Jan '07

17 Jan '07

Dear Address working Group IN RIPE NCC Congratulation to you for new year. there are important questions about PA assignment addresses to a customer. If a customer have a black PA IPV4 addresses (f.e: /22) from one lir with specified ASN which has been routed though it,and decide to reroute it from another ASs is it possible?IN fact there are 2 situation: 1.this customer have a block of PA IPV4 from LIR1 with ASn1 and route it.Simultaneously the customer decide to reroute it from another internet provider (ASn2).Is it possible?what policies are considered to RIPE and LIR1?weather the customer need to get agreement with LIR1?HOW? 2.The customer decide to disconnect internet link from LIR1 and connect through another ASN but have preferred to hold PA addresses from LIR1 and route it from another provider and new provider has accepted to route LIR1 PA addresses.Is it possible reroute it without renumbering?and weather RIPE NCC agree to this matter ?if it need to agreement with LIR1 ,what policie are considered by LIR1 and their customer? Many thanks to explain clarify this matter. The best regards.

2 1