RE: [ppml] Revising Centrally Assigned ULA draft
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@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@ietf.org; address-policy-wg@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@frontiercorp.com> Responder a: <marla.azinger@frontiercorp.com> Fecha: Thu, 14 Jun 2007 13:31:29 -0400 Para: Jeroen Massar <jeroen@unfix.org>, <jordi.palet@consulintel.es> CC: ARIN People Posting Mailing List <ppml@arin.net>, <ipv6@ietf.org>, <address-policy-wg@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@arin.net [mailto:ppml-bounces@arin.net]On Behalf Of Jeroen Massar Sent: Thursday, June 14, 2007 3:00 AM To: jordi.palet@consulintel.es Cc: ARIN People Posting Mailing List; ipv6@ietf.org; address-policy-wg@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@arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml
Hi Marla, Agree, but actually I was wondering, if the AC/board has the power so just modify the policy in order to use ULA-C space, assuming that when the ULA-C becomes available, it offers the same features required by this policy. It may be much easier and faster instead of going thru the PDP all the way. Or even the staff, because this becomes then only an implementation issue (kind of "we usedd prefix xx until now, but ULA-C is available and we can use that space w/o implications on the existing policy itself, same as if we exhaust the initial prefix for this policy and need to start using a new one"). Anyway is something that could be debated when ULA-C is available :-) Regards, Jordi
De: "Azinger, Marla" <marla.azinger@frontiercorp.com> Responder a: <marla.azinger@frontiercorp.com> Fecha: Fri, 15 Jun 2007 15:14:31 -0400 Para: <jordi.palet@consulintel.es>, ARIN People Posting Mailing List <ppml@arin.net> CC: <ipv6@ietf.org>, <address-policy-wg@ripe.net> Conversación: [ppml] Revising Centrally Assigned ULA draft Asunto: RE: [ppml] Revising Centrally Assigned ULA draft
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@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@ietf.org; address-policy-wg@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@frontiercorp.com> Responder a: <marla.azinger@frontiercorp.com> Fecha: Thu, 14 Jun 2007 13:31:29 -0400 Para: Jeroen Massar <jeroen@unfix.org>, <jordi.palet@consulintel.es> CC: ARIN People Posting Mailing List <ppml@arin.net>, <ipv6@ietf.org>, <address-policy-wg@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@arin.net [mailto:ppml-bounces@arin.net]On Behalf Of Jeroen Massar Sent: Thursday, June 14, 2007 3:00 AM To: jordi.palet@consulintel.es Cc: ARIN People Posting Mailing List; ipv6@ietf.org; address-policy-wg@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@arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml
********************************************** 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.
On Sat, 16 Jun 2007, JORDI PALET MARTINEZ wrote:
Anyway is something that could be debated when ULA-C is available :-)
if ULA-C is available... why are you so sure it will go through and be accepted? not many have supported it so far. Some of those in favour have changed view, me included. -- ------------------------------ Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID roger@jorgensen.no | - IPv6 is The Key! -------------------------------------------------------
Thus spake "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
Agree, but actually I was wondering, if the AC/board has the power so just modify the policy in order to use ULA-C space, assuming that when the ULA-C becomes available, it offers the same features required by this policy. It may be much easier and faster instead of going thru the PDP all the way.
This sounds suspiciously like "I don't seem to have the support of the community, so I wonder if the Board/AC can ignore the process and do what I want anyways." I don't know whether or not they can do that; it doesn't seem possible, but there's probably a loophole or two. However, given the vocal opposition to the proposal (and the very existence of ULA-C), I doubt you'd ever convince them to if they could. It's one thing to sneak through something that nobody cares about either way, but it's entirely different to deliberately exclude the community on something so divisive.
Anyway is something that could be debated when ULA-C is available :-)
If you seriously propose doing the above, I suspect you'll manage to alienate even the folks who agree with ULA-C. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov
participants (4)
-
Azinger, Marla -
JORDI PALET MARTINEZ -
Roger Jorgensen -
Stephen Sprunk