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

help
by Rob Bentley 16 Jun '07

16 Jun '07

-----Original Message----- From: address-policy-wg-admin(a)ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of address-policy-wg-request(a)ripe.net Sent: 16 June 2007 11:00 To: address-policy-wg(a)ripe.net Subject: address-policy-wg digest, Vol 1 #637 - 4 msgs Send address-policy-wg mailing list submissions to address-policy-wg(a)ripe.net To subscribe or unsubscribe via the World Wide Web, visit http://www.ripe.net/mailman/listinfo/address-policy-wg or, via email, send a message with subject or body 'help' to address-policy-wg-request(a)ripe.net You can reach the person managing the list at address-policy-wg-admin(a)ripe.net When replying, please edit your Subject line so it is more specific than "Re: Contents of address-policy-wg digest..." Today's Topics: 1. Re: [ppml] Revising Centrally Assigned ULA draft (Thomas Narten) 2. Re: Revising Centrally Assigned ULA draft (JORDI PALET MARTINEZ) 3. Re: [ppml] Revising Centrally Assigned ULA draft (JORDI PALET MARTINEZ) 4. Re: [ppml] Revising Centrally Assigned ULA draft (Randy Bush) --__--__-- Message: 1 To: Jeroen Massar <jeroen(a)unfix.org> cc: jordi.palet(a)consulintel.es, ARIN People Posting Mailing List <ppml(a)arin.net>, ipv6(a)ietf.org, "address-policy-wg(a)ripe.net" <address-policy-wg(a)ripe.net> Date: Fri, 15 Jun 2007 10:19:15 -0400 From: Thomas Narten <narten(a)us.ibm.com> Subject: [address-policy-wg] Re: [ppml] Revising Centrally Assigned ULA draft Jeroen Massar <jeroen(a)unfix.org> writes: > JORDI PALET MARTINEZ wrote: > > Operators have said that they will not be able to use ULA, but they cou= > ld > > use ULA-C, for example for thinks like microallocations for internal > > infrastructure's. > I really wonder where you got that idea, as I know of no such operator > who would ever say that. If there are any, let them bring up their > argumentation, please don't come up with "somebody said that" it does > not work that way. Maybe the assertion came from those who supported ARIN Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure (http://www.arin.net/policy/proposals/2006_2.html), where using a /48 out of their aggregate did not solve the technical problem at hand. At that time, the question was raised whether ULA-P solved the problem adequately. The answer I heard was a very clear "no". And ULA-C (if had existed then) would have. Thomas --__--__-- Message: 2 Date: Fri, 15 Jun 2007 15:14:43 +0000 From: JORDI PALET MARTINEZ <jordi.palet(a)consulintel.es> To: <ipv6(a)ietf.org> CC: ARIN People Posting Mailing List <ppml(a)arin.net>, "address-policy-wg(a)ripe.net" <address-policy-wg(a)ripe.net> Reply-To: jordi.palet(a)consulintel.es Subject: [address-policy-wg] Re: Revising Centrally Assigned ULA draft If you doubt about folks stating anything, then you should read *before* minutes of meetings. I'm now off-line in a plane, so can't point you to a specific URL, but this has been said at least in one ARIN meeting. It has been clear across all this discussion in several exploders, that there are both opinions, people that want ULA-C and people that don't. What you need to be smart here is to realize that those than don't want ULA-C have no any objective reason to oppose to it, because implementing ULA-C has no negative impact in others. While opposing to it has negative impact to all: Folks will use global space (PA or PI) for doing the function of ULA-C an this is a waste, yes a small waste but a waste. It seems to me irresponsible and unbalanced to do or try things like changing the HD-ratio or the default assignment size to end-sites because it is a waste, and then oppose to those that want to have ULA-C, not impacting in others and avoiding one further small saving in global unicast space. I'm not trying to convince anyone about supporting ULA-C, because it seems an impossible mission at least for a few, but at least, don't object to it if having it doesn't force you in any further implications, which is the case. Regards, Jordi > De: Jeroen Massar <jeroen(a)unfix.org> > Organizaci=F3n: Unfix > Responder a: <ipv6-bounces(a)ietf.org> > Fecha: Thu, 14 Jun 2007 11:00:11 +0100 > Para: <jordi.palet(a)consulintel.es> > CC: ARIN People Posting Mailing List <ppml(a)arin.net>, <ipv6(a)ietf.org>, > "address-policy-wg(a)ripe.net" <address-policy-wg(a)ripe.net> > Asunto: Re: Revising Centrally Assigned ULA draft >=20 > [cc'ing RIPE address policy + ARIN PPML where the discussion on this > happened, I have not seen any 'operators' who have said the below, if > there are they are there and can thus raise their voices because they > will see this message; removed the silly spam scoring subject...] >=20 > JORDI PALET MARTINEZ wrote: >> Operators have said that they will not be able to use ULA, but they could >> use ULA-C, for example for thinks like microallocations for internal >> infrastructure's. >=20 > I really wonder where you got that idea, as I know of no such operator > who would ever say that. If there are any, let them bring up their > argumentation, please don't come up with "somebody said that" it does > not work that way. >=20 > Real network operators, especially involved in the RIPE or other RIR's, > have more than enough address space from their PA allocations that they > can easily receive and they very well know how to use a /48 from that > for internal infrastructure as everybody does this. The IPv6 PA policies > even describe that a /48 can be used per POP of the owner of the PA block. >=20 > Also in the ARIN region any organization can get a /48 PI block for > about $100/year, as such these organizations won't be needing this > address space either as they can easily take a /64 out of that for those > needs. Firewalling is the key here. >=20 >=20 >> I think the policy proposal that I sent to several regions includes text and >> links to other documents that can clarify this perspective. >>=20 >> For example in RIPE NCC: >> http://www.ripe.net/ripe/policies/proposals/2007-05.html >=20 > That is your proposal indeed. No "Operator" has stood behind this and > various people from various organizations have clearly asked you and the > RIPE NCC to *freeze* this proposal till at least the IETF has worked out. >=20 > Anybody needing a "globally unique" block can get either PA or PI space. > ULA-C as such is useless. >=20 > Greets, > Jeroen >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6(a)ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- ********************************************** 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. --__--__-- Message: 3 Date: Fri, 15 Jun 2007 16:03:25 +0000 From: JORDI PALET MARTINEZ <jordi.palet(a)consulintel.es> To: ARIN People Posting Mailing List <ppml(a)arin.net> CC: <ipv6(a)ietf.org>, <address-policy-wg(a)ripe.net> Reply-To: jordi.palet(a)consulintel.es Subject: [address-policy-wg] Re: [ppml] Revising Centrally Assigned ULA draft Hi Marla, In fact, when I started to work on this, it was because I realized about the possibility to use ULA-C as the space for the microallocations and talking with different folks they said that it will be possible with ULA-C, but not ULA. I also talked with people from the AC and they considered the point (I was told) to use ULA-C for the microallocations when ULA-C is available. So my view is that probably the microallocations policy should not expire, but instead, be modified to make usage of the ULA-C space instead of global unicast. Regards, Jordi > De: "Azinger, Marla" <marla.azinger(a)frontiercorp.com> > Responder a: <marla.azinger(a)frontiercorp.com> > Fecha: Thu, 14 Jun 2007 13:31:29 -0400 > Para: Jeroen Massar <jeroen(a)unfix.org>, <jordi.palet(a)consulintel.es> > CC: ARIN People Posting Mailing List <ppml(a)arin.net>, <ipv6(a)ietf.org>, > <address-policy-wg(a)ripe.net> > Conversaci=F3n: [ppml] Revising Centrally Assigned ULA draft > Asunto: RE: [ppml] Revising Centrally Assigned ULA draft >=20 > I think a point here that needs to be looked at is this: >=20 > If ULA-C is addressed by IETF and then in turn we end up with RIR's > responsible for handing out ULA-C blocks, then those existing policy's such as > ARIN's NRPM 6.10.2 Microallocations for Internal Infastructure should be > expired and no longer an active policy. >=20 > And there are different flavors to the debate of why ULA-C would be better > than such policy as ARIN's NRPM 6.10.2 Microallocations for Internal > Infastructure. Ie Standardization, conservation ect... >=20 > Cheers! > Marla Azinger > Frontier Communications >=20 >=20 > -----Original Message----- > From: ppml-bounces(a)arin.net [mailto:ppml-bounces@arin.net]On Behalf Of > Jeroen Massar > Sent: Thursday, June 14, 2007 3:00 AM > To: jordi.palet(a)consulintel.es > Cc: ARIN People Posting Mailing List; ipv6(a)ietf.org; > address-policy-wg(a)ripe.net > Subject: Re: [ppml] Revising Centrally Assigned ULA draft >=20 >=20 > [cc'ing RIPE address policy + ARIN PPML where the discussion on this > happened, I have not seen any 'operators' who have said the below, if > there are they are there and can thus raise their voices because they > will see this message; removed the silly spam scoring subject...] >=20 > JORDI PALET MARTINEZ wrote: >> Operators have said that they will not be able to use ULA, but they could >> use ULA-C, for example for thinks like microallocations for internal >> infrastructure's. >=20 > I really wonder where you got that idea, as I know of no such operator > who would ever say that. If there are any, let them bring up their > argumentation, please don't come up with "somebody said that" it does > not work that way. >=20 > Real network operators, especially involved in the RIPE or other RIR's, > have more than enough address space from their PA allocations that they > can easily receive and they very well know how to use a /48 from that > for internal infrastructure as everybody does this. The IPv6 PA policies > even describe that a /48 can be used per POP of the owner of the PA block. >=20 > Also in the ARIN region any organization can get a /48 PI block for > about $100/year, as such these organizations won't be needing this > address space either as they can easily take a /64 out of that for those > needs. Firewalling is the key here. >=20 >=20 >> I think the policy proposal that I sent to several regions includes text and >> links to other documents that can clarify this perspective. >>=20 >> For example in RIPE NCC: >> http://www.ripe.net/ripe/policies/proposals/2007-05.html >=20 > That is your proposal indeed. No "Operator" has stood behind this and > various people from various organizations have clearly asked you and the > RIPE NCC to *freeze* this proposal till at least the IETF has worked out. >=20 > Anybody needing a "globally unique" block can get either PA or PI space. > ULA-C as such is useless. >=20 > Greets, > Jeroen >=20 ********************************************** 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. --__--__-- Message: 4 Date: Fri, 15 Jun 2007 12:58:12 -1000 From: Randy Bush <randy(a)psg.com> To: Mark Smith <ipng(a)69706e6720323030352d30312d31340a.nosense.org> CC: ipv6(a)ietf.org, ARIN People Posting Mailing List <ppml(a)arin.net>, address-policy-wg(a)ripe.net Subject: [address-policy-wg] Re: [ppml] Revising Centrally Assigned ULA draft > If (non-globally routed) PI is the answer to the ULA-C question, is > there going to be enough (non-globally routed) PI so that I can get a > (non-globally routed) PI allocation for my home, at a small charge for > the guaranteed uniqueness e.g. US$10 per annum ? How about my Personal > Area Network that interconnects my mobile phone, portable music player > and pedometer in my shoes. Will there be enough (non-globally routed) > PI that everybody on the planet who might end up having that sort of > PAN can get a (non-globally routed) PI address allocation, should they > want one ? How about if they want separate allocations for both their > PAN and their home network. these are rir policy and price issues. they are not technical issues. except for routability, which, as smb says, don't think you ain't gonna want to connect it some day; you will. randy End of address-policy-wg Digest

