From memsvcs at arin.net Mon May 1 12:24:48 2006 From: memsvcs at arin.net (Member Services) Date: Mon, 01 May 2006 12:24:48 -0400 Subject: [ppml] Proposed Policy: Recommended v6 aggregation practices Message-ID: <44563650.9090609@arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The ARIN Advisory Council (AC) will review this proposal and may decide to: 1. Accept the proposal as a formal policy proposal as it is presented; 2. Work with the author to: a) clarify the language or intent of the proposal; b) divide the proposal into two (2) or more proposals; or c) combine the proposal with other proposals; or, 3. Not accept the proposal as a formal policy proposal. The AC review will be conducted at their next regularly scheduled meeting. If the AC accepts the proposal or reaches an agreement with the author, then the proposal will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. If the AC does not accept the proposal or can not reach an agreement with the author, then the AC will notify the community of their decision with an explanation; at that time the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be considered closed. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Recommended v6 aggregation practices Author: Owen DeLong Proposal Version: 1.0 Proposal type: new Policy term: permanent Policy statement: Add section 6.3.9 to NRPM as follows: 6.3.9 Recommended Practices to Maximize Aggregation 6.3.9.1 Whenever feasible, an organization should make best possible use of provider assigned space. 6.3.9.2 Except in the most extraordinary of circumstances, no ASN should originate more than a single v6 aggregate prefix. Sparse allocation practices should prevent the need for growth-induced additional prefixes in most cases. Non-ISP organizations expanding beyond their reservation should renumber into the larger block if at all possible. 6.3.9.3 In the case of merger or acquisition resulting in a combination of multiple autonomous systems into a single topology and/or routing policy, the organization should strive to either combine the networks into one of the existing prefixes, or, obtain a new larger prefix and renumber. A grace period of up to 3 years should be allowed for this purpose. Rationale: A number of the concerns raised over proposal 2005-1 seem to center around the possibility of routing table growth due to further deaggregation and other forms of v4-like table bloat resulting from PI space. This proposal is an attempt to reduce and/or mitigate those issues to some extent. I have no illusion that this is a panacea, and, I remain convinced that the only truly viable solution is to develop a routing process for IDR which does not use the End System Identifier as the Routing Locator. I also remain uncomfortable with the idea of ARIN getting involved in routing policy. I think this is the purview of the ISPs exchanging the routes in question. However, I think these recommendations are a reasonable compromise towards a pragmatic attempt to address the existing situation until something better can be achieved. Timetable for implementation: Immediately upon BoT Approval Meeting presenter: Owen DeLong From marla_azinger at eli.net Mon May 1 12:49:36 2006 From: marla_azinger at eli.net (Azinger, Marla) Date: Mon, 1 May 2006 09:49:36 -0700 Subject: [ppml] "Recommended Practices" procedure Message-ID: <10ECB7F03C568F48B9213EF9E7F790D202100D16@wava00s2ke2k01.corp.pvt> Michel- Thank you for taking the time and writing those responses. Michel wrote: Marla Azinger wrote: > However, I also believe policy can change. So do I, otherwise I would not support 2005-1. > So why shouldnt this policy just be motivation to make shim6 work? Keep in mind that I _do_ support this policy, the short answer is that it's wishful thinking too little too late, read below for full rationale. The way I see 2005-1 is as follows: 1. The decision to allocate PI is an engineering decision, not a policy one. ARIN is stepping on the IETF toes doing this. 2. The IETF has failed to deliver an IPv6 multihoming solution for 11+ years running, which is precisely why ARIN has put 2005-1 in last call. 3. There is risk involved with 2005-1, but this risk is manageable. I don't believe PI prefixes handed out by 2005-1 can ever be reclaimed, but the policy can be changed back as you pointed out. To those who scream about early adopters getting an unfair edge, I say this: early adopters take risk and spend money late adopters don't; IPv6 desperately needs early adopters, having a PI block does not pay for the risk and the spending, shut up. Besides, many organizations already have a PI block, and those who don't can easily lie about their needs and become a LIR if they want one bad. 4. Regardless of the technical merits, 2005-1 is good for at least one thing: it sends a strong message to the IETF saying in substance "In case you have not noticed, it's about time to stick your head out of somewhere and actually deliver something that could be accepted by both the op community and the end customer". So far, so good. But now here are the catches: >> So why shouldnt this policy just be motivation to make shim6 work? > it sends a strong message to the IETF saying in substance: > In case you have not noticed, it's about time to stick your > head out of somewhere and actually deliver something Catch #1: the reasons shim6 has been rejected is because many technically enabled persons have assessed that it can _not_ be fixed (whatever it means by their criteria) by fine-tuning it. Shim6 has 4 major issues: a) It's not finalized yet. b) No real-world implementation. c) TE nightmare. d) Requires multiple addresses per host. Let's say a) and b) could eventually be solved. Remains to be seem though. c) and d) are structural design issues that are deliberate design choices. No changes to shim6 can make operators happy with TE issues neither could they convince enterprises that multiple PA addresses per host is a supportable solution. Catch #2: the IETF has noticed; they do not need your reminder neither motivation. I personally know, have met several times, and have a profound respect for many of the individuals involved there. I personally think that two or three are completely full of it and I disagree with score of others; that being said, and contrary to some conspiracy theories, and acknowledging that the IETF has some shortcomings and limitations, the fact of the matter is that the IETF is not this evil entity that tries to screw ARIN or somebody else. As said earlier, the IETF has failed to deliver an IPv6 multihoming solution but it's certainly not because they have not tried. > So why shouldnt this policy just be motivation to make shim6 work? You're sending the wrong message to the IETF. Shim6 is not economically and politically deployable given the current conditions. I can't speak for Mike O'Dell WRT GSE, but I can speak for MHAP and it's not economically and politically deployable given the current conditions either. The way out of this mess is a BGP replacement that could handle large-scale PI. Michel. From vaf at cisco.com Mon May 1 14:51:39 2006 From: vaf at cisco.com (Vince Fuller) Date: Mon, 1 May 2006 11:51:39 -0700 Subject: [ppml] "Recommended Practices" procedure In-Reply-To: References: Message-ID: <20060501185139.GA11863@vaf-lnx1.cisco.com> > 4. Regardless of the technical merits, 2005-1 is good for at least one > thing: it sends a strong message to the IETF saying in substance "In > case you have not noticed, it's about time to stick your head out of > somewhere and actually deliver something that could be accepted by both > the op community and the end customer". No, it sends quite the opposite message. It says, in effect, "Hey, aside from your strict topological addressing plan, that ipv6 stuff is good enough for us. So we'll just ignore the only thing that makes ipv6 routing scale and deploy it anyway". And no, I do not think that ipv6 is deployable with strict topological addressing (as the IETF naively specified) because the whole concept of an "address" is hopelessly non-scalable in ipv6 (and in IPv4, for that matter; but I think we have consensus that IPv4 won't scale into the next century). If you open the Pandora's box of "PI addressing" instead of demanding a scalable routing architecture, the game is over. > Catch #1: the reasons shim6 has been rejected is because many > technically enabled persons have assessed that it can _not_ be fixed > (whatever it means by their criteria) by fine-tuning it. Shim6 has 4 > major issues: > > a) It's not finalized yet. > b) No real-world implementation. > c) TE nightmare. > d) Requires multiple addresses per host. Actually, the major issue with shim6 is that it is attempting to build implementation "upgrades" to work around a fundamental architectural flaw. Basic design/engineering practice sugegsts that this won't result in an elegant, non-complex, or deployable solution. Trying to design shim6 without fixing (incomatibly changing) ipv6 "address" semantics was pretty much a lost cause from the start if such a solution was the goal. > Catch #2: the IETF has noticed; they do not need your reminder neither > motivation. I personally know, have met several times, and have a > profound respect for many of the individuals involved there. I > personally think that two or three are completely full of it and I > disagree with score of others; that being said, and contrary to some > conspiracy theories, and acknowledging that the IETF has some > shortcomings and limitations, the fact of the matter is that the IETF is > not this evil entity that tries to screw ARIN or somebody else. As said > earlier, the IETF has failed to deliver an IPv6 multihoming solution but > it's certainly not because they have not tried. The solution space was too constrained for the multi6/shim6 effort to have a realistic shot at success. Once a decision was made not to modify ipv6 protocol semantics (out of concern for the vast installed base that existed when multi6/shim6 started), the solution was virtually guarenteed to be complex, ugly, and of limited value. Again, basic design/engineering practice. > The way out of this mess is a BGP replacement that could handle > large-scale PI. BGP isn't the issue and devising a replacement for BGP doesn't attack the fundamental problem. Co-mingling endpoint identification and topological location pretty much guarentees that the single number space that you use for "addressing" can't provide both the flexibility (proof against renumbering) and scalability (routing that can be summarized at abstraction boundaries) that you want. --Vince From owen at delong.com Mon May 1 15:48:24 2006 From: owen at delong.com (Owen DeLong) Date: Mon, 01 May 2006 12:48:24 -0700 Subject: [ppml] "Recommended Practices" procedure In-Reply-To: <10ECB7F03C568F48B9213EF9E7F790D202100D16@wava00s2ke2k01.corp.pvt> References: <10ECB7F03C568F48B9213EF9E7F790D202100D16@wava00s2ke2k01.corp.pv t> Message-ID: <19C9D18A94F5F66E2E83321A@imac-en0.delong.sj.ca.us> --On May 1, 2006 9:49:36 AM -0700 "Azinger, Marla" wrote: > Michel- Thank you for taking the time and writing those responses. > > Michel wrote: > > I am curious though. The way you view Shim 6 and its creations/workings > is very dire. I confess I dont know the people who actually work on the > Shim 6 creation. Do they feel it is as hopeless as your view? Any > chance you know a few of them and could get them to post their view on > ppml? If Shim 6 is this hopeless then it seems the only solution left in > our hands is to use V6 as is like we need. > Shim6 is the wrong answer to the wrong question. The question we should be asking is "How do we build a scalable IDR[1] architecture?" What shim6 answers "Given that we won't build a scalable IDR architecture, how can we hack in enough support for multihoming that we can hope nobody insists on solving the other problems created by a PA-only world?" Yes, it is pretty dire, actually. However, there are other solutions. We need to go back and re-examine true ID/LOC splits. This can be done either by the use of extension headers, or, through the reservation of some high-order bits for a routing LOC and some modifications to routers to perform replacements on the LOC portions of the packet. Doing it with the high-order bits would be more of a flag-day kind of change, but, there are probably some clever tricks that can be done to mitigate this. Doing it with an extension header would be harder on the silicon engineers, but, would preserve complete backwards compatibility and not require any sort of flag-day changes. Anyone who wants a more detailed description of my thinking on this, send me a note OFF LIST and I'll forward you the details. > Michel wrote: > > This suggestion only addresses PI. Why is everyone stuck on PI? There > are large networks that need these capabilities (multihoming) as well. > We need solutions that enable Upstream Providers to employ multihomig as > well. > Marla, by definition, blocks ALLOCATED to LIRs are PI space to begin with. Large networks fall into one of two categories... LIRs (as I think you are describing) who were always able to get PI space, and, End Sites who cannot get PI space until 2005-1 becomes policy. In the latter case, this covers any organization which does not sell transit and has more than about 500 hosts and multihomes (2002-3). > First, thank you for the laugh. I never thought the IETF as an evil > empire. But the "perseption" that I am left with over the years is that > the IETF seems a bit unreachable. Yes, this is partly because I have not > had the money or priviledge to attend an IETF conference and make the > face to face contact. And for the past several years kept "hoping in > vein" that some majic liason person from IETF would come to an ARIN > conference and take down our concerns and suggestions and then return > later with a response from IETF or something to that effect. I pulled my > head out of the sand this time however, and came to realize that lack of > action and response on my part was also the problem. So to hear you say > they dont need my reminder or theory of motivation is disheartening, but > from where I sit my perception is that they do. If anything, to at least > get a response and answer of help with the situation. We need to take > action now, not sit in silence hoping this nightmare passe s us by. > FWIW, Tony Hain, Tomas Narten, and many others who were at ARIN in Montreal are active in IETF. Being active in IETF does not require attendance at the IETF meetings. Most of the IETF work is done on the mailing lists and all you really need to do is allocate a bunch of time and join one or more of the mailing lists. > Also, fortunatley Thomas Narten who is involved with IETF has responded > to this string and has expressed a willingness to help with this. So I > dont think my "reminder or motivation" was useless. I get your point > that the IETF may not be ignorant to this issue at hand, but the > communication and lack of action gives a different perception to the > masses. > IETF is definitely not ignorant, but, it is overweighted with vendors, large ISPs, and Academia and underweighted with operators and end-users. This creates an interesting polity in the IETF which does not lead to the most universal solutions being able to gain traction. Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From owen at delong.com Mon May 1 16:06:23 2006 From: owen at delong.com (Owen DeLong) Date: Mon, 01 May 2006 13:06:23 -0700 Subject: [ppml] "Recommended Practices" procedure In-Reply-To: <20060501185139.GA11863@vaf-lnx1.cisco.com> References: <20060501185139.GA11863@vaf-lnx1.cisco.com> Message-ID: <8467A188885B4369834C3F36@imac-en0.delong.sj.ca.us> --On May 1, 2006 11:51:39 AM -0700 Vince Fuller wrote: >> 4. Regardless of the technical merits, 2005-1 is good for at least one >> thing: it sends a strong message to the IETF saying in substance "In >> case you have not noticed, it's about time to stick your head out of >> somewhere and actually deliver something that could be accepted by both >> the op community and the end customer". > > No, it sends quite the opposite message. It says, in effect, "Hey, aside > from your strict topological addressing plan, that ipv6 stuff is good > enough for us. So we'll just ignore the only thing that makes ipv6 > routing scale and deploy it anyway". > Well... I guess we'll have to see which message they receive. I would hope they are smart enough to realize that it specifies a requirement for a scalable routing solution. Realistically, with a scalable solution to IDR, IPv6 is, essentially, deployable as is. So... The intended message and yours aren't very far apart, but, that subtle distinction does substantially change the meaning. Hopefully IETF will understand that it really is a demand for a scalable IDR solution to support PI space. > And no, I do not think that ipv6 is deployable with strict topological > addressing (as the IETF naively specified) because the whole concept of an > "address" is hopelessly non-scalable in ipv6 (and in IPv4, for that > matter; but I think we have consensus that IPv4 won't scale into the next > century). > Yes. > If you open the Pandora's box of "PI addressing" instead of demanding a > scalable routing architecture, the game is over. > I disagree. I think that the two can continue together quite nicely. What is it about PI addressing that prevents subsequent deployment of an ID/LOC split which is scalable? > The solution space was too constrained for the multi6/shim6 effort to have > a realistic shot at success. Once a decision was made not to modify ipv6 > protocol semantics (out of concern for the vast installed base that > existed when multi6/shim6 started), the solution was virtually guarenteed > to be complex, ugly, and of limited value. Again, basic design/engineering > practice. > I think there are ways we can change the protocol semantics without affecting end nodes and without having to do it in such a way that all routers have to be upgraded simultaneously. The simplest (from a protocol design perspective) would be to stick the LOC in a type 53 extension header and then use that for IDR. If we add a second subtype to 53, we can have a "beenthere" header which can be used to prevent packet looping. With these two data in the packet, AS PATH is all that is required for IDR forwarding and prefixes never need to leave the local AS (in terms of routing). >> The way out of this mess is a BGP replacement that could handle >> large-scale PI. > > BGP isn't the issue and devising a replacement for BGP doesn't attack the > fundamental problem. > Correct. > Co-mingling endpoint identification and topological location pretty much > guarentees that the single number space that you use for "addressing" > can't provide both the flexibility (proof against renumbering) and > scalability (routing that can be summarized at abstraction boundaries) > that you want. > Yes. On this, we absolutely agree. Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From dsd at servervault.com Mon May 1 16:24:01 2006 From: dsd at servervault.com (Divins, David) Date: Mon, 1 May 2006 16:24:01 -0400 Subject: [ppml] Proposed Policy: Recommended v6 aggregation practices Message-ID: While I do not necessarily disagree with the content of the policy, I do not believe ARIN is the correct place for a BCP on route aggregation. I do not claim to know where the best place is (IETF/IANA/Juniper/Linksys?) however; I do know I'm not crazy about it being ARIN. Just my thoughts... dsd -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of Member Services Sent: Monday, May 01, 2006 12:25 PM To: ppml at arin.net Subject: [ppml] Proposed Policy: Recommended v6 aggregation practices ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The ARIN Advisory Council (AC) will review this proposal and may decide to: 1. Accept the proposal as a formal policy proposal as it is presented; 2. Work with the author to: a) clarify the language or intent of the proposal; b) divide the proposal into two (2) or more proposals; or c) combine the proposal with other proposals; or, 3. Not accept the proposal as a formal policy proposal. The AC review will be conducted at their next regularly scheduled meeting. If the AC accepts the proposal or reaches an agreement with the author, then the proposal will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. If the AC does not accept the proposal or can not reach an agreement with the author, then the AC will notify the community of their decision with an explanation; at that time the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be considered closed. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Recommended v6 aggregation practices Author: Owen DeLong Proposal Version: 1.0 Proposal type: new Policy term: permanent Policy statement: Add section 6.3.9 to NRPM as follows: 6.3.9 Recommended Practices to Maximize Aggregation 6.3.9.1 Whenever feasible, an organization should make best possible use of provider assigned space. 6.3.9.2 Except in the most extraordinary of circumstances, no ASN should originate more than a single v6 aggregate prefix. Sparse allocation practices should prevent the need for growth-induced additional prefixes in most cases. Non-ISP organizations expanding beyond their reservation should renumber into the larger block if at all possible. 6.3.9.3 In the case of merger or acquisition resulting in a combination of multiple autonomous systems into a single topology and/or routing policy, the organization should strive to either combine the networks into one of the existing prefixes, or, obtain a new larger prefix and renumber. A grace period of up to 3 years should be allowed for this purpose. Rationale: A number of the concerns raised over proposal 2005-1 seem to center around the possibility of routing table growth due to further deaggregation and other forms of v4-like table bloat resulting from PI space. This proposal is an attempt to reduce and/or mitigate those issues to some extent. I have no illusion that this is a panacea, and, I remain convinced that the only truly viable solution is to develop a routing process for IDR which does not use the End System Identifier as the Routing Locator. I also remain uncomfortable with the idea of ARIN getting involved in routing policy. I think this is the purview of the ISPs exchanging the routes in question. However, I think these recommendations are a reasonable compromise towards a pragmatic attempt to address the existing situation until something better can be achieved. Timetable for implementation: Immediately upon BoT Approval Meeting presenter: Owen DeLong _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From Daniel_Alexander at Cable.Comcast.com Mon May 1 17:46:00 2006 From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel) Date: Mon, 1 May 2006 17:46:00 -0400 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 Message-ID: <2271C950731A734680BA3E2978816F1803CCF2CB@NJCHLEXCMB01.cable.comcast.com> I wanted to include some thoughts about the recent discussions. While they are not necessarily the best ideas, they are sometime reality. The two don't always go together. All the talk about not deploying PI space until the routing issues are fixed, may not be very realistic. Unfortunately, resources are rarely invested in a problem for the greater good. Money, time and development roadmaps are defined by immediate problems, and any solution is not going to be incorporated into code until long into the future. It is possible, the routing issues of v6 will not be fixed until there is a real world scaling issue, potentially due to PI space. At that point we will have to live with the past mistakes. Necessity is the mother of invention. We had our chance over the last 10 years to get it right and we missed. Talk about revoking or reclaiming allocations to correct the past is unproductive. Once an allocation is made, it's done. To talk about ARIN reclaiming space or making it "temporary" is an unrealistic solution. Maybe the PA'centric aspect of v6 is a legacy design that we need to get over. The business world has changed considerably since v6 development first began and we need to adjust to it. There are many businesses that have IT departments serving a larger footprint than many ISP. The needs of these organizations must be considered and we need to adjust to the future. Many years ago, life was simpler. ISP's dealt with issues about the Internet and provided services to customers. In today's world, many of those customers have businesses that are fundamentally dependent on the Internet. This means Executives do not want to be beholden to a particular ISP. They require they be in control of their own fate. This is why multihoming has become such an issue. This has nothing to do with technology and is entirely political, but they are not always exclusive. A v6 world needs to provide for both models, PI and PA. Maybe we are spending too much time arguing over one or the other, and need to get started by embracing both. -Dan From michel at arneill-py.sacramento.ca.us Tue May 2 02:08:45 2006 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Mon, 1 May 2006 23:08:45 -0700 Subject: [ppml] "Recommended Practices" procedure Message-ID: >> Michel Py wrote: >> c) and d) are structural design issues that are deliberate design >> choices. No changes to shim6 can make operators happy with TE >> issues neither could they convince enterprises that multiple PA >> addresses per host is a supportable solution. > Marla Azinger wrote: > I am curious though. The way you view Shim 6 and its > creations/workings is very dire. BTW I'm not the only one that views it that way; 2005-1 is in last call to provide PI instead, meaning the majority of the ARIN community considers shim6 not to be a viable solution. Besides, it's not dire, it's realistic. Shim6 is the last multihoming option the vast majority of enterprises would deploy; it's the result of over 10 years of work in the IETF. If it is not fixed by now, what makes you think that it could be fixed later? How many more years? > This suggestion only addresses PI. Why is everyone stuck on PI? > There are large networks that need these capabilities (multihoming) > as well. We need solutions that enable Upstream Providers to > employ multihoming as well. The only difference between an organization getting a PI block from ARIN or a PA block from ARIN is the name. 2005-1 removes the hypocrisy that organizations that are not ISPs and want to get a PI block will call themselves a LIR, distribute 200 /48 blocks to their buddies and employees and be left with 99.99% of what has a striking resemblance with a PI block. > But the "perception" that I am left with over the years is that the > IETF seems a bit unreachable. Yes, this is partly because I have not > had the money or priviledge to attend an IETF conference I have attended several IETF meetings on my own time and money, and I'm not the only one. As of being unreachable, I do not agree either. If you have something worthy to contribute, you can do it on mailing lists. As Owen said though, it does take a lot of time. > So to hear you say they dont need my reminder or theory of motivation > is disheartening, but from where I sit my perception is that they do. You underestimate the difficulty of the problem. If you had spent months or years trying to solve this issue you would not think like this. > We need to take action now, not sit in silence hoping > this nightmare passes us by. I'm sorry to break your heart but you're a few years late. > Owen DeLong wrote: > However, there are other solutions. We need to > go back and re-examine true ID/LOC splits. Music to my ego's ears, as he truly thinks he has produced the best ID/LOC so far. Better than 8+8 and GSE. I'm curious though, what makes you think that solutions that were discarded years ago are suddenly going to become the next best thing? The people that shot them in flames are still there; besides, they were far from perfect and at least half of the reasons that made the op community discard shim6 are valid for ID/LOCs as well. > Doing it with an extension header would be > harder on the silicon engineers They won't do it. This is one of the many things we discussed in ipv6mh meetings; a Spaniard from Marcelo Bagnulo's team came up with an idea involving headers; we had Fujitsu and Cisco and they said with a large smile that a new header in hardware could be considered, especially if someone happened to give them a few hundred million dollars to develop it. Nice try, no cigare. Owen, we worked years on this thing. >>> The way out of this mess is a BGP replacement that could >>> handle large-scale PI. >> BGP isn't the issue and devising a replacement for BGP >> doesn't attack the fundamental problem. > Correct. Wrong, wrong. Q: Why don't we give IPv6 PI to everyone? A: Because IPv4 PI was bad, so IPv6 will be bad. Q: Why was IPv4 PI bad? A: Because they were too many prefixes in the GRT. Among other things, this led to: a) Costly RAM upgrades. b) BGP routers going bezerk when large number of routes flapped. Q: Is IPv4 PI still bad? A: Not as much as it used to be, as router power has increased faster than the number of prefixes. Q: Why will IPv6 PI be bad? A: Since the RAM upgrade issue is now mostly irrelevant, the fear is that we don't know how many prefixes we can handle [if we give PI to everybody] before routers go bezerk again because the BGP process can't handle large route flaps. It's not a BGP problem you said? The bottom line is: keeping BGP as-is has the same appeal to router vendors as PA-only has to established operators. Keeping BGP as-is is the guarantee that there will be a need for updates as the routing table grows. That's why now they're lobbying to exhume unproven/never deployed ID/LOCs from the grave instead of working on a scalable version of BGP that could also have features such as secure interface to the RIR's databases so we could filter bogons and prefix hijacks right of the bat. > IETF is definitely not ignorant, but, it is > overweighted with vendors > > BGP isn't the issue and devising a replacement for BGP > doesn't attack the fundamental problem. :-D Michel. From owen at delong.com Tue May 2 02:26:31 2006 From: owen at delong.com (Owen DeLong) Date: Mon, 01 May 2006 23:26:31 -0700 Subject: [ppml] Proposed Policy: Recommended v6 aggregation practices In-Reply-To: References: Message-ID: This was intended just to be an augmentation to the stuff that already exists in that section of the IPv6 Policy Manual. It is an attempt at making a community recommendation, not necessarily a BCP. Owen --On May 1, 2006 4:24:01 PM -0400 "Divins, David" wrote: > While I do not necessarily disagree with the content of the policy, I do > not believe ARIN is the correct place for a BCP on route aggregation. I > do not claim to know where the best place is > (IETF/IANA/Juniper/Linksys?) however; I do know I'm not crazy about it > being ARIN. > > Just my thoughts... > > dsd > > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of > Member Services > Sent: Monday, May 01, 2006 12:25 PM > To: ppml at arin.net > Subject: [ppml] Proposed Policy: Recommended v6 aggregation practices > > ARIN received the following policy proposal. In accordance with the ARIN > Internet Resource Policy Evaluation Process, the proposal is being > posted to the ARIN Public Policy Mailing List (PPML) and being placed on > ARIN's website. > > The ARIN Advisory Council (AC) will review this proposal and may decide > to: > 1. Accept the proposal as a formal policy proposal as it is > presented; > 2. Work with the author to: > a) clarify the language or intent of the proposal; > b) divide the proposal into two (2) or more proposals; or > c) combine the proposal with other proposals; or, > 3. Not accept the proposal as a formal policy proposal. > > The AC review will be conducted at their next regularly scheduled > meeting. > > If the AC accepts the proposal or reaches an agreement with the author, > then the proposal will be posted as a formal policy proposal to PPML and > it will be presented at a Public Policy Meeting. If the AC does not > accept the proposal or can not reach an agreement with the author, then > the AC will notify the community of their decision with an explanation; > at that time the author may elect to use the petition process to advance > their proposal. If the author elects not to petition or the petition > fails, then the proposal will be considered closed. > > The ARIN Internet Resource Policy Evaluation Process can be found at: > http://www.arin.net/policy/irpep.html > > Mailing list subscription information can be found at: > http://www.arin.net/mailing_lists/index.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > >## * ## > > > Policy Proposal Name: Recommended v6 aggregation practices > > Author: Owen DeLong > > Proposal Version: 1.0 > > Proposal type: new > > Policy term: permanent > > Policy statement: > > Add section 6.3.9 to NRPM as follows: > > 6.3.9 Recommended Practices to Maximize Aggregation > > 6.3.9.1 > Whenever feasible, an organization should make best possible use of > provider assigned space. > > 6.3.9.2 > Except in the most extraordinary of circumstances, no ASN should > originate more than a single v6 aggregate prefix. Sparse allocation > practices should prevent the need for growth-induced additional prefixes > in most cases. Non-ISP organizations expanding beyond their reservation > should renumber into the larger block if at all possible. > > 6.3.9.3 > In the case of merger or acquisition resulting in a combination of > multiple autonomous systems into a single topology and/or routing > policy, the organization should strive to either combine the networks > into one of the existing prefixes, or, obtain a new larger prefix and > renumber. A grace period of up to 3 years should be allowed for this > purpose. > > Rationale: > > A number of the concerns raised over proposal 2005-1 seem to center > around the possibility of routing table growth due to further > deaggregation and other forms of v4-like table bloat resulting from PI > space. > > This proposal is an attempt to reduce and/or mitigate those issues to > some extent. I have no illusion that this is a panacea, and, I remain > convinced that the only truly viable solution is to develop a routing > process for IDR which does not use the End System Identifier as the > Routing Locator. > > I also remain uncomfortable with the idea of ARIN getting involved in > routing policy. I think this is the purview of the ISPs exchanging the > routes in question. However, I think these recommendations are a > reasonable compromise towards a pragmatic attempt to address the > existing situation until something better can be achieved. > > Timetable for implementation: Immediately upon BoT Approval > > Meeting presenter: Owen DeLong > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From owen at delong.com Tue May 2 02:58:15 2006 From: owen at delong.com (Owen DeLong) Date: Mon, 01 May 2006 23:58:15 -0700 Subject: [ppml] "Recommended Practices" procedure In-Reply-To: References: Message-ID: >>>> The way out of this mess is a BGP replacement that could >>>> handle large-scale PI. > >>> BGP isn't the issue and devising a replacement for BGP >>> doesn't attack the fundamental problem. > >> Correct. > > Wrong, wrong. [snip] > It's not a BGP problem you said? > Correct... It's not a BGP problem. BGP is how we trade routing information. Today, BGP trades prefix data and AS PATH data. If we find a way that IDR can be done strictly on AS PATH, then, we can take most of the prefixes out of BGP and leave all the AS PATH data there, and, BGP hasn't changed. The problem is not BGP... Yes, some possible solutions involve changing BGP. Other possible solutions involve changing the way we use BGP. > > The bottom line is: keeping BGP as-is has the same appeal to router > vendors as PA-only has to established operators. Keeping BGP as-is is > the guarantee that there will be a need for updates as the routing table > grows. That's why now they're lobbying to exhume unproven/never deployed > ID/LOCs from the grave instead of working on a scalable version of BGP > that could also have features such as secure interface to the RIR's > databases so we could filter bogons and prefix hijacks right of the bat. > Sure. In the long run, a modified BGP or new routing protocol will be required. However, in the short run, I think we can use existing BGP in concert with a scalable solution which will buy time to do the changes to the routing protocol for later optimization. > >> IETF is definitely not ignorant, but, it is >> overweighted with vendors > >> >> BGP isn't the issue and devising a replacement for BGP >> doesn't attack the fundamental problem. > Vince and I actually agree about this. This is rare, but, he and I actually agree that ID/LOC split is the only viable long term solution that has been presented. Owen -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From jeroen at unfix.org Tue May 2 04:43:24 2006 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 02 May 2006 10:43:24 +0200 Subject: [ppml] Address Space versus Routing Slots Message-ID: <1146559404.13927.85.camel@firenze.zurich.ibm.com> Hi, As it seems there is quite some controversy about the term "PI". For many people "PI" seems to imply "DFZ Routing Slot entry", this is not the case of course. ARIN, RIPE, APNIC, AFRINIC & LACNIC hand out, based on demand, requirements, fulfilment and other factors _Address Space_. They *DON'T* guarantee any routing though. Just like it is not able to currently (easily ;) announce a IPv4 >/24 usefully, if a lot of ISP's filter larger blocks, or only the few interresting ones, eg if Google would filter on IPv4 /16's or so, a lot of sites would become quite sad, or at least their users. That is economics. If one doesn't want to accept a route, don't accept it. Thus for the folks hating the idea of "IPv6 PI", when the time comes you have the option of not accepting the route, or to make it economically nice for you: let them pay for it ;) Anyhow, back to the guts... Currently the RIR's pass out IPv6 PA address space, which means that the ISP breaks up this address space and provides chunks of it to it's end-users. There is some fierce discussion (actually more corner closet to other corner closet talk) going on about "PI address space". PI is provider independent, which means the end-sites can keep on using this address space wherever they are, even disconnected from the internet. PI only provides end-sites globally unique address space, that is independent of any provider. PI thus doesn't *NOT* say that it will have any entry at all in the DFZ routing tables. For that matter PA doesn't even mean this. Taking a nice look at the IPv6 PA allocation to the Holy See (just a random nice example ;), they could use it internally as a globally unique addressing space addressing all their churches, monestaries and I know what. It does not even mean that this address space would have to be announced in the DFZ as it is only for their own use. (It is being announced already btw and it works) Normally of course people will, more sooner than later want to communicate to networks on the global internet. For the time being, say the upcoming ten or so years, this will mean that these routes are taking a slot in the routing tables. Now some idea I would see happening in the future.... lets see what you folks think of it ;) At a certain point, some bright person somewhere on this planet will come up with an ideal solution of not having a global DFZ any more. One of these solutions could be some form of shim6 or HIP. These protocols could use the Address Space the site has as an identification mechanism. The actuall routing though, using a locator, might very well happen using a completely different address space, of which only relatively a few ISP's will be announcing those routes into the DFZ. Yes this will require some mind set changes, but not for the coming couple of years at least so one can get used to it ;) Now some drawings as examples, a current "IPv4 PI Multihomed Site", thus 2 different access mediums, and own IPv4 PI address space and some upstreams. +-----------+ |Remote Host| +-----------+ | +--+ |RR| +--+ | ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, { World Wide Internet(tm)(z) } ````````````````````````````` | | +------------+ +------------+ | Upstream 1 | | Upstream 2 | +------------+ +------------+ | | BGP BGP | | +--+ +--+ +----|R1|---------------|R2|----+ | +--+ Site +--+ | | (ASN) | | +------+ | | | Host | | | +------+ a:b:c::/48 | +-------------------------------+ The site thus has 1 globally unique address space, they announce this to their two upstreams and they receive 'full' tables from both of them. If they want U1 to deliver most packets they drop the announement to U2, prepend a lot of their own ASN or do some other tricks. When they want to use U2 for outgoing packets they use U2 to send them out over. Very basic traffic engineering. The Remote Host doesn't know a thing of these tricks that are getting played as the routing system takes care of it. Now compare the above with: +-----------+ |Remote Host| +-----------+ : | : : +--+ : : |SR| : .....+--+...: | ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, { World Wide Internet(tm)(z) } ````````````````````````````` | | +------------+ +------------+ | Upstream 1 | | Upstream 2 | +------------+ +------------+ | | BGP BGP | 1:2:3::/48 | 4:5:6::/48 +--+ +--+ +----|S1|---------------|S2|----+ | +--+ Site +--+ | | (ASN) | | +------+ | | | Host | | | +------+ a:b:c::/48 | +-------------------------------+ The site still have their own globally unique address space (the IPv6 PI they most likely can soon get from ARIN). Their upstreams are providing them with each a chunk out of their PA space. The upstreams still provide BGP tables (they are small as they only contain PA) to the ensite. The endsite thus can traffic engineer outbound using BGP just like in the previous scenario. The site does NOT though announce it's own address space into BGP. When a packet hits one of the two exit routers (S1/S2) the exit picks it's upstream of choice, based on BGP and possibly other metrics, translates the packet to source address of the packet to the address space of that upstream and kicks it up the chain. When the remote host now wants to send a packet back, it's SR sees what possiblities it has to send the packet back, translating the destination to the PA prefix of it's choice, which might be influenced by the sending side. On the wire thus the PA space is used, while when the packet crosses the S1/2/R they will be the same as the original. There is one missing magic component here of course, how do S1/2 and SR communicate to tell that S1/2 are authoritive that when a packets coming from 1:2:3::/48 and 4:5:6::/48 are actually a:b:c::/48. And how do they communicate their current policy to the remote router. A sort of mini-bgp where S1/2 talks to SR could solve this. But that is the work for the bright folks ;) (Who are working on this in context of shim6). Note that in the above I depict SR as being able to be integrated on the remote host, for large scalability reasons, but it could also be somewhere in front of it, eg at the site's exits, or exist as a service somewhere else all depending on the wishes of the site. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 313 bytes Desc: This is a digitally signed message part URL: From Michael.Dillon at btradianz.com Tue May 2 04:49:35 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 2 May 2006 09:49:35 +0100 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 In-Reply-To: Message-ID: > Most customer facing routers don't have to have full tables, and, for the > ones that do, there are several alternatives to the idea of a full routing > table for both protocols on one router. Hear, hear! Network architects, engineers and operators do have alternatives. It is likely that some of these people have made bad choices and therefore ARIN's PI policy for IPv6 will cause them some pain, but this is not a good reason to reject the policy. The operations situation is not cut and dried; there are many possible ways that operators can adapt to PI addresses. Sometimes the only way to get people to put their thinking caps on is to present them with a fait accompli. But, if it turns out that ARIN's new IPv6 PI policy is shortsighted and operators can show that insurmountable problems are imminent and none of the technical alternatives will mitigate their problems, then the policy can be changed again. This is a PROCESS, this is not about carving monuments in stone. --Michael Dillon From Michael.Dillon at btradianz.com Tue May 2 05:02:00 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 2 May 2006 10:02:00 +0100 Subject: [ppml] Proposed Policy: Recommended v6 aggregation practices In-Reply-To: Message-ID: > While I do not necessarily disagree with the content of the policy, I do > not believe ARIN is the correct place for a BCP on route aggregation. I > do not claim to know where the best place is > (IETF/IANA/Juniper/Linksys?) however; I do know I'm not crazy about it > being ARIN. It's quite simple. The best place is a forum where network operators gather to discuss and agree on best inter-AS routing practices. Unfortunately, such a forum does not currently exist. Now, if you want to try to create such a forum, then I would argue that ARIN is the best place to try this. Of course, eventually the routing forum would either need to expand globally or else accept that much routing policy can be handled differently in different continents. But there really is no point trying to come to agreement or document best practice unless you have a substantial number of AS holders in the discussion. That is the fundamental problem. In the absence of such a forum I am happy to have ARIN publish recommended practices. They have as much right to do this as anyone else. --Michael Dillon From mpetach at netflight.com Tue May 2 10:50:24 2006 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 2 May 2006 07:50:24 -0700 Subject: [ppml] [GLOBAL-V6] Re: [address-policy-wg] Just say *NO* to PI space -- or how to make it less destructive In-Reply-To: <4451BD99.8000301@zurich.ibm.com> References: <63ac96a50604251156i5681cbfbl77c49ccd20254dd1@mail.gmail.com> <4451BD99.8000301@zurich.ibm.com> Message-ID: <63ac96a50605020750y25240f0di2dcca64f89a29918@mail.gmail.com> (apologies for the earlier html-mail; I had failed to notice gmail had toggled my default away from plain text) On 4/28/06, Brian E Carpenter wrote: > Matthew Petach wrote: > > On 4/24/06, Pekka Savola wrote: > > > >>Hi, > >> > >>On Fri, 21 Apr 2006, Ruchti, Marcus wrote: > >> > >>>I don't think flapping routes will increase due to the assignments > >>>of PI space, as in the most cases ISP's are requesting those for > >>>customers and offers managed multihoming solutions. So announcing > >>>these routes into BGP is the responsibility of an ISP. > >> > >>First off: there has been some discussion whether 200K routes is a > >>problem or not. If the numbers stayed at that level (how can we > >>ensure that?), that wouldn't be a huge problem. Bigger one is > >>dynamicity. Huston's study indicated that there are folks whose BGP > >>announcements flap (due to TE) intentionally 1000's of times a day. > >>Multiply that by the number of sites (and add sBGP or friends to the > >>stew) and you may start thinking that your DFZ router might have > >>better things to do than process that cruft. > > > > BGP flap dampening is already well understood for limiting the impact > > of flapping routes on your CPU, if that's a concern; it has no bearing > > on address allocation policy decisionmaking. And configuring dampening > > is up to each _recipient_ network, and is not something that should be > > codified > > into an address allocation policy, which is targetted at the _originating_ > > network. > > > > Let's stick to the topic at hand, which is how to craft a useful address > > allocation policy which allows for provider indepent address allocations, > > Matt, note that you are begging the question there. You're *assuming* that > the answer to the underlying problem is PI addressing. But let's use > that assumption for now... I'm speaking as a businessperson, and pointing out that PI addressing is a requirement for large businesses connecting to the Internet today. If we don't provide a way for those entities to connect in a way that does not tie them to their upstream providers in IPv6, they won't use IPv6--they'll use IPv4, where they can connect in a provider independent fashion. You say I'm "assuming" the answer is PI addressing; I'm pointing out that the *reality* of the situation is that PI addressing exists in IPv4, and has become a business requirement. If we don't address that requirement within the IPv6 policy, businesses won't migrate to IPv6. This isn't an assumption--this is the reality of the internet as it exists today. > Correct, in my personal view. So the policies put in place need to auto-limit > PI space at the level of thousands rather than millions of sites. Prudent > stewardship seems to call for that. Except that processor capabilities are increasing year over year; so while the limit today may be in the hundreds of thousands, in a few years it will be capable of supporting millions of sites; are you proposing that we keep updating the address allocation policy each year, to account for the increases in processor capabilities? Otherwise we really will be limiting the growth of the internet based on the slowest/most limited hardware in place, rather than letting it grow at the natural pace the market will support. I guess at this point, we've cast our votes in our respective directions; I've cast my vote in favour of 2005-1, as I think it's important to aim for the future and stimulate growth; you're free to vote against it, and look to the past, limiting the growth of the internet based on fears that routing hardware won't continue to scale to meet demands. It's up to the AC now to take our votes and decide what to do with them. > Brian Matt From michel at arneill-py.sacramento.ca.us Tue May 2 11:01:54 2006 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Tue, 2 May 2006 08:01:54 -0700 Subject: [ppml] Address Space versus Routing Slots Message-ID: > Jeroen Massar wrote: > The site still have their own globally unique address space (the > IPv6 PI they most likely can soon get from ARIN). Their upstreams > are providing them with each a chunk out of their PA space. > ....[snap].... translating the destination to the PA prefix of > it's choice, which might be influenced by the sending side. On > the wire thus the PA space is used, while when the packet crosses > the S1/2/R they will be the same as the original. This is exactly MHAP as I designed it 4 years ago. Nothing new technically, what makes you think the IETF is going to adopt it now? > Owen DeLong wrote: > Sure. In the long run, a modified BGP or new routing protocol will > be required. However, in the short run, I think we can use existing > BGP in concert with a scalable solution which will buy time to do > the changes to the routing protocol for later optimization. I wrote the following text 4 years ago, still is on the original page. > - It is not out of scope to discuss long-term solutions that require > major undertakings (such as replacing BGP), but the focus should be > on extracting out of these solutions the ideas that could be re-used > for solutions that have a shorter time-to-market. Same question as to Jeroen: what makes you think you can deliver a short-term solution now? Did you call a BoF to start with? Talked with the shim6 people to know how they feel about a 180 degrees turn? Michel. From jeroen at unfix.org Tue May 2 12:33:46 2006 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 02 May 2006 18:33:46 +0200 Subject: [ppml] Address Space versus Routing Slots In-Reply-To: References: Message-ID: <1146587627.21837.28.camel@firenze.zurich.ibm.com> On Tue, 2006-05-02 at 08:01 -0700, Michel Py wrote: > > Jeroen Massar wrote: > > The site still have their own globally unique address space (the > > IPv6 PI they most likely can soon get from ARIN). Their upstreams > > are providing them with each a chunk out of their PA space. > > ....[snap].... translating the destination to the PA prefix of > > it's choice, which might be influenced by the sending side. On > > the wire thus the PA space is used, while when the packet crosses > > the S1/2/R they will be the same as the original. > > This is exactly MHAP as I designed it 4 years ago. Nothing new > technically, what makes you think the IETF is going to adopt it now? It's indeed the MHAP way of solving the problem and I don't think people want to actually adopt it at all for various political (read: cashcow) reasons :( And I certainly am not even going to bother pushing for it as for me it doesn't hold any value, I am pretty happy with a little chunk of PA space as an enduser. The companies that need such a solution should be pushing and going for it. > > Owen DeLong wrote: > > Sure. In the long run, a modified BGP or new routing protocol will > > be required. However, in the short run, I think we can use existing > > BGP in concert with a scalable solution which will buy time to do > > the changes to the routing protocol for later optimization. > > I wrote the following text 4 years ago, still is on the original page. > > > - It is not out of scope to discuss long-term solutions that require > > major undertakings (such as replacing BGP), but the focus should be > > on extracting out of these solutions the ideas that could be re-used > > for solutions that have a shorter time-to-market. > > Same question as to Jeroen: what makes you think you can deliver a > short-term solution now? Did you call a BoF to start with? Talked with > the shim6 people to know how they feel about a 180 degrees turn? It's only the solution I see fit to solve the problem were everybody is making problem over and I really don't see any chance of it getting accepted simply because of the political reasons, just like most likely shim6 will not make at as some folks really don't want to give that kind of independence to people, just like they are opposed to "PI" in the first place... it is also why I say it might take multiple years, it might also take forever. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 313 bytes Desc: This is a digitally signed message part URL: From vaf at cisco.com Tue May 2 14:01:02 2006 From: vaf at cisco.com (Vince Fuller) Date: Tue, 2 May 2006 11:01:02 -0700 Subject: [ppml] "Recommended Practices" procedure In-Reply-To: References: Message-ID: <20060502180102.GA5431@vaf-lnx1.cisco.com> > > IETF is definitely not ignorant, but, it is > > overweighted with vendors > > > > > BGP isn't the issue and devising a replacement for BGP > > doesn't attack the fundamental problem. > > :-D FWIW, my involvement with IETF, NANOG, et alia long predates my current employment status. A quick look at RFC1338, RFC1519, etc. will verify that. As I have stated before, I do not speak for my employer. Quite the contrary since I feel my comments here reflect an advocacy for the large network operations community that at times is contrary to a vendor's interests (the best thing that could happen to a router vendor would be a return to the replace-the-core-every-2-or-3-years heyday of the 90s); they are based on my first-hand experience in that community from 1988 to 2001. --Vince From owen at delong.com Tue May 2 15:14:04 2006 From: owen at delong.com (Owen DeLong) Date: Tue, 02 May 2006 12:14:04 -0700 Subject: [ppml] Address Space versus Routing Slots In-Reply-To: References: Message-ID: <27B2EADA1D2813E30914C913@imac-en0.delong.sj.ca.us> >> Owen DeLong wrote: >> Sure. In the long run, a modified BGP or new routing protocol will >> be required. However, in the short run, I think we can use existing >> BGP in concert with a scalable solution which will buy time to do >> the changes to the routing protocol for later optimization. > > I wrote the following text 4 years ago, still is on the original page. > >> - It is not out of scope to discuss long-term solutions that require >> major undertakings (such as replacing BGP), but the focus should be >> on extracting out of these solutions the ideas that could be re-used >> for solutions that have a shorter time-to-market. > > Same question as to Jeroen: what makes you think you can deliver a > short-term solution now? Did you call a BoF to start with? Talked with > the shim6 people to know how they feel about a 180 degrees turn? > I think a solution is possible. I don't pretend to have all the answers, and, no, I don't have the resources to be as active in IETF as I would like to be, so, I must to some extent leave this part to others. My management barely understands the value of my participation in ARIN. They perceive no value whatsoever to IETF participation, unfortunately. However, I am hoping that by having rational PI policies in place, we can make it clear to IETF that PI will happen and that a scalable routing solution must be discussed/developed sooner rather than later. I have some ideas about how such a solution might be accomplished, but, they are just ideas. I'll happily share them with anyone who wishes to listen, and, I have shared them with several people. However, I do not know if that will yield any concrete results or not. All I can do is the best I can do. The alternative is to simply give up, which, I don't think serves the community at all. Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From michel at arneill-py.sacramento.ca.us Tue May 2 23:53:03 2006 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Tue, 2 May 2006 20:53:03 -0700 Subject: [ppml] Address Space versus Routing Slots Message-ID: > Jeroen Massar wrote: > [MHAP]The companies that need such a solution > should be pushing and going for it. These companies have no voice. Companies big enough to push it are better off with PI and likely eligible for it, why should they shoot themselves in the foot? PI is simpler and cheaper :-( >... it is also why I say it might take multiple years, > it might also take forever. So, we wait to see if the routing table gets to a million prefixes, and if it does then if enough people feel enough pain we have another shot at it. Maybe. Any bright ideas to make it happen faster? > Owen DeLong wrote: > All I can do is the best I can do. The alternative is to simply > give up, which, I don't think serves the community at all. Please consider another alternative: keep your energy for the day the ID/LOC battle can be fought successfully. > Vince Fuller wrote: > (the best thing that could happen to a router vendor would be a > return to the replace-the-core-every-2-or-3-years heyday of the 90s) Vince, you can't deny that preserving the status-quo on BGP is the best way to insure that it will happen again. As of touting ID/LOCs as the long-term solution, I have to question the IETF motives on this one. As the political matters that have discarded these solutions in the past are mostly unchanged, this sudden interest in digging them out of the grave looks rather suspicious to me. The shim6 team has been sent to a suicide mission, I wonder how many protocol designers are ready to dust off their old ID/LOC stuff to get slaughtered a second time. Since you have been around the IETF for such a long time, maybe you have some insight to share about this for the ARIN community? Michel. From weiler at tislabs.com Wed May 3 14:29:56 2006 From: weiler at tislabs.com (Sam Weiler) Date: Wed, 3 May 2006 14:29:56 -0400 (EDT) Subject: [ppml] Policy Proposal 2006-6: Bulk WHOIS agreement expiration clarification Message-ID: > If ARIN staff are going to arbitrarily decide to "expire" an > agreement which has no defined expiration, doing so unilaterally and > without notice is an extraordinarily bad idea. > > Let me just say that I think it's really pitiful that we should need > to use the policy process to micromanage operations at this level. > But believe me, I wouldn't be wasting my time writing something > this trivial if it weren't necessary to solve an actual problem. While I'm sad that this policy clarification seems to be necessary, it also seems perfectly reasonable. I support 2006-6. -- Sam From woody at pch.net Wed May 3 14:47:55 2006 From: woody at pch.net (Bill Woodcock) Date: Wed, 3 May 2006 11:47:55 -0700 (PDT) Subject: [ppml] Policy Proposal 2006-6: Bulk WHOIS agreement expiration clarification In-Reply-To: References: Message-ID: > While I'm sad that this policy clarification seems to be necessary, it > also seems perfectly reasonable. > I support 2006-6. Sorry, I've been trying to find time to update it based upon the quite-a-bit-of-additional-information I've gotten since writing it. I will, right now, once again, try to find time to update it. Expect another posting to PPML in a half-hour or so, or subject me to public shaming. -Bill From woody at pch.net Wed May 3 15:03:08 2006 From: woody at pch.net (Bill Woodcock) Date: Wed, 3 May 2006 12:03:08 -0700 (PDT) Subject: [ppml] MODIFICATION OF Policy Proposal 2006-6: Bulk WHOIS agreement expiration clarification In-Reply-To: References: Message-ID: Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0 Policy Proposal Name: Bulk WHOIS agreement expiration clarification Author: Bill Woodcock Proposal Version: 1.1 Proposal type: Modify Policy term: Permanent Policy statement: Text added to the end of "3.1. Bulk Copies of ARIN's WHOIS": If no term of validity or expiration date is included in the policy or AUP, it shall be deemed valid upon acceptance by ARIN and shall conclude after thirty days notice by ARIN, immediately upon cancellation by the other signatory, or immediately upon a violation of its terms. If an expiration date is included, ARIN shall provide thirty days notice prior to the expiration of an AUP agreement, in order that the data recipient shall have the opportunity to receive uninterrupted service. ARIN shall deliver notices to the other signatory by, at a minimum, email to an administrative and a technical contact email address supplied by the signatory. Rationale: Presently, there is no expiration date specified in the AUP agreement or in the policy. In practice, ARIN presently expires bulk WHOIS agreements after one year, but this expiration practice appears to be informal and undocumented. Likewise, in practice, notice of expiration is presently sent to the email address from which the original application was received, notwithstanding that this is unlikely to be the appropriate role account for the purpose. There is presently no formal schedule for expiration, and no formal notification mechanism for expiration or violations. This policy attempts to formalize these processes. Timetable for implementation: Immediate. END OF TEMPLATE From vaf at cisco.com Thu May 4 06:36:57 2006 From: vaf at cisco.com (Vince Fuller) Date: Thu, 4 May 2006 03:36:57 -0700 Subject: [ppml] Address Space versus Routing Slots In-Reply-To: References: Message-ID: <20060504103657.GA16715@vaf-lnx1.cisco.com> > > Vince Fuller wrote: > > (the best thing that could happen to a router vendor would be a > > return to the replace-the-core-every-2-or-3-years heyday of the 90s) > > Vince, you can't deny that preserving the status-quo on BGP is the best > way to insure that it will happen again. Carrying the "PI address" scheme of multihoming (i.e. assign a globally- visible prefix to anybody who wants to multihome) from IPv4 to ipv6 is the best way to ensure that it will happen again. And there are a lot more potential ipv6 prefixes than IPv4 prefixes. > As of touting ID/LOCs as the long-term solution, I have to question the > IETF motives on this one. As the political matters that have discarded > these solutions in the past are mostly unchanged, this sudden interest > in digging them out of the grave looks rather suspicious to me. The > shim6 team has been sent to a suicide mission, I wonder how many > protocol designers are ready to dust off their old ID/LOC stuff to get > slaughtered a second time. Since you have been around the IETF for such > a long time, maybe you have some insight to share about this for the > ARIN community? The IETF's position on this matter is that shim6 is the answer. My view, that an ID/LOC split is a fundamental requirement for scalable multi- homing, is considered heretical among the IETF leadership. Please don't confuse anything that I write with an IETF position because the two couldn't be more differeent. --Vince From michel at arneill-py.sacramento.ca.us Thu May 4 10:25:35 2006 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Thu, 4 May 2006 07:25:35 -0700 Subject: [ppml] Address Space versus Routing Slots Message-ID: Vince, >>> Vince Fuller wrote: >>> (the best thing that could happen to a router vendor would be a >>> return to the replace-the-core-every-2-or-3-years heyday of the 90s) >> Michel Py wrote: >> Vince, you can't deny that preserving the status-quo on BGP is the >> best way to insure that it will happen again. > Carrying the "PI address" scheme of multihoming (i.e. assign a > globally-visible prefix to anybody who wants to multihome) from > IPv4 to ipv6 is the best way to ensure that it will happen again. > And there are a lot more potential ipv6 prefixes than IPv4 prefixes. This is very true but it's too late to do something about that, which is why I support 2005-1. It's not good, but it's the lesser of two evils. Try to be realistic and look what the alternatives are today for enterprises that need multihoming and need to deploy IPv6. These alternatives are: 1. Don't deploy IPv6. 2. Become a LIR. 3. Use RFC4193 and try to get it routed. 4. NATv6 RFC4193 addresses if 3. fails. If 2005-1 is adopted, the list becomes: 1. Get a PI block from 2005-1. Note that I'm not saying that 2005-1 will trigger massive IPv6 adoption as there are numerous other show stoppers, but that's another discussion. > The IETF's position on this matter is that shim6 is the answer. My > view, that an ID/LOC split is a fundamental requirement for scalable > multi-homing, is considered heretical among the IETF leadership. Keep in mind that trying to convince me on this is akin to preaching to a choir. Ever read draft-py-mhap-intro-00.txt? That's not the point; the point is what we can do about it. > Please don't confuse anything that I write with an IETF position > because the two couldn't be more different. Vince, one could wonder. I'm reading your slides from the GROW presentation: > Is it worth doing an IAB-sponsored experiment, workshop, or > other IETF-sanctioned activity along these lines to re-examine > GSE or explore other solutions? You have been around the IETF long enough to know that the answer to this is no, and will continue to be no for the foreseeable future. Why put in on the table in the first place? Are there any developments that I am not aware of that would make this fly without being another suicide mission? Reality check: PI sucks. Do you have a solution with reasonable chances of adoption that sucks less? If no, please support 2005-1. It sucks, but all the other alternatives are worse. Michel. From william at elan.net Thu May 4 10:53:10 2006 From: william at elan.net (william(at)elan.net) Date: Thu, 4 May 2006 07:53:10 -0700 (PDT) Subject: [ppml] Address Space versus Routing Slots In-Reply-To: References: Message-ID: On Thu, 4 May 2006, Michel Py wrote: > This is very true but it's too late to do something about that, which is > why I support 2005-1. It's not good, but it's the lesser of two evils. > Try to be realistic and look what the alternatives are today for > enterprises that need multihoming and need to deploy IPv6. I agree with Michael - IPv6 PI is not perfect but we desperately need such policy to help in adoption of IPv6 in the US - or otherwise we will run out of ipv4 space before majority are ready. >> The IETF's position on this matter is that shim6 is the answer. My >> view, that an ID/LOC split is a fundamental requirement for scalable >> multi-homing, is considered heretical among the IETF leadership. > > Keep in mind that trying to convince me on this is akin to preaching to > a choir. Ever read draft-py-mhap-intro-00.txt? That's not the point; the > point is what we can do about it. If there is enough interest from research and engineering folks then the thing to do is to form open design group and get the initial software to test the concept and polish the design. Have that all available as maintained internet drafts so if/when shim6 fails an alternative is right there to just take over and make a WG. >> Is it worth doing an IAB-sponsored experiment, workshop, or >> other IETF-sanctioned activity along these lines to re-examine >> GSE or explore other solutions? The activity need not be "officially IETF-sanctioned" (although that would be nice), it just that IETF needs to be aware of it and know that many if not majority of those involves are those also involved with IETF. -- William Leibzon Elan Networks william at elan.net From memsvcs at arin.net Thu May 4 13:27:31 2006 From: memsvcs at arin.net (Member Services) Date: Thu, 04 May 2006 13:27:31 -0400 Subject: [ppml] Policy Proposal 2006-6: Bulk WHOIS agreement expiration clarification - revised text Message-ID: <445A3983.6070204@arin.net> Policy Proposal 2006-6: Bulk WHOIS agreement expiration clarification has been revised by the author. This proposal is open for discussion on this mailing list. The current policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2006_6.html Regards, Member Services American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal Name: Bulk WHOIS agreement expiration clarification Author: Bill Woodcock Proposal Version: 1.1 Proposal type: Modify Policy term: Permanent Policy statement: Text added to the end of "3.1. Bulk Copies of ARIN's WHOIS": If no term of validity or expiration date is included in the policy or AUP, it shall be deemed valid upon acceptance by ARIN and shall conclude after thirty days notice by ARIN, immediately upon cancellation by the other signatory, or immediately upon a violation of its terms. If an expiration date is included, ARIN shall provide thirty days notice prior to the expiration of an AUP agreement, in order that the data recipient shall have the opportunity to receive uninterrupted service. ARIN shall deliver notices to the other signatory by, at a minimum, email to an administrative and a technical contact email address supplied by the signatory. Policy Rationale Presently, there is no expiration date specified in the AUP agreement or in the policy. In practice, ARIN presently expires bulk WHOIS agreements after one year, but this expiration practice appears to be informal and undocumented. Likewise, in practice, notice of expiration is presently sent to the email address from which the original application was received, notwithstanding that this is unlikely to be the appropriate role account for the purpose. There is presently no formal schedule for expiration, and no formal notification mechanism for expiration or violations. This policy attempts to formalize these processes. Timetable for implementation: Immediate. From drc at virtualized.org Thu May 4 20:17:19 2006 From: drc at virtualized.org (David Conrad) Date: Thu, 4 May 2006 17:17:19 -0700 Subject: [ppml] Address Space versus Routing Slots In-Reply-To: References: Message-ID: <15D9A2E0-A674-4788-9C2C-E9485C0C768F@virtualized.org> Hi, On May 4, 2006, at 7:53 AM, william(at)elan.net wrote: > I agree with Michael - IPv6 PI is not perfect but we desperately > need such > policy to help in adoption of IPv6 in the US - or otherwise we will > run > out of ipv4 space before majority are ready. I'm curious: what do people think will happen when IANA allocates the last unused /8? Rgds, -drc -------- My opinions are my own and do not necessarily represent the opinions of any organization I may be a part of. So there. From kloch at hotnic.net Thu May 4 20:24:55 2006 From: kloch at hotnic.net (Kevin Loch) Date: Thu, 04 May 2006 20:24:55 -0400 Subject: [ppml] Address Space versus Routing Slots In-Reply-To: <15D9A2E0-A674-4788-9C2C-E9485C0C768F@virtualized.org> References: <15D9A2E0-A674-4788-9C2C-E9485C0C768F@virtualized.org> Message-ID: <445A9B57.4030603@hotnic.net> David Conrad wrote: > I'm curious: what do people think will happen when IANA allocates the > last unused /8? I doubt the last /8 will ever be issued. What is interesting is what happens at the point at when the perception of scarcity becomes widespread. I expect various forms of hoarding coincident with restrictive policy changes. As space runs out a marketplace will almost certainly emerge, sanctioned or not. If I had to take a wild guess I'd say that 16 /8's remaining would be the psychological threshold for dysfunction to begin (not counting class D/E which should remain off limits no matter what). - Kevin From gih at apnic.net Thu May 4 20:47:06 2006 From: gih at apnic.net (Geoff Huston) Date: Fri, 05 May 2006 10:47:06 +1000 Subject: [ppml] Address Space versus Routing Slots In-Reply-To: <15D9A2E0-A674-4788-9C2C-E9485C0C768F@virtualized.org> References: <15D9A2E0-A674-4788-9C2C-E9485C0C768F@virtualized.org> Message-ID: <6.2.0.14.2.20060505104439.02a5b650@kahuna.telstra.net> >I'm curious: what do people think will happen when IANA allocates the >last unused /8? Equally curious folk want to know: Does IANA have a view? thanks, Geoff From the "you show me yours before I show you mine" Department :-) From drc at virtualized.org Thu May 4 21:45:47 2006 From: drc at virtualized.org (David Conrad) Date: Thu, 4 May 2006 18:45:47 -0700 Subject: [ppml] Address Space versus Routing Slots In-Reply-To: <6.2.0.14.2.20060505104439.02a5b650@kahuna.telstra.net> References: <15D9A2E0-A674-4788-9C2C-E9485C0C768F@virtualized.org> <6.2.0.14.2.20060505104439.02a5b650@kahuna.telstra.net> Message-ID: <9CB316E3-65EA-4515-9238-C91EC78C854C@virtualized.org> On May 4, 2006, at 5:47 PM, Geoff Huston wrote: >> I'm curious: what do people think will happen when IANA allocates the >> last unused /8? > Equally curious folk want to know: Does IANA have a view? Officially: nope. Not IANA's job to have views on that particular issue in my opinion. > From the "you show me yours before I show you mine" Department :-) I personally have a view, but that's just me. The reason I asked the question is that it sometimes appears that folks assume the Internet will grind to a halt when the last v4 /8 is allocated so we must deploy IPv6 at all costs. I would be curious to see what people think. In particular (and in keeping with the charter of this mailing list), I would be interested in hearing what the public policy implications are of events of v4 free space depletion (at 11:11 GMT Dec 12, 2012 I assume :-)). Rgds, -drc -------- My opinions are my own and do not necessarily represent the opinions of any organization I may be a part of. So there. From gih at apnic.net Thu May 4 22:15:06 2006 From: gih at apnic.net (Geoff Huston) Date: Fri, 05 May 2006 12:15:06 +1000 Subject: [ppml] Address Space versus Routing Slots In-Reply-To: <9CB316E3-65EA-4515-9238-C91EC78C854C@virtualized.org> References: <15D9A2E0-A674-4788-9C2C-E9485C0C768F@virtualized.org> <6.2.0.14.2.20060505104439.02a5b650@kahuna.telstra.net> <9CB316E3-65EA-4515-9238-C91EC78C854C@virtualized.org> Message-ID: <6.2.0.14.2.20060505120401.02a07d20@kahuna.telstra.net> >The reason I asked the question is that it sometimes appears that >folks assume the Internet will grind to a halt when the last v4 /8 is >allocated so we must deploy IPv6 at all costs. I would be curious to >see what people think. In particular (and in keeping with the >charter of this mailing list), I would be interested in hearing what >the public policy implications are of events of v4 free space >depletion (at 11:11 GMT Dec 12, 2012 I assume :-)). I had asked those questions at the RIPE open policy meeting last year, and also at the ARIN meeting where there was a round table on this topic. What appears to be obvious (well obvious to me at any rate) is that at the time when an RIR can no longer meet allocation demands via provision of unallocated address space (i.e. the RIR "runs out") then the current policy framework also reaches its current end point. Exhaustion of the IPv4 unallocated address pool does not imply complete unavailability of IPv4 address resources to industry players. i.e. the exhaustion of the unallocated IPv4 address pool does not appear to imply a forced IPv6 conversion onto the industry at that point in time There is reason to believe that the Internet industry will continue to use IPv4 as a base protocol well after this IPv4 unallocated address pool exhaustion date comes and goes. This raises a number of considerations, including: a) market-related considerations In the absence of the imposition of specific external control functions, a conventional economic response would be the emergence of various forms of trading markets in address resources. In conventional markets scarcity tends to operate as a pricing premium factor. Market behaviours would then imply an entirely different behaviour in terms of IPv4 address distribution functions. Release of current address holdings based on conversion to address compression technologies could come into play within a market-based pricing dynamic. The policy questions such a market dynamic would appear to raise include: What form of market regulation would be appropriate? How would it be applied? Who would apply it? Why would it be useful to have? From a "network integrity" perspective it may also be useful to consider: How can we preserve address utility (the integrity of address uniqueness) in an environment of market-based trading? Is the emergence of such markets Good or Bad? Avoidable or Inevitable? Appropriate or Inappropriate? Fair or Unfair? Are there any practical alternatives for the industry? How would address trading markets be best supported? Would such markets be regulated? How? What is the RIR role in such an environment? b) RIR policy considerations In the area of RIR Allocation Policies, there are the policy-related questions of: What is the threshold point where the application of different IPv4 address allocation policies may be appropriate? Or is ?no change? a wiser course of action? Or should the RIRs establish ?strategic reserve address pools? Why? c) broader considerations What about ?Equity?, ?Affordability?, ?Fairness? of access to address resources at a global level? And in what venue are such concerns best expressed? And how would they be expressed within the overall model? Overall I suspect that all these boil down to: What are most appropriate address management policy measures that will support the continued well-being of the global Internet and its users? And when will they be needed? The above are my personal opinions, of course. regards, Geoff From owen at delong.com Fri May 5 00:53:33 2006 From: owen at delong.com (Owen DeLong) Date: Thu, 04 May 2006 21:53:33 -0700 Subject: [ppml] Address Space versus Routing Slots In-Reply-To: <15D9A2E0-A674-4788-9C2C-E9485C0C768F@virtualized.org> References: <15D9A2E0-A674-4788-9C2C-E9485C0C768F@virtualized.org> Message-ID: <881F7BA37A4ED3A3F76B928B@odpwrbook.hq.netli.lan> I think that will depend a great deal on the level of v6 deployment at that time, the viability of v6 at the time, what policies are adopted by the RIRs, and the phase of the moon. Sorry... My crystal ball just doesn't extend that far. Owen --On May 4, 2006 5:17:19 PM -0700 David Conrad wrote: > Hi, > > On May 4, 2006, at 7:53 AM, william(at)elan.net wrote: >> I agree with Michael - IPv6 PI is not perfect but we desperately >> need such >> policy to help in adoption of IPv6 in the US - or otherwise we will >> run >> out of ipv4 space before majority are ready. > > I'm curious: what do people think will happen when IANA allocates the > last unused /8? > > Rgds, > -drc > -------- > My opinions are my own and do not necessarily represent the > opinions of any organization I may be a part of. So there. > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From Michael.Dillon at btradianz.com Fri May 5 04:36:49 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Fri, 5 May 2006 09:36:49 +0100 Subject: [ppml] Address Space versus Routing Slots In-Reply-To: <15D9A2E0-A674-4788-9C2C-E9485C0C768F@virtualized.org> Message-ID: > I'm curious: what do people think will happen when IANA allocates the > last unused /8? Not much because all the action will be over by then. When the IANA pool is down to less than a year's supply, then the situation will hit the general media. Stock market analysts will then start asking companies what their IPv6 migration plans are and if the company's plans are weak, their market value will drop. The resulting pressure from shareholders and analysts will cause an increase in demand for IPv6 connectivity and the demand for IPv4 addresses will slow down. It is entirely possible that IANA will never get to the point where it has to allocate the last unused /8 in IPv4. Also, the one year horizon is entirely dependent on consumption rates. If IPv6 takeup is steady, it is entirely possible that we never get to the point where we can say "Based on current consumption rates IANA will have to allocate the last IPv4 /8 sometime within the next 12 months.". --Michael Dillon From Michael.Dillon at btradianz.com Fri May 5 04:59:15 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Fri, 5 May 2006 09:59:15 +0100 Subject: [ppml] Address Space versus Routing Slots In-Reply-To: <6.2.0.14.2.20060505120401.02a07d20@kahuna.telstra.net> Message-ID: > >depletion (at 11:11 GMT Dec 12, 2012 I assume :-)). > What appears to be obvious (well obvious to me at any rate) is that at > the time when an RIR can no longer meet allocation demands via > provision of unallocated address space (i.e. the RIR "runs out") then the > current policy framework also reaches its current end point. Balderdash!!! The current policy framework is not dependent on having a large supply of IPv4 addresses. And the policies of ARIN and the other RIRs are not static. They adapt to the situation as it evolves. > Exhaustion of the IPv4 unallocated address pool does not imply complete > unavailability of IPv4 address resources to industry players. i.e. the > exhaustion of the unallocated IPv4 address pool does not appear to imply a > forced IPv6 conversion onto the industry at that point in time Policy cannot be predicted like this. It is more like seismological evolution than biological evolution. It is entire possible, and I would say it is LIKELY, that at some point in the next 4 years, ARIN could pass a policy the stops all IPv4 PI allocations in the interests of conserving the remaining IPv4 space for ISPs. At the same time I believe it likely that ARIN will not accept new ISP applicants for IPv4 PA space but will only allocate that space to existing ISPs. That isn't exactly a forced conversion to IPv6, but it does make it clear that IPv4 is intended to be in a holding pattern, not on a growth curve. > In the absence of the imposition of specific external control functions, > a conventional economic response would be the emergence of various forms > of trading markets in address resources. This has always been true of IPv4. Nothing new here, move along. > In conventional markets > scarcity tends to operate as a pricing premium factor. Market behaviours > would then imply an entirely different behaviour in terms of IPv4 > address distribution functions. Release of current address holdings > based on conversion to address compression technologies could come into > play within a market-based pricing dynamic. If you are unable to say this stuff in Plain English then I wonder why you bother to participate in the PUBLIC Policy Mailing List. If the PUBLIC can't make heads or tails of your sentences, then what is the point? > The policy questions such a market dynamic would appear to raise > include: What form of market regulation would be appropriate? How would > it be applied? Who would apply it? Why would it be useful to have? Totally irrelevant here. ARIN does not impose market regulation. If you want the UN to take over the RIR system and ask national governments to impose regulation then why don't you just say so? But don't expect a friendly reception here because most of us are opposed to the type of government control that you support. > In the area of RIR Allocation Policies, there are the policy-related > questions of: What is the threshold point where the application of > different IPv4 address allocation policies may be appropriate? Or is ?no > change? a wiser course of action? Or should the RIRs establish > ?strategic reserve address pools? Why? These are simpler questions. The threshold point is found when someone proposes a policy change to ARIN and that policy change makes it through the policy approval process. "No change" is a wiser course of action when no policy change makes it through the approval process. ARIN should establish strategic reserve address pools when a policy stating this makes it through the policy approval process. Why? Because the industry-driven bottom-up policy development process is BETTER than a bunch of academics sitting around and deciding what they should tell us to do. > What about ?Equity?, ?Affordability?, ?Fairness? of access to address > resources at a global level? And in what venue are such concerns best > expressed? And how would they be expressed within the overall model? Overall model? Who says we need an overall model? As far as I can see, it is only the supporters of government regulation under the umbrella of a UN overall model who support this. >The above are my personal opinions, of course. Does this mean that APNIC did not send you here to mess with ARIN politics in order to gain support for your "one global model" viewpoint? Why should we believe that? --Michael Dillon From sleibrand at internap.com Fri May 5 12:54:29 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 5 May 2006 12:54:29 -0400 (EDT) Subject: [ppml] Address Space versus Routing Slots In-Reply-To: References: Message-ID: Michael, I think you're being unfair to Geoff, and doing us all a dis-service by attacking his motives. Geoff is as entitled to his personal (political?) opinion as anyone else, and his participation on the ARIN public policy mailing list (participation in which isn't restricted to the ARIN region, BTW), doesn't constitute "interference". Geoff has provided the ARIN community with a lot of good analysis. If you don't agree with his viewpoint on issues like this, fine. But please don't let your participation in the PPML push us toward a name-calling flame-war. -Scott On 05/05/06 at 9:59am +0100, Michael.Dillon at btradianz.com wrote: > > >depletion (at 11:11 GMT Dec 12, 2012 I assume :-)). > > > What appears to be obvious (well obvious to me at any rate) is that at > > the time when an RIR can no longer meet allocation demands via > > provision of unallocated address space (i.e. the RIR "runs out") then > the > > current policy framework also reaches its current end point. > > Balderdash!!! > The current policy framework is not dependent on having > a large supply of IPv4 addresses. And the policies of ARIN > and the other RIRs are not static. They adapt to the situation > as it evolves. > > > Exhaustion of the IPv4 unallocated address pool does not imply complete > > unavailability of IPv4 address resources to industry players. i.e. the > > exhaustion of the unallocated IPv4 address pool does not appear to imply > a > > forced IPv6 conversion onto the industry at that point in time > > Policy cannot be predicted like this. It is more like > seismological evolution than biological evolution. It is > entire possible, and I would say it is LIKELY, that at > some point in the next 4 years, ARIN could pass a policy > the stops all IPv4 PI allocations in the interests of > conserving the remaining IPv4 space for ISPs. At the same > time I believe it likely that ARIN will not accept new ISP > applicants for IPv4 PA space but will only allocate that > space to existing ISPs. That isn't exactly a forced conversion > to IPv6, but it does make it clear that IPv4 is intended > to be in a holding pattern, not on a growth curve. > > > In the absence of the imposition of specific external control > functions, > > a conventional economic response would be the emergence of various > forms > > of trading markets in address resources. > > This has always been true of IPv4. Nothing new here, > move along. > > > In conventional markets > > scarcity tends to operate as a pricing premium factor. Market > behaviours > > would then imply an entirely different behaviour in terms of IPv4 > > address distribution functions. Release of current address holdings > > based on conversion to address compression technologies could come > into > > play within a market-based pricing dynamic. > > If you are unable to say this stuff in Plain English > then I wonder why you bother to participate in the > PUBLIC Policy Mailing List. If the PUBLIC can't make > heads or tails of your sentences, then what is the point? > > > The policy questions such a market dynamic would appear to raise > > include: What form of market regulation would be appropriate? How > would > > it be applied? Who would apply it? Why would it be useful to have? > > Totally irrelevant here. ARIN does not impose market regulation. > If you want the UN to take over the RIR system and ask national > governments to impose regulation then why don't you just say so? > But don't expect a friendly reception here because most of us are > opposed to the type of government control that you support. > > > In the area of RIR Allocation Policies, there are the policy-related > > questions of: What is the threshold point where the application of > > different IPv4 address allocation policies may be appropriate? Or is > ?no > > change? a wiser course of action? Or should the RIRs establish > > ?strategic reserve address pools? Why? > > These are simpler questions. The threshold point is found when > someone proposes a policy change to ARIN and that policy change > makes it through the policy approval process. "No change" is a > wiser course of action when no policy change makes it through the > approval process. ARIN should establish strategic reserve address > pools when a policy stating this makes it through the policy > approval process. Why? Because the industry-driven bottom-up > policy development process is BETTER than a bunch of academics > sitting around and deciding what they should tell us to do. > > > What about ?Equity?, ?Affordability?, ?Fairness? of access to address > > resources at a global level? And in what venue are such concerns best > > expressed? And how would they be expressed within the overall model? > > Overall model? Who says we need an overall model? As far as > I can see, it is only the supporters of government regulation > under the umbrella of a UN overall model who support this. > > >The above are my personal opinions, of course. > > Does this mean that APNIC did not send you here to mess > with ARIN politics in order to gain support for your > "one global model" viewpoint? Why should we believe that? > > --Michael Dillon > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From memsvcs at arin.net Fri May 5 13:57:28 2006 From: memsvcs at arin.net (Member Services) Date: Fri, 05 May 2006 13:57:28 -0400 Subject: [ppml] Proposed Policy: RSA Modification Procedure - not accepted by AC as formal policy proposal Message-ID: <445B9208.9060700@arin.net> On May 4, 2006, the ARIN Advisory Council (AC) concluded its review of the proposed policy 'RSA Modification Procedure' and did not accept it as a formal policy proposal. "It is the sense of the Advisory Council that proposed policy 'RSA Modification Procedure' is fundamentally an operational issue and thus is a matter that can best be addressed by the ARIN Board of Trustees. The Advisory Council will send this information to the ARIN Board of Trustees." During the initial review period the AC may decide to: 1) Accept the proposal as a formal policy proposal as it is presented, 2) Work with the author to clarify, divide or combine it with another proposal, or 3) Not accept the policy proposal. In the event that the AC decides not to accept the proposed policy, then the author may elect to use the petition process to advance the proposal. For petition details see the section called "Petition Process" in the ARIN Internet Resource Policy Evaluation Process which can be found at: http://www.arin.net/policy/irpep.html The deadline for the author to initiate a petition per the ARIN Internet Resource Policy Evaluation Process is 40 days prior to the meeting; the petition deadline for the ARIN XVIII Public Policy Meeting is September 1, 2006. If the author chooses not to petition or the petition is unsuccessful, then the proposed policy is closed. If a petition is successful, then the proposal will be numbered and posted for discussion and presented at ARIN's Public Policy Meeting. The proposed policy text can be found at: http://lists.arin.net/pipermail/ppml/2006-April/005376.html Regards, Member Services American Registry for Internet Numbers (ARIN) From drc at virtualized.org Fri May 5 19:26:44 2006 From: drc at virtualized.org (David Conrad) Date: Fri, 5 May 2006 16:26:44 -0700 Subject: [ppml] Address Space versus Routing Slots In-Reply-To: References: Message-ID: Michael, On May 5, 2006, at 1:59 AM, Michael.Dillon at btradianz.com wrote: > At the same > time I believe it likely that ARIN will not accept new ISP > applicants for IPv4 PA space but will only allocate that > space to existing ISPs. :-). And people complain now about how the RIRs restrain trade... >> In conventional markets scarcity tends to operate as a pricing >> premium factor. Market behaviours would then imply an entirely >> different behaviour in terms of IPv4 address distribution >> functions. Release of current address holdings >> based on conversion to address compression technologies could come >> into play within a market-based pricing dynamic. > > If you are unable to say this stuff in Plain English then I wonder > why you bother to participate in the PUBLIC Policy Mailing List. If > the PUBLIC can't make heads or tails of your sentences, then what > is the point? Um. I'm a member of the PUBLIC and what Geoff is saying is fairly plain to me. Which words did you have trouble with? >> The policy questions such a market dynamic would appear to raise >> include: What form of market regulation would be appropriate? >> How would >> it be applied? Who would apply it? Why would it be useful to have? > Totally irrelevant here. ARIN does not impose market regulation. Don't be silly. Sure it does. ARIN and the other RIRs do not permit independent trade in address space. For ARIN, see section 8 of the NPRM. They explicitly regulate the market into official non- existence, forcing address space trading into the black or gray market. Pretending such regulation doesn't exist wastes everyone's time. > If you want the UN to take over the RIR system and ask national > governments to impose regulation then why don't you just say so? > But don't expect a friendly reception here because most of us are > opposed to the type of government control that you support. These two sentences don't appear to correlate with anything Geoff was saying. Were you, perhaps, responding to a different message and made a cut-and-paste mistake? > Overall model? Who says we need an overall model? Well, an overall model exists, whether anyone says it is needed or not. The current overall model is defined within the existing RIR structures and policies which evolve over time. It is decentralized, bottom-up driven and one operational component of that model is that it currently disallows market-based mechanisms to improve address utilization efficiencies in IPv4 for good or ill. Whether or not this model will evolve to a market-based approach is a subject of fairly frequent, if not annoyingly repetitive, discussion on this list among others. >> The above are my personal opinions, of course. > Does this mean that APNIC did not send you here to mess > with ARIN politics in order to gain support for your > "one global model" viewpoint? Why should we believe that? Damn, Geoff. You've been found out. You're going to lose your Black Helicopter for sure now. The European Wing of the Illuminati has exposed you on the ARIN field of battle, now you'll have to regroup and ply the Protocols of APNIC via LACNIC or AfriNIC. Too bad. Longer flights and less convenient connections. :-) Michael: in my memory, this was probably the worst message you've sent on this mailing list. Rgds, -drc -------- My opinions are my own and do not necessarily represent the opinions of any organization I may be a part of. So there. From hannigan at renesys.com Sat May 6 03:16:51 2006 From: hannigan at renesys.com (Martin Hannigan) Date: Sat, 06 May 2006 03:16:51 -0400 Subject: [ppml] Address Space versus Routing Slots In-Reply-To: <15D9A2E0-A674-4788-9C2C-E9485C0C768F@virtualized.org> References: <15D9A2E0-A674-4788-9C2C-E9485C0C768F@virtualized.org> Message-ID: <7.0.1.0.2.20060506031129.02136848@renesys.com> At 08:17 PM 5/4/2006, David Conrad wrote: >Hi, > >On May 4, 2006, at 7:53 AM, william(at)elan.net wrote: > > I agree with Michael - IPv6 PI is not perfect but we desperately > > need such > > policy to help in adoption of IPv6 in the US - or otherwise we will > > run > > out of ipv4 space before majority are ready. > >I'm curious: what do people think will happen when IANA allocates the >last unused /8? Nothing. The commodity market for IPV4 will move above ground prior to that and instead of faking asset acquisitions and lying on applications, we'll see blocks openly traded in commodity or auction markets. Legacy space will have value and people will exploit that. Real money will exchange hands. The registry/registrar mess is a whole lot of fun to watch. Perhaps it makes sense to work on the conversion now and let the market decide when it's time for v6 based on value of V4? -M< -- Martin Hannigan (c) 617-388-2663 Renesys Corporation (w) 617-395-8574 Member of Technical Staff Network Operations hannigan at renesys.com From gih at apnic.net Sat May 6 06:50:14 2006 From: gih at apnic.net (Geoff Huston) Date: Sat, 06 May 2006 20:50:14 +1000 Subject: [ppml] Address Space versus Routing Slots In-Reply-To: References: Message-ID: <6.2.0.14.2.20060506203427.02dec8d0@kahuna.telstra.net> >Damn, Geoff. You've been found out. You're going to lose your Black >Helicopter for sure now. The European Wing of the Illuminati has >exposed you on the ARIN field of battle, now you'll have to regroup >and ply the Protocols of APNIC via LACNIC or AfriNIC. Too bad. >Longer flights and less convenient connections. I know - and it was all going so well too :-) Geoff From michel at arneill-py.sacramento.ca.us Sat May 6 15:03:21 2006 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Sat, 6 May 2006 12:03:21 -0700 Subject: [ppml] Address Space versus Routing Slots Message-ID: Hi Geoff, I might have a few leftover cans of black-colored paint suitable for aeronautical use that is rumored to absorb radar signals and make the aircraft unidentifiable; need any to re-coat your chopper? :-D > Geoff Huston wrote: > What appears to be obvious (well obvious to me at any rate) > is that at the time when an RIR can no longer meet allocation > demands via provision of unallocated address space (i.e. the > RIR "runs out") then the current policy framework also reaches > its current end point. Existing policies should be kept even then IMHO, because a few blocks might be freed over time. Possibly some kind of a waiting list with no guarantees whatsoever might be implemented. Without it, what would a RIR do if space became available? I don't think much of it would happen though, but it might be wise to plan for it. Besides, I think there still will be need for a policy framework for the continuing (renewed) use of already allocated space. > Exhaustion of the IPv4 unallocated address pool does not imply > complete unavailability of IPv4 address resources to industry > players. i.e. the exhaustion of the unallocated IPv4 address > pool does not appear to imply a forced IPv6 conversion onto the > industry at that point in time. Probably true in the US and quite possible in some other industrialized countries who tend to have large (>1) IP-per-capita ratios. > There is reason to believe that the Internet industry will > continue to use IPv4 as a base protocol well after this IPv4 > unallocated address pool exhaustion date comes and goes. Ack. > a) market-related considerations > Is the emergence of such markets Good or Bad? Define "good" and "bad" please :-D > Avoidable or Inevitable? IMHO some of it is inevitable. > Appropriate or Inappropriate? What difference does it make? > Fair or Unfair? Life is not fair nor markets. > Would such markets be regulated? How? What > is the RIR role in such an environment? IMHO the RIRs should not try to regulate prices or who has priority to get the IP blocks that are for "sale". I do think though that the RIRs should keep maintaining the WHOIS information. I do not like the idea of IP blocks being sold, I much prefer the RIRs continuing to lease them. Therefore I envision that when time has come RIR policies should allow the transfer of IP blocks (even if the transfer is not the by-product of a merger or acquisition, and even if there is money involved) and make sure that the identity of the new recipient is known, that they will pay the annual fees, and that they will abide by policies in place. The rationale behind this is as follows: if the RIRs try to regulate prices or who can "buy" or "sell", it will inevitably create a black market. The bottom line is that if there is demand, there will be supply. In the USA, we have an interesting historical prospective about this, called the prohibition. In their greatest righteous stupidity, our legislators managed to pass a constitutional amendment (which makes an act of congress look easy) to make alcohol illegal. As it turned out, the good people of the United States of America wanted to continue drinking booze, and all the prohibition achieved was to line the pockets of the mafia and a well-known political family (not because of their alleged ties to the mafia but because they cleverly bought rights to import booze during the prohibition for pennies and cashed in when it ended). As the Internet is not regulated by a single country or entity, it appears to me that trying to prevent or aggressively regulate the trade of IPv4 addresses after there are no more to allocate is doomed to fail. What the RIRs should do IMHO is to make sure that such trade stays on the table and does not move under the table. > In the area of RIR Allocation Policies, there are the policy-related > questions of: What is the threshold point where the application of > different IPv4 address allocation policies may be appropriate? Or is > "no change" a wiser course of action? I would favor a "no change" course of action until we get within 18 months of the predicted exhaustion (from a RIR prospective, not IANA), at which point the policies to allow transfer of IP blocks shall be discussed, and implemented immediately after the RIR allocates the last bit. > Or should the RIRs establish "strategic reserve address pools"? Why? The problem about strategic reserves is defining a policy about who gets a piece of them based on some perceived need. This easily becomes an ugly political nightmare that will inevitably create inequalities (why him but not me). I would tend to say this: as long as there's food everyone can feast, when there's no food left everyone starves. I'm not trying to say that strategic reserves are a bad idea or discourage them though, the points I'm trying to make is that a) reaching consensus on any will be difficult and b) the cure might be worse than the disease. I think strategic reserves are better discussed around a specific proposal than in the absolute. Michel. From bmanning at vacation.karoshi.com Sun May 7 09:30:23 2006 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sun, 7 May 2006 13:30:23 +0000 Subject: [ppml] unanswered questions Message-ID: <20060507133023.GA11716@vacation.karoshi.com.> all good arguments for setting aside resources for learning about the impact of IPv6 now.... :) (from the NZNOG list) ----- Forwarded message from Perry Lorier ----- Date: Sun, 07 May 2006 23:16:36 +1200 From: Perry Lorier > "We will need this in 10 years, so we should start learning about it > now" is an argument, I guess, but most ISPs of my acquaintance are > more concerned with staying business for the next five years than > they are with optimising their costs in ten. HTTP, IM and P2P all showed a doubling of bytes transfered over the protocol every 2 weeks for at least 6 months. In the case of HTTP and P2P they became the dominant amount of traffic for some networks inside that 6 months. *If* IPv6 ever grows a killer app (big if...) an ISP may discover that it's traffic is all inside IPv6 tunnels, and their traffic engineering no longer works. An Enterprise may discover they are unable to firewall inside IPv6 traffic. Everyone may discover that their traffic monitoring software no longer reports useful results (Why is 60% of my traffic protocol 41?). "We'll just firewall all IPv6" just makes everyone's Internet slow. You might have less than 6 months to deal with this. IPv6 is dissimilar enough from v4 to require some retraining. (What happened to all the ARP messages? Why don't I need DHCP? Why *do* I need DHCP? Why are addresses that begin with Fe80: special? 2002:? 3ffe:? What's the deal with RFC1918? Is it normal my machine has nearly 100 IPv6 addresses on a single interface? Why doesn't doing the obvious ping of a link local address work? Why shouldn't I assign ...:feed:cafe:babe:f00d as an address to a machine? Given a mac address, what IPv6 address would be dynamically assigned to this host? What's the story with DAD? and what's he doing on my network? I have an MTU of 576 on a link, what happened to my v6 traffic? Would it be better if it was 1000, 1100, 1200, 1300, 1400, 1500? How am I going to remember all these v6 addresses? What's the v6 address for localhost? What's the broadcast address on a v6 network? How do I enable v6 on the various host types inside my network? More importantly, quick, how do I turn it off again? If I have an IPv6 address on an interface, does that mean I can talk to v6 hosts on the Internet? Why does connecting to some hosts on the internet now take a long time, it didn't yesterday! What changed? My network is v4 only and has a NAT box in front of it to protect me from malicious traffic, how come all of these machines can talk to v6 machines on the internet? How come v6 machines on the internet are successfully talking to them! Whats the story with Site locals? Where's all this multicast traffic come from? What's the HD ratio, and is it important to me? How do I multihome? What's a home agent good for and why does my machine want one? Who's IKE and what's he doing in my kernel? What's the v6 equivilent tool for ? How do IPv6 only hosts talk to a IPv4 only host? How do IPv4 only hosts talk to IPv6 only hosts? Someone once said IPv6 gave me {security, QoS, addresses} for free, are they lying? misinformed? or is there some tiny element of truth? What are the pitfalls with v6 addresses and DNS? Do I need to update my resolvers? What's ULA, do I need it? Should I give dialup users a /20, /32, /48, /56, /64, /120, /127, or /128? What about DSL users? What about colo'd users? What about my fridge? Given an IPv6 address, can you derive it's MAC address? What are the privacy implications of this? How are these addressed? What's 6to4? ISATAP? 6over4? Teredo? SHIM6? Are these acronyms going to haunt my nightmares? How do I do NAT in an IPv6 world? What's AH and why is that going to mean I can't screw with my users traffic anymore? What's ESP and is that going to make firewalling troublesome? And what's the story with QoS? How on earth am I going to find 2**108 customers in two years to keep APNIC happy?) ----- End forwarded message ----- From jason.schiller at mci.com Sun May 7 17:36:47 2006 From: jason.schiller at mci.com (Jason Schiller (schiller@uu.net)) Date: Sun, 07 May 2006 17:36:47 -0400 (EDT) Subject: [ppml] Address Space versus Routing Slots In-Reply-To: <7.0.1.0.2.20060506031129.02136848@renesys.com> Message-ID: On Sat, 6 May 2006, Martin Hannigan wrote: > At 08:17 PM 5/4/2006, David Conrad wrote: > >Hi, > > > >On May 4, 2006, at 7:53 AM, william(at)elan.net wrote: > > > I agree with Michael - IPv6 PI is not perfect but we desperately > > > need such > > > policy to help in adoption of IPv6 in the US - or otherwise we will > > > run > > > out of ipv4 space before majority are ready. > > > >I'm curious: what do people think will happen when IANA allocates the > >last unused /8? > > > Nothing. The commodity market for IPV4 will move above ground prior > to that and instead of faking asset acquisitions and lying on applications, > we'll see blocks openly traded in commodity or auction markets. Legacy > space will have value and people will exploit that. Real money will > exchange hands. > > The registry/registrar mess is a whole lot of fun to watch. Perhaps it > makes sense to work on the conversion now and let the market decide when > it's time for v6 based on value of V4? > > -M< Not that I disagree, but what will be the impact of the IPv4 commodity market in relationship to the routing table and the concepts of good IPv4 stewardship? First off, it is likely that those with large amounts of legacy will sell off small unused chunks of that space. "So you need a /22 to turn up a new customer, and I've got this legacy Class B. I could sell you the .26, .113, .117, and .118 subnets." This results in de-aggegragtion and many more specific in the routing table. This also makes the only justification for IP space how much money you have. This means poor companies (or countries) may be left out in the cold increasing the digital divide, and spinning up the efforts of WSIS and the UN. It is also possible that rich companys might stockpile the remaining addesses. What would happen if say Cogent bought up all of the remaining space? Can you see other ISPs hanging out the "no address vacancy, please try Cogent" sign? ___Jason From hannigan at renesys.com Sun May 7 21:48:54 2006 From: hannigan at renesys.com (Martin Hannigan) Date: Sun, 7 May 2006 21:48:54 -0400 Subject: [ppml] Address Space versus Routing Slots In-Reply-To: References: Message-ID: At 5:36 PM -0400 05:07:2006, Jason Schiller (schiller at uu.net) wrote: >On Sat, 6 May 2006, Martin Hannigan wrote: > >> At 08:17 PM 5/4/2006, David Conrad wrote: >> >Hi, >> > >> >On May 4, 2006, at 7:53 AM, william(at)elan.net wrote: >> > > I agree with Michael - IPv6 PI is not perfect but we desperately >> > > need such >> > > policy to help in adoption of IPv6 in the US - or otherwise we will >> > > run >> > > out of ipv4 space before majority are ready. >> > >> >I'm curious: what do people think will happen when IANA allocates the >> >last unused /8? >> >> >> Nothing. The commodity market for IPV4 will move above ground prior >> to that and instead of faking asset acquisitions and lying on applications, >> we'll see blocks openly traded in commodity or auction markets. Legacy >> space will have value and people will exploit that. Real money will >> exchange hands. >> >> The registry/registrar mess is a whole lot of fun to watch. Perhaps it >> makes sense to work on the conversion now and let the market decide when >> it's time for v6 based on value of V4? >> >> -M< > >Not that I disagree, but what will be the impact of the IPv4 commodity >market in relationship to the routing table and the concepts of good IPv4 >stewardship? Nothing, I suppose. Operators would not be asked to change policies. You'd add slots, but not at the rate of the feared v6 influx. Operator routing policy would effectively be an influence on the pricing so theoretically, operators could squeeze the prefix. This needs more analysis. > >First off, it is likely that those with large amounts of legacy will sell >off small unused chunks of that space. "So you need a /22 to turn up a >new customer, and I've got this legacy Class B. I could sell you the .26, >.113, .117, and .118 subnets." > >This results in de-aggegragtion and many more specific in the routing table. > >This also makes the only justification for IP space how much money you >have. This means poor companies (or countries) may be left out in the >cold increasing the digital divide, and spinning up the efforts of >WSIS and the UN. It is also possible that rich companys might stockpile >the remaining addesses. What would happen if say Cogent bought up all of >the remaining space? Can you see other ISPs hanging out the "no address >vacancy, please try Cogent" sign? I don't know that poor people would be up the creek. We don't know what the pricing would be. Could be. But... For example, if they want PI, they can go to the commodity market and buy it. If not, they can pay for PA space from their provider. It may also go the other way where the price of a legacy /16 isn't worth as much as people think. Regardless, as the intrinisic value rose, there would be ample reason to go to a V6 stategy since the amount of address space alone would theoretically keep prices low enough for a point of entry of almost anyone. BTW, our friend Aaron Hughes has an excellent "cheat sheet" on prefix lengths and recently included v6. http://www.bind.com/netmasks.html As far as the Internet have-nots, Africa has less than 2% of all distributed public facing root-servers. The continent with less is Antartica. (I made a preso related to this last week, as a matter of fact) -M< -- Martin Hannigan (c) 617-388-2663 Renesys Corporation (w) 617-395-8574 Member of Technical Staff Network Operations hannigan at renesys.com From tvest at pch.net Sun May 7 22:42:54 2006 From: tvest at pch.net (Tom Vest) Date: Sun, 7 May 2006 22:42:54 -0400 Subject: [ppml] Address Space versus Routing Slots In-Reply-To: References: Message-ID: On May 7, 2006, at 9:48 PM, Martin Hannigan wrote: > At 5:36 PM -0400 05:07:2006, Jason Schiller (schiller at uu.net) wrote: >> On Sat, 6 May 2006, Martin Hannigan wrote: >> >>> At 08:17 PM 5/4/2006, David Conrad wrote: >>>> Hi, >>>> >>>> On May 4, 2006, at 7:53 AM, william(at)elan.net wrote: >>>>> I agree with Michael - IPv6 PI is not perfect but we desperately >>>>> need such policy to help in adoption of IPv6 in the US - or >>>>> otherwise we will >>>>> run out of ipv4 space before majority are ready. >>>> >>>> I'm curious: what do people think will happen when IANA >>>> allocates the >>>> last unused /8? >>> >>> Nothing. The commodity market for IPV4 will move above ground prior >>> to that and instead of faking asset acquisitions and lying on >>> applications, >>> we'll see blocks openly traded in commodity or auction markets. >>> Legacy >>> space will have value and people will exploit that. Real money will >>> exchange hands. >>> >>> The registry/registrar mess is a whole lot of fun to watch. >>> Perhaps it >>> makes sense to work on the conversion now and let the market >>> decide when >>> it's time for v6 based on value of V4? >>> >>> -M< >> >> Not that I disagree, but what will be the impact of the IPv4 >> commodity >> market in relationship to the routing table and the concepts of >> good IPv4 >> stewardship? > > > Nothing, I suppose. Operators would not be asked to change policies. > > You'd add slots, but not at the rate of the feared v6 influx. Operator > routing policy would effectively be an influence on the pricing so > theoretically, operators could squeeze the prefix. This needs more > analysis. > >> First off, it is likely that those with large amounts of legacy >> will sell >> off small unused chunks of that space. "So you need a /22 to turn >> up a >> new customer, and I've got this legacy Class B. I could sell you >> the .26, >> .113, .117, and .118 subnets." >> >> This results in de-aggegragtion and many more specific in the >> routing table. >> >> This also makes the only justification for IP space how much money >> you >> have. This means poor companies (or countries) may be left out in >> the >> cold increasing the digital divide, and spinning up the efforts of >> WSIS and the UN. It is also possible that rich companys might >> stockpile >> the remaining addresses. What would happen if say Cogent bought >> up all of >> the remaining space? Can you see other ISPs hanging out the "no >> address >> vacancy, please try Cogent" sign? > > > I don't know that poor people would be up the creek. We don't know > what the pricing would be. Could be. But... > > For example, if they want PI, they can go to the commodity market > and buy it. If not, they can pay for PA space from their provider. In some places with limited transport options, PA in nontrivial quantities (/24 or larger) cannot be had at any price. In some places with limited transport options, PI (or even non-NIR allocated) will not get routed at any price. Obvious implications -- a fair number of "poor people" are already up the creek, but for the most part only in places where other critical infrastructure bottlenecks already exist... With new bottlenecks looming in more and more places, some attention to likely market outcomes is probably (strongly) warranted. TV > It may also go the other way where the price of a legacy /16 > isn't worth as much as people think. > > Regardless, as the intrinisic value rose, there would be > ample reason to go to a V6 stategy since the amount of > address space alone would theoretically keep prices low enough > for a point of entry of almost anyone. > > BTW, our friend Aaron Hughes has an excellent "cheat sheet" on > prefix lengths and recently included v6. > > http://www.bind.com/netmasks.html > > As far as the Internet have-nots, Africa has less than 2% of all > distributed public facing root-servers. The continent with less is > Antartica. (I made a preso related to this last week, as a matter of > fact) > > > -M< > > > > > > -- > Martin Hannigan (c) 617-388-2663 > Renesys Corporation (w) 617-395-8574 > Member of Technical Staff Network Operations > hannigan at renesys.com > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From bmanning at vacation.karoshi.com Mon May 8 02:30:43 2006 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 8 May 2006 06:30:43 +0000 Subject: [ppml] Address Space versus Routing Slots In-Reply-To: References: Message-ID: <20060508063043.GA16750@vacation.karoshi.com.> > BTW, our friend Aaron Hughes has an excellent "cheat sheet" on > prefix lengths and recently included v6. > > http://www.bind.com/netmasks.html > an outgrowth of RFC1878 perhaps? --bill From Michael.Dillon at btradianz.com Mon May 8 04:04:01 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Mon, 8 May 2006 09:04:01 +0100 Subject: [ppml] Address Space versus Routing Slots In-Reply-To: Message-ID: > I think you're being unfair to Geoff, Politics and policymaking is all about being unfair. We must make choices and those choices always leave somebody less than pleased. Anybody who has been involved in politics (policymaking) understands this and has likely felt the sting of being on the losing side. > and doing us all a dis-service by > attacking his motives. Geoff is as entitled to his personal (political?) > opinion as anyone else, Of course he is. And I am entitled to dissect his opinion and interpret it, just as others are entitled to dissect and interpret my opinions. People have certainly done so in the past. > and his participation on the ARIN public policy > mailing list (participation in which isn't restricted to the ARIN region, > BTW), doesn't constitute "interference". I never said that he should be kicked off the list. Better to have opinions aired in public and discussed in public rather than in the backrooms. > Geoff has provided the ARIN community with a lot of good analysis. If you > don't agree with his viewpoint on issues like this, fine. But please > don't let your participation in the PPML push us toward a name-calling > flame-war. If you don't want name-calling flame-wars then why are you trying to escalate this dispute? What about the CONTENT of Geoff's message or the CONTENT of my message? What do you think of that? --Michael Dillon From Michael.Dillon at btradianz.com Mon May 8 04:18:06 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Mon, 8 May 2006 09:18:06 +0100 Subject: [ppml] Address Space versus Routing Slots In-Reply-To: Message-ID: > > At the same > > time I believe it likely that ARIN will not accept new ISP > > applicants for IPv4 PA space but will only allocate that > > space to existing ISPs. > > :-). And people complain now about how the RIRs restrain trade... Yes. However, we are talking about a hypothetical future time in which IPv6 Internet access is more widely available. Therefore, restricting access to IPv4 addresses does not really restrain trade because new entrants into the market are still free to use IPv6. We will have only removed the choice to use obsolete technology. > Um. I'm a member of the PUBLIC and what Geoff is saying is fairly > plain to me. Which words did you have trouble with? David, anyone who has spent a few years working within the realm of Internet politics, must accept that they are no longer just plain members of the public. You and I understand (or think we understand) all kinds of jargon that is inscrutrable to most members of the public including the vast majority of ARIN members. Check the recent postings to the ARIN-DISCUSS list to see what I mean. I believe that we need to reach out to include more people in policymaking rather than close ranks and keep newcomers out by bamboozling them with arcane terminology. > Don't be silly. Sure it does. ARIN and the other RIRs do not permit > independent trade in address space. Are you not aware of the numerous instances where people have bought and sold IPv4 address ranges using shell companies? The main thing that limits the trade in address space is that the courts do not consider IP addresses to be PROPERTY and therefore the courts will not enforce simple contracts of sale. If I wanted to I could sell you 199.167/16 and then turn around and sell it to someone in China and someone else in Australia. The best that you could do against me in court is to get your money back because I did not deliver ANYTHING at all. But you won't get the court to revoke the Chinese and Australian sales in favor of your sale. Since IP addresses are not property, there is no IP address market to regulate. > Well, an overall model exists, whether anyone says it is needed or > not. The current overall model is defined within the existing RIR > structures and policies which evolve over time. It is decentralized, > bottom-up driven and one operational component of that model is that > it currently disallows market-based mechanisms to improve address > utilization efficiencies in IPv4 for good or ill. If you want to call this an overall model, then fine. This is the way that it should be and I don't see any major problems with it, other than the fact that nobody gets to have things all their own way. > Michael: in my memory, this was probably the worst message you've > sent on this mailing list. Well, you can't win them all. ;-) --Michael Dillon From sleibrand at internap.com Mon May 8 08:26:37 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Mon, 8 May 2006 08:26:37 -0400 (EDT) Subject: [ppml] Address Space versus Routing Slots In-Reply-To: References: Message-ID: On 05/08/06 at 9:04am +0100, Michael.Dillon at btradianz.com wrote: > > and his participation on the ARIN public policy mailing list > > (participation in which isn't restricted to the ARIN region, BTW), > > doesn't constitute "interference". > > I never said that he should be kicked off the list. > Better to have opinions aired in public and discussed > in public rather than in the backrooms. Ok, cool. > What about the CONTENT of Geoff's message or > the CONTENT of my message? What do you think of > that? My take on the "what happens when the IANA and the RIRs run out of new space to give" is that we will likely end up with the buying and selling of IPv4 netblocks. As has been stated, the presence of a cheap substitute (IPv6) will likely keep the price for IPv4 netblocks down, but there will still be folks with a perceived "need" for IPv4 space. I don't like the idea of creating property rights for IPv4 addresses (and giving title to existing holders). However, I do think we'll have to legitimize a market for transferring registrations between organizations when said organizations contractually agree to do so (for monetary considerations or otherwise). If we put in place reasonable policies for such transfers, I think we reduce the likelihood of the courts stepping in and turning IP addresses into property. It may also be worthwhile for ARIN to regulate the manner in which netblocks may be subdivided. For example, if you are a /16 holder and want to transfer a /22, ARIN might reasonably require that you start from either the beginning or the end of your netblock range, so that only one record is required in WHOIS for each resulting netblock (as opposed to 3 total if the transferred /22 is out of the middle of the block). This will also help somewhat with maintaining CIDR aggregation. -Scott From Michael.Dillon at btradianz.com Mon May 8 09:12:18 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Mon, 8 May 2006 14:12:18 +0100 Subject: [ppml] Address Space versus Routing Slots In-Reply-To: Message-ID: > I don't like the idea of creating property rights for IPv4 addresses (and > giving title to existing holders). However, I do think we'll have to > legitimize a market for transferring registrations between organizations > when said organizations contractually agree to do so (for monetary > considerations or otherwise). If we put in place reasonable policies for > such transfers, I think we reduce the likelihood of the courts stepping in > and turning IP addresses into property. This is indeed something that ARIN may need to support by changing policies at that time. Currently companies can sell networks and the addresses transfer along with the rest of the SOFT assets. But in the IPv4 twilight scenario, companies are likely to be selling network equipment which is not capable of robust IPv6 support in its existing configuration. The buyers presumably are buying the equipment in order to stretch the lifetime of existing IPv4 services that they cannot migrate to v6 for technical or for ECONOMIC reasons. It seems reasonable for ARIN to consider a policy by which the company who is exiting the v4 world can also transfer v4 addresses to the company buying the equipment. Provided that the recipient can demonstrate a need for the QUANTITY of addresses being received. This may not be the total number of addresses being given up. Of course, this is all very hypothetical at this point in time since we do not know if there will EVER be a shortage of IPv4 addresses. If there is no shortage, then all talk of monetizing IPv4 addreses seems a bit early to me. --Michael Dillon From vaf at cisco.com Mon May 8 18:22:37 2006 From: vaf at cisco.com (Vince Fuller) Date: Mon, 8 May 2006 15:22:37 -0700 Subject: [ppml] Address Space versus Routing Slots In-Reply-To: References: Message-ID: <20060508222237.GA14758@vaf-lnx1.cisco.com> > Vince, one could wonder. I'm reading your slides from the GROW > presentation: > > > Is it worth doing an IAB-sponsored experiment, workshop, or > > other IETF-sanctioned activity along these lines to re-examine > > GSE or explore other solutions? > > You have been around the IETF long enough to know that the answer to > this is no, and will continue to be no for the foreseeable future. Why > put in on the table in the first place? Are there any developments that > I am not aware of that would make this fly without being another suicide > mission? Those slides were written in the spirit of optimism and playing nice within the IETF. In an earlier, less politically-correct version of the slides, that bullet point had some sort of plea for the IESG/IAB to not actively sabotage an effort should a group of people choose to start one. No doubt that is way too much ask, given the various egos and vested interests involved in the current failure-track "solution". > Reality check: PI sucks. Do you have a solution with reasonable chances > of adoption that sucks less? Not given the political climate within the IETF. But each of us has to tilt at a windmill once in a while. > If no, please support 2005-1. It sucks, but all the other alternatives > are worse. I won't support a proposal that is fundamentally wrong. Perhaps if or when the pain gets bad enough, there will be more impetus to solve the multihoming problem for real. I'll remark that the horse has probably been reduced to an oily smudge by now, so there probably isn't much point in continuing this discussion... :-) --Vince From michel at arneill-py.sacramento.ca.us Tue May 9 01:07:47 2006 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Mon, 8 May 2006 22:07:47 -0700 Subject: [ppml] Address Space versus Routing Slots Message-ID: > Vince Fuller wrote: > Those slides were written in the spirit of optimism and playing nice > within the IETF. In an earlier, less politically-correct version of > the slides, that bullet point had some sort of plea for the IESG/IAB > to not actively sabotage an effort should a group of people choose > to start one. No doubt that is way too much ask, given the various > egos and vested interests involved in the current failure-track > "solution". Sigh. >> Reality check: PI sucks. Do you have a solution with >> reasonable chances of adoption that sucks less? > Not given the political climate within the IETF. But each > of us has to tilt at a windmill once in a while. Guilty as charged. > there probably isn't much point in continuing this discussion... :-) Although we disagree on the course of action, we mostly agree on the assessment of the current situation. I felt that a few people in this discussion were well on their way to tilting at the same windmill; I hope I have convinced some not to embark in the same wild goose chase. Michel. From pekkas at netcore.fi Tue May 9 01:10:40 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 9 May 2006 08:10:40 +0300 (EEST) Subject: [ppml] Address Space versus Routing Slots In-Reply-To: <20060508222237.GA14758@vaf-lnx1.cisco.com> References: <20060508222237.GA14758@vaf-lnx1.cisco.com> Message-ID: On Mon, 8 May 2006, Vince Fuller wrote: >> If no, please support 2005-1. It sucks, but all the other alternatives >> are worse. > > I won't support a proposal that is fundamentally wrong. Perhaps if or > when the pain gets bad enough, there will be more impetus to solve the > multihoming problem for real. Vince has said it very well here and in other posts. Let me put in my two observations, - If the goal is to make PI available to pretty much everyone with zero or very little cost, the only even half-reasonable approach seems to be geographical allocation, with all of its warts and issues. At least that gives some hope of serious aggregation down the road, and if aggregated, minimizes sites' TE abuse of DFZ. - If the goal is to make PI available to O(1000) [or fewer] sites defined using some reasonable metric and with an annual fee, with a requirement (like with LIRs today) that the prefix be advertised with a single aggregated advertisement, the damage to the DFZ might be restricted enough. But I'm not sure whether such policy would be worth the effort, as it appears that many such sites have been getting aboard as LIRs and have obtained PA space.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owen at delong.com Tue May 9 01:51:16 2006 From: owen at delong.com (Owen DeLong) Date: Mon, 08 May 2006 22:51:16 -0700 Subject: [ppml] Address Space versus Routing Slots In-Reply-To: References: <20060508222237.GA14758@vaf-lnx1.cisco.com> Message-ID: <12F9C31E545AEEBD4BC0A9E4@odpwrbook.hq.netli.lan> > - If the goal is to make PI available to pretty much everyone with > zero or very little cost, the only even half-reasonable approach seems > to be geographical allocation, with all of its warts and issues. At > least that gives some hope of serious aggregation down the road, and > if aggregated, minimizes sites' TE abuse of DFZ. > Pekka, Aggregation is NOT the solution. The need for aggregation is proof that we have failed to develop a scalable routing architecture. Why are so many people determined to preserve this failure? It makes no sense to me. Why not look for a scalable routing solution that can be depolyed without requiring aggregation? Owen -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From pekkas at netcore.fi Tue May 9 01:55:08 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 9 May 2006 08:55:08 +0300 (EEST) Subject: [ppml] Address Space versus Routing Slots In-Reply-To: <12F9C31E545AEEBD4BC0A9E4@odpwrbook.hq.netli.lan> References: <20060508222237.GA14758@vaf-lnx1.cisco.com> <12F9C31E545AEEBD4BC0A9E4@odpwrbook.hq.netli.lan> Message-ID: On Mon, 8 May 2006, Owen DeLong wrote: >> - If the goal is to make PI available to pretty much everyone with >> zero or very little cost, the only even half-reasonable approach seems >> to be geographical allocation, with all of its warts and issues. At >> least that gives some hope of serious aggregation down the road, and >> if aggregated, minimizes sites' TE abuse of DFZ. > > Pekka, > Aggregation is NOT the solution. The need for aggregation is proof > that we have failed to develop a scalable routing architecture. Why > are so many people determined to preserve this failure? It makes no > sense to me. Why not look for a scalable routing solution that can > be depolyed without requiring aggregation? Indeed, aggregation is a stop-gap until we DO have a [more] scalable routing/multi-homing/... architecture. Until we do, being conservative seems like a prudent approach. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owen at delong.com Tue May 9 02:25:37 2006 From: owen at delong.com (Owen DeLong) Date: Mon, 08 May 2006 23:25:37 -0700 Subject: [ppml] Address Space versus Routing Slots In-Reply-To: References: <20060508222237.GA14758@vaf-lnx1.cisco.com> <12F9C31E545AEEBD4BC0A9E4@odpwrbook.hq.netli.lan> Message-ID: > Indeed, aggregation is a stop-gap until we DO have a [more] scalable > routing/multi-homing/... architecture. Until we do, being conservative > seems like a prudent approach. I'm inclined to think that 10 years without progress on this issue is an indication that conservatism is leading to neglect instead of spurring a solution. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From tli at tropos.com Tue May 9 03:52:15 2006 From: tli at tropos.com (Tony Li) Date: Tue, 9 May 2006 00:52:15 -0700 Subject: [ppml] Address Space versus Routing Slots In-Reply-To: <12F9C31E545AEEBD4BC0A9E4@odpwrbook.hq.netli.lan> Message-ID: <002d01c6733d$7d75a8a0$9801a8c0@tropos.com> > Aggregation is NOT the solution. The need for aggregation is proof > that we have failed to develop a scalable routing architecture. Why > are so many people determined to preserve this failure? It makes no > sense to me. Why not look for a scalable routing solution that can > be depolyed without requiring aggregation? A scalable routing architecture requires that the information content that is being exchanged scale at a rate that is substantially less (in order theoretic terms) than the number of nodes and sites that are being attached to the network. Abstraction of nodes into groups of nodes is the only possible method of significantly reducing the required amount of information. In routing terms, the abstraction of addressing (more specifically, locator) information is aggregation. Any other abstraction of locator information would also be aggregation. This is true for both geographic abstraction, topological abstraction, or "everyone who's surname starts with R" abstraction. All abstractions are likely to require exceptions. The number of these exceptions necessary to achieve adequate connectivity defines the efficiency of the abstraction scheme. Some abstractions are more efficient than others. Abstractions are frequently hierarchical (i.e., computer science tree structured), as a multi-level abstraction allows for gains in efficiency at higher levels and recapture of losses due to exceptions. A routing architecture is 'scalable' if the cost of running the architecture is 'reasonable'. Precise definitions of these terms is a judgement call. However, we have another technology known as 'bridging', where no abstraction occurs and the amount of control information scales linearly with the number of nodes in the network. This is currently thought to not be scalable to the size of the Internet. Regards, Tony From Michael.Dillon at btradianz.com Tue May 9 05:00:14 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 9 May 2006 10:00:14 +0100 Subject: [ppml] Address Space versus Routing Slots In-Reply-To: <12F9C31E545AEEBD4BC0A9E4@odpwrbook.hq.netli.lan> Message-ID: > Aggregation is NOT the solution. The need for aggregation is proof > that we have failed to develop a scalable routing architecture. On the contrary. The need for aggregation is proof that we have designed a hierarchical routing architecture that is based on aggregation. This started when CIDR was introduced and has been honed a bit since that time. Hierarchy is known to be the KEY STRUCTURE in creating scalability in networks. You may feel that you can create a more scalable network by using a different technique for creating hierarchy, i.e. hierarchical locators with a flat identifier space, however it is overstatement to say that aggregation is a sign of failure. > Why > are so many people determined to preserve this failure? It makes no > sense to me. Why not look for a scalable routing solution that can > be depolyed without requiring aggregation? I support your effort to find a scalable way in which to split locators and identifiers in IPv6. However, at the same time I believe in free competitive markets. That is why I also support the implementation of geo-topological addressing in IPv6. The two solutions are different in many ways. Geotopo addressing can be implemented sooner with no new protocols or router code changes. But locator/identifier split holds the promise of greater scalability (bigger sized network). Geotopo is closer to the current way of doing things which means that it is more likely to gain traction sooner and therefore provide benefits of reducing the global routing table size. But, if the locator/identifier split can be implemented and eventually supercede geotopo then that is not necessarily bad. It is called evolution. Along the way to the end game there are many solutions that are right for their time but which are ultimately discarded. They are just as essential as the end game because they help us attain that goal. Quite frankly, given the amount of work needed to design, implement and deploy a locator/identifier split, I would have thought you would welcome the breathing time given by a shorter term solution. One thing that would really kill locator/identifier split is to release it into the wild before it is completely figured out. And in the end, ARIN is a place for ADDRESS ALLOCATION policies which includes some form of geotopo algorithm. IETF is the place for new protocol design. Going back to the subject line... How can 2005-1 be implemented in a way that conserves future routing slots? Allow for future aggregation. The easy algorithm is to take a large reserve of IPv6 addresses and allocate west of the Mississippi from the bottom-up and east of the Mississippi from the bottom down. For the purposes of this algorithm, we should consider the Manitoba/Ontario border to be the northern continuation of the Mississippi and Nunavut should be in the west. The tougher algorithm, but still within ARIN's abilities to implement, would divide the region into 8 to 10 sub regions trying to focus on the centers of city clusters which have richer connectivity within the cluster than without. CAIDA could help with this determination although I suspect that a brute force technique of simply aggregating neighboring LATAs would work well enough. Unfortunately, a collection of LATAs has a hard boundary which really is against the geotopo principle of using center points of node clusters. The city is the archetypical centerpoint of a node cluster because it has very rich internal connectivity compared to external connectivity and the external connectivity tends to be directed to other city clusters. In order to do a full implementation of geotopo addressing using the 5,000 or so cities with population over 100,000 we would need the IETF to agree to set aside 1/8 of the IPv6 address space for geo-topological addressing and an allocation plan acceptable to geographers and economists. --Michael Dillon From owen at delong.com Tue May 9 06:34:22 2006 From: owen at delong.com (Owen DeLong) Date: Tue, 09 May 2006 03:34:22 -0700 Subject: [ppml] Address Space versus Routing Slots In-Reply-To: <002d01c6733d$7d75a8a0$9801a8c0@tropos.com> References: <002d01c6733d$7d75a8a0$9801a8c0@tropos.com> Message-ID: <13EC75ADC7B1FE010D99608D@odpwrbook.hq.netli.lan> Point well taken, Tony. What you say is absolutely true from an academic perspective. Permit me to clarify the pragmatic intent of my statement... When I referred to Aggregation, I meant prefix-based aggregation preserving the dual-purpose role of the IP address as both locator and end system identifier. I agree that topological locators should be hierarchical. However, because of the mobility of end systems, trying to make the topological locator part of the end system identifier is inherently prone to compromise in one or both purposes of said identifier. This is the problem we face today, and, while topologic rigidity can create a scalable routing architecture from a strictly cost of delivering routes perspective, the collateral costs (renumbering difficulty, multihoming limitations, protocol complexity, etc.) involved in doing so are quite high. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From weiler at tislabs.com Mon May 15 14:19:00 2006 From: weiler at tislabs.com (Sam Weiler) Date: Mon, 15 May 2006 14:19:00 -0400 (EDT) Subject: [ppml] Proposed Policy: RSA Modification Procedure - not accepted by AC as formal policy proposal In-Reply-To: <445B9208.9060700@arin.net> References: <445B9208.9060700@arin.net> Message-ID: On Fri, 5 May 2006, Member Services wrote: > "It is the sense of the Advisory Council that proposed policy 'RSA > Modification Procedure' is fundamentally an operational issue and thus > is a matter that can best be addressed by the ARIN Board of Trustees. > The Advisory Council will send this information to the ARIN Board of > Trustees." I disagree with the AC on this one. To the extent that RSA terms create significant barriers to getting resources, it's appropriate for those terms to come under scrutiny in the public policy process. That said, I still have some faith in the staff's ability to handle the details of contract negotiation, and I don't want to review every minor change to the RSA -- I'd like to leave most of the discretion to set contract terms in their hands. Hence I've crafted a policy proposal that isn't as broad as the one the AC just rejected. This proposal doesn't strictly force all RSA changes to go through public review. Instead, it just prevents ARIN from erecting a few particular barriers to getting resources without getting those barriers endorsed through the public policy process. I hope that we never need a proposal like this again. I hope that future changes in the prerequisites to getting access to resources, whether contractual or financial, are run by the community in an informal but effective way, much as ARIN did with a minor change to the IRPEP recently. If we find ourselves repeating this exercise even as often as once a year, then we probably need a policy as broad as the one the AC just rejected. In the meantime, I think this is a reasonable and less intrusive option. -- Sam 1. Policy Proposal Name: Requirement for Reasonable Contract Terms 2. Author Samuel Weiler weiler at tislabs.com SPARTA, Inc. 3. Proposal Version: 1 4. Submission Date: 15 May 2006 5. Proposal type: new 6. Policy term: permanent 7. Policy statement: ARIN may not require as a condition of any application, allocation, or assignment that the applicant enter into any agreement which either: 1) allows ARIN to modify the agreement without the explicit consent of the applicant, except via policy changes made through ARIN's public policy process, 2) allows ARIN to cancel or revoke an assignment or allocation for failure to execute some future agreement other than a periodic renewal of the same agreement, so long as the terms of the renewal agreement are unchanged or reflect only changes required by public policies, or 3) affects resources other than those being applied for, whether not yet assigned or previously assigned by ARIN, another registry, or another source. This policy shall be interpreted so as to prohibit ARIN from denying any application for resources on the grounds that an applicant has failed to make or indicated an unwillingness to make an agreement that is prohibited by this policy. 8. Rationale: This policy seeks to prevent ARIN from requiring certain abhorrent contract terms as a condition of obtaining or retaining resources without the explicit approval of those terms through the public policy process. ARIN's present registration services agreement (RSA) allows ARIN to unilaterally modify the RSA without any further consent from users of resources. The policy aims to prevent ARIN from including such terms in the RSA or any other prerequisite to getting an assignment (e.g., a membership agreement). Users of resources will still be able to voluntarily accept new RSA terms, if they so wish. Additionally, certain other RIRs require those applying for membership or resources to agree to accept those registries' terms for preexisting resources, whether assigned by that RIR, another RIR, or by another entity. Item 3 in this policy seeks to prevent ARIN from requiring such terms. It would still be possible to make public policy that imposes such requirements. 9. Timetable for implementation: Immediately upon approval. 10. Meeting presenter: Samuel Weiler From memsvcs at arin.net Tue May 16 12:50:14 2006 From: memsvcs at arin.net (Member Services) Date: Tue, 16 May 2006 12:50:14 -0400 Subject: [ppml] Proposed Policy: Requirement for Reasonable Contract Terms Message-ID: <446A02C6.20407@arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The ARIN Advisory Council (AC) will review this proposal and may decide to: 1. Accept the proposal as a formal policy proposal as it is presented; 2. Work with the author to: a) clarify the language or intent of the proposal; b) divide the proposal into two (2) or more proposals; or c) combine the proposal with other proposals; or, 3. Not accept the proposal as a formal policy proposal. Since this proposal was received within 10 days of the next scheduled meeting of the ARIN Advisory Council, the review period will be extended to the regularly scheduled meeting that occurs after the upcoming meeting. If the AC accepts the proposal or reaches an agreement with the author, then the proposal will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. If the AC does not accept the proposal or can not reach an agreement with the author, then the AC will notify the community of their decision with an explanation; at that time the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be considered closed. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Requirement for Reasonable Contract Terms Author: Samuel Weiler Proposal Version: 1 Submission Date: 15 May 2006 Proposal type: new Policy term: permanent Policy statement: ARIN may not require as a condition of any application, allocation, or assignment that the applicant enter into any agreement which either: 1) allows ARIN to modify the agreement without the explicit consent of the applicant, except via policy changes made through ARIN's public policy process, 2) allows ARIN to cancel or revoke an assignment or allocation for failure to execute some future agreement other than a periodic renewal of the same agreement, so long as the terms of the renewal agreement are unchanged or reflect only changes required by public policies, or 3) affects resources other than those being applied for, whether not yet assigned or previously assigned by ARIN, another registry, or another source. This policy shall be interpreted so as to prohibit ARIN from denying any application for resources on the grounds that an applicant has failed to make or indicated an unwillingness to make an agreement that is prohibited by this policy. Rationale: This policy seeks to prevent ARIN from requiring certain abhorrent contract terms as a condition of obtaining or retaining resources without the explicit approval of those terms through the public policy process. ARIN's present registration services agreement (RSA) allows ARIN to unilaterally modify the RSA without any further consent from users of resources. The policy aims to prevent ARIN from including such terms in the RSA or any other prerequisite to getting an assignment (e.g., a membership agreement). Users of resources will still be able to voluntarily accept new RSA terms, if they so wish. Additionally, certain other RIRs require those applying for membership or resources to agree to accept those registries' terms for preexisting resources, whether assigned by that RIR, another RIR, or by another entity. Item 3 in this policy seeks to prevent ARIN from requiring such terms. It would still be possible to make public policy that imposes such requirements. Timetable for implementation: Immediately upon approval. Meeting presenter: Samuel Weiler From aaronh at bind.com Fri May 19 18:10:21 2006 From: aaronh at bind.com (Aaron Hughes) Date: Fri, 19 May 2006 18:10:21 -0400 Subject: [ppml] Address Space versus Routing Slots In-Reply-To: References: Message-ID: <20060519221021.GD27227@user1.bind.com> On Sun, May 07, 2006 at 09:48:54PM -0400, Martin Hannigan wrote: > > BTW, our friend Aaron Hughes has an excellent "cheat sheet" on > prefix lengths and recently included v6. > > http://www.bind.com/netmasks.html > I had not finished this document when this link was posted and I wanted to make sure to give Joe Provo the credit for all of the v4 work which I copied from him in the mid 90s. My work on this document begins at the v6 section. Apologies for posting to the list for this, but I don't want to burn any bridges and wanted to make sure to give credit where credit is due. Cheers, Aaron -- Aaron Hughes aaronh at bind.com (703) 244-0427 Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8 http://www.bind.com/