RE: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot)
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@arin.net [mailto:ppml-bounces@arin.net] On Behalf Of vixie@vix.com Sent: Thursday, May 10, 2007 9:59 PM To: ppml@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@arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml
I don't understand your point about why ULA need to be registered if its not going to be globally routed. Also PI is not the same as ULA - PI do come from RIRs and in IPv6 there was no way to get PI (except in a few special cases) until recent ARIN's micro-allocation policy. On Fri, 11 May 2007, Tony Hain wrote:
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@arin.net [mailto:ppml-bounces@arin.net] On Behalf Of vixie@vix.com Sent: Thursday, May 10, 2007 9:59 PM To: ppml@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@arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml
_______________________________________________ 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
ULA Central is intended so that some subset of the internet can reliably use it to interconnect while not being "globally" routed. The problem I have with this theory is that the delta between a collection of networks routing by mutual agreement and the internet is: A. Fuzzy B. Non-Existant C. There is no difference D. Meaningless E. Any and/or All of the above Pick your favorite answer from the above and you've pretty much got it. If ULA central were limited to not exiting the local AS (in some meaningful way, like routers won't forward routes or traffic to ULA addresses to external adjacencies), then, I might see it as something other than an end-run on the RIR process. However, in it's current state of "license for anyone who wants to run a competing RIR for networks that choose to interoperate on this basis" I think it's a pretty bad idea. Owen On May 11, 2007, at 12:03 AM, william(at)elan.net wrote:
I don't understand your point about why ULA need to be registered if its not going to be globally routed. Also PI is not the same as ULA - PI do come from RIRs and in IPv6 there was no way to get PI (except in a few special cases) until recent ARIN's micro-allocation policy.
On Fri, 11 May 2007, Tony Hain wrote:
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@arin.net [mailto:ppml-bounces@arin.net] On Behalf Of vixie@vix.com Sent: Thursday, May 10, 2007 9:59 PM To: ppml@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@arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml
_______________________________________________ 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
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 problem I have with this theory is that the delta between a collection of networks routing by mutual agreement and the internet is:
A. Fuzzy B. Non-Existant C. There is no difference D. Meaningless E. Any and/or All of the above
Pick your favorite answer from the above and you've pretty much got it.
Perhaps it is time for the RIRs to develop clear definitions for the Internet and IP internetworks so that the delta between them is clear.
However, in it's current state of "license for anyone who wants to run a competing RIR for networks that choose to interoperate on this basis" I think it's a pretty bad idea.
The RIR process is the way that the organizations sharing IP number resources reach agreement on who gets what. These organizations have to work together outside of the RIRs to reach agreement on who connects to what and who routes what. If a group of organizations outside the RIR can reach agreement on global internetwork connectivity between them, but separate from the Internet, and if the IP number resource pool is big enough to let these organizations manage their own addressing requirements on that internetwork, then why should the RIRs be upset. Among the many IP networks operated by my company there is a global IPv4 internetwork that is completely separate from the Internet. It has thousands of companies connected to it and, naturally, it uses registered IPv4 addresses. It's not the only such global network. We run one for the financial services industry. There is also such a network for the auto-manufacturing industry, and for the airline industry. And there are probably others as well. --Michael Dillon
If we want to avoid other entities acting as a central registry for ULA-central, then it is clear that the RIRs should do that, and for that, the only way is thru a policy. Regards, Jordi
De: Owen DeLong <owen@delong.com> Responder a: <address-policy-wg-admin@ripe.net> Fecha: Thu, 10 May 2007 23:12:21 -0700 Para: "william(at)elan.net" <william@elan.net> CC: Tony Hain <alh-ietf@tndh.net>, <vixie@vix.com>, <ppml@arin.net>, "address-policy-wg@ripe.net" <address-policy-wg@ripe.net> Asunto: [address-policy-wg] Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot)
ULA Central is intended so that some subset of the internet can reliably use it to interconnect while not being "globally" routed.
The problem I have with this theory is that the delta between a collection of networks routing by mutual agreement and the internet is:
A. Fuzzy B. Non-Existant C. There is no difference D. Meaningless E. Any and/or All of the above
Pick your favorite answer from the above and you've pretty much got it. If ULA central were limited to not exiting the local AS (in some meaningful way, like routers won't forward routes or traffic to ULA addresses to external adjacencies), then, I might see it as something other than an end-run on the RIR process. However, in it's current state of "license for anyone who wants to run a competing RIR for networks that choose to interoperate on this basis" I think it's a pretty bad idea.
Owen
On May 11, 2007, at 12:03 AM, william(at)elan.net wrote:
I don't understand your point about why ULA need to be registered if its not going to be globally routed. Also PI is not the same as ULA - PI do come from RIRs and in IPv6 there was no way to get PI (except in a few special cases) until recent ARIN's micro-allocation policy.
On Fri, 11 May 2007, Tony Hain wrote:
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@arin.net [mailto:ppml-bounces@arin.net] On Behalf Of vixie@vix.com Sent: Thursday, May 10, 2007 9:59 PM To: ppml@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@arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml
_______________________________________________ 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
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.
It is time to be blunt. The BS about being an end-run on PI is a tacit acknowledgement that people demand the utility of PI and will do whatever it takes to work around attempts to thwart them. The only reason ULA & PI are related is that there is no global acknowledgement that PI is necessary and will exist despite short-sighted attempts to squelch it. Also, just because someone else has a different deployment model off to the side that you don't see doesn't make it wrong. Enterprise networks need to keep private interconnect routing sorted out from their public side routing, and while complex IGP entries and ACLs will do the job, a simpler approach is to use the routing system for the job it was designed to do and use a local prefix for the non-global interconnect. PI does not solve the locality problem, so ULA is needed as well. For those organizations that don't want to consider even the remotest possibility that there will be an address collision with a future merger/acquisition/partner (having been burned on 1918), ULA-central makes more sense than ULA-local. Every PI block should automatically come with a ULA-central block. One could even argue that every RIR member should automatically receive a ULA-central block. Use is up to them. It has no ongoing cost so it would be cheaper to just set one up while doing the requested service than to have to come back and add it later. There is no shortage here. The RIR membership should really get past their preferred religion and start thinking long term revenue here. ULA-central doesn't cost anything substantial, yet provides a reason to justify RIR membership for those who don't consider ULA-local to be unique enough and would not otherwise become a member. Tony
-----Original Message----- From: Owen DeLong [mailto:owen@delong.com] Sent: Friday, May 11, 2007 9:12 AM To: william(at)elan.net Cc: Tony Hain; vixie@vix.com; ppml@arin.net; address-policy-wg@ripe.net Subject: Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot)
ULA Central is intended so that some subset of the internet can reliably use it to interconnect while not being "globally" routed.
The problem I have with this theory is that the delta between a collection of networks routing by mutual agreement and the internet is:
A. Fuzzy B. Non-Existant C. There is no difference D. Meaningless E. Any and/or All of the above
Pick your favorite answer from the above and you've pretty much got it. If ULA central were limited to not exiting the local AS (in some meaningful way, like routers won't forward routes or traffic to ULA addresses to external adjacencies), then, I might see it as something other than an end-run on the RIR process. However, in it's current state of "license for anyone who wants to run a competing RIR for networks that choose to interoperate on this basis" I think it's a pretty bad idea.
Owen
On May 11, 2007, at 12:03 AM, william(at)elan.net wrote:
I don't understand your point about why ULA need to be registered if its not going to be globally routed. Also PI is not the same as ULA - PI do come from RIRs and in IPv6 there was no way to get PI (except in a few special cases) until recent ARIN's micro-allocation policy.
On Fri, 11 May 2007, Tony Hain wrote:
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@arin.net [mailto:ppml-bounces@arin.net] On Behalf Of vixie@vix.com Sent: Thursday, May 10, 2007 9:59 PM To: ppml@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@arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml
_______________________________________________ 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
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
Owen, I just want to be clear about somehting you said. You view ULA central as "an end-run on the RIR process." Is this because the expired ULC-central draft suggests that some new "central allocation authority" be established to assign these addresses? If the draft RFC was resurrected and all references to "cental allocation authority" and "cental authority" were removed and replaced with clear text explaining the following: - IANA should divide FC00::/8 into eight /11s - Each RIR would be given one /11 to make ULA-Central assignments - Three /11s would be held in reserve for new RIRs in the future. Would you still think this was an end-run on the RIR process? Would you be in support of the draft moving forward? Do you think this should not be decided by an RFC, but rather as a global policy through each of the RIRs? If you prefer the RIR process, would you be in favor of a global policy submitted to ARIN that had the provisions of the expired ULA-central draft, with the modification of removing "cental authority" and clearly designating how IANA should divide the space among the existing RIRs? ULA-central text snippets below. ___Jason draft-ietf-ipv6-ula-central-01.txt -- section 3.2.1 "Global IDs should be assigned under the authority of a single allocation organization because they are pseudo-random and without any structure. This is easiest to accomplish if there is a single authority for the assignments." draft-ietf-ipv6-ula-central-01.txt -- section 7.0 "The IANA is instructed to designate an allocation authority, based on instructions from the IAB, for centrally assigned Unique Local IPv6 unicast addresses. This allocation authority shall comply with the requirements described in Section 3.2 of this document, including in particular allocation on a permanent basis and with sufficient provisions to avoid hoarding of numbers. If deemed appropriate, the authority may also consist of multiple organizations performing the allocation authority duties. The designated allocation authority is required to document how they will meet the requirements described in Section 3.2 of this document in an RFC. This RFC will be shepherd through the IETF by the IAB." ========================================================================== Jason Schiller (703)886.6648 Senior Internet Network Engineer fax:(703)886.0512 Public IP Global Network Engineering schiller@uu.net UUNET / Verizon jason.schiller@verizonbusiness.com The good news about having an email address that is twice as long is that it increases traffic on the Internet. On Thu, 10 May 2007, Owen DeLong wrote:
Date: Thu, 10 May 2007 23:12:21 -0700 From: Owen DeLong <owen@delong.com> To: "william(at)elan.net" <william@elan.net> Cc: vixie@vix.com, ppml@arin.net, address-policy-wg@ripe.net Subject: Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot)
ULA Central is intended so that some subset of the internet can reliably use it to interconnect while not being "globally" routed.
The problem I have with this theory is that the delta between a collection of networks routing by mutual agreement and the internet is:
A. Fuzzy B. Non-Existant C. There is no difference D. Meaningless E. Any and/or All of the above
Pick your favorite answer from the above and you've pretty much got it. If ULA central were limited to not exiting the local AS (in some meaningful way, like routers won't forward routes or traffic to ULA addresses to external adjacencies), then, I might see it as something other than an end-run on the RIR process. However, in it's current state of "license for anyone who wants to run a competing RIR for networks that choose to interoperate on this basis" I think it's a pretty bad idea.
Owen
On May 11, 2007, at 12:03 AM, william(at)elan.net wrote:
I don't understand your point about why ULA need to be registered if its not going to be globally routed. Also PI is not the same as ULA - PI do come from RIRs and in IPv6 there was no way to get PI (except in a few special cases) until recent ARIN's micro-allocation policy.
On Fri, 11 May 2007, Tony Hain wrote:
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@arin.net [mailto:ppml-bounces@arin.net] On Behalf Of vixie@vix.com Sent: Thursday, May 10, 2007 9:59 PM To: ppml@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@arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml
_______________________________________________ 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
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
If the draft RFC was resurrected
Would you still think this was an end-run on the RIR process?
Would you be in support of the draft moving forward?
If you prefer the RIR process, would you be in favor of a global
Seems to me that if the draft is not resurrected, there are no ULA addresses for ARIN or RIPE to register, regardless of anything that ARIN or RIPE members might desire. policy
submitted to ARIN that had the provisions of the expired ULA-central draft, with the modification of removing "cental authority" and clearly designating how IANA should divide the space among the existing RIRs?
Seems to me that the NRO requires that identical policies be PASSED by all of the RIRs before they can be considered "global policy". This is an area where it makes a whole lot of sense to have discussions on several RIR mailing lists before ANY policy proposal is submitted to ANY of the 5 RIRs. I'm not going to quibble with the wording of the draft at this point. I just wonder whether it is appropriate for the RIR mailing lists to be used as a working group for writing Internet drafts? It seems to be a stupid way to proceed because there are at least 5 different mailing lists involved, one of which is primarily in Spanish. Crossposting is not a solution. If people are serious about this central ULA concept then they should get ONE of the RIRs to set up a working group (RIPE would be my first choice, ARIN second) and then have all of this discussion in that working group mailing list. People from all of the 5 RIRs should be invited to the working group by official RIR postings to whatever lists are appropriate. Some RIRs have announcement lists for such things or members-only lists to ensure that the word gets out. Then draft the document in your ONE SINGLE mailing list discussion, submit it to the IETF, and only then, after an agreed draft is formally in the IETF pipeline, submit your global policy proposals to each of the RIRs. The way this is being done right now is pure madness and I would expect that the RIR boards will reject any policies that arise through this UNFAIR AND DISJOINTED process. We have always allowed the IETF to take first place when it comes to creating new number resources. There is no good reason to change this for so-called central-ULA addresses. We do need the technical expertise that is in the IETF to review this before we can make any kind of policy decisions about a registry for these addresses. I know many people on the RIR policy lists are technical experts, but that doesn't count, because these are policy lists, not technical ones. It is one thing for a few technical people to convince a large number of non-technical people about a topic. It is another thing entirely, for those few technical people to convince the large number of technical people who participate in the IETF. It seems to me that the promoters of central-ULA are trying to bypass the IETF's technical review process and I don't like this. --Michael Dillon
On May 11, 2007, at 6:35 AM, <michael.dillon@bt.com> wrote:
I'm not going to quibble with the wording of the draft at this point. I just wonder whether it is appropriate for the RIR mailing lists to be used as a working group for writing Internet drafts?
I don't see why not, but... In your email, you noted the disjoint nature of the RIRs and the need to cross-post or whatever. Speaking as chair of IPv6 Operations (v6ops@ops.ietf.org), I would invite you and all those interested in the effort to use the v6ops list for the purpose and the v6ops working group as a venue to do the work. If you would like, we can arrange a v6ops interim meeting at the RIR meeting of your choice, or it could be discussed in the currently-planned meeting in the third week of July in Chicago. One technical question I would ask. What does a "Central Authority" and "IANA Assignment" have to do with a "Local" address of any type? It seems in context that the major issue is an address prefix that is not advertised to neighboring ISPs and can be generally configured to be refused if offered by a neighboring ISP, in the same way that an RFC 1918 address is not advertised and is generally refused between IPv4 networks. In any draft on this topic, regardless of where it is discussed, if central assignment is in view, the reason for having such assignment should be clearly stated.
On 2007-05-11 16:14, Fred Baker wrote: ...
One technical question I would ask. What does a "Central Authority" and "IANA Assignment" have to do with a "Local" address of any type? It seems in context that the major issue is an address prefix that is not advertised to neighboring ISPs and can be generally configured to be refused if offered by a neighboring ISP, in the same way that an RFC 1918 address is not advertised and is generally refused between IPv4 networks. In any draft on this topic, regardless of where it is discussed, if central assignment is in view, the reason for having such assignment should be clearly stated.
Fred, the point is that ULAs should be unambiguous, so that if they happen to meet (e.g. via a VPN, or following a merge of two previously separate networks) there is no collision. Currently ULAs include a pseudo-random prefix, which leaves open a theoretical possibility of collision. Centrally-allocated ULAs would not have this issue. Brian
Thus spake "Brian E Carpenter" <brc@zurich.ibm.com>
Fred, the point is that ULAs should be unambiguous, so that if they happen to meet (e.g. via a VPN, or following a merge of two previously separate networks) there is no collision. Currently ULAs include a pseudo-random prefix, which leaves open a theoretical possibility of collision. Centrally-allocated ULAs would not have this issue.
The chance is negligible until you have a number of organizations interconnecting that approaches the AS count on the public Internet. Those who are uncomfortable with those odds can get PIv6 space. ULA Central does not solve any problems that the existing tools already solve, and it creates new problems of its own. 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
Thus spake "Stephen Sprunk" <stephen@sprunk.org>
ULA Central does not solve any problems that the existing tools already solve, and it creates new problems of its own.
That should be "don't already solve". 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
I've already indicated this in previous occasions, but may be not in ppml ... We are proceeding in parallel, with the ID and the PDP at the same time. Nothing in the PDP precludes doing so. The RIRs don't depend on IETF at all, they can define global policies for things that the IETF failed to complete if that's the case. IANA can be instructed the same by the RIRs (which a global policy) than by the IETF itself with an RFC. Even when the IETF get the document as an RFC, the RIRs need a policy (in this case no need for a global one) to start using the resource. That's why both things are needed. The boards of the RIRs, if the policy reach consensus, should hold the implementation until the RFC is available or instead, a global policy reach consensus to replace the function of the RFC. This is something that it is natural to be done, but again, doesn't preclude to start debating about the policy and win some time. If anyone want to discuss about the ULA-central ID, I encourage to bring that discussion to the ipv6 WG mailing list, no need to create a new one. For discussions about the policy proposal, use the corresponding RIR mail exploder. Regards, Jordi
De: <michael.dillon@bt.com> Responder a: <ietf-bounces@ietf.org> Fecha: Fri, 11 May 2007 14:35:25 +0100 Para: <ppml@arin.net>, <address-policy-wg@ripe.net>, <ietf@ietf.org> Conversación: Can the RIRs bypass the IETF and do their own thing? Asunto: Can the RIRs bypass the IETF and do their own thing?
If the draft RFC was resurrected
Would you still think this was an end-run on the RIR process?
Would you be in support of the draft moving forward?
Seems to me that if the draft is not resurrected, there are no ULA addresses for ARIN or RIPE to register, regardless of anything that ARIN or RIPE members might desire.
If you prefer the RIR process, would you be in favor of a global policy submitted to ARIN that had the provisions of the expired ULA-central draft, with the modification of removing "cental authority" and clearly designating how IANA should divide the space among the existing RIRs?
Seems to me that the NRO requires that identical policies be PASSED by all of the RIRs before they can be considered "global policy". This is an area where it makes a whole lot of sense to have discussions on several RIR mailing lists before ANY policy proposal is submitted to ANY of the 5 RIRs.
I'm not going to quibble with the wording of the draft at this point. I just wonder whether it is appropriate for the RIR mailing lists to be used as a working group for writing Internet drafts? It seems to be a stupid way to proceed because there are at least 5 different mailing lists involved, one of which is primarily in Spanish. Crossposting is not a solution.
If people are serious about this central ULA concept then they should get ONE of the RIRs to set up a working group (RIPE would be my first choice, ARIN second) and then have all of this discussion in that working group mailing list. People from all of the 5 RIRs should be invited to the working group by official RIR postings to whatever lists are appropriate. Some RIRs have announcement lists for such things or members-only lists to ensure that the word gets out. Then draft the document in your ONE SINGLE mailing list discussion, submit it to the IETF, and only then, after an agreed draft is formally in the IETF pipeline, submit your global policy proposals to each of the RIRs.
The way this is being done right now is pure madness and I would expect that the RIR boards will reject any policies that arise through this UNFAIR AND DISJOINTED process. We have always allowed the IETF to take first place when it comes to creating new number resources. There is no good reason to change this for so-called central-ULA addresses. We do need the technical expertise that is in the IETF to review this before we can make any kind of policy decisions about a registry for these addresses.
I know many people on the RIR policy lists are technical experts, but that doesn't count, because these are policy lists, not technical ones. It is one thing for a few technical people to convince a large number of non-technical people about a topic. It is another thing entirely, for those few technical people to convince the large number of technical people who participate in the IETF. It seems to me that the promoters of central-ULA are trying to bypass the IETF's technical review process and I don't like this.
--Michael Dillon
_______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
********************************************** 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.
If anyone want to discuss about the ULA-central ID, I encourage to bring that discussion to the ipv6 WG mailing list, no need to create a new one. For discussions about the policy proposal, use the corresponding RIR mail exploder.
I don't know if Fred Baker's message on the IETF list made it to the RIR lists, but he offers a single central discussion place for the central ULA concept. -----quoted from IETF list--------- In your email, you noted the disjoint nature of the RIRs and the need to cross-post or whatever. Speaking as chair of IPv6 Operations (v6ops@ops.ietf.org), I would invite you and all those interested in the effort to use the v6ops list for the purpose and the v6ops working group as a venue to do the work. If you would like, we can arrange a v6ops interim meeting at the RIR meeting of your choice, or it could be discussed in the currently-planned meeting in the third week of July in Chicago. --------------- So, now there is no longer any need to complain that the IETF is too slow or that the RIRs need to work in parallel. Anyone can join the v6ops list (instructions here http://www.ietf.org/html.charters/v6ops-charter.html ) and anyone can propose how central ULAs could be made to work. And for those who wish to meet face-to-face, there is an opportunity in Chicago in July. Hopefully, the v6ops list will look at other alternatives such as using AS numbers to define a block of addresses similar to the way GLOP defined multicast addressing in RFC 3180 http://www.ietf.org/rfc/rfc3180.txt --Michael Dillon
That may be true for IPv6 operational issues, however, following the IETF procedures, for discussing about ULA-central, which is an IPv6 WG item, it should be done at the ipv6@ietf.org mail exploder. Regards, Jordi
De: <michael.dillon@bt.com> Responder a: <ppml-bounces@arin.net> Fecha: Mon, 14 May 2007 09:46:56 +0100 Para: <ppml@arin.net>, <address-policy-wg@ripe.net> Conversación: [ppml] Can the RIRs bypass the IETF and do their own thing? Asunto: Re: [ppml] Can the RIRs bypass the IETF and do their own thing?
If anyone want to discuss about the ULA-central ID, I encourage to bring that discussion to the ipv6 WG mailing list, no need to create a new one. For discussions about the policy proposal, use the corresponding RIR mail exploder.
I don't know if Fred Baker's message on the IETF list made it to the RIR lists, but he offers a single central discussion place for the central ULA concept.
-----quoted from IETF list--------- In your email, you noted the disjoint nature of the RIRs and the need to cross-post or whatever. Speaking as chair of IPv6 Operations (v6ops@ops.ietf.org), I would invite you and all those interested in the effort to use the v6ops list for the purpose and the v6ops working group as a venue to do the work. If you would like, we can arrange a v6ops interim meeting at the RIR meeting of your choice, or it could be discussed in the currently-planned meeting in the third week of July in Chicago. ---------------
So, now there is no longer any need to complain that the IETF is too slow or that the RIRs need to work in parallel. Anyone can join the v6ops list (instructions here http://www.ietf.org/html.charters/v6ops-charter.html ) and anyone can propose how central ULAs could be made to work. And for those who wish to meet face-to-face, there is an opportunity in Chicago in July.
Hopefully, the v6ops list will look at other alternatives such as using AS numbers to define a block of addresses similar to the way GLOP defined multicast addressing in RFC 3180 http://www.ietf.org/rfc/rfc3180.txt
--Michael Dillon
_______________________________________________ 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.
Just on a technical side-note... michael.dillon@bt.com wrote: [...]
Hopefully, the v6ops list will look at other alternatives such as using AS numbers to define a block of addresses
Are there enough bits to earmark for that, in a regime of 32bit AS numbers?
similar to the way GLOP defined multicast addressing in RFC 3180 http://www.ietf.org/rfc/rfc3180.txt
--Michael Dillon
Wilfried.
On 2007-05-11 23:32, JORDI PALET MARTINEZ wrote:
I've already indicated this in previous occasions, but may be not in ppml ...
We are proceeding in parallel, with the ID and the PDP at the same time. Nothing in the PDP precludes doing so.
The RIRs don't depend on IETF at all, they can define global policies for things that the IETF failed to complete if that's the case. IANA can be instructed the same by the RIRs (which a global policy) than by the IETF itself with an RFC.
Not quite. The RIRs have authority delegated to them by IANA, and IANA operates under the terms of its MoU and SLA with the IETF. So the RIRs' scope is to set and implement policy within their delegated authority, which itself has to be within the terms of the IANA MoU and SLA. In this case, I would check out section 4.3 of RFC 2860, especially the clause (b) in the second paragraph. It's clear to me that centrally- allocated ULAs are in IETF scope under that clause. That being said, there's no conceivable problem with a draft being developed by any set of people that want to do so, and the RIR people are obviously strongly motivated to do so in this case. (Personally, I see little need for it, since the existing pseudo-random ULAs are good enough for any practical purpose, but that is a discussion we can have in the IETF once there is a draft to discuss.) Brian
Brian, On Mon, May 14, 2007 at 01:34:31PM +0200, Brian E Carpenter wrote:
On 2007-05-11 23:32, JORDI PALET MARTINEZ wrote:
The RIRs don't depend on IETF at all, they can define global policies for things that the IETF failed to complete if that's the case. IANA can be instructed the same by the RIRs (which a global policy) than by the IETF itself with an RFC.
Not quite. The RIRs have authority delegated to them by IANA, and IANA operates under the terms of its MoU and SLA with the IETF. So the RIRs' scope is to set and implement policy within their delegated authority, which itself has to be within the terms of the IANA MoU and SLA.
The RIRs authority comes from their communities, not from IANA. That's what "bottom-up" means. Many industries need a neutral organisation to do business. Airlines have a system to handle reservations. Many industries use the ISO to set standards (paint colour, carpet thickness, and so on). Universities have accreditation bodies to insure a certain quality of education. And so on. The ISPs of the world need someone to handle resource allocation. The RIRs do that. They also do a bunch of other stuff. Really, the RIRs' scope is whatever their communities think it should be. If the RIRs decide to allocate numbers from dead:beef::/32 based on lunar tides, then the IETF and IANA and ICANN can complain about it all day long, but it's not their decision to make. Of course they can participate in the policy making process like everyone else. :) -- Shane
On 2007-05-14 16:08, Shane Kerr wrote:
Brian,
On Mon, May 14, 2007 at 01:34:31PM +0200, Brian E Carpenter wrote:
The RIRs don't depend on IETF at all, they can define global policies for things that the IETF failed to complete if that's the case. IANA can be instructed the same by the RIRs (which a global policy) than by the IETF itself with an RFC. Not quite. The RIRs have authority delegated to them by IANA, and IANA operates under the terms of its MoU and SLA with the IETF. So
On 2007-05-11 23:32, JORDI PALET MARTINEZ wrote: the RIRs' scope is to set and implement policy within their delegated authority, which itself has to be within the terms of the IANA MoU and SLA.
The RIRs authority comes from their communities, not from IANA. That's what "bottom-up" means.
We're both right. It works because there is a wide consensus to both listen to the community and respect the mechanisms in place. Brian
Hi, On Mon, May 14, 2007 at 04:08:19PM +0200, Shane Kerr wrote:
If the RIRs decide to allocate numbers from dead:beef::/32 based on lunar tides, then the IETF and IANA and ICANN can complain about it all day long, but it's not their decision to make. Of course they can participate in the policy making process like everyone else. :)
Well, technically you are correct - but given the way "The Internet" works, it works better if there is agreement on where the numbers come from, and how they are distributed in a way that makes them unique. So the RIRs *do* try to cooperate with ICANN/IANA and the IETF :-) And please let's *not* use the RIPE APWG mailinglist for a fundamental debate on whether the RIR model is all broken, the IETF is too slow to be useful, or whatever gripes you have - we need to focus the discussions somewhat, otherwise too many people will just stop working with us. [If you really feel that the RIPE model is all broken, by all means say so -- but please open a new mail thread for it, instead of shanghaiing a specific policy proposal discussion] Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 113403 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
I fully agree with Gert! I'm looking forward to a draft to discuss on its technical merits. Brian On 2007-05-14 23:31, Gert Doering wrote:
Hi,
On Mon, May 14, 2007 at 04:08:19PM +0200, Shane Kerr wrote:
If the RIRs decide to allocate numbers from dead:beef::/32 based on lunar tides, then the IETF and IANA and ICANN can complain about it all day long, but it's not their decision to make. Of course they can participate in the policy making process like everyone else. :)
Well, technically you are correct - but given the way "The Internet" works, it works better if there is agreement on where the numbers come from, and how they are distributed in a way that makes them unique.
So the RIRs *do* try to cooperate with ICANN/IANA and the IETF :-)
And please let's *not* use the RIPE APWG mailinglist for a fundamental debate on whether the RIR model is all broken, the IETF is too slow to be useful, or whatever gripes you have - we need to focus the discussions somewhat, otherwise too many people will just stop working with us.
[If you really feel that the RIPE model is all broken, by all means say so -- but please open a new mail thread for it, instead of shanghaiing a specific policy proposal discussion]
Gert Doering -- APWG chair
Not quite. The RIRs have authority delegated to them by IANA, and IANA operates under the terms of its MoU and SLA with the IETF. So the RIRs' scope is to set and implement policy within their delegated authority, which itself has to be within the terms of the IANA MoU and SLA.
I looked into this some time ago, and found that the U.S. Department of Commerce delegated authority to ICANN, and that ICANN delegated to the RIRs. According to IANA, IANA is just the bookkeeper, and is run by ICANN under contract with the U.S. Government: According documents at http://www.icann.org/general/agreements.htm ICANN contracted with the U.S. Government to handle the IANA function. According to one MoU, the IETF "appointed" ICANN to perform IANA functions, however, there seems to be no authority for IETF to make such a delegation. This MoU is just a notice that the IETF concurs with the award of the U.S. Goverment contract. Using the word "appointed" doesn't mean the IETF has any actual authority to make appointments or to appoint someone else. I note that the IANA physical address is the same as ICANN: Internet Assigned Numbers Authority 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292 USA +1-310-823-9358 (phone) +1-310-823-8649 (facsimile) The agreements that I've found with ICANN, e.g. http://www.icann.org/general/ietf-iana-agreement-v8.htm place the IETF as a technical collaborator to assist ICANN with the IANA function. The IETF provides technical experts to the ICANN/IANA. The IETF is just a technical consultant on IANA functions. Administative authority over RIRs resides in ICANN, and above ICANN, the U.S. Government. ICANN can end the MoU at any time, and find a new technical consultant. The IETF can also end the MoU at any time. But the IETF doesn't have the authority to appoint a new IANA operator.
In this case, I would check out section 4.3 of RFC 2860, especially the clause (b) in the second paragraph. It's clear to me that centrally- allocated ULAs are in IETF scope under that clause.
Nothing in these MoUs supercede the U.S. Government contracts and agreements that delegate the actual final authority. Also, RFC2860 is superceded by the January 2007 MoU that I cited above. The authority goes top down: US Government ICANN RIRs The RIR's can do whatever ICANN and the US Government allow them to do. The IETF _can_ be taken out of the picture if there is cause to do so. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000
Hi, On Mon, May 14, 2007 at 03:04:19PM -0400, Dean Anderson wrote: [..]
ICANN can end the MoU at any time, and find a new technical consultant. The IETF can also end the MoU at any time. But the IETF doesn't have the authority to appoint a new IANA operator. [..] The RIR's can do whatever ICANN and the US Government allow them to do. The IETF _can_ be taken out of the picture if there is cause to do so.
Not quite. If ICANN decides "we won't listen to IETF anymore", or "we try to inforce non-useful politics to the RIRs" there is no big reason why the RIRs couldn't just kick ICANN, install the NRO in its place, and change the structure to IETF -> NRO -> RIRs Remember: the existing mechanism works, because the communities (!!) agree that it's a useful way to handle address distribution. The US DoC might have some say for ARIN, but the rest of the world couldn't care less - and I'm sure that the DoC is well aware of this and won't try to break apart working structures. So this is all sort of academic. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 113403 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 US DoC has as much say for ARIN as it does for the RIPE NCC. The RIRs existed before ICANN. The relationship between the RIRs and ICANN is defined in the ASO MoU, an agreement between ICANN on the one hand and the NRO on behalf of the RIRs on the other. There is no mention in the ICANN bylaws of the RIRs. Ray
-----Original Message----- From: Gert Doering [mailto:gert@space.net] Sent: Tuesday, May 15, 2007 4:40 AM To: Dean Anderson Cc: ppml@arin.net; address-policy-wg@ripe.net; jordi.palet@consulintel.es; ietf@ietf.org Subject: Re: [address-policy-wg] Re: Can the RIRs bypass the IETF and do their own thing?
Hi,
ICANN can end the MoU at any time, and find a new technical consultant. The IETF can also end the MoU at any time. But the IETF doesn't have
On Mon, May 14, 2007 at 03:04:19PM -0400, Dean Anderson wrote: [..] the
authority to appoint a new IANA operator. [..] The RIR's can do whatever ICANN and the US Government allow them to do. The IETF _can_ be taken out of the picture if there is cause to do so.
Not quite. If ICANN decides "we won't listen to IETF anymore", or "we try to inforce non-useful politics to the RIRs" there is no big reason why the RIRs couldn't just kick ICANN, install the NRO in its place, and change the structure to
IETF -> NRO -> RIRs
Remember: the existing mechanism works, because the communities (!!) agree that it's a useful way to handle address distribution.
The US DoC might have some say for ARIN, but the rest of the world couldn't care less - and I'm sure that the DoC is well aware of this and won't try to break apart working structures.
So this is all sort of academic.
Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 113403
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
_______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
On Tue, 15 May 2007, Ray Plzak wrote:
The US DoC has as much say for ARIN as it does for the RIPE NCC.
The US DoC, through IANA functions, says, e.g., what IP Address blocks each can allocate. That seems to qualify as 'much say' You seem to be confusing delegation of authority with loss of authority. The DoC has contracted the IANA function to ICANN and doesn't involve itself much, and ultimately plans to get out altogether. However, the IANA operator (ICANN) then has 'much say'. But the DoC 'get out altogether' event hasn't happened yet. So you can't write out the DoC just yet.
The RIRs existed before ICANN. The relationship between the RIRs and ICANN is defined in the ASO MoU, an agreement between ICANN on the one hand and the NRO on behalf of the RIRs on the other. There is no mention in the ICANN bylaws of the RIRs.
The fallacy of this claim was already stated: RIRs get their authority and IP Address Allocations, etc from IANA. The fact that RIRs existed before ICANN is irrelevant, because IANA existed before the RIRs. And, as I noted, IANA functions are now contracted to ICANN. Technically, it is in fact the IANA (not ICANN) that has direct control over RIRs. But, as I pointed out, ICANN has full control over IANA functions by contract with the US Government. And, as I pointed out, the IETF is a technical consultant to ICANN. The MoUs are just that: Memoranda of Understanding. MoUs can be terminated, and don't supercede the contracts with the US Government. So, it is possible for ICANN/IANA to disregard the technical advice of its technical consultant and so it is possible for ICANN/IANA to allow the RIRs to do something which the IETF doesn't approve. There is nothing the IETF can do about it. The IETF can't fire ICANN as IANA operator, but ICANN could fire the IETF as its technical consultant. Of course, the IETF can also quit as the technical consultant. The IETF has no exclusive monopoly on technical experts. The practical effect of a break with the IETF is to get rid of only the people in the IESG and IAB. Roughly ~25 experts are easily replaced. BTW, it is not the case that I think any of this _will_ happen, but it clarifies the relationships to know what is possible under the current contracts. I expect that people will reach reasonable accomodations with all the stakeholders involved. Of course, sometimes that doesn't happen. But, probably people are more reasonable when they realize the consequences of unreasonable intransigence. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000
The US DoC has as much say for ARIN as it does for the RIPE NCC.
The US DoC, through IANA functions, says, e.g., what IP Address blocks each can allocate. That seems to qualify as 'much say'
Didn't say how much say, just said that whatever say it had for ARIN it was the same as it had for the RIPE NCC.
You seem to be confusing delegation of authority with loss of authority. The DoC has contracted the IANA function to ICANN and doesn't involve itself much, and ultimately plans to get out altogether. However, the IANA operator (ICANN) then has 'much say'. But the DoC 'get out altogether' event hasn't happened yet. So you can't write out the DoC just yet.
Don't how you arrived at that conclusion based on a casual observation. Not writing them out, don't know how you got that.
The RIRs existed before ICANN. The relationship between the RIRs and ICANN is defined in the ASO MoU, an agreement between ICANN on the one hand and the NRO on behalf of the RIRs on the other. There is no mention in the ICANN bylaws of the RIRs.
The fallacy of this claim was already stated:
What is false about those statements? RIRs get their authority
and IP Address Allocations, etc from IANA. The fact that RIRs existed before ICANN is irrelevant, because IANA existed before the RIRs. And, as I noted, IANA functions are now contracted to ICANN. Technically, it is in fact the IANA (not ICANN) that has direct control over RIRs. But, as I pointed out, ICANN has full control over IANA functions by contract with the US Government. And, as I pointed out, the IETF is a technical consultant to ICANN. The MoUs are just that: Memoranda of Understanding. MoUs can be terminated, and don't supercede the contracts with the US Government.
Never intimated anything about authority lines or derivation of authority, just pointing out some of the factors in the relationship between ICANN and the RIRs. Ray
On Tue, 15 May 2007, Ray Plzak wrote:
The US DoC has as much say for ARIN as it does for the RIPE NCC.
The US DoC, through IANA functions, says, e.g., what IP Address blocks each can allocate. That seems to qualify as 'much say'
Didn't say how much say, just said that whatever say it had for ARIN it was the same as it had for the RIPE NCC.
Ok. Then we are agreed that "say" is equal. I think perhaps I misunderstood your message; so long as you aren't disputing that IANA and the DoC has influence over RIRs, we are in agreement. I think we are also in agreement that the RIRs and ICANN/IANA can bypass the IETF by agreeing to do so. The IETF doesn't have any authority to stop IANA from making decisions which contradict the IETF advice to IANA. The IETF doesn't appoint IANA.
The RIRs existed before ICANN. The relationship between the RIRs and ICANN is defined in the ASO MoU, an agreement between ICANN on the one hand and the NRO on behalf of the RIRs on the other. There is no mention in the ICANN bylaws of the RIRs.
The fallacy of this claim was already stated:
What is false about those statements?
A fallacy is the false implication of statements supporting a conclusion. One doesn't need false statements to have a fallacy---only a conclusion not supported by the statements. I thought you were asserting that there isn't any control by DoC over RIRs, and that those statements were your justification. That would be a fallacy, but it seems in retrospect you weren't disputing control of DoC over RIRs, so I guess I just misunderstood you. My apologies. However, a nit while I'm at it: The MoU is just a written understanding, and can be terminated at any time by either party. The ICANN bylaws do not need to mention the RIRs for ICANN to contract the IANA function. The absence of RIRs in ICANN bylaws is irrelevant.
RIRs get their authority and IP Address Allocations, etc from IANA. The fact that RIRs existed before ICANN is irrelevant, because IANA existed before the RIRs. And, as I noted, IANA functions are now contracted to ICANN. Technically, it is in fact the IANA (not ICANN) that has direct control over RIRs. But, as I pointed out, ICANN has full control over IANA functions by contract with the US Government. And, as I pointed out, the IETF is a technical consultant to ICANN. The MoUs are just that: Memoranda of Understanding. MoUs can be terminated, and don't supercede the contracts with the US Government.
Never intimated anything about authority lines or derivation of authority, just pointing out some of the factors in the relationship between ICANN and the RIRs.
Sorry, this subject sounds to me like CORE, the MoUvement & January 1998 all over again. I may be overreacting to past history. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000
Hi, last word from my side on this (and then please take it off the APWG list, as it is getting increasingly off-topic - feel free to discuss this with me in private, though): On Tue, May 15, 2007 at 12:46:22PM -0400, Dean Anderson wrote:
The RIRs existed before ICANN. The relationship between the RIRs and ICANN is defined in the ASO MoU, an agreement between ICANN on the one hand and the NRO on behalf of the RIRs on the other. There is no mention in the ICANN bylaws of the RIRs.
The fallacy of this claim was already stated: RIRs get their authority and IP Address Allocations, etc from IANA.
RIRs get their authority from their respective communities. IANA is a tool to ease unique distribution of addresses. If the RIRs communities stop accepting their RIR's authority, there is nothing the DoC, ICANN, or the RIRs can do about it (how can the DoC tell me what addresses to use on my local part of the network?) - and that process works on all nodes in the tree. We already had the situation where ICANN didn't get their act together, and the RIRs seriously considered installing the NRO in its place. So please come down from your US-centric "the DoC rules the world" view - ICANN/IANA is there because they get the job done, and the RIR communities appreciate that. Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 113403 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 US DoC has as much say for ARIN as it does for the RIPE NCC.
The US DoC, through IANA functions, says, e.g., what IP Address blocks each can allocate. That seems to qualify as 'much say'
So it seems that you and Ray are in agreement. All the other details are not terribly relevant to RIR policy discussions because we have processes and structures to make sure that everything is done properly. We have no plans to change any of the structures because at the present time, they seem to work OK. As for the matter that started this, central ULAs, there is not need to worry about who controls what. The fact is that it is customary for new address types to be defined *FIRST* in the IETF and even if there is the possibility of an alternate process, we would not dream of exercising that unless the customary process, via the IETF, had broken down. The IETF process cannot be considered broken just because a draft has expired. In fact, expiry of a draft indicates that the original authors no longer care enough about the matter to progress it further. The WG chair of IPv6 Operations has already offered the v6ops list http://www.ietf.org/html.charters/v6ops-charter.html For those people who *DO* wish to progress a draft for Central ULA addresses. This is a sign that the IETF process is open for business in this case. At this point, I think it is inappropriate to continue the Central ULA discussion on the RIR policy lists. In fact, if any policy were to come out of such a discussion, I would vote against it even though my company could potentially benefit from something like a Central ULA address block. But at the same time, my company supports the IETF process in general and I don't believe we would want to be perceived as usurping the IETF. That is why I would vote against any policy proposal that is not based on an RFC. I urge all of you who have an interest in Central ULA addresses, both pro and con, to take your discussion to the v6ops list. And I urge the people in favour of Central ULA addresses to write an Internet draft explaining just what it is that you want to do. At this point in time, there is no valid draft document so I don't even know what it is that you are discussing. --Michael Dillon
Michael, [ stripping out a lot of content to just say what I want to say... ] On Wed, May 16, 2007 at 10:38:11AM +0100, michael.dillon@bt.com wrote:
At this point, I think it is inappropriate to continue the Central ULA discussion on the RIR policy lists.
Agreed.
In fact, if any policy were to come out of such a discussion, I would vote against it [...]
Me too (well, the RIPE region doesn't vote on policies, but rather say I would oppose Central ULA proposals). -- Shane
On May 11, 2007, at 6:05 AM, Jason Schiller wrote:
Owen,
I just want to be clear about somehting you said. You view ULA central as "an end-run on the RIR process." Is this because the expired ULC- central draft suggests that some new "central allocation authority" be established to assign these addresses?
If the draft RFC was resurrected and all references to "cental allocation authority" and "cental authority" were removed and replaced with clear text explaining the following:
- IANA should divide FC00::/8 into eight /11s - Each RIR would be given one /11 to make ULA-Central assignments - Three /11s would be held in reserve for new RIRs in the future.
Would you still think this was an end-run on the RIR process?
I would not think it was an end-run on RIRs at that point.
Would you be in support of the draft moving forward?
It would depend on what provisions were in the draft to prevent it from being an end-run on PI policies.
Do you think this should not be decided by an RFC, but rather as a global policy through each of the RIRs?
I am not sure. I kind of like Tony's (malformed) suggestion that ULA- C should come with PI. If the qualifications for ULA-C were the same, or, if ULA-C was only available to orgs. that had PI, I think that would be acceptable.
If you prefer the RIR process, would you be in favor of a global policy submitted to ARIN that had the provisions of the expired ULA-central draft, with the modification of removing "cental authority" and clearly designating how IANA should divide the space among the existing RIRs?
Not sure about that. I do support the idea of ULA-Central as intended, but, I'd have to see a policy or RFC that implemented it in such a way that I had reasonable confidence it wouldn't become "the easy way to get PI". If we're going to do that, I'd rather do it by relaxing the PI policy than by designating some "nudge nudge wink wink" address space. Owen
ULA-central text snippets below.
___Jason
draft-ietf-ipv6-ula-central-01.txt -- section 3.2.1 "Global IDs should be assigned under the authority of a single allocation organization because they are pseudo-random and without any structure. This is easiest to accomplish if there is a single authority for the assignments."
draft-ietf-ipv6-ula-central-01.txt -- section 7.0
"The IANA is instructed to designate an allocation authority, based on instructions from the IAB, for centrally assigned Unique Local IPv6 unicast addresses. This allocation authority shall comply with the requirements described in Section 3.2 of this document, including in particular allocation on a permanent basis and with sufficient provisions to avoid hoarding of numbers. If deemed appropriate, the authority may also consist of multiple organizations performing the allocation authority duties.
The designated allocation authority is required to document how they will meet the requirements described in Section 3.2 of this document in an RFC. This RFC will be shepherd through the IETF by the IAB."
====================================================================== ==== Jason Schiller (703) 886.6648 Senior Internet Network Engineer fax:(703) 886.0512 Public IP Global Network Engineering schiller@uu.net UUNET / Verizon jason.schiller@verizonbusiness.com
The good news about having an email address that is twice as long is that it increases traffic on the Internet.
On Thu, 10 May 2007, Owen DeLong wrote:
Date: Thu, 10 May 2007 23:12:21 -0700 From: Owen DeLong <owen@delong.com> To: "william(at)elan.net" <william@elan.net> Cc: vixie@vix.com, ppml@arin.net, address-policy-wg@ripe.net Subject: Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot)
ULA Central is intended so that some subset of the internet can reliably use it to interconnect while not being "globally" routed.
The problem I have with this theory is that the delta between a collection of networks routing by mutual agreement and the internet is:
A. Fuzzy B. Non-Existant C. There is no difference D. Meaningless E. Any and/or All of the above
Pick your favorite answer from the above and you've pretty much got it. If ULA central were limited to not exiting the local AS (in some meaningful way, like routers won't forward routes or traffic to ULA addresses to external adjacencies), then, I might see it as something other than an end- run on the RIR process. However, in it's current state of "license for anyone who wants to run a competing RIR for networks that choose to interoperate on this basis" I think it's a pretty bad idea.
Owen
On May 11, 2007, at 12:03 AM, william(at)elan.net wrote:
I don't understand your point about why ULA need to be registered if its not going to be globally routed. Also PI is not the same as ULA - PI do come from RIRs and in IPv6 there was no way to get PI (except in a few special cases) until recent ARIN's micro-allocation policy.
On Fri, 11 May 2007, Tony Hain wrote:
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@arin.net [mailto:ppml-bounces@arin.net] On Behalf Of vixie@vix.com Sent: Thursday, May 10, 2007 9:59 PM To: ppml@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@arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml
_______________________________________________ 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
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 On Fri, May 11, 2007 at 06:58:55AM -0700, Owen DeLong wrote:
Do you think this should not be decided by an RFC, but rather as a global policy through each of the RIRs?
I am not sure. I kind of like Tony's (malformed) suggestion that ULA- C should come with PI. If the qualifications for ULA-C were the same, or, if ULA-C was only available to orgs. that had PI, I think that would be acceptable.
I can't really understand the reasoning behind that. What are you trying to achieve, why do you want to restrict handing out ULA-C to only a specific (small) subset of folks out there? I'd take a much simpler approach - install a one-time setup fee, which will prevent folks from just grabbing 10000s of ULA-C prefixes, and then just hand them out to whoever wants some (and pays the handling fee). There's enough /48s in that /8 so that the risk of running out is really low - if there is some mechanism to limit the amount of prefixes a single entity can request. Money works well for that, usually. [..]
Not sure about that. I do support the idea of ULA-Central as intended, but, I'd have to see a policy or RFC that implemented it in such a way that I had reasonable confidence it wouldn't become "the easy way to get PI". If we're going to do that, I'd rather do it by relaxing the PI policy than by designating some "nudge nudge wink wink" address space.
ULA-C becomes PI the moment folks will accept it in their routing table (and if that is a serious risk, ULA-L could as easily become PI the same way). But why should routing folks do that? I, for one, hereby state that I will not route other folks ULA space on AS5539. Period. Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 113403 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
On May 14, 2007, at 2:36 PM, Gert Doering wrote:
Hi
On Fri, May 11, 2007 at 06:58:55AM -0700, Owen DeLong wrote:
Do you think this should not be decided by an RFC, but rather as a global policy through each of the RIRs?
I am not sure. I kind of like Tony's (malformed) suggestion that ULA- C should come with PI. If the qualifications for ULA-C were the same, or, if ULA-C was only available to orgs. that had PI, I think that would be acceptable.
I can't really understand the reasoning behind that. What are you trying to achieve, why do you want to restrict handing out ULA-C to only a specific (small) subset of folks out there?
I don't want to give ULA-C to people who have an incentive to abuse it as PI.
I'd take a much simpler approach - install a one-time setup fee, which will prevent folks from just grabbing 10000s of ULA-C prefixes, and then just hand them out to whoever wants some (and pays the handling fee).
I specifically don't want to achieve the suggested objective and would strongly oppose such an action.
There's enough /48s in that /8 so that the risk of running out is really low - if there is some mechanism to limit the amount of prefixes a single entity can request. Money works well for that, usually.
I don't care about running out. I care about less stringent standards in ULA criteria being used to create an end-run on PI policy.
[..]
Not sure about that. I do support the idea of ULA-Central as intended, but, I'd have to see a policy or RFC that implemented it in such a way that I had reasonable confidence it wouldn't become "the easy way to get PI". If we're going to do that, I'd rather do it by relaxing the PI policy than by designating some "nudge nudge wink wink" address space.
ULA-C becomes PI the moment folks will accept it in their routing table (and if that is a serious risk, ULA-L could as easily become PI the same way). But why should routing folks do that?
Hopefully routing folks won't, but, in my experience, $$$ can lead routing folks to ignore what should or shouldn't be done from an internet context and, instead, focus on what makes money. I agree that ULA-L is a bad idea for all the same reasons. However, there is nothing which can be done about ULA-L at the RIR policy level. At the RIR Policy level, ULA-C can be addressed, at least for the moment.
I, for one, hereby state that I will not route other folks ULA space on AS5539. Period.
Good for you. If you can get everyone else with an AS to make the same promise in writing and make that promise binding on their successors and assigns, then, we might have something. Owen
Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 113403
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
[Funny those multi-mailinglist threads - I never know in which mailbox they'll congregate!] On 15-mei-2007, at 0:47, Owen DeLong wrote:
If the qualifications for ULA-C were the same, or, if ULA-C was only available to orgs. that had PI, I think that would be acceptable.
I can't really understand the reasoning behind that. What are you trying to achieve, why do you want to restrict handing out ULA-C to only a specific (small) subset of folks out there?
I don't want to give ULA-C to people who have an incentive to abuse it as PI.
Don't forget that address space is only useful if it's (almost) universally accepted. This is almost certainly not going to be the case for any type of ULA. Apart from that, I would argue that if you want to make sure that ULAs can't be used as PI, it's beneficial to make sure that there are as many of those block out there as possible, so that the prospect of carrying even a subset of those becomes inpractical. And in my opinion, there is no reason to involve the RIRs in giving out ULA-c space, as there are no requirements that must be checked. Just make sure the price is high enough that people aren't going to use up excessively large amounts and any domain registry/registrar should be able to give those out. Something like 5 euros per year should make sure people won't register millions of them without creating a barrier for those who need ULA space and prefer the centrally assigned kind.
ULA-C becomes PI the moment folks will accept it in their routing table (and if that is a serious risk, ULA-L could as easily become PI the same way). But why should routing folks do that?
Hopefully routing folks won't, but, in my experience, $$$ can lead routing folks to ignore what should or shouldn't be done from an internet context and, instead, focus on what makes money.
If you can get 5% of the internet population to boycott routable ULAs that makes them unusable as such so this won't be a problem.
On Tue, May 22, 2007 at 10:45:12AM +0200, Iljitsch van Beijnum wrote:
Don't forget that address space is only useful if it's (almost) universally accepted.
that is hardly true.
Just make sure the price is high enough that people aren't going to use up excessively large amounts and any domain registry/registrar should be able to give those out.
selling numbers eh? thats a neat trick. will RIPE sell me address space? --bill
bmanning@karoshi.com wrote:
selling numbers eh? thats a neat trick. will RIPE sell me address space?
4 years from now, there will be an active IPv4 address space market, whatever about ipv6. Nick -- 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@inex.ie
4 years from now, there will be an active IPv4 address space market, whatever about ipv6.
bingo! what amazes me is the lack of real work on the problem that a a jillion v6-only sites can not connect to the internet in a useful scalable way. without that, everyone will continue to need ipv4 space for a loooooong time. and it will be sliced and diced, and bought and sold, in smaller and smaller pieces. and nats will be ubiquitous, as if they were not already. this is not a pleasing picture. but it's the likely reality. randy
Randy Bush wrote:
what amazes me is the lack of real work on the problem that a a jillion v6-only sites can not connect to the internet in a useful scalable way. without that, everyone will continue to need ipv4 space for a loooooong time. and it will be sliced and diced, and bought and sold, in smaller and smaller pieces. and nats will be ubiquitous, as if they were not already. this is not a pleasing picture. but it's the likely reality.
I see a two potential escape paths: 1. larger access providers run into the comcast problem[1] and realise that ipv4 is a dead end. this will lead to mass consumer ipv6 enablement, potentially with proxies to provide ipv4 transport. this will be particularly noticeable in emerging markets, where a) there is a relatively small install base which leads to a massive requirement for address space and b) there are language borders, which means that local content providers can service their entire market on ipv6 without having to worry about whether the current ipv4 install base can access it 2. wide-scale implementation of NAT at access levels is going to make people realise exactly how evil NAT is, and that ultimately, administration, hackery and capex costs for obtaining new ipv4 space are going to end up as more than the cost of moving to ipv6. There's nothing that concentrates the mind like having your business size constrained by a technical problem. But you're right on about fragmentation. It's going to happen in a big way and the effect on the internet is going to be savage. Ironically, massive fragmentation is a good driver for ipv6 takeup. Nick [1] http://www.nanog.org/mtg-0606/durand.html
Nick, On May 22, 2007, at 8:58 AM, Nick Hilliard wrote:
1. larger access providers run into the comcast problem[1] and realise that ipv4 is a dead end. this will lead to mass consumer ipv6 enablement, potentially with proxies to provide ipv4 transport.
Perhaps the best future scenario that has a reasonable chance of actually getting deployed is a world in which the core is v6 which provides IPv4 tunneled transit connectivity to v4 NAT/ALG endpoints. IPv6 native hosts within those endpoints could bypass the IPv4 NAT/ ALG to connect to IPv6 enabled content.
this will be particularly noticeable in emerging markets, where a) there is a relatively small install base which leads to a massive requirement for address space and b) there are language borders, which means that local content providers can service their entire market on ipv6 without having to worry about whether the current ipv4 install base can access it
This makes the assumption that emerging markets have no interest in existing Internet content, the vast majority of which is and will remain on IPv4 for the foreseeable future.
2. wide-scale implementation of NAT at access levels is going to make people realise exactly how evil NAT is, and that ultimately, administration, hackery and capex costs for obtaining new ipv4 space are going to end up as more than the cost of moving to ipv6. There's nothing that concentrates the mind like having your business size constrained by a technical problem.
The most likely future is highly dependent on NAT/ALG. For the foreseeable future, most content on the Internet will continue to be provided by IPv4. In order for IPv6-only sites to access that content, you will need to have v6-to-v4 NAT/ALG at one end or the other.
But you're right on about fragmentation. It's going to happen in a big way and the effect on the internet is going to be savage. Ironically, massive fragmentation is a good driver for ipv6 takeup.
OK, I give up. How does massive fragmentation drive IPv6 takeup? Thanks, -drc
David Conrad wrote:
OK, I give up. How does massive fragmentation drive IPv6 takeup?
Hmmm, my original comment looks like it came out my ass. The driver is that massive fragmentation will cause significant expansion of the default-free routing table. For operators who run on slightly older and less capable routers which are reaching their end-of-life in terms of fib explosion, this is going to provide them with a good driver to upgrade their core boxes. I'd propose that there would be two consequences to this: 1) any new system they are going to deploy is almost certainly going to support ipv6 out-of-the-box and 2) it's going to cause network engineers and - with any luck - bean-counters to realise that continuing problems with ipv4 have just taken a very large chunk out of their annual capex. Which gets back to my original point that ipv6 is not going to see any level of success until it becomes a financially more attractive option than ipv4. Let's rephrase the original comment as not so much driving ipv6 uptake but removing further obstacles to its uptake. Nick
On 22-mei-2007, at 17:41, Randy Bush wrote:
4 years from now, there will be an active IPv4 address space market, whatever about ipv6.
bingo!
...and that will be the fastest way to kill the remaining v4 space. Triple word value!
what amazes me is the lack of real work on the problem that a a jillion v6-only sites can not connect to the internet in a useful scalable way.
Interconnection between IPv6 clients and IPv4 servers can work very well and it can be done at three layers: - application - transport - network At the application layer we have proxies. The problem is that applications need to be aware of them and you need different proxies for different applications. However, pretty much any client-to-server TCP application can make use of the CONNECT method created for HTTPS proxying without the proxy having to be aware of the application protocol. At the transport layer you can have a TCP relay with a DNS ALG, serves the same function as a CONNECT proxy but without the app having to know about it. Not widely implemented, though. And for the network layer the IETF defined NAT-PT (network address translation - protocol translation) which translates between IPv6 and IPv4 and performs IPv4 NAT. Haven't tested this myself due to lack of implementations I could get my hands on and then the IETF decided this wasn't a good idea after all so NAT-PT is either already gone or on the way out. So the good news is that it's fairly trivial to support IPv6-only clients if you have a dual stack proxy and mail server. This takes care of HTTP (90% of all apps right there), HTTPS, mail and basic IM functionality. There are two flavors of peer-to-peer. The first one is towards specific peers, such as with VoIP, so you either need to wait for everyone to have IPv6 or have application-specific proxies. The second type is towards any reasonable subset of a lot of peers, such as BitTorrent. You don't care which peers you talk to, as long as it's enough to get the file. So what you need here is a reasonable subset of peers that are dual stack to facilitate the movement of bits between IPv6-only and IPv4-only peers. There's also often a server or tracker, which would have to be proxied or dual stack. There you have it. You can actually run IPv6-only and get work done, even with the current state of affairs.
On Tue, May 22, 2007 at 04:33:28PM +0100, Nick Hilliard wrote:
bmanning@karoshi.com wrote:
selling numbers eh? thats a neat trick. will RIPE sell me address space?
4 years from now, there will be an active IPv4 address space market, whatever about ipv6.
sucker bet. :) there is already an active IPv4 address space market. --bill
Nick
-- 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@inex.ie
Gert Doering wrote:
... I'd take a much simpler approach - install a one-time setup fee, which will prevent folks from just grabbing 10000s of ULA-C prefixes, and then just hand them out to whoever wants some (and pays the handling fee).
A registration fee is a one-time event. RIR membership is ongoing and provides a way to know what is active. I doubt there would ever be need to reclaim/reuse any of the allocations, but this is an attractive resource, use it as such to provide a reason to be an RIR member.
... ULA-C becomes PI the moment folks will accept it in their routing table (and if that is a serious risk, ULA-L could as easily become PI the same way). But why should routing folks do that?
PI will exist in whatever form it has to. If that means punching holes in PA space, then it will be that. Rather than trying to prevent the unpreventable through a disassociated policy, grab it and manage it. Create PI that is managed. If that exists in an easy to get form, the ULA-C discussion is moot because it will cost more to convince an ISP to route it than to just get recognized PI space.
I, for one, hereby state that I will not route other folks ULA space on AS5539. Period.
That is a fine position to take, but that is only one of ~20k AS's. Create a managed PI space, & ULA-C space, then the intended state will be easy for ISPs to enforce. Without both, unmanaged versions of both will be created and create confusion down the road. Tony
Hi, On Mon, May 14, 2007 at 05:42:47PM -0700, Tony Hain wrote:
PI will exist in whatever form it has to. If that means punching holes in PA space, then it will be that. Rather than trying to prevent the unpreventable through a disassociated policy, grab it and manage it. Create PI that is managed. If that exists in an easy to get form, the ULA-C discussion is moot because it will cost more to convince an ISP to route it than to just get recognized PI space.
Thanks for these thoughts. Wearing the APWG chair hat, I encourage people to think through this, in the light of the open policy proposals (for IPv6 PI, and for ULA-Central), and give us their feedback accordingly. Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 113403 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
Owen DeLong wrote:
......
If you prefer the RIR process, would you be in favor of a global policy submitted to ARIN that had the provisions of the expired ULA-central draft, with the modification of removing "cental authority" and clearly designating how IANA should divide the space among the existing RIRs?
Not sure about that. I do support the idea of ULA-Central as intended, but, I'd have to see a policy or RFC that implemented it in such a way that I had reasonable confidence it wouldn't become "the easy way to get PI". If we're going to do that, I'd rather do it by relaxing the PI policy than by designating some "nudge nudge wink wink" address space.
The 'central authority' was not intended to preclude the RIR's, just not impose something upon them they didn't want. The RIR's are member organizations that don't sell or lease address space, they manage a resource on behalf of the members. If you want long term membership to grow and/or sustain the costs of running the organization, then you need to offer a service that is attractive. ULA-C space is an attractive resource to many organizations that have been burned on 1918 mergers. If you don't want that to become an alternate PI space, then recognize that PI space is another attractive resource that would justify sustaining membership. Most of the potential members that would be interested in one of those would also be interested in the other, so create a policy that automatically allocates both to reduce internal costs for interacting with the paperwork & database. The noise about PI blowing out the routing system is just that, -noise-. If all ~20k AS entities came and demanded PI space we would have a whopping 20k routing entries in the IPv6 DFZ BGP mesh. At 1/10th the IPv4 table, and basically stable vs. growing at a compound rate, that is not even noticeable. Tony
Tony Hain wrote:
Owen DeLong wrote:
...... [...]
The noise about PI blowing out the routing system is just that, -noise-. If all ~20k AS entities came and demanded PI space we would have a whopping 20k routing entries in the IPv6 DFZ BGP mesh. At 1/10th the IPv4 table, and basically stable vs. growing at a compound rate, that is not even noticeable.
I have long since stopped listening to *that* "-noise-" as you put it.
Tony
I am prepared to start listening again as soon as the "Gain"-figures in the CIDR report start to change dramatically: --- 11May07 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 217147 140280 76867 35.4% All ASes Wilfried.
I am prepared to start listening again as soon as the "Gain"-figures in the CIDR report start to change dramatically:
--- 11May07 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 217147 140280 76867 35.4% All ASes
i pretty much hate TE routes. companies who build their business plans on TE routes are, as randy bush once called it, just grazing in the commons. but apparently nobody filters on prefix length any more. that surprises me.
Paul Vixie wrote:
I am prepared to start listening again as soon as the "Gain"-figures in the CIDR report start to change dramatically:
--- 11May07 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 217147 140280 76867 35.4% All ASes
i pretty much hate TE routes. companies who build their business plans on TE routes are, as randy bush once called it, just grazing in the commons.
but apparently nobody filters on prefix length any more. that surprises me.
Surprised, not really... I simply take it as living proof that almost nobody really cares about seeing some (50..)70K+ routes more or less in their boxes, these days. Wilfried.
Wilfried Woeber, UniVie/ACOnet wrote: [..]
I simply take it as living proof that almost nobody really cares about seeing some (50..)70K+ routes more or less in their boxes, these days.
See it is a business trick: when there are say 300k routes in the routing tables, you are forcing your competition to also carry that amount of routes in their tables, that means your competition will also have to buy fast new cool routers with a lot of memory. This makes various vendors happy, but it also takes care of emptying your competitions pocket books. When they spend all their cash on routers, they won't be able to invest in other things or need to up their prices, resulting in those customers coming to you etc etc etc. Economics 101. Has not much to do with "The Internet" any more. The road to monopoly has many routes ;) Greets, Jeroen
On Tue, 15 May 2007, Jeroen Massar wrote:
Wilfried Woeber, UniVie/ACOnet wrote: [..]
I simply take it as living proof that almost nobody really cares about seeing some (50..)70K+ routes more or less in their boxes, these days.
See it is a business trick: when there are say 300k routes in the routing tables, you are forcing your competition to also carry that amount of routes in their tables, that means your competition will also
I'm going to assume by "300k routes in the routing tables" that you are referring to the 'global internet routing table'. Well remember there are 2 routing tables, the 'global internet routing table' and a providers internal routing table.. You aggregate where you can and don't send internal routes to peers, only PI and routes that get leaked for multihoming/traffic engineering reasons. The larger the provider and the more fragmented their address space, the larger their internal routing table. So by the time the 'global internet routing table' reaches 300k routes, your largest transit providers will be well past 300k.
have to buy fast new cool routers with a lot of memory. This makes
Does this go for folks who think PI is great too? I'd be happy to deggregate to everyone, and get this over with right now.. but something tells me that wouldn't last more than a few hours. I'm not interested in making the competition have to buy hardware too -- unless it pushes the vendors along to build new hardware. I just want a vendor to make something that can support all the routes and not have to replace it by the time we get it deployed.
various vendors happy, but it also takes care of emptying your competitions pocket books. When they spend all their cash on routers, they won't be able to invest in other things or need to up their prices, resulting in those customers coming to you etc etc etc. Economics 101. Has not much to do with "The Internet" any more.
The road to monopoly has many routes ;)
Greets, Jeroen
############################################### # Heather Schiller # # Customer Security & IP Address Management # # 800.900.0241 # # security@mci.com # ###############################################
I've talked with Leo from IANA about this details a few days ago. Basically there are two choices to make this happen (even both in parallel): 1) The ID becomes an RFC and possibly has further details, as for example a possible split of the FC00 in between several registries, or just a mention of the IANA as to designate the central registry (a single one or distributed across several), with an explicit mention of the RIRs as being that authority. 2) A global policy doing the same job. The risk here is that it is not accepted by any of the RIRs, and then we become stuck. I will say that the RFC path may be faster and actually is what I'm trying to follow with the ID authors. Regards, Jordi
De: Jason Schiller <schiller@uu.net> Responder a: <ppml-bounces@arin.net> Fecha: Fri, 11 May 2007 09:05:10 -0400 (EDT) Para: Owen DeLong <owen@delong.com> CC: <vixie@vix.com>, <ppml@arin.net>, "address-policy-wg@ripe.net" <address-policy-wg@ripe.net> Asunto: Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot)
Owen,
I just want to be clear about somehting you said. You view ULA central as "an end-run on the RIR process." Is this because the expired ULC-central draft suggests that some new "central allocation authority" be established to assign these addresses?
If the draft RFC was resurrected and all references to "cental allocation authority" and "cental authority" were removed and replaced with clear text explaining the following:
- IANA should divide FC00::/8 into eight /11s - Each RIR would be given one /11 to make ULA-Central assignments - Three /11s would be held in reserve for new RIRs in the future.
Would you still think this was an end-run on the RIR process?
Would you be in support of the draft moving forward?
Do you think this should not be decided by an RFC, but rather as a global policy through each of the RIRs?
If you prefer the RIR process, would you be in favor of a global policy submitted to ARIN that had the provisions of the expired ULA-central draft, with the modification of removing "cental authority" and clearly designating how IANA should divide the space among the existing RIRs?
ULA-central text snippets below.
___Jason
draft-ietf-ipv6-ula-central-01.txt -- section 3.2.1 "Global IDs should be assigned under the authority of a single allocation organization because they are pseudo-random and without any structure. This is easiest to accomplish if there is a single authority for the assignments."
draft-ietf-ipv6-ula-central-01.txt -- section 7.0
"The IANA is instructed to designate an allocation authority, based on instructions from the IAB, for centrally assigned Unique Local IPv6 unicast addresses. This allocation authority shall comply with the requirements described in Section 3.2 of this document, including in particular allocation on a permanent basis and with sufficient provisions to avoid hoarding of numbers. If deemed appropriate, the authority may also consist of multiple organizations performing the allocation authority duties.
The designated allocation authority is required to document how they will meet the requirements described in Section 3.2 of this document in an RFC. This RFC will be shepherd through the IETF by the IAB."
========================================================================== Jason Schiller (703)886.6648 Senior Internet Network Engineer fax:(703)886.0512 Public IP Global Network Engineering schiller@uu.net UUNET / Verizon jason.schiller@verizonbusiness.com
The good news about having an email address that is twice as long is that it increases traffic on the Internet.
On Thu, 10 May 2007, Owen DeLong wrote:
Date: Thu, 10 May 2007 23:12:21 -0700 From: Owen DeLong <owen@delong.com> To: "william(at)elan.net" <william@elan.net> Cc: vixie@vix.com, ppml@arin.net, address-policy-wg@ripe.net Subject: Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot)
ULA Central is intended so that some subset of the internet can reliably use it to interconnect while not being "globally" routed.
The problem I have with this theory is that the delta between a collection of networks routing by mutual agreement and the internet is:
A. Fuzzy B. Non-Existant C. There is no difference D. Meaningless E. Any and/or All of the above
Pick your favorite answer from the above and you've pretty much got it. If ULA central were limited to not exiting the local AS (in some meaningful way, like routers won't forward routes or traffic to ULA addresses to external adjacencies), then, I might see it as something other than an end-run on the RIR process. However, in it's current state of "license for anyone who wants to run a competing RIR for networks that choose to interoperate on this basis" I think it's a pretty bad idea.
Owen
On May 11, 2007, at 12:03 AM, william(at)elan.net wrote:
I don't understand your point about why ULA need to be registered if its not going to be globally routed. Also PI is not the same as ULA - PI do come from RIRs and in IPv6 there was no way to get PI (except in a few special cases) until recent ARIN's micro-allocation policy.
On Fri, 11 May 2007, Tony Hain wrote:
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@arin.net [mailto:ppml-bounces@arin.net] On Behalf Of vixie@vix.com Sent: Thursday, May 10, 2007 9:59 PM To: ppml@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@arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml
_______________________________________________ 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
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
_______________________________________________ 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.
I hate to just parrot someone else's comments, but I'm entirely against the entire concept of ULA-central for exactly the reasons Owen outlines below. (Thanks, Owen, for getting that written so I don't have to!) -David On Thu, May 10, 2007 at 11:12:21PM -0700, Owen DeLong wrote:
ULA Central is intended so that some subset of the internet can reliably use it to interconnect while not being "globally" routed.
The problem I have with this theory is that the delta between a collection of networks routing by mutual agreement and the internet is:
A. Fuzzy B. Non-Existant C. There is no difference D. Meaningless E. Any and/or All of the above
Pick your favorite answer from the above and you've pretty much got it. If ULA central were limited to not exiting the local AS (in some meaningful way, like routers won't forward routes or traffic to ULA addresses to external adjacencies), then, I might see it as something other than an end-run on the RIR process. However, in it's current state of "license for anyone who wants to run a competing RIR for networks that choose to interoperate on this basis" I think it's a pretty bad idea.
Owen
On May 11, 2007, at 12:03 AM, william(at)elan.net wrote:
I don't understand your point about why ULA need to be registered if its not going to be globally routed. Also PI is not the same as ULA - PI do come from RIRs and in IPv6 there was no way to get PI (except in a few special cases) until recent ARIN's micro-allocation policy.
On Fri, 11 May 2007, Tony Hain wrote:
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@arin.net [mailto:ppml-bounces@arin.net] On Behalf Of vixie@vix.com Sent: Thursday, May 10, 2007 9:59 PM To: ppml@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@arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml
_______________________________________________ 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
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
_______________________________________________ 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
I don't understand your point about why ULA need to be registered if its not going to be globally routed. Also PI is not the same as ULA - PI do come from RIRs and in IPv6 there was no way to get PI (except in a few special cases) until recent ARIN's micro-allocation policy.
ULA addresses *WILL* be globally routed on an IPv6 internetwork. It just won't be the IP internetwork known as the Internet. Remember, IP addresses are not for use on the Internet, they are for use on IP networks. --Michael Dillon
Even if not globally routed, you may want to avoid a possible clash with another organization, for example in case of a merge. ULA-central is NOT intended to be uses as IPv6 PI. IPv6 PI is available already in ARIN, APNIC and AfriNIC. Ongoing policy proposals in both RIPE NCC and LACNIC. Regards, Jordi (I'm the the one that submitted the ULA-central policy proposal to all the regions, ARIN coming next)
De: "william(at)elan.net" <william@elan.net> Responder a: <ppml-bounces@arin.net> Fecha: Fri, 11 May 2007 00:03:08 -0700 (PDT) Para: Tony Hain <alh-ietf@tndh.net> CC: <vixie@vix.com>, <ppml@arin.net>, "address-policy-wg@ripe.net" <address-policy-wg@ripe.net> Asunto: Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot)
I don't understand your point about why ULA need to be registered if its not going to be globally routed. Also PI is not the same as ULA - PI do come from RIRs and in IPv6 there was no way to get PI (except in a few special cases) until recent ARIN's micro-allocation policy.
On Fri, 11 May 2007, Tony Hain wrote:
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@arin.net [mailto:ppml-bounces@arin.net] On Behalf Of vixie@vix.com Sent: Thursday, May 10, 2007 9:59 PM To: ppml@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@arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml
_______________________________________________ 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
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 Fri, 11 May 2007, JORDI PALET MARTINEZ wrote:
Even if not globally routed, you may want to avoid a possible clash with another organization, for example in case of a merge.
I agree. The importance of it being assigned by an authority is that that authority provides uniqueness. This is often important when an address collision occurs, such that one entity can prove they have the legitmate claim to use those numbers. Although these addresses may be used "internally" it is also important that they be capable to be supported by DNS (without setting up a split-horrizon DNS), for ease of management __Jason
On May 11, 2007, at 1:37 AM, JORDI PALET MARTINEZ wrote:
Even if not globally routed, you may want to avoid a possible clash with another organization, for example in case of a merge.
ULA-central is NOT intended to be uses as IPv6 PI.
Intent is not the problem. Probability of implementation outside of the intent is the problem. ULA Central is only beneficial if it is somehow easier to get than IPv6 PI. If it is easier to get and there is no solid (router-enforced) way to preclude it from being "globally routed", then, it will get abused as an alternative to IPv6 PI. Owen
This is something that could possibly be managed depending on how you setup the fees for ULA-central, but there may be other ways also. I think RIRs staff will make sure that one is not used instead of the other. Fraud (telling you need ULA-central and using as PI) is always a possibility with any policy, and there are means to verify it. I also believe that if transit providers understand the difference, they will not allow using ULA-central as PI, moreover, you will always have the risk of trying so and being filtered in part of the Internet. A PI requester will not risk (unless there is no PI, but now is available already in 3 regions, and I expect that will be in all before ULA-central is adopted in any). Regards, Jordi
De: Owen DeLong <owen@delong.com> Responder a: <owen@delong.com> Fecha: Fri, 11 May 2007 06:38:39 -0700 Para: <jordi.palet@consulintel.es> CC: <ppml@arin.net>, "address-policy-wg@ripe.net" <address-policy-wg@ripe.net> Asunto: Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot)
On May 11, 2007, at 1:37 AM, JORDI PALET MARTINEZ wrote:
Even if not globally routed, you may want to avoid a possible clash with another organization, for example in case of a merge.
ULA-central is NOT intended to be uses as IPv6 PI.
Intent is not the problem. Probability of implementation outside of the intent is the problem.
ULA Central is only beneficial if it is somehow easier to get than IPv6 PI.
If it is easier to get and there is no solid (router-enforced) way to preclude it from being "globally routed", then, it will get abused as an alternative to IPv6 PI.
Owen
********************************************** 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.
ULA-central is NOT intended to be uses as IPv6 PI.
but there is no way to stop it from becoming so.
On Mon, May 14, 2007 at 05:30:40AM +0000, bmanning@karoshi.com wrote:
ULA-central is NOT intended to be uses as IPv6 PI.
but there is no way to stop it from becoming so.
In the same way that RFC 1918 space is such a huge problem for the IPv4 routing table, ULA-central would be a problem in IPv6. (I think ULA-central is completely unnecessary, but I also think the "oh mi gawd IPv6 PI!!!1" argument is bogus.) -- Shane
bmanning@karoshi.com wrote:
ULA-central is NOT intended to be uses as IPv6 PI.
but there is no way to stop it from becoming so.
Other than by issuing bogon lists, where the ULA-centra prefixes will be noted. You certainly can't stop it or any other type of ipv6 address from becoming PI. But you can stop it from being useful PI space, which is all you need to do. Nick
On Mon, May 14, 2007 at 01:30:01PM +0100, Nick Hilliard wrote:
bmanning@karoshi.com wrote:
ULA-central is NOT intended to be uses as IPv6 PI.
but there is no way to stop it from becoming so.
Other than by issuing bogon lists, where the ULA-centra prefixes will be noted. You certainly can't stop it or any other type of ipv6 address from becoming PI. But you can stop it from being useful PI space, which is all you need to do.
Nick
you, my friend, have an over inflated view of your ability to effect "useful" for others. imho of course. --bill
bmanning@karoshi.com wrote:
On Mon, May 14, 2007 at 01:30:01PM +0100, Nick Hilliard wrote:
Other than by issuing bogon lists, where the ULA-centra prefixes will be noted. You certainly can't stop it or any other type of ipv6 address from becoming PI. But you can stop it from being useful PI space, which is all you need to do.
Nick
you, my friend, have an over inflated view of your ability to effect "useful" for others. imho of course.
I make no claim of any such ability :-) The point is, if a block is carved out and marked specifically as being non-routable on the public v6 internet, it will have degraded connectivity to some degree or other. On a related issue, I'd be interested to know what the reachability degradation was like for the last of the 3ffe:: space after 6/6/6? You didn't happen to do any measurements on it? Nick, psychically effecting usefulness all over the v6 internet
On Tue, May 15, 2007 at 10:47:28AM +0100, Nick Hilliard wrote:
bmanning@karoshi.com wrote:
On Mon, May 14, 2007 at 01:30:01PM +0100, Nick Hilliard wrote:
Other than by issuing bogon lists, where the ULA-centra prefixes will be noted. You certainly can't stop it or any other type of ipv6 address from becoming PI. But you can stop it from being useful PI space, which is all you need to do.
Nick
you, my friend, have an over inflated view of your ability to effect "useful" for others. imho of course.
I make no claim of any such ability :-)
er... perhaps I misread. you stated; "you can stop it from being useful PI space, which is all you need to do." i understand this as you (party Q) being able to effect any communications between myself (party R) and Gert (party S)... the single time this is effective is when party Q is in the transit path btwn R & S.
The point is, if a block is carved out and marked specifically as being non-routable on the public v6 internet, it will have degraded connectivity to some degree or other.
do i care? does that effect the usefulness of a given prefix if some ISP someplace filters out (refuses to listen) to the announcements? i posit that: a) i have zero influence on your operational behaviour when i have zero business relationship w/ you b) you have the ability to set whatever policies you like for packet acceptance into your network and packet egress from your network.
On a related issue, I'd be interested to know what the reachability degradation was like for the last of the 3ffe:: space after 6/6/6? You didn't happen to do any measurements on it?
for those parties still using the space, it is useful. i suspect that parties who filter prefixes "degrade" their clients ability to reach nodes/content in those filtered ranges. of course some clients utilize other tools (VPNs, tunnels, etc) to bypass crippled ISP thinking. (from the POV of the client ... kind of like many hotel networks) your general qustion (prefix reachability) is based on (imho again) a flawed premise... if i may, could you clarify the two endpoints for such a reachability study?
Nick, psychically effecting usefulness all over the v6 internet
got me there... can you also bend spoons w/ your mental powers? :) --bill
bmanning@karoshi.com wrote:
er... perhaps I misread. you stated; "you can stop it from being useful PI space, which is all you need to do." i understand this as you (party Q) being able to effect any communications between myself (party R) and Gert (party S)... the single time this is effective is when party Q is in the transit path btwn R & S.
"you" == RIRs/whoever publishing these blocks in a list of prefixes which should not be seen on the public ipv6 internet, due to community mandate. Well, we can talk about individual scenarios but let's not, because there's no problem cooking up situations where ULA-central could have some conceivable merit, in terms of regular reachability between two arbitrary parties on the public v6 internet, although I can't really think of any case where it would be more useful than, say regular PI or PA. Before abandoning this thought, consider: - do you want to base your bilateral communications and possibly your business on an something which is frankly unsupported as designed and could stop working at any stage if operator Q were to implement uncontroversial prefix filters? - do you want to go beyond communications between R and S? Prove the point, Bill. Go ahead and advertise 10/8 and use it in anger on the public ipv4 internet. When you've got some good figures which indicate how useful it is, let us know.
The point is, if a block is carved out and marked specifically as being non-routable on the public v6 internet, it will have degraded connectivity to some degree or other.
do i care?
Given your position on announcing 3ffe::/24 and 3ffe:800::/24 until fairly recently, evidently not :-)
does that effect the usefulness of a given prefix if some ISP someplace filters out (refuses to listen) to the announcements? i posit that: a) i have zero influence on your operational behaviour when i have zero business relationship w/ you b) you have the ability to set whatever policies you like for packet acceptance into your network and packet egress from your network.
No argument there. But we're talking about different things. So far, you're talking about connectivity between exactly two specific parties. I'm not.
On a related issue, I'd be interested to know what the reachability degradation was like for the last of the 3ffe:: space after 6/6/6? You didn't happen to do any measurements on it?
your general qustion (prefix reachability) is based on (imho again) a flawed premise... if i may, could you clarify the two endpoints for such a reachability study?
I was thinking more of X = time, Y = % of ipv6 space reachable from ${3ffe}, where 100% at a particular timepoint would be # of reachable prefixes from some place known to be relatively well connected (cue flames for fuzzy specification). Given your reaction to the question, it sounds like you haven't done looked into this, which is a minor pity. Nick, bill's friend(tm)
On Tue, May 15, 2007 at 12:47:09PM +0100, Nick Hilliard wrote:
bmanning@karoshi.com wrote:
er... perhaps I misread. you stated; "you can stop it from being useful PI space, which is all you need to do." i understand this as you (party Q) being able to effect any communications between myself (party R) and Gert (party S)... the single time this is effective is when party Q is in the transit path btwn R & S.
"you" == RIRs/whoever publishing these blocks in a list of prefixes which should not be seen on the public ipv6 internet, due to community mandate.
i have problems w/ the term "public [I,i]nternet" - could you please define it?
- do you want to base your bilateral communications and possibly your business on an something which is frankly unsupported as designed and could stop working at any stage if operator Q were to implement uncontroversial prefix filters?
are you suggesting that party Q is the only option for communications btwn parties R & S?
- do you want to go beyond communications between R and S?
sure...
Prove the point, Bill. Go ahead and advertise 10/8 and use it in anger on the public ipv4 internet. When you've got some good figures which indicate how useful it is, let us know.
not a chance. i will note that there are a whole bunch of folks who do use 10.0.0.0/8 "in anger" on the internet - i see many packets w/ this netblock as a source address.
The point is, if a block is carved out and marked specifically as being non-routable on the public v6 internet, it will have degraded connectivity to some degree or other.
do i care?
Given your position on announcing 3ffe::/24 and 3ffe:800::/24 until fairly recently, evidently not :-)
marked by whom? (and wrt 3ffe:: space... folks are still using it and so i still annouce it. it remains useful for them. :)
does that effect the usefulness of a given prefix if some ISP someplace filters out (refuses to listen) to the announcements? i posit that: a) i have zero influence on your operational behaviour when i have zero business relationship w/ you b) you have the ability to set whatever policies you like for packet acceptance into your network and packet egress from your network.
No argument there. But we're talking about different things. So far, you're talking about connectivity between exactly two specific parties. I'm not.
so your talking about multicast? last i checked, nearly all traffic was unicast; e.g. end to end, e.g. between exactly two specific parties.
On a related issue, I'd be interested to know what the reachability degradation was like for the last of the 3ffe:: space after 6/6/6? You didn't happen to do any measurements on it?
your general qustion (prefix reachability) is based on (imho again) a flawed premise... if i may, could you clarify the two endpoints for such a reachability study?
I was thinking more of X = time, Y = % of ipv6 space reachable from ${3ffe}, where 100% at a particular timepoint would be # of reachable prefixes from some place known to be relatively well connected (cue flames for fuzzy specification). Given your reaction to the question, it sounds like you haven't done looked into this, which is a minor pity.
but that is the wrong question. how in the world do you ensure reachability across thousands of ASNs, each of which is willing/able to set their own policies about prefix acceptance? I'm almost persuaded that I don't WANT reachability to all that v6 space... too many places to hid spambots. (and yes, the fuzzy specification is hard to code to... :)
Nick, bill's friend(tm)
thats a new one... :) care to take out a partnership in "Bills Bait & Sushi" ... there are franchise ops available.
[this is getting far too pedantic and way off topic for address-policy-wg] bmanning@karoshi.com wrote:
i have problems w/ the term "public [I,i]nternet" - could you please define it?
In such a way that 1) you'd be happy with the definition and 2) we're stay relaticely on-topic for address-policy-wg@ripe? I doubt it. Your ability to pick nits far exceeds the charter of this mailing list - and, indeed my patience for creating water tight definitions. I'm aware of your position on "which [Ii]nternet are we talking about".
- do you want to base your bilateral communications and possibly your business on an something which is frankly unsupported as designed and could stop working at any stage if operator Q were to implement uncontroversial prefix filters?
are you suggesting that party Q is the only option for communications btwn parties R & S?
no, merely that allowing your money and livelihood to depend on something unsupported (as-designed) is not a wise move, imo.
marked by whom? (and wrt 3ffe:: space... folks are still using it and so i still annouce it. it remains useful for them. :)
Why not - if it makes you happy. Incidentally, would you mind if I also announced 3ffe::/24 to my v6 upstreams? Now that 3ffe space is deprecated (and let's not get into the "by whom" argument here), I'm sure you can't have any objections. I could make 3ffe::/24 useful to my peers too, I'm sure. What do you think? After all, sharing is caring.
No argument there. But we're talking about different things. So far, you're talking about connectivity between exactly two specific parties. I'm not.
so your talking about multicast? last i checked, nearly all traffic was unicast; e.g. end to end, e.g. between exactly two specific parties.
no, i'm talking about unicast between R and [A-P][S-Z]. I.e. generic connectivity on the public ipv6 Internet (note calculated use of undefined term) between relatively arbitrary parties also on the same public Internet.
I was thinking more of X = time, Y = % of ipv6 space reachable from ${3ffe}, where 100% at a particular timepoint would be # of reachable prefixes from some place known to be relatively well connected (cue flames for fuzzy specification). Given your reaction to the question, it sounds like you haven't done looked into this, which is a minor pity.
but that is the wrong question. how in the world do you ensure reachability across thousands of ASNs, each of which is willing/able to set their own policies about prefix acceptance?
No idea. Global dictatorship? But policies can be defined which create a network of networks which generally interoperate and interconnect well, and where if you can't get connectivity from point A to point B, that might be considered enough of a problem for the relevant people to want to fix it. That's enough for me.
bill's friend(tm)
thats a new one... :) care to take out a partnership in "Bills Bait & Sushi" ... there are franchise ops available.
In a different world, perhaps. It might appeal to me more if I were of the meat-eating inclination. Do you have any other appealing franchise options? Nick, "you know what I mean"
On 15-mei-2007, at 11:47, Nick Hilliard wrote:
On a related issue, I'd be interested to know what the reachability degradation was like for the last of the 3ffe:: space after 6/6/6? You didn't happen to do any measurements on it?
I wanted to keep my 3ffe block in the air as long as possible to see what would happen. Unfortunately, my ISP stopped routing it almost immediately and I was dead in the water... I was surprised to see how fast all of this went down.
Iljitsch van Beijnum wrote:
On 15-mei-2007, at 11:47, Nick Hilliard wrote:
On a related issue, I'd be interested to know what the reachability degradation was like for the last of the 3ffe:: space after 6/6/6? You didn't happen to do any measurements on it?
I wanted to keep my 3ffe block in the air as long as possible to see what would happen. Unfortunately, my ISP stopped routing it almost immediately and I was dead in the water... I was surprised to see how fast all of this went down.
As with everything in that order, see either RIS (http://ris.ripe.net) or of course http://www.sixxs.net/tools/grh/dfp/6bone/ Both 3ffe::/24 and 3ffe:800::/24 are still being announced by Bill Manning, the rest died off quite quickly in the week after Greets, Jeroen -- GRH 6bone list sorted: 2007-05-22 2 <-- still alive 2007-02-16 1 2006-12-15 1 2006-12-14 1 2006-10-07 1 2006-09-19 1 2006-07-29 1 2006-07-18 1 2006-07-08 1 2006-06-30 1 2006-06-26 1 2006-06-21 1 2006-06-19 1 2006-06-16 1 2006-06-15 2 2006-06-13 2 2006-06-12 1 2006-06-08 3 2006-06-07 11 2006-06-06 23 <-- 6GONE date 2006-06-05 1 2006-06-01 2 2006-05-30 1 2006-05-29 1 2006-05-24 2 2006-05-17 1 ... lot of other stuff...
bmanning@karoshi.com wrote:
ULA-central is NOT intended to be uses as IPv6 PI.
but there is no way to stop it from becoming so.
The only effective way to stop it is to make PI have a lower cost than ULA-C. The most straight forward way to implement that is; at the RIR policy level acknowledge that PI will exist and create the appropriate mechanisms to manage it; at the ISP level, recognize that PI is available and refuse (set exorbitant fees) to route ULA-C. Trying to stop something that is outside the RIR policy control through RIR policy is a waste of time and energy. Recognize that whatever you do PI will exist in some form, and avoid the situation where it is completely unmanageable by creating a formal process where it is easy enough to get that people won't bother with working around you. If you want something to be contained and managed then step up and manage it. Trying to abolish it will only ensure that it exists outside the realm of manageability. Tony
And the only way to control ULA-central is to have it within the RIR system, instead of waiting for IETF to move ahead the document and doing themselves or thru and alternative third party organization. So having a "managed" path for ULA-central is in our hands. Regards, Jordi
De: Tony Hain <alh-ietf@tndh.net> Responder a: <alh-ietf@tndh.net> Fecha: Mon, 14 May 2007 17:28:47 -0700 Para: <bmanning@karoshi.com>, 'JORDI PALET MARTINEZ' <jordi.palet@consulintel.es> CC: <ppml@arin.net>, <address-policy-wg@ripe.net> Asunto: RE: [address-policy-wg] Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot)
bmanning@karoshi.com wrote:
ULA-central is NOT intended to be uses as IPv6 PI.
but there is no way to stop it from becoming so.
The only effective way to stop it is to make PI have a lower cost than ULA-C. The most straight forward way to implement that is; at the RIR policy level acknowledge that PI will exist and create the appropriate mechanisms to manage it; at the ISP level, recognize that PI is available and refuse (set exorbitant fees) to route ULA-C.
Trying to stop something that is outside the RIR policy control through RIR policy is a waste of time and energy. Recognize that whatever you do PI will exist in some form, and avoid the situation where it is completely unmanageable by creating a formal process where it is easy enough to get that people won't bother with working around you. If you want something to be contained and managed then step up and manage it. Trying to abolish it will only ensure that it exists outside the realm of manageability.
Tony
********************************************** 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 15-mei-2007, at 9:57, JORDI PALET MARTINEZ wrote:
And the only way to control ULA-central is to have it within the RIR system,
How would that work in practice? Approximately 100% of all organizations use RFC 1918 space. Obviously one use for RFC 1918 space goes away with IPv6 (NAT) but I'd say that the number of internet users requiring some kind of local addressing will still be 10, 20, 30 or more percent. The RIR membership is measured in thousands. So tens of thousands or even hundreds of thousands of organizations that may want ULA-c space have no relationship with an RIR. They may not even have a relationship with an ISP... So how are the RIRs supposed to manage their relationship with 10 or 100 times as many people as they have relationships with now?
It is a matter of having the same organization that allocated IP addresses doing allocation of IP addresses, despite the number of "possible customers", instead of having a *new* organization doing so. I really think it may become a political issue and breach for the RIRs system and I don't feel very comfortable with that. The allocation of the ULA-central addresses can be managed in a very automated way, so not a big issue if really becomes a "big" number of them (which I'm convinced will be the case, because only some big entities may want to avoid using ULA local, but enough to avoid wasting global unicast instead). Regards, Jordi
De: Iljitsch van Beijnum <iljitsch@muada.com> Responder a: <address-policy-wg-admin@ripe.net> Fecha: Tue, 22 May 2007 10:51:19 +0200 Para: <jordi.palet@consulintel.es> CC: <ppml@arin.net>, "address-policy-wg@ripe.net" <address-policy-wg@ripe.net> Asunto: Re: [address-policy-wg] Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot)
On 15-mei-2007, at 9:57, JORDI PALET MARTINEZ wrote:
And the only way to control ULA-central is to have it within the RIR system,
How would that work in practice? Approximately 100% of all organizations use RFC 1918 space. Obviously one use for RFC 1918 space goes away with IPv6 (NAT) but I'd say that the number of internet users requiring some kind of local addressing will still be 10, 20, 30 or more percent. The RIR membership is measured in thousands. So tens of thousands or even hundreds of thousands of organizations that may want ULA-c space have no relationship with an RIR. They may not even have a relationship with an ISP...
So how are the RIRs supposed to manage their relationship with 10 or 100 times as many people as they have relationships with now?
********************************************** 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 May 22, 2007, at 1:51 AM, Iljitsch van Beijnum wrote:
On 15-mei-2007, at 9:57, JORDI PALET MARTINEZ wrote:
And the only way to control ULA-central is to have it within the RIR system,
How would that work in practice? Approximately 100% of all organizations use RFC 1918 space. Obviously one use for RFC 1918 space goes away with IPv6 (NAT) but I'd say that the number of internet users requiring some kind of local addressing will still be 10, 20, 30 or more percent. The RIR membership is measured in thousands. So tens of thousands or even hundreds of thousands of organizations that may want ULA-c space have no relationship with an RIR. They may not even have a relationship with an ISP...
First of all, at least in the case of ARIN, membership is not a requirement for obtaining Address space. I realize that in RIPE and APNIC, membership is required. However, nobody actually NEEDS local addressing, technically. Technically, people NEED addressing. The distinction between local and global addressing is mostly an administrative convenience. There is no local addressing purpose for which global addresses are inadequate or infeasible. I'm quite sure that the RIRs can handle additional business relationships just fine. If someone has neither a relationship with an ISP nor a relationship with an RIR, then, one of those two things will have to change before they get addresses assigned. Same way things work today, except for RFC-1918 and ULA-Local.
So how are the RIRs supposed to manage their relationship with 10 or 100 times as many people as they have relationships with now?
Same way they do now. Might require beefier or more servers, and an increased staff, but, I would expect that with 10-100 times the fees rolling in, that won't be a problem. Owen
Thus spake "Iljitsch van Beijnum" <iljitsch@muada.com>
On 15-mei-2007, at 9:57, JORDI PALET MARTINEZ wrote:
And the only way to control ULA-central is to have it within the RIR system,
How would that work in practice? Approximately 100% of all organizations use RFC 1918 space. Obviously one use for RFC 1918 space goes away with IPv6 (NAT) but I'd say that the number of internet users requiring some kind of local addressing will still be 10, 20, 30 or more percent. The RIR membership is measured in thousands.
All correct.
So tens of thousands or even hundreds of thousands of organizations that may want ULA-c space have no relationship with an RIR. They may not even have a relationship with an ISP...
So how are the RIRs supposed to manage their relationship with 10 or 100 times as many people as they have relationships with now?
You have the flawed assumption that everyone who uses RFC1918 space today will want/need ULA-C in the future. The vast majority of folks will be fine with ULA-L (or PA) space, and the target market for ULA-C is identical to the target market for PIv6. It will be the same number of orgs regardless of which type of space they request, so the debate comes down to why we want to put orgs on ULA-C space instead of just giving them PI space. If they're truly going to use it privately, they won't consume routing slots in the DFZ, and if they aren't they'll be using PIv6 anyways and won't have a need for ULA-C. I object to making orgs second-class IPv6 citizens under the guise of "private" addresses, and there is significant risk that ULA-C will end up not being "private" because there will be a set of ISPs that agree to route the space for a fee. If that set grows to critical mass, ULA-C will be no different than PIv6 anyways. 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
On 27-mei-2007, at 22:51, Stephen Sprunk wrote:
Thus spake "Iljitsch van Beijnum" <iljitsch@muada.com>
On 15-mei-2007, at 9:57, JORDI PALET MARTINEZ wrote:
And the only way to control ULA-central is to have it within the RIR system,
How would that work in practice? Approximately 100% of all organizations use RFC 1918 space. Obviously one use for RFC 1918 space goes away with IPv6 (NAT) but I'd say that the number of internet users requiring some kind of local addressing will still be 10, 20, 30 or more percent. The RIR membership is measured in thousands.
All correct.
So tens of thousands or even hundreds of thousands of organizations that may want ULA-c space have no relationship with an RIR. They may not even have a relationship with an ISP...
So how are the RIRs supposed to manage their relationship with 10 or 100 times as many people as they have relationships with now?
You have the flawed assumption that everyone who uses RFC1918 space today will want/need ULA-C in the future.
No, what I said was:
Approximately 100% of all organizations use RFC 1918 space. Obviously one use for RFC 1918 space goes away with IPv6 (NAT) but I'd say that the number of internet users requiring some kind of local addressing will still be 10, 20, 30 or more percent.
The vast majority of folks will be fine with ULA-L
Most people aren't very good with statistics, knowing for sure you have unique space is better than having just a 99.9999% probability that it's unique.
(or PA) space
PA or PI is irrelevant to this discussion, people who need ULA may not even connect to the internet, and if they do, they need this space in ADDITION to routable address space, regardless of the type.
and the target market for ULA-C is identical to the target market for PIv6.
Nonsense.
so the debate comes down to why we want to put orgs on ULA-C space instead of just giving them PI space.
No-brainer: ULA-C space doesn't use up routing table slots.
If they're truly going to use it privately, they won't consume routing slots in the DFZ, and if they aren't they'll be using PIv6 anyways and won't have a need for ULA-C.
You are being ridiculous. There is no connection between ULA-C and PI. Everyone can get ULA, not everyone can get PI. And ULA is even more important for people who have PA because that way they can have their internal infrastructure on stable addresses even when their routable address space is renumbered. Also, with IPv4, it's very common to use RFC 1918 space for internal infrastructure that must not be reachable from the internet. It's much more convenient to use unroutable address space for this rather than routable address space that is filtered.
there is significant risk that ULA-C will end up not being "private" because there will be a set of ISPs that agree to route the space for a fee. If that set grows to critical mass, ULA-C will be no different than PIv6 anyways.
I don't see the problem. We agree that routing ULA space is a bad idea. However, if someone is prepared to give me enough money to change my mind, how can that possibly be a problem? Or do you want to protect yourself from your own greed?
On man, mai 28, 2007 14:30, Iljitsch van Beijnum wrote:
On 27-mei-2007, at 22:51, Stephen Sprunk wrote:
Thus spake "Iljitsch van Beijnum" <iljitsch@muada.com>
On 15-mei-2007, at 9:57, JORDI PALET MARTINEZ wrote: Approximately 100% of all organizations use RFC 1918 space. Obviously one use for RFC 1918 space goes away with IPv6 (NAT) but I'd say that the number of internet users requiring some kind of local addressing will still be 10, 20, 30 or more percent.
The vast majority of folks will be fine with ULA-L
Most people aren't very good with statistics, knowing for sure you have unique space is better than having just a 99.9999% probability that it's unique.
not really, I work a place where we just can´t have any more collision of address space, we have a few options and ULA-central is the best. 1.) get ula-central and know for sure we won´t get into this issue ever again. 2.) administrate our own local version of ULA-central for the organization we co-operate with 3.) get RIR-space with all the add on administration and documentation... For me, only option 1.) is a real option, the other two are just work-around since we don´t need global routing of the address space in question.
(or PA) space
PA or PI is irrelevant to this discussion, people who need ULA may not even connect to the internet, and if they do, they need this space in ADDITION to routable address space, regardless of the type.
this go for the type of organization I work for. We have our own /32 already and it suite our need for public address space just fine given the 3 options above.
and the target market for ULA-C is identical to the target market for PIv6. Nonsense.
Not often but sometimes I agree with Iljitsch, this is one of them. PI or no PI, PA or PI are completly irrelevant when we talk about the need for ULA-central or not. ULA-central will satisfy a need for non-routable address space that some bigger organization have. ULA-local are just a no go even with a 99,99999% chance of no collision at all. Or to put it in another context, renumbering or any change, experimentation or downtime of the infrastructure are just not an option when we´re talking about medicial/health related equipment.
so the debate comes down to why we want to put orgs on ULA-C space instead of just giving them PI space. No-brainer: ULA-C space doesn't use up routing table slots.
see above, PI or PA have nothing todo in the discussion of ULA-C or not. Site-local, the one that got deprecated would have suited OUR (where I work) just fine but it isn´t there so we need a replacement and ULA-C is what we would need.
If they're truly going to use it privately, they won't consume routing slots in the DFZ, and if they aren't they'll be using PIv6 anyways and won't have a need for ULA-C.
You are being ridiculous. There is no connection between ULA-C and PI. Everyone can get ULA, not everyone can get PI. And ULA is even more important for people who have PA because that way they can have their internal infrastructure on stable addresses even when their routable address space is renumbered. Also, with IPv4, it's very common to use RFC 1918 space for internal infrastructure that must not be reachable from the internet. It's much more convenient to use unroutable address space for this rather than routable address space that is filtered.
100% correct for the organization I work for. We have in fact several very seperated network. To use RIR space, PI or PA for all of them is simply a waste since we don´t need global reachability for it. We just need _UNIQUE_ address space so we can when the need arrise connect any of them together.
there is significant risk that ULA-C will end up not being "private" because there will be a set of ISPs that agree to route the space for a fee. If that set grows to critical mass, ULA-C will be no different than PIv6 anyways. I don't see the problem. We agree that routing ULA space is a bad idea. However, if someone is prepared to give me enough money to change my mind, how can that possibly be a problem? Or do you want to protect yourself from your own greed?
I only have one thing to say, so what if the ISP agrees to route them? RIR space, PI or PA, give _global_ routability. ULA-C or ULA-Local give us the option to interconnect some closed network together anyway we want AND know it won´t get routed global. -- ------------------------------ Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID roger@jorgensen.no | - IPv6 is The Key! -------------------------------------------------------
Thus spake "Roger Jørgensen" <roger@jorgensen.no>
On man, mai 28, 2007 14:30, Iljitsch van Beijnum wrote:
On 27-mei-2007, at 22:51, Stephen Sprunk wrote:
The vast majority of folks will be fine with ULA-L
Most people aren't very good with statistics, knowing for sure you have unique space is better than having just a 99.9999% probability that it's unique.
not really, I work a place where we just can´t have any more collision of address space, we have a few options and ULA- central is the best.
1.) get ula-central and know for sure we won´t get into this issue ever again.
Unless the central administrator(s) screw up. The odds of that are non-zero, you know; in fact, as long as there's humans involved it's safe to say the odds are higher than a ULA-L collision.
2.) administrate our own local version of ULA-central for the organization we co-operate with
Which is basically ULA-L, except that when someone new wants to join your private club, you'll need to spend a few seconds making sure they don't collide, and if they do (which is statistically unlikely, unless your club is on the scale of the public Internet) they'll need to renumber before they can join.
3.) get RIR-space with all the add on administration and documentation...
The documentation is minimal unless you need a block larger than the minimum size, and the administration would be the same either way.
For me, only option 1.) is a real option, the other two are just work-around since we don´t need global routing of the address space in question.
No, you've decided #1 is what you want, so you're downplaying its problems and potential harm to the community and criticizing all other options.
(or PA) space
PA or PI is irrelevant to this discussion, people who need ULA may not even connect to the internet, and if they do, they need this space in ADDITION to routable address space, regardless of the type.
this go for the type of organization I work for. We have our own /32 already and it suite our need for public address space just fine given the 3 options above.
So why not carve out a /48, block it at your firewall to the public network, and get "local" addresses for free instead of paying for ULA-C?
ULA-central will satisfy a need for non-routable address space that some bigger organization have. ULA-local are just a no go even with a 99,99999% chance of no collision at all. Or to put it in another context, renumbering or any change, experimentation or downtime of the infrastructure are just not an option when we´re talking about medicial/health related equipment.
If you're in the medical field and your equipment can't withstand a few seconds of outage here and there (six nines = 31sec/yr downtime) without killing someone, you're going to have a lot of dead people on your hands. You and/or your vendors have failed. Networks have outages, period. In a typical network, most of them will be hardware-, circuit-, or design-related. I participated in a project for $BIG_TELCO and it took them several years of effort just to get from three nines to five nines consistently, and they never hit six nines. Nearly all of the remaining issues, when we were done, were due to humans making typos. If you think you're going to get to six (or more) nines of reliability, you're delusional in thinking that you're better at this than people literally throwing billions of dollars and thousands of engineers at the problem. Besides, renumbering should not cause any outages (at least more than what you normally see) unless your staff is incompetent. It's a lot of work, but it shouldn't cause an outage, much less death.
so the debate comes down to why we want to put orgs on ULA-C space instead of just giving them PI space.
No-brainer: ULA-C space doesn't use up routing table slots.
see above, PI or PA have nothing todo in the discussion of ULA-C or not.
Yes, it does. If an org needs unique address space that will never appear in the DFZ, how does ULA-C meet their needs any better than PI? What is the purpose in creating yet another thing that needs to be registered when we already have two alternatives that fit every need I've seen proposed so far?
Site-local, the one that got deprecated would have suited OUR (where I work) just fine but it isn´t there so we need a replacement and ULA-C is what we would need.
If SLAs would have worked for you, then you have no fundamental need for unique addresses and ULA-Ls are overkill, much less ULA-C.
If they're truly going to use it privately, they won't consume routing slots in the DFZ, and if they aren't they'll be using PIv6 anyways and won't have a need for ULA-C.
You are being ridiculous. There is no connection between ULA-C and PI. Everyone can get ULA, not everyone can get PI.
Anyone who is large enough to care about the extreme unlikelihood of collisions with ULA-L will be able to get PI, at least in ARIN's region. The bar is incredibly low; just about the only folks who don't qualify are people running home networks. And, for that matter, people can get a single PI block larger than /48, whereas someone who needs more than a /48 in ULA-C space would need multiple distinct blocks, presumably multiplying the fees to more than what PI costs. If your argument is that ULA-C will be cheaper, that is perhaps an argument that PI fees are too high -- not that anyone has stated if or how much cheaper ULA-C would be if it did pass. I have a hard time seeing anyone who has a legitimate need for ULA-C _or_ PI space whining about $100/yr. If they can't afford that, they can't afford anyone knowledgeable enough to care about the problems with ULA-L (or PA) space. 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
ok, i give. if ula address space is assigned/managed by registries, how is it actually different from pi space? if ipv6 space is effectively infinite (and we once thought ipv4 space was), then what is the use of ula address space? why not just assign vanilla ipv6 space? i am very confused by all the smoke and am trying to find the core of this stuff. randy
Hi Randy,
ok, i give. if ula address space is assigned/managed by registries, how is it actually different from pi space?
Basically ULA space has the same 'routability' as RFC1918 space, with the added benefit of less (or in case of ULA central: no) possibility for conflicting addresses when merging/connecting separate networks. PI space is expected to be routed globally (if the user of the space wants to).
if ipv6 space is effectively infinite (and we once thought ipv4 space was), then what is the use of ula address space? why not just assign vanilla ipv6 space?
At this moment there is no IPv6 PI spa
ok, i give. if ula address space is assigned/managed by registries, how is it actually different from pi space? Basically ULA space has the same 'routability' as RFC1918 space
which is a benefit because ...? rfc 1918 space is a hack to deal with an address space shortage. we are told ipv6 space is effectively infinite. hence we do not need rfc 1918 style space.
with the added benefit of less (or in case of ULA central: no) possibility for conflicting addresses when merging/connecting separate networks.
because, in statistical hope, it will not overlap. i.e. it does not even conserve space a la 1918. so, again, what's the benefit?
PI space is expected to be routed globally (if the user of the space wants to).
as has been amply demonstrated, 1918 space leaks time and again. so this ula stuff will leak time and again.
if ipv6 space is effectively infinite (and we once thought ipv4 space was), then what is the use of ula address space? why not just assign vanilla ipv6 space? At this moment there is no IPv6 PI spa
so we do this kinky thing to create a half-assed version of it? pfui! randy
(Tony, what where the exact thoughts about the below) Randy Bush wrote:
ok, i give. if ula address space is assigned/managed by registries, how is it actually different from pi space? Basically ULA space has the same 'routability' as RFC1918 space
which is a benefit because ...? rfc 1918 space is a hack to deal with an address space shortage. we are told ipv6 space is effectively infinite. hence we do not need rfc 1918 style space.
The only 'real' benefit I heared up to now was iirc from Tony Hain who mentioned that it might in corporate cases be handy to be able to simply have ULA-Central space as the space that is used internally, and possibly by partner organizations linking in. Thus that you use fc00::/8 on internal + interconnected networks. While using other spaces on the internet (that big public thing). The main advantage is that firewalling becomes easier, as you know that space under fc00::/8 is internal and thus from another company. Splitting routing, doing firewalling etc thus becomes easier as you know what is public and what is not. [..]
PI space is expected to be routed globally (if the user of the space wants to).
as has been amply demonstrated, 1918 space leaks time and again. so this ula stuff will leak time and again.
ULA space should be !A'ed out by routers per default and have a special switch to enable forwarding for them. Security folks will be quite happy with that too I guess.
if ipv6 space is effectively infinite (and we once thought ipv4 space was), then what is the use of ula address space? why not just assign vanilla ipv6 space?
IMHO there should not be a distinction between "PI" and "PA" space. Both will be broken up into blocks for "Traffic Engineering" purposes and other such things anyway, as can already be seen in BGP today. It should all simply be 'address space' and the size of the block received from the RIR should be based on the amount of address space they can justify and where possible only 1 such block per organization. The latter is unrealistic too as when an organization breaks up they might want to split that block etc yadiyadi. The only folks who can really stop that from happening is the ISP's themselves. Any organization with enough cash or importance can get any block fairly well routed onto the Internet. Lots of ISP's will protest, but to keep customers they will bend over anyway. If an ISP wants to keep the number of routes they accept low, they can already do this easily by taking all the inet6num's which have been delegated directly from the RIR's and use those to build filters. Filter list will be insanely large, but then you have the minimum you want to accept. Currently the classification between PA/PI sort of helps there as PA is </32 and PI = </48. Then take Gerts filters and one is fine. At the moment though anyone can simply accept </48 and should not have any issues in table size yet. Greets, Jeroen
ULA space should be !A'ed out by routers per default and have a special switch to enable forwarding for them.
oh, site-local. i remember that disaster. no wonder the internet-draft was stuffed. as i just told someone else in private email. you are asking that routers hard code the association between routability and address space. and next you only want this at site border routers and not 'internal' routers. this was called site-local, and was soundly rejected as a disaster in the making. use global space and filter your routing announcements and packets. randy
Randy Bush wrote:
ULA space should be !A'ed out by routers per default and have a special switch to enable forwarding for them. oh, site-local. i remember that disaster. no wonder the internet-draft was stuffed.
RFC 1925 2(11) “Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works.” randy
Hi, On Mon, May 28, 2007 at 11:12:34PM -1000, Randy Bush wrote:
Randy Bush wrote:
ULA space should be !A'ed out by routers per default and have a special switch to enable forwarding for them. oh, site-local. i remember that disaster. no wonder the internet-draft was stuffed.
RFC 1925 2(11) ?Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works.?
Actually there is a difference - site-locals are not unique between different sites that might be linked privately, eventually. I wasn't there when site-local was killed, but from what I understand, the "uniqueness" and "where is a site border?" arguments where the ones that people had most issues with. ULAs do solve this - but indeed, having PI space easily available would take away the need for "give me internal addresses that I do not want to see globally routed". OTOH, folks are afraid of PI, so ULAs are a possible answer to the question "how can I get address space for internal use, which is never meant to be visible on 'the global Internet'?". I agree with you that any sort of "hard-code filter in router software" is something to recommend to your competition :-) (after all, even if ULAs are not supposed to be "globally" routable, they *are* supposed to be used for private connetions between enterprises, and how is the router supposed to tell the difference?). Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 113403 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
Randy, On Mon, May 28, 2007 at 10:26:19PM -1000, Randy Bush wrote:
ok, i give. if ula address space is assigned/managed by registries, how is it actually different from pi space? Basically ULA space has the same 'routability' as RFC1918 space
which is a benefit because ...? rfc 1918 space is a hack to deal with an address space shortage. we are told ipv6 space is effectively infinite. hence we do not need rfc 1918 style space.
The advantage of RFC 1918 space that ULA (non-central) provides is you don't have to talk to anyone to get your addresses. This is nice for things like labs, prototype environments, people who just want to use IPv6 within their home/office but don't have IPv6 connectivity, and so on. This advantage will get smaller over time, as most people will have a /48 from their Internet provider "by default", and can use that space for disconnected environments; 65536 is a lot of lab networks! :) There are no advantages to ULA (central), as I see it. Which is why I oppose it. -- Shane
[ arin dropped from cc:s as this is a local joke ]
The advantage of RFC 1918 space that ULA (non-central) provides is you don't have to talk to anyone to get your addresses.
italian isps seem to have figured out how to do that long ago :) randy
On 29-mei-2007, at 11:18, Shane Kerr wrote:
There are no advantages to ULA (central), as I see it. Which is why I oppose it.
It troubles me that so many people are willing to deprive others of something that those others consider useful just because they themselves don't find that thing useful. Quote from dr. Phil: "If your kid wakes up at night and says 'daddy I'm thirsty can I get some water' you don't say 'I'm not thirsty, you don't need water', you give the kid a glass of water. Everyone has different needs."
On Tue, May 29, 2007 at 11:31:14AM +0200, Iljitsch van Beijnum wrote:
On 29-mei-2007, at 11:18, Shane Kerr wrote:
There are no advantages to ULA (central), as I see it. Which is why I oppose it.
It troubles me that so many people are willing to deprive others of something that those others consider useful just because they themselves don't find that thing useful.
If something is not useful to me, but might be useful to others, I generally don't oppose it. But I do not think ULA central is useful to anyone. Even if ULA central is useful, I don't think it is something the RIRs need to be involved in. If you insist on ULA central, my preferred implementation is a web page where you click on a button that says "give me a ULA prefix" and it allocates a random prefix that is not in use, and prints it on the screen. The only implementation question I'm not sure about is whether the list of allocated prefixes would be public or not; I lean towards making it public, although there is a (small) privacy concern. I think the cost of this implementation is low enough you could find a group of volunteers to host the system. -- Shane
On 29-mei-2007, at 12:00, Shane Kerr wrote:
It troubles me that so many people are willing to deprive others of something that those others consider useful just because they themselves don't find that thing useful.
If something is not useful to me, but might be useful to others, I generally don't oppose it.
But I do not think ULA central is useful to anyone.
People have come out and said it's useful to them, so you are putting your judgment ahead of theirs.
Even if ULA central is useful, I don't think it is something the RIRs need to be involved in.
On that, we agree.
If you insist on ULA central, my preferred implementation is a web page where you click on a button that says "give me a ULA prefix" and it allocates a random prefix that is not in use, and prints it on the screen. The only implementation question I'm not sure about is whether the list of allocated prefixes would be public or not; I lean towards making it public, although there is a (small) privacy concern. I think the cost of this implementation is low enough you could find a group of volunteers to host the system.
I think a mechanism similar to IEEE MAC addresses would be good: organizations can buy a block for a price that's large enough to cover the costs of maintaining the IANA registry and also high enough to make sure people aren't going to buy unreasonable quantities ($/eu 1000 - 5000 or so for a block of a million /48s seems about right) and then the block holders can then redistribute the individual ULA prefixes in any way they see fit. Presumably, end-users would buy their prefixes from distributors that have a good system for enforcing uniqueness in place, but this can be traded off against other needs.
Shane Kerr wrote: [...]
If you insist on ULA central, my preferred implementation is a web page where you click on a button that says "give me a ULA prefix" and it allocates a random prefix that is not in use, and prints it on the screen. The only implementation question I'm not sure about is whether the list of allocated prefixes would be public or not; I lean towards making it public, although there is a (small) privacy concern. I think the cost of this implementation is low enough you could find a group of volunteers to host the system.
My take on this is that (general) ULA is supposed to provide access to "almost" unique prefixes. This can be managed in a distributed way. The "central" thing is supposed to take care of the 10^-<whatever> chance that your's is used by someone else, too. Thus it is only (more) useful (than general ULA) if the distribution environment can guarantee uniqueness. Such a guarantee involves management and review, and complaint handling - eventually, plus protection against DoS-Attempts and legal protection. I am not convinced that a simple (=cheap / for free) mechanism is "good enough".
-- Shane
Wilfried.
Agree, and in addition to that, I'm convinced that it is not good at all that somebody else different than the RIRs start allocating addresses. Regards, Jordi
De: "Wilfried Woeber, UniVie/ACOnet" <Woeber@CC.UniVie.ac.at> Organización: UniVie - ACOnet Responder a: <Woeber@CC.UniVie.ac.at> Fecha: Tue, 29 May 2007 11:08:49 +0000 Para: Shane Kerr <shane@time-travellers.org> CC: <ppml@arin.net>, "address-policy-wg@ripe.net" <address-policy-wg@ripe.net> Asunto: Re: [ppml] [address-policy-wg] Those pesky ULAs again
Shane Kerr wrote:
[...]
If you insist on ULA central, my preferred implementation is a web page where you click on a button that says "give me a ULA prefix" and it allocates a random prefix that is not in use, and prints it on the screen. The only implementation question I'm not sure about is whether the list of allocated prefixes would be public or not; I lean towards making it public, although there is a (small) privacy concern. I think the cost of this implementation is low enough you could find a group of volunteers to host the system.
My take on this is that (general) ULA is supposed to provide access to "almost" unique prefixes. This can be managed in a distributed way.
The "central" thing is supposed to take care of the 10^-<whatever> chance that your's is used by someone else, too. Thus it is only (more) useful (than general ULA) if the distribution environment can guarantee uniqueness.
Such a guarantee involves management and review, and complaint handling - eventually, plus protection against DoS-Attempts and legal protection. I am not convinced that a simple (=cheap / for free) mechanism is "good enough".
-- Shane
Wilfried.
********************************************** 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.
JORDI PALET MARTINEZ wrote:
Agree, and in addition to that, I'm convinced that it is not good at all that somebody else different than the RIRs start allocating addresses.
Regards, Jordi
Well, it depends.... As long as the operation (i.e. the resource access policies) of the RIRs is mostly influenced by the existing user community (ISPs and other *existing* stakeholders) I can understand people to argue in favour of establishing alternatives. But that is partially off-topic in this context. Wilfried.
If you insist on ULA central, my preferred implementation is a web page where you click on a button that says "give me a ULA prefix" and it allocates a random prefix that is not in use, and prints it on the screen.
sounds like a great idea for all of ipv6 allocation. what is the difference ula or pi/pa? randy
sounds like a great idea for all of ipv6 allocation. what is the difference ula or pi/pa?
Here's my take. ULAs are not intended to be publically routed by ISPs. While some may attempt to get ISPs to route them, ISPs will have clear documentation saying they are not intended to be used that way, and they are free to filter them. And in fact they SHOULD be filtered. (I'd say MUST, but since that is not enforceable...) We have ULAs already. What is missing is centralized ULAs. I've had enough conversations with people that want to use ULAs - but simply aren't satisfied with probalistic uniqueness. They want something more meaningful, like a signed contract that that can pay some fee for and get some assurance that no one else is going to get that address. This sort of thing makes business people happy. People do worry about collisions and the impact that would have. ULAs are intended to be much more easy to obtain than PI space, because PI space is intended to be publically routed. PI space, on the other hand, is not useful if it is not publically routed (generally speaking). Poeple obtaining PI space are very much assuming it will be publically routed. ULA space is useful even if not publically routed (and is intended for uses that do not require public routability). E.g., it can be used to number infrastructure devices, with assurance those addresses will not need to change the way public addresses might. Is ULA space the same as PI? Only if you want to give everybody and their brother PI space and don't care about what that does to the routing tables. I don't believe we can (or should) do that. And keep in mind, in IPv6 devices can have multiple addresses simultaneously. So it is quite possible to have ULA-C addresses in addition to public addresses. So having ULA-C addresses does not imply that those addresses have to be used for communicating with off-site destinations. Thomas
thomas, that's all nice. but please explain why this is technically any different and better than pi space. i keep remembering It's perfectly appropriate to be upset. I thought of it in a slightly different way--like a space that we were exploring and, in the early days, we figured out this consistent path through the space: IP, TCP, and so on. What's been happening over the last few years is that the IETF is filling the rest of the space with every alternative approach, not necessarily any better. Every possible alternative is now being written down. And it's not useful. -- Jon Postel
Thus spake "Thomas Narten" <narten@us.ibm.com>
sounds like a great idea for all of ipv6 allocation. what is the difference ula or pi/pa?
Here's my take.
ULAs are not intended to be publically routed by ISPs. While some may attempt to get ISPs to route them, ISPs will have clear documentation saying they are not intended to be used that way, and they are free to filter them. And in fact they SHOULD be filtered. (I'd say MUST, but since that is not enforceable...)
ISPs SHOULD filter RFC 1918 space, but many don't. If it weren't for the collision issue, you'd be able to get to a heck of a lot of "private" networks.
We have ULAs already. What is missing is centralized ULAs. I've had enough conversations with people that want to use ULAs - but simply aren't satisfied with probalistic uniqueness. They want something more meaningful, like a signed contract that that can pay some fee for and get some assurance that no one else is going to get that address. This sort of thing makes business people happy. People do worry about collisions and the impact that would have.
The RIRs are happy to sign a contract and take a fee to issue unique address space -- it's called PI. All you're going to do is make the RIRs allocate single-sized blocks out of fc00::/8 instead of 2000::/3, creating a v6 swamp that will inherit all of the problems of the v4 swamp. There is absolutely nothing else different about the addresses you propose handing out, except you _hope_ that ISPs won't route them (much) and you _hole_ that the RIRs will set the requirements and fees lower. The policy process can't guarantee the former and may not deliver the latter; OTOH, it could just as easily deliver the latter for PI if desired.
ULAs are intended to be much more easy to obtain than PI space, because PI space is intended to be publically routed.
If PI is tough to get from your RIR, change the policy. ARIN makes getting PIv6 space trivial for a minimum-sized request (the same size you'd get with ULA) and even has explicit policy stating that requests for private use are valid (though, for v4, RFC1918 is encouraged). We have no shortage of address space in v6; policies that discourage PI are _only_ justified to the extent they are needed to keep routing table growth under control. In the case of private use, that limitation doesn't apply since anyone who _really_ intends their block to be for private use won't consume a global routing slot.
PI space, on the other hand, is not useful if it is not publically routed (generally speaking). Poeple obtaining PI space are very much assuming it will be publically routed.
PI space is useful for anything that needs a globally-unique address that isn't tied to a provider. Whether you advertize it (or portions of it) publicly is up to you. The same would be true for ULA-C, except there's an upproven theory that many people won't accept the route.
ULA space is useful even if not publically routed (and is intended for uses that do not require public routability). E.g., it can be used to number infrastructure devices, with assurance those addresses will not need to change the way public addresses might.
Ditto for PI. 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
ULAs are not intended to be publically routed by ISPs. While some may attempt to get ISPs to route them, ISPs will have clear documentation saying they are not intended to be used that way, and they are free to filter them. And in fact they SHOULD be filtered. (I'd say MUST, but since that is not enforceable...)
Should ULA-C be published in the Whois database? what about reverse DNS for them, should they be delegated or just reply a NXDOMAIN? Roque ------------------------------------------------------------- Roque Gagliano ANTEL - URUGUAY rgaglian@antel.net.uy
Should ULA-C be published in the Whois database? what about reverse DNS for them, should they be delegated or just reply a NXDOMAIN?
let's see. ula-c should be assigned and tracked by rirs. they should have whois and in-addr.arpa. do remind me how they differ from pi space. i keep forgetting. randy
more "practical" questions: why should they be cheaper than PI block? do they take less administrative work form RIR? do they take less "space" in their databases? in many RIRs you need to pay a "membership" fee and doing so you get the right to vote in their members meetings, if you get an ULA-C allocation, should you be considered a member? would you pay your membership fee to the RIR? again, why should this allocation be cheaper that a PI allocation? Roque On Jun 7, 2007, at 10:54 AM, Randy Bush wrote:
Should ULA-C be published in the Whois database? what about reverse DNS for them, should they be delegated or just reply a NXDOMAIN?
let's see. ula-c should be assigned and tracked by rirs. they should have whois and in-addr.arpa. do remind me how they differ from pi space. i keep forgetting.
randy
------------------------------------------------------------- Roque Gagliano ANTEL - URUGUAY rgaglian@antel.net.uy
Wouldn't it be nice if we had a ULA bit or two to play with in the BGP announcements? Then everyone could define their own.. I know this is facetious and not a serious consideration, but it was an interesting thought.. ________________________________ From: ppml-bounces@arin.net [mailto:ppml-bounces@arin.net] On Behalf Of Roque Gagliano Sent: Thursday, June 07, 2007 8:57 AM To: Randy Bush Cc: Thomas Narten; ppml@arin.net; address-policy-wg@ripe.net Subject: Re: [ppml] [address-policy-wg] Those pesky ULAs again more "practical" questions: why should they be cheaper than PI block? do they take less administrative work form RIR? do they take less "space" in their databases? in many RIRs you need to pay a "membership" fee and doing so you get the right to vote in their members meetings, if you get an ULA-C allocation, should you be considered a member? would you pay your membership fee to the RIR? again, why should this allocation be cheaper that a PI allocation? Roque On Jun 7, 2007, at 10:54 AM, Randy Bush wrote: Should ULA-C be published in the Whois database? what about reverse DNS for them, should they be delegated or just reply a NXDOMAIN? let's see. ula-c should be assigned and tracked by rirs. they should have whois and in-addr.arpa. do remind me how they differ from pi space. i keep forgetting. randy ------------------------------------------------------------- Roque Gagliano ANTEL - URUGUAY rgaglian@antel.net.uy
Hi Roque, This is something that never is defined by the policies. It is up to the board to decide and I'm fine with board decisions on this. If you don't, they you should make sure to select a different board composition next time :-). Regards, Jordi De: Roque Gagliano <rgaglian@antel.net.uy> Responder a: <ppml-bounces@arin.net> Fecha: Thu, 7 Jun 2007 10:56:32 -0300 Para: Randy Bush <randy@psg.com> CC: Thomas Narten <narten@us.ibm.com>, <ppml@arin.net>, <address-policy-wg@ripe.net> Asunto: Re: [ppml] [address-policy-wg] Those pesky ULAs again more "practical" questions: why should they be cheaper than PI block? do they take less administrative work form RIR? do they take less "space" in their databases? in many RIRs you need to pay a "membership" fee and doing so you get the right to vote in their members meetings, if you get an ULA-C allocation, should you be considered a member? would you pay your membership fee to the RIR? again, why should this allocation be cheaper that a PI allocation? Roque On Jun 7, 2007, at 10:54 AM, Randy Bush wrote:
Should ULA-C be published in the Whois database? what about reverse DNS for them, should they be delegated or just reply a NXDOMAIN?
let's see. ula-c should be assigned and tracked by rirs. they should have whois and in-addr.arpa. do remind me how they differ from pi space. i keep forgetting.
randy
------------------------------------------------------------- Roque Gagliano ANTEL - URUGUAY rgaglian@antel.net.uy _______________________________________________ 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.
Should ULA-C be published in the Whois database? what about reverse DNS for them, should they be delegated or just reply a NXDOMAIN?
let's see. ula-c should be assigned and tracked by rirs. they should have whois and in-addr.arpa. do remind me how they differ from pi space. i keep forgetting.
while i'm uncomfortable with randy's tone here, i agree with his concern. the difference between pi and ula has been given as "not intended to be routed in the DFZ". this means a pi prefix can be routed privately, as for example among cooperating BGP peers at an IX, or between companies involved in private relationships such as banking or manufacturing, and of course, it will mean that "merge/acquire" no longer implies "renumber the RFC1918's on one or both sides". but since we could never possibly fit all of ipv6 into the DFZ, and since the cost and availability of pi is theoretically manageable by us (the RIR system) to make sure everybody who needs it can get and can afford it, i fail to see the virtue of making some of it cheaper and worth less. this whole argument has helped me understand that there is a policy hole but that "unroutable" isn't it. if the RIR system had multiple high order prefixes (IPv6 /10's or whatever) to allocate from, with a minimum length policy that varied, then global static route-ingress filters could be set that would outlaw TE routes, which are the major source of DFZ bloat, way over the top compared to SMB PI routes. i think i oppose ula simply because there's no way to define "local" in a way that will serve a network's needs throughout its probable life cycle, except in the case where RFC1918 (or IPv6 "site local") would have served.
On Thu, 7 Jun 2007, Paul Vixie wrote:
Should ULA-C be published in the Whois database? what about reverse DNS for them, should they be delegated or just reply a NXDOMAIN? let's see. ula-c should be assigned and tracked by rirs. they should have whois and in-addr.arpa. do remind me how they differ from pi space. i keep forgetting. while i'm uncomfortable with randy's tone here, i agree with his concern. the difference between pi and ula has been given as "not intended to be routed in the DFZ". this means a pi prefix can be routed privately, as for example among cooperating BGP peers at an IX, or between companies involved in private relationships such as banking or manufacturing, and of course, it will mean that "merge/acquire" no longer implies "renumber the RFC1918's on one or both sides".
but since we could never possibly fit all of ipv6 into the DFZ, and since the cost and availability of pi is theoretically manageable by us (the RIR system) to make sure everybody who needs it can get and can afford it, i fail to see the virtue of making some of it cheaper and worth less.
Well, I was really in favour of ULA-C but now given some time and after listning to all of the arguments, and maybe most important I realized one huge thing that ULA-C maybe can't provide, DNS, which leave it useless for our usage. Without reverse DNS possibility ULA-C is useless. On the other hand, why do we need PI? What we need is a policy that make sure those that could gain from ULA-C can get public routable IP space, and then they can themself decide if they want to route it or not. It's possible and upto them. If we have to call it PI then so be it... I really dislike the name but I can live with it. -- ------------------------------ Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID roger@jorgensen.no | - IPv6 is The Key! -------------------------------------------------------
but since we could never possibly fit all of ipv6 into the DFZ, and since the cost and availability of pi is theoretically manageable by us (the RIR system) to make sure everybody who needs it can get and can afford it, i fail to see the virtue of making some of it cheaper and worth less.
Well, I was really in favour of ULA-C but now given some time and after listning to all of the arguments, and maybe most important I realized one huge thing that ULA-C maybe can't provide, DNS, which leave it useless for our usage.
Without reverse DNS possibility ULA-C is useless.
i agree, but i think that the implications of your statement are very telling. if these addresses really did correspond to "private" networks, then reverse dns could be managed with cutouts, much as is done for RFC 1918 in-addrs now. but since we all expect that these "private" networks will be interconnected among private (non-transit) relationships, we know that the entity seeing one of these "private" addresses and needing to know the PTR for it may not have a direct relationship to the owner of the network using the address. that's another way of saying that these addresses are not actually private, or local; the fact that they aren't intended to be carried in the DFZ matters not at all.
On the other hand, why do we need PI? What we need is a policy that make sure those that could gain from ULA-C can get public routable IP space, and then they can themself decide if they want to route it or not. It's possible and upto them.
If we have to call it PI then so be it... I really dislike the name but I can live with it.
for this discussion, i think we should forget about the distinction between PI and PA, which only make sense when there is a "provider." perhaps the automotive exchange network will be an LIR for assigning network numbers to its members, or perhaps not. the term we've probably been looking for is UA (unique address, or universal address) in comparison to IPv6 "site local" or IPv4 RFC1918 (which are nonunique and nonuniversal; sometimes "ambiguous"). everybody needs UA, whether they have a provider or not. some UA's will be in the DFZ and some not, according to the business needs of the network owner. one of those business needs is "nobody will route PI UA for me" or "the cost of routing PI UA is very high" and so, some UA will be PA UA. that's not a RIR issue per se, other than that it may drive policy toward smaller/cheaper UA allocations which all come from some particular /10 so that draconian DFZ router operators can reject these routes if they don't originate in peers.
On the other hand, why do we need PI?
There are many reasons. That the prefix is routable on the internet is however not always a requirement by the requester. The RIRs could make that as an option when requesting space. It would surely be easier to get PI space if it didn’t have to be routable (on the internet). There could be different requirements for this. j -----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Roger Jorgensen Sent: 8. juni 2007 18:44 To: Paul Vixie Cc: ppml@arin.net; address-policy-wg@ripe.net; roger@jorgensen.no Subject: Re: [ppml] [address-policy-wg] Those pesky ULAs again On Thu, 7 Jun 2007, Paul Vixie wrote:
Should ULA-C be published in the Whois database? what about reverse DNS for them, should they be delegated or just reply a NXDOMAIN? let's see. ula-c should be assigned and tracked by rirs. they should have whois and in-addr.arpa. do remind me how they differ from pi space. i keep forgetting. while i'm uncomfortable with randy's tone here, i agree with his concern. the difference between pi and ula has been given as "not intended to be routed in the DFZ". this means a pi prefix can be routed privately, as for example among cooperating BGP peers at an IX, or between companies involved in private relationships such as banking or manufacturing, and of course, it will mean that "merge/acquire" no longer implies "renumber the RFC1918's on one or both sides".
but since we could never possibly fit all of ipv6 into the DFZ, and since the cost and availability of pi is theoretically manageable by us (the RIR system) to make sure everybody who needs it can get and can afford it, i fail to see the virtue of making some of it cheaper and worth less.
Well, I was really in favour of ULA-C but now given some time and after listning to all of the arguments, and maybe most important I realized one huge thing that ULA-C maybe can't provide, DNS, which leave it useless for our usage. Without reverse DNS possibility ULA-C is useless. On the other hand, why do we need PI? What we need is a policy that make sure those that could gain from ULA-C can get public routable IP space, and then they can themself decide if they want to route it or not. It's possible and upto them. If we have to call it PI then so be it... I really dislike the name but I can live with it. -- ------------------------------ Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID roger@jorgensen.no | - IPv6 is The Key! -------------------------------------------------------
Should ULA-C be published in the Whois database? what about reverse DNS for them, should they be delegated or just reply a NXDOMAIN?
let's see. ula-c should be assigned and tracked by rirs. they should have whois and in-addr.arpa. do remind me how they differ from pi space. i keep forgetting.
Oh, they differ because they are supposedly "not routeable on the public big-I Internet" because "they will be filtered away by ISPs". However, I suspect you are perhaps hinting that when a sufficient number of organizations have been given ULA-C addresses, the pressure on ISPs is going to be like "oh, pretty please, for this amount of $$$, can you please route these ULA-C addresses for me across your network", and after a while with the sheer meat- weight of all the sloppily-handed-out ULA-C addresses, we will have re-created the swamp from IPv4 (192/8)? Regards, - Håvard
Havard Eidnes wrote:
[...] we will have re-created the swamp from IPv4 (192/8)?
By introducing ipv6 PI, we are already committing to reproduce a routing swamp, albeit with defined borders (which will allow reasonable length-based prefix filtering). ULA-C would simply be another similarly defined swamp area, of limited reachability and therefore of limited use. Sure, you're going to get a couple of organisation crazeee enough to want to advertise this space. If they're stupid enough to want their business model depend on a completely broken engineering model, let them go ahead with it and see how far it gets them. Nick
On Jun 7, 2007, at 8:47 AM, Havard Eidnes wrote:
we will have re-created the swamp from IPv4 (192/8)?
Oh, we've already done that. And, I suspect, recreated the class As as well. Rgds, -drc
There are no advantages to ULA (central), as I see it. Which is why I oppose it. It troubles me that so many people are willing to deprive others of something that those others consider useful just because they themselves don't find that thing useful.
nice emotional argument. all it lacks are technology and facts
On May 29, 2007, at 2:31 AM, Iljitsch van Beijnum wrote:
On 29-mei-2007, at 11:18, Shane Kerr wrote:
There are no advantages to ULA (central), as I see it. Which is why I oppose it.
It troubles me that so many people are willing to deprive others of something that those others consider useful just because they themselves don't find that thing useful.
Quote from dr. Phil: "If your kid wakes up at night and says 'daddy I'm thirsty can I get some water' you don't say 'I'm not thirsty, you don't need water', you give the kid a glass of water. Everyone has different needs."
Right, but, if your kid wakes up at night and says "Daddy, I've got a hankering to blow stuff up. Can I get a grenade?" You don't just hand the kid a live grenade, whether you like to blow stuff up or not. Most of the opposition to ULA-C is because we see real downsides to it and don't see ANY upsides. Advantages of ULA-C (even to those who claim there are some): Virtually none. Some minor configuration convenience if a number of unsubstantiated assumptions are hard-coded into routers. Disadvantages of ULA-C: Nothing prevents it from becoming another form of provider-independent routed space on the internet. The policies for ULA-C are likely to be different from the policies for PI. If both address spaces function in an equivalent manner and have different policies to obtain/maintain the addresses, then the policy mechanism is undermined. etc. Owen _______________________________________________ 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
On 29-mei-2007, at 18:40, Owen DeLong wrote:
Advantages of ULA-C (even to those who claim there are some): Virtually none.
I'm sure you don't mind the plane renumbering in flight when it switches from one satellite connection to the next. Myself, I'd like to see the flight systems to have stable addressing regardless of the orientation of the satellite antennas.
Disadvantages of ULA-C:
I can't believe you keep pounding on this dead horse. These are PRIVATE addresses. Period.
On May 29, 2007, at 11:58 AM, Iljitsch van Beijnum wrote:
On 29-mei-2007, at 18:40, Owen DeLong wrote:
Advantages of ULA-C (even to those who claim there are some): Virtually none.
I'm sure you don't mind the plane renumbering in flight when it switches from one satellite connection to the next. Myself, I'd like to see the flight systems to have stable addressing regardless of the orientation of the satellite antennas.
I'm not seeing something here. Wouldn't the plane have an IP address given to it from the airline? If the airline needs to renumber, wouldn't they would do it in stages -- as planes land?
On 29-mei-2007, at 19:09, Scott Nelson wrote:
Advantages of ULA-C (even to those who claim there are some): Virtually none.
I'm sure you don't mind the plane renumbering in flight when it switches from one satellite connection to the next. Myself, I'd like to see the flight systems to have stable addressing regardless of the orientation of the satellite antennas.
I'm not seeing something here. Wouldn't the plane have an IP address given to it from the airline? If the airline needs to renumber, wouldn't they would do it in stages -- as planes land?
If you number the planes from the airline's address space, you need to keep rerouting those address blocks for the planes continuously as the plane flies around. It's really hard to make that work well, and the airline probably needs some kind of world-wide private network to do it. It makes much more sense to give the parts of the plane that need connectivity addresses that are tied to the connection they happen to have at any point in time. I.e., when it's in the air the passengers can email through a satellite link, when it's on the ground the service people can access the plane's systems for maintenance. But you really want the different systems in the plane to be able to talk to each other regardless of what external connectivity there is and regardless of any addressing such connectivity brings with it.
On Tue, May 29, 2007 at 06:58:47PM +0200, Iljitsch van Beijnum wrote:
Advantages of ULA-C (even to those who claim there are some): Virtually none.
I'm sure you don't mind the plane renumbering in flight when it switches from one satellite connection to the next. Myself, I'd like to see the flight systems to have stable addressing regardless of the orientation of the satellite antennas.
Disadvantages of ULA-C:
I can't believe you keep pounding on this dead horse. These are PRIVATE addresses. Period.
Uh, neither of those reasons undermines the solution others have proposed: use PI space. You can always just not announce some part (or all) of your space. That would make it private. ULA-C sounds to me like a request to the guys who spin silicon to help people keep from screwing up their router configs. If someone can't manage to filter their BGP such that they keep some (or all) of their space private, I don't see why Cisco, Juniper, et al., need to do that for them. -David
ULA-C sounds to me like a request to the guys who spin silicon to help people keep from screwing up their router configs. If someone can't manage to filter their BGP such that they keep some (or all) of their space private, I don't see why Cisco, Juniper, et al., need to do that for them.
or that the router vendors will do a more reliable job of it, given the complexity of knowing what is a site border and what is not, especially when folk are saying that there are actually multiple entities inside the border. and do we really want the vendors to hard-code address filters in the sillycone? this is the path on which site-local died, and the death was a good thing. RFC 1925 2(11) “Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works.” randy
On 29-mei-2007, at 19:25, David Williamson wrote:
Disadvantages of ULA-C:
I can't believe you keep pounding on this dead horse. These are PRIVATE addresses. Period.
Uh, neither of those reasons undermines the solution others have proposed: use PI space.
That's like saying people can use real money instead of monopoly money. I really don't get this. Did you guys bet a lot of money that there would never be ULA-C or something? If you don't like it, don't use it yourself and filter it, but PLEASE don't whine about it.
On May 29, 2007, at 10:32 AM, Iljitsch van Beijnum wrote:
On 29-mei-2007, at 19:25, David Williamson wrote:
Disadvantages of ULA-C:
I can't believe you keep pounding on this dead horse. These are PRIVATE addresses. Period.
Uh, neither of those reasons undermines the solution others have proposed: use PI space.
That's like saying people can use real money instead of monopoly money. I really don't get this. Did you guys bet a lot of money that there would never be ULA-C or something?
Um, no. It's like saying that counterfeit money is bad and we'd rather not create a sponsored system for printing it. Oh, wait, the treasury department (at least in the US, and, I'm betting whoever is the responsible agency in most other governments) feels that way.
If you don't like it, don't use it yourself and filter it, but PLEASE don't whine about it.
That's like saying if you don't like counterfeit currency, don't use it yourself, but, don't complain about the damage it does to your economy. Right. Owen
On 29-mei-2007, at 19:38, Owen DeLong wrote:
Uh, neither of those reasons undermines the solution others have proposed: use PI space.
That's like saying people can use real money instead of monopoly money. I really don't get this. Did you guys bet a lot of money that there would never be ULA-C or something?
Um, no. It's like saying that counterfeit money is bad and we'd rather not create a sponsored system for printing it.
Your view that ULA-C is like counterfeit money while it's more like monopoly money nicely illustrates the entire point (or rather, pointlessness) of this discussion. On 29-mei-2007, at 19:39, David Williamson wrote:
If you don't like it, don't use it yourself and filter it, but PLEASE don't whine about it.
Calling a debate "whining" is a bit rude.
Whether DHCPv6 is better than stateless autoconfiguration is a debate. The people who think DHCPv6 is the way to go are wrong, but there is no harm in them thinking that: they can run DHCPv6 while I run stateless autoconfig and everyone is happy. The whole ULA-C thing is not a debate. The anti-group is trying to wear the pro-group down by repeating the same few arguments that don't make a whole lot of sense over and over, and try to deprive the pro-group from something that group feels is useful based on fear, uncertainty and doubt. It's bullying.
My "whining" isn't intended to change your mind - I don't think any argument I make is likely to do that. My argument, however, is that there's no problem solved by ULA-C that can't be solved by PI space,
That's not really true, because ULA is recognizable as such, while PI space is presumed to be routable, even if routing it isn't desired. But more importantly, ULA-C would be exceedingly easy to get, while PI is exceedingly hard to get.
and the creation of ULA-C would entirely undermine the RIR-based PI system.
If only that were true. Unaggregatable PI is something we know can't work if widely deployed. But the realities of the RIR system are such that this is irrelevant. The only way ULA-C can effectively become PI is if everyone (for a large value of "everyone") accepts those advertisements. That will only happen if everyone thinks its a good idea, i.e., when you guys change your mind. Since there doesn't seem to be much danger of that happening (and people like me, who are also quite stubborn, are also against this) I don't see the problem. And IF we all change our minds, then obviously we'd have a good reason for that, wouldn't we?
If you seriously think that ULA-C is entirely orthogonal to PI space, and will have zero impact on the usage of PI space...well...we'll have to agree to disagree.
You can agree to disagree on things that are a matter of opinion or believe. You can't agree to disagree on an engineering decision with global impact.
All of this, of course, distracts from the real underlying problem, as Mr. Vixie points out.
Identifier/locator split, you mean? There was no way they could have designed and implemented that successfully 25 years ago: not enough giants to stand on the shoulders of. We can probably do those parts now, but I'm not so sure about being able to deploy it, and if it's actually going to buy us something if we manage that.
On Tue, May 29, 2007 at 08:59:15PM +0200, Iljitsch van Beijnum wrote:
But more importantly, ULA-C would be exceedingly easy to get, while PI is exceedingly hard to get.
I wasn't going to post again today to this list, but I cannot let blatantly incorrect statements go by. PI is not hard to get, although your experience may vary by region. My org holds a PI /48, and it took me 2 days of duration and ten minutes of effort to receive it. That's nearly trivial, in my book. -David
Agree, in ARIN region is not difficult to get, but in other two regions (LACNIC and RIPE NCC) is still impossible. However more difference to point to is that using PI for a function such as the one covered by ULA-Central is wasting space. It seems to me that this is quite contradictory for those folks that decided that /48 is too much for end sites and wanted to change it to /56. Some seems to be in favor of not "wasting" space, but when it comes to ULA-Central, the saving part is the less important one, even if implementing ULA-central will not damage at all to those that don't want to use it. Regards, Jordi
De: David Williamson <dlw+arin@tellme.com> Responder a: <ppml-bounces@arin.net> Fecha: Tue, 29 May 2007 12:08:02 -0700 Para: Iljitsch van Beijnum <iljitsch@muada.com> CC: ARIN PPML <ppml@arin.net>, "address-policy-wg@ripe.net" <address-policy-wg@ripe.net> Asunto: Re: [ppml] [address-policy-wg] Those pesky ULAs again
On Tue, May 29, 2007 at 08:59:15PM +0200, Iljitsch van Beijnum wrote:
But more importantly, ULA-C would be exceedingly easy to get, while PI is exceedingly hard to get.
I wasn't going to post again today to this list, but I cannot let blatantly incorrect statements go by. PI is not hard to get, although your experience may vary by region. My org holds a PI /48, and it took me 2 days of duration and ten minutes of effort to receive it. That's nearly trivial, in my book.
-David _______________________________________________ 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.
Thus spake "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
Agree, in ARIN region is not difficult to get, but in other two regions (LACNIC and RIPE NCC) is still impossible.
However more difference to point to is that using PI for a function such as the one covered by ULA-Central is wasting space.
How is using a PI /48 any more or less wasteful than a ULA-C /48? If anything, there is less ULA space (currently /7) available than PI space (currently /3) so we should be more concerned about waste in ULA land. Creating a new type of address space for "private" use just because some companies are too lazy to figure out how to configure their firewalls (which don't even exist yet) is not good engineering. 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
aside from the difficulties pointed out during this thread regarding enforcement of ULA terms vs. PI terms, there are two other things that prevent me from thinking well of ULA. first, ARIN does not currently consider routability when allocating address space. non-routable space comes from ietf/iana, not the RIRs. so, for ARIN to start allocating nonroutable space is a big change. we would have to define "routable", we could face implied liability for routability on "normal address space" (even if we continue to disclaim it in the NRPM as we do now), and we would then walk the slippery slope of the changing definition "largest" with respect to breidbart's maxim: >> But what *IS* the internet? > It's the largest equivalence class in the reflexive transitive > symmetric closure of the relationship "can be reached by an IP > packet from". --Seth Breidbart second, even with the rampant EUI64 wastage of the bottom 64 bits of the IPv6 address space, there's still a lot of space, and it's not hard to get. it's perfectly reasonable for all addresses to be unique even if some are never expected to be "routed" or are only "privately routed" or whatever. so while i think that ietf/iana ought to allocate a "private" block of space for IPv6 since a lot of the world loves their IPv4 NAT and wants to be able to do the same thing with IPv6, one block ought to be enough. (heck, maybe the old site-local prefix is still available.)
On 30-mei-2007, at 18:22, Paul_Vixie@isc.org wrote:
first, ARIN does not currently consider routability when allocating address space.
Hm: http://www.arin.net/policy/nrpm.html 6.3.4. Aggregation Wherever possible, address space should be distributed in a hierarchical manner, according to the topology of network infrastructure. This is necessary to permit the aggregation of routing information by ISPs, and to limit the expansion of Internet routing tables. This goal is particularly important in IPv6 addressing, where the size of the total address pool creates significant implications for both internal and external routing. The whole "routing is not guaranteed" thing is obviously in there because of the lawyers since ARIN can't force ISPs to route any given block of address space, not because routability isn't a goal.
non-routable space comes from ietf/iana, not the RIRs. so, for ARIN to start allocating nonroutable space is a big change.
Keeping the RIRs out of the ULA business would nicely avoid any problems resulting from that. Just let the domain sell the ip6.arpa domains in question.
(heck, maybe the old site-local prefix is still available.)
http://www.ietf.org/rfc/rfc3879.txt Existing implementations and deployments MAY continue to use this prefix.
The whole "routing is not guaranteed" thing is obviously in there because of the lawyers since ARIN can't force ISPs to route any given block of address space, not because routability isn't a goal.
yes. but also because of the other part of my text, which you didn't include in your reply so i don't know whether you agreed with it or not:
... we would have to define "routable", we could face implied liability for routability on "normal address space" (even if we continue to disclaim it in the NRPM as we do now), and we would then walk the slippery slope of the changing definition "largest" with respect to breidbart's maxim:
>> But what *IS* the internet? > It's the largest equivalence class in the reflexive transitive > symmetric closure of the relationship "can be reached by an IP > packet from". --Seth Breidbart in other words, the definition of "routable" depends on who you want to be able to exchange packets with. if three networks are numbered in 10.1/16, 10.2/16, and 10.3/16, and they interconnect, then that address space is "routable" for *some* definition of "routable". i don't think we want to have to define, and then live with the implications of, the word "routable".
non-routable space comes from ietf/iana, not the RIRs. so, for ARIN to start allocating nonroutable space is a big change.
Keeping the RIRs out of the ULA business would nicely avoid any problems resulting from that. Just let the domain sell the ip6.arpa domains in question.
see above. dunno why you didn't read it the first time i posted it here but i've posted it again and added some explaination. "universal" or "unique" we know the definition of. "local" and "routable", not so much so.
On 1-jun-2007, at 19:00, Paul Vixie wrote:
yes. but also because of the other part of my text, which you didn't include in your reply so i don't know whether you agreed with it or not:
... we would have to define "routable", we could face implied liability for routability on "normal address space" (even if we continue to disclaim it in the NRPM as we do now), and we would then walk the slippery slope of the changing definition "largest" with respect to breidbart's maxim:
But what *IS* the internet? It's the largest equivalence class in the reflexive transitive symmetric closure of the relationship "can be reached by an IP packet from". --Seth Breidbart
in other words, the definition of "routable" depends on who you want to be able to exchange packets with.
I'm not sure if I agree that there is a potential liability, but then, I'm not a lawyer, I don't play one on TV and the legal system where I live is quite different from that where ARIN is. The question of what "routability" is is not one that I'm interested in. We know what this means today, massaging the definition to fit a particular purpose can only lead to suboptimal results.
"local" and "routable", not so much so.
Ok, if that makes you happy: Routable address space: any block of global unicast address space that when announced through or by an internet service provider, allows the holder to receive packets addressed to the addresses in question from all possible sources connected to the internet without additional effort. ULA fails this test because it falls outside the global unicast block and because announcing it to one ISP isn't enough to receive packets from all over the world because people will filter.
in other words, the definition of "routable" depends on who you want to be able to exchange packets with.
... The question of what "routability" is is not one that I'm interested in. We know what this means today, massaging the definition to fit a particular purpose can only lead to suboptimal results.
we do not know, for the purpose of understanding and implementing a ULA policy, what "routability" means today. your lack of interest in it is not going to advance the debate as to whether ULA is a good or bad policy.
"local" and "routable", not so much so.
Ok, if that makes you happy:
Routable address space: any block of global unicast address space that when announced through or by an internet service provider, allows the holder to receive packets addressed to the addresses in question from all possible sources connected to the internet without additional effort.
"the internet"? let me quote this again in case you missed it the last two times: >> But what *IS* the internet? > It's the largest equivalence class in the reflexive transitive > symmetric closure of the relationship "can be reached by an IP > packet from". --Seth Breidbart smaller private connectivity domains would only depend on uniqueness among their participants. are you trying to make a definition of "routable" that depends on which connectivity domain the observer is actually in? or would it be enough to say "the connectivity domain that ARIN's members all share"?
ULA fails this test because it falls outside the global unicast block and because announcing it to one ISP isn't enough to receive packets from all over the world because people will filter.
so the routability of an address block can also depend on filters? (and perhaps on firewalls?) and is an address block that's "routable" today capable of being "unroutable" tomorrow? and if it's "routable" according to network X, can it be "unroutable" according to network Y? i can't imagine how a policy with these dependencies would be implemented. which is precisely the point i'm trying to make. the RIR system can guaranty uniqueness among RIR allocations, but can make no assertions either way as to "routability". since any definition of ULA depends on a definition of "routable", i think this slope is too slippery for us.
On 2-jun-2007, at 2:02, Paul Vixie wrote:
smaller private connectivity domains would only depend on uniqueness among their participants. are you trying to make a definition of "routable" that depends on which connectivity domain the observer is actually in? or would it be enough to say "the connectivity domain that ARIN's members all share"?
How did we get from routability tto uniqueness? "uniqueness among their participants" doesn't sound so bad until people start participating in multiple connectivity domains. I don't want to fumble the math so I'll spare you (and myself), but you get in the situation where there is overlap really fast. Also, in computer science there are only three numbers: 0, 1 and many. If we need more than one block of private space to avoid collisions, the obvious choice is to have as many blocks as there are domains.
ULA fails this test because it falls outside the global unicast block and because announcing it to one ISP isn't enough to receive packets from all over the world because people will filter.
so the routability of an address block can also depend on filters? (and perhaps on firewalls?) and is an address block that's "routable" today capable of being "unroutable" tomorrow? and if it's "routable" according to network X, can it be "unroutable" according to network Y?
Don't pretend this is news to you. Ever tried to cat herd? Herding network operators is even worse.
i can't imagine how a policy with these dependencies would be implemented.
Hence the "routability not guaranteed" disclaimer.
which is precisely the point i'm trying to make. the RIR system can guaranty uniqueness among RIR allocations, but can make no assertions either way as to "routability". since any definition of ULA depends on a definition of "routable", i think this slope is too slippery for us.
As I said before, if ARIN feels it should only give out "hopefully routable" address space like it does today, no problem, let other people give out ULA-C space. But ARINs definition issues don't preclude the usefulness of ULA-C.
How did we get from routability tto uniqueness?
uniqueness is the RIR goal for allocations today. routability is a new idea that would have to be seriously investigated to make ULA allocations possible.
"uniqueness among their participants" doesn't sound so bad until people start participating in multiple connectivity domains. I don't want to fumble the math so I'll spare you (and myself), but you get in the situation where there is overlap really fast. Also, in computer science there are only three numbers: 0, 1 and many. If we need more than one block of private space to avoid collisions, the obvious choice is to have as many blocks as there are domains.
to me, the obvious choice, since even after wasting half the address space on EUI64, IPv6 is a really large space compared to distance vector convergence limits, is one block, IPv6:0/0. some parts of this will be routed. some will not be routed. some will be routed some days but not others. all allocations from the RIR system will be unique.
which is precisely the point i'm trying to make. the RIR system can guaranty uniqueness among RIR allocations, but can make no assertions either way as to "routability". since any definition of ULA depends on a definition of "routable", i think this slope is too slippery for us.
As I said before, if ARIN feels it should only give out "hopefully routable" address space like it does today, no problem, let other people give out ULA-C space. But ARINs definition issues don't preclude the usefulness of ULA-C.
since ULA is designed to conserve something that we can't use all of (IPv6 address space) because of something else we can't get enough of (routing table size), at the expense of constraining the future usability of the allocations (forcing a renumbering event to go from unroutable to routable) and requiring a new system of monitoring and enforcement, which by example RFC 1918 still lacks), i have to say, ULA looks like all-pain no-gain to me.
* Paul Vixie:
first, ARIN does not currently consider routability when allocating address space. non-routable space comes from ietf/iana, not the RIRs. so, for ARIN to start allocating nonroutable space is a big change. we would have to define "routable", we could face implied liability for routability on "normal address space"
Why? There is a technical difference between the two offerings (separate address spaces). It seems to me that this criterion is completely sufficient. It's up to the requestor to decide which type they need, and to make sure that the meet the published requirements. On the other hand, the IPv6 address space is so large that any entity can pick some prefix and use it to implement its own ULA registry. If there is real demand for such a service, that demand itself will make sure that the prefix won't be used for any other purpose. (".local." could be seen as a counter-example, but I believe the initial problems have been fixed by now.)
Creating a new type of address space for "private" use just because some companies are too lazy to figure out how to configure their firewalls (which don't even exist yet) is not good engineering.
"Some people want it." and i want cash to fall from the sky. if we do everything anybody wants, we will have even less reliable code, more net breakage, ... randy
I will agree with this.. though I might have phrased it differently. Rather than mandate how organizations must use portions of their allocations, why not just let the whole thing be publicly routable? Then if an organization decides to use part of their allocation for private routing they can choose a block and quantity appropriate for their needs. Just as today we block private addresses at the network edge, we can continue to do so for IPv6. IPv6 is bigger, but it's not magic.. I have access lists in place on my routers to prevent private IP routing and IP spoofing.. I assume (yeah, I know) that most responsible sysadmin's do the same. I really don't understand the controversy over or need for ULA-C. Feel free to honestly educate me. I like feeling educated. Kevin :$s/worry/happy/g
-----Original Message----- From: ppml-bounces@arin.net [mailto:ppml-bounces@arin.net] On Behalf Of Stephen Sprunk Sent: Wednesday, May 30, 2007 9:21 AM To: jordi.palet@consulintel.es; ARIN PPML; address-policy-wg@ripe.net Subject: Re: [ppml] [address-policy-wg] Those pesky ULAs again
Thus spake "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
Agree, in ARIN region is not difficult to get, but in other two regions (LACNIC and RIPE NCC) is still impossible.
However more difference to point to is that using PI for a function such as the one covered by ULA-Central is wasting space.
How is using a PI /48 any more or less wasteful than a ULA-C /48? If anything, there is less ULA space (currently /7) available than PI space (currently /3) so we should be more concerned about waste in ULA land.
Creating a new type of address space for "private" use just because some companies are too lazy to figure out how to configure their firewalls (which don't even exist yet) is not good engineering.
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
_______________________________________________ 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
On Tue, 2007-05-29 at 12:08 -0700, David Williamson wrote:
I wasn't going to post again today to this list, but I cannot let blatantly incorrect statements go by. PI is not hard to get, although your experience may vary by region. My org holds a PI /48, and it took me 2 days of duration and ten minutes of effort to receive it. That's nearly trivial, in my book.
If you want to endorse PI for "private" use please also consider that it leaves blocks wide open to abuse. Separate ULA-C space can easily be filtered, but how do you easily prevent hijacking of unannounced PI-prefixes should such private blocks become as commonplace as rfc1918-space? //per
On May 30, 2007, at 4:33 AM, Per Heldal wrote:
On Tue, 2007-05-29 at 12:08 -0700, David Williamson wrote:
I wasn't going to post again today to this list, but I cannot let blatantly incorrect statements go by. PI is not hard to get, although your experience may vary by region. My org holds a PI /48, and it took me 2 days of duration and ten minutes of effort to receive it. That's nearly trivial, in my book.
If you want to endorse PI for "private" use please also consider that it leaves blocks wide open to abuse. Separate ULA-C space can easily be filtered, but how do you easily prevent hijacking of unannounced PI-prefixes should such private blocks become as commonplace as rfc1918-space?
How do you prevent it now, in IPv4 ? (I know several companies with addressable blocks for internal use, and so I suspect that this is not that rare.) Regards Marshall
//per
_______________________________________________ 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
On Wed, 2007-05-30 at 10:48 -0400, Marshall Eubanks wrote:
On May 30, 2007, at 4:33 AM, Per Heldal wrote:
If you want to endorse PI for "private" use please also consider that it leaves blocks wide open to abuse. Separate ULA-C space can easily be filtered, but how do you easily prevent hijacking of unannounced PI-prefixes should such private blocks become as commonplace as rfc1918-space?
How do you prevent it now, in IPv4 ?
I filter private addresses ;) (rfc1918).
(I know several companies with addressable blocks for internal use, and so I suspect that this is not that rare.)
From a transit-provider perspective I find it reasonable to filter anything smaller than RIR-allocated blocks . I.e. anything longer than a /48 from PI-land is filtered. A couple extra bits may be accepted if
I expect those relatively few with "hidden" V4 PI to be elegible for V6 PI and that they will continue a similar practise with V6. My concern is directed at those who promote unannounced public V6 blocks as a mass-replacement for rfc1918 when efforts imho are better spent on solutions to eliminate the use of NAT and private space. Btw, holding back part of a PI block is also going to create problems. the as-path-length is 2 or less (for TE purposes). Similar goes for PA-land. Where does that leave a /48 split split up to keep parts of it "secret"? //per
On Tue, May 29, 2007 at 07:32:27PM +0200, Iljitsch van Beijnum wrote:
That's like saying people can use real money instead of monopoly money. I really don't get this. Did you guys bet a lot of money that there would never be ULA-C or something?
If you don't like it, don't use it yourself and filter it, but PLEASE don't whine about it.
Calling a debate "whining" is a bit rude. My "whining" isn't intended to change your mind - I don't think any argument I make is likely to do that. My argument, however, is that there's no problem solved by ULA-C that can't be solved by PI space, and the creation of ULA-C would entirely undermine the RIR-based PI system. That latter possibility is the thing that worries those of us who are whining. That seems like a "bad idea". If you seriously think that ULA-C is entirely orthogonal to PI space, and will have zero impact on the usage of PI space...well...we'll have to agree to disagree. All of this, of course, distracts from the real underlying problem, as Mr. Vixie points out. Okay, I think that's my quote of posts to ppml for the day. Time to let someone else add their thoughts. -David
On Tue, 2007-05-29 at 10:25 -0700, David Williamson wrote:
Uh, neither of those reasons undermines the solution others have proposed: use PI space. You can always just not announce some part (or all) of your space. That would make it private.
Until there's a magic solution for scalable IDR you'll hit the filter-wall. For ARIN's PI-block (/48 as defined by ARIN), expect networks to filter anything that is more specific. Hence you won't be able to keep a chunk "private" by making it "invisible" to the outside world.
ULA-C sounds to me like a request to the guys who spin silicon to help people keep from screwing up their router configs. If someone can't manage to filter their BGP such that they keep some (or all) of their space private, I don't see why Cisco, Juniper, et al., need to do that for them.
ULA-C is a questionable workaround for the IT-industry's failure to solve basic problems. E.g; why, in 2007, is renumbering even an issue anymore? It shouldn't be a problem when changing upstream provider, nor should it be an issue when different private networks are joined. //per
On 29-mei-2007, at 19:25, David Williamson wrote:
Uh, neither of those reasons undermines the solution others have proposed: use PI space.
Well, give me a couple of PI blocks and I'll think about it. Did I mention that I'm in the RIPE region but not a RIPE member/LIR? And that my IPv4 space is a /29 plus a /32?
Iljitsch van Beijnum wrote:
On 29-mei-2007, at 18:40, Owen DeLong wrote:
Advantages of ULA-C (even to those who claim there are some): Virtually none.
I'm sure you don't mind the plane renumbering in flight when it switches from one satellite connection to the next. Myself, I'd like to see the flight systems to have stable addressing regardless of the orientation of the satellite antennas.
Which is probably an application for ip-mobility agents and not BGP. Boeing's (now) historical implementation should be looked at as a generally bad idea and one can only imagine what it would have looked like if some large fraction of the 20,000 or so commercial aviation aircraft that would have been good candidates for it had been so equipped.
Disadvantages of ULA-C:
I can't believe you keep pounding on this dead horse. These are PRIVATE addresses. Period. _______________________________________________ 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 policies for ULA-C are likely to be different from the policies for PI.
ULA-C doesn't exist. There is not even a current Internet draft to define what the acronym stands for. If any RIRs create a policy on that basis, then it will be the beginning of the end of the RIR system. The RIRs are supposed to be stewards, prudently managing a shared resource. --Michael Dillon
That's broken. As it has been stated in previous messages some days ago, RIR communities can do whatever they want, especially if IETF fails. I'm doing IETF work, but it is clear that some times, for whatever reasons is too slow, or even fails. This community has the right to bypass that if required. And one more demonstration that this is broken: All the RIRs did 4-byte-ASN policies when no RFCs where available. As you can see the RIR system is still working. So yes, I will much prefer to have an RFC, and this is the way we are going, but nothing precludes to go in parallel, as it has been done in the 4-byte-ASN, and probably some other times I guess. And, in the worst case, if the IETF fails again on this (I'm sure will not be the case this time), we could always go for a global policy to instruct IANA to delegate that resource to the RIRs. Regards, Jordi
De: <michael.dillon@bt.com> Responder a: <ppml-bounces@arin.net> Fecha: Tue, 29 May 2007 22:13:47 +0100 Para: <ppml@arin.net>, <address-policy-wg@ripe.net> Conversación: [ppml] [address-policy-wg] Those pesky ULAs again Asunto: Re: [ppml] [address-policy-wg] Those pesky ULAs again
The policies for ULA-C are likely to be different from the policies for PI.
ULA-C doesn't exist. There is not even a current Internet draft to define what the acronym stands for. If any RIRs create a policy on that basis, then it will be the beginning of the end of the RIR system.
The RIRs are supposed to be stewards, prudently managing a shared resource.
--Michael Dillon
_______________________________________________ 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 29-mei-2007, at 23:52, JORDI PALET MARTINEZ wrote:
That's broken. As it has been stated in previous messages some days ago, RIR communities can do whatever they want, especially if IETF fails. I'm doing IETF work, but it is clear that some times, for whatever reasons is too slow, or even fails. This community has the right to bypass that if required.
The IETF is far from perfect, but I'm not quite convinced that the RIRs stepping in when the IETF doesn't produce the desired results is going to work well.
And one more demonstration that this is broken: All the RIRs did 4- byte-ASN policies when no RFCs where available.
There had been a draft for more than 5 years, the reason that there was no RFC was a process particularity (can't publish a routing RFC without there being interoperable implementations), not lack of consensus on any technical issue.
So yes, I will much prefer to have an RFC, and this is the way we are going,
What exactly is the way we are going?
That's broken. As it has been stated in previous messages some days ago, RIR communities can do whatever they want, especially if IETF fails.
That may be true but since the IETF is not failing, there is no reason for the RIRs to take over any IETF functions.
I'm doing IETF work, but it is clear that some times, for whatever reasons is too slow, or even fails. This community has the right to bypass that if required.
What community? So far I see only you suggesting that the RIRs should usurp the IETF role in defining Internet numbers.
And one more demonstration that this is broken: All the RIRs did 4-byte-ASN policies when no RFCs where available. As you can see the RIR system is still working.
Jordi, you are twisting the truth. When the RIRs passed the 4-byte ASN policies, there were already Internet drafts working their way through the IETF process. 4-byte ASN work was part of the charter of the IETF's IDR working group. According to the IDR records here http://www3.ietf.org/proceedings/05nov/idr.html They had a goal to submit an RFC candidate document to the IESG in October 2005 which was more than a year before ARIN passed its 4-byte ASN policy. This is an example of the RIRs working in concert with the IETF. What you are proposing is for the RIRs to completely bypass the IETF process entirely.
So yes, I will much prefer to have an RFC, and this is the way we are going, but nothing precludes to go in parallel, as it has been done in the 4-byte-ASN, and probably some other times I guess.
Your guess is not good enough. In fact, even if you manage to get an RIR to pass some sort of ULA-C policy, it will not be good enough for most companies who want a centrally registered address block. These companies want some security of ownership in those addresses. They want strong assurances that their registered allocation will stay with them for the life of the company or the life of IPv6 whichever comes first. If ULA-C comes about through the dubious process that you propose, then there is no guarantee that the RIRs won't revoke ULA-C 6 months later. I would recommend that anyone needing the guarantee of uniqueness from a central registry should apply for PI address blocks. And if your local RIR does not offer PI IPv6 blocks, then work to get a policy passed to do this, such as was done in the ARIN region.
And, in the worst case, if the IETF fails again on this (I'm sure will not be the case this time), we could always go for a global policy to instruct IANA to delegate that resource to the RIRs.
Regards, Jordi
De: <michael.dillon@bt.com> Responder a: <ppml-bounces@arin.net> Fecha: Tue, 29 May 2007 22:13:47 +0100 Para: <ppml@arin.net>, <address-policy-wg@ripe.net> Conversación: [ppml] [address-policy-wg] Those pesky ULAs again Asunto: Re: [ppml] [address-policy-wg] Those pesky ULAs again
The policies for ULA-C are likely to be different from the policies for PI.
ULA-C doesn't exist. There is not even a current Internet draft to define what the acronym stands for. If any RIRs create a policy on that basis, then it will be the beginning of the end of the RIR system.
The RIRs are supposed to be stewards, prudently managing a shared resource.
--Michael Dillon
_______________________________________________ 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.
_______________________________________________ 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
On Wed, 30 May 2007 michael.dillon@bt.com wrote:
That's broken. As it has been stated in previous messages some days ago, RIR communities can do whatever they want, especially if IETF fails.
That may be true but since the IETF is not failing, there is no reason for the RIRs to take over any IETF functions.
I think there is evidence that the IETF is failing. Rather than a complete list of every failure, I'll just point out that the IETF (that is, the IESG and IAB), have a number of now well documented problems with: corruption conflicts of interest bad faith false statements silencing critics various kinds of deception Millions of dollars are involved in these deceptions. A recent egregious example of corruption, that is, officials profiting from deception, is the Housley authz-extns scandal. Russ Housley and Mark Brown submitted a draft to the IETF standardizing a patented TLS authorization protocol in February 2006. The patent was submitted in January 2005. The problem: They didn't tell the IETF about the patent, in violation of the IETF Policy. Their draft (seven revisions), stated that By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. What is even more egregious about this is that Housley was an IESG member during this time, and knew the policy of the IETF on patent disclosure. The draft was approved by the IESG as a standard in June 2006. Housley still kept mum on the patent. Brown (the other author) finally made a disclosure on November 26, 2006 (right over Thanksgiving). A good eye by Sam Hartman caught the emailed disclosure notice, and thereby discovered the deception. It was discussed by the IESG on the next telechat on 11/30/2006. The IESG announced withdrawal of the approval in February, 2007. It turns out the Housley was paid to write and promote the draft. Housley knew the IETF policy, and didn't disclose the patent, and repeatedly made material false statements. The IETF/ISOC membership and the public lost a legal right by unknowingly using the patented standards. Software patents are usually worth millions of dollars, and patented standards are many time more valuable. I refer one to the definition of "Actionable Fraud". [I used Black's Law Dictionary.] In spite of this, the IESG still (and subsequently!) made Housley Chairman of the IETF and IESG. It is an understatement to say that this is very bad judgment. And after the full extent of the scandal is known, Housley has not even been made to resign. So, I think it is becoming clear that the IETF is an organization that is failing: There is not a majority of honest people on its managing boards to avoid involving the IETF in serious scandal, nor even enough to object to promoting people known to be involved in serious scandal, nor even enough to force a scandalized Chairman to resign after the seriousness of the scandal is known. I think that's pretty bad, and it will only get worse. [Enron and Worldcom come to mind] --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000
Note: soryr for the previous message, I hit the wrong key and sent it by accident Hi Randy,
ok, i give. if ula address space is assigned/managed by registries, how is it actually different from pi space?
Basically ULA space has the same 'routability' as RFC1918 space, with the added benefit of less (or in case of ULA central: no) possibility for conflicting addresses when merging/connecting separate networks. PI space is expected to be routed globally (if the user of the space wants to).
if ipv6 space is effectively infinite (and we once thought ipv4 space was), then what is the use of ula address space? why not just assign vanilla ipv6 space?
At this moment there is no IPv6 PI space (yet) in the RIPE region. When there is PI space, there will maybe be recurring costs for it (RIPE policy proposal 2007-01 is in discussion now). ULA space is free to use and has a low possibility of conflicts, and ULA Central will probably have one-time fee and is globally unique. So the main reason will probably be cost... - Sander
On tir, mai 29, 2007 05:44, Randy Bush wrote: <snip>
if ipv6 space is effectively infinite (and we once thought ipv4 space was), then what is the use of ula address space? why not just assign vanilla ipv6 space?
It´s not that infinite as people like to belive. We have something between 2^20 and 2^28 as the max number of global networks within the current structure of IPv6. It´s high but far from infinite. -- ------------------------------ Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID roger@jorgensen.no | - IPv6 is The Key! -------------------------------------------------------
On tir, mai 29, 2007 04:42, Stephen Sprunk wrote:
Thus spake "Roger Jørgensen" <roger@jorgensen.no> <snip> Anyone who is large enough to care about the extreme unlikelihood of collisions with ULA-L will be able to get PI, at least in ARIN's region. The bar is incredibly low; just about the only folks who don't qualify are people running home networks. And, for that matter, people can get a single PI block larger than /48, whereas someone who needs more than a /48 in ULA-C space would need multiple distinct blocks, presumably multiplying the fees to more than what PI costs.
without going into details, PA/PI space is really a waste to be used in a closed network that should never ever be directly connected to the public Internet. You can say we are building our own very closed version of Internet and other will be connected to us sooner or later. We need to know we have unique address space no mather how many other organization we connect with.
If your argument is that ULA-C will be cheaper, that is perhaps an argument that PI fees are too high -- not that anyone has stated if or how much cheaper ULA-C would be if it did pass. I have a hard time seeing anyone who has a legitimate need for ULA-C _or_ PI space whining about $100/yr. If they can't afford that, they can't afford anyone knowledgeable enough to care about the problems with ULA-L (or PA) space.
money isn´t on the table at all. It´s easier to get managment and other to understand that the addresses are unique with ULA-C than to explain how low the chances are to get a collission with ULA-L. It´s that easy. PI or PA or whatever you called it given out of the public routable address pool and to be used on a closed network is simply a waste. It´s that simple. -- ------------------------------ Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID roger@jorgensen.no | - IPv6 is The Key! -------------------------------------------------------
without going into details, PA/PI space is really a waste to be used in a closed network that should never ever be directly connected to the public Internet. You can say we are building our own very closed version of Internet and other will be connected to us sooner or later. We need to know we have unique address space no mather how many other organization we connect with.
and how is the ula *unique* address space different from pi/pa unique address space? randy
Hi Randy,
and how is the ula *unique* address space different from pi/pa unique address space?
ULA space is supposed to be filtered on border routers. It's a kind of BCP: you should filter out ULA and route PI/PA. What you do is is ofcourse your own descision. - Sander
-----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Roger Jørgensen
1.) get ula-central and know for sure we won´t get into this issue ever again.
2.) administrate our own local version of ULA-central for the organization we co-operate with
3.) get RIR-space with all the add on administration and documentation... For me, only option 1.) is a real option, the other two are just work-around since we don´t need global routing of the address space in question.
The RIRs already provide globally unique address space. This is what you want. Both ULA-C and the RIRs do not guarantee global routability anyway. ULA-L is never globally unique, so basically there is no such thing as "Unique Locally Assigned" addresses. Q: Is it correct that you can get a /26 IPv4 PA block, but you can't get a /96 IPv6 PA block? Why is that? Cheers, J
* Jørgen Hovland wrote:
Q: Is it correct that you can get a /26 IPv4 PA block, but you can't get a /96 IPv6 PA block? Why is that?
It's not correct. /48, /56, /64, and /112 are the most common assigments here.
Hi Lutz, Which RIR is that? According to RIPEs IPv6 policy, the minimum PA block is /32 so I was kinda wondering. I need a /96. I can even manage with a /112. (Please let's not start a useless discussion of why you think I need it). Cheers, J -----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Lutz Donnerhacke Sent: 29. mai 2007 15:22 To: address-policy-wg@ripe.net Subject: Re: [address-policy-wg] Those pesky ULAs again * Jørgen Hovland wrote:
Q: Is it correct that you can get a /26 IPv4 PA block, but you can't get a /96 IPv6 PA block? Why is that?
It's not correct. /48, /56, /64, and /112 are the most common assigments here.
* Jørgen Hovland wrote:
* Jørgen Hovland wrote:
Q: Is it correct that you can get a /26 IPv4 PA block, but you can't get a /96 IPv6 PA block? Why is that?
It's not correct. /48, /56, /64, and /112 are the most common assigments here.
Which RIR is that? According to RIPEs IPv6 policy, the minimum PA block is /32 so I was kinda wondering. I need a /96. I can even manage with a /112. (Please let's not start a useless discussion of why you think I need it).
I talk about assignments, not about allocations. If you try to get a IPv4 PA allocation from RIPE, I wonder how you will get a /26. All you can get is an IPv4 PA assignment from your LIR with a size of /26.
Lutz Donnerhacke wrote:
* Jørgen Hovland wrote:
* Jørgen Hovland wrote:
Q: Is it correct that you can get a /26 IPv4 PA block, but you can't get a /96 IPv6 PA block? Why is that?
It's not correct. /48, /56, /64, and /112 are the most common assigments here.
Which RIR is that? According to RIPEs IPv6 policy, the minimum PA block is /32 so I was kinda wondering. I need a /96. I can even manage with a /112. (Please let's not start a useless discussion of why you think I need it).
I talk about assignments, not about allocations. If you try to get a IPv4 PA allocation from RIPE, I wonder how you will get a /26. All you can get is an IPv4 PA assignment from your LIR with a size of /26.
And now I am feeling royally mixed up... I thought we were discussing IPv6? Wilfried
On Wed, May 30, 2007 at 04:36:56PM +0000, Wilfried Woeber, UniVie/ACOnet wrote:
Lutz Donnerhacke wrote:
* Jørgen Hovland wrote:
* Jørgen Hovland wrote:
Q: Is it correct that you can get a /26 IPv4 PA block, but you can't get a /96 IPv6 PA block? Why is that?
It's not correct. /48, /56, /64, and /112 are the most common assigments here.
Which RIR is that? According to RIPEs IPv6 policy, the minimum PA block is /32 so I was kinda wondering. I need a /96. I can even manage with a /112. (Please let's not start a useless discussion of why you think I need it).
I talk about assignments, not about allocations. If you try to get a IPv4 PA allocation from RIPE, I wonder how you will get a /26. All you can get is an IPv4 PA assignment from your LIR with a size of /26.
And now I am feeling royally mixed up... I thought we were discussing IPv6?
Of course. The original question was how to get a /96 IPv6-PA, because it is possible to get a /26 IPv4-PA. This question was motivated by finding an argument for IPv6-PI. The answer is very simple: When talking about PA, we have the following scheme: There are allocations given from RIR to LIR. And there are assignments given vom LIR to Users. When talking about PI, we have a different scheme: There is no allocation. The assignments are given from the RIR to Users. Breaking it down to the question: A /26 IPv4-PA is an assignment. A /96 IPv6-PA is an assignment, too. Allocations of PA does not exists with this network sizes. Rolling it back to the motivation, there is no relationship between the existence of PA and PI. We can't argument with PA assigments in order to find a reason for or against PI.
The smaller subnet in IPv6, if you want to keep autoconfiguration and other things working, is /64, so why you want something smaller coming from the RIRs ? In addition to that, if you want to allow subneting for your customers and your own network, you need extra bits for that. So that's why typically you will get a minimum of /32 block from the RIR and customers will get a /48 from you. Regards, Jordi
De: Jørgen Hovland <jorgen@hovland.cx> Responder a: <address-policy-wg-admin@ripe.net> Fecha: Tue, 29 May 2007 15:11:02 +0200 Para: 'Roger Jørgensen' <roger@jorgensen.no> CC: 'Stephen Sprunk' <stephen@sprunk.org>, 'ARIN PPML' <ppml@arin.net>, <address-policy-wg@ripe.net> Asunto: RE: [address-policy-wg] Those pesky ULAs again
-----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Roger Jørgensen
1.) get ula-central and know for sure we won´t get into this issue ever again.
2.) administrate our own local version of ULA-central for the organization we co-operate with
3.) get RIR-space with all the add on administration and documentation... For me, only option 1.) is a real option, the other two are just work-around since we don´t need global routing of the address space in question.
The RIRs already provide globally unique address space. This is what you want. Both ULA-C and the RIRs do not guarantee global routability anyway.
ULA-L is never globally unique, so basically there is no such thing as "Unique Locally Assigned" addresses.
Q: Is it correct that you can get a /26 IPv4 PA block, but you can't get a /96 IPv6 PA block? Why is that?
Cheers,
J
********************************************** 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 Mon, 2007-05-14 at 05:30 +0000, bmanning@karoshi.com wrote:
ULA-central is NOT intended to be uses as IPv6 PI.
but there is no way to stop it from becoming so.
What makes that different from any other randomly selected block of addresses if you don't apply some form of filter? The current routing-architecture applied to v6 will blow up in our face sooner or later without improved mechanisms to prevent excessive de-aggregation and unauthorised use of unallocated blocks. I'm no fan of private addressing, but it doesn't seem awfully hard to include the handling of ULA-central in such a solution. //per
participants (39)
-
bmanning＠karoshi.com -
Brian E Carpenter -
David Conrad -
David Williamson -
Dean Anderson -
Florian Weimer -
Fred Baker -
Gert Doering -
Havard Eidnes -
Heather Schiller -
Iljitsch van Beijnum -
Jason Schiller -
Jeroen Massar -
Joel Jaeggli -
JORDI PALET MARTINEZ -
Jørgen Hovland -
Kevin Kargel -
Lutz Donnerhacke -
Marshall Eubanks -
michael.dillon＠bt.com -
Nick Hilliard -
Nick Hilliard -
Owen DeLong -
Paul Vixie -
Paul_Vixie＠isc.org -
Per Heldal -
Randy Bush -
Ray Plzak -
Roger Jorgensen -
Roger Jørgensen -
Roque Gagliano -
Sander Steffann -
Scott Nelson -
Shane Kerr -
Stephen Sprunk -
Thomas Narten -
Tony Hain -
Wilfried Woeber, UniVie/ACOnet -
william(at)elan.net