1 0

RE: [ppml] Revising Centrally Assigned ULA draft
by Azinger, Marla 15 Jun '07

15 Jun '07

I think a point here that needs to be looked at is this: If ULA-C is addressed by IETF and then in turn we end up with RIR's responsible for handing out ULA-C blocks, then those existing policy's such as ARIN's NRPM 6.10.2 Microallocations for Internal Infastructure should be expired and no longer an active policy. And there are different flavors to the debate of why ULA-C would be better than such policy as ARIN's NRPM 6.10.2 Microallocations for Internal Infastructure. Ie Standardization, conservation ect... Cheers! Marla Azinger Frontier Communications -----Original Message----- From: ppml-bounces(a)arin.net [mailto:ppml-bounces@arin.net]On Behalf Of Jeroen Massar Sent: Thursday, June 14, 2007 3:00 AM To: jordi.palet(a)consulintel.es Cc: ARIN People Posting Mailing List; ipv6(a)ietf.org; address-policy-wg(a)ripe.net Subject: Re: [ppml] Revising Centrally Assigned ULA draft [cc'ing RIPE address policy + ARIN PPML where the discussion on this happened, I have not seen any 'operators' who have said the below, if there are they are there and can thus raise their voices because they will see this message; removed the silly spam scoring subject...] JORDI PALET MARTINEZ wrote: > Operators have said that they will not be able to use ULA, but they could > use ULA-C, for example for thinks like microallocations for internal > infrastructure's. I really wonder where you got that idea, as I know of no such operator who would ever say that. If there are any, let them bring up their argumentation, please don't come up with "somebody said that" it does not work that way. Real network operators, especially involved in the RIPE or other RIR's, have more than enough address space from their PA allocations that they can easily receive and they very well know how to use a /48 from that for internal infrastructure as everybody does this. The IPv6 PA policies even describe that a /48 can be used per POP of the owner of the PA block. Also in the ARIN region any organization can get a /48 PI block for about $100/year, as such these organizations won't be needing this address space either as they can easily take a /64 out of that for those needs. Firewalling is the key here. > I think the policy proposal that I sent to several regions includes text and > links to other documents that can clarify this perspective. > > For example in RIPE NCC: > http://www.ripe.net/ripe/policies/proposals/2007-05.html That is your proposal indeed. No "Operator" has stood behind this and various people from various organizations have clearly asked you and the RIPE NCC to *freeze* this proposal till at least the IETF has worked out. Anybody needing a "globally unique" block can get either PA or PI space. ULA-C as such is useless. Greets, Jeroen

2 1

Re: PI for Not-DNS Anycast.
by Mattias Ahnberg 14 Jun '07

14 Jun '07

> DALnet announces the same prefix in several places in an identical > fashion as the one I described. So no, it's not anycast as it's not > globally reachable. Other than 194.68.45.0/24 that can't be reached from anywhere we also have another netblock (194.14.236.0/24) that CAN be reached from everywhere i.e. more "true anycast". The obvious problem we face is ofcourse when a server dies and a user ends up on another one and the first comes back again they will be disconnected from the latter and forced onto the first. We're not very bothered by this compared to the advantages it gives us. For others it may be too bad of a setup, ofcourse. -- /ahnberg.

1 0

RE: [address-policy-wg] 2007-05 Discussion Period extended until 9 July 2007 (IPv6 ULA-Central)
by jwkckid1＠ix.netcom.com 11 Jun '07

11 Jun '07

Michael and all, Why not? There are efforts in IPv8 and in china, IPv9. -----Original Message----- >From: michael.dillon(a)bt.com >Sent: Jun 11, 2007 4:47 AM >To: address-policy-wg(a)ripe.net >Subject: RE: [address-policy-wg] 2007-05 Discussion Period extended until 9 July 2007 (IPv6 ULA-Central) > >> PDP Number: 2007-05 >> IPv6 ULA-Central >> >> Dear Colleagues >> >> The Discussion Period for the proposal described in 2007-05 >> has been extended until 9 July 2007. > >It disturbs me to see that RIPE is seriously engaged in discussing the >implementation of an addressing proposal that the IETF has already >rejected. Anyone who supports this proposal AT THIS TIME, is also >attacking the current structure of the Regional Internet Registry system >and its relationship to IANA, the IETF and ICANN. > >This is not the time or the place to be discussing central ULA >addresses. If the IETF has rejected the idea in the past, then it is up >to people to fix their design and take it back to the IETF forums. >Regional Internet Registries should not create policy for numbering >resources which have not been created by the IETF or delegated to the >RIRs by IANA. > >--Michael Dillon > Regards, Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1(a)ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827

1 0

2007-05 Discussion Period extended until 9 July 2007 (IPv6 ULA-Central)
by Filiz Yilmaz 11 Jun '07

11 Jun '07

PDP Number: 2007-05 IPv6 ULA-Central Dear Colleagues The Discussion Period for the proposal described in 2007-05 has been extended until 9 July 2007. This policy is intended to allow the assignment of IPv6 blocks within the so-called 'Centrally Assigned Unique Local IPv6 Unicast Addresses' to organisations or individuals requiring it. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2007-05.html We encourage you to review this policy proposal and send your comments to <address-policy-wg(a)ripe.net>. Regards Filiz Yilmaz RIPE NCC Policy Development Officer

6 7

RE: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot)
by Tony Hain 08 Jun '07

