From gert at space.net Mon Feb 5 09:05:19 2007 From: gert at space.net (Gert Doering) Date: Mon, 5 Feb 2007 09:05:19 +0100 Subject: [address-policy-wg] [arano@inetcore.com: [GLOBAL-V6] Fwd: [sig-policy] prop-046: IPv4 countdown policy proposal] Message-ID: <20070205080519.GC28483@Space.Net> 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 ----- 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 at lists.apnic.net From: Takashi Arano 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 at lists.apnic.net X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussion of new global IPv6 policy development X-AP-Lists: Discussion of new global IPv6 policy development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: global-v6-bounces at 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 at inetcore.com >Delivered-To: arano at inetcore.com >From: "Kenny Huang" >To: >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 at lists.apnic.net >X-Mailman-Version: 2.1.4 >List-Id: APNIC SIG on resource management policy >X-AP-Lists: APNIC SIG on resource management policy >List-Unsubscribe: , >List-Archive: >List-Post: >List-Help: >List-Subscribe: , >Sender: sig-policy-bounces at 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 at 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 at lists.apnic.net >http://mailman.apnic.net/mailman/listinfo/sig-policy _______________________________________________ global-v6 mailing list global-v6 at 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 at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From filiz at ripe.net Tue Feb 6 11:07:01 2007 From: filiz at ripe.net (Filiz Yilmaz) Date: Tue, 06 Feb 2007 11:07:01 +0100 Subject: [address-policy-wg] 2006-06 Last Call for Comments (IPv4 Maximum Allocation Period) Message-ID: <20070206100701.9071A2F583@herring.ripe.net> 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 at ripe.net before 6 March 2007. Regards Filiz Yilmaz RIPE NCC Policy Development Officer From axel.pawlik at ripe.net Tue Feb 6 12:50:19 2007 From: axel.pawlik at ripe.net (Axel Pawlik) Date: Tue, 06 Feb 2007 12:50:19 +0100 Subject: [address-policy-wg] [arano@inetcore.com: [GLOBAL-V6] Fwd: [sig-policy] prop-046: IPv4 countdown policy proposal] In-Reply-To: <20070205080519.GC28483@Space.Net> References: <20070205080519.GC28483@Space.Net> Message-ID: <45C86B7B.1070901@ripe.net> Gert Doering wrote: > 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. Absolutely, thanks Gert. I am looking forward to the discussions. This is a timely activity, we have also started to think about what to do when "the end is near". Maybe we could keep this in mind for Tallinn, for a short presentation of the APNIC discussions (if any). cheers, Axel From plzak at arin.net Tue Feb 6 13:40:02 2007 From: plzak at arin.net (Ray Plzak) Date: Tue, 6 Feb 2007 07:40:02 -0500 Subject: [address-policy-wg] [arano@inetcore.com: [GLOBAL-V6] Fwd: [sig-policy] prop-046: IPv4 countdown policy proposal] In-Reply-To: <45C86B7B.1070901@ripe.net> References: <20070205080519.GC28483@Space.Net> <45C86B7B.1070901@ripe.net> Message-ID: It is being discussed in the ARIN region. http://lists.arin.net/pipermail/ppml/2007-February/thread.html Ray > -----Original Message----- > From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg- > admin at ripe.net] On Behalf Of Axel Pawlik > Sent: Tuesday, February 06, 2007 6:50 AM > To: Gert Doering > Cc: address-policy-wg at ripe.net > Subject: Re: [address-policy-wg] [arano at inetcore.com: [GLOBAL-V6] Fwd: > [sig-policy] prop-046: IPv4 countdown policy proposal] > > Gert Doering wrote: > > 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. > > Absolutely, thanks Gert. I am looking forward to the discussions. > This is a timely activity, we have also started to think about > what to do when "the end is near". > > Maybe we could keep this in mind for Tallinn, for a short > presentation of the APNIC discussions (if any). > > cheers, Axel From ncc at ripe.net Tue Feb 6 17:14:36 2007 From: ncc at ripe.net (Mark Guz) Date: Tue, 06 Feb 2007 17:14:36 +0100 Subject: [address-policy-wg] Tonight's RIPE NCC Maintenance Rescheduled for 13 February Message-ID: <45C8A96C.7030803@ripe.net> [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 . Regards, Mark Guz Senior Engineer RIPE NCC Singel 258 Amsterdam 1016 AB Tel: +31 (0) 20 535 4444 Fax: +31 (0) 20 535 4445 From ncc at ripe.net Tue Feb 6 17:14:36 2007 From: ncc at ripe.net (Mark Guz) Date: Tue, 06 Feb 2007 17:14:36 +0100 Subject: [address-policy-wg] [ncc-announce] Tonight's RIPE NCC Maintenance Rescheduled for 13 February Message-ID: <45C8A96C.7030803@ripe.net> [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 . Regards, Mark Guz Senior Engineer RIPE NCC Singel 258 Amsterdam 1016 AB Tel: +31 (0) 20 535 4444 Fax: +31 (0) 20 535 4445 From filiz at ripe.net Thu Feb 8 17:15:14 2007 From: filiz at ripe.net (Filiz Yilmaz) Date: Thu, 08 Feb 2007 17:15:14 +0100 Subject: [address-policy-wg] 2006-04 Policy Proposal Withdrawn (Contact e-mail Address Requirements) Message-ID: <20070208161514.CBEC02F583@herring.ripe.net> 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 From cfriacas at fccn.pt Mon Feb 12 10:51:10 2007 From: cfriacas at fccn.pt (Carlos Friacas) Date: Mon, 12 Feb 2007 09:51:10 +0000 (WET) Subject: [address-policy-wg] Concerns on policy proposal 2005-08 In-Reply-To: References: Message-ID: Hi, On Fri, 26 Jan 2007, JORDI PALET MARTINEZ wrote: (...) > What I recall is that address space is not a good to be sold by the LIRs, > and they don't own it. Only the real cost for the "management" should be > charged, and I can tell you for sure that this is not in the order of 12 > Euros per month per IPv4 address as it is being charged in Spain (I guess > about the same in other countries). Yes. Unfortunately :-( If an end-customer wants a fixed public IP, it usually pays for an "extra". > So the real situation with IPv4 is that this is not the case. Many ISPs > actually "sell" the addresses. Yes. Afaik, this is true for ISPs with a broad spectrum of customers (but not every LIR is doing this...). Theory <> Practice. :-( > We need to understand that if we do the same with IPv6, we in fact kill IPv6 Kill "early deployment of" IPv6. In five/six years from now, global needs should be different... ;-) > and there is no advantage to deploy it. The possible business with IPv6 is > the fact that new services and applications can be generated and make profit Which new services and applications? 99,9999... % of engineers/programmers/designers/... are "formatted" for the v4-only perspective. And i'm not even thinking about the holy grail - the killer app - but the fact is that there's still no application that could *significantly* work better in v6 when compared to v4. > from them BECAUSE: > 1) there are enough IPv6 addresses > 2) its provision is easier (specially if all the end-users get the same > prefix, so network become "flat", such as /48 right now). Very marginal effect on profit. This can in fact help reduce expenses, but no real effect on profit. > 3) there is no NAT (which will be better avoid if we have 1 and 2 above) Unfortunately most people like NAT. :-( > Probably we can add other things to the list, but the important point is to > make sure that the addresses are there for end-users applications and > services at no cost (and I'm not talking just about money, but > "justification" cost). Justification cost = Time is money! :-) I can partially agree with this. However, on the other side i can also see that bigger ISPs could get an eye on IPv6, if they could make some extra money by assigning /48s to customers. Smaller ISPs could of course get into IPv6 from the perspective of offering something others still don't. Cheers, ------------------------------------------------------------------------- Carlos Friac,as See: Wide Area Network Working Group (WAN) www.gigapix.pt FCCN - Fundacao para a Computacao Cientifica Nacional www.ipv6.eu Av. do Brasil, n.101 www.6diss.org 1700-066 Lisboa www.geant2.net Tel: +351 218440100 Fax: +351 218472167 www.fccn.pt ------------------------------------------------------------------------- "Internet is just routes (209927/730), naming (billions) and... people!" Aviso de Confidencialidade Esta mensagem e' exclusivamente destinada ao seu destinatario, podendo conter informacao CONFIDENCIAL, cuja divulgacao esta' expressamente vedada nos termos da lei. Caso tenha recepcionado indevidamente esta mensagem, solicitamos-lhe que nos comunique esse mesmo facto por esta via ou para o telefone +351 218440100 devendo apagar o seu conteudo de imediato. Warning This message is intended exclusively for its addressee. It may contain CONFIDENTIAL information protected by law. If this message has been received by error, please notify us via e-mail or by telephone +351 218440100 and delete it immediately. From ncc at ripe.net Mon Feb 12 16:38:13 2007 From: ncc at ripe.net (Andrei Robachevsky) Date: Mon, 12 Feb 2007 16:38:13 +0100 Subject: [address-policy-wg] Transfer of ERX resources from RIPE NCC to AfriNIC Message-ID: <45D089E5.50601@ripe.net> [Apologies for duplicate e-mails] Dear colleagues, On Wednesday 14 February 2007, the RIPE NCC will transfer management of several Early Registration PI address blocks and Autonomous System Numbers to AfriNIC. A list of the resources being transferred is available at: http://www.ripe.net/projects/erx/transferred.html You can find more information about AfriNIC at: http://www.afrinic.net For more information on the ERX project, see: http://www.ripe.net/projects/erx/index.html Regards, Andrei Robachevsky, Chief Technical Officer RIPE NCC From ncc at ripe.net Mon Feb 12 16:38:13 2007 From: ncc at ripe.net (Andrei Robachevsky) Date: Mon, 12 Feb 2007 16:38:13 +0100 Subject: [address-policy-wg] [ncc-announce] Transfer of ERX resources from RIPE NCC to AfriNIC Message-ID: <45D089E5.50601@ripe.net> [Apologies for duplicate e-mails] Dear colleagues, On Wednesday 14 February 2007, the RIPE NCC will transfer management of several Early Registration PI address blocks and Autonomous System Numbers to AfriNIC. A list of the resources being transferred is available at: http://www.ripe.net/projects/erx/transferred.html You can find more information about AfriNIC at: http://www.afrinic.net For more information on the ERX project, see: http://www.ripe.net/projects/erx/index.html Regards, Andrei Robachevsky, Chief Technical Officer RIPE NCC From filiz at ripe.net Wed Feb 14 17:33:52 2007 From: filiz at ripe.net (Filiz Yilmaz) Date: Wed, 14 Feb 2007 17:33:52 +0100 Subject: [address-policy-wg] 2006-05 New Draft Document Published (PI Assignment Size) Message-ID: <20070214163352.AF8552F583@herring.ripe.net> PDP Number: 2006-05 PI Assignment Size Dear Colleagues We have published a draft document for the proposal described in 2006-05. This proposal suggests to have the minimum assignment size for PI assignments to be a /24 when routing is a major issue for a multihoming End User. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2006-05.html and the draft document at: http://www.ripe.net/ripe/draft-documents/2006-05-draft.html We encourage you to read the draft document text and send any comments to address-policy-wg at ripe.net before 14 March 2007. Regards Filiz Yilmaz RIPE NCC Policy Development Officer From president at ukraine.su Wed Feb 14 17:42:25 2007 From: president at ukraine.su (Max Tulyev) Date: Wed, 14 Feb 2007 18:42:25 +0200 Subject: [address-policy-wg] 2006-05 New Draft Document Published (PI Assignment Size) In-Reply-To: <20070214163352.AF8552F583@herring.ripe.net> References: <20070214163352.AF8552F583@herring.ripe.net> Message-ID: <45D33BF1.7000105@ukraine.su> +1 :) I fully support that proposal. I think it is also a good idea to add a field 'Global: Yes/No' in the requet. If for example the net is requested for private peering - it can be smaller than /24 safe as not attended to be globally reachable. If the net is requested for announcing in global routing table - it should be /24 even if customer really need 1 IP at all. Filiz Yilmaz wrote: > PDP Number: 2006-05 > PI Assignment Size > > Dear Colleagues > > We have published a draft document for the proposal described in > 2006-05. > > This proposal suggests to have the minimum assignment size for PI > assignments to be a /24 when routing is a major issue for a > multihoming End User. > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2006-05.html > > and the draft document at: > > http://www.ripe.net/ripe/draft-documents/2006-05-draft.html > > We encourage you to read the draft document text and send any comments > to address-policy-wg at ripe.net before 14 March 2007. > > Regards > > Filiz Yilmaz > RIPE NCC > Policy Development Officer > -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From Woeber at CC.UniVie.ac.at Wed Feb 14 18:41:39 2007 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 14 Feb 2007 17:41:39 +0000 Subject: [address-policy-wg] 2006-05 New Draft Document Published (PI Assignment Size) In-Reply-To: <20070214163352.AF8552F583@herring.ripe.net> References: <20070214163352.AF8552F583@herring.ripe.net> Message-ID: <45D349D3.1020103@CC.UniVie.ac.at> I oppose that proposal, and for more than 1 reason... - "...when routing is a major issue for the End User" there is no definition of "major issue" and there is no indication regarding which entity has to qualify or check this statement. In effect this will open a path to a minimum /24 assignment per site, and PI instead of PA. - when the ISPs decide to NOT route some small address blocks then trying to circumvent their configuration and intent by messing around with address assignment policies is royally broken. If this is really an operational problem then it needs a resolution on the routing plane. - "...suggests to add an assignment criteria to make sure the PI space is assigned to those networks that really need it. Multihoming seems" I consider a policy proposal which uses words and phrases like "suggests to" an "seems" to be broken. - on a more general note, as long as the minimum assignemt size for customers receiving PA is raised to /24, too, this proposal is a real incentive to go for PI instead of PA. Wilfried. From gert at space.net Wed Feb 14 18:48:11 2007 From: gert at space.net (Gert Doering) Date: Wed, 14 Feb 2007 18:48:11 +0100 Subject: [address-policy-wg] 2006-05 New Draft Document Published (PI Assignment Size) In-Reply-To: <45D349D3.1020103@CC.UniVie.ac.at> References: <20070214163352.AF8552F583@herring.ripe.net> <45D349D3.1020103@CC.UniVie.ac.at> Message-ID: <20070214174811.GP28483@Space.Net> Hi, On Wed, Feb 14, 2007 at 05:41:39PM +0000, Wilfried Woeber, UniVie/ACOnet wrote: > - on a more general note, as long as the minimum assignemt size for customers > receiving PA is raised to /24, too, this proposal is a real incentive to go > for PI instead of PA. A "not" is missing somewhere in this sentence, but I think the intended meaning is clear :) (not commenting on the policy proposal itself) Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 98999 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From Woeber at CC.UniVie.ac.at Wed Feb 14 19:17:51 2007 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 14 Feb 2007 18:17:51 +0000 Subject: [address-policy-wg] 2006-05 New Draft Document Published (PI Assignment Size) In-Reply-To: <20070214174811.GP28483@Space.Net> References: <20070214163352.AF8552F583@herring.ripe.net> <45D349D3.1020103@CC.UniVie.ac.at> <20070214174811.GP28483@Space.Net> Message-ID: <45D3524F.4090307@CC.UniVie.ac.at> You are right, thanks for spotting it! It should have read "...receiving PA is not raised to /24, too... Wilfried. Gert Doering wrote: > Hi, > > On Wed, Feb 14, 2007 at 05:41:39PM +0000, Wilfried Woeber, UniVie/ACOnet wrote: > >>- on a more general note, as long as the minimum assignemt size for customers >>receiving PA is raised to /24, too, this proposal is a real incentive to go >>for PI instead of PA. > > > A "not" is missing somewhere in this sentence, but I think the intended > meaning is clear :) > > (not commenting on the policy proposal itself) > > Gert Doering > -- APWG chair From fgarcia at eurocomercial.es Wed Feb 14 21:42:52 2007 From: fgarcia at eurocomercial.es (=?ISO-8859-1?Q?Fernando_Garc=EDa?=) Date: Wed, 14 Feb 2007 21:42:52 +0100 Subject: [address-policy-wg] 2006-05 New Draft Document Published (PI Assignment Size) In-Reply-To: <45D349D3.1020103@CC.UniVie.ac.at> References: <20070214163352.AF8552F583@herring.ripe.net> <45D349D3.1020103@CC.UniVie.ac.at> Message-ID: Well I support the proposal El 14/02/2007, a las 18:41, Wilfried Woeber, UniVie/ACOnet escribi?: > - "...when routing is a major issue for the End User" > > there is no definition of "major issue" and there is no indication > regarding which entity has to qualify or check this statement. My understand of "major issue" is "when the end user is going to use it for routing to/from Internet" > > In effect this will open a path to a minimum /24 assignment per site, > and PI instead of PA. Not a bad idea. If a end user wants multihoming, he will get it (becoming a LIR itself, getting a slice of a PA and announcing it independently,etc.: money talks and RIR listen) and probably (I think so) this is the least dangerous way to do it. It will increase the routing table size like any other but at least this will help to preserve some address space. > > - when the ISPs decide to NOT route some small address blocks then > trying to circumvent their configuration and intent by messing around > with address assignment policies is royally broken. If this is really > an operational problem then it needs a resolution on the routing > plane. I dont see it as an operational problem. I see it as a business problem. Companies want/need multihoming and will get it one way of another. We can set up things to do it in the least dangerous way or try to oppose it and see how things get worse. > > - on a more general note, as long as the minimum assignemt size for > customers > receiving PA is raised to /24, too, this proposal is a real > incentive to go > for PI instead of PA. I agree with that. I don't see a real reason to assign lower than /24 to any customer (and assigning less than /24 is a nightmare for reverse DNS). My two cents. > ------------------------------------------------ Tecnocom Fernando Garcia Eurocomercial - Depto T?cnico Josefa Valc?rcel 26, Edificio Merrimack III Madrid 28027 Tel: +34 91 4359687 Fax: +34 91 4313240 e-mail: fgarcia at eurocomercial.es http://www.tecnocom.biz http://www.eurocomercial.es From president at ukraine.su Thu Feb 15 12:54:38 2007 From: president at ukraine.su (Max Tulyev) Date: Thu, 15 Feb 2007 13:54:38 +0200 Subject: [address-policy-wg] 2006-05 New Draft Document Published (PI Assignment Size) In-Reply-To: References: <20070214163352.AF8552F583@herring.ripe.net> <45D349D3.1020103@CC.UniVie.ac.at> Message-ID: <45D449FE.3000001@ukraine.su> Fernando Garc?a wrote: > I agree with that. I don't see a real reason to assign lower than /24 to > any customer (and assigning less than /24 is a nightmare for reverse DNS). There is a reason. If there is a address space not need to be routed globally, but need to be unique. For example, city-wide Internet exchange point. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From sokolovsky at seaexpress.ru Thu Feb 15 15:11:56 2007 From: sokolovsky at seaexpress.ru (Sokolovsky Andrey) Date: Thu, 15 Feb 2007 17:11:56 +0300 Subject: [address-policy-wg] RIPE Policy Proposal 2006-05 Message-ID: Hi, Our customer would like to have PI address space, but his requirement is something under /24 prefix. As many ISPs filter prefixes smaller than /24.These networks could be announced, but actually not working properly. As "RIPE Policy Proposal 2006-05" with status "open for discussion" I wish to vote for this document. Regards, Andrey Sokolovsky From president at ukraine.su Mon Feb 19 00:06:11 2007 From: president at ukraine.su (Max Tulyev) Date: Sun, 18 Feb 2007 23:06:11 +0000 Subject: [address-policy-wg] 2006-05 New Draft Document Published (PI Assignment Size) In-Reply-To: <45D349D3.1020103@CC.UniVie.ac.at> References: <20070214163352.AF8552F583@herring.ripe.net> <45D349D3.1020103@CC.UniVie.ac.at> Message-ID: <45D8DBE3.6050906@ukraine.su> Wilfried Woeber, UniVie/ACOnet wrote: > - on a more general note, as long as the minimum assignemt size for customers > receiving PA is raised to /24, too, this proposal is a real incentive to go > for PI instead of PA. Who need PI for global routing - get it and use now without any problem. There is a difference between policy and the real. This proposal eliminates this difference. I think it is good. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From filiz at ripe.net Mon Feb 26 07:02:32 2007 From: filiz at ripe.net (Filiz Yilmaz) Date: Mon, 26 Feb 2007 07:02:32 +0100 Subject: [address-policy-wg] 2006-02 Discussion Period extended until 19 March 2007 (IPv6 Address Allocation and Assignment Policy) Message-ID: <20070226060232.795982F583@herring.ripe.net> PDP Number: 2006-02 IPv6 Address Allocation and Assignment Policy Dear Colleagues The Discussion Period for the proposal 2006-06 has been extended until until 19 March 2007. This proposal is to change the IPv6 Initial Allocation criteria and the End Site definition in the "IPv6 Address Allocation and Assignment Policy". 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 . Regards Filiz Yilmaz RIPE NCC Policy Development Officer From gert at space.net Mon Feb 26 07:50:11 2007 From: gert at space.net (Gert Doering) Date: Mon, 26 Feb 2007 07:50:11 +0100 Subject: [address-policy-wg] Re: 2006-02 Discussion Period extended until 19 March 2007 (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <20070226060232.795982F583@herring.ripe.net> References: <20070226060232.795982F583@herring.ripe.net> Message-ID: <20070226065011.GK28483@Space.Net> Hi everybody, I have asked Filiz to extend the discussion period for this proposal, because there have been *no* comments in the last round - but the proposal itself was changed, and as such, I can't just declare "consensus" or "no consensus" here. Please give us your input on whether you think the proposal *as written right now* is a good thing to have. regards, Gert Doering, Address Policy WG Chair On Mon, Feb 26, 2007 at 07:02:32AM +0100, Filiz Yilmaz wrote: > PDP Number: 2006-02 > IPv6 Address Allocation and Assignment Policy > > Dear Colleagues > > The Discussion Period for the proposal 2006-06 has been extended > until until 19 March 2007. > > This proposal is to change the IPv6 Initial Allocation criteria and > the End Site definition in the "IPv6 Address Allocation and > Assignment Policy". > > 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 . > > Regards > > Filiz Yilmaz > RIPE NCC > Policy Development Officer > Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 98999 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 305 bytes Desc: not available URL: From mike.simkins at mac.com Mon Feb 26 10:34:36 2007 From: mike.simkins at mac.com (Mike Simkins) Date: Mon, 26 Feb 2007 09:34:36 +0000 Subject: [address-policy-wg] Re: 2006-02 Discussion Period extended until 19 March 2007 (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <20070226065011.GK28483@Space.Net> References: <20070226060232.795982F583@herring.ripe.net> <20070226065011.GK28483@Space.Net> Message-ID: <45E2A9AC.1050803@mac.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I cannot personally see any problems with this, since the holder of the block should (must?) advertise it as a single aggregate, the routing tables should not grow dependent on if the provider makes 1 or 65000 IPv6 assignments Mike. Gert Doering wrote: > Hi everybody, > > I have asked Filiz to extend the discussion period for this proposal, > because there have been *no* comments in the last round - but the proposal > itself was changed, and as such, I can't just declare "consensus" or > "no consensus" here. > > Please give us your input on whether you think the proposal *as written > right now* is a good thing to have. > > regards, > > Gert Doering, > Address Policy WG Chair > > > On Mon, Feb 26, 2007 at 07:02:32AM +0100, Filiz Yilmaz wrote: >> PDP Number: 2006-02 >> IPv6 Address Allocation and Assignment Policy >> >> Dear Colleagues >> >> The Discussion Period for the proposal 2006-06 has been extended >> until until 19 March 2007. >> >> This proposal is to change the IPv6 Initial Allocation criteria and >> the End Site definition in the "IPv6 Address Allocation and >> Assignment Policy". >> >> 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 . >> >> Regards >> >> Filiz Yilmaz >> RIPE NCC >> Policy Development Officer >> > > > Gert Doering > -- NetMaster -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (Darwin) iD8DBQFF4qirxUvvuPE3k4oRAuSTAJ9h7Jx5/hM+T+fswHqQTJlVMXoJRgCdHqWC M2YrsdRI6eL9rSH4HoBoUWI= =HM9j -----END PGP SIGNATURE----- From Woeber at CC.UniVie.ac.at Mon Feb 26 11:56:10 2007 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Mon, 26 Feb 2007 10:56:10 +0000 Subject: [address-policy-wg] Re: 2006-02 Discussion Period extended until 19 March 2007 (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <20070226065011.GK28483@Space.Net> References: <20070226060232.795982F583@herring.ripe.net> <20070226065011.GK28483@Space.Net> Message-ID: <45E2BCCA.9040303@CC.UniVie.ac.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [ sorry, Gert, for only sending to you privately on my 1st attempt :-/ ] Gert Doering wrote: > Hi everybody, > > I have asked Filiz to extend the discussion period for this proposal, > because there have been *no* comments in the last round - but the proposal > itself was changed, and as such, I can't just declare "consensus" or > "no consensus" here. > > Please give us your input on whether you think the proposal *as written > right now* is a good thing to have. I fully support the proposal. Just as an editorial comment: We should also remove the "requirement" to advertise the prefix. This is another (useless) artificial barrier to the deployment of IPv6 as a generally avalable technology for building networks. Even if it is kept, the holder of a prefix can still "advertise" the prefix to - well to whom and where?? Central IPv6 Routing Police? - and still *not* carry traffic for any particular application. What have we got, other than a useless occupied slot in some routing tables... I'd propose to reword it slightly along the lines of: "If the prefix is advertised or announced towards the routing core it has to be advertised as, or aggregated into, a single announcement." I'm sure "Routing" can help with this if needed. Wilfried > regards, > > Gert Doering, > Address Policy WG Chair -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) iQCVAwUBReK8yd/RXX7wrLNpAQJdnwP/XrZo9I1oYMA5nkvY+bVM6IGuw4O0xvVq CGiwfnkkmbL7gnABrbu386ELVTvc2frF68p/T0V5OeiInJBy3Yi6rt8kI6mI1cYE UAhbbjQ4x4KRO69HVH1I8jGh+yd8AjzJnd+g8vbXcA11c80EPEDlP33N5FJOEJhe qZ92VsSh7JA= =Psu+ -----END PGP SIGNATURE----- From slz at baycix.de Mon Feb 26 12:52:52 2007 From: slz at baycix.de (Sascha Lenz) Date: Mon, 26 Feb 2007 12:52:52 +0100 Subject: [address-policy-wg] Re: 2006-02 Discussion Period extended until 19 March 2007 (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <20070226065011.GK28483@Space.Net> References: <20070226060232.795982F583@herring.ripe.net> <20070226065011.GK28483@Space.Net> Message-ID: <45E2CA14.9060206@baycix.de> Hi, Gert Doering schrieb: > Hi everybody, > > I have asked Filiz to extend the discussion period for this proposal, > because there have been *no* comments in the last round - but the proposal > itself was changed, and as such, I can't just declare "consensus" or > "no consensus" here. that's the whole problem with this "democracy" thing :-) Existing Allocation holders might not care anymore, others might not read the relevant mailinglists/webpages <...> (and some get bored of the lenghtly PDP ...) > Please give us your input on whether you think the proposal *as written > right now* is a good thing to have. *** VOTE *** If it comes to a vote: This is a *YES* for the vote-counter, as written right now. *** VOTE *** I supported the key point of the proposal (getting rid of some no longer needed obstacles for LIRs who want to get an IPv6 Allocation) from the start, so the changes are fine with me. I don't think there are any relevant downsides like (relevant) routing table growth -> i don't see _any_ downsides from the main changes. What i won't do now is commenting on minor wording issues; i want this proposal to be passed, NOW, not to continue some more years with some more versions of the draft. I think this can be dealt with in a follow-up proposal if really needed in this case. The main points are fine. (BTW: This is not a personal issue, i have all my IPv6 Allocations already :-) I just want to get this done for the sake of IPv6 distribution since we're discussing about that for ages now!) -- ======================================================================== = Sascha Lenz SLZ-RIPE slz at baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ======================================================================== From nick at inex.ie Mon Feb 26 13:14:07 2007 From: nick at inex.ie (Nick Hilliard) Date: Mon, 26 Feb 2007 12:14:07 +0000 Subject: [address-policy-wg] Re: 2006-02 Discussion Period extended until 19 March 2007 (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <45E2BCCA.9040303@CC.UniVie.ac.at> References: <20070226060232.795982F583@herring.ripe.net> <20070226065011.GK28483@Space.Net> <45E2BCCA.9040303@CC.UniVie.ac.at> Message-ID: <45E2CF0F.4000809@inex.ie> > Just as an editorial comment: We should also remove the "requirement" to > advertise the prefix. This is another (useless) artificial barrier to the > deployment of IPv6 as a generally avalable technology for building networks. I'd like to second Wilfred on this point. Just because RIPE has allocated address space, this does not mean that the address space will be visible on the Internet at any particular stage. RIPE NCC provides a general address space registry function, not just a public internet address registry function. While there is an argument for using PI for private assignments, right now we can't do this in ipv6, because there is no ipv6 PI space yet. But more importantly, there are situations where it may be appropriate for a private entity to register large amounts of v6 address space, where PI would be less appropriate due to sub-assignment issues. Nick Hilliard -- Network Ability Ltd. | Head of Operations | Tel: +353 1 6169698 3 Westland Square | INEX - Internet Neutral | Fax: +353 1 6041981 Dublin 2, Ireland | Exchange Association | Email: nick at inex.ie From s.steffann at computel.nl Mon Feb 26 13:31:41 2007 From: s.steffann at computel.nl (Sander Steffann) Date: Mon, 26 Feb 2007 13:31:41 +0100 Subject: [address-policy-wg] Re: 2006-02 Discussion Period extended until 19 March 2007 (IPv6 Address Allocation and Assignment Policy) References: <20070226060232.795982F583@herring.ripe.net> <20070226065011.GK28483@Space.Net> Message-ID: <007a01c759a2$57cec090$64c8a8c0@balefirehome> Hi, > Please give us your input on whether you think the proposal *as written > right now* is a good thing to have. Looks good to me - Sander From jorgen at hovland.cx Mon Feb 26 13:21:49 2007 From: jorgen at hovland.cx (=?UTF-8?Q?J=C3=B8rgen_Hovland?=) Date: Mon, 26 Feb 2007 13:21:49 +0100 Subject: [address-policy-wg] Re: 2006-02 Discussion Period extended until 19 March 2007 (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <45E2CF0F.4000809@inex.ie> References: <20070226060232.795982F583@herring.ripe.net> <20070226065011.GK28483@Space.Net> <45E2BCCA.9040303@CC.UniVie.ac.at> <45E2CF0F.4000809@inex.ie> Message-ID: <012b01c759a0$b12cc850$9227b3d5@tungemaskin> I don't really disagree with any of this, but RIPE is a registry. I don't think an address allocation policy should have any requirements with regards to any global or internal routing table as it is out of scope. It could however have recommendations or helpful hints like "if the prefix is advertised on the internet and not announced as a single aggregate, the prefix will most likely be filtered by many parties". j -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Nick Hilliard Sent: 26. februar 2007 13:14 To: Woeber at CC.UniVie.ac.at Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] Re: 2006-02 Discussion Period extended until 19 March 2007 (IPv6 Address Allocation and Assignment Policy) > Just as an editorial comment: We should also remove the "requirement" to > advertise the prefix. This is another (useless) artificial barrier to the > deployment of IPv6 as a generally avalable technology for building networks. I'd like to second Wilfred on this point. Just because RIPE has allocated address space, this does not mean that the address space will be visible on the Internet at any particular stage. RIPE NCC provides a general address space registry function, not just a public internet address registry function. While there is an argument for using PI for private assignments, right now we can't do this in ipv6, because there is no ipv6 PI space yet. But more importantly, there are situations where it may be appropriate for a private entity to register large amounts of v6 address space, where PI would be less appropriate due to sub-assignment issues. Nick Hilliard -- Network Ability Ltd. | Head of Operations | Tel: +353 1 6169698 3 Westland Square | INEX - Internet Neutral | Fax: +353 1 6041981 Dublin 2, Ireland | Exchange Association | Email: nick at inex.ie From Woeber at CC.UniVie.ac.at Mon Feb 26 13:39:08 2007 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Mon, 26 Feb 2007 12:39:08 +0000 Subject: [address-policy-wg] Re: 2006-02 Discussion Period extended until 19 March 2007 (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <45E2CA14.9060206@baycix.de> References: <20070226060232.795982F583@herring.ripe.net> <20070226065011.GK28483@Space.Net> <45E2CA14.9060206@baycix.de> Message-ID: <45E2D4EC.1080504@CC.UniVie.ac.at> Sascha, Sascha Lenz wrote: > Hi, > > Gert Doering schrieb: > >> Hi everybody, [...] > > I supported the key point of the proposal (getting rid of some no longer > needed obstacles for LIRs who want to get an IPv6 Allocation) from the > start, so the changes are fine with me. > > I don't think there are any relevant downsides like (relevant) routing > table growth -> i don't see _any_ downsides from the main changes. > > What i won't do now is commenting on minor wording issues; i want this > proposal to be passed, NOW, not to continue some more years with some > more versions of the draft. I think this can be dealt with in a > follow-up proposal if really needed in this case. The main points are fine. thanks for pointing out *that* aspect, I am with you. My proposal was more along the lines of - if we have to touch it again, anyway,... > (BTW: This is not a personal issue, i have all my IPv6 Allocations > already :-) I just want to get this done for the sake of IPv6 > distribution since we're discussing about that for ages now!) Same here :-) Wilfried. From slz at baycix.de Mon Feb 26 13:46:24 2007 From: slz at baycix.de (Sascha Lenz) Date: Mon, 26 Feb 2007 13:46:24 +0100 Subject: [address-policy-wg] 2006-05 New Draft Document Published (PI Assignment Size) In-Reply-To: <20070214163352.AF8552F583@herring.ripe.net> References: <20070214163352.AF8552F583@herring.ripe.net> Message-ID: <45E2D6A0.90705@baycix.de> Hi, Filiz Yilmaz schrieb: > PDP Number: 2006-05 > PI Assignment Size > > Dear Colleagues > > We have published a draft document for the proposal described in > 2006-05. > > This proposal suggests to have the minimum assignment size for PI > assignments to be a /24 when routing is a major issue for a > multihoming End User. [...] *** VOTE *** For the votecounter: This is a *YES* for the proposal in general. *** VOTE *** For those who want to continue the discussion: Yes, i actually have problems with the proposal, but only in theory. Wilfried makes some valid points. Routing-problems "should not" be solved by some address policy, this proposal might be a problem for PA vs. PI assignments ("why should i go for PA!?") and some of the wording is quite fishy ("routing being a major issue", "suggests to"). Unfortunately, i have to come up with my almighty killer-argument: "real life" :-/ a) Solving routing issues with Address Policy changes Not nice, but how do you change routing habbits? Not at all. Routing is no central thing but a distributed one. Noone can tell anyone else what/how/whom to route. Just look at the problems with de-bogonizing new /8 blocks, or the ongoing IPv6 filter-criteria discussion with personal feelings taking over routing/filter descisions because there is no tie-breaker who makes the global descision for a particular routing policy (yes, IPv6 might be a completely different thing here than IPv4, but i think you all get my point). ==> It's not possible to solve this particular problem in the routing domain. OTOH, Address Policy is a rather central thing, at least within a RIR region. So we actually CAN change something here. There is no other way to address this PI-Assignment-routing-issue than changing the assignment policy. The only valid question here is, "_IS_ there a problem? do we _need_ to change anything here?". But i guess we're already past this point. It is an actual problem for RIPE (people coming back many times when they realize what they have done with requesting >/24 Prefixes, then some lies, then they get what they really want - <=/24), and for the LIRs/Endusers since they have problems with a lenghtly Address requesting process. This policy would just fit real-life a little better. b) PI vs. PA I don't think that's a problem. People who KNOW about PI vs. PA and WANT PI, will always go for PI, nowerdays they just lie about the needed size. So i don't see a relevant amount of entities going for PI instead of PA now when this virtual "barrier" of routability falls. Of course, there will be SOME. c) IPv4-Address (& Aut-num?) space wasted? I don't care. There is IPv6 and 4byte ASNs. Please, waste IPv4 as much as possible so we can go for IPv6 :-) No issue there. d) Wording - "routing a major issue" Well that's perfectly clear i think. If the Assignment is advertised from an "PI-only" AS, that's a valid "major routing issue" for me for example. This just simplifies things. As we all know, people lie about that anyways if needed, so why make up a complicated list of valid reasons here? Hostmasters at RIPE are clueful enough to ask the right questions about fishy requests. - "The proposal also suggests to add an assignment criteria to make sure the PI space is assigned to those networks that really need it." Well this is only part of the proposal text, not of the policy draft. Bad idea, but i think it's safe to just ignore it :-) Again: Real-life == people lie anyways. And i don't want to make RIPE require thousands of documents and stuff for a simple IP assignment. This process should be _EASY_ for anyone (even with PI space). ==> Many problems with the proposal in theory, but all not real-life proof. The RIRs and LIRs have to keep up with the actual needs out there, as bad as that sounds for some of our ears :-/ P.S.: This mail might be a little confusing(?) since i was interrupted multiple times while composing it and i don't have the time for cleaning it up before sending now, sorry. -- ======================================================================== = Sascha Lenz SLZ-RIPE slz at baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ======================================================================== From michael.dillon at bt.com Mon Feb 26 10:27:02 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 26 Feb 2007 09:27:02 -0000 Subject: [address-policy-wg] 2006-02 Discussion Period extended until 19 March 2007 (IPv6 Address Allocation and Assignment Policy) Message-ID: <2DA00C5A2146FB41ABDB3E9FCEBC74C1012F1A1A@i2km07-ukbr.domain1.systemhost.net> > http://ripe.net/ripe/policies/proposals/2006-02.html Given that IPv6 is currently not primarily used by commercial network service providers, I think that this is an excellent revision. It allows the traditional network pionering organizations, universities, to justify an IPv6 allocation and it is broad enough that any commercial service provider who wishes to use IPv6 can still get an allocation. --Michael Dillon From michael.dillon at bt.com Mon Feb 26 13:33:36 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 26 Feb 2007 12:33:36 -0000 Subject: [address-policy-wg] Re: 2006-02 Discussion Period extended until 19 March 2007 (IPv6 Address Allocation and Assignment Policy) Message-ID: <2DA00C5A2146FB41ABDB3E9FCEBC74C1012F212A@i2km07-ukbr.domain1.systemhost.net> > > Just as an editorial comment: We should also remove the > "requirement" to > > advertise the prefix. I suppose that could be interpreted as "announce to at least one other AS using BGP4" which can be done without ever having the prefix visible on the public Internet. However, due to the ambiguity of the word "advertise" it would be good to get rid of it and put something less Internet-centric in its place. After all, RFC 2050 explicitly states that RIRs can allocate prefixes that will never be used on the Internet. The RIRs allocate IP resources, not Internet resources. > While there is an argument for using PI for private > assignments, right now > we can't do this in ipv6, because there is no ipv6 PI space > yet. But more > importantly, there are situations where it may be appropriate > for a private > entity to register large amounts of v6 address space, where > PI would be > less appropriate due to sub-assignment issues. In particular, there is a general misunderstanding of what "private addressing" means because most people have not read RFC 1918 carefully enough. Many people feel that addresses used on the Internet are "public" and therefore addresses that are not used on the Internet are private. This implies that all non-Internet use of IPv4 addresses should use RFC 1918 allocated ranges. However, that's not the case at all. In fact, RFC 1918 has allocated ranges for networks which will never interconnect. In other words, the word "private" refers to the networks themselves. A private network is one which never connects to another network. In the real world there are many instances of non-Internet IP networks which do interconnect, often on a large scale. Because they interconnect, they need unique addresses, i.e. RIR allocations. In the IPv4 world, people would rig up complex workarounds because of address scarcity, such as double-NAT. However, in the IPv6 world this is not necessary and RIR policy should not force people into replicating these workarounds. --Michael Dillon From jordi.palet at consulintel.es Tue Feb 27 08:56:31 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Tue, 27 Feb 2007 15:56:31 +0800 Subject: [address-policy-wg] Re: 2006-02 Discussion Period extended until 19 March 2007 (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <20070226065011.GK28483@Space.Net> Message-ID: I think the proposal now is more focused and less complex than v1, and tried to follow the suggestions received from the majority of the people that was in favor, so hopefully they can publicly speak up if they are still in favor. Regards, Jordi > De: Gert Doering > Responder a: > Fecha: Mon, 26 Feb 2007 07:50:11 +0100 > Para: "address-policy-wg at ripe.net" > Asunto: [address-policy-wg] Re: 2006-02 Discussion Period extended until 19 > March 2007 (IPv6 Address Allocation and Assignment Policy) > > Hi everybody, > > I have asked Filiz to extend the discussion period for this proposal, > because there have been *no* comments in the last round - but the proposal > itself was changed, and as such, I can't just declare "consensus" or > "no consensus" here. > > Please give us your input on whether you think the proposal *as written > right now* is a good thing to have. > > regards, > > Gert Doering, > Address Policy WG Chair > > > On Mon, Feb 26, 2007 at 07:02:32AM +0100, Filiz Yilmaz wrote: >> PDP Number: 2006-02 >> IPv6 Address Allocation and Assignment Policy >> >> Dear Colleagues >> >> The Discussion Period for the proposal 2006-06 has been extended >> until until 19 March 2007. >> >> This proposal is to change the IPv6 Initial Allocation criteria and >> the End Site definition in the "IPv6 Address Allocation and >> Assignment Policy". >> >> 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 . >> >> Regards >> >> Filiz Yilmaz >> RIPE NCC >> Policy Development Officer >> > > > Gert Doering > -- NetMaster > -- > Total number of prefixes smaller than registry allocations: 98999 > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 ********************************************** 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. From jordi.palet at consulintel.es Tue Feb 27 09:12:19 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Tue, 27 Feb 2007 16:12:19 +0800 Subject: [address-policy-wg] Re: 2006-02 Discussion Period extended until 19 March 2007 (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <45E2CF0F.4000809@inex.ie> Message-ID: Hi Nick, I believe it will be more appropriate to use in those cases ULA or ULA-central (this needs to be rescued and moved up in the IETF process, as I already voiced in ppml and in the last ARIN meeting). However, the point here is to know if you will still support this policy proposal "as is" right now, so we can finally get this done and then new changes applied in the future, or if I need to send a new version which doesn't include the "advertisement" bit, so we can vote for both ? By the way, trying to answer also Wilfried's email, I think the "to whom" it is advertised may be clarified as "The LIR must advertise *to the next hops* the single address block through a single aggregated prefix.". Regards, Jordi > De: Nick Hilliard > Responder a: > Fecha: Mon, 26 Feb 2007 12:14:07 +0000 > Para: > CC: "address-policy-wg at ripe.net" > Asunto: Re: [address-policy-wg] Re: 2006-02 Discussion Period extended until > 19 March 2007 (IPv6 Address Allocation and Assignment Policy) > >> Just as an editorial comment: We should also remove the "requirement" to >> advertise the prefix. This is another (useless) artificial barrier to the >> deployment of IPv6 as a generally avalable technology for building networks. > > I'd like to second Wilfred on this point. Just because RIPE has allocated > address space, this does not mean that the address space will be visible on > the Internet at any particular stage. RIPE NCC provides a general address > space registry function, not just a public internet address registry function. > > While there is an argument for using PI for private assignments, right now > we can't do this in ipv6, because there is no ipv6 PI space yet. But more > importantly, there are situations where it may be appropriate for a private > entity to register large amounts of v6 address space, where PI would be > less appropriate due to sub-assignment issues. > > > Nick Hilliard > -- > Network Ability Ltd. | Head of Operations | Tel: +353 1 6169698 > 3 Westland Square | INEX - Internet Neutral | Fax: +353 1 6041981 > Dublin 2, Ireland | Exchange Association | Email: nick at inex.ie > ********************************************** 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. From Woeber at CC.UniVie.ac.at Tue Feb 27 09:45:00 2007 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 27 Feb 2007 08:45:00 +0000 Subject: [address-policy-wg] Re: 2006-02 Discussion Period extended until 19 March 2007 (IPv6 Address Allocation and Assignment Policy) In-Reply-To: References: Message-ID: <45E3EF8C.20409@CC.UniVie.ac.at> JORDI PALET MARTINEZ wrote: > Hi Nick, > > I believe it will be more appropriate to use in those cases ULA or > ULA-central (this needs to be rescued and moved up in the IETF process, as I > already voiced in ppml and in the last ARIN meeting). > > However, the point here is to know if you will still support this policy > proposal "as is" right now, so we can finally get this done and then new > changes applied in the future, or if I need to send a new version which > doesn't include the "advertisement" bit, so we can vote for both ? For obvious reasons I cannot speak for Nick, but my take here is - get it out through the door as it is, if there's support for it. Then we can start a next round to improve. The "real" issue at the moment is to change the address distribution policy, and not the fine-tuning of routing recommendations. > By the way, trying to answer also Wilfried's email, I think the "to whom" it > is advertised may be clarified as "The LIR must advertise *to the next hops* > the single address block through a single aggregated prefix.". This is one aspect I am not so sure about: "to the next hops". There may well be very good reasons to advertise smaller portions to your next hop(s). And "we" really don't care about that, do we? The "real" issue imho is to make sure that just one prefix makes it to the core/DFZ/. And as has been pointed out already, from the point of view of an RIR this is (should be?) more like a (strong) recommendation than a formal *address policy* aspect. If this recommendation is violated, the RIR doesn't have appropriate means to sanction anyway... Wilfried. > Regards, > Jordi > > > > > >>De: Nick Hilliard >>Responder a: >>Fecha: Mon, 26 Feb 2007 12:14:07 +0000 >>Para: >>CC: "address-policy-wg at ripe.net" >>Asunto: Re: [address-policy-wg] Re: 2006-02 Discussion Period extended until >>19 March 2007 (IPv6 Address Allocation and Assignment Policy) >> >> >>>Just as an editorial comment: We should also remove the "requirement" to >>>advertise the prefix. This is another (useless) artificial barrier to the >>>deployment of IPv6 as a generally avalable technology for building networks. >> >>I'd like to second Wilfred on this point. Just because RIPE has allocated >>address space, this does not mean that the address space will be visible on >>the Internet at any particular stage. RIPE NCC provides a general address >>space registry function, not just a public internet address registry function. >> >>While there is an argument for using PI for private assignments, right now >>we can't do this in ipv6, because there is no ipv6 PI space yet. But more >>importantly, there are situations where it may be appropriate for a private >>entity to register large amounts of v6 address space, where PI would be >>less appropriate due to sub-assignment issues. >> >> >>Nick Hilliard >>-- >>Network Ability Ltd. | Head of Operations | Tel: +353 1 6169698 >>3 Westland Square | INEX - Internet Neutral | Fax: +353 1 6041981 >>Dublin 2, Ireland | Exchange Association | Email: nick at inex.ie From jordi.palet at consulintel.es Tue Feb 27 10:40:10 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Tue, 27 Feb 2007 17:40:10 +0800 Subject: [address-policy-wg] Re: 2006-02 Discussion Period extended until 19 March 2007 (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <45E3EF8C.20409@CC.UniVie.ac.at> Message-ID: Below, in-line. > De: "Wilfried Woeber, UniVie/ACOnet" > Organizaci?n: UniVie - ACOnet > Responder a: > Fecha: Tue, 27 Feb 2007 08:45:00 +0000 > Para: > CC: "address-policy-wg at ripe.net" > Asunto: Re: [address-policy-wg] Re: 2006-02 Discussion Period extended until > 19 March 2007 (IPv6 Address Allocation and Assignment Policy) > > JORDI PALET MARTINEZ wrote: > >> Hi Nick, >> >> I believe it will be more appropriate to use in those cases ULA or >> ULA-central (this needs to be rescued and moved up in the IETF process, as I >> already voiced in ppml and in the last ARIN meeting). >> >> However, the point here is to know if you will still support this policy >> proposal "as is" right now, so we can finally get this done and then new >> changes applied in the future, or if I need to send a new version which >> doesn't include the "advertisement" bit, so we can vote for both ? > > For obvious reasons I cannot speak for Nick, but my take here is - get it out > through the door as it is, if there's support for it. Then we can start a next > round to improve. The "real" issue at the moment is to change the address > distribution policy, and not the fine-tuning of routing recommendations. Ok, thanks. > >> By the way, trying to answer also Wilfried's email, I think the "to whom" it >> is advertised may be clarified as "The LIR must advertise *to the next hops* >> the single address block through a single aggregated prefix.". > > This is one aspect I am not so sure about: "to the next hops". There may well > be very good reasons to advertise smaller portions to your next hop(s). And > "we" really don't care about that, do we? The "real" issue imho is to make > sure that just one prefix makes it to the core/DFZ/. > > And as has been pointed out already, from the point of view of an RIR this is > (should be?) more like a (strong) recommendation than a formal *address > policy* > aspect. If this recommendation is violated, the RIR doesn't have appropriate > means to sanction anyway... Well, I'm not sure I agree ... But I think it will be better to stop this part of the thread here if we want to move ahead now :-) > > Wilfried. > >> Regards, >> Jordi >> >> >> >> >> >>> De: Nick Hilliard >>> Responder a: >>> Fecha: Mon, 26 Feb 2007 12:14:07 +0000 >>> Para: >>> CC: "address-policy-wg at ripe.net" >>> Asunto: Re: [address-policy-wg] Re: 2006-02 Discussion Period extended until >>> 19 March 2007 (IPv6 Address Allocation and Assignment Policy) >>> >>> >>>> Just as an editorial comment: We should also remove the "requirement" to >>>> advertise the prefix. This is another (useless) artificial barrier to the >>>> deployment of IPv6 as a generally avalable technology for building >>>> networks. >>> >>> I'd like to second Wilfred on this point. Just because RIPE has allocated >>> address space, this does not mean that the address space will be visible on >>> the Internet at any particular stage. RIPE NCC provides a general address >>> space registry function, not just a public internet address registry >>> function. >>> >>> While there is an argument for using PI for private assignments, right now >>> we can't do this in ipv6, because there is no ipv6 PI space yet. But more >>> importantly, there are situations where it may be appropriate for a private >>> entity to register large amounts of v6 address space, where PI would be >>> less appropriate due to sub-assignment issues. >>> >>> >>> Nick Hilliard >>> -- >>> Network Ability Ltd. | Head of Operations | Tel: +353 1 6169698 >>> 3 Westland Square | INEX - Internet Neutral | Fax: +353 1 6041981 >>> Dublin 2, Ireland | Exchange Association | Email: nick at inex.ie > ********************************************** 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. From filiz at ripe.net Tue Feb 27 10:55:41 2007 From: filiz at ripe.net (Filiz Yilmaz) Date: Tue, 27 Feb 2007 10:55:41 +0100 Subject: [address-policy-wg] 2006-07 Last Call for Comments (First Raise in IPv4 Assignment Window Size) Message-ID: <20070227095541.726292F583@herring.ripe.net> PDP Number: 2006-07 First Raise in IPv4 Assignment Window Size Dear Colleagues The proposal described in 2006-07 is now at its Concluding Phase. 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 Please e-mail any final comments about this proposal to address-policy-wg at ripe.net before 27 March 2007. Regards Filiz Yilmaz RIPE NCC Policy Development Officer From Woeber at CC.UniVie.ac.at Tue Feb 27 11:08:20 2007 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 27 Feb 2007 10:08:20 +0000 Subject: [address-policy-wg] Re: 2006-02 Discussion Period extended until 19 March 2007 (IPv6 Address Allocation and Assignment Policy) In-Reply-To: References: Message-ID: <45E40314.5080208@CC.UniVie.ac.at> JORDI PALET MARTINEZ wrote: [...] > Well, I'm not sure I agree ... But I think it will be better to stop this > part of the thread here if we want to move ahead now :-) Correct :-) -W From michael.dillon at bt.com Tue Feb 27 11:27:34 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 27 Feb 2007 10:27:34 -0000 Subject: [address-policy-wg] Re: 2006-02 Discussion Period extended until 19 March 2007 (IPv6 Address Allocation and Assignment Policy) Message-ID: <2DA00C5A2146FB41ABDB3E9FCEBC74C10137BC78@i2km07-ukbr.domain1.systemhost.net> > "we" really don't care about that, do we? The "real" issue > imho is to make > sure that just one prefix makes it to the core/DFZ/ favourite term here>. ...to make sure that no more than one prefix makes it to the core routing tables. If the organization heavily deaggregates these prefixes on an extranet, then this is fine as long as the owner of the extranet has no problem with it. The real issue is that the Internet has no owner and therefore it is not clear who should manage routing guidelines/recommendations. Since this is a grey area for the RIRs, might I suggest that all issues of routing be removed from IPv4, IPv6 and ASN policies in order to collect them together in a single "Routing Recommendations" document? This can then contain the necessary prose to clarify the differences between the Internet and other internetworks. That way we no longer have to worry about ambiguous references to "advertising" routes in the policies. > And as has been pointed out already, from the point of view > of an RIR this is > (should be?) more like a (strong) recommendation than a > formal *address policy* > aspect. If this recommendation is violated, the RIR doesn't > have appropriate > means to sanction anyway... All the more reason to collect this material in a document separate from the policies themselves. --Michael Dillon From madams at netcologne.de Tue Feb 27 09:41:55 2007 From: madams at netcologne.de (Michael Adams) Date: Tue, 27 Feb 2007 09:41:55 +0100 Subject: [address-policy-wg] Re: 2006-02 Discussion Period extended until 19 March 2007 (IPv6 Address Allocation and Assignment Poli In-Reply-To: <45E2BCCA.9040303@CC.UniVie.ac.at> References: <20070226060232.795982F583@herring.ripe.net>, <20070226065011.GK28483@Space.Net>, <45E2BCCA.9040303@CC.UniVie.ac.at> Message-ID: <45E3FCE3.3800.ED4CA2B2@madams.netcologne.de> Wilfried Woeber, UniVie/ACOne, 26 Feb 2007 10:56: > I fully support the proposal. Me too. If it comes to a vote I would say yes. > Just as an editorial comment: We should also remove the "requirement" to > advertise the prefix. This is another (useless) artificial barrier to the > deployment of IPv6 as a generally avalable technology for building networks. I'm still thinking about this point but right now I agree with Wilfried. I can imagine cases where allocated IPv6 is needed or very useful without connecting (now or during the next years) to the public internet or other private networks. > I'd propose to reword it slightly along the lines of: > > "If the prefix is advertised or announced towards the routing core it has > to be advertised as, or aggregated into, a single announcement." I like the idea of giving recommendations about this and pointing out what can happen when violating them. But I'm not sure if this is the right place. Also for me it's not clear which consequences not announcing or not aggregating prefixes will have (besides the technical ones). I suppose in this case Ripe _may_ do something, not _must_ do something. Fine for me. Anyway I support the proposal as it is. cheers, Michael -- Michael Adams Tel: +49 221 2222 657 Network Engineering & Design Fax: +49 221 2222 7657 NetCologne Gesch?ftsf?hrer Gesellschaft f?r Telekommunikation mbH Werner Hanf Am Coloneum 9 Dipl.-Ing. Karl-Heinz Zankel 50829 K?ln HRB 25580, Amtsgericht K?ln From gert at space.net Tue Feb 27 22:34:27 2007 From: gert at space.net (Gert Doering) Date: Tue, 27 Feb 2007 22:34:27 +0100 Subject: [address-policy-wg] Re: 2006-02 Discussion Period extended until 19 March 2007 (IPv6 Address Allocation and Assignment Poli In-Reply-To: <45E3FCE3.3800.ED4CA2B2@madams.netcologne.de> References: <45E2BCCA.9040303@CC.UniVie.ac.at> <45E3FCE3.3800.ED4CA2B2@madams.netcologne.de> Message-ID: <20070227213427.GB28483@Space.Net> Hi, just as a side note: On Tue, Feb 27, 2007 at 09:41:55AM +0100, Michael Adams wrote: > [...] If it comes to a vote I would say yes. We're *not* voting in "RIPE policy land" - if only due to practical problems "who gets to vote, who has how many votes, etc." But of course you're helping me/us by clearly stating "I am in favour of the proposal [because...]" or "I am opposing this proposal [because...]" :) So - thanks to those that have participated this round. Good input. regards, Gert Doering -- RIPE APWG chair -- Total number of prefixes smaller than registry allocations: 98999 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From ncc at ripe.net Mon Feb 12 16:38:13 2007 From: ncc at ripe.net (Andrei Robachevsky) Date: Mon, 12 Feb 2007 16:38:13 +0100 Subject: [address-policy-wg] [ncc-announce] Transfer of ERX resources from RIPE NCC to AfriNIC Message-ID: <45D089E5.50601@ripe.net> [Apologies for duplicate e-mails] Dear colleagues, On Wednesday 14 February 2007, the RIPE NCC will transfer management of several Early Registration PI address blocks and Autonomous System Numbers to AfriNIC. A list of the resources being transferred is available at: http://www.ripe.net/projects/erx/transferred.html You can find more information about AfriNIC at: http://www.afrinic.net For more information on the ERX project, see: http://www.ripe.net/projects/erx/index.html Regards, Andrei Robachevsky, Chief Technical Officer RIPE NCC