June 2007 - address-policy-wg

PI for Not-DNS Anycast.
by Andy Davidson 11 Aug '07

11 Aug '07

Hi, Can I get the community's thoughts on this, please .. I think we have a well defined policy on what to do when someone needs some PI in order to run an Anycasted DNS service. We set out a family of requirements based on geographic diversity, for instance, that clearly states what should be in place when a request for PI for DNS use is made. What if a company wants to try to deploy an anycasted production service for something which is not DNS ? It could be a proprietary protocol, or something standard like http. Is the community view that they should just deaggregate some of their PA - which I don't like the sound of - or apply for PI in the normal way, and pretend anycast isn't necessarily involved ? Many thanks Andy

13 25

2006-02 Last Call for Comments (IPv6 Address Allocation and Assignment Policy)
by Filiz Yilmaz 04 Jul '07

04 Jul '07

PDP Number: 2006-02 IPv6 Address Allocation and Assignment Policy Dear Colleagues The proposal described in 2006-02 is now at its Concluding Phase. 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://www.ripe.net/ripe/policies/proposals/2006-02.html Please e-mail any final comments about this proposal to address-policy-wg(a)ripe.net before 2 July 2007. Regards Filiz Yilmaz RIPE NCC Policy Development Officer

11 23

How to get a IPv6 /32 the cheap way: go to AFRINIC
by Jeroen Massar 01 Jul '07

01 Jul '07

[*full rant mode*] My eye just fell on a very strange new allocation, apparently made under some new rules in the AFRINIC region which seem to be very wasteful and very out of sync with the rest of the world who are at least thinking a bit about address conservation instead of just blowing address space like there is no tomorrow: http://www.afrinic.net/docs/policies/afpol-v6200407-000.htm#5 details: 8<-------------- 5.1.1. Initial allocation criteria To qualify for an initial allocation of IPv6 address space, an organization must: a) be an LIR; b) not be an end site; c) show a detailed plan to provide IPv6 connectivity to organizations in the AfriNIC region. d) show a reasonable plan for making /48 IPv6 assignments to end sites in the AfriNIC region within twelve months. The LIR should also plan to announce the allocation as a single aggregated block in the inter-domain routing system within twelve months. 5.1.2. Initial allocation size Organizations that meet the initial allocation criteria are eligible to receive a minimum allocation of /32. ---------------------------------------------->8 Wow, so you make a new 'company' in 911 land and say "I am going to allocate a single /48" and you get a FULL /32 even when you will never ever ever use it or even are going to think about using it? The first "organization" which is using this to waste space seems to be: inet6num: 2001:42d0::/32 netname: AfriNIC-IPv6-1 descr: AfriNIC descr: RIR country: MU Gee, the RIR itself. How many people are using the AFRINIC network? 10-50? Are they really *ever* going to need more than a /48? Are they ever going to have a need for 65536 of those /48's? Really this is just a waste of address space. Yes there is "enough", but being sooo obviously wasteful just to be able to have a nice slot in the routing tables is a bit over done. I hope that the other regions take this in mind too when (re)considering their address policies. Giving out /48's or even a /40 to an organization that is in-effect an end-site I can understand, especially when they can justify the need for that amount of address space. But giving /32's to every single endsite that simply asks for it is very very very far fetched. They will not even ever fill up a /40 of address space even if they would have two sites (read: offices) in every country in Africa, let alone 65536 sites. Such a waste. Funnily later in the above document they point to HD ratios. What point is that when the waste is already happened? RIR's should be giving out address space based on "need" and that need must justified, giving out /32's as "those fit in the routing slots" is a really really bad idea. In short: if you want a nice /32 without issues: setup a small shop in Africa and presto! Greets, Jeroen

16 27

ICANN Board Resolution on the Deployment of IPv6
by JORDI PALET MARTINEZ 30 Jun '07

30 Jun '07

I think this resolution that has been taken unanimously by the board today here in San Juan deservers this email at least: http://www.ipv6tf.org/index.php?page=news/newsroom&id=3052 Regards, Jordi ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

1 0

2007-01 Awaiting Documentation
by Filiz Yilmaz 28 Jun '07

28 Jun '07

Dear Colleagues, As you may remember, during the Address Policy Working Group session at RIPE 54, the community asked us to prepare a draft contract between End Users and the RIPE NCC in order to facilitate discussion about proposal 2007-01, "Direct Internet Resource Assignments to End Users from the RIPE NCC". The RIPE NCC Executive Board will meet at the beginning of September to discuss this draft End User contract. Only after this meeting can a draft contract be published. Until then, the proposer, Nick Hilliard, and the Address Policy Working Group Chairs decided to keep the current status of proposal 2007-01 as "Discussion Phase - Awaiting for Documentation." Kind regards, Filiz Yilmaz RIPE NCC Policy Development Officer

1 0

The Choice: IPv4 Exhaustion or Transition to IPv6
by JORDI PALET MARTINEZ 27 Jun '07

27 Jun '07