08 Jun '07

I agree that this will help inform the debate, and while Iljitsch did a good job of outlining the issue, he left out a significant point::: People explicitly chose to be in the state of "as there is currently no obvious way to make services only available locally" by insisting that the local-scope addressing range have a global-scope as far as application developers were concerned. Now the application developers are complaining about the consequences of their choice, because the alternative to 'no routing path for an attack' is to insert a device that has to make policy decisions with limited information. The current ULA-central discussions will be directly involved in this issue. It is critical that all of the RIR's have policies establishing a mechanism for registering ULA-central prefixes & PI. For those who don't recall, the reason ULA-central was tabled was that it was seen as a potential end-run to acquire PI space in the absence of appropriate policy to do so out of a range recognized for global routing. The need for keeping some things local while others are global is real, and the lack of appropriate mechanisms to accomplish that through the routing system that is designed to deal with path selection leads to entire industries for fragile work-arounds along with their increased complexity. Tony > -----Original Message----- > From: ppml-bounces(a)arin.net [mailto:ppml-bounces@arin.net] On Behalf Of > vixie(a)vix.com > Sent: Thursday, May 10, 2007 9:59 PM > To: ppml(a)arin.net > Subject: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica > (seen on slashdot) > > i think that this article will help inform the debate around the ipv6 > transition: > > http://arstechnica.com/articles/paedia/ipv6-firewall-mixed-blessing.ars > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML(a)arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml

39 155

2006-01 Discussion Period extended until 19 June 2007 (Provider Independent (PI) IPv6 Assignments for End User Organisations)
by Filiz Yilmaz 07 Jun '07

07 Jun '07

PDP Number: 2006-01 Provider Independent (PI) IPv6 Assignments for End User Organisations Dear Colleagues The text of the policy proposal 2006-01 has changed. We have published the new version today, as a result the discussion period for this proposal has been extended until 19 June 2007. This proposal is intended to provide a solution for organisations that need IPv6 Provider Independent (PI) assignments. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2006-01.html We encourage you to review this policy proposal and send your comments to <address-poliy-wg(a)ripe.net>. Regards Filiz Yilmaz RIPE NCC Policy Development Officer

17 28

New RIPE Document available: RIPE-411
by RIPE NCC Document Announcement Service 07 Jun '07

07 Jun '07

A new RIPE Document is available from the RIPE Document store. Ref: ripe-411 Title: IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region Author: RIPE NCC Date: June 2007 Format: PDF=82,541 Obsoletes: ripe-405 This document describes the RIPE community¢s current IPv4 address allocation and assignment policies. They were developed through a bottom-up, consensus driven, open policy development process in the RIPE Address Policy Working Group (AP WG). The RIPE Network Coordination Centre (RIPE NCC) facilitates and supports this process. These policies apply to the RIPE NCC and the Local Internet Registries (LIRs) within the RIPE NCC service region. You can find this document at: http://www.ripe.net/docs/ripe-411.html Regards RIPE NCC Webmaster

