- address-policy-wg - mailman.ripe.net

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

2006-04 Policy Proposal Withdrawn (Contact e-mail Address Requirements)
by Filiz Yilmaz 08 Feb '07

08 Feb '07

PDP Number: 2006-04 Contact e-mail Address Requirements Dear Colleagues The proposal 2006-04, Contact e-mail Address Requirements has been withdrawn. The proposer and the Address Policy Working Group chair decided that not enough consensus was reached. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/archive/ Regards Filiz Yilmaz RIPE NCC Policy Development Officer

1 0

Tonight's RIPE NCC Maintenance Rescheduled for 13 February
by Mark Guz 06 Feb '07

06 Feb '07

[Apologies for duplicate e-mails] Dear Colleagues, We have cancelled plans to carry out maintenance work on our core network infrastructure this evening. This means that RIPE NCC services will be available as usual. We will carry out this maintenance work on Tuesday, 13 February between 21:00 and 23:00 (UTC). During this time, many of our services will be unavailable. We apologise for any inconvenience that this may cause. 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

1 0

[arano@inetcore.com: [GLOBAL-V6] Fwd: [sig-policy] prop-046: IPv4 countdown policy proposal]
by Gert Doering 06 Feb '07

06 Feb '07

Hi, this is a policy currently discussed in the APNIC region. I haven't formed an opinion of my own on this yet, but I think it might be useful to be aware of it. Gert Doering, APWG Chair ----- Forwarded message from Takashi Arano <arano(a)inetcore.com> ----- X-IronPort-SBRS: 3.5 X-Greylist: delayed 1099 seconds by postgrey-1.21 at kombu.apnic.net; Tue, 30 Jan 2007 20:45:27 EST X-Mailer: QUALCOMM Windows Eudora Version 6.2J rev4.2 Date: Tue, 30 Jan 2007 19:26:35 +0900 To: global-v6(a)lists.apnic.net From: Takashi Arano <arano(a)inetcore.com> X-AP-Spam-Status: No, hits=0 required=6 X-AP-Spam-Status: No, hits=0 required=6 X-AP-Spam-Score: 0 (notspam) X-Scanned-By: MIMEDefang 2.15 (www dot roaringpenguin dot com slash mimedefang) X-Mailman-Approved-At: Wed, 31 Jan 2007 08:40:22 +1000 Subject: [GLOBAL-V6] Fwd: [sig-policy] prop-046: IPv4 countdown policy proposal X-BeenThere: global-v6(a)lists.apnic.net X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussion of new global IPv6 policy development <global-v6.lists.apnic.net> X-AP-Lists: Discussion of new global IPv6 policy development <global-v6.lists.apnic.net> List-Unsubscribe: <http://mailman.apnic.net/mailman/listinfo/global-v6>, <mailto:global-v6-request@lists.apnic.net?subject=unsubscribe> List-Archive: <http://www.apnic.net/mailing-lists/global-v6> List-Post: <mailto:global-v6@lists.apnic.net> List-Help: <mailto:global-v6-request@lists.apnic.net?subject=help> List-Subscribe: <http://mailman.apnic.net/mailman/listinfo/global-v6>, <mailto:global-v6-request@lists.apnic.net?subject=subscribe> Errors-To: global-v6-bounces(a)lists.apnic.net All, Hello. I will forward our proposal to this mailing list just FYI. It is not an IPv6 policy, though. Regards, Takashi Arano >X-Original-To: arano(a)inetcore.com >Delivered-To: arano(a)inetcore.com >From: "Kenny Huang" <huangk(a)alum.sinica.edu> >To: <sig-policy(a)apnic.net> >Date: Tue, 30 Jan 2007 15:51:34 +0800 >X-Mailer: Microsoft Office Outlook, Build 11.0.6353 >Thread-Index: AcdEKKt/vRhEhwUHSvaQIKaDUzp1lAAGqTXQ >X-AP-Spam-Status: No, hits=0 required=6 >X-AP-Spam-Status: No, hits=0 required=6 >X-AP-Spam-Score: 0 (notspam) >X-Scanned-By: MIMEDefang 2.15 (www dot roaringpenguin dot com slash mimedefang) >Cc: >Subject: [sig-policy] prop-046: IPv4 countdown policy proposal >X-BeenThere: sig-policy(a)lists.apnic.net >X-Mailman-Version: 2.1.4 >List-Id: APNIC SIG on resource management policy <sig-policy.lists.apnic.net> >X-AP-Lists: APNIC SIG on resource management policy<sig-policy.lists.apnic.net> >List-Unsubscribe: <http://mailman.apnic.net/mailman/listinfo/sig-policy>,<mailto:sig-policy-request@lists.apnic.net?subject=unsubscribe> >List-Archive: <http://www.apnic.net/mailing-lists/sig-policy> >List-Post: <mailto:sig-policy@lists.apnic.net> >List-Help: <mailto:sig-policy-request@lists.apnic.net?subject=help> >List-Subscribe: <http://mailman.apnic.net/mailman/listinfo/sig-policy>,<mailto:sig-policy-request@lists.apnic.net?subject=subscribe> >Sender: sig-policy-bounces(a)lists.apnic.net > > > >Dear SIG members > >Yesterday, the proposal "IPv4 countdown policy proposal" was sent to the >Policy SIG for review. It will be presented at the Policy SIG at APNIC 23 in >Bali, Indonesia, 26 February - 2 March 2007. You are invited to review and >comment on the proposal on the mailing list before the meeting. > >The proposal's history can be found at: > > http://www.apnic.net/policy/proposals/prop-046-v001.html > >Regards, > >Kenny Huang >Policy SIG >huangk(a)alum.sinica.edu > > >prop-046-v001: IPv4 countdown policy proposal > >________________________________________________________________________ > > > >Co-authors: Toshiyuki Hosaka (JPNIC) > Takashi Arano (Intec Netcore, Inc.) > Kuniaki Kondo (Atelier Mahoroba) > Tomohiro Fujisaki (NTT) > Akinori Maemura (JPNIC) > Kosuke Ito (IRI Ubitech) > Shuji Nakamura (IPv6 Promotion Council) > Tomoya Yoshida (NTT Communications) > Susumu Sato (JPNIC) > Akira Nakagawa (KDDI) > >Version: 1 > >Date: 29 January 2007 > >SIG: Policy > > >1. Introduction >---------------- > >The exhaustion of IPv4 address is approaching round the corner. Geoff >Huston's latest projection at Potaroo (as of January 6, 2007) >(http://www.potaroo.net/tools/ipv4/) draws the date of IANA pool exhaustion >as 31st May 2011, and that of RIR pool as 14th July 2012. > >Tony Hain projects similar dates based on a different algorithm of his own. >>>From these data, we may observe that if that the current allocation trend >continues, the exhaustion of IPv4 address space is expected to take place as >early as within the next five years. > >ICANN/IANA and RIRs must co-ordinate with stakeholders to achieve smooth >termination of IPv4 address space as the Internet bodies responsible for >stable management and distribution of IP number resources. > >This proposal provides some ideas as well as concrete examples of the policy >that helps IPv4 allocations come to an end with "the minimum confusion" and >in "as fair manner as possible". > >"Five years at the earliest" is not too far in the future for the exhaustion >of IPv4 address space. Assuming the minimum of one year is required for >sufficient policy discussions with this proposal as a start, and two years >for preparation and transfer by LIRs, we need to start the discussions right >at this time. > > > >2. Summary of current problems >------------------------------- > >Despite the fact that several projections are made on IPv4 address to run >out as early as within the next few years, no discussions are taking place >on any of the RIR's policy fora including that of APNIC. >This section lists possible problems if no policies are defined to prepare >for the terminal period of allocations. > > >2.1 LIR > > LIRs currently do not consider IPv4 address exhaustion as an > imminent issue in the first place. It is possible that they will > finally realize the situation only when impacts of the exhaustion > becomes visible as a practical matter, and lead to confusions such > as re-addressing their network or making subsequent requests at the > last minute in within a limited time frame. > > There could also be cases where allocations blocks cannot be > allocated to some of the LIRs even though requests are >submitted > on the same day. Moreover, although it would be necessary for LIRs > to announce to their customers that IPv4 address space will not be > available for assignments eventually, it is difficult to plan this > timing without clear policy for the last phase of allocations. > > As new IPv4 address allocations space will no longer be available, > LIRs have no choice but to build networks based on IPv6. However, > there are risks of trouble if preparations are made from that point > in time, as it will lead to premature actions even if some time can > be bought by re-addressing and subsequent allocations. > > Lastly, using up all available IPv4 address space will disable > assignments to services inevitable for co-existence of IPv4 and > IPv6 networks, such as the translator service between the two > networks, which it may create situation where transfer to IPv6 > network will not even be possible. > > >2.2 RIR/NIR > > It is likely that smooth allocations by RIRs/NIRs will be hindered > by rush of inquiries during the terminal phase of allocations. > > >2.3 End users > > End users generally receive address assignments from ISPs > accompanied with Internet connection service. If an ISP no longer > has IPv4 address space available, nor unable to provide IPv6 > service, end users will not be able to receive services from that > ISP. > > Moreover, if the terminal date of allocations remains ambiguous, > it may leave end users behind to prepare for IPv6 ready network. > > > >3. Benefits >------------ > >There will be the following benefits by implementing the policy for >IPv4 address exhaustion as proposed on this paper. > > >3.1 LIR > > LIRs will be able to consciously plan their addressing within their > networks if the final date of allocations is clearly demonstrated. > Keeping a certain amount of unallocated address blocks enables > allocations/assignments for "critical infrastructure" after the > termination of regular allocations, which will be explained later > section in more details. > > >3.2 RIR/NIR > > Announcing the date of terminating allocations in advance and > ensuring that all allocations before this date will be made > according to the policy at the time enables RIRs/NIRs to make the > last allocation without confusions and avoids causing feelings of > unfairness among LIRs and end users. In addition, consistent policy > applied to all RIRs removes bias towards certain region as well as > inter-regional unfairness. The period which IPv6 support is > completed becomes clear, therefore, RIRs/NIRs can prepare for this. > > >3.3 End user > > As this proposal enables LIRs to prepare for the terminal period of > allocations in advance, it reduces the risk of delays/suspensions of > assignments from LIRs to enduers, and end users will be able to > continuously receive services from LIRs. As in the case of LIRs, end > users will be able to prepare for IPv6 support by the date of > allocation termination is clarified. In addition, IPv6 connectivity > as well as IPv4 address required during the allocation termination > period will be smoothly secured by LIRs preparing for such period. > > As listed above, there will be important, notable benefits for > stakeholders as a result of this policy. It is therefore necessary > to take the following actions to achieve a smooth transfer to IPv6 > and prevent causing instability in the Internet as well as; > > - start discussions on allocation scheme during the exhaustion > period, > > - indicate a roadmap to exhaustion after raising awareness on the > issue, and > > - allow enough time for LIRs to plan timing of addressing of their > networks, submit allocation requests, and consider how to switch > to IPv6. > > > >4. Proposal >----------- > >4.1 Principles > > As the first step to discuss IPv4 exhaustion planning, we would > like to have an agreement(consensus) on the following four > principles. > > -------------------------------------------------------------------- > (1) Global synchronization: > > All five RIRs will proceed at the same time for measures on >IPv4 > address exhaustion. > > (2) Some Blocks to be left: > > Keep a few /8 stocks instead of distributing all. > > (3) Keeping current practices until the last moment : > > Maintain the current policy until the last allocation. > > (4) Separate discussions on "Recycle" issue : > > Recovery of unused address space should be discussed >separately > -------------------------------------------------------------------- > > > (1) Global synchronization: > > All RIRs must proceed at the same time to take measures for > IPv4 address exhaustion. This is important not only for >ensuring > fairness for LIRs across the regions, but alsot to prevent > confusions such as attempts to receive allocations from an >RIR > outside their region. The five RIRs should facilitate >bottom-up > discussions, which should be well coordinated under the > leaderships of ICANN ASO and NRO. > > > (2) Some blocks to be left: > > It is not practical to consider that IPv4 address blocks can >be > allocated to the last piece. It is expected to cause >confusions > if one party can receive an allocation while the other has >to > give up, just with a touch of a difference. The best >solution > to avoid such confusion is to set in advance, a date in >which > one is able to receive an allocation if requests are >submitted > before this timeline. > > Furthermore, there are few cases where allocations or > assignments of IPv4 address space become absolutely >necessary > in the future. For example, requirements to start a >translator > service between IPv4 and IPv6 networks should be supported, >and > there may be some requirements in the future that are >beyond > our imagination at this current moment. > > As such, a date to stop allocations under the current policy > should be set/defined so that certain number of IPv4 >address > blocks will be kept as stocks instead of allocating all >blocks > without remains. > > > (3) Maintaining current practices until the last moment : > > Allocations should be made based on the current policy until >the > time to terminate allocations. As the IPv4 Internet has now > developed into a social infrastructure supporting large >number > of businesses, making large changes in the current policy > towards conservation within the next one or two years will >lead > to large-scale confusions, and difficult in the reality. > > > (4) Separate discussion from "Recycle" issue > > Recovering unused allocated/assigned address blocks is an > important measure, and in fact, it has already be discussed >and > implemented in each RIR regions. This issue, however should >be > considered separately from this proposal as recovery of a >few > /8 blocks extends the lifetime of IPv4 for less than one >year > while efforts for the recovery is expected to require > substantial time. > > >4.2 Details of the proposal > > This section provides an example of a proposal in case consensus is > reached on basic principles introduced in section 4.1. > > - Set the date for termination of allocations and the date of > announcement > > Set the date to terminate allocations as a general rule, and > announce it a certain period in advance. Define the date of > announcement as "A-date" and the date to terminate allocations > as "T-date". The two dates will be set as follows: > > > A-date (Date of Announcement): > > - The day in which the IANA pool becomes less than 30*/8 > > - RIRs must announce "T-date" on this day, which is >defined > later > > (*) There will be no changes in the policy on >A-date > > > T-date(Date of Termination): > > - Exactly two years after A-date > > - 10*/8 blocks should remain at T-date, and defined as >two > years after A-date, based on the current pace of > allocations > > - It is however possible to move T-date forward at the >point > where address consumpution exceeds the projections >during > the course of two years > > (*) new allocations/assignments from RIRs should >terminate > on T-date as a general rule. Allocations or >assignments > to "critical infrastructure" after T-date >should be > defined by a separate policy. > > > A-date is set in order to: > > - Allow some grace period and period for networks to be IPv6 > ready until the termination of allocations. > - Prevent unfairness among LIRs by clarifying the date, such > as not being able to receive allocations by a small >difference > in timing. > > The rationale for setting A-date as "when IANA pool becomes >less > than 30*/8" is as follows: > > The rate of allocations from IANA to RIRs after 2000 >is as > follows. > > 2000 : 4*/8 > 2001 : 6*/8 > 2002 : 4*/8 > 2003 : 5*/8 > 2004 : 9*/8 > 2005 : 13*/8 > 2006 : 10*/8 > > Approximately 10*/8 has been allocated annually >after 2003, > and the consumption is likely to accelerate with >rise of the > last minute demands. As it is better to keep minimum >stocks > of address pool at IANA, 30*/8 is set as the >threshold > value, and allocations should be terminated two >years after > it reaches the value, which ensures that IANA/RIRs >secure > the address space for allocations/assignments to >critical > infrastructure. > > >4.3 Effect on APNIC members/NIRs > > APNIC members are expected to concretely grasp the termination date > of allocations and take actions within their organization to prepare > for the event. > > NIRs will also terminate allocations to its LIRs in line with APNIC. > Therefore, NIRs will be required to sufficiently promote and keep > the community informed on the date of termination of >allocations, > just as it is expected of APNIC. > > >* sig-policy: APNIC SIG on resource management policy * >_______________________________________________ >sig-policy mailing list >sig-policy(a)lists.apnic.net >http://mailman.apnic.net/mailman/listinfo/sig-policy _______________________________________________ global-v6 mailing list global-v6(a)lists.apnic.net http://mailman.apnic.net/mailman/listinfo/global-v6 ----- End forwarded message ----- Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 98999 SpaceNet AG Mail: netmaster(a)Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234

3 2

2006-06 Last Call for Comments (IPv4 Maximum Allocation Period)
by Filiz Yilmaz 06 Feb '07

06 Feb '07

PDP Number: 2006-06 IPv4 Maximum Allocation Period Dear Colleagues The proposal described in 2006-06 is now at its Concluding Phase. This proposal is to have the RIPE NCC allocate address space to Local Internet Registries (LIRs) based on their one-year needs. In other words, it suggests setting a maximum allocation period of 12 months. You can find the full proposal at: http://ripe.net/ripe/policies/proposals/2006-06.html and the draft RIPE Document at: http://ripe.net/ripe/draft-documents/2006-06-draft.html Please e-mail any final comments about this proposal to address-policy-wg(a)ripe.net before 6 March 2007. Regards Filiz Yilmaz RIPE NCC Policy Development Officer

1 0

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