Hi all, I've published a document trying to analyze the IPv4 exhaustion problem and what is ahead of us, considering among others, changes in policies. http://www.ipv6tf.org/index.php?page=news/newsroom&id=3004 I guess this could be useful in order to understand possible implications of modifying existing policies, or setting up new ones, or even just to create some debate about those changes. The document was completed last April, but didn't had the time to tidy up until a few days ago. Regards, Jordi ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

1 0

Re: [address-policy-wg] 2006-02 Last Call for Comments (IPv6 Address Allocation and Assignment Policy)
by Aleksi Suhonen 27 Jun '07

27 Jun '07

Hello, > And which prefix size does the organization get then? There are enough > end-site organizations that can easily justify a /42 worth of address > space, 64 /48's isn't that much if you give every separate building > where you have an office a /48 and those offices can definitely be > considered sites. Easy is great, but there should be a possibility for > sites to request a bit more. Hmm ... /48 shouldn't be the lower bound for organization internal site subnetting. It should be /64. If every separate building needs several subnets and room to expand, then they should be given 256 /64s (aka /56). Or if it can be shown that some building really needs more, then perhaps a bigger block can be justified. It would still be hard to convince me that an organization would need sixtyfivethousand subnets in every building. Now, if the organization has more than 256 buildings, THEN it might be reasonable to give the organization a bigger block than /48. (Of course, there might be organizations that have very special needs that have nothing to do with office buildings, and I'm not commenting on those at all here.) I may be wrong, -- Aleksi Suhonen / Axu TM Oy Internetworking Consulting Cellular: +358 45 670 2048 World Wide Web: www.axu.tm

3 3

Re : [ppml] on PPML? - was Re: How to get ...
by Iwu Mbatelege 22 Jun '07

22 Jun '07

Please stop this non sense debate here: Have you also come across the following address waist? I haven't seen you guys making any noise about them! 014/8 Jun 91 IANA - Public Data Network ---- (a whole /8 for an organisation of less than 20 people?) inet6num: 2001:07F8::/29 inet6num: 2001:07FD::/32 netname: K-rootserver-net-20030829 descr: This assignment given to k-root.server.net descr: maintained by the RIPE NCC --- (just for the Kroot server Infratsructure ????? is this an LIR) inet6num2001:0DC0::/32 netnameAPNIC-AP-V6-20030124 descrAPNIC Pty Ltd - Brisbane Offices + Servers descrLevel 1, 33 Park Rd descrPO Box 2131, Milton descrBrisbane, QLD. countryAU --- (just for APNIC??? an LIR?) So is your problem with AfriNIC or you are going to request IANA , RIPE NCC, APNIC too to send you their justifications? note that most of the v6 assignments/allocations above were made in 2003 where none of these RIR had IPv6 PI policy in place. IM. ----- Message d'origine ---- De : Jeroen Massar <jeroen(a)unfix.org> À : Edward Lewis <Ed.Lewis(a)neustar.biz> Cc : ARIN Address Policy <ppml(a)arin.net> Envoyé le : Vendredi, 22 Juin 2007, 20h23mn 08s Objet : Re: [ppml] on PPML? - was Re: How to get ... Edward Lewis wrote: > At 16:44 +0100 6/22/07, Jeroen Massar wrote: > >> Global address consumption affects everybody globally. As such, if >> AfriNIC >> decides to waste address space, that affects all RIR's globally. As >> such it >> also affects ARIN, as such it affects you. > > I guess I was too subtle in making my point. Which point? Sorry, but not everybody is into prose, some people are engineers and simply want straight words. > If you are criticizing the activities of Afrinic, take it up discreetly > with Afrinic. The "Court of Public Opinion" is not a place for a fair > "fight." It is a problem with AfriNIC that has an effect globally. It is not a fight, it is public questioning. If you want to ignore it, then ignore it. > I don't like the precedent of accusing an RIR of a misdoing and asking > them to publicly defend themselves. The RIR's operate in a delicate > balance of both openness in policy development and resource registration > and confidentiality in handling and judging the worthiness of requests. That openness is not there when a RIR makes up their own rules without asking their membership. Or did I miss the superinternal memo that is not supposed to be public in the first place? > Working in a environment of openness, confidentiality, and neutrality is > difficult. You cannot defend yourself to the fullest because of the > limits of what can be, what can not be, and what might otherwise be > implied. > > Plus this is the ARIN mailing list. Stop thinking in your little American box. Or is the war in Iraq something that does not happen in the US and thus not relevant? To pull something in that also shows that local decisions have global effects. >> Then please try to explain me why I saw this recently: >> 2001:42c8::/32 Canada TGB-V6-AFRICA > > I believe that question is wholly inappropriate for this list. > Especially for this list. (In the pulic meetings, our chair doesn't > tolerate personal "accusations" either, something I was heartened to > witness in April.) If you try to say "Shut up" to me then either: - simply say on this list - simply say so by sending a private message And I am very sure that ARIN staff and other people are also very able to provide me with a similar message when needed very quickly. Please bring arguments along, they tend to help. I brought that up as a note to show you *WHY* it was appropriate to bring these matters up on the PPML mailinglist as policies and decisions happening in other regions *DO* affect ARIN. Let me repeat again, that I have NOTHING against that 2001:42c8::/32 assignment which is really a good thing and very well justified. It only demonstrates that Address Policy is a global thing, not something local. Organizations are global and the Internet is global. Policies and laws etc are not but they do affect us globally. And in case you don't like me mailing, then simply block all mail from jeroen(a)unfix.org, which is always nicely PGP signed, thus should be very easy to block in your MUA or even MTA. Greets, Jeroen _______________________________________________ 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 _____________________________________________________________________________ Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail

4 3

2007-04 New Draft Document Published (IANA Policy for Allocation of ASN Blocks to RIRs)
by Filiz Yilmaz 21 Jun '07

21 Jun '07

PDP Number: 2007-04 IANA Policy for Allocation of ASN Blocks to RIRs Dear Colleagues We have published a draft document for the proposal described in 2007-04. This proposal is to have a global policy for the Regional Internet Registries (RIRs) to receive blocks of Autonomous System Numbers (ASNs) from the Internet Assigned Numbers Authority (IANA). You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2007-04.html and the draft document at: http://www.ripe.net/ripe/draft-documents/2007-04-draft.html We encourage you to read the draft document text and send any comments to address-policy-wg(a)ripe.net before 12 July 2007. Regards Filiz Yilmaz RIPE NCC Policy Development Officer

4 4

Impact Analysis
by Filiz Yilmaz 20 Jun '07

20 Jun '07

Dear Colleagues, During the Address Policy Working Group session at the RIPE 53 Meeting in 2006, the community supported the idea of having an impact analysis conducted by the RIPE NCC for each policy that has been proposed. The community wanted to know the expected impact that a policy may have if it is eventually accepted. The RIPE NCC will therefore conduct an impact analysis for every policy proposal that moves to the Review Phase of the RIPE Policy Development Process (PDP) from now on. The impact analysis provides projections in the two areas most discussed by the community: A. Impact of the policy on the registry and addressing system - Information will be provided about the possible impact of the proposal on address/Internet number resource consumption and fragmentation/aggregation. B. Impact of the policy on RIPE NCC operations/services The first impact analysis has been created for the proposal 2007-04, IANA Policy for Allocation of ASN Blocks to RIRs. You can view this analysis under 'Additional Information' in this proposal at: http://www.ripe.net/ripe/policies/proposals/2007-04.html Kind regards Filiz Yilmaz RIPE NCC Policy Development Officer

2 1

ULA-C draft version 2 available (I-D ACTION:draft-ietf-ipv6-ula-central-02.txt)
by Jeroen Massar 18 Jun '07

18 Jun '07

Reply-To set to ipv6(a)ietf.org, use it as there is where the discussion should be. This mail is mostly so that folks can't claim that they "didn't know". IETF is, just like the RIR communities open and individual participation. Thus if you have something on your mind, write down the arguments and send them in. Note on the IETF lists: subscription is helpful, otherwise you might not get the responses (unless you read the public archive). List Admins will, as soon as possible approve mails that get into the queue though, but with todays amount of spam coming in that might not be immediate. The document is at: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-ula-central-02.txt Subscription information + archive etc for ipv6(a)ietf.org can be found at: https://www1.ietf.org/mailman/listinfo/ipv6 Greets, Jeroen -------- Original Message -------- A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Centrally Assigned Unique Local IPv6 Unicast Addresses Author(s) : R. Hinden, B. Haberman Filename : draft-ietf-ipv6-ula-central-02.txt Pages : 11 Date : 2007-6-18 This document defines Centrally allocated IPv6 Unique Local addresses. These addresses are globally unique and are intended for local communications, usually inside of a site. They are not expected to be routable on the global Internet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-ula-central-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request(a)ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-ula-central-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv(a)ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-ula-central-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft.

1 0

Re: Revising Centrally Assigned ULA draft
by Jeroen Massar 18 Jun '07

18 Jun '07

[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

10 10

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

18 Jun '07

Jordi- We are saying the same thing. Just how you get there is different. It is true, we could either modify or eliminate the current ARIN policy to work in unison with what might be a finsished RFC on ULA-C. I just believe that sometimes it is easier to start with a fresh policy. In this case, I think it would be less confusing to expire the current policy and replace it with a new one that is more fitting as opposed to trying to modify the current one. A modification could quickly confuse anyone who has not been following all of the ULA emails and conversations. I suppose we can figure this out when we get to that bridge. Cheers! Marla Azinger Frontier Communications ARIN AC -----Original Message----- From: ppml-bounces(a)arin.net [mailto:ppml-bounces@arin.net]On Behalf Of JORDI PALET MARTINEZ Sent: Friday, June 15, 2007 9:03 AM To: ARIN People Posting Mailing List Cc: ipv6(a)ietf.org; address-policy-wg(a)ripe.net Subject: 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ón: [ppml] Revising Centrally Assigned ULA draft > Asunto: RE: [ppml] Revising Centrally Assigned ULA draft > > 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 > ********************************************** 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. _______________________________________________ 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

4 3

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