1 0

2005-08 Last Call for Comments (Proposal to Amend the IPv6 Assignment and Utilisation Requirement Policy)
by Filiz Yilmaz 05 Jun '07

05 Jun '07

PDP Number: 2005-08 Proposal to Amend the IPv6 Assignment and Utilisation Requirement Policy Dear Colleagues The proposal described in 2005-08 is now at its Concluding Phase. This proposal is to amend the RIPE IPv6 address allocation policies regarding the definition of the default size of End Site allocations, the threshold value for End Site allocation efficiency, and the method of calculation of the End Site allocation efficiency metric. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2005-08.html As you may remember, two draft documents for this proposal were published during its Review Phase. Now that both drafts have been moved to Last Call, we have published a combined draft document for your convenience. You can find this combined document at: http://www.ripe.net/ripe/draft-documents/2005-08.html The two separate draft documents for this proposal can still be found at: Defining allocation efficiency measurement unit as /56: http://www.ripe.net/ripe/draft-documents/2005-08-56s.html Changing the HD ratio value to 0.94: http://www.ripe.net/ripe/draft-documents/2005-08-hd-ratio.html Please e-mail any final comments about this proposal to address-policy-wg(a)ripe.net before 3 July 2007. Regards Filiz Yilmaz RIPE NCC Policy Development Officer

1 0

ULA discussion
by Sander Steffann 31 May '07

31 May '07

Hello all, The ULA discussion has been going on for some time now, and I'd like to summarize it a bit. The differences between ULA address space and PI (or PA) address space: - ULA space should be easier/cheaper to get than PI space - PI space is meant for routing outside your organization and associated networks - ULA space is meant for inside your organization and associated networks Usefulness of ULA space: - I see some people/organizations who would realy like it - I see some people/organizations who don't like it As people who don't ULA don't have to use it (and filter fc00::/7), I would like to see other (preferably objective/technical) reasons why ULA space is a bad idea. Why should we deny ULA space to those who want it and think it is useful to them? Usefulness of ULA-Central space: - Some people think that the possibility of a conflict between two ULA-Local prefixes is so small that it does not really matter - Other people think even that very small chance does matter, and they would like a ULA-Central registry If the people/organizations who want an ULA-Central registry also pay for it, are there any other problems with providing such a registry? The question remains about who should operate and maintain that registry. Because RIPE NCC has a lot of experience with maintaining an IP address registry, they are a likely candidate for this. What arguments are there for and against letting RIPE NCC maintain this registry? What are possible alternatives? I hope I summarized everything correctly, and that I covered all remaining questions. If I missed anything, please let me know. If you have any input about any of the remaining questions, let's discuss it! Thank you, Sander Steffann

5 4