From Michael.Dillon at btradianz.com Wed Feb 1 04:59:05 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 1 Feb 2006 09:59:05 +0000 Subject: [ppml] 2005-1 status In-Reply-To: Message-ID: > Here is an alternative version that starts with default assignment of > /48 and allows for more with justification for the extra subnets. > I'm not sure if "justify need for additional subnets" is clear enough. > What justifies the use of a subnet? ARIN policy has always been a bit fuzzy about justification. This is where the ARIN analysts exercize their judgement based on ARIN's prior experience with allocations. The closest that the NPRM comes to defining it is in section 8.3. > Please forgive me if I'm not doing this "correctly", but even though > I've lurked on this list for a while I have never participated in any > policy development processes. The only incorrect way to participate is silence. > In today's environment, an > organization does not have to be particularly "large" or "complex" to > have legitimate need for PI space and real multi-provider multi-homing. Existing policy doesn't fuss much about size and refers to "customer requirement" as a justification for addresses. For instance 4.2.3.6. > I saw this come up on the list a bit around a week ago, but have the > feeling that the provider community, which dominates this process, isn't > listening. I agree. ARIN's policies have been CAPTURED by a single interest group, largely due to lack of broad based member participation in the policymaking process. > It's > not that we (the customers) don't trust you, it's that in today's > regulatory/business environment we no longer are permitted to trust you. > If I don't have a solid plan for what to do quickly and painlessly to > switch ISP's, I lose my job or our customers or both. For better or for > worse, PI space and multi-homing are the answer du jour. Local multihoming based on geo-topological IPv6 addresses is also a workable solution to this issue. The main technical hurdle is that it requires use of IPv6 instead of IPv4. And the main policy hurdle is that it requires IANA and the RIRs to start allocated addresses out of a global block that is set aside for geo-topological addressing. Other than that, it can be implemented using today's technology unchanged. --Michael Dillon From Michael.Dillon at btradianz.com Wed Feb 1 05:07:02 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 1 Feb 2006 10:07:02 +0000 Subject: [ppml] IPv6 address as a Globally Unique ID? In-Reply-To: <43DFB2C9.2070305@nist.gov> Message-ID: > http://www.smart.gov/iab/documents/PACS.pdf This document does indeed state that their globally unique ID will be an IPv6 address. ARIN, the NRO and IANA should really send an official letter to the government telling them that this is not an appropriate use of an IPv6 address. For one thing, the rightmost 64 bits of the IPv6 address are already sufficient for a globally unique identifier. In addition there are models that the government could adopt for creating a 64-bit globally unique identifier such as the IEEE's EUI-64. However, it is wholly inappropriate to use an IPv6 address because these addresses are reserved for use by device interfaces which connect to IPv6 protocol networks. --Michael Dillon From Michael.Dillon at btradianz.com Wed Feb 1 05:15:22 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 1 Feb 2006 10:15:22 +0000 Subject: [ppml] 2005-1 status In-Reply-To: Message-ID: > On one side, if we do allow PI addressing to get out of hand, current > routing technology cannot scale to support it, and, the internet will > be incapable of maintaining a routing infrastructure. That's an exaggeration. You are assuming that ARIN will give out PI addresses randomly. Since policy is not yet cast in stone, this is not yet a valid assumption. People have suggested that such PI allocations be made out of a DESIGNATED BLOCK so that tools can distinguish PI addresses from normal IPv6 address blocks. If ARIN were to further ensure that these PI allocations could be aggregated by city or LATA then the scaling impact can be mitigated by aggregation of many small routes into one larger prefix for each city or LATA. Network operators will then only need to keep detail for PI users in the same city or LATA. Note that this is very much like geo-topological addressing on a regional (single RIR) scale. And we can do it today by making the appropriate ARIN policy. > A non-functional > internet or one in which some significant portion of addresses are > unreachable or unstable does not serve the end user or provider > constituencies. This is the extreme of one side of this issue, and, > the source of most of the anti-PI statements. ARIN has never guaranteed the routability of address prefixes. --Michael Dillon From owen at delong.com Wed Feb 1 07:32:47 2006 From: owen at delong.com (Owen DeLong) Date: Wed, 01 Feb 2006 04:32:47 -0800 Subject: [ppml] 2005-1 status In-Reply-To: References: Message-ID: <31B456E9549E0013AC57575F@odpwrbook.hq.netli.lan> --On February 1, 2006 10:15:22 AM +0000 Michael.Dillon at btradianz.com wrote: >> On one side, if we do allow PI addressing to get out of hand, current >> routing technology cannot scale to support it, and, the internet will >> be incapable of maintaining a routing infrastructure. > > That's an exaggeration. You are assuming that ARIN will > give out PI addresses randomly. Since policy is not yet > cast in stone, this is not yet a valid assumption. People > have suggested that such PI allocations be made out of > a DESIGNATED BLOCK so that tools can distinguish PI addresses > from normal IPv6 address blocks. > No, Michael, I'm beginning with the premise that it is what will happen if we ALLOW IT TO GET OUT OF HAND. I am not suggesting that allowing it to get out of hand is what will happen. I am not assuming that will happen. I am simply stating that is the consequence if it DOES get out of hand. I believe it is accurate as such. [snip]I remain unconvinced about your geo-centric addressing ideas. >> A non-functional >> internet or one in which some significant portion of addresses are >> unreachable or unstable does not serve the end user or provider >> constituencies. This is the extreme of one side of this issue, and, >> the source of most of the anti-PI statements. > > ARIN has never guaranteed the routability of address prefixes. > While that is true, and, remember, I'm supporting 2005-1... Heck, I'm the original AUTHOR... It's not like I'm opposed to granting PI space, and, I think I'm one of the more liberally focused people on the subject. The fact remains that if PI allocations cause the routing infrastructure to melt, it's bad for everyone. That's all I was saying. I did not comment on the expectation or likelihood of such an event, with or without this policy. For the record, I do not believe that passing Kevin's last revision to 2005-1 will lead to any of the scenarios described by the anti-PI contingent. I do not believe that there will be a run on ASNs, IPv6 addresses or anything else as a result. I do not believe that it will melt the routing infrastructure for several years to come at the very least. Frankly, if the IETF thinks I am wrong about this, then, they should start designing a new routing infrastructure that can support the requirements of the real world. Unfortunately, as much as you think end-users are underrepresented in ARIN (and I agree that they are, BTW), they are essentially unrepresented in IETF. I think last I looked, IETF seems to be about 90% vendors, 9% ISPs and about 1% everyone else (policy wonks, lobbyists, press, end-users, lookey-loos, etc.). I suspect that if end users were better represented in IETF, that a routing system that could accomodate PI space would not have been tossed aside as "too hard" so easily. The IETF used to do a much better job of understanding the true needs of end users. What has changed is the nature of the end users. It used to be that the end users were, by and large, also the network operators and protocol engineers. Now that John Q. Public is the norm and not the exception on the internet, I'm not sure that the IETF model of development scales so well. 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 Michael.Dillon at btradianz.com Wed Feb 1 07:57:02 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 1 Feb 2006 12:57:02 +0000 Subject: [ppml] 2005-1 status In-Reply-To: <31B456E9549E0013AC57575F@odpwrbook.hq.netli.lan> Message-ID: > Frankly, if the IETF thinks I am wrong about > this, then, they should start designing a new routing infrastructure > that can support the requirements of the real world. The IETF ceased being responsible for the Internet's routing structure at least a decade ago. Seems to me that all the recent advancements in routing have been driven by network operators or vendors or end users, often with no IETF involvement. > The IETF used to do a much better job of understanding the true > needs of end users. What has changed is the nature of the end users. > It used to be that the end users were, by and large, also the network > operators and protocol engineers. Now that John Q. Public is the > norm and not the exception on the internet, I'm not sure that the > IETF model of development scales so well. I think it has been shown that the IETF model of the 1980s did not scale and therefore in the first decade of the 21st century, we don't rely on the IETF to supply operational improvements to the Internet. However, the IETF model of open public discussion has scaled reasonably well in numerous other groups and organizations that tackle the various problems of the Internet. --Michael Dillon From paul at vix.com Wed Feb 1 10:28:19 2006 From: paul at vix.com (Paul Vixie) Date: Wed, 01 Feb 2006 15:28:19 +0000 Subject: [ppml] 2005-1 status In-Reply-To: Your message of "Wed, 01 Feb 2006 10:15:22 GMT." References: Message-ID: <20060201152819.91E3F11426@sa.vix.com> # If ARIN were to further ensure that these PI allocations could be aggregated # by city or LATA then the scaling impact can be mitigated by aggregation of # many small routes into one larger prefix for each city or LATA. Network # operators will then only need to keep detail for PI users in the same city # or LATA. urban legend alert! (we already beat this one to death, didn't we?) # Note that this is very much like geo-topological addressing on a regional # (single RIR) scale. And we can do it today by making the appropriate ARIN # policy. unless there's a contract between the address holder and the address allocator preventing portability, regional addressing is like an initial introductory interest rate on a credit card -- the benefit, if any, will be fleeting. a large isp could ensure nonportability of its regional addresses. so could a city government or metropolitan communications authority. but not an RIR. # > A non-functional internet or one in which some significant portion of # > addresses are unreachable or unstable does not serve the end user or # > provider constituencies. This is the extreme of one side of this issue, # > and, the source of most of the anti-PI statements. # # ARIN has never guaranteed the routability of address prefixes. and yet i don't see ARIN's policy process approving the allocation of any significant amount of nonrouteable address space. so while it's not any sort of guaranty, it sure as heck is a guiding principle for policymaking. From Michael.Dillon at btradianz.com Wed Feb 1 11:57:10 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 1 Feb 2006 16:57:10 +0000 Subject: [ppml] 2005-1 status In-Reply-To: <20060201152819.91E3F11426@sa.vix.com> Message-ID: > and yet i don't see ARIN's policy process approving the allocation of any > significant amount of nonrouteable address space. so while it's not any > sort of guaranty, it sure as heck is a guiding principle for policymaking. When we moved from a /19 starter prefix for ISPs to a /20 starter prefix, we did not know how many ISPs would accept /20 prefixes. It was known that some ISPs had filtering policies that would not accept /20s. However, ARIN still went ahead with the policy change knowing that it was likely that these ISPs would not have full routeability. But since we were only moving the goalposts a small amount, we expected that the majority of those with /19 filters would adjust then to accomodate the /20 routes since it was a modest change. In the same way, if ARIN starts to hand out /48 PI blocks to IPv6 users, we cannot guarantee that they will be routable and we know that there are some people who are filtering such routes. But because this is a modest change, i.e. it has the precondition of owning a v4 PI block, we expect that ISPs will adjust their practices. If we include in this policy that these /48s will come out of a specific address range which will not be used for other types of IPv6 allocation, then it is even more likely that ISPs will adjust their practices. So it is not necessary for an ISP practice to be in place before ARIN changes policy. It merely needs to be technically and practically feasible for many ISPs to change their practice in order for ARIN to go ahead. In some ways this is similar to the opening of a new address range. ARIN does not wait for bogon filters to be updated before issuing addresses from the new range. ARIN takes reasonable actions, publicizes those actions, and expects the rest of the world to take note and adjust to the new situation. The objection seems to be that there is a threshold beyond which the number of /48 prefixes will have a deleterious effect on Internet routing. Most agree that this is so and we are looking for a way to avoid quickly arriving at that situation. However, there is not much we can do about the fate-sharing problem given the current practice on the Internet. If we issue /48 prefixes from an identifiable range, then ISPs can treat those prefixes differently from other /48 prefixes based on the range. However, if the total number of such prefixes exceeds the threshold where it causes pain, then the only defensive action available is to filter all /48 addresses in the range. Or to randomly pick a subset of the range for such filtering. All PI users then share the same fate. In order to forestall that event, ARIN could define MULTIPLE ranges for these /48s defined by geography. Then, when we hit the threshold, ISPs have the option of only filtering those /48s which are not local to them, i.e. not in the same geographical range. This is done by proxy aggregation and it is not simple for a truly national or international ISP to deal with at present, but then this threshold event is not likely to hit us right away. In the meantime it seems prudent for ARIN to take this action which causes no current harm, allows for people to experiment with geographical addressing and routing, and provides an out in the event that the numbers of PI allocations exceed our expectations. --Michael Dillon From narten at us.ibm.com Wed Feb 1 13:22:33 2006 From: narten at us.ibm.com (Thomas Narten) Date: Wed, 01 Feb 2006 13:22:33 -0500 Subject: [ppml] IPv6 address as a Globally Unique ID? In-Reply-To: Message from Michael.Dillon@btradianz.com of "Wed, 01 Feb 2006 10:07:02 GMT." Message-ID: <200602011822.k11IMXaJ000318@rotala.raleigh.ibm.com> Thanks for pointing this out. Seems pretty broken at first glance. I'm following up with folk on the IETF side to see what can/should be done to followup. Thomas Michael.Dillon at btradianz.com writes: > > http://www.smart.gov/iab/documents/PACS.pdf > This document does indeed state that their globally > unique ID will be an IPv6 address. ARIN, the NRO and IANA > should really send an official letter to the government > telling them that this is not an appropriate use of > an IPv6 address. > For one thing, the rightmost 64 bits of the IPv6 address > are already sufficient for a globally unique identifier. > In addition there are models that the government could adopt > for creating a 64-bit globally unique identifier such as > the IEEE's EUI-64. > However, it is wholly inappropriate to use an IPv6 address > because these addresses are reserved for use by device > interfaces which connect to IPv6 protocol networks. > --Michael Dillon > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From hannigan at renesys.com Wed Feb 1 13:49:10 2006 From: hannigan at renesys.com (Martin Hannigan) Date: Wed, 1 Feb 2006 13:49:10 -0500 Subject: [ppml] IPv6 address as a Globally Unique ID? In-Reply-To: <200602011822.k11IMXaJ000318@rotala.raleigh.ibm.com> References: <200602011822.k11IMXaJ000318@rotala.raleigh.ibm.com> Message-ID: >Thanks for pointing this out. Seems pretty broken at first glance. I'm >following up with folk on the IETF side to see what can/should be done >to followup. > >Thomas > >Michael.Dillon at btradianz.com writes: > > > > http://www.smart.gov/iab/documents/PACS.pdf I think a clarification should requested first. That clarification should ask whether the cards are intended to interface with the network, or not. If they are, they are technically devices and if someone decides to utilize them as unique identifierfor a secondary purpose, I'm not sure that it's a problem. For example, Cisco VMPS utilizes the username+mac-addr to authorize a login against a matrix of security permissions. This is not a unique idea. -M< -- Martin Hannigan (c) 617-388-2663 Renesys Corporation (w) 617-395-8574 Member of the Technical Staff Network Operations hannigan at renesys.com From tony.li at tony.li Wed Feb 1 13:53:08 2006 From: tony.li at tony.li (Tony Li) Date: Wed, 01 Feb 2006 10:53:08 -0800 Subject: [ppml] 2005-1 status In-Reply-To: References: Message-ID: <43E10394.7030307@tony.li> >> Frankly, if the IETF thinks I am wrong about >> this, then, they should start designing a new routing infrastructure >> that can support the requirements of the real world. > > The IETF ceased being responsible for the Internet's > routing structure at least a decade ago. Seems to > me that all the recent advancements in routing have > been driven by network operators or vendors or > end users, often with no IETF involvement. Actually, I would say that the IETF is still responsible, but continues to avoid making the hard choices that go along with changing the fundamental routing architecture. And, as there's currently nowhere else that can reasonably act as a forum for building consensus about the architecture. Tony From randy at psg.com Wed Feb 1 14:08:52 2006 From: randy at psg.com (Randy Bush) Date: Wed, 1 Feb 2006 11:08:52 -0800 Subject: [ppml] 2005-1 status References: <43E10394.7030307@tony.li> Message-ID: <17377.1860.948070.970700@roam.psg.com> > Actually, I would say that the IETF is still responsible, but continues > to avoid making the hard choices that go along with changing the > fundamental routing architecture. you, dr. bug, specifically said that, post-kobe, the ietf was not responsible for architecture. so it would seem hard for you to blame the ietf. i, on the other hand, disagree with you on that lack of responsibility. they just don't meet it. randy From drc at virtualized.org Wed Feb 1 14:13:16 2006 From: drc at virtualized.org (David Conrad) Date: Wed, 1 Feb 2006 11:13:16 -0800 Subject: [ppml] IPv6 address as a Globally Unique ID? In-Reply-To: References: <200602011822.k11IMXaJ000318@rotala.raleigh.ibm.com> Message-ID: Martin, On Feb 1, 2006, at 10:49 AM, Martin Hannigan wrote: > I think a clarification should requested first. That clarification > should ask whether the cards are intended to interface with the > network, or not. If they are, they are technically devices and if > someone > decides to utilize them as unique identifierfor a secondary > purpose, I'm > not sure that it's a problem. If they are intended to be connected to the network and the addresses are assigned to the person, then it would be a problem (assuming provider-based routing is still the routing paradigm in use). 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 bmanning at vacation.karoshi.com Wed Feb 1 14:17:04 2006 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 1 Feb 2006 19:17:04 +0000 Subject: [ppml] IPv6 address as a Globally Unique ID? In-Reply-To: References: <200602011822.k11IMXaJ000318@rotala.raleigh.ibm.com> Message-ID: <20060201191704.GA25143@vacation.karoshi.com.> On Wed, Feb 01, 2006 at 11:13:16AM -0800, David Conrad wrote: > Martin, > > On Feb 1, 2006, at 10:49 AM, Martin Hannigan wrote: > > I think a clarification should requested first. That clarification > > should ask whether the cards are intended to interface with the > > network, or not. If they are, they are technically devices and if > > someone > > decides to utilize them as unique identifierfor a secondary > > purpose, I'm > > not sure that it's a problem. > > If they are intended to be connected to the network and the addresses > are assigned to the person, then it would be a problem (assuming > provider-based routing is still the routing paradigm in use). that presumes something about the federal network, no? --bill > > 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 From tony.li at tony.li Wed Feb 1 14:33:31 2006 From: tony.li at tony.li (Tony Li) Date: Wed, 01 Feb 2006 11:33:31 -0800 Subject: [ppml] 2005-1 status In-Reply-To: <17377.1860.948070.970700@roam.psg.com> References: <43E10394.7030307@tony.li> <17377.1860.948070.970700@roam.psg.com> Message-ID: <43E10D0B.7060209@tony.li> Randy, >> Actually, I would say that the IETF is still responsible, but continues >> to avoid making the hard choices that go along with changing the >> fundamental routing architecture. > > you, dr. bug, specifically said that, post-kobe, the ietf was not > responsible for architecture. so it would seem hard for you to > blame the ietf. Actually, I believe the point that I was trying to make was that the IETF needed to step up and make architectural decisions consistently and across the board. The IETF must not use its architectural sword in an ad hoc manner to strike at various specific proposals. Doing so will turn architecture into simply a tool to be used for personal crusades rather than a force for the common good. > i, on the other hand, disagree with you on that lack of responsibility. > they just don't meet it. Allow me to clarify: given the lack of other parties, I believe that the IETF still holds the responsibility for architecture. Historically, they were tasked with, and acted to create and maintain the architecture. I believe it is still part of their charter. I vehemently don't believe that they are fulfilling that responsibility and that the community should seriously consider supporting any other group that would care to shoulder the load, thereby transferring the responsibility. So far, I have seen no other credible contenders. Tony From hannigan at renesys.com Wed Feb 1 14:33:31 2006 From: hannigan at renesys.com (Martin Hannigan) Date: Wed, 1 Feb 2006 14:33:31 -0500 Subject: [ppml] IPv6 address as a Globally Unique ID? In-Reply-To: <20060201191704.GA25143@vacation.karoshi.com.> References: <200602011822.k11IMXaJ000318@rotala.raleigh.ibm.com> <20060201191704.GA25143@vacation.karoshi.com.> Message-ID: >On Wed, Feb 01, 2006 at 11:13:16AM -0800, David Conrad wrote: >> Martin, >> >> On Feb 1, 2006, at 10:49 AM, Martin Hannigan wrote: >> > I think a clarification should requested first. That clarification >> > should ask whether the cards are intended to interface with the >> > network, or not. If they are, they are technically devices and if >> > someone >> > decides to utilize them as unique identifierfor a secondary >> > purpose, I'm >> > not sure that it's a problem. >> >> If they are intended to be connected to the network and the addresses >> are assigned to the person, then it would be a problem (assuming >> provider-based routing is still the routing paradigm in use). > > that presumes something about the federal network, no? Yes and that is an operational issue. I'm supporting the position that the card is a device eligible to be "addressed" in one way or another and that secondary uses are not unauthorized by any policy. I would not support policies that restrict uses of addresses for other purposes since it is technically only possible to use the addresses as designed, for network devices. If others "key" off of an IPV6 address as an identifier, that's a mistake on their part, but that shouldn't be a consideration in allocating the space. Again, I'll offer Cisco+VMPS as an example of this is not a unique idea. I am hesitant to share my personal opinion of it though since it is tough to see where the technical issue ends and the political problem ensues. -M< -- Martin Hannigan (c) 617-388-2663 Renesys Corporation (w) 617-395-8574 Member of the Technical Staff Network Operations hannigan at renesys.com From George.Kuzmowycz at aipso.com Wed Feb 1 16:07:08 2006 From: George.Kuzmowycz at aipso.com (George Kuzmowycz) Date: Wed, 01 Feb 2006 16:07:08 -0500 Subject: [ppml] 2005-1 status Message-ID: >>> 02/01/2006 4:59:05 AM >>> > It's > not that we (the customers) don't trust you, it's that in today's > regulatory/business environment we no longer are permitted to trust you. > If I don't have a solid plan for what to do quickly and painlessly to > switch ISP's, I lose my job or our customers or both. For better or for > worse, PI space and multi-homing are the answer du jour. Local multihoming based on geo-topological IPv6 addresses is also a workable solution to this issue. The main technical hurdle is that it requires use of IPv6 instead of IPv4. And the main policy hurdle is that it requires IANA and the RIRs to start allocated addresses out of a global block that is set aside for geo-topological addressing. Other than that, it can be implemented using today's technology unchanged. >>> I freely admit I'm not up to speed on this (and I recognize from subsequent discussion that it's not a consensus position). Can you point me to a starting point for reading? I also freely admit that I've got a ways to go in catching up with the IPv6 discussions. Part of the problem is that it seems to this newcomer like a bunch of people who have known each other forever and who staked out their positions a decade ago, and have been talking past each other ever since. Out here in the real world, real multi-homing and customer-level traffic engineering (or attempted traffic engineering) are genies that aren't going to go back in the bottle. You can deconstruct my last message all you want as to "needs" or "wants", but when the people who sign the contracts and spend the money say they "want" something, telling them that they don't "need" it doesn't sound like a good strategy. From Lee.Howard at stanleyassociates.com Wed Feb 1 16:15:57 2006 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Wed, 1 Feb 2006 16:15:57 -0500 Subject: [ppml] 2005-1 status Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB4012CC3AA@CL-S-EX-1.stanleyassociates.com> > aren't going to go back in the bottle. You can deconstruct my last > message all you want as to "needs" or "wants", but when the people who > sign the contracts and spend the money say they "want" something, > telling them that they don't "need" it doesn't sound like a good > strategy. As a competitive ISP, that would sound like a bad strategy. As a stewardship organization, the good of the whole trumps the desire of the one with the checkbook. If we can accomodate both, then by all means let's do. Running out of addresses again or building in unscalable structures sound like they'd be bad for the whole. Some of us disagree on the likelihood of those propositions, so we debate. Smart people can come to different beliefs of what the future will bring. Lee From owen at delong.com Wed Feb 1 16:24:25 2006 From: owen at delong.com (Owen DeLong) Date: Wed, 01 Feb 2006 13:24:25 -0800 Subject: [ppml] 2005-1 status In-Reply-To: References: Message-ID: --On February 1, 2006 12:57:02 PM +0000 Michael.Dillon at btradianz.com wrote: >> Frankly, if the IETF thinks I am wrong about >> this, then, they should start designing a new routing infrastructure >> that can support the requirements of the real world. > > The IETF ceased being responsible for the Internet's > routing structure at least a decade ago. Seems to > me that all the recent advancements in routing have > been driven by network operators or vendors or > end users, often with no IETF involvement. > I don't believe that any of the forces you mentioned have ever made a fundamental change to the way we do routing. Sure, they have made changes to the internal function of routers, but, the switch from BGP3 to BGP4 (which was the last significant change in routing structure) was done by IETF. What is needed now is a fundamental change in the routing architecture and protocol. BGP4 will not scale. We have to come up with a way to separate the interdomain topological locator from the End System Identifier. We need to have some mechanism for aggregating paths to said topological locators. Finally, we need some mechanism for quickly and securely mapping End System Identifiers to topological locators at the edge of the default-free zone. Such a change is not likely to come from operators, vendors or end users. >> The IETF used to do a much better job of understanding the true >> needs of end users. What has changed is the nature of the end users. >> It used to be that the end users were, by and large, also the network >> operators and protocol engineers. Now that John Q. Public is the >> norm and not the exception on the internet, I'm not sure that the >> IETF model of development scales so well. > > I think it has been shown that the IETF model of the 1980s > did not scale and therefore in the first decade of the > 21st century, we don't rely on the IETF to supply operational > improvements to the Internet. > So you're saying that IETF isn't responsible for IPv6? Other than things which can be implemented on a site-by-site basis without requiring a change in the protocol, I don't believe there have been any operational improvements in the internet outside of the IETF process. > However, the IETF model of open public discussion has scaled > reasonably well in numerous other groups and organizations that > tackle the various problems of the Internet. > The model of open public discussion can scale well if there is appropriate representation of the stakeholders and good moderation and facilitation of the discussion. However, over time, almost every group loses or fails to achieve at least one of these two properties. I am not opposed to the model... Indeed, I think it is the best model. However, it does have flaws and an awareness of those flaws is important. 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 Wed Feb 1 16:40:05 2006 From: owen at delong.com (Owen DeLong) Date: Wed, 01 Feb 2006 13:40:05 -0800 Subject: [ppml] 2005-1 status In-Reply-To: References: Message-ID: --On February 1, 2006 4:57:10 PM +0000 Michael.Dillon at btradianz.com wrote: >> and yet i don't see ARIN's policy process approving the allocation of > any >> significant amount of nonrouteable address space. so while it's not any >> sort of guaranty, it sure as heck is a guiding principle for > policymaking. > > When we moved from a /19 starter prefix for ISPs to > a /20 starter prefix, we did not know how many ISPs > would accept /20 prefixes. It was known that some ISPs > had filtering policies that would not accept /20s. > > However, ARIN still went ahead with the policy change > knowing that it was likely that these ISPs would not > have full routeability. But since we were only moving the > goalposts a small amount, we expected that the majority > of those with /19 filters would adjust then to accomodate > the /20 routes since it was a modest change. > It was also done in such a way that we made it clear to the ISPs at first that the /19 was reserved for them and they could get away with announcing the /19 if necessary. It was also pretty clear in the room that the majority of ISPs intended to update their filters to match ARIN's changes. The same was true when we passed 2002-3 which changed the minimum PI direct assignment from /20 to /22. > In the same way, if ARIN starts to hand out /48 PI blocks > to IPv6 users, we cannot guarantee that they will be routable > and we know that there are some people who are filtering > such routes. But because this is a modest change, i.e. it > has the precondition of owning a v4 PI block, we expect that > ISPs will adjust their practices. If we include in this policy > that these /48s will come out of a specific address range which > will not be used for other types of IPv6 allocation, then it > is even more likely that ISPs will adjust their practices. > Because of the participation we have seen and based on past practices, we have a reasonable expectation that routing policy will evolve to match ARIN policy in this matter. However, as it currently stands, it's hard to think of v6 as globally routable anyway. [snip] 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 sleibrand at internap.com Wed Feb 1 21:26:22 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 1 Feb 2006 21:26:22 -0500 (EST) Subject: [ppml] 2005-1 status In-Reply-To: References: Message-ID: Michael, Say ARIN defines a netblock for PI allocations, and allocates /44 through /32's out of it (IIRC /44 is the minimum allocation size in the current policy proposal, not /48). Then say APNIC and RIPE each decide to do the same, followed by LACNIC and AfriNIC. Now you have 5 different geographically identifiable ranges from which PI space is allocated. If at some point we have too many routes for routers to handle, operators in each region could safely filter smaller routes from the other regions, as long as they set up aggregate routes pointing in the right direction, or get their peers in the other regions to advertise the aggregates to them. That seems to me the extent to which geotopological addressing will be feasible in the real world, where NSPs operate continental or global backbones. And if the current iteration of 2005-1 gets approved, we may end up there sooner than we expect. IMO giving PI space to anyone multihomed with PA /48's from two providers is going to dramatically increase the rate of routing table growth over what we've seen with IPv4. If we're willing to deal with that using tricks like the one described above, fine, but I think we should seriously consider only issuing PI space to users whose size or network complexity makes the use of PA space for multihoming impractical. -Scott On 02/01/06 at 4:57pm -0000, Michael.Dillon at btradianz.com wrote: > > and yet i don't see ARIN's policy process approving the allocation of > any > > significant amount of nonrouteable address space. so while it's not any > > sort of guaranty, it sure as heck is a guiding principle for > policymaking. > > When we moved from a /19 starter prefix for ISPs to > a /20 starter prefix, we did not know how many ISPs > would accept /20 prefixes. It was known that some ISPs > had filtering policies that would not accept /20s. > > However, ARIN still went ahead with the policy change > knowing that it was likely that these ISPs would not > have full routeability. But since we were only moving the > goalposts a small amount, we expected that the majority > of those with /19 filters would adjust then to accomodate > the /20 routes since it was a modest change. > > In the same way, if ARIN starts to hand out /48 PI blocks > to IPv6 users, we cannot guarantee that they will be routable > and we know that there are some people who are filtering > such routes. But because this is a modest change, i.e. it > has the precondition of owning a v4 PI block, we expect that > ISPs will adjust their practices. If we include in this policy > that these /48s will come out of a specific address range which > will not be used for other types of IPv6 allocation, then it > is even more likely that ISPs will adjust their practices. > > So it is not necessary for an ISP practice to be in place > before ARIN changes policy. It merely needs to be technically > and practically feasible for many ISPs to change their practice > in order for ARIN to go ahead. In some ways this is similar to > the opening of a new address range. ARIN does not wait for bogon > filters to be updated before issuing addresses from the new range. > ARIN takes reasonable actions, publicizes those actions, and > expects the rest of the world to take note and adjust to the > new situation. > > The objection seems to be that there is a threshold beyond > which the number of /48 prefixes will have a deleterious > effect on Internet routing. Most agree that this is so and > we are looking for a way to avoid quickly arriving at that > situation. However, there is not much we can do about the > fate-sharing problem given the current practice on the Internet. > > If we issue /48 prefixes from an identifiable range, then > ISPs can treat those prefixes differently from other /48 > prefixes based on the range. However, if the total number of > such prefixes exceeds the threshold where it causes pain, > then the only defensive action available is to filter all > /48 addresses in the range. Or to randomly pick a subset > of the range for such filtering. All PI users then share > the same fate. > > In order to forestall that event, ARIN could define > MULTIPLE ranges for these /48s defined by geography. > Then, when we hit the threshold, ISPs have the option > of only filtering those /48s which are not local to > them, i.e. not in the same geographical range. This > is done by proxy aggregation and it is not simple for > a truly national or international ISP to deal with > at present, but then this threshold event is not likely > to hit us right away. > > In the meantime it seems prudent for ARIN to take this > action which causes no current harm, allows for people > to experiment with geographical addressing and routing, > and provides an out in the event that the numbers of > PI allocations exceed our expectations. > > --Michael Dillon > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From sleibrand at internap.com Wed Feb 1 21:35:16 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 1 Feb 2006 21:35:16 -0500 (EST) Subject: [ppml] 2005-1 status In-Reply-To: References: Message-ID: George, I think we all agree that enterprises need to be able to multihome, switch ISPs, and traffic engineer. But the devil is in the details, i.e. how. It sounds like you represent a large network that would qualify for IPv4 PI space, and for whom PA space is unreasonable because of the renumbering difficulty. So I wanted to get your opinion on the point I've been trying to introduce into the discussion: at what point along the spectrum from a home user to a large multinational corporation does PI space become the best (or only) option for effective multihoming? I know a home user doesn't need PI space: an IPv6 prefix from each of his ISPs (or his and his neighbors) would suffice. But does a small business with a single location need PI space to multihome? What about about a larger business with a hundred employees and a branch office or two? As I've stated before, I really think we need to set up the policy such that only the people for whom PI space is the only reasonable option will go that route. If we give PI space out to anyone with two ISPs, I'm pretty sure we're cause a marked increase in routing table growth over what we've seen with IPv4. -Scott On 02/01/06 at 4:07pm -0500, George Kuzmowycz ...: > >>> 02/01/2006 4:59:05 AM >>> > > It's > > not that we (the customers) don't trust you, it's that in today's > > regulatory/business environment we no longer are permitted to trust > you. > > If I don't have a solid plan for what to do quickly and painlessly > to > > switch ISP's, I lose my job or our customers or both. For better or > for > > worse, PI space and multi-homing are the answer du jour. > > Local multihoming based on geo-topological IPv6 addresses is > also a workable solution to this issue. The main technical hurdle > is that it requires use of IPv6 instead of IPv4. And the main > policy hurdle is that it requires IANA and the RIRs to start > allocated addresses out of a global block that is set aside for > geo-topological addressing. Other than that, it can be implemented > using today's technology unchanged. > >>> > > I freely admit I'm not up to speed on this (and I recognize from > subsequent discussion that it's not a consensus position). Can you point > me to a starting point for reading? > > I also freely admit that I've got a ways to go in catching up with the > IPv6 discussions. Part of the problem is that it seems to this newcomer > like a bunch of people who have known each other forever and who staked > out their positions a decade ago, and have been talking past each other > ever since. > > Out here in the real world, real multi-homing and customer-level > traffic engineering (or attempted traffic engineering) are genies that > aren't going to go back in the bottle. You can deconstruct my last > message all you want as to "needs" or "wants", but when the people who > sign the contracts and spend the money say they "want" something, > telling them that they don't "need" it doesn't sound like a good > strategy. > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From randy at psg.com Wed Feb 1 22:13:20 2006 From: randy at psg.com (Randy Bush) Date: Wed, 1 Feb 2006 19:13:20 -0800 Subject: [ppml] 2005-1 status References: Message-ID: <17377.30928.662512.909659@roam.psg.com> > I know a home user doesn't need PI space: hmmm. they have no IT department to help them renumber while the enterprise does. and it will keep the IT folk occupied, instead of spending their time saving the organization money by making the lives of the actual working folk less productive in the name of homogenization and efficiency. :-)/2 hmmm. maybe the home user's border devices can do something like nat. or some way to separate the home's internals from the external routing issues. hmmm. i wonder if something like that would work for the enterprise. you know, site multihoming with something that separates loc/routing from internal namespace. mo is less! :-) randy From kloch at hotnic.net Wed Feb 1 23:14:22 2006 From: kloch at hotnic.net (Kevin Loch) Date: Wed, 01 Feb 2006 23:14:22 -0500 Subject: [ppml] 2005-1 status In-Reply-To: References: Message-ID: <43E1871E.2090403@hotnic.net> Scott Leibrand wrote: > So I wanted to get your opinion on the point I've been trying > to introduce into the discussion: at what point along the spectrum from a > home user to a large multinational corporation does PI space become the > best (or only) option for effective multihoming? Unfortunately we simply don't know yet. There certainly isn't anything resembling a consensus on where the dividing line should be. For that reason the latest revision proposals simply permit anyone with an IPv4 allocation/assignment to get an IPv6 assignment. The idea is that those networks have already been evaluated by the best methods we currently have. Gauging the merits of IPv6 only networks is something that will take further work. The concern over a flood of non-IPv4-pi applicants is valid but greatly overstated. How many non-isp networks in the ARIN reigon are multihomed right now with IPv6 and have /48's swipped from two different ISP's? I'm guessing not very many. As we gain experience with these assignments we can revise the policy if necessary. - Kevin From bonomi at mail.r-bonomi.com Wed Feb 1 23:27:56 2006 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Wed, 1 Feb 2006 22:27:56 -0600 (CST) Subject: [ppml] 2005-1 status Message-ID: <200602020427.k124RuAa008973@s25.firmware.com> > From ppml-bounces at arin.net Wed Feb 1 21:13:31 2006 > From: Randy Bush > Date: Wed, 1 Feb 2006 19:13:20 -0800 > To: Scott Leibrand > Cc: ppml at arin.net > Subject: Re: [ppml] 2005-1 status > > > I know a home user doesn't need PI space: > > hmmm. they have no IT department to help them renumber while the > enterprise does. and it will keep the IT folk occupied, instead > of spending their time saving the organization money by making > the lives of the actual working folk less productive in the name > of homogenization and efficiency. :-)/2 > > hmmm. maybe the home user's border devices can do something like > nat. or some way to separate the home's internals from the > external routing issues. > > hmmm. i wonder if something like that would work for the > enterprise. you know, site multihoming with something that > separates loc/routing from internal namespace. > > mo is less! :-) > > > > randy > I've got to be missing something... What about all end-node nets use the "this" network for all internal nodes, with minimal NAT (add/remove actual network prefix) at the external interfaces. DNS zones, obviously, have to know/supply the actual network prefix as well as the 'this network' node address. Is there anything else that passes (potentially) _off_network_ IP addresses in the data portion of the packet? ('on network' addresses can be reconstructed from 'this' network, by the simple expedient of combining the 'this' network host address, with the actual network prefix from the packet source address.) From owen at delong.com Thu Feb 2 01:34:52 2006 From: owen at delong.com (Owen DeLong) Date: Wed, 01 Feb 2006 22:34:52 -0800 Subject: [ppml] 2005-1 status In-Reply-To: References: Message-ID: <9FBE3DF07B8FE83D3CD4484C@odpwrbook.hq.netli.lan> --On February 1, 2006 9:35:16 PM -0500 Scott Leibrand wrote: > George, > > I think we all agree that enterprises need to be able to multihome, switch > ISPs, and traffic engineer. But the devil is in the details, i.e. how. > It sounds like you represent a large network that would qualify for IPv4 > PI space, and for whom PA space is unreasonable because of the renumbering > difficulty. So I wanted to get your opinion on the point I've been trying > to introduce into the discussion: at what point along the spectrum from a > home user to a large multinational corporation does PI space become the > best (or only) option for effective multihoming? > Scott, With all due respect, I think you are asking the wrong question. That question boils down to how can we optimize who we give full citizenship in the internet to and who we treat as second class citizens. I think instead, we should be asking "How do we accomodate everyone who needs PA space?" Todays routing paradigm will not do it. We know that. As such, I think the question then shifts to "How long should we continue to accept a routing paradigm which is known not to meet the needs of all of the constituents of the internet? How hard should we work and how many entities are we willing to penalize in order to preserve the status quo?" > I know a home user doesn't need PI space: an IPv6 prefix from each of his > ISPs (or his and his neighbors) would suffice. But does a small business > with a single location need PI space to multihome? What about about a > larger business with a hundred employees and a branch office or two? > How do you know this? Granted, I agree that the home user that needs this today is few and far between. However, as more and more people and families become generators and not just consumers of content, I believe this will change in the long run. Certainly there are many small businesses with single locations that may need PI space to multihome effectively. Some may need it even if they are not multihomed in order to accomodate the ability to switch providers without having to address configurations an a vast number of devices they do not control. However, most such businesses are multihomed today, so, I can live with multihoming as a base threshold for now. Certainly, the larger the organization gets, the higher the percentage you will find needing PI space today. > As I've stated before, I really think we need to set up the policy such > that only the people for whom PI space is the only reasonable option will > go that route. If we give PI space out to anyone with two ISPs, I'm > pretty sure we're cause a marked increase in routing table growth over > what we've seen with IPv4. > That may be true. My question is: "Should we continue to penalize the end users in order to prevent this, or, should we instead start insisting on an improved routing paradigm that takes this need into account." I realize ARIN can't redesign the routing system, but, we can decide whether we want to base policy on preservation of the status quo, or, instead on the needs of all of our constituencies. 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 hannigan at renesys.com Thu Feb 2 02:17:20 2006 From: hannigan at renesys.com (Martin Hannigan) Date: Thu, 2 Feb 2006 02:17:20 -0500 Subject: [ppml] 2005-1 status In-Reply-To: References: Message-ID: > > >I know a home user doesn't need PI space: an IPv6 prefix from each of his >ISPs (or his and his neighbors) would suffice. But does a small business >with a single location need PI space to multihome? What about about a >larger business with a hundred employees and a branch office or two? > I'm convinced that home users will be multi-homed off each other in the near future and will need PI space to accomplish it across multiple providers or others willing to sublet bandwidth to others during outages. I think schemes like this are going to scale internet bandwidth factors beyond the existing only because we're just beginning to innovate ways to utlize all the dead air. P2P on iPods for music/video purchase and forwarding of payments at a public AP anyone? We may not immediately need PI for home users, but let's not stifle innovation. I have always felt that ALL space should be PI since it promotes independence and competition. The realities of engineering have altered that. We really don't need to give in. There will be money in resolving the routing table bloat problem that could occur down the road (agreeing with Owen's earlier comments). Getting back to reality, I think PI space does nothing but allow for independence and promote competition. I am all for PI every where when we can figure out how to route it all. In the meantime, it looks like I'm supporting 2005-1 the way it's going. -M< -- Martin Hannigan (c) 617-388-2663 Renesys Corporation (w) 617-395-8574 Member of the Technical Staff Network Operations hannigan at renesys.com From Michael.Dillon at btradianz.com Thu Feb 2 04:39:07 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Thu, 2 Feb 2006 09:39:07 +0000 Subject: [ppml] 2005-1 status In-Reply-To: Message-ID: > I freely admit I'm not up to speed on this (and I recognize from > subsequent discussion that it's not a consensus position). Can you point > me to a starting point for reading? You can find some discussion in the email messages here: http://lists.arin.net/pipermail/ppml/2005-November/thread.html that have "geo addressing" in their subject. > Part of the problem is that it seems to this newcomer > like a bunch of people who have known each other forever and who staked > out their positions a decade ago, and have been talking past each other > ever since. The way to change this is for newcomers to speak up, state their mind, and especially, ask tough questions. This is a discussion list and everyone has a right to be here and join in. --Michael Dillon From Michael.Dillon at btradianz.com Thu Feb 2 04:50:14 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Thu, 2 Feb 2006 09:50:14 +0000 Subject: [ppml] 2005-1 status In-Reply-To: Message-ID: > That seems to me the extent to which geotopological addressing will be > feasible in the real world, where NSPs operate continental or global > backbones. And if the current iteration of 2005-1 gets approved, we may > end up there sooner than we expect. I disagree on the feasibility question. This level of geotopological addressing is certainly the easiest to achieve, however it is feasible to take it to another level and subdivide the continental aggregates in some logical, geographically-driven manner. I suggest that it should be based on centers of interconnection, i.e. cities of 100,000 population or greater, and that it should not be overly concerned with sharp boundaries. If ABC Inc. in Hooterville wants to use Philadelphia addresses and XYZ Inc. wants to use Baltimore ones, then that should be acceptable since they are not clearly in one or the other population center. LATAs are also a reasonable way of carving up the USA. Or just making a six-way split along north/south and west/central/east lines. In the long term, I think the best results will come from using major cities as centers of gravity since that is where the road, rail, air and telecom networks interconnect the most. > but I think we should seriously > consider only issuing PI space to users whose size or network complexity > makes the use of PA space for multihoming impractical. Is there a practical, well-documented technique for multihoming IPv6 with PA addresses? --Michael Dillon From sleibrand at internap.com Thu Feb 2 08:17:30 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Thu, 2 Feb 2006 08:17:30 -0500 (EST) Subject: [ppml] 2005-1 status In-Reply-To: <43E1871E.2090403@hotnic.net> References: <43E1871E.2090403@hotnic.net> Message-ID: On 02/01/06 at 11:14pm -0500, Kevin Loch wrote: > There certainly isn't anything resembling a consensus on where the > dividing line should be. For that reason the latest revision proposals > simply permit anyone with an IPv4 allocation/assignment to get an IPv6 > assignment. The idea is that those networks have already been evaluated > by the best methods we currently have. I wholeheartedly agree with that portion of the policy. > Gauging the merits of IPv6 only networks is something that will take > further work. I agree. In my mind, this is a reason to be conservative in allocating IPv6 PI space to organizations that do not qualify for IPv4 PI space. > The concern over a flood of non-IPv4-pi applicants is valid but greatly > overstated. How many non-isp networks in the ARIN region are multihomed > right now with IPv6 and have /48's swipped from two different ISP's? > I'm guessing not very many. So if they don't exist yet, and it will take further work to determine which of them should get IPv6 PI space, why are we creating a policy that gives them IPv6 PI space no questions asked? Why shouldn't we create a policy that gives IPv6 PI space to anyone who would qualify for IPv4 PI space, and wait on codifying the IPv6-only portion of the policy until we have a better idea of what the other non-PI multihoming options will be, how easy it will be to renumber in the IPv6 world, and who needs IPv6-only PI space? > As we gain experience with these assignments we can revise the policy if > necessary. Agreed, but it's much easier to go slowly and loosen the policy later than to tighten it after you've already given early adopters space under a looser policy. -Scott From sleibrand at internap.com Thu Feb 2 08:30:42 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Thu, 2 Feb 2006 08:30:42 -0500 (EST) Subject: [ppml] 2005-1 status In-Reply-To: <9FBE3DF07B8FE83D3CD4484C@odpwrbook.hq.netli.lan> References: <9FBE3DF07B8FE83D3CD4484C@odpwrbook.hq.netli.lan> Message-ID: Owen, Do you attend IETF? It seems to me that's the place to push for an improved routing paradigm and a redesign of the routing system. I'll be at my first IETF in Dallas in March. If you'll be attending, let me know. I'd love to meet up with folks with good ideas on how to improve the Internet, and start actively participating in some working groups. Until someone finishes paving the road ahead and builds a bridge across the ravine in the distance, I don't think it's wise to take our foot off the brakes. We needn't stop yet, and I'd love to be able to speed up, but I don't think it's safe to do so just yet. -Scott On 02/01/06 at 10:34pm -0800, Owen DeLong wrote: > > > --On February 1, 2006 9:35:16 PM -0500 Scott Leibrand > wrote: > > > George, > > > > I think we all agree that enterprises need to be able to multihome, switch > > ISPs, and traffic engineer. But the devil is in the details, i.e. how. > > It sounds like you represent a large network that would qualify for IPv4 > > PI space, and for whom PA space is unreasonable because of the renumbering > > difficulty. So I wanted to get your opinion on the point I've been trying > > to introduce into the discussion: at what point along the spectrum from a > > home user to a large multinational corporation does PI space become the > > best (or only) option for effective multihoming? > > > Scott, > > With all due respect, I think you are asking the wrong question. That > question boils down to how can we optimize who we give full citizenship > in the internet to and who we treat as second class citizens. I think > instead, we should be asking "How do we accommodate everyone who needs > PA space?" Todays routing paradigm will not do it. We know that. > As such, I think the question then shifts to "How long should we continue > to accept a routing paradigm which is known not to meet the needs > of all of the constituents of the internet? How hard should we work > and how many entities are we willing to penalize in order to preserve > the status quo?" > > > I know a home user doesn't need PI space: an IPv6 prefix from each of his > > ISPs (or his and his neighbors) would suffice. But does a small business > > with a single location need PI space to multihome? What about about a > > larger business with a hundred employees and a branch office or two? > > > How do you know this? Granted, I agree that the home user that needs > this today is few and far between. However, as more and more people > and families become generators and not just consumers of content, I > believe this will change in the long run. > > Certainly there are many small businesses with single locations that may > need PI space to multihome effectively. Some may need it even if they > are not multihomed in order to accommodate the ability to switch providers > without having to address configurations an a vast number of devices they > do not control. However, most such businesses are multihomed today, > so, I can live with multihoming as a base threshold for now. > > Certainly, the larger the organization gets, the higher the percentage > you will find needing PI space today. > > > As I've stated before, I really think we need to set up the policy such > > that only the people for whom PI space is the only reasonable option will > > go that route. If we give PI space out to anyone with two ISPs, I'm > > pretty sure we're cause a marked increase in routing table growth over > > what we've seen with IPv4. > > > That may be true. My question is: "Should we continue to penalize the > end users in order to prevent this, or, should we instead start insisting > on an improved routing paradigm that takes this need into account." > > I realize ARIN can't redesign the routing system, but, we can decide > whether we want to base policy on preservation of the status quo, or, > instead on the needs of all of our constituencies. > > Owen > > -- > If this message was not signed with gpg key 0FE2AA3D, it's probably > a forgery. > From billd at cait.wustl.edu Thu Feb 2 09:15:43 2006 From: billd at cait.wustl.edu (Bill Darte) Date: Thu, 2 Feb 2006 08:15:43 -0600 Subject: [ppml] 2005-1 status Message-ID: Owen, My personal belief is that you frame the question(s) appropriately in this post. If the architecture of the Internet no longer serves the emerging interests of the constituents, then the architecture should change, rather than trying to craft discriminating address policy that preserves the status quo. On a slightly different topic, with the PI for endsites policy, there is no stipulation about the v4 blocks that exist in the v6 recipients 'possession'. You are assuming that that legacy assignment would endure in perpetuity? You have no expectation that the v6 block would require the legacy v4 blocks, whether PA or PI to be returned? I'm not suggesting this be the case...just want this issue to be addressed. bd > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Owen DeLong > Sent: Thursday, February 02, 2006 12:35 AM > To: Scott Leibrand; George Kuzmowycz > Cc: ppml at arin.net > Subject: Re: [ppml] 2005-1 status > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From sleibrand at internap.com Thu Feb 2 09:11:38 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Thu, 2 Feb 2006 09:11:38 -0500 (EST) Subject: [ppml] 2005-1 status In-Reply-To: References: Message-ID: Bill and Owen, What if the IETF comes up with a routing architecture / protocol design that allows for effective multihoming with PA space? That seems more likely to me (in the near term) than a complete replacement of BGP4. IMO policy should recognize the status quo for what it is: the way things are done. If the status quo needs to change, fine. That's why we're debating 2005-1. But I think it's dangerous to make policy with the goal of breaking things so that someone else will be forced to fix them later. IMO we should make policy that meets the current needs of our constituents, and strive to meet their future needs by working through the IETF process to fix the routing architecture, and then modifying policy in the future when future interests have emerged and we have a clearer idea of the tradeoffs. -Scott On 02/02/06 at 8:15am -0600, Bill Darte wrote: > Owen, > > My personal belief is that you frame the question(s) appropriately in this > post. > If the architecture of the Internet no longer serves the emerging interests > of the constituents, then the architecture should change, rather than trying > to craft discriminating address policy that preserves the status quo. > > On a slightly different topic, with the PI for endsites policy, there is no > stipulation about the v4 blocks that exist in the v6 recipients > 'possession'. You are assuming that that legacy assignment would endure in > perpetuity? You have no expectation that the v6 block would require the > legacy v4 blocks, whether PA or PI to be returned? > > I'm not suggesting this be the case...just want this issue to be addressed. > > bd > > > -----Original Message----- > > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > > Behalf Of Owen DeLong > > Sent: Thursday, February 02, 2006 12:35 AM > > To: Scott Leibrand; George Kuzmowycz > > Cc: ppml at arin.net > > Subject: Re: [ppml] 2005-1 status > > > > > > _______________________________________________ > > 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 > From memsvcs at arin.net Thu Feb 2 09:19:34 2006 From: memsvcs at arin.net (Member Services) Date: Thu, 02 Feb 2006 09:19:34 -0500 Subject: [ppml] Deadline for Policy Proposals - February 9, 2006 Message-ID: <43E214F6.6040501@arin.net> The ARIN XVII Public Policy Meeting will take place April 10-11, 2006, in Montreal. New policy proposals must be submitted by 23:59 EST, February 9, 2006, in order to be considered by the ARIN Advisory Council for possible inclusion on the ARIN XVII agenda. This is in accordance with ARIN's Internet Resource Policy Evaluation Process, which requires that proposed policies be submitted at least 60 days prior to the meeting. Those who wish to propose new ARIN number resource policies or modifications to existing policies must submit a Policy Proposal Template. The template must be sent via e-mail to policy at arin.net. The Policy Proposal Template can be found at: http://www.arin.net/policy/irpep_template.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) From billd at cait.wustl.edu Thu Feb 2 09:31:31 2006 From: billd at cait.wustl.edu (Bill Darte) Date: Thu, 2 Feb 2006 08:31:31 -0600 Subject: [ppml] 2005-1 status Message-ID: > Bill and Owen, > > What if the IETF comes up with a routing architecture / > protocol design that allows for effective multihoming with PA > space? That seems more likely to me (in the near term) than > a complete replacement of BGP4. > > IMO policy should recognize the status quo for what it is: > the way things are done. If the status quo needs to change, > fine. That's why we're debating 2005-1. But I think it's > dangerous to make policy with the goal of breaking things so > that someone else will be forced to fix them later. I think this is a mis-characterization... 2005-1 expressed a means to accommodate the needs of current users of the Internet and doesn't break with the status quo or break the routing infrastructure. I does bring into question whether 'in the longer term', the status quo will accommodate those future needs. As you suggest above, there may be more than one way to remedy those implications and does not attempt to specify any particular remedy. I would never advocate or support policy proposals whose goal is to "break things".... I have been around long enough (some may say too long) to have heard many 'sky falling' objections to address policy proposals that 'loosens' things to the point of 'breaking' the routing system. I've seen no evidence to date that such fear was warranted...even in the slightest. > IMO we > should make policy that meets the current needs of our > constituents, and strive to meet their future needs by > working through the IETF process to fix the routing > architecture, and then modifying policy in the future when > future interests have emerged and we have a clearer idea of > the tradeoffs. > > -Scott > > On 02/02/06 at 8:15am -0600, Bill Darte wrote: > > > Owen, > > > > My personal belief is that you frame the question(s) > appropriately in > > this post. If the architecture of the Internet no longer serves the > > emerging interests of the constituents, then the > architecture should > > change, rather than trying to craft discriminating address > policy that > > preserves the status quo. > > > > On a slightly different topic, with the PI for endsites > policy, there > > is no stipulation about the v4 blocks that exist in the v6 > recipients > > 'possession'. You are assuming that that legacy assignment would > > endure in perpetuity? You have no expectation that the v6 > block would > > require the legacy v4 blocks, whether PA or PI to be returned? > > > > I'm not suggesting this be the case...just want this issue to be > > addressed. > > > > bd > > > > > -----Original Message----- > > > From: ppml-bounces at arin.net > [mailto:ppml-bounces at arin.net] On Behalf > > > Of Owen DeLong > > > Sent: Thursday, February 02, 2006 12:35 AM > > > To: Scott Leibrand; George Kuzmowycz > > > Cc: ppml at arin.net > > > Subject: Re: [ppml] 2005-1 status > > > > > > > > > _______________________________________________ > > > 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 > > > From randy at psg.com Thu Feb 2 09:24:02 2006 From: randy at psg.com (Randy Bush) Date: Thu, 2 Feb 2006 04:24:02 -1000 Subject: [ppml] 2005-1 status References: Message-ID: <17378.5634.155101.499528@roam.psg.com> > If the architecture of the Internet no longer serves the emerging > interests of the constituents, then the architecture should > change yep > rather than trying to craft discriminating address policy that > preserves the status quo. rather than retry address policy that failed in the past, created a bad swamp, and forced an extremely difficult change on everyone with great pain, noise, and flamage from which some have still not completely recovered. please learn from history! randy From sleibrand at internap.com Thu Feb 2 09:29:07 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Thu, 2 Feb 2006 09:29:07 -0500 (EST) Subject: [ppml] 2005-1 status In-Reply-To: References: Message-ID: On 02/02/06 at 8:31am -0600, Bill Darte wrote: > 2005-1 expressed a means to accommodate the needs of current users of > the Internet and doesn't break with the status quo Yes it does. The most recently presented draft of 2005-1 allows any home user who can get a /48 from two ISPs to qualify for PI space. > or break the routing infrastructure. That remains to be seen. > I does bring into question whether 'in the longer term', the status quo > will accommodate those future needs. As you suggest above, there may be > more than one way to remedy those implications and does not attempt to > specify any particular remedy. So why are we specifying PI-for-everyone as the remedy? Why not just give IPv6 PI space to those who qualify for IPv4 PI space (for now), and wait until later to give out PI-for-everyone only if necessary? -Scott From kloch at hotnic.net Thu Feb 2 10:50:05 2006 From: kloch at hotnic.net (Kevin Loch) Date: Thu, 02 Feb 2006 10:50:05 -0500 Subject: [ppml] 2005-1 status In-Reply-To: References: Message-ID: <43E22A2D.3090801@hotnic.net> Scott Leibrand wrote: > On 02/02/06 at 8:31am -0600, Bill Darte wrote: > > >>2005-1 expressed a means to accommodate the needs of current users of >>the Internet and doesn't break with the status quo > > Yes it does. The most recently presented draft of 2005-1 allows any home > user who can get a /48 from two ISPs to qualify for PI space. Right now getting two /48's up and running is easier said than done, and probably not free (at least not for long). If you wanted to make it nearly impossible you could require native connections. Another way to limit it would be to require the /48's to be from ARIN LIR's. There's only about 73 of those online right now. In any case I expect the fees for PI space (I'm guessing minimum of $500/yr membership fee if deferred and maybe $1250/yr if not) would discourage frivilous assignments. - Kevin From billd at cait.wustl.edu Thu Feb 2 11:30:38 2006 From: billd at cait.wustl.edu (Bill Darte) Date: Thu, 2 Feb 2006 10:30:38 -0600 Subject: [ppml] 2005-1 status Message-ID: > > > 2005-1 expressed a means to accommodate the needs of > current users of > > the Internet and doesn't break with the status quo > > Yes it does. The most recently presented draft of 2005-1 > allows any home user who can get a /48 from two ISPs to > qualify for PI space. > > > or break the routing infrastructure. > > That remains to be seen. > > > I does bring into question whether 'in the longer term', the status > > quo will accommodate those future needs. As you suggest > above, there > > may be more than one way to remedy those implications and does not > > attempt to specify any particular remedy. > > So why are we specifying PI-for-everyone as the remedy? Why > not just give IPv6 PI space to those who qualify for IPv4 PI > space (for now), and wait until later to give out > PI-for-everyone only if necessary? > > -Scott I don't think I have taken a position of PI-for-everyone. I think we might rather consider our obligation to provide PI space to those who NEED it...but that the NEED is not solely determined by arbitrary thresholds. Those who have it now or could justify it under current policy is a 'safe' starting point for that discussion it seems.....like right where we are in my estimation. bd From sleibrand at internap.com Thu Feb 2 11:24:25 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Thu, 2 Feb 2006 11:24:25 -0500 (EST) Subject: [ppml] 2005-1 status In-Reply-To: <43E22A2D.3090801@hotnic.net> References: <43E22A2D.3090801@hotnic.net> Message-ID: On 02/02/06 at 10:50am -0500, Kevin Loch wrote: > Right now getting two /48's up and running is easier said than done, and > probably not free (at least not for long). If you wanted to make it > nearly impossible you could require native connections. Another way to > limit it would be to require the /48's to be from ARIN LIR's. There's > only about 73 of those online right now. So something like this? 3) Be currently multihomed using native IPv6 connectivity to two or more separate ARIN LIR's using at least one /48 assigned to them by each LIR. That would allow for widespread IPv6-only PI allocations once native IPv6 connectivity becomes more widespread, but in the near term limit PI allocations to those who have or qualify for IPv4 PI space. > In any case I expect the fees for PI space (I'm guessing minimum of > $500/yr membership fee if deferred and maybe $1250/yr if not) would > discourage frivolous assignments. That combined with the language above would be something I could support. I would actually prefer more restrictive language than the above in 3) initially, which could be loosened later, but it seems I'm in the minority with that view, so I'm willing to support the language above if that represents a consensus view. -Scott From Lee.Howard at stanleyassociates.com Thu Feb 2 11:45:26 2006 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Thu, 2 Feb 2006 11:45:26 -0500 Subject: [ppml] 2005-1 status Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40138EEF4@CL-S-EX-1.stanleyassociates.com> > In any case I expect the fees for PI space (I'm guessing minimum of > $500/yr membership fee if deferred and maybe $1250/yr if not) would > discourage frivilous assignments. Just to confirm current fees: $1250 is the current initial and annual fee for IPv6 micro-allocations (/48) for non-members. If you're a member, including a non-subscriber member ($500/year), the fee is waived through December 2006. There is currently no separate fee schedule for IPv6 end user assigments, as there is in IPv4. http://www.arin.net/billing/fee_schedule.html Lee > > - Kevin > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From owen at delong.com Thu Feb 2 17:25:39 2006 From: owen at delong.com (Owen DeLong) Date: Thu, 02 Feb 2006 14:25:39 -0800 Subject: [ppml] 2005-1 status In-Reply-To: References: <9FBE3DF07B8FE83D3CD4484C@odpwrbook.hq.netli.lan> Message-ID: <61480DE47EF7BE1E04958F99@imac-en0.delong.sj.ca.us> --On February 2, 2006 8:30:42 AM -0500 Scott Leibrand wrote: > Owen, > > Do you attend IETF? It seems to me that's the place to push for an > improved routing paradigm and a redesign of the routing system. > Agreed. Unfortunately, no, I don't have the resources to actively participate in IETF. As such, my effort on new routing paradigm is limited to explaining that one is needed sooner or later regardless of allocation policy, and, questioning the basic assumption in IP policy that we should preserve the current routing paradigm by constraining the use of IP and treating a significant portion of the world as second class citizens in such policy. > I'll be at my first IETF in Dallas in March. If you'll be attending, let > me know. I'd love to meet up with folks with good ideas on how to improve > the Internet, and start actively participating in some working groups. > I'd love to be there, but, I haven't even been able to get my employer to send me to an ARIN conference, let alone IETF. > Until someone finishes paving the road ahead and builds a bridge across > the ravine in the distance, I don't think it's wise to take our foot off > the brakes. We needn't stop yet, and I'd love to be able to speed up, but > I don't think it's safe to do so just yet. > I think as long as we keep our feet on the brakes, IETF will not begin construction. That is my concern. We are penalizing a significant portion of the ARIN constituency and creating multiple classes of citizenship while ignoring the fact that the DOT has not started construction on the bridge they promised to complete years ago. I was far more willing to accept this in IPv4 because it was supposed to get fixed in IPv6. It has not been fixed, and, the IETF shows no signs of even an intent to consider fixing it. Safe? Perhaps not, but, safety is relative. Remember, brakes are an ablative process, and, leaving our feet on them has consequences as well. 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 Thu Feb 2 17:45:25 2006 From: owen at delong.com (Owen DeLong) Date: Thu, 02 Feb 2006 14:45:25 -0800 Subject: [ppml] 2005-1 status In-Reply-To: References: Message-ID: --On February 2, 2006 9:11:38 AM -0500 Scott Leibrand wrote: > Bill and Owen, > > What if the IETF comes up with a routing architecture / protocol design > that allows for effective multihoming with PA space? That seems more > likely to me (in the near term) than a complete replacement of BGP4. > Changing the routing paradigm does not require a complete replacement of BGP4 or even a modification to the vast majority of routers. It requires the following things: Terms: RL = Routing Locater -- Destination ASN or equivalent ESI = End System Identifier -- Full IPv6 Host address Prefix = Same meaning as in IPv4/IPv6 prefixes today. 1. An extension header for placing the destination RL in the datagram. (Extension header type 53 could be given a new subtype to do this, the protocol is already designed to support this). 2. Intra AS routing and routing outside the DFZ continues to be done as it is today based on prefixes. 3. At the edge of the DFZ, routers which are aware of this new header would do the lookup necessary to insert it and insert the header into datagrams they are routing. 4. Within the DFZ, routers which are aware of this new header would forward the packet based on its contents and ignore the prefix unless the RL matched the local ASN. 5. A mechanism for providing authenticated trnaslations between Prefix->RL(s) would be required. Said mechanism would have to be distributed. I believe DNS records with digital signature chains leading back to IANA is a possible solution. 6. Eventually, when this is deployed widely enough, BGP could be modified to speak only of AS Path data and drop the prefix information to improve scalability. 7. Later, we might be able to gain further optimizations by finding ways to hierarchically assign RLs so that less specific AS paths can be used as you get further from the destination. This mechanism would allow for leaf sites to multihome by advertising the RLs of each of their upstreams instead of having their own RL. I believe this would solve the routing table scale problem when we got to the point that BGP no longer needed to advertise prefixes. > IMO policy should recognize the status quo for what it is: the way things > are done. If the status quo needs to change, fine. That's why we're > debating 2005-1. But I think it's dangerous to make policy with the goal > of breaking things so that someone else will be forced to fix them later. > IMO we should make policy that meets the current needs of our > constituents, and strive to meet their future needs by working through the > IETF process to fix the routing architecture, and then modifying policy in > the future when future interests have emerged and we have a clearer idea > of the tradeoffs. > I'm not proposing that we make policy for the sake of braking things. I am proposing that we no longer accept the way in which things are broken and continue to penalize ARIN constituents in order to work around that brokenness. To that end, I believe 2005-1 is a significant step in that direction. One which we should take. 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 Thu Feb 2 17:52:19 2006 From: owen at delong.com (Owen DeLong) Date: Thu, 02 Feb 2006 14:52:19 -0800 Subject: [ppml] 2005-1 status In-Reply-To: <17378.5634.155101.499528@roam.psg.com> References: <17378.5634.155101.499528@roam.psg.com> Message-ID: <44F666F52F4A7223D8171DBE@imac-en0.delong.sj.ca.us> >> rather than trying to craft discriminating address policy that >> preserves the status quo. > > rather than retry address policy that failed in the past, created > a bad swamp, and forced an extremely difficult change on everyone > with great pain, noise, and flamage from which some have still not > completely recovered. > I have learned from history, Randy. What I have learned is that we applied the wrong solution to the problem. Rather than solve the problem of "How do we build a global routing table to accomodate the PI needs of internet users" we solved the problem of "how do we change addressing policy to bandaid the current situation." There was much pain and flamage because the solution was only slightly better than the original problem. Further, many of us who accepted the solution did so expecting that IPv6 would have a more complete and workable solution (and that it was supposed to be coming soon). I have learned from history that continuing to accept this will only perpetuate the "let's treat as many users as possible as second class citizens and make it painful for them to switch providers." status quo. CIDR was necessary at the time because there was no way to build a new routing paradigm fast enough to resolve the issue before it caused a serious meltdown. For IPv6, this is not the case. What you call a bad swamp, I call a useful address allocation paradigm which, unfortunately, the current routing architecture has a problem scaling with. One solution is to reduce the utility of addresses as has been done. Another is to change the routing paradigm in such a way as to facilitate such an addressing policy. 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 Thu Feb 2 18:01:25 2006 From: owen at delong.com (Owen DeLong) Date: Thu, 02 Feb 2006 15:01:25 -0800 Subject: [ppml] 2005-1 status In-Reply-To: References: Message-ID: --On February 2, 2006 9:29:07 AM -0500 Scott Leibrand wrote: > On 02/02/06 at 8:31am -0600, Bill Darte wrote: > >> 2005-1 expressed a means to accommodate the needs of current users of >> the Internet and doesn't break with the status quo > > Yes it does. The most recently presented draft of 2005-1 allows any home > user who can get a /48 from two ISPs to qualify for PI space. > Current IPv4 status quo allows any home user who can justify a /22 (show that he is multhomed and has ~500 or so host addresses in use) to get PI space. I do not see these two as being significantly different thresholds. >> or break the routing infrastructure. > > That remains to be seen. > While I agree that we should not intentionally break the routing infrastructure, I would argue that if there is a need for PI space, the question should be "Can we prove this will break the routing infrastructure?" instead of "If it might break the routing infrastructure, let's avoid it." If we cannot prove that it will break the routing infrastructure, then, what basis do we have to create a group of "second class citizens" who cannot have PI space to meet their needs, just to avoid the speculative possibility that it might eventually present a scaling problem? >> I does bring into question whether 'in the longer term', the status quo >> will accommodate those future needs. As you suggest above, there may be >> more than one way to remedy those implications and does not attempt to >> specify any particular remedy. > > So why are we specifying PI-for-everyone as the remedy? Why not just give > IPv6 PI space to those who qualify for IPv4 PI space (for now), and wait > until later to give out PI-for-everyone only if necessary? > PI for everyone who cares enough to pay for it is the need. Failing to address that need is discriminatory and arbitrary unless you can prove a clear case for damage to the network. At 10 times the current IPv6 adoption rate, there is at least 5 years for IETF to develop a new routing paradigm and begin deployment and another 5 to get it deployed. 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 stephen at sprunk.org Thu Feb 2 18:06:07 2006 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 2 Feb 2006 17:06:07 -0600 Subject: [ppml] 2005-1 status References: <002501c62679$eb010a10$730016ac@ssprunk> Message-ID: <028501c6284d$3fde3d80$730016ac@ssprunk> [ This is bordering on OT, but I'm trying to keep it relevant ] Thus spake "Glenn Wiltse" > If I'm not mistaken the current IPv6 policy allows a LIR to give a /48 > to each end site. If a owner of a McD franchise (or whatever) asked a LIR > for IPv6 space, a LIR may likely just give that endsite a /48. So, I > don't undestand why you think the entire McD business could not justify a > need for more then a /47. With 31,000 sites today and ~2% annual growth, I don't see how they could justify asking for more than a /47 unless they had a legit use for more than three /64s per restaurant. They could even fit into a /48 without difficulty if they only needed one per restaurant (which is what I'd expect). Still, quibbling over /47 vs /44 is a distraction. I haven't heard anyone say that a /32 would be reasonable for an end site under any conditions. I have trouble conceiving any org on earth that has a real need for _over eight billion_ internal subnets, hence my original argument with the Kevin's draft proposal that would have given us such a policy. It's since been improved. S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin From owen at delong.com Thu Feb 2 18:24:39 2006 From: owen at delong.com (Owen DeLong) Date: Thu, 02 Feb 2006 15:24:39 -0800 Subject: [ppml] 2005-1 status In-Reply-To: References: <43E22A2D.3090801@hotnic.net> Message-ID: <47EC4C0B8D072F8B62111E1C@imac-en0.delong.sj.ca.us> I can live with Scott's proposed language, although, I don't see the additional restrictions as necessary or desirable. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From stephen at sprunk.org Thu Feb 2 18:57:21 2006 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 2 Feb 2006 17:57:21 -0600 Subject: [ppml] 2005-1 status References: Message-ID: <02b401c62854$72fb8d10$730016ac@ssprunk> Thus spake "George Kuzmowycz" > Please forgive me if I'm not doing this "correctly", but even though > I've lurked on this list for a while I have never participated in any > policy development processes. > > What I see distinctly under-represented here is the > corporate/enterprise IT view, Agreed, but that only comes into play when the AC tries to measure consensus _after_ the minority has the chance to sway the majority. It's also one of the reasons that ARIN (and the IETF) use this method instead of voting... I don't see too many of the ISP folks who are completely against PI space, though; it's more that many are afraid of it being significantly more popular than v4 multihoming is. > and as a result I think the vagueness of the "large/complex" will lead > to problems. In my view, the direction this policy is taking will lead to > even a lower rate of corporate IPv6 adoption than the pessimists here > think. In today's environment, an organization does not have to be > particularly "large" or "complex" to have legitimate need for PI space > and real multi-provider multi-homing. The "large/complex" label is just a section heading; it could be easily removed without affecting anything. Here's the text you snipped: 6.5.8. Direct assignments to large/complex end sites 6.5.8.1. To qualify for a direct assignment, an organization must: a) not be an IPv6 LIR; and b) meet at least ONE of the following requirements: 1) Have an IPv4 assignment or allocation directly from an RIR, the IANA or legacy registry; or 2) Qualify for an IPv4 assignment or allocation from ARIN under the IPv4 policy currently in effect; or 3) Be currently multihomed using IPv6 to two or more separate LIR's using at least one /48 assigned to them by each LIR. I don't see either of the latter two as being particularly difficult to accomplish for anyone who has a legitimate need for multihoming. If anything, the proposal is taking fire from ISPs for being _too easy_ to use. > A policy which makes that more difficult than it is today is doomed. Today it's impossible to get PI IPv6 space, so anything will make it better from the perspective of end sites. > Keep in mind, please, that network architecture decisions in the real > world are increasingly not being made on the basis of technical (i.e. > protocol-level or routing-policy-level) factors. Network architecture > decisions are being driven by what can be justified to compliance > officers, internal auditors, third-party review (audit or otherwise), > data security officers, etc. These may be people who know just enough > about networking to pass a CISSP or CISA or CIA exam but have no idea > what BGP is. Then, until the IETF produces something else workable, those organizations are simply not competent enough to multihome with either v4 or v6. That's neither ARIN's (or the ISPs') fault nor their responsibility to remedy. > There are many, many organizations that are large enough to > have an IT staff and an internal audit or compliance staff but not large > enough or old enough to have a legacy /16. Many of these organizations, > publicly, maybe are only a couple of /30's, but behind that could easily > be a /20's or a /19's worth of devices. Under current policy, the only > way to get PI space for such an organization is to renumber to non-1918 > space or to stretch the truth with ARIN (which seems to be the > nudge-nudge-wink-wink sort of advice that one occasionally gets). If they have a /20s worth of hosts, then they already qualify for v4 PI space and therefore would qualify for v6 PI space under this proposal. Where's the problem? It sounds like you're saying that they'd want a PI block outside the firewall but still use private addresses inside. The only equivalent of this in the v6 world is ULAs internally with NAT (ick!), but since they could get a PI /48 with this proposal, why bother? > Yet to an IT Director or above, who asks why we can have telephone > number portability but not IP address portability, what's the answer? My answer is to ask him if, when he moves, the post office allows him to take his old address with him. > I saw this come up on the list a bit around a week ago, but have the > feeling that the provider community, which dominates this process, isn't > listening. Policies which are predicated on providers' statements (as > I've seen here) of what an AS "needs" without listening to what those > ASes want and why don't make for a sustainable business model, IMO. It's > not that we (the customers) don't trust you, it's that in today's > regulatory/business environment we no longer are permitted to trust you. > If I don't have a solid plan for what to do quickly and painlessly to > switch ISP's, I lose my job or our customers or both. For better or for > worse, PI space and multi-homing are the answer du jour. If we gave everyone who wanted PI space some, either the ISPs would end up filtering it all or the DFZ would melt. Neither is acceptable, so the end sites have to compromise. This proposal is an attempt to do that. S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin From paul at vix.com Thu Feb 2 19:26:51 2006 From: paul at vix.com (Paul Vixie) Date: Fri, 03 Feb 2006 00:26:51 +0000 Subject: [ppml] ppml itself Message-ID: <20060203002651.1091711427@sa.vix.com> here's the output of "pick -subject '2001-status' +arin/ppml" here. those of us whose names appear here most often probably ought to take a step backward, let other folks talk, realize that even if we said something we hadn't said before nobody would know or notice, and consider some kind of omnibus-reply mechanism like sending one message per topic per week encompassing all of the issues raised upon which we would like to comment. progress doesn't look like what's below, and what's below definitely does not look (to me) like progress. 616 01/23 Marshall Eubanks [ppml] 2005-1 status< > because, a 629 01/23 "william(at)elan. Re: [ppml] 2005-1 status< I see no reason why 652 01/23 Scott Leibrand Re: [ppml] 2005-1 status< Why should the crite 673 01/24 Michael.Dillon at bt Re: [ppml] 2005-1 status<<> I like what Kevin ha 674 01/24 Michael.Dillon at bt Re: [ppml] 2005-1 status<<> so we have > to plan 676 01/24 Bill Darte Re: [ppml] 2005-1 status<<> There is pressure fo 677 01/24 Bill Darte Re: [ppml] 2005-1 status<<> > > Why should the c 679 01/24 Michael.Dillon at bt Re: [ppml] 2005-1 status<<> > Why should the met 682 01/24 "Howard, W. Lee" Re: [ppml] 2005-1 status< Ima 683 01/24 Kevin Loch Re: [ppml] 2005-1 status< Another reason to ma 711 01/25 Michael.Dillon at bt Re: [ppml] 2005-1 status<<> > We should be disti 713 01/25 "william(at)elan. Re: [ppml] 2005-1 status< Human factor. If ren 718 01/25 Bill Darte Re: [ppml] 2005-1 status<<> > > Bill, > > I thin 720 01/25 Bill Darte Re: [ppml] 2005-1 status<<> > > Human factor. If 722 01/25 Scott Leibrand Re: [ppml] 2005-1 status< What I ask is...is i 726 01/25 Bill Darte Re: [ppml] 2005-1 status<<> What I ask is...is i 727 01/25 Tony Li Re: [ppml] 2005-1 status<<> OK, Tony...it's an a 728 01/25 Owen DeLong Re: [ppml] 2005-1 status< So what do you think 740 01/27 To:ppml at arin.net Re: [ppml] 2005-1 status< > tony wrote: > > # 744 01/27 To:ppml at arin.net Re: [ppml] 2005-1 status<<# > ... Serious early 745 01/27 To:ppml at arin.net Re: [ppml] 2005-1 status<<# > ... Serious early 752 01/29 Kevin Loch Re: [ppml] 2005-1 status<> S 755 01/30 "Howard, W. Lee" Re: [ppml] 2005-1 status<<> -----Original Messag 756 01/30 "Stephen Sprunk" Re: [ppml] 2005-1 status< > 6.5.8.2. Direct as 760 01/30 Kevin Loch Re: [ppml] 2005-1 status< 762 01/30 Kevin Loch Re: [ppml] 2005-1 status< It is conceivable > 765 01/30 Steve Feldman Re: [ppml] 2005-1 status<> 768 01/30 Daniel Golding Re: [ppml] 2005-1 status< Think about it: McDo 774 01/31 "cja at daydream.com Re: [ppml] 2005-1 status<<--===============17346 775 01/31 "Stephen Sprunk" Re: [ppml] 2005-1 status<>> Kevin Loch Message: 3 > > Date: 780 01/31 Glenn Wiltse Re: [ppml] 2005-1 status< Here is an alternati 788 -02/01 Michael.Dillon at bt Re: [ppml] 2005-1 status<<> On one side, if we d 789 02/01 Owen DeLong Re: [ppml] 2005-1 status<<--===============02705 790 02/01 Michael.Dillon at bt Re: [ppml] 2005-1 status<<> Frankly, if the IETF 791 02/01 To:ppml at arin.net Re: [ppml] 2005-1 status<<# If ARIN were to furt 793 02/01 Michael.Dillon at bt Re: [ppml] 2005-1 status<<> and yet i don't see 795 02/01 Tony Li Re: [ppml] 2005-1 status<<>> Frankly, if the IET 798 02/01 Tony Li Re: [ppml] 2005-1 status<> Actually, I 800 02/01 "George Kuzmowycz Re: [ppml] 2005-1 status<<>>> aren't going to go b 802 02/01 Owen DeLong Re: [ppml] 2005-1 status<<--===============15658 803 02/01 Owen DeLong Re: [ppml] 2005-1 status<<--===============03983 804 02/01 Scott Leibrand Re: [ppml] 2005-1 status< From ppml-bounces at ar 808 02/01 Owen DeLong Re: [ppml] 2005-1 status<<--===============18833 809 02/02 Martin Hannigan Re: [ppml] 2005-1 status<<> > >I know a home use 810 02/02 Michael.Dillon at bt Re: [ppml] 2005-1 status<<> I freely admit I'm n 811 02/02 Michael.Dillon at bt Re: [ppml] 2005-1 status<<> That seems to me the 812 02/02 Scott Leibrand Re: [ppml] 2005-1 status< Bill and Owen, > > W 819 02/02 Kevin Loch Re: [ppml] 2005-1 status< > > 2005-1 expressed 822 02/02 "Howard, W. Lee" Re: [ppml] 2005-1 status<<> In any case I expect 823 02/02 Owen DeLong Re: [ppml] 2005-1 status<<--===============04970 824 02/02 Owen DeLong Re: [ppml] 2005-1 status<<--===============17321 825 02/02 Owen DeLong Re: [ppml] 2005-1 status<<--===============20028 826 02/02 Owen DeLong Re: [ppml] 2005-1 status<<--===============02331 827 02/02 "Stephen Sprunk" Re: [ppml] 2005-1 status<<[ This is bordering on 828 02/02 Owen DeLong Re: [ppml] 2005-1 status<<--===============06500 829 02/02 "Stephen Sprunk" Re: [ppml] 2005-1 status< References: <43E22A2D.3090801@hotnic.net> Message-ID: >On 02/02/06 at 10:50am -0500, Kevin Loch wrote: > >> Right now getting two /48's up and running is easier said than done, and >> probably not free (at least not for long). If you wanted to make it >> nearly impossible you could require native connections. Another way to >> limit it would be to require the /48's to be from ARIN LIR's. There's >> only about 73 of those online right now. > >So something like this? > > 3) Be currently multihomed using native IPv6 connectivity to two > or more separate ARIN LIR's using at least one /48 assigned to > them by each LIR. Scott: Requiring native connectivity is not neutral. It turns this policy into a market-maker for immediate IPV6 domination by a few networks and I am opposed to it's inclusion. It also denies near-term access to millions who would otherwise benefit from PI space and neutrality. Moving to IPV6 is going to be a capital intensive excercise regardless of forced native connectivity. Massaging the failure of IPV6 isn't in our interest, IMO. Thanks for your comments, I have found them very productive and stimulating. [ checks the for hot tamales in eudora...good none :-) ] -M< -- Martin Hannigan (c) 617-388-2663 Renesys Corporation (w) 617-395-8574 Member of the Technical Staff Network Operations hannigan at renesys.com From alh-ietf at tndh.net Thu Feb 2 20:20:04 2006 From: alh-ietf at tndh.net (Tony Hain) Date: Thu, 2 Feb 2006 17:20:04 -0800 Subject: [ppml] 2005-1 status In-Reply-To: Message-ID: <054101c6285f$f6a10630$517ba8c0@tndh.net> An alternative to protocol design in either the routing space or host stacks is to reconsider the myth of a global DFZ. The divergence in routeviews should already trigger the flag that there is no such thing as a globally common DFZ, so arguing PI allocation policy in the context of its impact on this mythical entity is bound to drag on. I just refreshed my geo I-D's http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-09.txt http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-use-09.txt Rather than argue about the topology/geography argument, please consider that this is: 1) an identifiable block 2) does not require any changes to existing hosts or routers 3) removes any arguments about prefix length vs. organizational size 4) allows for simple proxy aggregation where the detail becomes irrelevant 5) debases ITU/national arguments over access to sovereign allocations In the worst case these degenerate to the same number of routing slots as an arbitrary RIR allocation process. At the same time they lay a foundation where alternative business practices can evolve to better align the costs involved. Comments are always welcome (particularly thoughts about how to resolve the altitude problem) Tony > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of > Scott Leibrand > Sent: Thursday, February 02, 2006 6:12 AM > To: Bill Darte > Cc: ppml at arin.net > Subject: Re: [ppml] 2005-1 status > > Bill and Owen, > > What if the IETF comes up with a routing architecture / protocol design > that allows for effective multihoming with PA space? That seems more > likely to me (in the near term) than a complete replacement of BGP4. > > IMO policy should recognize the status quo for what it is: the way things > are done. If the status quo needs to change, fine. That's why we're > debating 2005-1. But I think it's dangerous to make policy with the goal > of breaking things so that someone else will be forced to fix them later. > IMO we should make policy that meets the current needs of our > constituents, and strive to meet their future needs by working through the > IETF process to fix the routing architecture, and then modifying policy in > the future when future interests have emerged and we have a clearer idea > of the tradeoffs. > > -Scott > > On 02/02/06 at 8:15am -0600, Bill Darte wrote: > > > Owen, > > > > My personal belief is that you frame the question(s) appropriately in > this > > post. > > If the architecture of the Internet no longer serves the emerging > interests > > of the constituents, then the architecture should change, rather than > trying > > to craft discriminating address policy that preserves the status quo. > > > > On a slightly different topic, with the PI for endsites policy, there is > no > > stipulation about the v4 blocks that exist in the v6 recipients > > 'possession'. You are assuming that that legacy assignment would endure > in > > perpetuity? You have no expectation that the v6 block would require the > > legacy v4 blocks, whether PA or PI to be returned? > > > > I'm not suggesting this be the case...just want this issue to be > addressed. > > > > bd > > > > > -----Original Message----- > > > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > > > Behalf Of Owen DeLong > > > Sent: Thursday, February 02, 2006 12:35 AM > > > To: Scott Leibrand; George Kuzmowycz > > > Cc: ppml at arin.net > > > Subject: Re: [ppml] 2005-1 status > > > > > > > > > _______________________________________________ > > > 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 > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From david.kessens at nokia.com Fri Feb 3 00:14:11 2006 From: david.kessens at nokia.com (David Kessens) Date: Thu, 2 Feb 2006 21:14:11 -0800 Subject: [ppml] 2005-1 status In-Reply-To: References: Message-ID: <20060203051411.GF6266@nokia.com> Bill, On Thu, Feb 02, 2006 at 10:30:38AM -0600, Bill Darte wrote: > scott wrote: > > So why are we specifying PI-for-everyone as the remedy? Why > > not just give IPv6 PI space to those who qualify for IPv4 PI > > space (for now), and wait until later to give out > > PI-for-everyone only if necessary? > > > > -Scott > > I don't think I have taken a position of PI-for-everyone. I think > we might rather consider our obligation to provide PI space to those > who NEED it...but that the NEED is not solely determined by > arbitrary thresholds. Those who have it now or could justify it > under current policy is a 'safe' starting point for that discussion > it seems.....like right where we are in my estimation. Why would this be less arbritrary ? The fact that somebody has a lot of ipv4 address space now doesn't mean they need a lot of ipv6 address space as well (maybe even to the contrary :-)). Allocating ipv6 address space to organizations who articulate a clear need for ipv6 address space seems the least arbritrary criteria for getting them ipv6 address space. Again, this whole distinction between PI and provider aggregated address space is artificial. Why would a small provider with a plan for 200 customers who uses less address space for itself and its customers than a medium sized business for just its own business get more address space than the medium sized business ? We need a policy that allows organizations of similar size, complexity and growth rate to get similar sized allocations. It really doesn't matter whether you are an ISP, business, non-profit or some hybrid structure. David Kessens --- From Michael.Dillon at btradianz.com Fri Feb 3 04:50:05 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Fri, 3 Feb 2006 09:50:05 +0000 Subject: [ppml] 2005-1 status In-Reply-To: <028501c6284d$3fde3d80$730016ac@ssprunk> Message-ID: > So, I > > don't undestand why you think the entire McD business could not justify a > > need for more then a /47. > > With 31,000 sites today and ~2% annual growth, I don't see how they could > justify asking for more than a /47 unless they had a legit use for more than > three /64s per restaurant. They could even fit into a /48 without > difficulty if they only needed one per restaurant (which is what I'd > expect). I don't understand this analysis. First of all, in the USA McDonalds has only 12,300 locations. Secondly, according to the existing IPv6 policy, if McDonalds were to go to an ISP and ask for IPv6 connectivity for their network of 12,300 restaurants, the ISP would assign them 12,300 /48 address blocks. That is the policy and if you don't understand why each location qualifies for a /48 then you need to do some study on the fundamentals of IPv6 addressing. > Still, quibbling over /47 vs /44 is a distraction. I haven't heard anyone > say that a /32 would be reasonable for an end site under any conditions. We are not discussing end sites here. We are discussing end users, in other words organizations which may have one or many end sites in their network. > I > have trouble conceiving any org on earth that has a real need for _over > eight billion_ internal subnets, hence my original argument with the Kevin's > draft proposal that would have given us such a policy. It's since been > improved. When you say "internal subnets" are you referring to /64 blocks? If so, then this is irrelevant to the discussion. /64s are only counted in the very unusual circumstance where an end site needs only a single IPv6 subnetwork. This is unlikely to occur outside of industrial applications. --Michael Dillon From tme at multicasttech.com Fri Feb 3 08:57:38 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Fri, 3 Feb 2006 08:57:38 -0500 Subject: [ppml] 2005-1 status In-Reply-To: <47EC4C0B8D072F8B62111E1C@imac-en0.delong.sj.ca.us> References: <43E22A2D.3090801@hotnic.net> <47EC4C0B8D072F8B62111E1C@imac-en0.delong.sj.ca.us> Message-ID: Can you prepare a revised version? There has been so much back and forth (some fairly tangential) that I am no longer sure exactly what the new proposal will say. Marshall On Feb 2, 2006, at 6:24 PM, Owen DeLong wrote: > I can live with Scott's proposed language, although, I don't see the > additional restrictions as necessary or desirable. > > Owen > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From kloch at hotnic.net Fri Feb 3 10:04:51 2006 From: kloch at hotnic.net (Kevin Loch) Date: Fri, 03 Feb 2006 10:04:51 -0500 Subject: [ppml] 2005-1 status In-Reply-To: References: <43E22A2D.3090801@hotnic.net> <47EC4C0B8D072F8B62111E1C@imac-en0.delong.sj.ca.us> Message-ID: <43E37113.3050905@hotnic.net> Marshall Eubanks wrote: > Can you prepare a revised version? There has been so much > back and forth (some fairly tangential) that I am no longer > sure exactly what the new proposal will say. Add new subsection in section 6.5 of the NRPM: 6.5.8. Direct assignments to large/complex end sites 6.5.8.1. To qualify for a direct assignment, an organization must: a) not be an IPv6 LIR; and b) meet at least ONE of the following requirements: 1) Have an IPv4 assignment or allocation directly from an RIR, the IANA or legacy registry; or 2) Qualify for an IPv4 assignment or allocation from ARIN under the IPv4 policy currently in effect; or 3) Be currently multihomed using IPv6 connectivity to two or more separate ARIN LIR's using at least one /48 assigned to them by each LIR. 6.5.8.2. Direct assignment size to large/multihomed end sites Organizations that meet the direct end site assignment criteria are eligible to receive a direct assignment. The minimum size of the assignment is /48. Organizations requesting a larger assignment or a second (or more) assignment must provide documentation justifying the need for additional subnets. 6.5.8.3. Subsequent Assignment Size Additional assignments may be made when the need for additional subnets is justified. When possible assignments will be made from an adjacent address block. Justification: In IPv4 policy there are three main types of organizations that addresses are delegated to. o ISP's receive allocations directly from ARIN or from other ISP's o End Users receive assignments from ISP's o Large and/or multihomed End Users receive assignments directly from ARIN. The third category is currently missing from IPv6 policy and this is believed to be severely hindering deployment by those organizations. In IPv6 policy-speak: o LIR's receive allocations directly from ARIN o End Sites receive assignments from LIR's This policy proposes: o Large and/or multihomed End Sites receive assignments directly from ARIN. This policy applies to organizations with networks that are large and/or complex enough to justify direct assignments. Like their IPv4 counterparts they do not make assignments to external organizations. They instead assign space internally to their own facilities. Similarly to IPv4 These internal assignments are not submitted to ARIN via swip/rwhois. A IPv6 network is considered eligible if it is multihomed. For transition purposes an organization with an IPv4 assignment or allocation from an RIR (or the legacy RIR) is automatically considered elligible, regardless of whether they were considered an ISP or End User under IPv4 policy. It is expected that the IPv6 only (non transition) requirements will be further refined as experience is gained. - Kevin From tme at multicasttech.com Fri Feb 3 10:39:36 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Fri, 3 Feb 2006 10:39:36 -0500 Subject: [ppml] 2005-1 status In-Reply-To: <43E37113.3050905@hotnic.net> References: <43E22A2D.3090801@hotnic.net> <47EC4C0B8D072F8B62111E1C@imac-en0.delong.sj.ca.us> <43E37113.3050905@hotnic.net> Message-ID: I support this, but I think a clarification is needed. Here : Be currently multihomed using IPv6 connectivity to two or more separate ARIN LIR's using at least one /48 assigned to them by each LIR. Who is using the /48 ? The LIR's ? or the applicant ? Presumably the latter, but that's not how it reads to me. How about Be currently multihomed using IPv6 connectivity in at least two / 48's, assigned to them by two or more separate ARIN LIR's. Regards Marshall On Feb 3, 2006, at 10:04 AM, Kevin Loch wrote: > Marshall Eubanks wrote: > >> Can you prepare a revised version? There has been so much >> back and forth (some fairly tangential) that I am no longer >> sure exactly what the new proposal will say. > > Add new subsection in section 6.5 of the NRPM: > > 6.5.8. Direct assignments to large/complex end sites > > 6.5.8.1. To qualify for a direct assignment, an > organization must: > > a) not be an IPv6 LIR; and > b) meet at least ONE of the following requirements: > > 1) Have an IPv4 assignment or allocation directly from an RIR, > the IANA or legacy registry; or > 2) Qualify for an IPv4 assignment or allocation from ARIN > under > the IPv4 policy currently in effect; or > 3) Be currently multihomed using IPv6 connectivity to two > or more separate ARIN LIR's using at least one /48 assigned > to them by each LIR. > > 6.5.8.2. Direct assignment size to large/multihomed end sites > > Organizations that meet the direct end site assignment > criteria > are eligible to receive a direct assignment. The minimum size > of the assignment is /48. Organizations requesting a larger > assignment or a second (or more) assignment must provide > documentation justifying the need for additional subnets. > > 6.5.8.3. Subsequent Assignment Size > > Additional assignments may be made when the need for > additional > subnets is justified. When possible assignments will be made > from an adjacent address block. > > Justification: > > In IPv4 policy there are three main types of organizations that > addresses are delegated to. > > o ISP's receive allocations directly from ARIN or from other ISP's > o End Users receive assignments from ISP's > o Large and/or multihomed End Users receive assignments directly > from > ARIN. > > The third category is currently missing from IPv6 policy and > this is believed to be severely hindering deployment by those > organizations. In IPv6 policy-speak: > > o LIR's receive allocations directly from ARIN > o End Sites receive assignments from LIR's > > This policy proposes: > > o Large and/or multihomed End Sites receive assignments directly > from ARIN. > > This policy applies to organizations with networks that are > large and/or complex enough to justify direct assignments. Like their > IPv4 counterparts they do not make assignments to external > organizations. They instead assign space internally to their own > facilities. Similarly to IPv4 These internal assignments are not > submitted to ARIN via swip/rwhois. > > A IPv6 network is considered eligible if it is multihomed. > For transition purposes an organization with an IPv4 assignment or > allocation from an RIR (or the legacy RIR) is automatically considered > elligible, regardless of whether they were considered an ISP or End > User under IPv4 policy. It is expected that the IPv6 only (non > transition) requirements will be further refined as experience is > gained. > > - Kevin > From memsvcs at arin.net Fri Feb 3 13:43:02 2006 From: memsvcs at arin.net (Member Services) Date: Fri, 03 Feb 2006 13:43:02 -0500 Subject: [ppml] Policy Proposal 2005-9: 4-Byte AS Number - revised text Message-ID: <43E3A436.5050703@arin.net> Policy Proposal 2005-9: 4-Byte AS Number has been revised by the author. This proposal is open for discussion on this mailing list and will be on the agenda at the upcoming ARIN Public Policy Meeting. The current policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2005_9.html Regards, Member Services American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal 2005-9: 4-Byte AS Number Author: Geoff Huston Proposal Version: Revision 1 (February 3, 2006) Proposal type: modify Policy term: temporary Policy statement: This policy proposal nominates 3 dates for changes to the current AS Number allocation policy for the registry: - Commencing 1 January 2007 the registry will process applications that specifically request 32-bit only AS Numbers and allocate such AS numbers as requested by the applicant. In the absence of any specific request for a 32-bit only AS Number, a 16-bit only AS Number will be allocated by the registry. - Commencing 1 January 2009 the registry will process applications that specifically request 16-bit only AS Numbers and allocate such AS Numbers as requested by the applicant. In the absence of any specific request for a 16-bit only AS Number, a 32-bit only AS Number will be allocated by the registry. - Commencing 1 January 2010 the registry will cease to make any distinction between 16-bit only AS Numbers and 32-bit only AS Numbers, and will operate AS number allocations from an undifferentiated 32-bit AS Number allocation pool. Nomenclature It is proposed to identify 32-bit AS Numbers using a syntax of ".". Accordingly, a 32-bit AS number of value 65546 (decimal) would be identified as "1.10". Terminology "16-bit only AS Numbers" refers to AS numbers in the range 0 - 65535 "32-bit only AS Numbers" refers to AS Numbers in the range 1.0 - 65535.65535 (decimal range 65,536 - 4,294,967,295) "32-bit AS Numbers" refers to AS Numbers in the range 0.0 - 65535.65535 (decimal range 0 - 4,294,967,295) Rationale: Recent studies of AS number consumption rates indicate that the existing 16-bit pool of unallocated AS Numbers will be exhausted sometime in the period between 2010 and 2016, absent of any concerted efforts of recovery of already-allocated AS Numbers [1] [2]. Standardization work in the IETF has produced a document that is currently being submitted as a Proposed Standard that will expand the AS Number space to a 32-bit field [3]. It is noted that some advance period may be required by network operators to undertake the appropriate procedures relating to support of 32-bit AS numbers, and while no flag day is required in the transition to the longer AS Number field, it is recognised that a prudent course of action is to allow for allocation of these extended AS numbers well in advance of an anticipated 16-bit AS Number exhaustion date. This policy proposal details a set of actions and associated dates for RIR AS Number allocation policies to assist in an orderly transition to use of the 32-bit AS Number space. The essential attributes of this policy proposal are to facilitate the ease of transitional arrangements by equipment vendors, network managers and network operations staff, to provide the industry with some predictability in terms of dates and associated actions with respect to registry operational procedures for AS Number allocations. References [1] Daily AS Number Report, http://www.potaroo.net/tools/asns [2] ASNs MIA: A Comparision of RIR Statistics and RIS Reality, http://www.nanog.org/mtg-0510/wilhelm.html [3] BGP Support for Four-octet AS Number Space, draft-ietf-idr-as4bytes-12.txt Timetable for implementation: Procedures to support this proposal need to be implemented by 1 January 2007 From iggy at merit.edu Fri Feb 3 13:42:17 2006 From: iggy at merit.edu (Glenn Wiltse) Date: Fri, 3 Feb 2006 13:42:17 -0500 (EST) Subject: [ppml] 2005-1 status In-Reply-To: <43E37113.3050905@hotnic.net> References: <43E22A2D.3090801@hotnic.net> <47EC4C0B8D072F8B62111E1C@imac-en0.delong.sj.ca.us> <43E37113.3050905@hotnic.net> Message-ID: I find the re-working of this proposal as shown here, to be of little or no value. It gives no explination of what criteria there would be for obtaining more then a /48. In general as it relates to this and the earlier version, I object to the use of the term 'large/complex end sites', since, the biggest need for these types of direct assignments are for multi homed orginizations, not a a 'end site'. I belive this policy should be addressing the need of the 'large/complex orginzation' that doesn't want to have their IPv6 address space directly tied to a ISP/LIR. In my mind, these should not be considered 'end sites'. Either way, it seems to me we aren't anywhere near consensus on this issue, and I don't think this re-work gets us any closer. Glenn Wiltse On Fri, 3 Feb 2006, Kevin Loch wrote: > Marshall Eubanks wrote: > >> Can you prepare a revised version? There has been so much >> back and forth (some fairly tangential) that I am no longer >> sure exactly what the new proposal will say. > > Add new subsection in section 6.5 of the NRPM: > > 6.5.8. Direct assignments to large/complex end sites > > 6.5.8.1. To qualify for a direct assignment, an > organization must: > > a) not be an IPv6 LIR; and > b) meet at least ONE of the following requirements: > > 1) Have an IPv4 assignment or allocation directly from an RIR, > the IANA or legacy registry; or > 2) Qualify for an IPv4 assignment or allocation from ARIN under > the IPv4 policy currently in effect; or > 3) Be currently multihomed using IPv6 connectivity to two > or more separate ARIN LIR's using at least one /48 assigned > to them by each LIR. > > 6.5.8.2. Direct assignment size to large/multihomed end sites > > Organizations that meet the direct end site assignment criteria > are eligible to receive a direct assignment. The minimum size > of the assignment is /48. Organizations requesting a larger > assignment or a second (or more) assignment must provide > documentation justifying the need for additional subnets. > > 6.5.8.3. Subsequent Assignment Size > > Additional assignments may be made when the need for additional > subnets is justified. When possible assignments will be made > from an adjacent address block. > > Justification: > > In IPv4 policy there are three main types of organizations that > addresses are delegated to. > > o ISP's receive allocations directly from ARIN or from other ISP's > o End Users receive assignments from ISP's > o Large and/or multihomed End Users receive assignments directly from > ARIN. > > The third category is currently missing from IPv6 policy and > this is believed to be severely hindering deployment by those > organizations. In IPv6 policy-speak: > > o LIR's receive allocations directly from ARIN > o End Sites receive assignments from LIR's > > This policy proposes: > > o Large and/or multihomed End Sites receive assignments directly > from ARIN. > > This policy applies to organizations with networks that are > large and/or complex enough to justify direct assignments. Like their > IPv4 counterparts they do not make assignments to external > organizations. They instead assign space internally to their own > facilities. Similarly to IPv4 These internal assignments are not > submitted to ARIN via swip/rwhois. > > A IPv6 network is considered eligible if it is multihomed. > For transition purposes an organization with an IPv4 assignment or > allocation from an RIR (or the legacy RIR) is automatically considered > elligible, regardless of whether they were considered an ISP or End > User under IPv4 policy. It is expected that the IPv6 only (non > transition) requirements will be further refined as experience is > gained. > > - Kevin > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > > !DSPAM:43e371cf22695494612546! > > From tme at multicasttech.com Fri Feb 3 14:04:17 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Fri, 3 Feb 2006 14:04:17 -0500 Subject: [ppml] Policy Proposal 2005-9: 4-Byte AS Number - revised text In-Reply-To: <43E3A436.5050703@arin.net> References: <43E3A436.5050703@arin.net> Message-ID: <19C37754-AB83-46ED-8496-A386ED651BEA@multicasttech.com> Dear Geoff; Could you possibly send to the list a diff with the previous version ? Regards Marshall On Feb 3, 2006, at 1:43 PM, Member Services wrote: > Policy Proposal 2005-9: 4-Byte AS Number has been revised by the > author. This proposal is open for discussion on this mailing list > and will be on the agenda at the upcoming ARIN Public Policy > Meeting. > > The current policy proposal text is provided below and is also > available > at: http://www.arin.net/policy/proposals/2005_9.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > ### * ### > > Policy Proposal 2005-9: 4-Byte AS Number > > Author: Geoff Huston > > Proposal Version: Revision 1 (February 3, 2006) > > Proposal type: modify > > Policy term: temporary > > Policy statement: > > This policy proposal nominates 3 dates for changes to the > current > AS Number allocation policy for the registry: > > - Commencing 1 January 2007 the registry will process > applications > that specifically request 32-bit only AS Numbers and allocate such AS > numbers as requested by the applicant. In the absence of any specific > request for a 32-bit only AS Number, a 16-bit only AS Number will be > allocated by the registry. > > - Commencing 1 January 2009 the registry will process > applications > that specifically request 16-bit only AS Numbers and allocate such AS > Numbers as requested by the applicant. In the absence of any specific > request for a 16-bit only AS Number, a 32-bit only AS Number will be > allocated by the registry. > > - Commencing 1 January 2010 the registry will cease to make any > distinction between 16-bit only AS Numbers and 32-bit only AS Numbers, > and will operate AS number allocations from an undifferentiated 32-bit > AS Number allocation pool. > > Nomenclature > > It is proposed to identify 32-bit AS Numbers using a syntax > of ". in decimal>". Accordingly, a 32-bit AS number of value 65546 > (decimal) would be identified as "1.10". > > Terminology > > "16-bit only AS Numbers" refers to AS numbers in the range 0 > - 65535 > > "32-bit only AS Numbers" refers to AS Numbers in the range 1.0 - > 65535.65535 (decimal range 65,536 - 4,294,967,295) > > "32-bit AS Numbers" refers to AS Numbers in the range 0.0 - > 65535.65535 (decimal range 0 - 4,294,967,295) > > > Rationale: > > Recent studies of AS number consumption rates indicate that the > existing 16-bit pool of unallocated AS Numbers will be exhausted > sometime in the period between 2010 and 2016, absent of any concerted > efforts of recovery of already-allocated AS Numbers [1] [2]. > Standardization work in the IETF has produced a document that is > currently being submitted as a Proposed Standard that will expand > the AS > Number space to a 32-bit field [3]. > > It is noted that some advance period may be required by network > operators to undertake the appropriate procedures relating to > support of > 32-bit AS numbers, and while no flag day is required in the transition > to the longer AS Number field, it is recognised that a prudent > course of > action is to allow for allocation of these extended AS numbers well in > advance of an anticipated 16-bit AS Number exhaustion date. > > This policy proposal details a set of actions and associated > dates > for RIR AS Number allocation policies to assist in an orderly > transition > to use of the 32-bit AS Number space. > > The essential attributes of this policy proposal are to > facilitate > the ease of transitional arrangements by equipment vendors, network > managers and network operations staff, to provide the industry with > some predictability in terms of dates and associated actions with > respect to registry operational procedures for AS Number allocations. > > References > > [1] Daily AS Number Report, http://www.potaroo.net/tools/asns > [2] ASNs MIA: A Comparision of RIR Statistics and RIS Reality, > http://www.nanog.org/mtg-0510/wilhelm.html > [3] BGP Support for Four-octet AS Number Space, > draft-ietf-idr-as4bytes-12.txt > > > Timetable for implementation: Procedures to support this proposal need > to be implemented by 1 January 2007 > > > > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From stephen at sprunk.org Fri Feb 3 15:56:43 2006 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 3 Feb 2006 14:56:43 -0600 Subject: [ppml] 2005-1 status References: Message-ID: <00e201c62911$1530a450$6601a8c0@ssprunk> Thus spake >> So, I don't undestand why you think the entire McD business could >> not justify a need for more then a /47. >> >> With 31,000 sites today and ~2% annual growth, I don't see how they >> could justify asking for more than a /47 unless they had a legit use >> for more than three /64s per restaurant. They could even fit into a >> /48 without difficulty if they only needed one per restaurant (which is >> what I'd expect). > > I don't understand this analysis. First of all, in the USA McDonalds > has only 12,300 locations. ARIN covers more than the USA. And, typically, corporations based in the US use the same address space for their foreign operations even if they could (in theory) get space from a more appropriate RIR. It's a moot point anyways; 12,300 is just as good a number to argue about as 31,000. > Secondly, according to the existing IPv6 policy, if McDonalds were to > go to an ISP and ask for IPv6 connectivity for their network of 12,300 > restaurants, the ISP would assign them 12,300 /48 address blocks. > That is the policy ... No, the current policy is that the LIR can assign a single /48 or forward the request for more (with justification) to ARIN. You're confusing "end site" with "location". According to the NRPM: 6.2.9. End site An end site is defined as an end user (subscriber) [...] So, a single end user organization counts as one "end site" regardless of the number of physical locations it has. > and if you don't understand why each location qualifies for a /48 then > you need to do some study on the fundamentals of IPv6 addressing. I fail to see why "the fundamentals of IPv6 addressing" require a /48 to be assigned to a location with one or two subnets. Ever heard of VLSM? >> Still, quibbling over /47 vs /44 is a distraction. I haven't heard >> anyone say that a /32 would be reasonable for an end site under >> any conditions. > > We are not discussing end sites here. We are discussing end users, in > other words organizations which may have one or many end sites in their > network. See above about 6.2.9. >> I have trouble conceiving any org on earth that has a real need for >> _over eight billion_ internal subnets, hence my original argument with >> the Kevin's draft proposal that would have given us such a policy. >> It's since been improved. > > When you say "internal subnets" are you referring to /64 blocks? If so, > then this is irrelevant to the discussion. /64s are only counted in the > very unusual circumstance where an end site needs only a single IPv6 > subnetwork. This is unlikely to occur outside of industrial applications. Presumably, /64s would be counted when determining if a single end site were justified in requesting more than a single /48. The HD ratio could be easily used for this, though there's currently no defined threshold for this purpose. S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin From stephen at sprunk.org Fri Feb 3 17:19:56 2006 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 3 Feb 2006 16:19:56 -0600 Subject: [ppml] 2005-1 status References: <43E22A2D.3090801@hotnic.net><47EC4C0B8D072F8B62111E1C@imac-en0.delong.sj.ca.us><43E37113.3050905@hotnic.net> Message-ID: <00e301c62911$15b89900$6601a8c0@ssprunk> Thus spake "Glenn Wiltse" > I find the re-working of this proposal as shown here, to be of little > or no value. It gives no explination of what criteria there would be for > obtaining more then a /48. In reviewing the IPv4 policy, I don't see much direction on what is required to justify more than the minimum size for an initial end-user v4 allocation, and what little there is doesn't seem to apply to v6. The ARIN staff has a lot of discretion in what "justify" means in v4 policies, so I don't see any departure from existing practice in using the same word in v6 policy. Also, whereas justification is required in nearly all v4 assignments, it should be fairly rare in v6 assignments since the minimum size is already very large. Also, there is existing policy (6.5.4.2) that explicitly calls out the lack of formal criteria for giving end sites more than a /48. The proposal under discussion does no worse than what we already have. > In general as it relates to this and the earlier version, I object to > the use of the term 'large/complex end sites', since, the biggest need for > these types of direct assignments are for multi homed orginizations, not a > a 'end site'. I belive this policy should be addressing the need of the > 'large/complex orginzation' that doesn't want to have their IPv6 address > space directly tied to a ISP/LIR. In my mind, these should not be > considered 'end sites'. So if we changed the section heading (which has absolutely no effect on the policy) from 6.5.8. Direct assignments to large/complex end sites to 6.5.8. Direct assignments to end-user organizations this objection would be moot? 6.2.9 defines "end sites" to be synonymous with "end-user organizations", even though "site" implies a single physical location. The idea that end-user orgs often have private connectivity between locations is consistently missed by the ISP folks here, hence the misleading term. The "large/complex" modifier is superfluous, but the qualifications are most likely to be met by such orgs. > Either way, it seems to me we aren't anywhere near consensus on > this issue, and I don't think this re-work gets us any closer. You're welcome to float your own proposal on what you think can achieve consensus. I'm sure Kevin will be happy to hear any constructive input you have on his draft as well. S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin From jeroen at unfix.org Sat Feb 4 12:18:34 2006 From: jeroen at unfix.org (Jeroen Massar) Date: Sat, 04 Feb 2006 18:18:34 +0100 Subject: [ppml] 2005-1 status In-Reply-To: <43E37113.3050905@hotnic.net> References: <43E22A2D.3090801@hotnic.net> <47EC4C0B8D072F8B62111E1C@imac-en0.delong.sj.ca.us> <43E37113.3050905@hotnic.net> Message-ID: <1139073514.9125.16.camel@firenze.zurich.ibm.com> On Fri, 2006-02-03 at 10:04 -0500, Kevin Loch wrote: [..] > 3) Be currently multihomed using IPv6 connectivity to two > or more separate ARIN LIR's using at least one /48 assigned > to them by each LIR. From this point *everybody* can request at least a /48. Just make a tunnel to Hurricane Electric and one to Hexago or a number of other sites where you can get such an allocation. Putting down criteria is hard, probably too hard though. In either case scrap the "ARIN" part from the above. Some site might have arranged connectivity from a party in the LACNIC and one in the ARIN region and then they would be excluded from the above. Of course the question 'what is multihoming' is another nice one: - one prefix and multiple physically seperate links to the same provider - one prefix and multiple physically seperate links to multiple providers - multiple prefixes over one/multiple links and a large number of other possiblities. Good one of course: is a tunnel a seperate link? Probably a reference to the wording on getting an ASN would be good to include here. The main thing I read from 2005-1 is that it gives the folks that want it the possiblity to acquire a globally unique address space block. Which is a good thing. But there should be a hard note, which is also given in the other allocation policies, that the RIR in question does not guarantee routability of that prefix. IMHO something along the lines of: Pay an initial high fee (say $2k US) and then every year a renewal fee ($500 US?) accomplishes the same thing. (Not that having a renewel currently makes sure the prefix is not used any more but (S-)BGP(-S) could solve that problem one day ;) Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 240 bytes Desc: This is a digitally signed message part URL: From stephen at sprunk.org Sat Feb 4 15:38:23 2006 From: stephen at sprunk.org (Stephen Sprunk) Date: Sat, 4 Feb 2006 14:38:23 -0600 Subject: [ppml] 2005-1 status References: <43E22A2D.3090801@hotnic.net><47EC4C0B8D072F8B62111E1C@imac-en0.delong.sj.ca.us><43E37113.3050905@hotnic.net> <1139073514.9125.16.camel@firenze.zurich.ibm.com> Message-ID: <017801c629cc$61808e40$6501a8c0@ssprunk> Thus spake "Jeroen Massar" > On Fri, 2006-02-03 at 10:04 -0500, Kevin Loch wrote: > [..] > > 3) Be currently multihomed using IPv6 connectivity to two > > or more separate ARIN LIR's using at least one /48 assigned > > to them by each LIR. Given the below discussion, I think we can simplify this to: 3) Be currently multihomed using IPv6. without losing any meaning. More detail is redundant in the final context of the NRPM. > From this point *everybody* can request at least a /48. Just make a > tunnel to Hurricane Electric and one to Hexago or a number of other > sites where you can get such an allocation. Good point; that's a major oversight. Though I think the fees for doing it would discourage most folks, it still needs to be fixed/clarified. > Putting down criteria is hard, probably too hard though. > In either case scrap the "ARIN" part from the above. Some site might > have arranged connectivity from a party in the LACNIC and one in the > ARIN region and then they would be excluded from the above. Sounds logical. At least one link needs to be in ARIN's region for an assignment to make sense; where the rest of the links go shouldn't matter. > Of course the question 'what is multihoming' is another nice one: (Un?)fortunately, we already have an official definition. From the NRPM: 2.7 Multihomed An organization is multihomed if it receives full-time connectivity from more than one ISP and has one or more routing prefixes announced by at least two of its upstream ISPs. I'd like to think tunnels wouldn't qualify as "full-time connectivity", but it's not clear. When this definition was adopted it probably wasn't considered that someone might get IP service via a tunnel (over what?). We probably need to update this if we wish to exclude tunnels, or at least tunnels that aren't to the same ISP that provides the physical link. Interestingly, an org with two locations but no connection between them may qualify as multihomed, even if it only has one ISP at each location. Also, an org with one physical connection may qualify as multihomed if it has a tunnel to a second ISP. Not good. Note that all of these holes apply just as much to IPv4 if they also apply to IPv6. We either need an update to 2.7 or an official interpretation of "full-time connectivity", but IMHO they should no be considered potential flaws in this proposal specifically. > - one prefix and multiple physically seperate links > to the same provider That's commonly called redundancy, not multihoming. It doesn't fit the 2.7 definition in any case. > - one [or more] prefix[es] and multiple physically seperate links > to multiple providers That (as edited) seems to be a rewording of 2.7. > - multiple prefixes over one/multiple links The number of prefixes shouldn't be relevant. If anything, we should discourage end sites from announcing multiple prefixes. > and a large number of other possiblities. Good one of course: is a > tunnel a seperate link? Probably a reference to the wording on > getting an ASN would be good to include here. Section 5 just (implicitly) references section 2.7. That's no help. > The main thing I read from 2005-1 is that it gives the folks that want > it the possiblity to acquire a globally unique address space block. > Which is a good thing. But there should be a hard note, which is > also given in the other allocation policies, that the RIR in question > does not guarantee routability of that prefix. Section 6.4.2 already covers that. > IMHO something along the lines of: Pay an initial high fee (say $2k > US) and then every year a renewal fee ($500 US?) accomplishes > the same thing. Presumably ARIN would develop a fee schedule for these assignments. I think we only need to call that out if we have specific directions as to what the schedule should look like. I, for one, would like to see fees waived for a single IPv6 assignment for as long as the org is paying fees on one or more IPv4 assignments, but I think that should be a separate policy (assuming PI ever passes). > (Not that having a renewel currently makes sure the prefix is not > used any more but (S-)BGP(-S) could solve that problem one day ;) We have the same problem with all other assignment types too, so it's not unique to this proposal. S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin From gih at apnic.net Sat Feb 4 15:43:59 2006 From: gih at apnic.net (Geoff Huston) Date: Sun, 05 Feb 2006 07:43:59 +1100 Subject: [ppml] Policy Proposal 2005-9: 4-Byte AS Number - revised text In-Reply-To: <19C37754-AB83-46ED-8496-A386ED651BEA@multicasttech.com> References: <43E3A436.5050703@arin.net> <19C37754-AB83-46ED-8496-A386ED651BEA@multicasttech.com> Message-ID: <6.2.0.14.2.20060205073326.02c35008@kahuna.telstra.net> At 06:04 AM 4/02/2006, Marshall Eubanks wrote: >Dear Geoff; > >Could you possibly send to the list a diff with the previous version ? > >Regards >Marshall sure There are only 4 changes that have been applied - as noted below Geoff ========================================== Policy Proposal 2005-9: 4-Byte AS Number Author: Geoff Huston Proposal Version: Revision 1 (February 3, 2006) Proposal type: modify Policy term: temporary Policy statement: This policy proposal nominates 3 dates for changes to the current AS Number allocation policy for the registry: | - Commencing 1 January 2007 the registry will process Global change "On 1 January" to "Commencing 1 January | applications that specifically request 32-bit only AS Numbers Global change "4-byte" to "32-bit" and allocate such AS numbers as requested by the applicant. In the absence of any specific request for a 32-bit only AS | Number, a 16-bit only AS Number will be allocated by the global change "2-byte" to "16-bit" registry. - Commencing 1 January 2009 the registry will process applications that specifically request 16-bit only AS Numbers and allocate such AS Numbers as requested by the applicant. In the absence of any specific request for a 16-bit only AS Number, a 32-bit only AS Number will be allocated by the registry. - Commencing 1 January 2010 the registry will cease to make any distinction between 16-bit only AS Numbers and 32-bit only AS Numbers, and will operate AS number allocations from an undifferentiated 32-bit AS Number allocation pool. Nomenclature It is proposed to identify 32-bit AS Numbers using a syntax of | ".". Accordingly, a 32-bit AS number of value 65546 (decimal) would be identified as "1.10". Terminology "16-bit only AS Numbers" refers to AS numbers in the range 0 - 65535 "32-bit only AS Numbers" refers to AS Numbers in the range 1.0 - 65535.65535 (decimal range 65,536 - 4,294,967,295) "32-bit AS Numbers" refers to AS Numbers in the range 0.0 - 65535.65535 (decimal range 0 - 4,294,967,295) Rationale: Recent studies of AS number consumption rates indicate that the existing 16-bit pool of unallocated AS Numbers will be exhausted sometime in the period between 2010 and 2016, absent of any concerted efforts of recovery of already-allocated AS Numbers [1] [2]. Standardization work in the IETF has produced a document that is currently being submitted as a Proposed Standard that will expand the AS Number space to a 32-bit field [3]. It is noted that some advance period may be required by network operators to undertake the appropriate procedures relating to support of 32-bit AS numbers, and while no flag day is required in the transition to the longer AS Number field, it is recognised that a prudent course of action is to allow for allocation of these extended AS numbers well in advance of an anticipated 16-bit AS Number exhaustion date. This policy proposal details a set of actions and associated dates for RIR AS Number allocation policies to assist in an orderly transition to use of the 32-bit AS Number space. The essential attributes of this policy proposal are to facilitate the ease of transitional arrangements by equipment vendors, network managers and network operations staff, to provide the industry with some predictability in terms of dates and associated actions with respect to registry operational procedures for AS Number allocations. References [1] Daily AS Number Report, http://www.potaroo.net/tools/asns [2] ASNs MIA: A Comparision of RIR Statistics and RIS Reality, http://www.nanog.org/mtg-0510/wilhelm.html [3] BGP Support for Four-octet AS Number Space, draft-ietf-idr-as4bytes-12.txt Timetable for implementation: Procedures to support this proposal need to be implemented by 1 January 2007 From hannigan at renesys.com Sat Feb 4 18:26:01 2006 From: hannigan at renesys.com (Martin Hannigan) Date: Sat, 04 Feb 2006 18:26:01 -0500 Subject: [ppml] 2005-1 status In-Reply-To: <017801c629cc$61808e40$6501a8c0@ssprunk> References: <43E22A2D.3090801@hotnic.net> <47EC4C0B8D072F8B62111E1C@imac-en0.delong.sj.ca.us> <43E37113.3050905@hotnic.net> <1139073514.9125.16.camel@firenze.zurich.ibm.com> <017801c629cc$61808e40$6501a8c0@ssprunk> Message-ID: <7.0.1.0.0.20060204181320.01ae6918@renesys.com> At 03:38 PM 2/4/2006, you wrote: >Thus spake "Jeroen Massar" > > On Fri, 2006-02-03 at 10:04 -0500, Kevin Loch wrote: > > [..] [ SNIP] > > Putting down criteria is hard, probably too hard though. > > In either case scrap the "ARIN" part from the above. Some site might > > have arranged connectivity from a party in the LACNIC and one in the > > ARIN region and then they would be excluded from the above. > >Sounds logical. At least one link needs to be in ARIN's region for an >assignment to make sense; where the rest of the links go shouldn't matter. I always thought it was location of the entity. Signing contracts in foreign countries is expensive vis-a-vis, for one thing. I always felt that ARIN was serving areas, they do say region which to me implies area, vs. circuit landings. > > Of course the question 'what is multihoming' is another nice one: > >(Un?)fortunately, we already have an official definition. From the NRPM: > > 2.7 Multihomed > > An organization is multihomed if it receives full-time connectivity from > more than one ISP and has one or more routing prefixes announced > by at least two of its upstream ISPs. > >I'd like to think tunnels wouldn't qualify as "full-time connectivity", but >it's not clear. When this definition was adopted it probably wasn't >considered that someone might get IP service via a tunnel (over what?). We >probably need to update this if we wish to exclude tunnels, or at least >tunnels that aren't to the same ISP that provides the physical link. I'd advocate that tunnels do qualify as full time connectivity if you can go to and from the site via IPv6. The links themselves are simple electrical interfaces that know nothing about what is riding on them. >Interestingly, an org with two locations but no connection between them may >qualify as multihomed, even if it only has one ISP at each location. Also, >an org with one physical connection may qualify as multihomed if it has a >tunnel to a second ISP. Not good. The root server system does exactly this. >Note that all of these holes apply just as much to IPv4 if they also apply >to IPv6. We either need an update to 2.7 or an official interpretation of >"full-time connectivity", but IMHO they should no be considered potential >flaws in this proposal specifically. > [ SNIP ] You are right, but I think we should try and focus on 2005-1 for now. That was pretty overwhelming. :-) Martin Hannigan (c) 617-388-2663 Renesys Corporation (w) 617-395-8574 Member of the Technical Staff Network Operations hannigan at renesys.com From tme at multicasttech.com Sat Feb 4 19:28:30 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Sat, 4 Feb 2006 19:28:30 -0500 Subject: [ppml] Policy Proposal 2005-9: 4-Byte AS Number - revised text In-Reply-To: <6.2.0.14.2.20060205073326.02c35008@kahuna.telstra.net> References: <43E3A436.5050703@arin.net> <19C37754-AB83-46ED-8496-A386ED651BEA@multicasttech.com> <6.2.0.14.2.20060205073326.02c35008@kahuna.telstra.net> Message-ID: <882BC2DF-4D20-453A-9F9C-E1454F287283@multicasttech.com> Thanks. (I knew there weren't many, which is why I wanted a diff.) I support this as written. Regards Marshall On Feb 4, 2006, at 3:43 PM, Geoff Huston wrote: > At 06:04 AM 4/02/2006, Marshall Eubanks wrote: >> Dear Geoff; >> >> Could you possibly send to the list a diff with the previous >> version ? >> >> Regards >> Marshall > > > sure > > There are only 4 changes that have been applied - as noted below > > Geoff > > ========================================== > > Policy Proposal 2005-9: 4-Byte AS Number > > Author: Geoff Huston > > Proposal Version: Revision 1 (February 3, 2006) > > Proposal type: modify > > Policy term: temporary > > Policy statement: > > This policy proposal nominates 3 dates for changes to the > current AS Number allocation policy for the registry: > > | - Commencing 1 January 2007 the registry will process > > Global change "On 1 January" to "Commencing 1 January > > | applications that specifically request 32-bit only AS Numbers > > Global change "4-byte" to "32-bit" > > and allocate such AS numbers as requested by the applicant. In > the absence of any specific request for a 32-bit only AS > | Number, a 16-bit only AS Number will be allocated by the > > global change "2-byte" to "16-bit" > > registry. > > - Commencing 1 January 2009 the registry will process > applications that specifically request 16-bit only AS Numbers > and allocate such AS Numbers as requested by the applicant. In > the absence of any specific request for a 16-bit only AS > Number, a 32-bit only AS Number will be allocated by the > registry. > > - Commencing 1 January 2010 the registry will cease to make any > distinction between 16-bit only AS Numbers and 32-bit only AS > Numbers, and will operate AS number allocations from an > undifferentiated 32-bit AS Number allocation pool. > > Nomenclature > > It is proposed to identify 32-bit AS Numbers using a syntax of > | ". > global change ":" to "." > > decimal>". Accordingly, a 32-bit AS number of value 65546 > (decimal) would be identified as "1.10". > > > Terminology > > "16-bit only AS Numbers" refers to AS numbers in the range 0 - > 65535 > > "32-bit only AS Numbers" refers to AS Numbers in the range 1.0 - > 65535.65535 (decimal range 65,536 - 4,294,967,295) > > "32-bit AS Numbers" refers to AS Numbers in the range 0.0 - > 65535.65535 (decimal range 0 - 4,294,967,295) > > > Rationale: > > Recent studies of AS number consumption rates indicate that the > existing 16-bit pool of unallocated AS Numbers will be exhausted > sometime in the period between 2010 and 2016, absent of any > concerted efforts of recovery of already-allocated AS Numbers > [1] [2]. Standardization work in the IETF has produced a > document that is currently being submitted as a Proposed > Standard that will expand the AS Number space to a 32-bit field > [3]. > > It is noted that some advance period may be required by network > operators to undertake the appropriate procedures relating to > support of 32-bit AS numbers, and while no flag day is required > in the transition to the longer AS Number field, it is > recognised that a prudent course of action is to allow for > allocation of these extended AS numbers well in advance of an > anticipated 16-bit AS Number exhaustion date. > > This policy proposal details a set of actions and associated > dates for RIR AS Number allocation policies to assist in an > orderly transition to use of the 32-bit AS Number space. > > The essential attributes of this policy proposal are to > facilitate the ease of transitional arrangements by equipment > vendors, network managers and network operations staff, to > provide the industry with some predictability in terms of dates > and associated actions with respect to registry operational > procedures for AS Number allocations. > > References > > [1] Daily AS Number Report, http://www.potaroo.net/tools/asns > [2] ASNs MIA: A Comparision of RIR Statistics and RIS Reality, > http://www.nanog.org/mtg-0510/wilhelm.html > [3] BGP Support for Four-octet AS Number Space, > draft-ietf-idr-as4bytes-12.txt > > > Timetable for implementation: > > Procedures to support this proposal need to be implemented by 1 > January 2007 > > > From sleibrand at internap.com Sat Feb 4 16:47:08 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Sat, 4 Feb 2006 16:47:08 -0500 Subject: [ppml] Geo PI (draft-hain-ipv6-pi-addr-*) References: <054101c6285f$f6a10630$517ba8c0@tndh.net> Message-ID: <002301c62a01$f67fc3a0$651da8c0@LeibrandLaptop> Tony, I think an approach to lat/long PI addressing such as your draft-hain-ipv6-pi-addr-09.txt may be a solid foundation for choosing the PI block to assign to each individual organization. However, I think your draft-hain-ipv6-pi-addr-use-09.txt proposals, and previous discussion of similar ideas on PPML, have over-engineered the use cases and the implications for routing and exchange points. In particular, I read your drafts as requiring that all ISPs in a region would have to agree on the level of aggregation for the region and that all ISPs in that region interconnect at an exchange point, and also encouraging ISPs to filter more-specifics heard from their peers based on how many routes each origin AS announces and/or a certain prefix length. I think that all these requirements/suggestions are unnecessarily restrictive stipulations that encourage unnecessary opposition to the proposal. Here's what I see as a more realistic application of Geo PI: - Implement some sort of geography-based PI addressing scheme, either one like draft-hain-ipv6-pi-addr-09.txt, a population-based scheme like Michael Dillon has advocated, or something more like our current system, where RIRs allocate PI blocks to individual companies, but choose the particular netblock to allocate based on one of the schemes above. (I'm not sure which of those approaches is superior, but we can debate the merits of each separately.) - Initially, multihomed organizations allocated PI space would probably route them the exact same way they do IPv4 PI space today, announcing it in BGP to their transit providers, who would advertise it to everyone on the planet with a full BGP feed (the DFZ). - At some future point, some global tier 1 NSPs* may decide that the routing table growth is causing problems for their routers. At that point, they can begin aggregating PI space within their own network, such that within a region (which could be a BGP confederation sub-AS, for example) all more-specifics for that region are carried, but only the PI aggregate is carried outside the region. In order for an tier 1 NSP to do this effectively, they would have to ensure that all of their peers have at least two peering points within the region (private peering or exchanged-based, it doesn't matter), so that their peers can reach them and their customers' PI more-specifics for that region. - For transit customers outside the aggregated region, the tier 1 NSP would be able to just advertise the PI aggregate. For peers who only peer outside the region, the NSP could do one of several things: they could simply advertise the peer their PI aggregate, which opens the possibility of providing transit connectivity to the peer; they could carry all more-specifics from the aggregated region to the peering router(s), which would probably require a multihop BGP session or a tunnel; or they could simply not advertise routes from the aggregated region to their peer outside that region, requiring the peer to set up a peering point within the aggregated region or buy transit connectivity for traffic to that region. - When two or more NSPs set up such aggregation, a customer multi-homed to both NSPs would be able to announce their PI deaggregate to their transit providers just as they do now. Anyone trying to reach the customer from within the region (or from an NSP that doesn't aggregate) would be able to choose between the two resulting BGP paths. Anyone trying to reach the customer from outside the region would see the customer's IP space as part of a regional aggregate, and would route their traffic towards the region. Once the traffic arrived at the region, it would reach a router which would be able to choose between the two deaggregated paths, based on the BGP metrics (localpref, AS path, MEDs, etc.) set by the origin AS. - If the two NSPs the customer multi-homes to decide to aggregate differently, it might affect the traffic balance inbound to the multi-homed customer, but the customer will still have the leeway to adjust their announcements to compensate. For example, if NSP A aggregates a smaller region to a /32, and NSP B aggregates a larger region to a /28, then traffic from outside the larger region would prefer NSP A, while traffic from the in-between region would prefer NSP B, as the route would still be a deaggregate over NSP B in that region. Once traffic reached the smaller region, the origin AS's BGP metrics would take over. My point here is not that NSPs have to do things this way, but rather that a geography-based PI allocation scheme allows them to continue operating with the current model as long as they want to, and also gives them the flexibility to begin gradually aggregating PI space within their network as they see fit (for example by starting with large regions like continents, an later aggregating on a more regional basis as needed). We can implement such a geography-based PI allocation scheme *without* requiring everyone (or anyone) in a region to set up new interconnections, and without requiring anyone to coordinate the precise size of aggregated regions (and thereby the length of aggregate prefixes). IMO that makes it *much* more likely that such a system could reach consensus and actually get implemented. -Scott * A global tier 1 NSP means one who has a global backbone, don't buy transit from anyone, and have full reachability to the rest of the Internet via peering arrangements). P.S. Is there an IETF WG mailing list that draft-hain-ipv6-pi-addr* belong to? If so, I'd like to subscribe and cross-post the above message there as well. TIA. ----- Original Message ----- From: "Tony Hain" To: Sent: Thursday, February 02, 2006 8:20 PM Subject: Re: [ppml] 2005-1 status > An alternative to protocol design in either the routing space or host > stacks > is to reconsider the myth of a global DFZ. The divergence in routeviews > should already trigger the flag that there is no such thing as a globally > common DFZ, so arguing PI allocation policy in the context of its impact > on > this mythical entity is bound to drag on. > > I just refreshed my geo I-D's > http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-09.txt > http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-use-09.txt > > Rather than argue about the topology/geography argument, please consider > that this is: > 1) an identifiable block > 2) does not require any changes to existing hosts or routers > 3) removes any arguments about prefix length vs. organizational size > 4) allows for simple proxy aggregation where the detail becomes irrelevant > 5) debases ITU/national arguments over access to sovereign allocations > > In the worst case these degenerate to the same number of routing slots as > an > arbitrary RIR allocation process. At the same time they lay a foundation > where alternative business practices can evolve to better align the costs > involved. > > Comments are always welcome (particularly thoughts about how to resolve > the > altitude problem) > > Tony > > >> -----Original Message----- >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of >> Scott Leibrand >> Sent: Thursday, February 02, 2006 6:12 AM >> To: Bill Darte >> Cc: ppml at arin.net >> Subject: Re: [ppml] 2005-1 status >> >> Bill and Owen, >> >> What if the IETF comes up with a routing architecture / protocol design >> that allows for effective multihoming with PA space? That seems more >> likely to me (in the near term) than a complete replacement of BGP4. >> >> IMO policy should recognize the status quo for what it is: the way things >> are done. If the status quo needs to change, fine. That's why we're >> debating 2005-1. But I think it's dangerous to make policy with the goal >> of breaking things so that someone else will be forced to fix them later. >> IMO we should make policy that meets the current needs of our >> constituents, and strive to meet their future needs by working through >> the >> IETF process to fix the routing architecture, and then modifying policy >> in >> the future when future interests have emerged and we have a clearer idea >> of the tradeoffs. >> >> -Scott >> >> On 02/02/06 at 8:15am -0600, Bill Darte wrote: >> >> > Owen, >> > >> > My personal belief is that you frame the question(s) appropriately in >> this >> > post. >> > If the architecture of the Internet no longer serves the emerging >> interests >> > of the constituents, then the architecture should change, rather than >> trying >> > to craft discriminating address policy that preserves the status quo. >> > >> > On a slightly different topic, with the PI for endsites policy, there >> > is >> no >> > stipulation about the v4 blocks that exist in the v6 recipients >> > 'possession'. You are assuming that that legacy assignment would >> > endure >> in >> > perpetuity? You have no expectation that the v6 block would require the >> > legacy v4 blocks, whether PA or PI to be returned? >> > >> > I'm not suggesting this be the case...just want this issue to be >> addressed. >> > >> > bd >> > >> > > -----Original Message----- >> > > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On >> > > Behalf Of Owen DeLong >> > > Sent: Thursday, February 02, 2006 12:35 AM >> > > To: Scott Leibrand; George Kuzmowycz >> > > Cc: ppml at arin.net >> > > Subject: Re: [ppml] 2005-1 status >> > > >> > > >> > > _______________________________________________ >> > > 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 >> > >> _______________________________________________ >> 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 > From sleibrand at internap.com Sat Feb 4 22:20:05 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Sat, 4 Feb 2006 22:20:05 -0500 (EST) Subject: [ppml] Policy Proposal 2005-9: 4-Byte AS Number - revised text In-Reply-To: <882BC2DF-4D20-453A-9F9C-E1454F287283@multicasttech.com> References: <43E3A436.5050703@arin.net> <19C37754-AB83-46ED-8496-A386ED651BEA@multicasttech.com> <6.2.0.14.2.20060205073326.02c35008@kahuna.telstra.net> <882BC2DF-4D20-453A-9F9C-E1454F287283@multicasttech.com> Message-ID: On 02/04/06 at 7:28pm -0500, Marshall Eubanks wrote: > Thanks. (I knew there weren't many, which is why I wanted a diff.) > > I support this as written. Ditto. -Scott > On Feb 4, 2006, at 3:43 PM, Geoff Huston wrote: > > > At 06:04 AM 4/02/2006, Marshall Eubanks wrote: > >> Dear Geoff; > >> > >> Could you possibly send to the list a diff with the previous > >> version ? > >> > >> Regards > >> Marshall > > > > > > sure > > > > There are only 4 changes that have been applied - as noted below > > > > Geoff > > > > ========================================== > > > > Policy Proposal 2005-9: 4-Byte AS Number > > > > Author: Geoff Huston > > > > Proposal Version: Revision 1 (February 3, 2006) > > > > Proposal type: modify > > > > Policy term: temporary > > > > Policy statement: > > > > This policy proposal nominates 3 dates for changes to the > > current AS Number allocation policy for the registry: > > > > | - Commencing 1 January 2007 the registry will process > > > > Global change "On 1 January" to "Commencing 1 January > > > > | applications that specifically request 32-bit only AS Numbers > > > > Global change "4-byte" to "32-bit" > > > > and allocate such AS numbers as requested by the applicant. In > > the absence of any specific request for a 32-bit only AS > > | Number, a 16-bit only AS Number will be allocated by the > > > > global change "2-byte" to "16-bit" > > > > registry. > > > > - Commencing 1 January 2009 the registry will process > > applications that specifically request 16-bit only AS Numbers > > and allocate such AS Numbers as requested by the applicant. In > > the absence of any specific request for a 16-bit only AS > > Number, a 32-bit only AS Number will be allocated by the > > registry. > > > > - Commencing 1 January 2010 the registry will cease to make any > > distinction between 16-bit only AS Numbers and 32-bit only AS > > Numbers, and will operate AS number allocations from an > > undifferentiated 32-bit AS Number allocation pool. > > > > Nomenclature > > > > It is proposed to identify 32-bit AS Numbers using a syntax of > > | ". > > > global change ":" to "." > > > > decimal>". Accordingly, a 32-bit AS number of value 65546 > > (decimal) would be identified as "1.10". > > > > > > Terminology > > > > "16-bit only AS Numbers" refers to AS numbers in the range 0 - > > 65535 > > > > "32-bit only AS Numbers" refers to AS Numbers in the range 1.0 - > > 65535.65535 (decimal range 65,536 - 4,294,967,295) > > > > "32-bit AS Numbers" refers to AS Numbers in the range 0.0 - > > 65535.65535 (decimal range 0 - 4,294,967,295) > > > > > > Rationale: > > > > Recent studies of AS number consumption rates indicate that the > > existing 16-bit pool of unallocated AS Numbers will be exhausted > > sometime in the period between 2010 and 2016, absent of any > > concerted efforts of recovery of already-allocated AS Numbers > > [1] [2]. Standardization work in the IETF has produced a > > document that is currently being submitted as a Proposed > > Standard that will expand the AS Number space to a 32-bit field > > [3]. > > > > It is noted that some advance period may be required by network > > operators to undertake the appropriate procedures relating to > > support of 32-bit AS numbers, and while no flag day is required > > in the transition to the longer AS Number field, it is > > recognised that a prudent course of action is to allow for > > allocation of these extended AS numbers well in advance of an > > anticipated 16-bit AS Number exhaustion date. > > > > This policy proposal details a set of actions and associated > > dates for RIR AS Number allocation policies to assist in an > > orderly transition to use of the 32-bit AS Number space. > > > > The essential attributes of this policy proposal are to > > facilitate the ease of transitional arrangements by equipment > > vendors, network managers and network operations staff, to > > provide the industry with some predictability in terms of dates > > and associated actions with respect to registry operational > > procedures for AS Number allocations. > > > > References > > > > [1] Daily AS Number Report, http://www.potaroo.net/tools/asns > > [2] ASNs MIA: A Comparision of RIR Statistics and RIS Reality, > > http://www.nanog.org/mtg-0510/wilhelm.html > > [3] BGP Support for Four-octet AS Number Space, > > draft-ietf-idr-as4bytes-12.txt > > > > > > Timetable for implementation: > > > > Procedures to support this proposal need to be implemented by 1 > > January 2007 > > > > > > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From alh-ietf at tndh.net Mon Feb 6 01:27:51 2006 From: alh-ietf at tndh.net (Tony Hain) Date: Sun, 5 Feb 2006 22:27:51 -0800 Subject: [ppml] Geo PI (draft-hain-ipv6-pi-addr-*) In-Reply-To: <002301c62a01$f67fc3a0$651da8c0@LeibrandLaptop> Message-ID: <082e01c62ae6$74c94530$517ba8c0@tndh.net> Scott Leibrand wrote: > Tony, > > I think an approach to lat/long PI addressing such as your > draft-hain-ipv6-pi-addr-09.txt may be a solid foundation for choosing the > PI > block to assign to each individual organization. However, I think your > draft-hain-ipv6-pi-addr-use-09.txt proposals, and previous discussion of > similar ideas on PPML, have over-engineered the use cases and the > implications for routing and exchange points. In particular, I read your > drafts as requiring that all ISPs in a region would have to agree on the > level of aggregation for the region and that all ISPs in that region > interconnect at an exchange point, and also encouraging ISPs to filter > more-specifics heard from their peers based on how many routes each origin > AS announces and/or a certain prefix length. I think that all these > requirements/suggestions are unnecessarily restrictive stipulations that > encourage unnecessary opposition to the proposal. Exchange points are discussed, but would only really be required to suppress the basement multi-homer. There are business model issues tied up in this that will take a long time to resolve if they ever do. In the short term just basing PI allocations on this model would at least allow for the option later where random PI assignments would be difficult to sort out. > > Here's what I see as a more realistic application of Geo PI: > > - Implement some sort of geography-based PI addressing scheme, either one > like draft-hain-ipv6-pi-addr-09.txt, a population-based scheme like > Michael > Dillon has advocated, or something more like our current system, where > RIRs > allocate PI blocks to individual companies, but choose the particular > netblock to allocate based on one of the schemes above. (I'm not sure > which > of those approaches is superior, but we can debate the merits of each > separately.) To judge there needs to be some agreed on goals. The IETF effort in that space showed how there can never be agreement since the requirements of the ISP community and the end site community are in direct conflict. > - Initially, multihomed organizations allocated PI space would probably > route them the exact same way they do IPv4 PI space today, announcing it > in > BGP to their transit providers, who would advertise it to everyone on the > planet with a full BGP feed (the DFZ). A presumption for all approaches is that organizations that have an AS entry in BGP will have at least one prefix. Hopefully one will be sufficient, but I am hearing noise that some organizations want hundreds to deal with their VPN scenario. > - At some future point, some global tier 1 NSPs* may decide that the > routing table growth is causing problems for their routers. At that > point, > they can begin aggregating PI space within their own network, such that > within a region (which could be a BGP confederation sub-AS, for example) > all > more-specifics for that region are carried, but only the PI aggregate is > carried outside the region. In order for an tier 1 NSP to do this > effectively, they would have to ensure that all of their peers have at > least > two peering points within the region (private peering or exchanged-based, > it > doesn't matter), so that their peers can reach them and their customers' > PI > more-specifics for that region. I didn't want to get into the details of engineering the region more than to point out that some interchange will have to happen. > - For transit customers outside the aggregated region, the tier 1 NSP > would > be able to just advertise the PI aggregate. For peers who only peer > outside > the region, the NSP could do one of several things: they could simply > advertise the peer their PI aggregate, which opens the possibility of > providing transit connectivity to the peer; they could carry all > more-specifics from the aggregated region to the peering router(s), which > would probably require a multihop BGP session or a tunnel; or they could > simply not advertise routes from the aggregated region to their peer > outside > that region, requiring the peer to set up a peering point within the > aggregated region or buy transit connectivity for traffic to that region. The business models will develop based on what makes sense for that specific region. > - When two or more NSPs set up such aggregation, a customer multi-homed > to > both NSPs would be able to announce their PI deaggregate to their transit > providers just as they do now. Anyone trying to reach the customer from > within the region (or from an NSP that doesn't aggregate) would be able to > choose between the two resulting BGP paths. Anyone trying to reach the > customer from outside the region would see the customer's IP space as part > of a regional aggregate, and would route their traffic towards the region. > Once the traffic arrived at the region, it would reach a router which > would > be able to choose between the two deaggregated paths, based on the BGP > metrics (localpref, AS path, MEDs, etc.) set by the origin AS. > - If the two NSPs the customer multi-homes to decide to aggregate > differently, it might affect the traffic balance inbound to the multi- > homed > customer, but the customer will still have the leeway to adjust their > announcements to compensate. For example, if NSP A aggregates a smaller > region to a /32, and NSP B aggregates a larger region to a /28, then > traffic > from outside the larger region would prefer NSP A, while traffic from the > in-between region would prefer NSP B, as the route would still be a > deaggregate over NSP B in that region. Once traffic reached the smaller > region, the origin AS's BGP metrics would take over. > > My point here is not that NSPs have to do things this way, but rather that > a > geography-based PI allocation scheme allows them to continue operating > with > the current model as long as they want to, and also gives them the > flexibility to begin gradually aggregating PI space within their network > as > they see fit (for example by starting with large regions like continents, > an > later aggregating on a more regional basis as needed). We can implement > such a geography-based PI allocation scheme *without* requiring everyone > (or > anyone) in a region to set up new interconnections, and without requiring > anyone to coordinate the precise size of aggregated regions (and thereby > the > length of aggregate prefixes). IMO that makes it *much* more likely that > such a system could reach consensus and actually get implemented. I don't expect transit providers to even consider aggregation until there is an exchange point in the region acting as their customer and fronting for the local distribution of traffic. Fortunately it is not required to get started and can come along when it makes more sense to aggregate than to buy bigger routers. Thanks for the feedback, Tony > > -Scott > > * A global tier 1 NSP means one who has a global backbone, don't buy > transit > from anyone, and have full reachability to the rest of the Internet via > peering arrangements). > > P.S. Is there an IETF WG mailing list that draft-hain-ipv6-pi-addr* belong > to? If so, I'd like to subscribe and cross-post the above message there > as > well. TIA. > > > ----- Original Message ----- > From: "Tony Hain" > To: > Sent: Thursday, February 02, 2006 8:20 PM > Subject: Re: [ppml] 2005-1 status > > > > An alternative to protocol design in either the routing space or host > > stacks > > is to reconsider the myth of a global DFZ. The divergence in routeviews > > should already trigger the flag that there is no such thing as a > globally > > common DFZ, so arguing PI allocation policy in the context of its impact > > on > > this mythical entity is bound to drag on. > > > > I just refreshed my geo I-D's > > http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-09.txt > > http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-use-09.txt > > > > Rather than argue about the topology/geography argument, please consider > > that this is: > > 1) an identifiable block > > 2) does not require any changes to existing hosts or routers > > 3) removes any arguments about prefix length vs. organizational size > > 4) allows for simple proxy aggregation where the detail becomes > irrelevant > > 5) debases ITU/national arguments over access to sovereign allocations > > > > In the worst case these degenerate to the same number of routing slots > as > > an > > arbitrary RIR allocation process. At the same time they lay a foundation > > where alternative business practices can evolve to better align the > costs > > involved. > > > > Comments are always welcome (particularly thoughts about how to resolve > > the > > altitude problem) > > > > Tony > > > > > >> -----Original Message----- > >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of > >> Scott Leibrand > >> Sent: Thursday, February 02, 2006 6:12 AM > >> To: Bill Darte > >> Cc: ppml at arin.net > >> Subject: Re: [ppml] 2005-1 status > >> > >> Bill and Owen, > >> > >> What if the IETF comes up with a routing architecture / protocol design > >> that allows for effective multihoming with PA space? That seems more > >> likely to me (in the near term) than a complete replacement of BGP4. > >> > >> IMO policy should recognize the status quo for what it is: the way > things > >> are done. If the status quo needs to change, fine. That's why we're > >> debating 2005-1. But I think it's dangerous to make policy with the > goal > >> of breaking things so that someone else will be forced to fix them > later. > >> IMO we should make policy that meets the current needs of our > >> constituents, and strive to meet their future needs by working through > >> the > >> IETF process to fix the routing architecture, and then modifying policy > >> in > >> the future when future interests have emerged and we have a clearer > idea > >> of the tradeoffs. > >> > >> -Scott > >> > >> On 02/02/06 at 8:15am -0600, Bill Darte wrote: > >> > >> > Owen, > >> > > >> > My personal belief is that you frame the question(s) appropriately in > >> this > >> > post. > >> > If the architecture of the Internet no longer serves the emerging > >> interests > >> > of the constituents, then the architecture should change, rather than > >> trying > >> > to craft discriminating address policy that preserves the status quo. > >> > > >> > On a slightly different topic, with the PI for endsites policy, there > >> > is > >> no > >> > stipulation about the v4 blocks that exist in the v6 recipients > >> > 'possession'. You are assuming that that legacy assignment would > >> > endure > >> in > >> > perpetuity? You have no expectation that the v6 block would require > the > >> > legacy v4 blocks, whether PA or PI to be returned? > >> > > >> > I'm not suggesting this be the case...just want this issue to be > >> addressed. > >> > > >> > bd > >> > > >> > > -----Original Message----- > >> > > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > >> > > Behalf Of Owen DeLong > >> > > Sent: Thursday, February 02, 2006 12:35 AM > >> > > To: Scott Leibrand; George Kuzmowycz > >> > > Cc: ppml at arin.net > >> > > Subject: Re: [ppml] 2005-1 status > >> > > > >> > > > >> > > _______________________________________________ > >> > > 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 > >> > > >> _______________________________________________ > >> 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 > > From Michael.Dillon at btradianz.com Mon Feb 6 05:01:02 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Mon, 6 Feb 2006 10:01:02 +0000 Subject: [ppml] 2005-1 status In-Reply-To: <00e201c62911$1530a450$6601a8c0@ssprunk> Message-ID: > > Secondly, according to the existing IPv6 policy, if McDonalds were to > > go to an ISP and ask for IPv6 connectivity for their network of 12,300 > > restaurants, the ISP would assign them 12,300 /48 address blocks. > > That is the policy ... > > No, the current policy is that the LIR can assign a single /48 or forward > the request for more (with justification) to ARIN. > > You're confusing "end site" with "location". According to the NRPM: > > 6.2.9. End site > > An end site is defined as an end user (subscriber) [...] > > So, a single end user organization counts as one "end site" regardless of > the number of physical locations it has. Well, it seems like the policy needs more work to change this silliness. IPv6 addressing was intended to assign a /48 to a single end-site meaning more-or-less a single location. My apartment, your house, the Walgreen's store on the corner. RIPE has started to correct this with a policy proposal http://www.ripe.net/ripe/policies/proposals/2005-4.html to clarify the wording. Let's face it, McDonald's Restaurants is never going to buy an IPv6 connection to the IPv6 Internet if they already have a private network connecting all the restaurants. We are not supposed to be scrimping and saving on IPv6 address space by wringing our hands over whether or not a site DESERVES a /48. --Michael Dillon From Michael.Dillon at btradianz.com Mon Feb 6 05:06:23 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Mon, 6 Feb 2006 10:06:23 +0000 Subject: [ppml] 2005-1 status In-Reply-To: <017801c629cc$61808e40$6501a8c0@ssprunk> Message-ID: > Good point; that's a major oversight. Though I think the fees for doing it > would discourage most folks, it still needs to be fixed/clarified. Careful about this. It would not be wise to draw the Department of Justice into a "restraint of trade" investigation. Fees need to be fair and represent the value provided. One can argue that the value provided by ARIN to a service provider is vastly larger than the value provided to an end user and therefore, the end user fees should be vastly lower than the service provider fees. In addition, the annual fees reflect the fact that service providers require continuing support from ARIN because of their assignment activity and the inevitable requests for additional allocations. This is not the case for end users. Can you justify an onging fee at all? And can you justify more than a $100 first time fee? --Michael Dillon From leo at ripe.net Mon Feb 6 09:20:37 2006 From: leo at ripe.net (leo vegoda) Date: Mon, 6 Feb 2006 15:20:37 +0100 Subject: [ppml] 2005-1 status In-Reply-To: Message-ID: <00ce01c62b28$80073500$1d0200c1@FluffyBunny> Hi Michael, On Monday, February 06, 2006 11:01 AM, you wrote: [...] > RIPE has started to correct this with a policy proposal > http://www.ripe.net/ripe/policies/proposals/2005-4.html > to clarify the wording. Please note that this policy proposal was withdrawn by the proposer. Regards, -- leo vegoda RIPE NCC Registration Services Manager From dlw+arin at tellme.com Mon Feb 6 10:41:07 2006 From: dlw+arin at tellme.com (David Williamson) Date: Mon, 6 Feb 2006 07:41:07 -0800 Subject: [ppml] Policy Proposal 2005-9: 4-Byte AS Number - revised text In-Reply-To: <882BC2DF-4D20-453A-9F9C-E1454F287283@multicasttech.com> References: <43E3A436.5050703@arin.net> <19C37754-AB83-46ED-8496-A386ED651BEA@multicasttech.com> <6.2.0.14.2.20060205073326.02c35008@kahuna.telstra.net> <882BC2DF-4D20-453A-9F9C-E1454F287283@multicasttech.com> Message-ID: <20060206154107.GG853@shell01.corp.tellme.com> I generally don't like posts of the "me too!" variety, but in this case I think it's important to give a sense of the community's reaction. So...I agree: I support this as re-written. Thanks! -David On Sat, Feb 04, 2006 at 07:28:30PM -0500, Marshall Eubanks wrote: > Thanks. (I knew there weren't many, which is why I wanted a diff.) > > I support this as written. > > Regards > Marshall > > On Feb 4, 2006, at 3:43 PM, Geoff Huston wrote: > > > At 06:04 AM 4/02/2006, Marshall Eubanks wrote: > >> Dear Geoff; > >> > >> Could you possibly send to the list a diff with the previous > >> version ? > >> > >> Regards > >> Marshall > > > > > > sure > > > > There are only 4 changes that have been applied - as noted below > > > > Geoff > > > > ========================================== > > > > Policy Proposal 2005-9: 4-Byte AS Number > > > > Author: Geoff Huston > > > > Proposal Version: Revision 1 (February 3, 2006) > > > > Proposal type: modify > > > > Policy term: temporary > > > > Policy statement: > > > > This policy proposal nominates 3 dates for changes to the > > current AS Number allocation policy for the registry: > > > > | - Commencing 1 January 2007 the registry will process > > > > Global change "On 1 January" to "Commencing 1 January > > > > | applications that specifically request 32-bit only AS Numbers > > > > Global change "4-byte" to "32-bit" > > > > and allocate such AS numbers as requested by the applicant. In > > the absence of any specific request for a 32-bit only AS > > | Number, a 16-bit only AS Number will be allocated by the > > > > global change "2-byte" to "16-bit" > > > > registry. > > > > - Commencing 1 January 2009 the registry will process > > applications that specifically request 16-bit only AS Numbers > > and allocate such AS Numbers as requested by the applicant. In > > the absence of any specific request for a 16-bit only AS > > Number, a 32-bit only AS Number will be allocated by the > > registry. > > > > - Commencing 1 January 2010 the registry will cease to make any > > distinction between 16-bit only AS Numbers and 32-bit only AS > > Numbers, and will operate AS number allocations from an > > undifferentiated 32-bit AS Number allocation pool. > > > > Nomenclature > > > > It is proposed to identify 32-bit AS Numbers using a syntax of > > | ". > > > global change ":" to "." > > > > decimal>". Accordingly, a 32-bit AS number of value 65546 > > (decimal) would be identified as "1.10". > > > > > > Terminology > > > > "16-bit only AS Numbers" refers to AS numbers in the range 0 - > > 65535 > > > > "32-bit only AS Numbers" refers to AS Numbers in the range 1.0 - > > 65535.65535 (decimal range 65,536 - 4,294,967,295) > > > > "32-bit AS Numbers" refers to AS Numbers in the range 0.0 - > > 65535.65535 (decimal range 0 - 4,294,967,295) > > > > > > Rationale: > > > > Recent studies of AS number consumption rates indicate that the > > existing 16-bit pool of unallocated AS Numbers will be exhausted > > sometime in the period between 2010 and 2016, absent of any > > concerted efforts of recovery of already-allocated AS Numbers > > [1] [2]. Standardization work in the IETF has produced a > > document that is currently being submitted as a Proposed > > Standard that will expand the AS Number space to a 32-bit field > > [3]. > > > > It is noted that some advance period may be required by network > > operators to undertake the appropriate procedures relating to > > support of 32-bit AS numbers, and while no flag day is required > > in the transition to the longer AS Number field, it is > > recognised that a prudent course of action is to allow for > > allocation of these extended AS numbers well in advance of an > > anticipated 16-bit AS Number exhaustion date. > > > > This policy proposal details a set of actions and associated > > dates for RIR AS Number allocation policies to assist in an > > orderly transition to use of the 32-bit AS Number space. > > > > The essential attributes of this policy proposal are to > > facilitate the ease of transitional arrangements by equipment > > vendors, network managers and network operations staff, to > > provide the industry with some predictability in terms of dates > > and associated actions with respect to registry operational > > procedures for AS Number allocations. > > > > References > > > > [1] Daily AS Number Report, http://www.potaroo.net/tools/asns > > [2] ASNs MIA: A Comparision of RIR Statistics and RIS Reality, > > http://www.nanog.org/mtg-0510/wilhelm.html > > [3] BGP Support for Four-octet AS Number Space, > > draft-ietf-idr-as4bytes-12.txt > > > > > > Timetable for implementation: > > > > Procedures to support this proposal need to be implemented by 1 > > January 2007 > > > > > > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From iggy at merit.edu Mon Feb 6 11:19:15 2006 From: iggy at merit.edu (Glenn Wiltse) Date: Mon, 6 Feb 2006 11:19:15 -0500 (EST) Subject: [ppml] 2005-1 status In-Reply-To: References: Message-ID: To state the same posistion as Michael in a slightly differnt mannor, to illustrate the sillyness of saying McDonalds or other simmilarly large orginization should only receive a /48 or /47 if they should get a PI assignment... If each individual McDonald's location/franchise went to a single ISP or even multiple ISDs to get IPv6 space, then each location/fanchise would in fact be assigned a /48. So, later lets say McDonalds the corperation decides they want to provide newtworking services to all of their locations independent of any other ISP/LIR. In my opinion... It is very silly to expect the individual locations to settle for any less then they would have previously been allowed to have if they'd gotten space from a ISP/LIR. In effect, McDonald's coperation would become a ISP and should not be treated as if they were a single 'end site'. As such, it is my opinion that McDonalds coperation should be entitled to treating each end every retail location as a seperate 'end site'. Glenn Wiltse On Mon, 6 Feb 2006, Michael.Dillon at btradianz.com wrote: >>> Secondly, according to the existing IPv6 policy, if McDonalds were to >>> go to an ISP and ask for IPv6 connectivity for their network of 12,300 >>> restaurants, the ISP would assign them 12,300 /48 address blocks. >>> That is the policy ... >> >> No, the current policy is that the LIR can assign a single /48 or > forward >> the request for more (with justification) to ARIN. >> >> You're confusing "end site" with "location". According to the NRPM: >> >> 6.2.9. End site >> >> An end site is defined as an end user (subscriber) [...] >> >> So, a single end user organization counts as one "end site" regardless > of >> the number of physical locations it has. > > Well, it seems like the policy needs more work to change > this silliness. IPv6 addressing was intended to assign a > /48 to a single end-site meaning more-or-less a single > location. My apartment, your house, the Walgreen's store > on the corner. > > RIPE has started to correct this with a policy proposal > http://www.ripe.net/ripe/policies/proposals/2005-4.html > to clarify the wording. > > Let's face it, McDonald's Restaurants is never going to > buy an IPv6 connection to the IPv6 Internet if they already > have a private network connecting all the restaurants. > > We are not supposed to be scrimping and saving on IPv6 > address space by wringing our hands over whether or not > a site DESERVES a /48. > > --Michael Dillon > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > > !DSPAM:43e71e45259253056428827! > > From iggy at merit.edu Mon Feb 6 12:51:17 2006 From: iggy at merit.edu (Glenn Wiltse) Date: Mon, 6 Feb 2006 12:51:17 -0500 (EST) Subject: [ppml] 2005-1 status In-Reply-To: <00e301c62911$15b89900$6601a8c0@ssprunk> References: <43E22A2D.3090801@hotnic.net><47EC4C0B8D072F8B62111E1C@imac-en0.delong.sj.ca.us><43E37113.3050905@hotnic.net> <00e301c62911$15b89900$6601a8c0@ssprunk> Message-ID: IPv4 does have some fairly specific criteria for obtaining ip assignments driectly from ARIN. Many of these critiera are based on the realitive scarcity of IPv4 address space. The term utilization rate is used, and basicly describes some percentage of total ip address space used. You must have a imediate need for 25% utilization and expect 50% utilization within a year of the assignment, 80% before you can get more, etc... IPv6 address space is not scarce, in fact right now in the ARIN region it seems we are having trouble getting people interested in using it. Typicaly utilization rates for IPv6 are spoken of in terms of the number of /48s that are assigned, not in terms of IP addresses or even in terms of /64s used. I personaly think it's somewhat futile to try and duplicate the general IPv4 scheem of things, in hopes that it will suit the needs of IPv6 policy. In general we need to get away from the idea that IPv6 is somehow scarce. More specificly I don't think orginizations with PI IPv6 needs should be forced into a realtively small amount of IPv6 space simply because they are not a "ISP". Especially when many large orginizations with PI needs, quite possibly have a greater real need for space then many small ISPs do. When we are using words like 'site' we would be wise not just ignore the fact that the word typicaly is used to refer to a physical location and is not somehow synonymous with 'user' or 'orginzation'. Oh, and no offense to the people who work at ARIN, but I'm not comfortable making vague policy that gives them nearly unlimited discretion in maters that should be realtively well defined in public policy. If I were comfortable giving ARIN staff that much discretion, I'd probably just stay home rather then attend ARIN Public Policy Meetings. Glenn Wiltse On Fri, 3 Feb 2006, Stephen Sprunk wrote: > Thus spake "Glenn Wiltse" >> I find the re-working of this proposal as shown here, to be of little >> or no value. It gives no explination of what criteria there would be for >> obtaining more then a /48. > > In reviewing the IPv4 policy, I don't see much direction on what is required > to justify more than the minimum size for an initial end-user v4 allocation, > and what little there is doesn't seem to apply to v6. The ARIN staff has a > lot of discretion in what "justify" means in v4 policies, so I don't see any > departure from existing practice in using the same word in v6 policy. Also, > whereas justification is required in nearly all v4 assignments, it should be > fairly rare in v6 assignments since the minimum size is already very large. > > Also, there is existing policy (6.5.4.2) that explicitly calls out the lack > of formal criteria for giving end sites more than a /48. The proposal under > discussion does no worse than what we already have. > >> In general as it relates to this and the earlier version, I object to >> the use of the term 'large/complex end sites', since, the biggest need for >> these types of direct assignments are for multi homed orginizations, not a >> a 'end site'. I belive this policy should be addressing the need of the >> 'large/complex orginzation' that doesn't want to have their IPv6 address >> space directly tied to a ISP/LIR. In my mind, these should not be >> considered 'end sites'. > > So if we changed the section heading (which has absolutely no effect on the > policy) from > > 6.5.8. Direct assignments to large/complex end sites > > to > > 6.5.8. Direct assignments to end-user organizations > > this objection would be moot? > > 6.2.9 defines "end sites" to be synonymous with "end-user organizations", > even though "site" implies a single physical location. The idea that > end-user orgs often have private connectivity between locations is > consistently missed by the ISP folks here, hence the misleading term. > > The "large/complex" modifier is superfluous, but the qualifications are most > likely to be met by such orgs. > >> Either way, it seems to me we aren't anywhere near consensus on >> this issue, and I don't think this re-work gets us any closer. > > You're welcome to float your own proposal on what you think can achieve > consensus. I'm sure Kevin will be happy to hear any constructive input you > have on his draft as well. > > S > > Stephen Sprunk "Stupid people surround themselves with smart > CCIE #3723 people. Smart people surround themselves with > K5SSS smart people who disagree with them." --Aaron Sorkin > > !DSPAM:43e3d91912276650412592! > > From stephen at sprunk.org Mon Feb 6 14:42:03 2006 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 6 Feb 2006 13:42:03 -0600 Subject: [ppml] 2005-1 status References: Message-ID: <00ff01c62b58$cf627350$feac1cac@ssprunk> Thus spake >> > Secondly, according to the existing IPv6 policy, if McDonalds were to >> > go to an ISP and ask for IPv6 connectivity for their network of 12,300 >> > restaurants, the ISP would assign them 12,300 /48 address blocks. >> > That is the policy ... >> >> No, the current policy is that the LIR can assign a single /48 or >> forward the request for more (with justification) to ARIN. >> >> You're confusing "end site" with "location". According to the NRPM: >> >> 6.2.9. End site >> >> An end site is defined as an end user (subscriber) [...] >> >> So, a single end user organization counts as one "end site" regardless >> of the number of physical locations it has. > > Well, it seems like the policy needs more work to change > this silliness. IPv6 addressing was intended to assign a > /48 to a single end-site meaning more-or-less a single > location. My apartment, your house, the Walgreen's store > on the corner. That may have been the intent, but unless the author of that section speaks up, I think it's open for debate. IMHO, the intent was to assign a /48 to each leaf org unless they justified more regardless of the number of locations, and the choice of the word "site" was unfortunate. Note that 6.2.9 applies to PA space just as much as PI space, so if we want to change that it should be in a separate proposal from one that creates PI in the first place. And, for the record, I think the current proposal is useful whether or not 6.2.9 is changed. > RIPE has started to correct this with a policy proposal > http://www.ripe.net/ripe/policies/proposals/2005-4.html > to clarify the wording. As noted by Leo Vegoda, this has been withdrawn. I'd be interested in knowing why, though, in case it indicates what our experience might be in the same area. > Let's face it, McDonald's Restaurants is never going to > buy an IPv6 connection to the IPv6 Internet if they already > have a private network connecting all the restaurants. Why not? Such orgs likely use 10/8 today with NAT for global connectivity, and I don't see why they'd bother to deploy IPv6 in the first place without an IPv6 upstream connection. While I can't come up with a specific example of why McD's restaurants might need public IP connectivity, I know other similarly large orgs (which I can't detail) that need nearly every host in their network to have both inbound and outbound connectivity to other parties. This is a pain with IPv4 due to NAT, but IPv6 solves that nicely provided they can get PI space. The alternative is ULAs and NAT. > We are not supposed to be scrimping and saving on IPv6 > address space by wringing our hands over whether or not > a site DESERVES a /48. Nor are we supposed to be doing our best to waste IPv6 space by holding to an unstated "/48 per location" policy when a typical location only needs one or two /64s. If an applicant came back with reasonable justification why their site (i.e. org) needed more than a /48 total, even to the level of a /48 per location, I'm confident ARIN would go along with it. There is nothing in the proposal that prohibits such if it's justified. S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin From stephen at sprunk.org Mon Feb 6 14:54:13 2006 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 6 Feb 2006 13:54:13 -0600 Subject: [ppml] 2005-1 status References: <43E22A2D.3090801@hotnic.net> <47EC4C0B8D072F8B62111E1C@imac-en0.delong.sj.ca.us> <43E37113.3050905@hotnic.net> <1139073514.9125.16.camel@firenze.zurich.ibm.com> <017801c629cc$61808e40$6501a8c0@ssprunk> <7.0.1.0.0.20060204181320.01ae6918@renesys.com> Message-ID: <010001c62b58$cfca5ce0$feac1cac@ssprunk> Thus spake "Martin Hannigan" > At 03:38 PM 2/4/2006, you wrote: >>Sounds logical. At least one link needs to be in ARIN's region for an >>assignment to make sense; where the rest of the links go shouldn't matter. > > I always thought it was location of the entity. Signing contracts > in foreign countries is expensive vis-a-vis, for one thing. I always > felt that ARIN was serving areas, they do say region which to me implies > area, vs. circuit landings. Is there any policy for this on the IPv4 side? I didn't notice any, and I think it should be a goal to make IPv6 policy as consistent with IPv4 policy as possible, less the obvious matter of assignment sizes. >>I'd like to think tunnels wouldn't qualify as "full-time connectivity", >>but >>it's not clear. When this definition was adopted it probably wasn't >>considered that someone might get IP service via a tunnel (over what?). >>We probably need to update this if we wish to exclude tunnels, or at >>least tunnels that aren't to the same ISP that provides the physical link. > > I'd advocate that tunnels do qualify as full time connectivity if you can > go to and from the site via IPv6. The links themselves are simple > electrical interfaces that know nothing about what is riding on them. And, as pointed out earlier, this opens up the possibility that every home user that hits up a couple free tunnel brokers can get PI space. A policy with a hole like that will never pass because it will lead to a meltdown of the DFZ or wholesale filtering of PI space if there's even minor adoption. >>Interestingly, an org with two locations but no connection between >>them may qualify as multihomed, even if it only has one ISP at each >>location. Also, an org with one physical connection may qualify as >>multihomed if it has atunnel to a second ISP. Not good. > > The root server system does exactly this. We have explicit microallocation policies for folks like that. >>Note that all of these holes apply just as much to IPv4 if they also apply >>to IPv6. We either need an update to 2.7 or an official interpretation of >>"full-time connectivity", but IMHO they should no be considered potential >>flaws in this proposal specifically. > > [ SNIP ] > > You are right, but I think we should try and focus on 2005-1 for now. > That was pretty overwhelming. :-) Unfortunately, as much as I like the current proposal, I think we need one of the two actions I listed above before it has any hope of getting past the folks running the DFZ. S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin From kloch at hotnic.net Mon Feb 6 15:45:31 2006 From: kloch at hotnic.net (Kevin Loch) Date: Mon, 06 Feb 2006 15:45:31 -0500 Subject: [ppml] 2005-1 status In-Reply-To: <010001c62b58$cfca5ce0$feac1cac@ssprunk> References: <43E22A2D.3090801@hotnic.net> <47EC4C0B8D072F8B62111E1C@imac-en0.delong.sj.ca.us> <43E37113.3050905@hotnic.net> <1139073514.9125.16.camel@firenze.zurich.ibm.com> <017801c629cc$61808e40$6501a8c0@ssprunk> <7.0.1.0.0.20060204181320.01ae6918@renesys.com> <010001c62b58$cfca5ce0$feac1cac@ssprunk> Message-ID: <43E7B56B.4070701@hotnic.net> Stephen Sprunk wrote: > Thus spake "Martin Hannigan" >>I'd advocate that tunnels do qualify as full time connectivity if you can >>go to and from the site via IPv6. The links themselves are simple >>electrical interfaces that know nothing about what is riding on them. > > And, as pointed out earlier, this opens up the possibility that every home > user that hits up a couple free tunnel brokers can get PI space. A policy > with a hole like that will never pass because it will lead to a meltdown of > the DFZ or wholesale filtering of PI space if there's even minor adoption. Current IPv4 policy allows anyone to receive a /24 from an upstream provider if they are multihomed (section 4.2.3.6) *even if they only require one IP address*. I'm fairly certain this policy was crafted with the expectation of these /24's showing up in global tables. It also does not specifically rule out tunneled connections. While not stated, there may be an implicit requirement that the multihoming involve BGP. Obviously with PI assignments there is the expectation that BGP will be used. The latest proposal gives ARIN plenty of room to verify that BGP will be used and not just a tunnelbroker account. For transition purposes we should accomodate those who are multihoming today, even those multihoming without PI assignments under 4.2.3.6. - Kevin From Lee.Howard at stanleyassociates.com Mon Feb 6 17:44:43 2006 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Mon, 6 Feb 2006 17:44:43 -0500 Subject: [ppml] 2005-1 status Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40138F89C@CL-S-EX-1.stanleyassociates.com> This is edging into members' list discussion. If this becomes a thread, we should move it there. > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Michael.Dillon at btradianz.com > Sent: Monday, February 06, 2006 5:06 AM > To: ppml at arin.net > Subject: Re: [ppml] 2005-1 status > > In addition, the annual fees reflect the fact that > service providers require continuing support from > ARIN because of their assignment activity and the > inevitable requests for additional allocations. > This is not the case for end users. > > Can you justify an onging fee at all? Should whois and DNS servers be maintained, both in terms of Engineering running servers and Registration updating records? Will there be a continuing need for public policy meetings? > And can you justify more than a $100 first time > fee? We need to find out how much work is involved before we can know how much work is required, i.e., have a full set of policies. However, $100 seems awfully low. Lee > --Michael Dillon > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From owen at delong.com Tue Feb 7 05:02:08 2006 From: owen at delong.com (Owen DeLong) Date: Tue, 07 Feb 2006 02:02:08 -0800 Subject: [ppml] 2005-1 status In-Reply-To: References: Message-ID: <0518ED44C900623986D8E334@odpwrbook.hq.netli.lan> --On February 6, 2006 10:06:23 AM +0000 Michael.Dillon at btradianz.com wrote: >> Good point; that's a major oversight. Though I think the fees for doing > it >> would discourage most folks, it still needs to be fixed/clarified. > > Careful about this. It would not be wise to > draw the Department of Justice into a "restraint > of trade" investigation. Fees need to be fair and > represent the value provided. One can argue that > the value provided by ARIN to a service provider > is vastly larger than the value provided to an > end user and therefore, the end user fees should > be vastly lower than the service provider fees. > They are. The research and validation fees are the same (initial one time fee) per block size, and, that is reasonable because the fees scale with the relative amount of research and validation effort required on the part of ARIN staff. The maintenance fees, OTOH, for a subscriber are equal to the initial allocation fees. For an end-site, on the other hand, they are $100 regardless of the number of objects maintained by that ORG. As such, I think it is vastly cheaper overall for an ORG, but, the initial allocation fee does serve as a somewhat reasonable barrier to frivolous assignments. > In addition, the annual fees reflect the fact that > service providers require continuing support from > ARIN because of their assignment activity and the > inevitable requests for additional allocations. > This is not the case for end users. > Yep > Can you justify an onging fee at all? > Yes... Maintaining an object in the database has a cost. > And can you justify more than a $100 first time > fee? > No need. The barrier is the initial assignment fee. The maintenance fee can remain low. Owen > --Michael Dillon > > _______________________________________________ > 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 Tue Feb 7 05:06:11 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 7 Feb 2006 10:06:11 +0000 Subject: [ppml] 2005-1 status In-Reply-To: <00ff01c62b58$cf627350$feac1cac@ssprunk> Message-ID: > Nor are we supposed to be doing our best to waste IPv6 space by holding to > an unstated "/48 per location" policy when a typical location only needs one > or two /64s. In fact you are wrong. According to RFC 3177 http://www.rfc-editor.org/rfc/rfc3177.txt we are supposed to be giving a /48 unless we are absolutely certain that the site will never ever need more than one subnet. Therefore, if the site needs 2 subnets today, then they qualify for a /48 with no questions asked. In fact, if they might add a second subnet in the next 10 years, they also qualify for a /48 today. Here is a quote from RFC 3177: 4. Conservation of Address Space The question naturally arises whether giving a /48 to every subscriber represents a profligate waste of address space. Objective analysis shows that this is not the case. A /48 prefix under the 001 Global Unicast Address prefix contains 45 variable bits. That is, the number of available prefixes is 2 to the power 45 or about 35 trillion (35,184,372,088,832). > If an applicant came back with reasonable justification why their site (i.e. > org) needed more than a /48 total, even to the level of a /48 per location, > I'm confident ARIN would go along with it. There is nothing in the proposal > that prohibits such if it's justified. Justification means different things in the IPv4 world and the IPv6 world. We need to be careful not to confuse the two. --Michael Dillon From Michael.Dillon at btradianz.com Tue Feb 7 05:36:34 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 7 Feb 2006 10:36:34 +0000 Subject: [ppml] 2005-1 status In-Reply-To: <010001c62b58$cfca5ce0$feac1cac@ssprunk> Message-ID: > And, as pointed out earlier, this opens up the possibility that every home > user that hits up a couple free tunnel brokers can get PI space. A policy > with a hole like that will never pass because it will lead to a meltdown of > the DFZ or wholesale filtering of PI space if there's even minor adoption. It's not a hole in the policy. If the home user is actually implementing BGP multihoming, then they should qualify for a PI address block. It will most certainly not lead to meltdown of the DFZ. As you pointed out, providers use filtering to prevent such meltdown. That's just the way things are and we cannot change this. We have been asked by providers to make all these PI assignments from a single aggregate so that they can be easily identified for filtering purposes. You are correct, that this is likely to lead to WHOLESALE FILTERING in the event of a significant level of adoption. Our policy can mitigate against this possibility by selecting these PI assignments from geographical aggregates within the ARIN region. This raises the possibility that providers can selectively aggregate and filter such addresses if needed. Perhaps CAIDA's work on POP-level topology could be used by ARIN to decide how to divide up the PI assignments aggregate. In any case, the hurdle of actually implementing IPv6 multihoming, or IPv4 multihoming, puts enough of a limit on takeup of these PI blocks for the time being. --Michael Dillon From owen at delong.com Tue Feb 7 06:32:30 2006 From: owen at delong.com (Owen DeLong) Date: Tue, 07 Feb 2006 03:32:30 -0800 Subject: [ppml] 2005-1 status In-Reply-To: References: Message-ID: <31AABED13744C0C920B88AC0@odpwrbook.hq.netli.lan> --On February 7, 2006 10:06:11 AM +0000 Michael.Dillon at btradianz.com wrote: >> Nor are we supposed to be doing our best to waste IPv6 space by holding > to >> an unstated "/48 per location" policy when a typical location only needs > one >> or two /64s. > > In fact you are wrong. According to RFC 3177 > http://www.rfc-editor.org/rfc/rfc3177.txt > we are supposed to be giving a /48 unless we are absolutely > certain that the site will never ever need more than one subnet. > Therefore, if the site needs 2 subnets today, then they qualify > for a /48 with no questions asked. In fact, if they might add a > second subnet in the next 10 years, they also qualify for a > /48 today. > > Here is a quote from RFC 3177: > 4. Conservation of Address Space > > The question naturally arises whether giving a /48 to every > subscriber represents a profligate waste of address space. Objective > analysis shows that this is not the case. A /48 prefix under the 001 > Global Unicast Address prefix contains 45 variable bits. That is, > the number of available prefixes is 2 to the power 45 or about 35 > trillion (35,184,372,088,832). > It also does not define the term site, but, implies in the paragraph: 2. Background ... It is not obvious, however, that all edge networks are likely to be recursively subnetted; a single PC in a home or a telephone in a mobile cellular network, for example, may or may not interface to a subnetted local network. When a network number is delegated to a place that will not require subnetting, therefore, it might be acceptable for an ISP to give a single 64-bit prefix - perhaps shared among the dial-in connections to the same ISP router. However this decision may be taken in the knowledge that there is objectively no shortage of /48s, and the expectation that personal, home networks will become the norm. Indeed, it is widely expected that all IPv6 subscribers, whether domestic (homes), mobile (vehicles or individuals), or enterprises of any size, will eventually possess multiple always-on hosts, at least one subnet with the potential for additional subnetting, and therefore some internal routing capability. In other words the subscriber allocation unit is not always a host; it is always potentially a site. The question this memo is addressing is how much address space should be delegated to such sites. That the definition could extend to an enterprise of any size being treated as a "site". As such, I don't think you have proven your case. >> If an applicant came back with reasonable justification why their site > (i.e. >> org) needed more than a /48 total, even to the level of a /48 per > location, >> I'm confident ARIN would go along with it. There is nothing in the > proposal >> that prohibits such if it's justified. > > Justification means different things in the IPv4 world and the IPv6 world. > We need to be careful not to confuse the two. > Yes... In the IPv6 world, it means the needed number of subnets and has virtually no relationship to host needs whatsoever. I think that ARIN staff can be considered non-idiotic and would appropriately take this fact into account. 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 billd at cait.wustl.edu Tue Feb 7 08:32:32 2006 From: billd at cait.wustl.edu (Bill Darte) Date: Tue, 7 Feb 2006 07:32:32 -0600 Subject: [ppml] 2005-1 status Message-ID: RFC 3177 does not set IP address policy for ARIN region. The ARIN community of interest does, of which IETF is an interested party. Bill Darte ARIN AC > > Nor are we supposed to be doing our best to waste IPv6 space by > > holding > to > > an unstated "/48 per location" policy when a typical location only > > needs > one > > or two /64s. > > In fact you are wrong. According to RFC 3177 > http://www.rfc-editor.org/rfc/rfc3177.txt > we are supposed to be giving a /48 unless we are absolutely > certain that the site will never ever need more than one > subnet. Therefore, if the site needs 2 subnets today, then > they qualify for a /48 with no questions asked. In fact, if > they might add a second subnet in the next 10 years, they > also qualify for a /48 today. > > Here is a quote from RFC 3177: > 4. Conservation of Address Space > > The question naturally arises whether giving a /48 to every > subscriber represents a profligate waste of address space. > Objective > analysis shows that this is not the case. A /48 prefix > under the 001 > Global Unicast Address prefix contains 45 variable bits. That is, > the number of available prefixes is 2 to the power 45 or about 35 > trillion (35,184,372,088,832). > > > If an applicant came back with reasonable justification why > their site > (i.e. > > org) needed more than a /48 total, even to the level of a /48 per > location, > > I'm confident ARIN would go along with it. There is nothing in the > proposal > > that prohibits such if it's justified. > > Justification means different things in the IPv4 world and > the IPv6 world. We need to be careful not to confuse the two. > > --Michael Dillon > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From plzak at arin.net Tue Feb 7 13:39:00 2006 From: plzak at arin.net (Ray Plzak) Date: Tue, 7 Feb 2006 13:39:00 -0500 Subject: [ppml] 2005-1 status In-Reply-To: Message-ID: <20060207183902.A5E5D1FF4C@mercury.arin.net> Just to be clear, the policy statement is paragraph 6.5.4 of the NRPM, not RFC 3177. Ray > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of > Bill Darte > Sent: Tuesday, February 07, 2006 8:33 AM > To: 'Michael.Dillon at btradianz.com'; ARIN PPML > Subject: Re: [ppml] 2005-1 status > > RFC 3177 does not set IP address policy for ARIN region. The ARIN > community > of interest does, of which IETF is an interested party. > > Bill Darte > ARIN AC > > > > Nor are we supposed to be doing our best to waste IPv6 space by > > > holding > > to > > > an unstated "/48 per location" policy when a typical location only > > > needs > > one > > > or two /64s. > > > > In fact you are wrong. According to RFC 3177 > > http://www.rfc-editor.org/rfc/rfc3177.txt > > we are supposed to be giving a /48 unless we are absolutely > > certain that the site will never ever need more than one > > subnet. Therefore, if the site needs 2 subnets today, then > > they qualify for a /48 with no questions asked. In fact, if > > they might add a second subnet in the next 10 years, they > > also qualify for a /48 today. > > > > Here is a quote from RFC 3177: > > 4. Conservation of Address Space > > > > The question naturally arises whether giving a /48 to every > > subscriber represents a profligate waste of address space. > > Objective > > analysis shows that this is not the case. A /48 prefix > > under the 001 > > Global Unicast Address prefix contains 45 variable bits. That is, > > the number of available prefixes is 2 to the power 45 or about 35 > > trillion (35,184,372,088,832). > > > > > If an applicant came back with reasonable justification why > > their site > > (i.e. > > > org) needed more than a /48 total, even to the level of a /48 per > > location, > > > I'm confident ARIN would go along with it. There is nothing in the > > proposal > > > that prohibits such if it's justified. > > > > Justification means different things in the IPv4 world and > > the IPv6 world. We need to be careful not to confuse the two. > > > > --Michael Dillon > > > > _______________________________________________ > > 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 From stephen at sprunk.org Tue Feb 7 15:37:14 2006 From: stephen at sprunk.org (Stephen Sprunk) Date: Tue, 7 Feb 2006 14:37:14 -0600 Subject: [ppml] 2005-1 status References: Message-ID: <021901c62c3c$8e698de0$feac1cac@ssprunk> Thus spake >> Nor are we supposed to be doing our best to waste IPv6 space by >> holding to an unstated "/48 per location" policy when a typical >> location only needs one or two /64s. > > In fact you are wrong. According to RFC 3177 > http://www.rfc-editor.org/rfc/rfc3177.txt > we are supposed to be giving a /48 unless we are absolutely > certain that the site will never ever need more than one subnet. > Therefore, if the site needs 2 subnets today, then they qualify > for a /48 with no questions asked. In fact, if they might add a > second subnet in the next 10 years, they also qualify for a > /48 today. > > Here is a quote from RFC 3177: > 4. Conservation of Address Space > > The question naturally arises whether giving a /48 to every > subscriber represents a profligate waste of address space. Objective > analysis shows that this is not the case. A /48 prefix under the 001 > Global Unicast Address prefix contains 45 variable bits. That is, > the number of available prefixes is 2 to the power 45 or about 35 > trillion (35,184,372,088,832). 1. RFC 3177 is a suggestion by the IETF; ARIN makes the final policy. 2. Just like extant ARIN policy, RFC 3177 speaks of subscribers and not locations. It doesn't even use the misleading term "site" in that quote. Thank you for providing a citation in favor of my position :-) >> If an applicant came back with reasonable justification why their >> site (i.e. org) needed more than a /48 total, even to the level of a /48 >> per location, I'm confident ARIN would go along with it. There is >> nothing in the proposal that prohibits such if it's justified. > > Justification means different things in the IPv4 world and the IPv6 world. > We need to be careful not to confuse the two. There's no adequate definition for what it means in the IPv4 world, so how can IPv6 be all that different? We are relying on the ARIN staff to make reasonable decisions in both cases, and unless we have an outcry that this is not sufficient, let it stand. We'll never come up with enough rules to cover every possible situation, so letting well-trained humans use their best judgement is the most efficient solution. S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin From stephen at sprunk.org Tue Feb 7 15:29:08 2006 From: stephen at sprunk.org (Stephen Sprunk) Date: Tue, 7 Feb 2006 14:29:08 -0600 Subject: [ppml] 2005-1 status References: Message-ID: <021801c62c3c$8dfe9710$feac1cac@ssprunk> Thus spake >> And, as pointed out earlier, this opens up the possibility that every >> home user that hits up a couple free tunnel brokers can get PI space. >> A policy with a hole like that will never pass because it will lead to >> a meltdown of the DFZ or wholesale filtering of PI space if there's >> even minor adoption. > > It's not a hole in the policy. If the home user is actually > implementing BGP multihoming, then they should qualify for > a PI address block. That's arguable, but according to the current definitions, a site doesn't have to use BGP to be "multihomed" anyways, with either IPv4 or IPv6. All you need is "full-time connectivity" from two ISPs and have those two ISPs announce your routes. > Our policy can mitigate against this possibility by selecting > these PI assignments from geographical aggregates [...] We're all familiar with your affinity for geotop addressing, but I don't think that's sufficient mitigation for the problem at hand. > In any case, the hurdle of actually implementing IPv6 multihoming, > or IPv4 multihoming, puts enough of a limit on takeup of these > PI blocks for the time being. The "hurdle" of qualifying for multihoming currently consists of clicking your mouse a couple dozen times. That's not enough of a barrier. Paying a few hundred bucks to ARIN for a /48 does, but probably not enough to assuage ISPs' fears of a massive v6 swamp. S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin From heather.skanks at gmail.com Wed Feb 8 14:52:42 2006 From: heather.skanks at gmail.com (heather skanks) Date: Wed, 8 Feb 2006 14:52:42 -0500 Subject: [ppml] policy@arin.net broken? Message-ID: <616812070602081152u16c4cff0o26dfdf9a1af6df4f@mail.gmail.com> Hey, can someone fix this? :) The Postfix program : cannot append message to destination file /home/log/policy.log: error writing message: File too large --heather -------------- next part -------------- An HTML attachment was scrubbed... URL: From memsvcs at arin.net Wed Feb 8 16:50:28 2006 From: memsvcs at arin.net (Member Services) Date: Wed, 08 Feb 2006 16:50:28 -0500 Subject: [ppml] Issues with policy@arin.net Message-ID: <43EA67A4.7030907@arin.net> ARIN has corrected the issue with regards to submitting e-mails to policy at arin.net. We apologize for any inconvenience this may have caused the community. Nate Davis Director of Operations American Registry for Internet Numbers From narten at us.ibm.com Wed Feb 8 17:00:47 2006 From: narten at us.ibm.com (Thomas Narten) Date: Wed, 08 Feb 2006 17:00:47 -0500 Subject: [ppml] Principles for IPv6 PI allocations to end sites Message-ID: <200602082200.k18M0loh013237@cichlid.raleigh.ibm.com> Here are some thoughts I have w.r.t. this topic. Generally, I'm in favor of coming up with a policy for granting PI space to large end sites. However, I am also very concerned that we do not open the floodgates and create a situation a few years down the road that we wish we weren't in. Some principles I keep in my mind as I evaluate various proposals. IPv6 space is a public resource, and we need to avoid having a policy adopted today turn into an "early adopter bonus program". That is, if 5-10 years from now we have two classes of entities: - early adopters with PI assignments, and - those who wish they had a PI assignment, and believe they have just as much right to one as those that have them, but can't get them because the policy had to be changed and PI space has become much harder to get then I think we've done the community a huge disservice. Corallary: I don't buy the argument that "we can always change the policy later, if it proves to be problematic". The reality is that doing so will lead to the previous situation, and that makes it rather hard to change the policy. We won't be able to get consensus to do so. Thus, I think we need to be conservative now, at least at the outset. We can always loosen the policy later if that proves appropriate. Multihoming: we don't have a "magic bullet" multihoming solution on the table today, and I'm not willing to count on some solution appearing that bales us out of a mess we create under the assumption that one will come along. Thus, any policy we adopt to facilitiate multihoming needs to have sufficient incentives/checks to prevent the size of the table from exploding, not just this year or next, but in 5-10 years and beyond. And who wants multihoming? My guess is that as time goes on, many if not most businesses will. Thus, we are potentially talking 100K to millions of distinct PI assignments. I do not believe we can give _all_ of them PI space (due to scaling concerns). Thus, I worry that just saying "need to multihome" is insufficient justification. We can't afford to go there long term. I've come to believe that (at some level) we should let pretty much all of the "big sites" with PI space in v4 get it in v6. I don't think we should _require_ having v4 space as a prerequisite, but it's a reasonable assumption that those those that operate big sites today, and that multihome, will (eventually) do the same in IPv6, and therefore we should let them. Another way of looking at it: - giving space to those (IPv4 users) that don't plan on deploying IPv6 in the short term doesn't matter if v6 doesn't take off. - But if IPv6 does take off, those that are slow to deploy, will still eventually deploy (and we don't want to make IPv6 PI assignments just for early adopters). So it is fairly safe to give prefixes to existing large IPv4 users One question that arises is fairness. Since we can't give PI space to all end sites, who can we say yes to, and who will we have to say no to? And will we be able to defend the policies we come up with 5-10 years down the road? (I sure hope so...) One possible metric for fairness is that since PI allocations each have a cost associated with them (in terms of route slots in the DFZ), we should attempt to maximimize the benefit of each such slot. Thus, one reason I favor PI space for "large end sites" is that large can be an indication of the numbers of networks/devices/users covered by a prefix. The more users/machines/networks covered by a prefix, the greater the "benefit" to the community in terms of carrying that prefix in the DFZ. Hence, I tend to lean towards giving PI space only to the largest end sites, i.e., those that will provide benefit to the largest communities. There may be other metrics that we should consider; in any case, I do think its useful to think about what metric we are actually using, and what community is going to benefit from a PI assignments, since there will certainly be other communities that might also benefit, but to whom we will be forced to say no to. I believe we need to allocate PI space out of specific prefix, so that it is clearly identifiable in case filters are needed. Hopefully, we will never have to impose filters, but it is better to have the capability to impose filters based on explicit knowledge (e.g., by knowing that anything within a specific prefix is PI to end sites) than having to approximate by just assuming that all prefixes of some fixed length are PI. Given that one of the goals of IPv6 address allocation is to minimize fragmentation of address blocks, we should try hard to ensure that if an end site ever gets a PI block, it will never need (or get) a second one from a separate block. That is, I think we should (just like with LIR assigments) have the RIRs use sparse allocation (or equivalent) to allow future expansion. IPv6 has sufficient address space to do this. Fixing the assignment at a fixed value (and stating up front that no larger prefix will ever be given) is just asking for trouble (i.e. runs risk of future fragementation) Thomas From narten at us.ibm.com Wed Feb 8 17:09:21 2006 From: narten at us.ibm.com (Thomas Narten) Date: Wed, 08 Feb 2006 17:09:21 -0500 Subject: [ppml] Comments on revised 2005-1 proposal of 2006-02-03 In-Reply-To: Message from Kevin Loch of "Fri, 03 Feb 2006 10:04:51 EST." <43E37113.3050905@hotnic.net> Message-ID: <200602082209.k18M9L9t013516@cichlid.raleigh.ibm.com> > Marshall Eubanks wrote: > > Can you prepare a revised version? There has been so much > > back and forth (some fairly tangential) that I am no longer > > sure exactly what the new proposal will say. > Add new subsection in section 6.5 of the NRPM: > 6.5.8. Direct assignments to large/complex end sites I agree with others about the "complex" wording not being helpful. IMO, we are fine just changing this to: 6.5.8. Direct assignments to large end sites > 6.5.8.1. To qualify for a direct assignment, an > organization must: > a) not be an IPv6 LIR; and > b) meet at least ONE of the following requirements: > 1) Have an IPv4 assignment or allocation directly from an RIR, > the IANA or legacy registry; or I have a hard time supporting giving owners of "legacy" IPv4 registrations automatic IPv6 space. This just perpetuates the "early adopter" program (e.g., those that got big assignments prior to the the RIRs, get similar treatment in IPv6). Also, IMO, it's not enough to have "an IPv4 assignment or allocation directly from an RIR"; there are different types of assignments/allocations. We should restrict giving out IPv6 PI space that satisfy specific criteria. Indeed, I'm not sure why 1) is even needed. I think item 2) (that follows) is a better justification and can subsume 1). > 2) Qualify for an IPv4 assignment or allocation from ARIN under > the IPv4 policy currently in effect; or With some caveats, since not all allocations are the same (e.g., getting space for anycast, etc.) > 3) Be currently multihomed using IPv6 connectivity to two > or more separate ARIN LIR's using at least one /48 assigned > to them by each LIR. IMO, being multihomed in IPv4 should also be sufficient justification. One argument I keep hearing is that "we're assigning PI space in IPv4 for multihoming, and the system is working". So let's try and leverage that experience. > 6.5.8.2. Direct assignment size to large/multihomed end sites > Organizations that meet the direct end site assignment criteria > are eligible to receive a direct assignment. The minimum size > of the assignment is /48. Organizations requesting a larger > assignment or a second (or more) assignment must provide > documentation justifying the need for additional subnets. I suspect that /48 is too small, if we are aiming at the biggest end sites. E.g., take sites that have O(100K) subnets. According the HD ratio thresholds, that would correspond to (I think) a /44. One thing that I would find helpful is if there is any data available concerning sizes of organizations (in terms of networks/devices/users). How many organizations have 100K subnets? Is that number small enough that we can use it as a threshhold to give everyone with 100K subnets a PI assignment? Although the following is far from perfect, using number of employees might be attractive in that it is information that is often publically available, and gives a very rough indication of number of machines (assume some multiple of machines/subnets per employee). But I recall from previous discussions, people preferred more relevant criteria like numbers of subnets. > 6.5.8.3. Subsequent Assignment Size > Additional assignments may be made when the need for additional > subnets is justified. When possible assignments will be made > from an adjacent address block. Perhaps specifically tie this back to the the HD ratio. So, here is a revised strawman based on the comments above: Add new subsection in section 6.5 of the NRPM: 6.5.8. Direct assignments to large end sites 6.5.8.1. To qualify for a direct assignment, an organization must: a) not be an IPv6 LIR; b) meet all of the following requirements: 1) Qualify for an IPv4 direct assignment from ARIN under the IPv4 policy currently in effect [specifically, Section 4.3, excluding microassignments. Note also that this means end site must qualify for a /22 if multihoming. Is this bar high enough?]. 2) Be currently multihomed using IPv4 or IPv6 as defined in "ARIN Number Resource Policy Manual Version 2005.1 - September 7, 2005" [note: text referred to is: 2.7. Multihomed An organization is multihomed if it receives full-time connectivity from more than one ISP and has one or more routing prefixes announced by at least two of its upstream ISPs. ] 6.5.8.2. Direct assignment size to large end sites Organizations that meet the direct end site assignment criteria given in Section 6.5.8.1 are eligible to receive a direct assignment. The minimum size of the assignment is a /40. Larger assignments will be made when justified using the existing IPv6 applied HD ratio as given in Section 6.5. Assignments will be made out of a specially designated address block that indicates a direct assignment to an endsite. 6.5.8.3. Subsequent Assignment Size An organization may receive an additional assignment when it has grown to include enough distinct physical locations to justify the larger assignment. Where possible, the assignment will be made from an adjacent address block. ================================================================ So, what do people think of the above? An improvement? Still some unacceptable points? Questions relating to above: 1) How many direct /22 IPv4 assignments have been made to date? That is, how many organizations do we think would qualify? Are we talking a few thousand? tens of thousands? or? Thomas From memsvcs at arin.net Wed Feb 8 18:14:26 2006 From: memsvcs at arin.net (Member Services) Date: Wed, 08 Feb 2006 18:14:26 -0500 Subject: [ppml] ARIN XVII Meeting Registration is Now Open Message-ID: <43EA7B52.1040509@arin.net> Bonjour, Mesdames et Messieurs! ARIN is pleased to invite you to attend the ARIN XVII Public Policy and Members Meeting this April in Montreal, Canada. The meeting will be held at the Hilton Montreal Bonaventure. ARIN's meetings are a great chance for the entire community to benefit from the technical and operational expertise of their colleagues, keep up on all the latest technical issues facing the network operator community, and contribute to Internet number resource policy discussions and development. In addition to the Public Policy and Members Meeting, there will be a number of informative events, including the "Getting Started with IPv6 Workshop" on Sunday April 9. ARIN is excited to once again offer this workshop for those that were unable to attend when it was originally held at ARIN XVI in Los Angeles. Sunday will also feature tutorials, a First Timers Luncheon, the Open Policy Hour, and the 7th Annual ARIN Foosball Tournament. On Monday, after the Public Policy Meeting, we will also be hosting another exciting social event. Meeting Registration and Hotel Information: You will find links to register for the meeting and additional information by visiting the ARIN XVII home page, available at: http://www.arin.net/ARIN-XVII/ Register before March 27, 2006, and pay the discounted early registration fee. ARIN Members in Good Standing are allowed two (2) free meeting registrations per Org ID. For those unable to attend ARIN XVII in person, remote participant registration is also now open. Additional information is available on the page linked to above. Information about the hotel, travel, and how to make a room reservation is available at: http://www.arin.net/ARIN-XVII/hotel.html As rooms are limited, make sure to reserve your hotel room now. Reservations must be made online by March 25, 2006. After the cut-off date, room reservations will be accepted according to availability. ARIN XVI Overview * Sunday, April 9 - "Getting Started with IPv6" Workshop, Tutorials, Open Policy Hour, and Foosball Tournament * Monday, April 10 - Public Policy, Day 1 and ARIN Social * Tuesday, April 11 - Public Policy, Day 2 * Wednesday, April 12 - Members Meeting (open to all attendees) Additional agenda details and more information about ARIN XVII will be posted to our website as we get closer to the meeting, so check back often! Regards, Member Services Department American Registry for Internet Numbers From dgolding at burtongroup.com Wed Feb 8 20:28:06 2006 From: dgolding at burtongroup.com (Daniel Golding) Date: Wed, 08 Feb 2006 20:28:06 -0500 Subject: [ppml] Principles for IPv6 PI allocations to end sites In-Reply-To: <200602082200.k18M0loh013237@cichlid.raleigh.ibm.com> Message-ID: On 2/8/06 5:00 PM, "Thomas Narten" wrote: > > One possible metric for fairness is that since PI allocations each > have a cost associated with them (in terms of route slots in the DFZ), > we should attempt to maximimize the benefit of each such slot. Thus, > one reason I favor PI space for "large end sites" is that large can be > an indication of the numbers of networks/devices/users covered by a > prefix. The more users/machines/networks covered by a prefix, the > greater the "benefit" to the community in terms of carrying that > prefix in the DFZ. Hence, I tend to lean towards giving PI space only > to the largest end sites, i.e., those that will provide benefit to the > largest communities. > > [snip] This is a common trap. The assumption that more IP addresses means a need for PI space is shaky. Many large enterprises have tens of thousands of users behind a few NAT gateways - that won't change in v6. Also, many content providers may only need a few visible IP addresses, but may generate massive amount of traffic. The numbers game is easy to fall into. Its important not to fall into this sort of thinking. Becoming multihomed costs money. That's a barrier. Paying for IP address space and an AS are also barriers. Value on the Internet is largely tied to economics. If we need higher barriers to PI address space, they should be economic, rather than any sort of arbitrary value judgments by "wise men". > > Thomas > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml -- Daniel Golding From owen at delong.com Wed Feb 8 23:21:31 2006 From: owen at delong.com (Owen DeLong) Date: Wed, 08 Feb 2006 20:21:31 -0800 Subject: [ppml] Principles for IPv6 PI allocations to end sites In-Reply-To: References: Message-ID: The difficulty with the barriers should be economic argument is that ARIN fees are set by ARIN membership and BOD and are not even subject of discussion in the public policy process. As such, we cannot implement policy through economics at the ARIN level. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From Ed.Lewis at neustar.biz Wed Feb 8 23:42:43 2006 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Wed, 8 Feb 2006 23:42:43 -0500 Subject: [ppml] Principles for IPv6 PI allocations to end sites In-Reply-To: <200602082200.k18M0loh013237@cichlid.raleigh.ibm.com> References: <200602082200.k18M0loh013237@cichlid.raleigh.ibm.com> Message-ID: I haven't been able to read the 2005-1 thread, so this message is quite welcome. At 17:00 -0500 2/8/06, Thomas Narten wrote: >Here are some thoughts I have w.r.t. this topic. Generally, I'm in >favor of coming up with a policy for granting PI space to large end >sites. However, I am also very concerned that we do not open the >floodgates and create a situation a few years down the road that we >wish we weren't in. > >Some principles I keep in my mind as I evaluate various proposals. > >IPv6 space is a public resource, and we need to avoid having a policy >adopted today turn into an "early adopter bonus program". That is, if >5-10 years from now we have two classes of entities: Are we truly concerned about "early adopters" when we have a hard time getting IPv6 rolling at all? (That's my snicker-eliciting comment.) "Early adoption" is already past tense in (at least) the APNIC region. I understand the point here, perhaps the label "early adopter" is a misnomer though. >Corallary: I don't buy the argument that "we can always change the >policy later, I have to disagree with this. Coming up with a perfect policy is difficult. We can have a "perfect" design of a technical system, but in a subjective environment such as address allocation policy I think we ought to strive for a perfect policy but realize that it's a dream. >Multihoming: we don't have a "magic bullet" multihoming solution on ... >One question that arises is fairness. Since we can't give PI space to ... >prefix in the DFZ. Hence, I tend to lean towards giving PI space only >to the largest end sites, i.e., those that will provide benefit to the >largest communities. I think the above is the crux of the problem. I'll agree that we ought to forget about a technical solution to multihoming coming any time soon (snicker - one more broken promise by IPv6). Fairness is what this is all about - but I don't think the size of the benefiting community is the metric. (For example, if a site is in the US but plans to market to China and will have it's web site in the Chinese language, does that mean it caters to the "largest" community.) >There may be other metrics that we should consider; in any case, I do I would think that the metric ought to be tied to the level of pain of reacting to an event that would have driven a would-be PI user to PI. I.e., if the reason to want PI space to be to avoid having to renumber out of a failed ISP's address range into another, then priority ought to go to PI-wannabes with the largest address need. (Or that have the largest number of firewalls which need to have addresses configured, etc.) >I believe we need to allocate PI space out of specific prefix, so that How would this differ from todays (IPv4's) swamp space? I suppose that it would only be within one RIR (but across LIRs to manage), but it would be as painful to routing as the IPv4 swamp. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... From tvest at pch.net Thu Feb 9 00:21:49 2006 From: tvest at pch.net (Tom Vest) Date: Thu, 9 Feb 2006 00:21:49 -0500 Subject: [ppml] Principles for IPv6 PI allocations to end sites In-Reply-To: References: Message-ID: <7F738FCC-06C5-496E-BAC4-525E7A4F33EF@pch.net> On Feb 8, 2006, at 8:28 PM, Daniel Golding wrote: > > > On 2/8/06 5:00 PM, "Thomas Narten" wrote: >> >> One possible metric for fairness is that since PI allocations each >> have a cost associated with them (in terms of route slots in the >> DFZ), >> we should attempt to maximimize the benefit of each such slot. Thus, >> one reason I favor PI space for "large end sites" is that large >> can be >> an indication of the numbers of networks/devices/users covered by a >> prefix. The more users/machines/networks covered by a prefix, the >> greater the "benefit" to the community in terms of carrying that >> prefix in the DFZ. Hence, I tend to lean towards giving PI space only >> to the largest end sites, i.e., those that will provide benefit to >> the >> largest communities. >> >> > > [snip] > > This is a common trap. The assumption that more IP addresses means > a need > for PI space is shaky. Many large enterprises have tens of > thousands of > users behind a few NAT gateways - that won't change in v6. Also, many > content providers may only need a few visible IP addresses, but may > generate > massive amount of traffic. The numbers game is easy to fall into. Hi Dan, No doubt you are correct, many enterprises have lots of unobservable applications and users, and many of them generate lots of traffic. The publicly visible IP don't reflect these unobservables accurately. But can't you say the same thing about traffic? Is it any safer to assume that traffic provides any more accurate a metric of value, or even costs, than public Internet production? Given the everyday management of traffic volumes/directions to serve business needs, I would think that the numbers game would be even more dubious with respect to traffic. > Its important not to fall into this sort of thinking. Becoming > multihomed > costs money. That's a barrier. Paying for IP address space and an > AS are > also barriers. Value on the Internet is largely tied to economics. > If we > need higher barriers to PI address space, they should be economic, > rather > than any sort of arbitrary value judgments by "wise men". I agree with you that ARIN should care about economics, and that allocations should reflect some economic realities. But given this, I still think that publicly verifiable activities should be given greater weight. If IP address will still be objects of public trust in the future (not universally accepted I think), then ARIN will continue to have an obligation to assure that their use adds value, for some meaning of "assure". If we are apprehensive about public policies and "wise men," why should we have any confidence at all in private policies and the unverifiable claims of "self-interested men"? I also agree that the idea of value attaches more easily to running an AS, which bundles lots of value-suggestive things together in one package. I guess the market has already internalized this view anyway (cf. the new MCI-VZ peering requirements). However, this conclusion just shifts the burden of ARIN's stewardship responsibilities from IP addresses to ASNs. Should requirements for AS allocations be more robust, or evaluations more rigorous? Regardless, how does this shift in attention help to solve the problem of *PI* space? Tom >> Thomas >> _______________________________________________ >> PPML mailing list >> PPML at arin.net >> http://lists.arin.net/mailman/listinfo/ppml > > -- > Daniel Golding > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From iggy at merit.edu Thu Feb 9 08:28:30 2006 From: iggy at merit.edu (Glenn Wiltse) Date: Thu, 9 Feb 2006 08:28:30 -0500 (EST) Subject: [ppml] Comments on revised 2005-1 proposal of 2006-02-03 In-Reply-To: <200602082209.k18M9L9t013516@cichlid.raleigh.ibm.com> References: <200602082209.k18M9L9t013516@cichlid.raleigh.ibm.com> Message-ID: In general, I like the direction Thomas is heading in... (giving PI to the largest sites and trying not to give out small blocks simply because someone says they need multi homing, etc...) I would change refferances to 'end site', in favor of the term 'end orginization' (which would imply these cant' be re-assigned to other orginizations, but little else implyed in the meaning) In my mind, the only real sticky point is in deciding what exactly defines a originization as being 'large' enough to get a PI assignment. I do think that a /40 is about the smallest sized block that I would like to see given out as IPv6 PI space at this time. Just how you define who is large enough to justify such a assignment I do not know. I personaly would rather see unique street addresses be considered as justification for space, more so then number of employees... but perhaps either or... or some combination of both, etc... Anyway, I do really think Thomas is on the right track with his most recent comments and/or proposal. Glenn Wiltse On Wed, 8 Feb 2006, Thomas Narten wrote: >> Marshall Eubanks wrote: > >>> Can you prepare a revised version? There has been so much >>> back and forth (some fairly tangential) that I am no longer >>> sure exactly what the new proposal will say. > >> Add new subsection in section 6.5 of the NRPM: > >> 6.5.8. Direct assignments to large/complex end sites > > I agree with others about the "complex" wording not being > helpful. IMO, we are fine just changing this to: > > 6.5.8. Direct assignments to large end sites > >> 6.5.8.1. To qualify for a direct assignment, an >> organization must: > >> a) not be an IPv6 LIR; and >> b) meet at least ONE of the following requirements: > >> 1) Have an IPv4 assignment or allocation directly from an RIR, >> the IANA or legacy registry; or > > I have a hard time supporting giving owners of "legacy" IPv4 > registrations automatic IPv6 space. This just perpetuates the "early > adopter" program (e.g., those that got big assignments prior to the > the RIRs, get similar treatment in IPv6). > > Also, IMO, it's not enough to have "an IPv4 assignment or allocation > directly from an RIR"; there are different types of > assignments/allocations. We should restrict giving out IPv6 PI space > that satisfy specific criteria. > > Indeed, I'm not sure why 1) is even needed. I think item 2) (that > follows) is a better justification and can subsume 1). > >> 2) Qualify for an IPv4 assignment or allocation from ARIN under >> the IPv4 policy currently in effect; or > > With some caveats, since not all allocations are the same (e.g., > getting space for anycast, etc.) > >> 3) Be currently multihomed using IPv6 connectivity to two >> or more separate ARIN LIR's using at least one /48 assigned >> to them by each LIR. > > IMO, being multihomed in IPv4 should also be sufficient justification. > One argument I keep hearing is that "we're assigning PI space in IPv4 > for multihoming, and the system is working". So let's try and leverage > that experience. > >> 6.5.8.2. Direct assignment size to large/multihomed end sites > >> Organizations that meet the direct end site assignment criteria >> are eligible to receive a direct assignment. The minimum size >> of the assignment is /48. Organizations requesting a larger >> assignment or a second (or more) assignment must provide >> documentation justifying the need for additional subnets. > > I suspect that /48 is too small, if we are aiming at the biggest end > sites. E.g., take sites that have O(100K) subnets. According the HD > ratio thresholds, that would correspond to (I think) a /44. > > One thing that I would find helpful is if there is any data available > concerning sizes of organizations (in terms of > networks/devices/users). How many organizations have 100K subnets? Is > that number small enough that we can use it as a threshhold to give > everyone with 100K subnets a PI assignment? > > Although the following is far from perfect, using number of employees > might be attractive in that it is information that is often publically > available, and gives a very rough indication of number of machines > (assume some multiple of machines/subnets per employee). But I recall > from previous discussions, people preferred more relevant criteria > like numbers of subnets. > >> 6.5.8.3. Subsequent Assignment Size > >> Additional assignments may be made when the need for additional >> subnets is justified. When possible assignments will be made >> from an adjacent address block. > > Perhaps specifically tie this back to the the HD ratio. > > So, here is a revised strawman based on the comments above: > > Add new subsection in section 6.5 of the NRPM: > > 6.5.8. Direct assignments to large end sites > > 6.5.8.1. To qualify for a direct assignment, an organization > must: > > a) not be an IPv6 LIR; > > b) meet all of the following requirements: > > 1) Qualify for an IPv4 direct assignment from ARIN under the > IPv4 policy currently in effect [specifically, Section > 4.3, excluding microassignments. Note also that this means > end site must qualify for a /22 if multihoming. Is this > bar high enough?]. > > 2) Be currently multihomed using IPv4 or IPv6 as defined in > "ARIN Number Resource Policy Manual Version 2005.1 - > September 7, 2005" > > > [note: text referred to is: > > 2.7. Multihomed > > An organization is multihomed if it receives full-time > connectivity from more than one ISP and has one or more > routing prefixes announced by at least two of its upstream > ISPs. ] > > 6.5.8.2. Direct assignment size to large end sites > > Organizations that meet the direct end site assignment > criteria given in Section 6.5.8.1 are eligible to receive a > direct assignment. The minimum size of the assignment is a > /40. Larger assignments will be made when justified using the > existing IPv6 applied HD ratio as given in Section 6.5. > > Assignments will be made out of a specially designated > address block that indicates a direct assignment to an > endsite. > > 6.5.8.3. Subsequent Assignment Size > > An organization may receive an additional assignment when it > has grown to include enough distinct physical locations to > justify the larger assignment. Where possible, the assignment > will be made from an adjacent address block. > > ================================================================ > > So, what do people think of the above? An improvement? Still some > unacceptable points? > > Questions relating to above: > > 1) How many direct /22 IPv4 assignments have been made to date? That > is, how many organizations do we think would qualify? Are we > talking a few thousand? tens of thousands? or? > > Thomas > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > > !DSPAM:43ea6c25173031292612334! > > From dgolding at burtongroup.com Thu Feb 9 09:00:17 2006 From: dgolding at burtongroup.com (Daniel Golding) Date: Thu, 09 Feb 2006 09:00:17 -0500 Subject: [ppml] Comments on revised 2005-1 proposal of 2006-02-03 In-Reply-To: Message-ID: On 2/9/06 8:28 AM, "Glenn Wiltse" wrote: > In general, I like the direction Thomas is heading in... (giving > PI to the largest sites and trying not to give out small blocks simply > because someone says they need multi homing, etc...) > > I would change refferances to 'end site', in favor of the term 'end > orginization' (which would imply these cant' be re-assigned to other > orginizations, but little else implyed in the meaning) > > In my mind, the only real sticky point is in deciding what exactly > defines a originization as being 'large' enough to get a PI assignment. > > I do think that a /40 is about the smallest sized block that I would like > to see given out as IPv6 PI space at this time. Just how you define who is > large enough to justify such a assignment I do not know. > > I personaly would rather see unique street addresses be considered > as justification for space, more so then number of employees... but > perhaps either or... or some combination of both, etc... > > Anyway, I do really think Thomas is on the right track with his > most recent comments and/or proposal. > > Glenn Wiltse This is a dead end. The last 2005-1 was defeated at the last ARIN meeting specifically because of the 100k host requirement. - Daniel Golding From Michael.Dillon at btradianz.com Thu Feb 9 09:25:43 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Thu, 9 Feb 2006 14:25:43 +0000 Subject: [ppml] Comments on revised 2005-1 proposal of 2006-02-03 In-Reply-To: Message-ID: > > I do think that a /40 is about the smallest sized block that I would like > > to see given out as IPv6 PI space at this time. Just how you define who is > > large enough to justify such a assignment I do not know. > > > > I personaly would rather see unique street addresses be considered > > as justification for space, more so then number of employees... but > > perhaps either or... or some combination of both, etc... > This is a dead end. The last 2005-1 was defeated at the last ARIN meeting > specifically because of the 100k host requirement. I beg to differ with you. Glenn is trying to define how to justify a specific size of IPv6 address block. This is something that we have not had to define before since the IPv6 rules that we now have, only cover allocations to providers who then make assignments to their subscribers. In this case, 2005-1, we have to define rules that ARIN would use to determine the size of a block to be assigned to a subscriber who comes directly to ARIN rather than going to an upstream network operator. We are already in broad agreement that it is justified to make such an application to ARIN when there is no single upstream provider to provide a single assignment. Now, how do we measure justification for IPv6. As Glenn has pointed out, it is more consistent with IPv6 addressing design and existing policy, if we count the number of physical locations. He suggests street addresses. Others might suggest that we count the number of buildings. In either case, the ARIN analysts could request backup information to confirm these numbers. When you say that the last meeting defeated the proposal due to the 100k host requirement, you seem to ignore the fact that Glenn has moved the discussion away from host counting and into location counting, with presumably, one /48 being assigned per location. In any case, if we need to justify the magnitude of the address block assigned, then we need to measure something or other in the applicant's situation. So the question is, what do we measure? And what is the threshold at which an end user orgnization qualifies? If anything is a dead end at this point, it appears to be the concept that measurement is unnecessary and a PI block is justified by the mere fact of multihoming. Everybody seems to want some measurement, some threshold. --Michael Dillon From iggy at merit.edu Thu Feb 9 09:33:44 2006 From: iggy at merit.edu (Glenn Wiltse) Date: Thu, 9 Feb 2006 09:33:44 -0500 (EST) Subject: [ppml] Comments on revised 2005-1 proposal of 2006-02-03 In-Reply-To: References: Message-ID: I wasn't nessasarly endorsing any 'host count' as being the defining factor. However I do think the main point of contention is how exactly to determin some size threshold nessasary, and what to use as a unit of meassure. That's why I personaly like the idea of using unique street addresss. One thing I don't like, and I think many others don't like, is the idea that ARIN would hand out many /48s simply because some orginzations felt they had to have PI space and/or they are currently multi homed. Maybe later, after some of the biggest end originzations have gotten PI space, and we know where we stand in terms of demand and/or needs, we could possibly later relax the size limits and/or then start to give out smaller block, etc... Glenn Wiltse On Thu, 9 Feb 2006, Dan Golding wrote: > On 2/9/06 8:28 AM, "Glenn Wiltse" wrote: > >> In general, I like the direction Thomas is heading in... (giving >> PI to the largest sites and trying not to give out small blocks simply >> because someone says they need multi homing, etc...) >> >> I would change refferances to 'end site', in favor of the term 'end >> orginization' (which would imply these cant' be re-assigned to other >> orginizations, but little else implyed in the meaning) >> >> In my mind, the only real sticky point is in deciding what exactly >> defines a originization as being 'large' enough to get a PI assignment. >> >> I do think that a /40 is about the smallest sized block that I would like >> to see given out as IPv6 PI space at this time. Just how you define who is >> large enough to justify such a assignment I do not know. >> >> I personaly would rather see unique street addresses be considered >> as justification for space, more so then number of employees... but >> perhaps either or... or some combination of both, etc... >> >> Anyway, I do really think Thomas is on the right track with his >> most recent comments and/or proposal. >> >> Glenn Wiltse > > This is a dead end. The last 2005-1 was defeated at the last ARIN meeting > specifically because of the 100k host requirement. > > - Daniel Golding > > > > > !DSPAM:43eb4f0186132993215505! > > From memsvcs at arin.net Thu Feb 9 10:16:42 2006 From: memsvcs at arin.net (Member Services) Date: Thu, 09 Feb 2006 10:16:42 -0500 Subject: [ppml] Proposed Policy: MicroAllocations for Internal Infrastructure Message-ID: <43EB5CDA.9060705@arin.net> ARIN received the following proposed policy. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List and being placed on ARIN's website. The ARIN Advisory Council (AC) will review the proposal and within ten working days may decide to: 1) Support the proposal as is, 2) Work with the author to clarify, divide or combine one or more policy proposals, or 3) Not support the policy proposal. If the AC supports the proposal or reaches an agreement to work with the author, then the proposal will be posted as a formal policy proposal to the Public Policy Mailing List and it will be presented at the Public Policy Meeting. If the AC does not support the proposal, then the author may elect to use the petition process to advance the proposal. If the author elects not to petition or the petition fails, then the proposed policy 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: MicroAllocations for Internal Infrastructure Author: Jason Schiller, Chris Morrow, Heather Skanks, Greg Stilwell, Beth Vu Proposal type: modify Policy term: permanent Policy statement: To replace section 6.10 6.10 Micro-allocation ARIN will make micro-allocations for critical infrastructure, and the RIRs and IANA as defined in the sub-sections below. These allocations will be no longer (more specific) than a IPv6 /48. Multiple allocations may be granted in certain situations. Micro-allocations MUST be provided from a specific range of addresses. ARIN will make a list of these blocks publicly available. ISPs and other organizations receiving these micro-allocations will be charged under the ISP fee schedule, while end-users will be charged under the fee schedule for end-users. This policy does not preclude organizations from requesting address space under other policies. 6.10.1 Micro-allocation for public exchange points Public Internet exchange point operators must provide justification for the micro-allocation, including: connection policy, location, other participants (minimum of two total), ASN, and contact information. Exchange point allocations MUST be allocated from specific blocks reserved only for this purpose. 6.10.2 Micro-allocation for core DNS service providers Core DNS service providers (e.g. ICANN-sanctioned root, gTLD, and ccTLD operators) must provide justification for the micro-allocation, including: name of core DNS server, location, ASN, and contact information. Core DNS server allocations MUST be allocated from the micro-allocation block. This block must be separate from the exchange point micro-allocation block and the internal infrastructure micro-allocation block. 6.10.3 Micro-allocation for internal infrastructure Organizations that currently hold IPv6 allocations may apply for a micro-allocation for internal infrastructure. Applicant must provide justification indicating why a separate non-routed block is required. Justification must include why a sub-allocation of currently held IP space cannot be utilized. Internal infrastructure allocations MUST NOT be routed on global Internet. Internal infrastructure allocations MUST be allocated from specific blocks reserved only for this purpose. Rationale: Organizations that have only a single aggregate may require additional noncontiguous IP space for their internal infrastructure. This space should not be routed in the global Internet routing table. This will provide for the protection of internal infrastructure and support for applications that are sensitive to long convergence times like VoIP. It is important to note that the additional prefix allocation will not negatively impact the global routing table size as the additional prefix should not be routed. BGP Re-Convergence ------------------ ISPs use BGP to originate their aggregate from multiple nodes within their infrastructure. They do this by routing their aggregate to discard on multiple devices. This ensures the Internet can reach the aggregate even when one or more nodes fail. If the next hop for a route is reachable via an aggregate that is in the routing table, then failures affecting the reachability of the next hop are subject to BGP hold timers, which can cause traffic to be dropped for the length of the bgp hold time (typically 3 minutes) The BGP re-convergence problem results when a multi-homed customer is announcing the same route to two different edge routers. When the edge router sourcing the primary path fails, the local address which is acting as the next hop, is removed from the IGP. If the next hop is still reachable through an aggregate or covering route, then the route will not be immediately invalidated in bgp. Until the bgp session with the failed device times out, traffic will be drawn to the device originating the aggregate, which is routed to discard and traffic will be dropped. After the bgp session with the failed device times out, the route will be removed and the next best route will be used. To minimize route failover time, you must ensure that the local addresses of the infrastructure, that act as next-hops for Internet routes, are NOT numbered with addresses that are a more specific than the aggregate. A detailed description of the problem space follows in the next three paragraphs. Having BGP next-hops that are not aggregated can cause faster convergence for customers who have multiple links to multiple routers of a single upstream AS. Take the case where a customer has two connections, link1 to edge-router1 and link2 to edge-router2, to a single upstream AS. The customer has an eBGP session with the loopback 2001:DB8::1/128 on edge-router1 and with loopback 2001:DB8::2/128 on edge-router2. The customer advertises a single prefix 2001:DB8:1000::/48 to both edge-router1 and edge-router2. The edge routers set next-hop self. The upstream ISP will have two paths to the prefix 2001:DB8:1000::/48, one with a protocol next-hop of 2001:DB8::1 and one with a protocol next-hop of 2001:DB8::2. Assume the upstream ISP's entire network prefers the path to 2001:DB8:1000::/48 with a protocol next-hop of 2001:DB8::1 due to lower BGP MED value. Also assume that all of the address space owned by the upstream ISP is 2001:DB8::/32, and the loopbacks of both edge routers are a more specific of the aggregate /32. The upstream ISP has a pull-up route for 2001:DB8::/32 in the core of the network. This allows for the aggregation of all the more specific routes of 2001:DB8::/32. It insures the stability of the 2001:DB8::/32 announcement, while preventing an isolated edge router from advertising reachability to the network. If edge-router1 fails then 2001:DB8::1/128 will be immediately removed from the IGP. The preferred prefix for 2001:DB8:1000::/48 with a next-hop of 2001:DB8::1 will remain a valid bgp route and will continue to be the best path because 2001:DB8::1 is reachable through the pull-up route 2001:DB8::/32. Traffic will get blackholed for up to three minutes (BGP default hold time) until the BGP prefix 2001:DB8:1000::/48 with a protocol next-hop of 2001:DB8::1 times out. Only then will traffic get forwarded to the next best path for 2001:DB8:1000::/48 with a protocol next-hop of 2001:DB8::2. If instead the loopbacks of the edge routers (or any BGP protocol next-hop addresses) are not part of the 2001:DB8::/32 aggregate, and there is no aggregate that covers the edge router loopbacks, then convergence will be much quicker. Assume that edge-router1 is using 2001:408::1 and edge-router2 is using 2001:408::2, and the only pull-up route is 2001:DB8::/32. In this case once edge-router1 fails, the IGP will detect it and remove 2001:408::1/128 from the IGP. This will invalidate the preferred path to 201:DB8:1000::/48 with a protocol next-hop of 2001:408:1 as there will be no route to the next hop (or even a less specific of this address). Once the path is invalidated, then the next best path to 2001:DB8:1000::/48 with a protocol next-hop of 2001:408::2 will be declared best. Convergence times will be on the order of magnitude of the IGP failure detection and path re-calculation, typically less than one second. --------------- | Core Router |static route | |2001:DB8::/32 discard ----+------+--- | | / \ /-------------/ \--------\ / \ / /----------------------------\ \ | | | | ------+---+-- --+---+------ |Core Router|static route |Core Router|static route | |2001:DB8::/32 discard | |2001:DB8::/32 discard ---------+--- ---------+--- | | ---------+--------- ---------+--------- | edge-router1 | | edge-router2 | | 2001:DB8::1/128 | | 2001:DB8::2/128 | ---------+--------- ---------+--------- | | \ link1 link2 / \------------\ /----------/ \ / | | ----+---------+---- | CPE | | | ---------+--------- | LAN 2001:DB8:1000::/48 Internal Infrastructure Security Considerations ----------------------------------------------- Internal infrastructure could be numbered out of space that is not routed or reachable by the public Internet. This could be used to secure internal only services in a multi-layered approach by filtering direct network connections in the forwarding plane, and not routing the network in the global Internet routing table. Internal services which could take advantage of these layers of protection include: SNMP services, iBGP mesh, Out-of-Band management network(s), remote access to the network devices that make up the network in question. A layered security approach will help to prevent breaches in security via singular config management problems. Additionally, having all of the services out of an aggregate block will simplify the configuration management situation. In essence, this allows for a two tier approach of protecting infrastructure, both in the control plane by not routing the network, and in the forwarding plane by utilizing packet filters which are easily constructed and managed due to the uniqueness of the internal infrastructure block. Private Address Considerations ------------------------------ Private addresses are not appropriate for a number of reasons. A public Internet network using private addresses internally may create confusion if trace routes contain private addresses. Additional problems may result due to wide spread filtering of private address space. ICMP mesages may get dropped due to such a policy. This can lead to precieved odd behavior and make troubleshooting difficult. Additionally, the consequences of accidentally routing private ip space that is not globally unique, are potentially worse than if you accidentally announced globally unique space. DNS for private address space is today provided by blackhole-1.iana.org. and blackhole-2.iana.org. A provider who wants to maintain forward and reverse DNS sanity has to hijack those ip addresses to provide consistent DNS resolution. This will cause any users who's traffic transits that provider's network to also get 'inconsistent' answers with respect to the private address space in question. For management and troubleshooting purposes, it is important that infrastructure which provides Internet route reachability be numbered with addresses that resolve through DNS. Also, global uniqueness of addressing is important in minimizing renumbering efforts as organizations (and their networks) merge. RFC 4193 provides for neither of these needs. Timetable for implementation: Immediate From andrew.dul at quark.net Thu Feb 9 11:55:17 2006 From: andrew.dul at quark.net (=?iso-8859-1?Q?Andrew=20Dul?=) Date: Thu, 09 Feb 2006 16:55:17 +0000 Subject: [ppml] alternative to 2005-1 Message-ID: <20060209165517.11227.qmail@hoster908.com> I have written the following policy as an alternative to 2005-1. I believe this policy is more conservative that the existing proposed 2005-1 policy. While this policy does allow PI allocations to end-sites, it limits the scope to current IPv4 holders with a direct allocation. I believe a more conservative policy is desirable as the first IPv6 PI policy. If I receive positive feedback on this policy today, I'm willing to post this as an alternative to 2005-1 to be discussed at the upcoming meeting. Andrew ------ 6.5.8. Direct assignments to end sites 6.5.8.1. To qualify for a direct end site assignment, an organization must: 1. not be an LIR; 2. be an end site; 3. be currently multihomed using IPv4; 4. be an ARIN member for at least 1 year prior to assignment of an IPv6 end site assignment; 5. have a direct assignment from ARIN of at least a IPv4 /19 and can show the current utilization of 80% of an IPv4 /19 equivalent. 6.5.8.2. Direct assignment size to end sites Organizations that meet the direct end site assignment criteria are eligible to receive a direct assignment of /48 out of a reserved /44. Direct Assignments shall be allocated from a separate super-block to allow for LIRs to filter. 6.5.8.3. Subsequent direct assignments to end sites Organizations assignment size may be increased by 1 bit (to a maximum of /44) when they demonstrate the active usage of 50% of the assigned /64 subnets. Only one direct assignment may be made to an end site organization under Section 6.5.8. Organizations which can demonstrate active usage of more than 50% of /64 networks from a /44 assignment may apply for an additional allocation as an LIR. From sleibrand at internap.com Thu Feb 9 12:10:10 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Thu, 9 Feb 2006 12:10:10 -0500 (EST) Subject: [ppml] alternative to 2005-1 In-Reply-To: <20060209165517.11227.qmail@hoster908.com> References: <20060209165517.11227.qmail@hoster908.com> Message-ID: Andrew, First, I would clarify that for 6.5.8.1 you must meet ALL of the listed criteria (AND instead of OR). Also, why do you specify /19 for #5 under 6.5.8.1? Shouldn't someone with a IPv4 PI /22 be able to get an IPv6 /48? I prefer this alternative policy over the current draft of 2005-1, because it is conservative and avoids the possibility of an early adopter bonus. However, I think a /19 IPv4 requirement is a bit too conservative, and that anyone who qualifies for a /22 of PI space in IPv4 should qualify for a /48 of IPv6 PI space. I would also say that #5 should be changed to say "qualifies for a direct assignment from ARIN of at least a IPv4 ...", instead of requiring them to already have such an assignment. So my preferred language for 6.5.8.1 would be: 6.5.8.1. To qualify for a direct end site assignment, an organization must: 1. not be an LIR; 2. be an end site; 3. be currently multihomed using IPv4; 4. be an ARIN member for at least 1 year prior to assignment of an IPv6 end site assignment; 5. qualify for a direct assignment from ARIN of at least a IPv4 /22 -Scott On 02/09/06 at 4:55pm -0000, Andrew Dul wrote: > I have written the following policy as an alternative to 2005-1. > > I believe this policy is more conservative that the existing proposed 2005-1 policy. While this policy does allow PI allocations to end-sites, it limits the scope to current IPv4 holders with a direct allocation. I believe a more conservative policy is desirable as the first IPv6 PI policy. > > If I receive positive feedback on this policy today, I'm willing to post this as an alternative to 2005-1 to be discussed at the upcoming meeting. > > Andrew > > ------ > > > 6.5.8. Direct assignments to end sites > > 6.5.8.1. To qualify for a direct end site assignment, an organization must: > > 1. not be an LIR; > 2. be an end site; > 3. be currently multihomed using IPv4; > 4. be an ARIN member for at least 1 year prior to assignment of an IPv6 end site assignment; > 5. have a direct assignment from ARIN of at least a IPv4 /19 and can show the current utilization of 80% of an IPv4 /19 equivalent. > > 6.5.8.2. Direct assignment size to end sites > > Organizations that meet the direct end site assignment criteria are eligible to receive a direct assignment of /48 out of a reserved /44. Direct Assignments shall be allocated from a separate super-block to allow for LIRs to filter. > > 6.5.8.3. Subsequent direct assignments to end sites > > Organizations assignment size may be increased by 1 bit (to a maximum of /44) when they demonstrate the active usage of 50% of the assigned /64 subnets. > > Only one direct assignment may be made to an end site organization under Section 6.5.8. > > Organizations which can demonstrate active usage of more than 50% of /64 networks from a /44 assignment may apply for an additional allocation as an LIR. > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From andrew.dul at quark.net Thu Feb 9 12:21:27 2006 From: andrew.dul at quark.net (=?iso-8859-1?Q?Andrew=20Dul?=) Date: Thu, 09 Feb 2006 17:21:27 +0000 Subject: [ppml] alternative to 2005-1 Message-ID: <20060209172128.17942.qmail@hoster908.com> > -------Original Message------- > From: Scott Leibrand > Also, why do you specify /19 for #5 under 6.5.8.1? Shouldn't someone with > a IPv4 PI /22 be able to get an IPv6 /48? > It is just a line in the sand. I personally believe that a /22 is too small, however there are those who will think that an org with a /22 should be able to obtain a IPv6 PI address space. By increasing the IPv4 network requirement we reduce the number of possible allocations. I think this is a reasonable compromise to ensure that we adopt a IPv6 PI policy sooner rather than later. Having said that if the consensus of the community is to allow an org with a /22 to obtain a IPv6 PI allocation, I also support that. Andrew From sleibrand at internap.com Thu Feb 9 12:30:58 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Thu, 9 Feb 2006 12:30:58 -0500 (EST) Subject: [ppml] alternative to 2005-1 In-Reply-To: <20060209172128.17942.qmail@hoster908.com> References: <20060209172128.17942.qmail@hoster908.com> Message-ID: On 02/09/06 at 5:21pm -0000, Andrew Dul wrote: > > Also, why do you specify /19 for #5 under 6.5.8.1? Shouldn't someone > > with a IPv4 PI /22 be able to get an IPv6 /48? > > It is just a line in the sand. > > I personally believe that a /22 is too small, however there are those > who will think that an org with a /22 should be able to obtain a IPv6 PI > address space. By increasing the IPv4 network requirement we reduce the > number of possible allocations. Ok. I think that by simply preventing anyone who doesn't qualify for IPv4 PI space from getting IPv6 PI space, we reduce the number of possible allocations sufficiently. IOW, my biggest concern is IPv6-PI-for-everyone, not simply giving IPv6 PI space to anyone who qualifies for IPv4 PI space. > I think this is a reasonable compromise to ensure that we adopt a IPv6 > PI policy sooner rather than later. And if that's what it takes to get it passed, I'll support it, since we can always make the policy more liberal later (whereas it's hard to make it more conservative later). > Having said that if the consensus of the community is to allow an org > with a /22 to obtain a IPv6 PI allocation, I also support that. Ditto for /19's or whatever the consensus is... -Scott From narten at us.ibm.com Thu Feb 9 12:45:26 2006 From: narten at us.ibm.com (Thomas Narten) Date: Thu, 09 Feb 2006 12:45:26 -0500 Subject: [ppml] alternative to 2005-1 In-Reply-To: Message from andrew.dul@quark.net of "Thu, 09 Feb 2006 17:21:27 GMT." <20060209172128.17942.qmail@hoster908.com> Message-ID: <200602091745.k19HjQIH026277@rotala.raleigh.ibm.com> > > Also, why do you specify /19 for #5 under 6.5.8.1? Shouldn't someone with > > a IPv4 PI /22 be able to get an IPv6 /48? > > > It is just a line in the sand. > I personally believe that a /22 is too small, however there are > those who will think that an org with a /22 should be able to obtain > a IPv6 PI address space. Note: a /22 is only 2^10 addresses, or 1024. That's a pretty darn small site, if you ask me. A /19 is somewhat better, namely, 8192. Still, I fear there are 10s to 100s of thousands of organizations in this size. Remember, each entity with a PI assignment translates into a routing slot in the DFZ. Heck, even if we set a threshold of /16, we'd be saying "anyone who can justify a class B assignment". I suspect that the number of end sites meeting that criteria is pretty large. I'd feel a lot more comfortable picking a threshold if I had a rough idea of how many entities we're talking about who would qualify. Given the above, even /19 sounds too low. In the absense of data, I'd say be _very _ conservative, e.g., start with a /16 (or higher). Thomas From billd at cait.wustl.edu Thu Feb 9 13:05:35 2006 From: billd at cait.wustl.edu (Bill Darte) Date: Thu, 9 Feb 2006 12:05:35 -0600 Subject: [ppml] alternative to 2005-1 Message-ID: Again, I assume that everyone assumes...that an end site's v4 allocation is preserved 'forever' even with the v6 allocation...right? I never see this as specifically stated. If that is the case, then each v6 PI for an existing v4 PI IS and additional routing slot, but not if the v4 is eventually withdrawn...right? For the record... bd > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Thomas Narten > Sent: Thursday, February 09, 2006 11:45 AM > To: Andrew Dul > Cc: ppml at arin.net > Subject: Re: [ppml] alternative to 2005-1 > > > > > Also, why do you specify /19 for #5 under 6.5.8.1? Shouldn't > > > someone with a IPv4 PI /22 be able to get an IPv6 /48? > > > > > > It is just a line in the sand. > > > I personally believe that a /22 is too small, however there > are those > > who will think that an org with a /22 should be able to > obtain a IPv6 > > PI address space. > > Note: a /22 is only 2^10 addresses, or 1024. That's a pretty > darn small site, if you ask me. > > A /19 is somewhat better, namely, 8192. > > Still, I fear there are 10s to 100s of thousands of > organizations in this size. Remember, each entity with a PI > assignment translates into a routing slot in the DFZ. > > Heck, even if we set a threshold of /16, we'd be saying > "anyone who can justify a class B assignment". I suspect that > the number of end sites meeting that criteria is pretty large. > > I'd feel a lot more comfortable picking a threshold if I had > a rough idea of how many entities we're talking about who > would qualify. Given the above, even /19 sounds too low. > > In the absense of data, I'd say be _very _ conservative, > e.g., start with a /16 (or higher). > > Thomas > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From dgolding at burtongroup.com Thu Feb 9 12:54:17 2006 From: dgolding at burtongroup.com (Daniel Golding) Date: Thu, 09 Feb 2006 12:54:17 -0500 Subject: [ppml] alternative to 2005-1 In-Reply-To: <200602091745.k19HjQIH026277@rotala.raleigh.ibm.com> Message-ID: On 2/9/06 12:45 PM, "Thomas Narten" wrote: >>> Also, why do you specify /19 for #5 under 6.5.8.1? Shouldn't someone with >>> a IPv4 PI /22 be able to get an IPv6 /48? >>> > >> It is just a line in the sand. > >> I personally believe that a /22 is too small, however there are >> those who will think that an org with a /22 should be able to obtain >> a IPv6 PI address space. > > Note: a /22 is only 2^10 addresses, or 1024. That's a pretty darn small > site, if you ask me. > > A /19 is somewhat better, namely, 8192. > > Still, I fear there are 10s to 100s of thousands of organizations in > this size. Remember, each entity with a PI assignment translates into > a routing slot in the DFZ. > > Heck, even if we set a threshold of /16, we'd be saying "anyone who > can justify a class B assignment". I suspect that the number of end > sites meeting that criteria is pretty large. > > I'd feel a lot more comfortable picking a threshold if I had a rough > idea of how many entities we're talking about who would qualify. Given > the above, even /19 sounds too low. > > In the absense of data, I'd say be _very _ conservative, e.g., start > with a /16 (or higher). Again, we are headed down a road that we have been on before. The last 2005-1 was defeated because of this point - the bar was set too high. I can understand those who wish for no end-site multihoming. I can understand those who wish for end-site multihoming similar to IPv4. However, I can't understand going in circles, which is exactly what we are doing. > > Thomas > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml - Dan From hannigan at renesys.com Thu Feb 9 13:00:55 2006 From: hannigan at renesys.com (Martin Hannigan) Date: Thu, 09 Feb 2006 13:00:55 -0500 Subject: [ppml] alternative to 2005-1 In-Reply-To: References: <200602091745.k19HjQIH026277@rotala.raleigh.ibm.com> Message-ID: <7.0.1.0.0.20060209125927.01b36348@renesys.com> At 12:54 PM 2/9/2006, Daniel Golding wrote: >On 2/9/06 12:45 PM, "Thomas Narten" wrote: > > >>> Also, why do you specify /19 for #5 under 6.5.8.1? Shouldn't > someone with > >>> a IPv4 PI /22 be able to get an IPv6 /48? > >>> > > > >> It is just a line in the sand. > > > >> I personally believe that a /22 is too small, however there are > >> those who will think that an org with a /22 should be able to obtain > >> a IPv6 PI address space. > > > > Note: a /22 is only 2^10 addresses, or 1024. That's a pretty darn small > > site, if you ask me. > > > > A /19 is somewhat better, namely, 8192. > > > > Still, I fear there are 10s to 100s of thousands of organizations in > > this size. Remember, each entity with a PI assignment translates into > > a routing slot in the DFZ. > > > > Heck, even if we set a threshold of /16, we'd be saying "anyone who > > can justify a class B assignment". I suspect that the number of end > > sites meeting that criteria is pretty large. > > > > I'd feel a lot more comfortable picking a threshold if I had a rough > > idea of how many entities we're talking about who would qualify. Given > > the above, even /19 sounds too low. > > > > In the absense of data, I'd say be _very _ conservative, e.g., start > > with a /16 (or higher). > >Again, we are headed down a road that we have been on before. The last >2005-1 was defeated because of this point - the bar was set too high. I can >understand those who wish for no end-site multihoming. I can understand >those who wish for end-site multihoming similar to IPv4. However, I can't >understand going in circles, which is exactly what we are doing. This is deadlock again. -M< -- Martin Hannigan (c) 617-388-2663 Renesys Corporation (w) 617-395-8574 Member of Technical Staff Network Operations hannigan at renesys.com From billd at cait.wustl.edu Thu Feb 9 13:47:54 2006 From: billd at cait.wustl.edu (Bill Darte) Date: Thu, 9 Feb 2006 12:47:54 -0600 Subject: [ppml] Principles for IPv6 PI allocations to end sites Message-ID: So....deriving a 'pain index' that establishes a threshold for PI? Number of hosts to renumber, Number of Firewalls and other embedded address devices, Number of available ISPs to choose from(level of competitive opportunity), Multihoming Experience with BGP, AS Number etc., What factors would contribute to an objective mechanism of establishing pain.... Or is all else dwarfed by numbers of hosts? I am not in favor of 'arbitrary' boundaries. 100,000 hosts = PI, 99,000 not enough pain = No PI? Reasonable? Justifiable? Still say that the problem is not with address policy, but with routing technology/technique. Why are other parts of the world experiencing growth of IPv6? Less pain?, Willingness to accept PA?, Smarter geeks?, what? Bill Darte ARIN AC > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Edward Lewis > Sent: Wednesday, February 08, 2006 10:43 PM > To: Thomas Narten > Cc: ppml at arin.net > Subject: Re: [ppml] Principles for IPv6 PI allocations to end sites > > > I haven't been able to read the 2005-1 thread, so this message is > quite welcome. > > At 17:00 -0500 2/8/06, Thomas Narten wrote: > >Here are some thoughts I have w.r.t. this topic. Generally, I'm in > >favor of coming up with a policy for granting PI space to large end > >sites. However, I am also very concerned that we do not open the > >floodgates and create a situation a few years down the road that we > >wish we weren't in. > > > >Some principles I keep in my mind as I evaluate various proposals. > > > >IPv6 space is a public resource, and we need to avoid having > a policy > >adopted today turn into an "early adopter bonus program". > That is, if > >5-10 years from now we have two classes of entities: > > Are we truly concerned about "early adopters" when we have a hard > time getting IPv6 rolling at all? (That's my snicker-eliciting > comment.) > > "Early adoption" is already past tense in (at least) the APNIC > region. I understand the point here, perhaps the label "early > adopter" is a misnomer though. > > >Corallary: I don't buy the argument that "we can always change the > >policy later, > > I have to disagree with this. Coming up with a perfect policy is > difficult. We can have a "perfect" design of a technical system, but > in a subjective environment such as address allocation policy I think > we ought to strive for a perfect policy but realize that it's a dream. > > >Multihoming: we don't have a "magic bullet" multihoming solution on > ... > >One question that arises is fairness. Since we can't give PI space to > ... > >prefix in the DFZ. Hence, I tend to lean towards giving PI > space only > >to the largest end sites, i.e., those that will provide > benefit to the > >largest communities. > > I think the above is the crux of the problem. > > I'll agree that we ought to forget about a technical solution to > multihoming coming any time soon (snicker - one more broken promise > by IPv6). Fairness is what this is all about - but I don't think the > size of the benefiting community is the metric. (For example, if a > site is in the US but plans to market to China and will have it's web > site in the Chinese language, does that mean it caters to the > "largest" community.) > > >There may be other metrics that we should consider; in any case, I do > > I would think that the metric ought to be tied to the level of pain > of reacting to an event that would have driven a would-be PI user to > PI. I.e., if the reason to want PI space to be to avoid having to > renumber out of a failed ISP's address range into another, then > priority ought to go to PI-wannabes with the largest address need. > (Or that have the largest number of firewalls which need to have > addresses configured, etc.) > > >I believe we need to allocate PI space out of specific > prefix, so that > > How would this differ from todays (IPv4's) swamp space? I suppose > that it would only be within one RIR (but across LIRs to manage), but > it would be as painful to routing as the IPv4 swamp. > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > -=-=-=-=-=-=- > Edward Lewis > +1-571-434-5468 > NeuStar > > Nothin' more exciting than going to the printer to watch the > toner drain... _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From steven.feldman at cnet.com Thu Feb 9 13:36:59 2006 From: steven.feldman at cnet.com (Steve Feldman) Date: Thu, 9 Feb 2006 10:36:59 -0800 Subject: [ppml] alternative to 2005-1 In-Reply-To: <20060209165517.11227.qmail@hoster908.com> References: <20060209165517.11227.qmail@hoster908.com> Message-ID: I'm somewhat confused by this discussion: Is the intent to also disallow site multihoming using PA space? If I can obtain a /48 from one provider, and also announce it through one or more other providers, doesn't it use that same "routing slot" a PI assignment would use? If so, then why is this better than a PI assignment? If I can't do that, then it effectively prevents me from multihoming at all, which prevents me from using IPv6 in any meaningful way. Steve From sleibrand at internap.com Thu Feb 9 15:01:18 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Thu, 9 Feb 2006 15:01:18 -0500 (EST) Subject: [ppml] alternative to 2005-1 In-Reply-To: <200602091745.k19HjQIH026277@rotala.raleigh.ibm.com> References: <200602091745.k19HjQIH026277@rotala.raleigh.ibm.com> Message-ID: On 02/09/06 at 12:45pm -0500, Thomas Narten wrote: > > > Also, why do you specify /19 for #5 under 6.5.8.1? Shouldn't someone with > > > a IPv4 PI /22 be able to get an IPv6 /48? > > > It is just a line in the sand. > > > I personally believe that a /22 is too small, however there are > > those who will think that an org with a /22 should be able to obtain > > a IPv6 PI address space. > > Note: a /22 is only 2^10 addresses, or 1024. That's a pretty darn small > site, if you ask me. So what? We give them a routing slot for IPv4. Why shouldn't they get one in IPv6? > A /19 is somewhat better, namely, 8192. > > Still, I fear there are 10s to 100s of thousands of organizations in > this size. Remember, each entity with a PI assignment translates into > a routing slot in the DFZ. Regardless of how many such organizations exist, the number of IPv4 PI /22's vs. /19's tells you how many such organizations would qualify for IPv6 PI space under this type of policy. The number isn't that large, and with a /22 requirement limits you to at maximum the same number of IPv6 PI blocks as we have IPv4 PI blocks. IMO those kinds of numbers are small enough to deal with effectively without wholesale PI filtering, unlike in the IPv6-PI-for-everyone case. > Heck, even if we set a threshold of /16, we'd be saying "anyone who > can justify a class B assignment". I suspect that the number of end > sites meeting that criteria is pretty large. But significantly smaller than the number of sites for whom PI space is necessary to avoid significant renumbering pain when changing ISPs. > I'd feel a lot more comfortable picking a threshold if I had a rough > idea of how many entities we're talking about who would qualify. Given > the above, even /19 sounds too low. > > In the absence of data, I'd say be _very _ conservative, e.g., start > with a /16 (or higher). We have plenty of data. Just count the number of netblocks in the current IPv4 table. If you want to be more precise, count the number of /22's and larger in the table from the ranges reserved for IPv4 PI assignments. -Scott From Ed.Lewis at neustar.biz Thu Feb 9 15:04:13 2006 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Thu, 9 Feb 2006 15:04:13 -0500 Subject: [ppml] Principles for IPv6 PI allocations to end sites Message-ID: I wish I had an answer. (I knew that when I spoke up.) But seriously, the drive to want provider independent space is a reaction to not be willing to rely on a single ISP. I'll go further out the limb and say "not willing to rely on a single ISP to be reliable." If I'm worried about reaching the largest audience, then all I want is a global transit provider with fat pipes. Unlike placing a mall at the cross roads to attract more vehicle traffic, placement of servers isn't so sensitive to diverse topology. (Fewer hops yes, but 30 T-1's are not better than a single T-3, other things being equal.) I think back to the April 2001 ARIN meeting (in SF) which happened right after an ISP suddenly went belly up and folks went scrambling for a new provider. I mention that because that is why I think provider independent space is an important topic - of course I may be wrong which is why I'm laying my cards on the table. If I'm right, then whatever metric we use ought to be tied to that. Still, I don't have the perfect metric in mind (like the perfect heuristic), but when I am looking at metrics, I'd be looking to see if it captures the pain thresh hold that drives a requestor to seek their own space. We (a TLD operator) have provider independent space because we use multiple providers to our different locations. And we do that not for bandwidth but to limit damage of one going up. We don't have a lot of servers at the locations - it's not size but the fact that we have so-called critical infrastructure. Still, I am not making a point...;) Consider my comment in the context of Thomas' "greatest audience" suggestion, which I think may be contrary to the heuristic. The reason is that such a metric helps "the big boys" gain even more of an advantage. I.e., (for example) Amazon would have a larger audience than a local competitor. The price leverage Amazon would have would augmented by reliability leverage. Just take this as some thoughts on the topic, not much more. At 9:33 -0600 2/9/06, Bill Darte wrote: >So....deriving a 'pain index' that establishes a threshold for PI? > >Number of hosts to renumber >Number of Firewalls and other embedded address devices >Number of available ISPs to choose from(level of competitive opportunity) >Multihoming >Experience with BGP >AS Number >etc. > >What factors would contribute to an objective mechanism of establishing >pain.... > >Or is all else dwarfed by numbers of hosts? > >I am not in favor of 'arbitrary' boundaries. 100,000 hosts = PI, 99,000 not >enough pain = No PI? Reasonable? Justifiable? > >Still say that the problem is not with address policy, but with routing >technology/technique. > >Why are other parts of the world experiencing growth of IPv6? > >Less pain?, Willingness to accept PA?, Smarter geeks?, what? > >Bill Darte >ARIN AC > >> -----Original Message----- >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On >> Behalf Of Edward Lewis >> Sent: Wednesday, February 08, 2006 10:43 PM >> To: Thomas Narten >> Cc: ppml at arin.net >> Subject: Re: [ppml] Principles for IPv6 PI allocations to end sites >> >> >> I haven't been able to read the 2005-1 thread, so this message is >> quite welcome. >> >> At 17:00 -0500 2/8/06, Thomas Narten wrote: >> >Here are some thoughts I have w.r.t. this topic. Generally, I'm in >> >favor of coming up with a policy for granting PI space to large end >> >sites. However, I am also very concerned that we do not open the >> >floodgates and create a situation a few years down the road that we >> >wish we weren't in. >> > >> >Some principles I keep in my mind as I evaluate various proposals. >> > >> >IPv6 space is a public resource, and we need to avoid having >> a policy >> >adopted today turn into an "early adopter bonus program". >> That is, if >> >5-10 years from now we have two classes of entities: >> >> Are we truly concerned about "early adopters" when we have a hard >> time getting IPv6 rolling at all? (That's my snicker-eliciting >> comment.) >> >> "Early adoption" is already past tense in (at least) the APNIC >> region. I understand the point here, perhaps the label "early >> adopter" is a misnomer though. >> >> >Corallary: I don't buy the argument that "we can always change the >> >policy later, >> >> I have to disagree with this. Coming up with a perfect policy is >> difficult. We can have a "perfect" design of a technical system, but >> in a subjective environment such as address allocation policy I think >> we ought to strive for a perfect policy but realize that it's a dream. >> >> >Multihoming: we don't have a "magic bullet" multihoming solution on >> ... >> >One question that arises is fairness. Since we can't give PI space to >> ... >> >prefix in the DFZ. Hence, I tend to lean towards giving PI >> space only >> >to the largest end sites, i.e., those that will provide >> benefit to the >> >largest communities. >> >> I think the above is the crux of the problem. >> >> I'll agree that we ought to forget about a technical solution to >> multihoming coming any time soon (snicker - one more broken promise >> by IPv6). Fairness is what this is all about - but I don't think the >> size of the benefiting community is the metric. (For example, if a >> site is in the US but plans to market to China and will have it's web >> site in the Chinese language, does that mean it caters to the >> "largest" community.) >> >> >There may be other metrics that we should consider; in any case, I do >> >> I would think that the metric ought to be tied to the level of pain >> of reacting to an event that would have driven a would-be PI user to >> PI. I.e., if the reason to want PI space to be to avoid having to >> renumber out of a failed ISP's address range into another, then >> priority ought to go to PI-wannabes with the largest address need. >> (Or that have the largest number of firewalls which need to have >> addresses configured, etc.) >> >> >I believe we need to allocate PI space out of specific >> prefix, so that >> >> How would this differ from todays (IPv4's) swamp space? I suppose >> that it would only be within one RIR (but across LIRs to manage), but >> it would be as painful to routing as the IPv4 swamp. >> >> -- >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> -=-=-=-=-=-=- >> Edward Lewis >> +1-571-434-5468 >> NeuStar >> >> Nothin' more exciting than going to the printer to watch the >> toner drain... _______________________________________________ >> PPML mailing list >> PPML at arin.net >> http://lists.arin.net/mailman/listinfo/ppml >> -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... From drc at virtualized.org Thu Feb 9 15:18:28 2006 From: drc at virtualized.org (David Conrad) Date: Thu, 9 Feb 2006 12:18:28 -0800 Subject: [ppml] alternative to 2005-1 In-Reply-To: References: <200602091745.k19HjQIH026277@rotala.raleigh.ibm.com> Message-ID: <2ED4AF46-7327-4850-BD14-1E1B148AD4F1@virtualized.org> Hi, On Feb 9, 2006, at 12:01 PM, Scott Leibrand wrote: >> Note: a /22 is only 2^10 addresses, or 1024. That's a pretty darn >> small >> site, if you ask me. > So what? We give them a routing slot for IPv4. Why shouldn't they > get > one in IPv6? One of the arguments back in IPng days was that one of the benefits of IPng would be we'd be able to start with a clean slate in terms of routing and all the historical mistakes made with IPv4 wouldn't be repeated. 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 andrew.dul at quark.net Thu Feb 9 15:35:37 2006 From: andrew.dul at quark.net (=?iso-8859-1?Q?Andrew=20Dul?=) Date: Thu, 09 Feb 2006 20:35:37 +0000 Subject: [ppml] alternative to 2005-1 Message-ID: <20060209203537.32391.qmail@hoster908.com> > -------Original Message------- > From: Thomas Narten > > Heck, even if we set a threshold of /16, we'd be saying "anyone who > can justify a class B assignment". I suspect that the number of end > sites meeting that criteria is pretty large. > > I'd feel a lot more comfortable picking a threshold if I had a rough > idea of how many entities we're talking about who would qualify. Given > the above, even /19 sounds too low. > The proposed policy as written requires an org who requests an allocation to be an ARIN member for at least 1 year. According to ARIN's website there are currently 2371 members. As a worst case under this policy only ~2k PI blocks could be issued in the next 12 months. That seems like a pretty slow start to me. http://www.arin.net/statistics/index.html From owen at delong.com Thu Feb 9 15:46:10 2006 From: owen at delong.com (Owen DeLong) Date: Thu, 09 Feb 2006 12:46:10 -0800 Subject: [ppml] Comments on revised 2005-1 proposal of 2006-02-03 In-Reply-To: References: Message-ID: <0DEE9AF372810493550E1E88@dhcp64-134-112-117.stone.dal.wayport.net> I thought the original argument against opening up PI was to avoid creating an early adopter advantage. Why is it better to give large organizations first crack at an early adopter advantage and then later consider whether or not to treat the rest as second class citizens? I see that as being even worse than the small risk of an early adopter advantage. Frankly, I think that realistically, the following are true: 1. We need a new IDR paradigm that allows for a separation between the routing locator and the end system identifier (ASN and IP address are most likely mappings for RL and ESI in the near term, but, today, we are using IP address for both). 2. By continuing to treat organizations below some arbitrary threshold as second class citizens on the internet, we _MAY_ be able to postpone the date when the new routing paradigm mentioned in 1 is required. 3. Even if we gave v6 PI blocks to everyone who could justify them under the most liberal of these policies, I believe it would be at least 10 years before we had to truly worry about router meltdown due to table size. That should be more than adequate time for IETF to develop a solution. (I believe I have good beginnings of a solution. Let me know if you are interested in more detail). 4. I believe a solution is possible which requires: 1. code changes on core routers. 2. code changes on DFZ Edge routers. 3. Additional CPU on DFZ Edge routers (potentially) 4. Suggests crypto acceleration on DFZ Edge routers 5. Does not require modifications to non-DFZ routers 6. Limits the size of the global routing table to the list of viable AS Paths. 7. Allows leaf sites to multihome with a single PI block and no AS, thus not increasing the routing table slots in the DFZ. 5. Since the above solution does not require edge router updates, and most DFZ routers see software updates more than once per year and hardware replacement usually on approx. a 3 year cycle, and, this doesn't require hardware changes (although some are recommended), 10 years gives the IETF 7 years to argue, code, test, agree, and publish and we still have plenty of time for the vendors to add it to the featureset and roll it out to end users. I agree that expecting IETF to agree on anything in 7 years may be a bit optimistic, but, I think it can be done. Finally, we need PI space for end sites/users/organizations/whetever term you prefer precisely because IPv6 did not solve multihoming. The lack of a multihoming solution in IPv6 makes it a non-starter for most organizations. Lack of PI space will have a similar effect for other reasons besides multhoming. Renumbering a /48 can be prohibitively painful and costly, especially when it involves ACLs and pointers that are maintained in foreign authority zones (customers VPN ACLs, etc.). Locking businesses into a particular provider just because we're too lazy to fix the protocol is no longer an option. Owen Owen --On February 9, 2006 9:33:44 AM -0500 Glenn Wiltse wrote: > I wasn't nessasarly endorsing any 'host count' as being the > defining factor. However I do think the main point of contention > is how exactly to determin some size threshold nessasary, and what > to use as a unit of meassure. That's why I personaly like > the idea of using unique street addresss. > > One thing I don't like, and I think many others don't like, is the > idea that ARIN would hand out many /48s simply because some orginzations > felt they had to have PI space and/or they are currently multi homed. > > Maybe later, after some of the biggest end originzations have gotten > PI space, and we know where we stand in terms of demand and/or needs, we > could possibly later relax the size limits and/or then start to give out > smaller block, etc... > > Glenn Wiltse > > On Thu, 9 Feb 2006, Dan Golding wrote: > >> On 2/9/06 8:28 AM, "Glenn Wiltse" wrote: >> >>> In general, I like the direction Thomas is heading in... (giving >>> PI to the largest sites and trying not to give out small blocks simply >>> because someone says they need multi homing, etc...) >>> >>> I would change refferances to 'end site', in favor of the term 'end >>> orginization' (which would imply these cant' be re-assigned to other >>> orginizations, but little else implyed in the meaning) >>> >>> In my mind, the only real sticky point is in deciding what exactly >>> defines a originization as being 'large' enough to get a PI assignment. >>> >>> I do think that a /40 is about the smallest sized block that I would >>> like to see given out as IPv6 PI space at this time. Just how you >>> define who is large enough to justify such a assignment I do not know. >>> >>> I personaly would rather see unique street addresses be considered >>> as justification for space, more so then number of employees... but >>> perhaps either or... or some combination of both, etc... >>> >>> Anyway, I do really think Thomas is on the right track with his >>> most recent comments and/or proposal. >>> >>> Glenn Wiltse >> >> This is a dead end. The last 2005-1 was defeated at the last ARIN meeting >> specifically because of the 100k host requirement. >> >> - Daniel Golding >> >> >> >> >> !DSPAM:43eb4f0186132993215505! >> >> > _______________________________________________ > 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 billd at cait.wustl.edu Thu Feb 9 16:02:21 2006 From: billd at cait.wustl.edu (Bill Darte) Date: Thu, 9 Feb 2006 15:02:21 -0600 Subject: [ppml] Comments on revised 2005-1 proposal of 2006-02-03 Message-ID: I would add to Owen's list that 'some' in the region, certainly in the world would see the distinction between big and small as rich and poor and...this would lead to a resurgence of the 'Governance' issues that ARIN counsel warned have not gone away...only postponed.... If I can paraphrase my recollection of his pronouncements at the last meeting. bd > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Owen DeLong > Sent: Thursday, February 09, 2006 2:46 PM > To: Glenn Wiltse; Dan Golding > Cc: PPML > Subject: Re: [ppml] Comments on revised 2005-1 proposal of 2006-02-03 > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From owen at delong.com Thu Feb 9 15:52:48 2006 From: owen at delong.com (Owen DeLong) Date: Thu, 09 Feb 2006 12:52:48 -0800 Subject: [ppml] alternative to 2005-1 In-Reply-To: <20060209165517.11227.qmail@hoster908.com> References: <20060209165517.11227.qmail@hoster908.com> Message-ID: <7F80E76C9431C9F884174F2D@dhcp64-134-112-117.stone.dal.wayport.net> > 6.5.8. Direct assignments to end sites > > 6.5.8.1. To qualify for a direct end site assignment, an > organization must: > > 1. not be an LIR; > 2. be an end site; > 3. be currently multihomed using IPv4; > 4. be an ARIN member for at least 1 year prior to assignment of an IPv6 > end site assignment; > 5. have a direct assignment from ARIN of at least a > IPv4 /19 and can show the current utilization of 80% of an IPv4 /19 > equivalent. > Why should they have to be an ARIN member at all? Current recipients of end-site assignments have no such requirement in IPv4 or IPv6. Requirement 4 is absolutely specious. Requirement 5 is similarly specious unless you are willing to adapt it to match current IPv4 policy since adoption of 2002-3 and move the boundary to at least /22. > Organizations which can demonstrate active usage of more than 50% of /64 > networks from a /44 assignment may apply for an additional allocation as > an LIR. > Unless you also modify the criteria for an LIR (eliminating the requirement for assignments to external organizations or altering the definition of external organizations), this paragraph is meaningless. They can apply now, but, they will not receive one because they do not meet the ARIN requirements for an LIR. 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 dgolding at burtongroup.com Thu Feb 9 15:58:07 2006 From: dgolding at burtongroup.com (Daniel Golding) Date: Thu, 09 Feb 2006 15:58:07 -0500 Subject: [ppml] alternative to 2005-1 In-Reply-To: <2ED4AF46-7327-4850-BD14-1E1B148AD4F1@virtualized.org> Message-ID: On 2/9/06 3:18 PM, "David Conrad" wrote: > Hi, > > On Feb 9, 2006, at 12:01 PM, Scott Leibrand wrote: >>> Note: a /22 is only 2^10 addresses, or 1024. That's a pretty darn >>> small >>> site, if you ask me. >> So what? We give them a routing slot for IPv4. Why shouldn't they >> get >> one in IPv6? > > One of the arguments back in IPng days was that one of the benefits > of IPng would be we'd be able to start with a clean slate in terms of > routing and all the historical mistakes made with IPv4 wouldn't be > repeated. > > Rgds, > -drc > -------- The world is different now, than in the IPng days. Enterprises, governments, providers, and individuals now utilize the Internet for a plethora of economic and personal applications. There is no longer a clean slate. Way too much of this discussion ignores this. If IPv6 PI space isn't available, is more difficult to get, or there are more hoops to jump through, there will be no IPv6, as we know now it. We do not have a free hand. If the wrong decisions are made, they may be ARIN's last decisions. The failure of IPv6 and the RIR exhaustion of the v4 space may lead to a market-driven system that may evolve considerably different regulatory mechanisms. Consensus decision making breaks down after a certain point. I'm thinking we are approaching that point. - Dan From ahp at hilander.com Thu Feb 9 16:04:03 2006 From: ahp at hilander.com (Alec H. Peterson) Date: Thu, 9 Feb 2006 14:04:03 -0700 Subject: [ppml] alternative to 2005-1 In-Reply-To: References: Message-ID: Hi Dan, On Feb 9, 2006, at 13:58, Daniel Golding wrote: > > The world is different now, than in the IPng days. Enterprises, > governments, > providers, and individuals now utilize the Internet for a plethora of > economic and personal applications. There is no longer a clean slate. > > Way too much of this discussion ignores this. If IPv6 PI space isn't > available, is more difficult to get, or there are more hoops to jump > through, there will be no IPv6, as we know now it. Statements like that tell me that we are still thinking in IPv4 terms. This is precisely why this discussion is happening, because we _need_ to think in non-IPv4 terms. If we are constrained by how things work in the IPv4 world then you are correct. However, if we are constrained by how things work in the IPv4 world then IPv6 will not be worth much anyway. Alec From owen at delong.com Thu Feb 9 16:12:29 2006 From: owen at delong.com (Owen DeLong) Date: Thu, 09 Feb 2006 13:12:29 -0800 Subject: [ppml] Principles for IPv6 PI allocations to end sites In-Reply-To: References: Message-ID: <959859B51C1005BB7B13F21A@dhcp64-134-112-117.stone.dal.wayport.net> --On February 9, 2006 3:04:13 PM -0500 Edward Lewis wrote: > I wish I had an answer. (I knew that when I spoke up.) > > But seriously, the drive to want provider independent space is a > reaction to not be willing to rely on a single ISP. I'll go further > out the limb and say "not willing to rely on a single ISP to be > reliable." > WHile that's a technically accurate summary it is also misleading. Specifically, there are many forms of that problem which have distinct characteristics: + ISP does not reliably deliver traffic + ISP goes out of business + ISP stops performing well + ISP raises fees beyond what is competitive/reasonable etc. The bottom line is that no sane enterprise (or even small business with a significant dependence on internet for it's business) would accept being locked into a single provider. Sure, lots of people have grudgingly accepted this in IPv4 to a certain extent. However, wholesale expansion of this error into a new protocol (IPv6) is not the right answer. > If I'm worried about reaching the largest audience, then all I want > is a global transit provider with fat pipes. Unlike placing a mall > at the cross roads to attract more vehicle traffic, placement of > servers isn't so sensitive to diverse topology. (Fewer hops yes, but > 30 T-1's are not better than a single T-3, other things being equal.) > Well... A global transit provider which will: + Never raise its prices + Reliably lower its prices as economics change + Never go down + Never misroute packets + Never do stupid things because of bogus billing disputes + Never go out of business + etc. > I think back to the April 2001 ARIN meeting (in SF) which happened > right after an ISP suddenly went belly up and folks went scrambling > for a new provider. > > I mention that because that is why I think provider independent space > is an important topic - of course I may be wrong which is why I'm > laying my cards on the table. > I completely agree. 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 owen at delong.com Thu Feb 9 16:16:11 2006 From: owen at delong.com (Owen DeLong) Date: Thu, 09 Feb 2006 13:16:11 -0800 Subject: [ppml] alternative to 2005-1 In-Reply-To: <2ED4AF46-7327-4850-BD14-1E1B148AD4F1@virtualized.org> References: <200602091745.k19HjQIH026277@rotala.raleigh.ibm.com> <2ED4AF46-7327-4850-BD14-1E1B148AD4F1@virtualized.org> Message-ID: > One of the arguments back in IPng days was that one of the benefits > of IPng would be we'd be able to start with a clean slate in terms of > routing and all the historical mistakes made with IPv4 wouldn't be > repeated. > And yet we turned right around and repeated the mistake of integrating the route locator and end system identifier into the same number and propogated the mistake of requiring every prefix to be visible in nearly every routing table in the DFZ(s). The fact that some of us are interested in crafting address policy that is fair to the end users instead of optimized to work-around these mistakes better than we did in IPv4 could be viewed as an effort at improvement. 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 packetgrrl at gmail.com Thu Feb 9 16:23:16 2006 From: packetgrrl at gmail.com (cja@daydream.com) Date: Thu, 9 Feb 2006 14:23:16 -0700 Subject: [ppml] alternative to 2005-1 In-Reply-To: References: <20060209165517.11227.qmail@hoster908.com> Message-ID: Steve, It is different because when the block is out of someone's PA space then it's still announced as part of an aggregate even if the specific /48 is filtered. So sure.. this site will announce the more specific and it will take up a "routing slot" but if the tables are too big for an ISP to carry it can filter and just accept the aggregate and still be able to reach that endsite. I hope this doesn't intend to disallow site multihoming with PA space. ---Cathy On 2/9/06, Steve Feldman wrote: > > I'm somewhat confused by this discussion: > > Is the intent to also disallow site multihoming using PA space? > > If I can obtain a /48 from one provider, and also announce it > through one or more other providers, doesn't it use that same > "routing slot" a PI assignment would use? If so, then why > is this better than a PI assignment? > > If I can't do that, then it effectively prevents me from > multihoming at all, which prevents me from using IPv6 in > any meaningful way. > > Steve > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > -------------- next part -------------- An HTML attachment was scrubbed... URL: From George.Kuzmowycz at aipso.com Thu Feb 9 16:49:28 2006 From: George.Kuzmowycz at aipso.com (George Kuzmowycz) Date: Thu, 09 Feb 2006 16:49:28 -0500 Subject: [ppml] alternative to 2005-1 Message-ID: >>> "Andrew Dul" 02/09/2006 3:35:37 PM >>> > -------Original Message------- > From: Thomas Narten > > Heck, even if we set a threshold of /16, we'd be saying "anyone who > can justify a class B assignment". I suspect that the number of end > sites meeting that criteria is pretty large. > > I'd feel a lot more comfortable picking a threshold if I had a rough > idea of how many entities we're talking about who would qualify. Given > the above, even /19 sounds too low. > The proposed policy as written requires an org who requests an allocation to be an ARIN member for at least 1 year. >>> What justification is there for such a requirement that, when you parse it, doesn't end up sounding like restraint of trade? What organization do I have to be a member of to bid on RF spectrum with the FCC? From George.Kuzmowycz at aipso.com Thu Feb 9 16:54:46 2006 From: George.Kuzmowycz at aipso.com (George Kuzmowycz) Date: Thu, 09 Feb 2006 16:54:46 -0500 Subject: [ppml] Principles for IPv6 PI allocations to end sites Message-ID: >>> Owen DeLong 02/09/2006 4:12:29 PM >>> --On February 9, 2006 3:04:13 PM -0500 Edward Lewis wrote: > I wish I had an answer. (I knew that when I spoke up.) > > But seriously, the drive to want provider independent space is a > reaction to not be willing to rely on a single ISP. I'll go further > out the limb and say "not willing to rely on a single ISP to be > reliable." > [SNIP] The bottom line is that no sane enterprise (or even small business with a significant dependence on internet for it's business) would accept being locked into a single provider. >>> The argument I tried to make last week, before I went out of e-mail range, is that from the enterprise perspective it is no longer a question of "would accept"; in today's business regulatory environment enterprises which rely on Internet connectivity for some portion of their business _are not permitted_ to accept this condition. From randy at psg.com Thu Feb 9 17:03:45 2006 From: randy at psg.com (Randy Bush) Date: Thu, 09 Feb 2006 12:03:45 -1000 Subject: [ppml] Principles for IPv6 PI allocations to end sites In-Reply-To: References: Message-ID: <43EBBC41.20703@psg.com> > The bottom line is that no sane enterprise (or even small business with > a significant dependence on internet for it's business) would accept > being locked into a single provider. which explains why no one does this today? or are most current enterprises insane? i always wondered. randy From andrew.dul at quark.net Thu Feb 9 17:43:43 2006 From: andrew.dul at quark.net (=?iso-8859-1?Q?Andrew=20Dul?=) Date: Thu, 09 Feb 2006 22:43:43 +0000 Subject: [ppml] alternative to 2005-1 Message-ID: <20060209224343.30592.qmail@hoster908.com> > -------Original Message------- > From: Andrew Dul > Subject: Re: [ppml] alternative to 2005-1 > Sent: 09 Feb '06 12:35 > > > -------Original Message------- > > From: Thomas Narten > > > > Heck, even if we set a threshold of /16, we'd be saying "anyone who > > can justify a class B assignment". I suspect that the number of end > > sites meeting that criteria is pretty large. > > > > I'd feel a lot more comfortable picking a threshold if I had a rough > > idea of how many entities we're talking about who would qualify. Given > > the above, even /19 sounds too low. > > > > The proposed policy as written requires an org who requests an allocation to be an > ARIN member for at least 1 year. According to ARIN's website there are currently > 2371 members. As a worst case under this policy only ~2k PI blocks > could be > issued in the next 12 months. That seems like a pretty slow start to me. My understanding of the membership standings appear not be correct. Only ISP/LIR IPv4 subscribers automatically become ARIN members. My understanding was that all direct assignment holders automatically became members. I can drop this requirement from the proposed policy. Andrew From sleibrand at internap.com Thu Feb 9 18:14:54 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Thu, 9 Feb 2006 18:14:54 -0500 (EST) Subject: [ppml] Proposed Policy: MicroAllocations for Internal Infrastructure In-Reply-To: <43EB5CDA.9060705@arin.net> References: <43EB5CDA.9060705@arin.net> Message-ID: This seems like a reasonable IPv6 MicroAllocation policy. If we're going to replace the "/24 using IPv4 or a /48 using IPv6" language of section 6.10 with the text below, IMO we should also modify section 4.4 to remove the "/48 using IPv6" language and instead refer users to 6.10 for the IPv6 MicroAllocation policy. Aside from that quibble, I currently support the policy proposal as written. -Scott On 02/09/06 at 10:16am -0500, Member Services wrote: > ARIN received the following proposed policy. In accordance with the ARIN > Internet Resource Policy Evaluation Process, the proposal is being > posted to the ARIN Public Policy Mailing List and being placed on ARIN's > website. > > The ARIN Advisory Council (AC) will review the proposal and within ten > working days may decide to: > 1) Support the proposal as is, > 2) Work with the author to clarify, divide or combine one or more > policy proposals, or > 3) Not support the policy proposal. > > If the AC supports the proposal or reaches an agreement to work with the > author, then the proposal will be posted as a formal policy proposal to > the Public Policy Mailing List and it will be presented at the Public > Policy Meeting. If the AC does not support the proposal, then the author > may elect to use the petition process to advance the proposal. If the > author elects not to petition or the petition fails, then the proposed > policy 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: MicroAllocations for Internal Infrastructure > > Author: Jason Schiller, Chris Morrow, Heather Skanks, Greg Stilwell, Beth Vu > > Proposal type: modify > > Policy term: permanent > > Policy statement: > > To replace section 6.10 > > 6.10 Micro-allocation > > ARIN will make micro-allocations for critical infrastructure, and the > RIRs and IANA as defined in the sub-sections below. These allocations > will be no longer (more specific) than a IPv6 /48. Multiple allocations > may be granted in certain situations. Micro-allocations MUST be provided > from a specific range of addresses. ARIN will make a list of these > blocks publicly available. ISPs and other organizations receiving these > micro-allocations will be charged under the ISP fee schedule, while > end-users will be charged under the fee schedule for end-users. This > policy does not preclude organizations from requesting address space > under other policies. > > 6.10.1 Micro-allocation for public exchange points Public Internet > exchange point operators must provide justification for the > micro-allocation, including: connection policy, location, other > participants (minimum of two total), ASN, and contact information. > > Exchange point allocations MUST be allocated from specific blocks > reserved only for this purpose. > > 6.10.2 Micro-allocation for core DNS service providers Core DNS service > providers (e.g. ICANN-sanctioned root, gTLD, and ccTLD operators) must > provide justification for the micro-allocation, including: name of core > DNS server, location, ASN, and contact information. > > Core DNS server allocations MUST be allocated from the micro-allocation > block. This block must be separate from the exchange point > micro-allocation block and the internal infrastructure micro-allocation > block. > > 6.10.3 Micro-allocation for internal infrastructure Organizations that > currently hold IPv6 allocations may apply for a micro-allocation for > internal infrastructure. Applicant must provide justification > indicating why a separate non-routed block is required. > Justification must include why a sub-allocation of currently held IP > space cannot be utilized. > > Internal infrastructure allocations MUST NOT be routed on global Internet. > > Internal infrastructure allocations MUST be allocated from specific > blocks reserved only for this purpose. > > Rationale: > > Organizations that have only a single aggregate may require > additional noncontiguous IP space for their internal infrastructure. > This space should not be routed in the global Internet routing table. > This will provide for the protection of internal infrastructure and > support for applications that are sensitive to long convergence times > like VoIP. > It is important to note that the additional prefix allocation will not > negatively impact the global routing table size as the additional prefix > should not be routed. > > > BGP Re-Convergence > ------------------ > > ISPs use BGP to originate their aggregate from multiple nodes within > their infrastructure. They do this by routing their aggregate to > discard on multiple devices. This ensures the Internet can reach the > aggregate even when one or more nodes fail. > > > If the next hop for a route is reachable via an aggregate that is in the > routing table, then failures affecting the reachability of the next hop > are subject to BGP hold timers, which can cause traffic to be dropped > for the length of the bgp hold time > > (typically 3 minutes) > > The BGP re-convergence problem results when a multi-homed customer is > announcing the same route to two different edge routers. When the edge > router sourcing the primary path fails, the local address which is > acting as the next hop, is removed from the IGP. If the next hop is > still reachable through an aggregate or covering route, then the route > will not be immediately invalidated in bgp. Until the bgp session with > the failed device times out, traffic will be drawn to the device > originating the aggregate, which is routed to discard and traffic will > be dropped. After the bgp session with the failed device times out, the > route will be removed and the next best route will be used. To minimize > route failover time, you must ensure that the local addresses of the > infrastructure, that act as next-hops for Internet routes, are NOT > numbered with addresses that are a more specific than the aggregate. > > A detailed description of the problem space follows in the next three > paragraphs. > > Having BGP next-hops that are not aggregated can cause faster > convergence for customers who have multiple links to multiple routers of > a single upstream AS. > Take the case where a customer has two connections, link1 to > edge-router1 and link2 to edge-router2, to a single upstream AS. The > customer has an eBGP session with the loopback 2001:DB8::1/128 on > edge-router1 and with loopback 2001:DB8::2/128 on edge-router2. The > customer advertises a single prefix 2001:DB8:1000::/48 to both > edge-router1 and edge-router2. The edge routers set next-hop self. The > upstream ISP will have two paths to the prefix 2001:DB8:1000::/48, one > with a protocol next-hop of 2001:DB8::1 and one with a protocol next-hop > of 2001:DB8::2. Assume the upstream ISP's entire network prefers the > path to 2001:DB8:1000::/48 with a protocol next-hop of 2001:DB8::1 due > to lower BGP MED value. Also assume that all of the address space owned > by the upstream ISP is 2001:DB8::/32, and the loopbacks of both edge > routers are a more specific of the aggregate /32. The upstream ISP has > a pull-up route for 2001:DB8::/32 in the core of the network. This > allows for the aggregation of all the more specific routes of > 2001:DB8::/32. It insures the stability of the 2001:DB8::/32 > announcement, while preventing an isolated edge router from advertising > reachability to the network. > > If edge-router1 fails then 2001:DB8::1/128 will be immediately removed > from the IGP. The preferred prefix for 2001:DB8:1000::/48 with a > next-hop of 2001:DB8::1 will remain a valid bgp route and will continue > to be the best path because 2001:DB8::1 is reachable through the pull-up > route 2001:DB8::/32. Traffic will get blackholed for up to three > minutes (BGP default hold time) until the BGP prefix 2001:DB8:1000::/48 > with a protocol next-hop of 2001:DB8::1 times out. Only then will > traffic get forwarded to the next best path for 2001:DB8:1000::/48 with > a protocol next-hop of 2001:DB8::2. > > If instead the loopbacks of the edge routers (or any BGP protocol > next-hop addresses) are not part of the 2001:DB8::/32 aggregate, and > there is no aggregate that covers the edge router loopbacks, then > convergence will be much quicker. Assume that edge-router1 is using > 2001:408::1 and edge-router2 is using 2001:408::2, and the only pull-up > route is 2001:DB8::/32. In this case once edge-router1 fails, the IGP > will detect it and remove 2001:408::1/128 from the IGP. This will > invalidate the preferred path to 201:DB8:1000::/48 with a protocol > next-hop of 2001:408:1 as there will be no route to the next hop (or > even a less specific of this address). Once the path is invalidated, > then the next best path to 2001:DB8:1000::/48 with a protocol next-hop > of 2001:408::2 will be declared best. Convergence times will be on the > order of magnitude of the IGP failure detection and path re-calculation, > typically less than one second. > > > --------------- > | Core Router |static route > | |2001:DB8::/32 discard > ----+------+--- > | | > / \ > /-------------/ \--------\ > / \ > / /----------------------------\ \ > | | | | > ------+---+-- --+---+------ > |Core Router|static route |Core Router|static route > | |2001:DB8::/32 discard | |2001:DB8::/32 discard > ---------+--- ---------+--- > | | > ---------+--------- ---------+--------- > | edge-router1 | | edge-router2 | > | 2001:DB8::1/128 | | 2001:DB8::2/128 | > ---------+--------- ---------+--------- > | | > \ link1 link2 / > \------------\ /----------/ > \ / > | | > ----+---------+---- > | CPE | > | | > ---------+--------- > | > LAN 2001:DB8:1000::/48 > > > Internal Infrastructure Security Considerations > ----------------------------------------------- > > Internal infrastructure could be numbered out of space that is not > routed or reachable by the public Internet. This could be used to > secure internal only services in a multi-layered approach by filtering > direct network connections in the forwarding plane, and not routing the > network in the global Internet routing table. Internal services which > could take advantage of these layers of protection include: SNMP > services, iBGP mesh, Out-of-Band management network(s), remote access to > the network devices that make up the network in question. A layered > security approach will help to prevent breaches in security via singular > config management problems. Additionally, having all of the services out > of an aggregate block will simplify the configuration management situation. > > In essence, this allows for a two tier approach of protecting > infrastructure, both in the control plane by not routing the network, > and in the forwarding plane by utilizing packet filters which are easily > constructed and managed due to the uniqueness of the internal > infrastructure block. > > > Private Address Considerations > ------------------------------ > > Private addresses are not appropriate for a number of reasons. A public > Internet network using private addresses internally may create confusion > if trace routes contain private addresses. Additional problems may > result due to wide spread filtering of private address space. ICMP > mesages may get dropped due to such a policy. This can lead to > precieved odd behavior and make troubleshooting difficult. > > Additionally, the consequences of accidentally routing private ip space > that is not globally unique, are potentially worse than if you > accidentally announced globally unique space. > > DNS for private address space is today provided by blackhole-1.iana.org. > and blackhole-2.iana.org. A provider who wants to maintain forward and > reverse DNS sanity has to hijack those ip addresses to provide > consistent DNS resolution. > This will cause any users who's traffic transits that provider's network > to also get 'inconsistent' answers with respect to the private address > space in question. > > For management and troubleshooting purposes, it is important that > infrastructure which provides Internet route reachability be numbered > with addresses that resolve through DNS. Also, global uniqueness of > addressing is important in minimizing renumbering efforts as > organizations (and their networks) merge. RFC 4193 provides for neither > of these needs. > > > Timetable for implementation: Immediate > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From memsvcs at arin.net Thu Feb 9 18:36:17 2006 From: memsvcs at arin.net (Member Services) Date: Thu, 09 Feb 2006 18:36:17 -0500 Subject: [ppml] Proposed Policy: Capturing Originations in Templates Message-ID: <43EBD1F1.6070806@arin.net> ARIN received the following proposed policy. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List and being placed on ARIN's website. The ARIN Advisory Council (AC) will review the proposal and within ten working days may decide to: 1) Support the proposal as is, 2) Work with the author to clarify, divide or combine one or more policy proposals, or 3) Not support the policy proposal. If the AC supports the proposal or reaches an agreement to work with the author, then the proposal will be posted as a formal policy proposal to the Public Policy Mailing List and it will be presented at the Public Policy Meeting. If the AC does not support the proposal, then the author may elect to use the petition process to advance the proposal. If the author elects not to petition or the petition fails, then the proposed policy 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: Capturing Originations in Templates Author: Sandra Murphy Proposal type: new Policy term: permanent Policy statement: ARIN will collect an optional field in all IPv4 and IPv6 address block transactions (allocation and assignment requests, reallocation and reassignment actions, transfer and experimental requests). This additional field will be used to record a list of the ASes that the user permits to originate address prefixes within the address block. ARIN will produce a collection of the mappings from address blocks to ASes permitted to originate that address block, The collection will consist of a list where each entry will consist, at a minimum, of an address block, a list of AS numbers, and a tag indicating the type of delegation of the address block. This collection will be produced at least daily. ARIN will make the collected mappings from address blocks to AS numbers available for bulk transfer in one or more formats chosen at its own discretion, informed by the community's current needs. This data will not be subject to any redistribution restrictions -- it may be republished or repackaged it any form. Should ARIN choose to use WHOIS bulk transfer as the bulk form of data access required by this paragraph, the address block to AS mappings will not be subject to any redistribution restrictions, but the remainder of the WHOIS data will remain subject to the terms of the then-current AUP regarding bulk access to WHOIS data. ARIN may also make the collected or individual mappings from address blocks to AS numbers available in other forms, possibly query services, chosen at its own discretion, informed by the community's current needs. ARIN may require agreement to an acceptable use policy for access to the data in these forms. Rationale: Origination of prefixes by ASes that have no authority for the origination is a recurring problem in the Internet routing system. A list of authorized prefix originations would be beneficial to operators in constructing routing filter lists to counter bogus originations, interacting with customers requesting routing of a prefix, and diagnosing routing problems. A list of authorized prefix originations is also the necessary first step for any known solution for securing the routing system. Prefix originations can be stored in routing registry RPSL route objects. However, the authority for addresses and for ASes belongs to the RIRs. There is presently no mechanism to translate ARIN's authority for number resources to an IRR. Furthermore, operators have been less than diligent in creating and maintaining route objects. Capturing the prefix origination authorization in number resource registrations with ARIN has two main goals: benefit from the scrutiny with which ARIN verifies initial requests and authenticates subsequent transactions, and inherit the operators' self-discipline in completing resource requests and transactions. As an additional benefit, this could take a step toward populating the IRR with data known to be accurate. The intended use of this data means that both query for individual entries and bulk access to a list of the collected entries, without restriction on redistribution, is required. This policy requires that the additional data be provided through the usual whois query service and some bulk access service that has no restrictions. It permits ARIN to provide the bulk access through the existing bulk whois service if the new additional data is not subject to the bulk whois AUP restrictions. The policy does not limit ARIN to providing only those two services (whois query and unrestricted bulk access); other additional services may be developed at ARIN's discretion. It is expected that entries in the list of collected entries will include at a minimum the present NetRange and NetType attributes, with a new attribute, perhaps named OriginatingASList, for the list of permitted originating ASes. This policy will presumably be incorporated into NPRM section 3.4. Timetable for implementation: Within sixty (60) days of approval. From Michael.Dillon at btradianz.com Fri Feb 10 05:03:47 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Fri, 10 Feb 2006 10:03:47 +0000 Subject: [ppml] alternative to 2005-1 In-Reply-To: <7.0.1.0.0.20060209125927.01b36348@renesys.com> Message-ID: > >Again, we are headed down a road that we have been on before. The last > >2005-1 was defeated because of this point - the bar was set too high. I can > >understand those who wish for no end-site multihoming. I can understand > >those who wish for end-site multihoming similar to IPv4. However, I can't > >understand going in circles, which is exactly what we are doing. > > This is deadlock again. I certainly do not consider a wide-ranging discussion to be DEADLOCK or GOING IN CIRCLES. This is not a union bargaining table. This is a discussion of possible ways in which we can craft an IPv6 PI policy. The discussion is not deadlocked at all. It has explored a number of different possibilities and, as is inevitable, sometimes the discussion goes down dead ends. This is a good thing because it helps people understand which possibilities need to be eliminated. This means that we are making good progress. I think it may help if the policy is written in such a way that we separate the requirements for IPv4 users from the requirements for non-IPv4 users. We seem to have general consensus that most end users who have an IPv4 PI block should be able to get an IPv6 one. The wording of that still needs some honing, but we do not need to worry so much about a landrush situation. On the other hand, if an end user has no IPv4 PI history, the possibility of a landrush exists and the policy language has to be tightened up a bit. IMHO, a good policy would deal with each case separately. --Michael Dillon From owen at delong.com Fri Feb 10 05:35:46 2006 From: owen at delong.com (Owen DeLong) Date: Fri, 10 Feb 2006 02:35:46 -0800 Subject: [ppml] Proposed Policy: Capturing Originations in Templates In-Reply-To: <43EBD1F1.6070806@arin.net> References: <43EBD1F1.6070806@arin.net> Message-ID: I oppose this policy... It represents a duplication of effort. There are already a number of routing registries (RADB, ARIN RR, etc.) which can be used to express such data in far greater detail and a more useful fashion. Please, let's not reinvent the wheel with a new inferior solution to an already solved problem. Owen --On February 9, 2006 6:36:17 PM -0500 Member Services wrote: > ARIN received the following proposed policy. In accordance with the ARIN > Internet Resource Policy Evaluation Process, the proposal is being > posted to the ARIN Public Policy Mailing List and being placed on ARIN's > website. > > The ARIN Advisory Council (AC) will review the proposal and within ten > working days may decide to: > 1) Support the proposal as is, > 2) Work with the author to clarify, divide or combine one or more > policy proposals, or > 3) Not support the policy proposal. > > If the AC supports the proposal or reaches an agreement to work with the > author, then the proposal will be posted as a formal policy proposal to > the Public Policy Mailing List and it will be presented at the Public > Policy Meeting. If the AC does not support the proposal, then the author > may elect to use the petition process to advance the proposal. If the > author elects not to petition or the petition fails, then the proposed > policy 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: Capturing Originations in Templates > > Author: Sandra Murphy > > Proposal type: new > > Policy term: permanent > > Policy statement: > > ARIN will collect an optional field in all IPv4 and IPv6 address block > transactions (allocation and assignment requests, reallocation and > reassignment actions, transfer and experimental requests). This > additional field will be used to record a list of the ASes that the user > permits to originate address prefixes within the address block. > > ARIN will produce a collection of the mappings from address blocks to > ASes permitted to originate that address block, The collection will > consist of a list where each entry will consist, at a minimum, of > an address block, a list of AS numbers, and a tag indicating the type of > delegation of the address block. This collection will be produced at > least daily. > > ARIN will make the collected mappings from address blocks to AS numbers > available for bulk transfer in one or more formats chosen at its own > discretion, informed by the community's current needs. This data will > not be subject to any redistribution restrictions -- it may be > republished or repackaged it any form. Should ARIN choose to use WHOIS > bulk transfer as the bulk form of data access required by this > paragraph, the address block to AS mappings will not be subject to any > redistribution restrictions, but the remainder of the WHOIS data will > remain subject to the terms of the then-current AUP regarding bulk > access to WHOIS data. > > ARIN may also make the collected or individual mappings from address > blocks to AS numbers available in other forms, possibly query > services, chosen at its own discretion, informed by the community's > current needs. ARIN may require agreement to an acceptable use policy > for access to the data in these forms. > > Rationale: > > Origination of prefixes by ASes that have no authority for the > origination is a recurring problem in the Internet routing system. A > list of authorized prefix originations would be beneficial to operators in > constructing routing filter lists to counter bogus > originations, > interacting with customers requesting routing of a prefix, and > diagnosing routing problems. > > A list of authorized prefix originations is also the necessary first > step for any known solution for securing the routing system. > > Prefix originations can be stored in routing registry RPSL route > objects. However, the authority for addresses and for ASes belongs to > the RIRs. There is presently no mechanism to translate ARIN's authority > for number resources to an IRR. Furthermore, operators have been less > than diligent in creating and maintaining route objects. Capturing the > prefix origination authorization in number resource registrations with > ARIN has two main goals: > benefit from the scrutiny with which ARIN verifies initial > requests and authenticates subsequent transactions, and > inherit the operators' self-discipline in completing resource > requests and transactions. > As an additional benefit, this could take a step toward populating the > IRR with data known to be accurate. > > The intended use of this data means that both query for individual > entries and bulk access to a list of the collected entries, without > restriction on redistribution, is required. This policy requires that > the additional data be provided through the usual whois query service > and some bulk access service that has no restrictions. It permits ARIN > to provide the bulk access through the existing bulk whois service if > the new additional data is not subject to the bulk whois AUP > restrictions. The policy does not limit ARIN to providing only those > two services (whois query and unrestricted bulk access); other > additional services may be developed at ARIN's discretion. > > It is expected that entries in the list of collected entries will > include at a minimum the present NetRange and NetType attributes, with a > new attribute, perhaps named OriginatingASList, for the list of > permitted originating ASes. > > This policy will presumably be incorporated into NPRM section 3.4. > > Timetable for implementation: Within sixty (60) days of approval. > > > _______________________________________________ > 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 Feb 10 05:47:23 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Fri, 10 Feb 2006 10:47:23 +0000 Subject: [ppml] Proposed Policy: Capturing Originations in Templates In-Reply-To: Message-ID: > I oppose this policy... It represents a duplication of effort. There are > already > a number of routing registries (RADB, ARIN RR, etc.) which can be used to > express such data in far greater detail and a more useful fashion. Please, > let's not reinvent the wheel with a new inferior solution to an already > solved problem. One could argue that existing routing registries suffer from a stale data problem due to the fact that there is not an authoritative source of the data. If ARIN would operate a routing registry, they have the potential of solving the stale data problem. I wonder why the policy doesn't just say that ARIN will operate a routing registry and, for each allocated or assigned address block, collect the list of the ASes that the block owner permits to originate address prefixes within the address block. It would make for simpler wording and achieve much the same ends. It would not be duplication of effort any more than it is duplication of effort for ARIN to operate DNS servers containing in-addr.arpa delegations. After all, every ARIN member already operates a DNS server so why does ARIN duplicate the effort instead of publishing a BIND zone file on their website? --Michael Dillon From owen at delong.com Fri Feb 10 05:54:22 2006 From: owen at delong.com (Owen DeLong) Date: Fri, 10 Feb 2006 02:54:22 -0800 Subject: [ppml] Proposed Policy: Capturing Originations in Templates In-Reply-To: References: Message-ID: <62E1A4461A686AE061D3586D@dhcp64-134-112-117.stone.dal.wayport.net> --On February 10, 2006 10:47:23 AM +0000 Michael.Dillon at btradianz.com wrote: >> I oppose this policy... It represents a duplication of effort. There > are >> already >> a number of routing registries (RADB, ARIN RR, etc.) which can be used > to >> express such data in far greater detail and a more useful fashion. > Please, >> let's not reinvent the wheel with a new inferior solution to an already >> solved problem. > > One could argue that existing routing registries suffer > from a stale data problem due to the fact that there is > not an authoritative source of the data. If ARIN would > operate a routing registry, they have the potential of > solving the stale data problem. > Since the policy makes this data optional in any assignment, this data in ARINs database would have a similar issue, no? > I wonder why the policy doesn't just say that ARIN > will operate a routing registry and, for each allocated > or assigned address block, collect the list of the ASes that > the block owner permits to originate address prefixes > within the address block. > ARIN already operates a routing registry, but, registration in an RR requires more data than simply a list of valid origins. This is both good and bad. It's good in that the data in the RR is specific enough that it can actually be used to build real ACLs and configuration statements for routers. It's bad in that it breeds a certain amount of complexity. It's good in that it provides syntax for specifying which AS can originate which prefix rather than just a list of ASs each of which is allowed to originate some unknown subset of a given prefix. > It would make for simpler wording and achieve much the > same ends. > I'm still not seeing that this buys us anything we don't already have, except yet another place for this data to be poorly maintained. > It would not be duplication of effort any more > than it is duplication of effort for ARIN to operate > DNS servers containing in-addr.arpa delegations. After > all, every ARIN member already operates a DNS server so > why does ARIN duplicate the effort instead of publishing > a BIND zone file on their website? > Huh? This made no sense to me. ARIN's DNS servers participate at a different level of the hierarchy than the ARIN resource recipients (not limited to members). Those delegations are not a duplication of effort, they are a required part of the database structure. Since there is no correct way to translate the data being proposed to be collected into RPSL (at least not with accurate results), I don't see it being placed in the RR by any automatic process from the template. 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 ppml at rs.seastrom.com Fri Feb 10 07:23:00 2006 From: ppml at rs.seastrom.com (Robert E.Seastrom) Date: Fri, 10 Feb 2006 07:23:00 -0500 Subject: [ppml] alternative to 2005-1 In-Reply-To: (Alec H. Peterson's message of "Thu, 9 Feb 2006 14:04:03 -0700") References: Message-ID: <87vevnflnf.fsf@valhalla.seastrom.com> "Alec H. Peterson" writes: >> Way too much of this discussion ignores this. If IPv6 PI space isn't >> available, is more difficult to get, or there are more hoops to jump >> through, there will be no IPv6, as we know now it. > > Statements like that tell me that we are still thinking in IPv4 > terms. This is precisely why this discussion is happening, because > we _need_ to think in non-IPv4 terms. If we are constrained by how > things work in the IPv4 world then you are correct. However, if we > are constrained by how things work in the IPv4 world then IPv6 will > not be worth much anyway. We *are* thinking in non-IPv4 terms. In the site multihoming arena, we have devolved from thinking in IPv4 terms of "rough consensus and working code" to thinking in OSI terms, where it is perfectly acceptable to block implementation of a known-working-but-flawed mechanism in favor of a paper design, or worse, a yet-to-be-conceived design. Unless we break this trend, I agree with Dan, we can forget about IPv6. ---Rob From iggy at merit.edu Fri Feb 10 09:28:55 2006 From: iggy at merit.edu (Glenn Wiltse) Date: Fri, 10 Feb 2006 09:28:55 -0500 (EST) Subject: [ppml] Comments on revised 2005-1 proposal of 2006-02-03 In-Reply-To: <0DEE9AF372810493550E1E88@dhcp64-134-112-117.stone.dal.wayport.net> References: <0DEE9AF372810493550E1E88@dhcp64-134-112-117.stone.dal.wayport.net> Message-ID: If every sane end user that depends on the internet should need to have PI space, then it would seem that there is a very good chance that every sane user of the internet today will demand PI space soon anywy. So how about we just given any originzation that asks for it a /48 direct from ARIN. After all it's going to be prohibitively painfull when they go from Provider IPv6 space to PI IPv6 space right? Under this likelyhood we might as well also stop giving /32s to LIR/ISPs, because noone will be using space from ISPs, etc... (I hope you detected the sarcasim in that first paragraph) My reasoning for suggeting that only large 'end orginizations' should currently be elidable for PI space... My posistion is that ARIN should NOT give any PI space to any originzation that has a single physical site at this time. Given the difficulty in renumbering is even greater if an orginzation could have large numbers of /48s, I belive we should make provisions for very large orginzations to obtain PI space at this time. The reason I think these large originzations should qualify and smaller ones should not, is simply because it's going to be much more risky for these large orginzations to put for the effort to go to IPv6. So, it's my feeling that any originzation that can that show they would be able to obtain signficant numbers of /48s under current policy (by getting them from LIR/ISPs all over the ARIN region), should be able to go direct to ARIN and obtain enough space in a single contigious block, to suit all of their individual /48 needs. I'm thinking of orginizations like perhaps WalMart, Kmart/Sears, Ford, GM, Toyta, Honda, Starbucks, McDonalds, Wendys, Tim Hortons(for all you Canadians out there), etc... where if each individual location of these companys got a /48 from some local ISP, the company as a whole, would infact be eligible to obtain significant numbers of /48s under current policy. I beleive originzations like these that wish to move to IPv6 at this time, should be able to get direct PI assignments from ARIN. Part of the reason I think these large companys should be given a early advantage over small companys, is simply because if some of these big companys never move to IPv6 then there's a good chance that IPv6 will never get widely used in the ARIN region. Where I'm not convinced that Glenn's corner store in my hometown USA, should be able to get any PI space at this time. Glenn Wiltse On Thu, 9 Feb 2006, Owen DeLong wrote: > I thought the original argument against opening up PI was to avoid creating > an early adopter advantage. Why is it better to give large organizations > first crack at an early adopter advantage and then later consider whether > or not to treat the rest as second class citizens? I see that as being > even worse than the small risk of an early adopter advantage. > > Frankly, I think that realistically, the following are true: > > 1. We need a new IDR paradigm that allows for a separation between > the routing locator and the end system identifier (ASN and IP > address are most likely mappings for RL and ESI in the near > term, but, today, we are using IP address for both). > > 2. By continuing to treat organizations below some arbitrary > threshold as second class citizens on the internet, we _MAY_ > be able to postpone the date when the new routing paradigm > mentioned in 1 is required. > > 3. Even if we gave v6 PI blocks to everyone who could justify > them under the most liberal of these policies, I believe it > would be at least 10 years before we had to truly worry > about router meltdown due to table size. That should be > more than adequate time for IETF to develop a solution. > (I believe I have good beginnings of a solution. Let me > know if you are interested in more detail). > > 4. I believe a solution is possible which requires: > > 1. code changes on core routers. > 2. code changes on DFZ Edge routers. > 3. Additional CPU on DFZ Edge routers (potentially) > 4. Suggests crypto acceleration on DFZ Edge routers > 5. Does not require modifications to non-DFZ routers > 6. Limits the size of the global routing table to the > list of viable AS Paths. > 7. Allows leaf sites to multihome with a single PI block > and no AS, thus not increasing the routing table > slots in the DFZ. > > 5. Since the above solution does not require edge router updates, > and most DFZ routers see software updates more than once per > year and hardware replacement usually on approx. a 3 year > cycle, and, this doesn't require hardware changes (although > some are recommended), 10 years gives the IETF 7 years > to argue, code, test, agree, and publish and we still have > plenty of time for the vendors to add it to the featureset > and roll it out to end users. I agree that expecting IETF > to agree on anything in 7 years may be a bit optimistic, > but, I think it can be done. > > Finally, we need PI space for end sites/users/organizations/whetever term > you prefer precisely because IPv6 did not solve multihoming. The lack > of a multihoming solution in IPv6 makes it a non-starter for most > organizations. Lack of PI space will have a similar effect for other > reasons besides multhoming. Renumbering a /48 can be prohibitively > painful and costly, especially when it involves ACLs and pointers > that are maintained in foreign authority zones (customers VPN ACLs, > etc.). Locking businesses into a particular provider just because > we're too lazy to fix the protocol is no longer an option. > > Owen > > Owen > > > --On February 9, 2006 9:33:44 AM -0500 Glenn Wiltse wrote: > >> I wasn't nessasarly endorsing any 'host count' as being the >> defining factor. However I do think the main point of contention >> is how exactly to determin some size threshold nessasary, and what >> to use as a unit of meassure. That's why I personaly like >> the idea of using unique street addresss. >> >> One thing I don't like, and I think many others don't like, is the >> idea that ARIN would hand out many /48s simply because some orginzations >> felt they had to have PI space and/or they are currently multi homed. >> >> Maybe later, after some of the biggest end originzations have gotten >> PI space, and we know where we stand in terms of demand and/or needs, we >> could possibly later relax the size limits and/or then start to give out >> smaller block, etc... >> >> Glenn Wiltse >> >> On Thu, 9 Feb 2006, Dan Golding wrote: >> >>> On 2/9/06 8:28 AM, "Glenn Wiltse" wrote: >>> >>>> In general, I like the direction Thomas is heading in... (giving >>>> PI to the largest sites and trying not to give out small blocks simply >>>> because someone says they need multi homing, etc...) >>>> >>>> I would change refferances to 'end site', in favor of the term 'end >>>> orginization' (which would imply these cant' be re-assigned to other >>>> orginizations, but little else implyed in the meaning) >>>> >>>> In my mind, the only real sticky point is in deciding what exactly >>>> defines a originization as being 'large' enough to get a PI assignment. >>>> >>>> I do think that a /40 is about the smallest sized block that I would >>>> like to see given out as IPv6 PI space at this time. Just how you >>>> define who is large enough to justify such a assignment I do not know. >>>> >>>> I personaly would rather see unique street addresses be considered >>>> as justification for space, more so then number of employees... but >>>> perhaps either or... or some combination of both, etc... >>>> >>>> Anyway, I do really think Thomas is on the right track with his >>>> most recent comments and/or proposal. >>>> >>>> Glenn Wiltse >>> >>> This is a dead end. The last 2005-1 was defeated at the last ARIN meeting >>> specifically because of the 100k host requirement. >>> >>> - Daniel Golding >>> >>> >>> >>> >>> !DSPAM:43eb4f0186132993215505! >>> >>> >> _______________________________________________ >> 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. > From stephen at sprunk.org Fri Feb 10 09:52:21 2006 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 10 Feb 2006 08:52:21 -0600 Subject: [ppml] Comments on revised 2005-1 proposal of 2006-02-03 References: <200602082209.k18M9L9t013516@cichlid.raleigh.ibm.com> Message-ID: <053f01c62e51$a4000050$feac1cac@ssprunk> Thus spake "Thomas Narten" > I have a hard time supporting giving owners of "legacy" IPv4 > registrations automatic IPv6 space. This just perpetuates the "early > adopter" program (e.g., those that got big assignments prior to the > the RIRs, get similar treatment in IPv6). I would normally agree with this, but there are folks with legacy PI assignments that cannot qualify for a _new_ PI block from the RIRs. >> 3) Be currently multihomed using IPv6 connectivity to two >> or more separate ARIN LIR's using at least one /48 assigned >> to them by each LIR. > > IMO, being multihomed in IPv4 should also be sufficient justification. > One argument I keep hearing is that "we're assigning PI space in IPv4 > for multihoming, and the system is working". So let's try and leverage > that experience. That'll create a land rush for sure, as everyone who currently has a v4 block comes running for their v6 block _without actually deploying v6_. Part of this policy is to accelerate the actual deployment of v6 in the ARIN region, not just hand out space to orgs. > I suspect that /48 is too small, if we are aiming at the biggest end > sites. E.g., take sites that have O(100K) subnets. According the HD > ratio thresholds, that would correspond to (I think) a /44. > > One thing that I would find helpful is if there is any data available > concerning sizes of organizations (in terms of > networks/devices/users). How many organizations have 100K subnets? Is > that number small enough that we can use it as a threshhold to give > everyone with 100K subnets a PI assignment? I've worked with a large fraction of the Fortune 50, and few have a need for O(100k) subnets. For those that have a justifiable need for more than a /48, the proposal allows that. > Although the following is far from perfect, using number of employees > might be attractive in that it is information that is often publically > available, and gives a very rough indication of number of machines > (assume some multiple of machines/subnets per employee). But I recall > from previous discussions, people preferred more relevant criteria > like numbers of subnets. The number of employees is even less relevant, IMHO, than the number of physical locations. >> 6.5.8.3. Subsequent Assignment Size > >> Additional assignments may be made when the need for additional >> subnets is justified. When possible assignments will be made >> from an adjacent address block. > > Perhaps specifically tie this back to the the HD ratio. I have no argument with a HD ration tie-in, but then we'd need some debate on what the correct ratio is. I don't think the number for ISPs is necessarily correct for end sites. > So, here is a revised strawman based on the comments above: > > Add new subsection in section 6.5 of the NRPM: > > 6.5.8. Direct assignments to large end sites > > 6.5.8.1. To qualify for a direct assignment, an organization > must: > > a) not be an IPv6 LIR; > > b) meet all of the following requirements: > > 1) Qualify for an IPv4 direct assignment from ARIN under the > IPv4 policy currently in effect [specifically, Section > 4.3, excluding microassignments. Note also that this means > end site must qualify for a /22 if multihoming. Is this > bar high enough?]. > > 2) Be currently multihomed using IPv4 or IPv6 as defined in > "ARIN Number Resource Policy Manual Version 2005.1 - > September 7, 2005" You don't need to call out the reference, since it's obvious. > 6.5.8.2. Direct assignment size to large end sites > > Organizations that meet the direct end site assignment > criteria given in Section 6.5.8.1 are eligible to receive a > direct assignment. The minimum size of the assignment is a > /40. Larger assignments will be made when justified using the > existing IPv6 applied HD ratio as given in Section 6.5. Whoa, now you're saying all end sites deserve at least a /40? Or is that a typo? > Assignments will be made out of a specially designated > address block that indicates a direct assignment to an > endsite. > > 6.5.8.3. Subsequent Assignment Size > > An organization may receive an additional assignment when it > has grown to include enough distinct physical locations to > justify the larger assignment. Where possible, the assignment > will be made from an adjacent address block. Now only growth in the number of physical locations justifies additional assignments? There may be other legitimate reasons for an org to come back for more addresses. > So, what do people think of the above? An improvement? Still some > unacceptable points? I think it's a step backwards; objections noted above. > Questions relating to above: > > 1) How many direct /22 IPv4 assignments have been made to date? That > is, how many organizations do we think would qualify? Are we > talking a few thousand? tens of thousands? or? Well, right off the bat I'd say it's on the order of the number of assigned ASNs. How many new folks will go get an ASN to take advantage of this policy is up for debate... S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin From tme at multicasttech.com Fri Feb 10 10:11:47 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Fri, 10 Feb 2006 10:11:47 -0500 Subject: [ppml] Comments on revised 2005-1 proposal of 2006-02-03 In-Reply-To: <053f01c62e51$a4000050$feac1cac@ssprunk> References: <200602082209.k18M9L9t013516@cichlid.raleigh.ibm.com> <053f01c62e51$a4000050$feac1cac@ssprunk> Message-ID: On Feb 10, 2006, at 9:52 AM, Stephen Sprunk wrote: > Thus spake "Thomas Narten" >> I have a hard time supporting giving owners of "legacy" IPv4 >> registrations automatic IPv6 space. This just perpetuates the "early >> adopter" program (e.g., those that got big assignments prior to the >> the RIRs, get similar treatment in IPv6). > > I would normally agree with this, but there are folks with legacy PI > assignments that cannot qualify for a _new_ PI block from the RIRs. > >>> 3) Be currently multihomed using IPv6 connectivity to two >>> or more separate ARIN LIR's using at least one /48 >>> assigned >>> to them by each LIR. >> >> IMO, being multihomed in IPv4 should also be sufficient >> justification. >> One argument I keep hearing is that "we're assigning PI space in IPv4 >> for multihoming, and the system is working". So let's try and >> leverage >> that experience. > > That'll create a land rush for sure, as everyone who currently has > a v4 > block comes running for their v6 block _without actually deploying > v6_. > Part of this policy is to accelerate the actual deployment of v6 in > the ARIN > region, not just hand out space to orgs. > >> I suspect that /48 is too small, if we are aiming at the biggest end >> sites. E.g., take sites that have O(100K) subnets. According the HD >> ratio thresholds, that would correspond to (I think) a /44. >> >> One thing that I would find helpful is if there is any data available >> concerning sizes of organizations (in terms of >> networks/devices/users). How many organizations have 100K subnets? Is >> that number small enough that we can use it as a threshhold to give >> everyone with 100K subnets a PI assignment? > > I've worked with a large fraction of the Fortune 50, and few have a > need for > O(100k) subnets. For those that have a justifiable need for more > than a > /48, the proposal allows that. > >> Although the following is far from perfect, using number of employees >> might be attractive in that it is information that is often >> publically >> available, and gives a very rough indication of number of machines >> (assume some multiple of machines/subnets per employee). But I recall >> from previous discussions, people preferred more relevant criteria >> like numbers of subnets. > > The number of employees is even less relevant, IMHO, than the > number of > physical locations. > >>> 6.5.8.3. Subsequent Assignment Size >> >>> Additional assignments may be made when the need for >>> additional >>> subnets is justified. When possible assignments will be >>> made >>> from an adjacent address block. >> >> Perhaps specifically tie this back to the the HD ratio. > > I have no argument with a HD ration tie-in, but then we'd need some > debate > on what the correct ratio is. I don't think the number for ISPs is > necessarily correct for end sites. > >> So, here is a revised strawman based on the comments above: >> >> Add new subsection in section 6.5 of the NRPM: >> >> 6.5.8. Direct assignments to large end sites >> >> 6.5.8.1. To qualify for a direct assignment, an organization >> must: >> >> a) not be an IPv6 LIR; >> >> b) meet all of the following requirements: >> >> 1) Qualify for an IPv4 direct assignment from ARIN under the >> IPv4 policy currently in effect [specifically, Section >> 4.3, excluding microassignments. Note also that this means >> end site must qualify for a /22 if multihoming. Is this >> bar high enough?]. >> >> 2) Be currently multihomed using IPv4 or IPv6 as defined in >> "ARIN Number Resource Policy Manual Version 2005.1 - >> September 7, 2005" > > You don't need to call out the reference, since it's obvious. > >> 6.5.8.2. Direct assignment size to large end sites >> >> Organizations that meet the direct end site assignment >> criteria given in Section 6.5.8.1 are eligible to receive a >> direct assignment. The minimum size of the assignment is a >> /40. Larger assignments will be made when justified using the >> existing IPv6 applied HD ratio as given in Section 6.5. > > Whoa, now you're saying all end sites deserve at least a /40? Or > is that a > typo? > >> Assignments will be made out of a specially designated >> address block that indicates a direct assignment to an >> endsite. >> >> 6.5.8.3. Subsequent Assignment Size >> >> An organization may receive an additional assignment when it >> has grown to include enough distinct physical locations to >> justify the larger assignment. Where possible, the assignment >> will be made from an adjacent address block. > > Now only growth in the number of physical locations justifies > additional > assignments? There may be other legitimate reasons for an org to > come back > for more addresses. > >> So, what do people think of the above? An improvement? Still some >> unacceptable points? > > I think it's a step backwards; objections noted above. > >> Questions relating to above: >> >> 1) How many direct /22 IPv4 assignments have been made to date? That >> is, how many organizations do we think would qualify? Are we >> talking a few thousand? tens of thousands? or? > > Well, right off the bat I'd say it's on the order of the number of > assigned > ASNs. How many new folks will go get an ASN to take advantage of this > policy is up for debate... > I think that is way off. I was told a while ago it was a few dozen at most 2002-3 requests, so that's 3 orders of magnitude less than the number of ASN. I am sure that ARIN can provide an updated number. It is true that most new ASN announced into BGP are from multi-homed end sites. Here, for example, are the new announcements with ARIN handles for the month of February so far as seen from here : 11885 CSI [PP469-ARIN] {RONKONKOMA, NY, US} CAMP SYSTEMS INTERNATIONAL 17050 MCVP-AS-NO [BMI29-ARIN] {Boston, MA, US} TAC Partners, Inc. 22388 TRANSPAC [CR721-ARIN] {Bloomington, IN, US} Indiana University 17372 BMO-TOR2 [AU155-ARIN] {Scarborough, ON, CA} Bank of Montreal 33676 BIVAPR-AS [PM380-ARIN] {Santurce, PR, PR} WHTV Broadcasting Corp. 14572 SUAVEMENTE [SNO26-ARIN] {Chula Vista, CA, US} Suavemente, INC. 14600 MXL-PROD [NOC1845-ARIN] {Englewood, CO, US} MX Logic, Inc. 16936 TECHNORATI [TTC1-ARIN] {San Francisco, CA, US} Technorati, Inc. 32287 SOLANA-CITIPLEX [PATRI6-ARIN] {New York, NY, US} Citigroup 19666 HENDERSONBROTHERS-MAIN [ECO22-ARIN] {Pittsburgh, PA, US} Henderson Brothers, Inc. 10851 NREP [ON2-ARIN] {Nashville, TN, US} Nashville Regional Exchange Point 10659 SEQUENT-CS2 [NOCTE3-ARIN] {Research Triangle Park, NC, US} IBM 26388 RLMNY [JO400-ARIN] {NEW YORK, NY, US} ROBINSON LERER AND MONTGOMERY 21955 TALECRIS [TS1177-ARIN] {RTP, NC, US} Talecris Biotherapeutics (as seen as part of the multicast status page effort, http:// www.multicasttech.com/status ) How many of these are truly multihomed is not clear, but I do not think that many are asking for micro-assignments. I do think that the ones that do need them, should be able to get them. I think that, within some loose filters, they can be trusted to make that determination. I do not know if many people are thinking in IPv4 or IPv6, but it seems clear to me that a lot are thinking in terms of 1999. Those days are gone. Regards Marshall Eubanks > S > > Stephen Sprunk "Stupid people surround themselves with smart > CCIE #3723 people. Smart people surround themselves with > K5SSS smart people who disagree with them." --Aaron Sorkin > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From memsvcs at arin.net Fri Feb 10 10:26:25 2006 From: memsvcs at arin.net (Member Services) Date: Fri, 10 Feb 2006 10:26:25 -0500 Subject: [ppml] Proposed Policy: IPv6 Direct PI Assignments for End Sites Message-ID: <43ECB0A1.2060002@arin.net> ARIN received the following proposed policy. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List and being placed on ARIN's website. The ARIN Advisory Council (AC) will review the proposal and within ten working days may decide to: 1) Support the proposal as is, 2) Work with the author to clarify, divide or combine one or more policy proposals, or 3) Not support the policy proposal. If the AC supports the proposal or reaches an agreement to work with the author, then the proposal will be posted as a formal policy proposal to the Public Policy Mailing List and it will be presented at the Public Policy Meeting. If the AC does not support the proposal, then the author may elect to use the petition process to advance the proposal. If the author elects not to petition or the petition fails, then the proposed policy 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: IPv6 Direct PI Assignments for End Sites Author: Andrew Dul Proposal type: new Policy term: permanent Policy statement: Add new subsection to the NRPM: 6.5.8. Direct assignments to end sites 6.5.8.1. To qualify for a direct end site assignment, an organization must meet all of the following criteria: 1. not be an LIR; 2. be an end site; 3. be currently multihomed using IPv4; 4. have a direct assignment from ARIN of at least a IPv4 /19 and can show the current utilization of 80% of an IPv4 /19 equivalent. 6.5.8.2. Direct assignment size to end sites Organizations that meet the direct end site assignment criteria are eligible to receive a direct assignment of /48 out of a reserved /44. Direct Assignments shall be allocated from a separate super-block to allow for LIRs to filter. 6.5.8.3. Subse quent direct assignments to end sites Organizations assignment size may be increased by 1 bit (to a maximum of /44) when they demonstrate the active usage of 50% of the assigned /64 subnets. Only one direct assignment may be made to an end site organization under Section 6.5.8. Organizations which can demonstrate active usage of more than 50% of /64 networks from a /44 assignment shall qualify for an additional allocation as an LIR. Rationale: This policy is proposed as an alternative to the existing 2005-1 policy proposal. This policy is intended to be more conservative that the existing proposed 2005-1 policy. While this policy does allow PI assignments to end-sites, it limits the scope to current IPv4 holders with direct assignments. A more conservative policy is desirable as the first IPv6 PI policy. Current ARIN policy does not permit an end-site from obtaining a Provider Independent IPv6 address block directly from ARIN. There is currently no viable IPv6 multihoming method available for these end-sites. Shim6 & other methods have been proposed as a possible method to meet multihoming requirements. Today, no implementation or alternatives exist to ?traditional? IPv4 multihoming which announces unique address space from an ASN. The largest end-sites (corporations & content providers) have the greatest to gain and/or lose by not having an available method to multihome. While IPv6 provides for stateless auto configuration for end hosts, no new methods for renumbering the infrastructure are available. The cost and complexity of renumbering these large organizations makes it essential to provide stable address resources which are not assigned from a LIR. The lack of an end-site assignment policy is currently preventing the real planning and deployment of IPv6 networks in these organizations. Other policy proposals (2005-1) addressing this issue have been presented at the ARIN 15 & 16 meetings. This policy proposal attempts to address the issues that were raised on the ppml mailing list and at the public policy meetings for 2005-1. Specifically, the main issue surrounding the creation of consensus on this policy appears to be the criteria for which end-sites should be able to obtain an endsite assignment. Concerns have been raised about the creation of a new IPv6 ?swamp? by having a policy that is too lenient. This issue is addressed in the policy by limiting the endsite assignments to current organizations with a modest IPv4 assignment. The assignment of IPv4 resources is orthogonal to the assignment of IPv6 addresses. However, the use of existing IPv4 assignments and ARIN membership are postulated as an appropriate regulator for the initial assignments under an IPv6 endsite policy. It is reasonable to consider changes to the membership and IPv4 assignment requirements in the future. This review should be conducted after the endsite assignment policy has been in place long enough to understand the demand for endsite IPv6 assignments and the development of IPv6 networks have matured. This policy proposal does not attempt to address the assignment needs for endsites which currently do not have IPv4 assignments. Timetable for implementation: within 90 days of approval by the BoT From leslien at arin.net Fri Feb 10 10:28:24 2006 From: leslien at arin.net (Leslie Nobile) Date: Fri, 10 Feb 2006 10:28:24 -0500 Subject: [ppml] Comments on revised 2005-1 proposal of 2006-02-03 In-Reply-To: <200602082209.k18M9L9t013516@cichlid.raleigh.ibm.com> Message-ID: <002f01c62e56$a2080ea0$6bfc95c0@arin.net> Hi Thomas- On Feb. 8, you asked "How many direct /22 IPv4 assignments have been made to date? That is, how many organizations do we think would qualify? Are we talking a few thousand? tens of thousands? or?" Under policy 2002-3 "Address Policy for Multi-homed Networks" (implemented in May 2004), ARIN has issued: 244 /22s 176 /21s Regards, Leslie Nobile Director, Registration Services ARIN -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of Thomas Narten Sent: Wednesday, February 08, 2006 5:09 PM To: Kevin Loch Cc: ppml at arin.net Subject: [ppml] Comments on revised 2005-1 proposal of 2006-02-03 > Marshall Eubanks wrote: > > Can you prepare a revised version? There has been so much back and > > forth (some fairly tangential) that I am no longer sure exactly what > > the new proposal will say. > Add new subsection in section 6.5 of the NRPM: > 6.5.8. Direct assignments to large/complex end sites I agree with others about the "complex" wording not being helpful. IMO, we are fine just changing this to: 6.5.8. Direct assignments to large end sites > 6.5.8.1. To qualify for a direct assignment, an > organization must: > a) not be an IPv6 LIR; and > b) meet at least ONE of the following requirements: > 1) Have an IPv4 assignment or allocation directly from an RIR, > the IANA or legacy registry; or I have a hard time supporting giving owners of "legacy" IPv4 registrations automatic IPv6 space. This just perpetuates the "early adopter" program (e.g., those that got big assignments prior to the the RIRs, get similar treatment in IPv6). Also, IMO, it's not enough to have "an IPv4 assignment or allocation directly from an RIR"; there are different types of assignments/allocations. We should restrict giving out IPv6 PI space that satisfy specific criteria. Indeed, I'm not sure why 1) is even needed. I think item 2) (that follows) is a better justification and can subsume 1). > 2) Qualify for an IPv4 assignment or allocation from ARIN under > the IPv4 policy currently in effect; or With some caveats, since not all allocations are the same (e.g., getting space for anycast, etc.) > 3) Be currently multihomed using IPv6 connectivity to two > or more separate ARIN LIR's using at least one /48 assigned > to them by each LIR. IMO, being multihomed in IPv4 should also be sufficient justification. One argument I keep hearing is that "we're assigning PI space in IPv4 for multihoming, and the system is working". So let's try and leverage that experience. > 6.5.8.2. Direct assignment size to large/multihomed end sites > Organizations that meet the direct end site assignment criteria > are eligible to receive a direct assignment. The minimum size > of the assignment is /48. Organizations requesting a larger > assignment or a second (or more) assignment must provide > documentation justifying the need for additional subnets. I suspect that /48 is too small, if we are aiming at the biggest end sites. E.g., take sites that have O(100K) subnets. According the HD ratio thresholds, that would correspond to (I think) a /44. One thing that I would find helpful is if there is any data available concerning sizes of organizations (in terms of networks/devices/users). How many organizations have 100K subnets? Is that number small enough that we can use it as a threshhold to give everyone with 100K subnets a PI assignment? Although the following is far from perfect, using number of employees might be attractive in that it is information that is often publically available, and gives a very rough indication of number of machines (assume some multiple of machines/subnets per employee). But I recall from previous discussions, people preferred more relevant criteria like numbers of subnets. > 6.5.8.3. Subsequent Assignment Size > Additional assignments may be made when the need for additional > subnets is justified. When possible assignments will be made > from an adjacent address block. Perhaps specifically tie this back to the the HD ratio. So, here is a revised strawman based on the comments above: Add new subsection in section 6.5 of the NRPM: 6.5.8. Direct assignments to large end sites 6.5.8.1. To qualify for a direct assignment, an organization must: a) not be an IPv6 LIR; b) meet all of the following requirements: 1) Qualify for an IPv4 direct assignment from ARIN under the IPv4 policy currently in effect [specifically, Section 4.3, excluding microassignments. Note also that this means end site must qualify for a /22 if multihoming. Is this bar high enough?]. 2) Be currently multihomed using IPv4 or IPv6 as defined in "ARIN Number Resource Policy Manual Version 2005.1 - September 7, 2005" [note: text referred to is: 2.7. Multihomed An organization is multihomed if it receives full-time connectivity from more than one ISP and has one or more routing prefixes announced by at least two of its upstream ISPs. ] 6.5.8.2. Direct assignment size to large end sites Organizations that meet the direct end site assignment criteria given in Section 6.5.8.1 are eligible to receive a direct assignment. The minimum size of the assignment is a /40. Larger assignments will be made when justified using the existing IPv6 applied HD ratio as given in Section 6.5. Assignments will be made out of a specially designated address block that indicates a direct assignment to an endsite. 6.5.8.3. Subsequent Assignment Size An organization may receive an additional assignment when it has grown to include enough distinct physical locations to justify the larger assignment. Where possible, the assignment will be made from an adjacent address block. ================================================================ So, what do people think of the above? An improvement? Still some unacceptable points? Questions relating to above: 1) How many direct /22 IPv4 assignments have been made to date? That is, how many organizations do we think would qualify? Are we talking a few thousand? tens of thousands? or? Thomas _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From memsvcs at arin.net Fri Feb 10 10:31:43 2006 From: memsvcs at arin.net (Member Services) Date: Fri, 10 Feb 2006 10:31:43 -0500 Subject: [ppml] Proposed Policy: IPv4 Micro-allocations for anycast services (experimental) Message-ID: <43ECB1DF.4000006@arin.net> ARIN received the following proposed policy. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List and being placed on ARIN's website. The ARIN Advisory Council (AC) will review the proposal and within ten working days may decide to: 1) Support the proposal as is, 2) Work with the author to clarify, divide or combine one or more policy proposals, or 3) Not support the policy proposal. If the AC supports the proposal or reaches an agreement to work with the author, then the proposal will be posted as a formal policy proposal to the Public Policy Mailing List and it will be presented at the Public Policy Meeting. If the AC does not support the proposal, then the author may elect to use the petition process to advance the proposal. If the author elects not to petition or the petition fails, then the proposed policy 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: IPv4 Micro-allocations for anycast services (experimental) Author: David Williamson Proposal type: new Policy term: temporary Policy statement: In the NRPM IPv4 section, renumber 4.4 to 4.4.1, and add: 4.4.2 Micro-allocations for anycast services - ARIN will make micro-allocations to organizations wishing to deploy anycast based services, provided they meet the following criteria: * All of the criteria normally required to receive IPv4 space, AND * The organization must have multiple (at least two) discrete multi-homed networks. * The organization must advertise directly allocated networks from each multi-homed site. Micro-allocations for anycast services will be no longer than a /24. These allocations will be made out of blocks reserved for micro-allocation purposes. ISPs and other organizations receiving these micro-allocations will be charged under the ISP fee schedule, while end-users will be charged under the fee schedule for end-users. This policy is experimental, and is limited to 16 allocations and two years from adoption. In addition, organizations may receive no more than one microallocation under this policy. Rationale: There are an increasing number of anycast-based applications being offered by service providers and other organizations. Indeed, many basic infrastructure services (like the DNS root servers) are already anycast based. (See RFC 1546 for an authoritative discussion of anycast services.) It's worth noting that IPv6 has anycast built into the protocol itself. This is a sign that there is significant community interest in anycast as a technology, and highlights the lack of IPv4 allocation policy for anycast. Deployment of new services is severely hampered by current IPv4 allocation policies. For organizations that do not have legacy IP space, justifying a /22 to serve a handful of addresses is effectively impossible. As many ISPs also filter routes longer than /22, it is impractical to use a longer mask for any netblock that is utilized for an anycast service. This situation is also generally unfavorable to younger organizations, while giving older organizations that do have a surplus of legacy space a competitive advantage. In light of this, some organizations may simply lie about their addressing needs in order to convince an RIR or LIR that a /22 is required, when a much smaller network would suffice. This is not a behavior that should be encouraged by policy. The obvious answer is that a micro-allocation scheme needs to be created to allow organizations deploying anycast services to acquire a network of more appropriate size. It is also clear that a micro-allocation policy that makes it easier for organizations to acquire small netblocks may lead to additional improper allocations to organizations that simply wish to acquire additional small blocks of space. This policy proposal attempts to address that by requiring more stringent requirements for such allocations. A previous policy proposal (2005-6) is similar to this proposal, but with a few significant changes. There was signficant negative feedback to that policy based on a couple of key difficulties, which this proposal attempts to address. The primary difficulty is that an anycast network looks much like a normal multihomed network from the outside. This led to the consensus belief that the earlier policy proposal would be abused by organizations that wouldn't otherwise qualify for address space. This proposal futher restricts allocations such that only organizations that are already demonstratably multihomed with direct allocations can possibly qualify. Such organizations will typically have little use for a small allocation unless they really intend to use it for a specific purpose. In addition, this policy is marked as experimental and has a sunset clause, which will definitively prevent widespread abuse. It is hoped that operational experience will show that this policy is not seeing abuse, and it can later be modified to be permanent. In the event that this policy is widely abused, the total damage is limited and will be fixed in a relatively short time span. Timetable for implementation: immediate From woody at pch.net Fri Feb 10 10:30:37 2006 From: woody at pch.net (Bill Woodcock) Date: Fri, 10 Feb 2006 07:30:37 -0800 (PST) Subject: [ppml] Proposed Policy: Capturing Originations in Templates In-Reply-To: References: Message-ID: On Fri, 10 Feb 2006, Owen DeLong wrote: > There are already a number of routing registries (ARIN RR, etc.) On Fri, 10 Feb 2006 Michael.Dillon at btradianz.com wrote: > One could argue that existing routing registries suffer > from a stale data problem due to the fact that there is > not an authoritative source of the data. If ARIN would > operate a routing registry... That's what the ARIN RR _is_. ARIN has been operating a routing registry for several years. As Owen just pointed out. > ...they have the potential of solving the stale data problem. How so? What policy would you enact to give ARIN the lattitude to "solve the problem" of the data people publish through routing registries? -Bill From owen at delong.com Fri Feb 10 11:16:47 2006 From: owen at delong.com (Owen DeLong) Date: Fri, 10 Feb 2006 08:16:47 -0800 (PST) Subject: [ppml] Comments on revised 2005-1 proposal of 2006-02-03 In-Reply-To: <002f01c62e56$a2080ea0$6bfc95c0@arin.net> Message-ID: <200602101616.k1AGGlm8032020@sipregister.delong.com> kiSo, that looks like about 19 months yielded just over 400 routing table entries. Hardly what I would call a land rush. WAY under the number of PA prefixes added in the same time, I bet. Owen > > Under policy 2002-3 "Address Policy for Multi-homed Networks" (implemented > in May 2004), ARIN has issued: > > 244 /22s > 176 /21s > > > Regards, > Leslie Nobile > Director, Registration Services > ARIN > > From owen at delong.com Fri Feb 10 11:20:00 2006 From: owen at delong.com (Owen DeLong) Date: Fri, 10 Feb 2006 08:20:00 -0800 (PST) Subject: [ppml] Proposed Policy: IPv6 Direct PI Assignments for End Sites In-Reply-To: <43ECB0A1.2060002@arin.net> Message-ID: <200602101620.k1AGK0c1032052@sipregister.delong.com> Since I think most people know where I stand and why, I'll keep this short just to officially get counted as chiming in on the policy... I oppose this policy. It is not an improvement over 2005-1. It restores the bias favoring only the wealthiest organizations and has a very similar net effect to the version of 2005-1 that was defeated at the last ARIN meeting. Owen From sleibrand at internap.com Fri Feb 10 11:42:20 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 10 Feb 2006 11:42:20 -0500 (EST) Subject: [ppml] alternative to 2005-1 In-Reply-To: References: Message-ID: On 02/10/06 at 10:03am -0000, Michael.Dillon at btradianz.com wrote: > I think it may help if the policy is written in such > a way that we separate the requirements for IPv4 users > from the requirements for non-IPv4 users. We seem to have > general consensus that most end users who have an IPv4 > PI block should be able to get an IPv6 one. The wording > of that still needs some honing, but we do not need to > worry so much about a landrush situation. > > On the other hand, if an end user has no IPv4 PI history, > the possibility of a landrush exists and the policy language > has to be tightened up a bit. > > IMHO, a good policy would deal with each case separately. Michael, What if we break this up into two policies? One could be along the lines of what Andrew proposed at the beginning of this thread, and would give IPv6 PI space to those who have (or qualify for) IPv4 PI space. IMO this is urgent, and should be done at Montreal if possible. A second policy could then be discussed regarding giving IPv6 PI space to those without IPv4 PI space. IMO this is a little less urgent given the small number of IPv6-only networks out there, but no less important in the long term. -Scott From memsvcs at arin.net Fri Feb 10 11:44:23 2006 From: memsvcs at arin.net (Member Services) Date: Fri, 10 Feb 2006 11:44:23 -0500 Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 Assignments for End Sites - revised text Message-ID: <43ECC2E7.3040806@arin.net> Policy Proposal 2005-1: Provider-independent IPv6 Assignments for End Sites has been revised by the authors. This proposal is open for discussion on this mailing list and will be on the agenda at the upcoming ARIN Public Policy Meeting. The current policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2005_1.html Regards, Member Services American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal 2005-1: Provider-independent IPv6 Assignments for End Sites Author: Owen Delong, Kevin Loch Proposal Version: 3 (2006-02-09) Proposal type: modify Policy term: permanent Policy statement: Add new subsection in section 6.5 of the NRPM: 6.5.8. Direct assignments to end sites 6.5.8.1. To qualify for a direct assignment, an organization must: a) not be an IPv6 LIR; and b) Qualify for an IPv4 assignment or allocation from ARIN under the IPv4 policy currently in effect. 6.5.8.2. Direct assignment size to end sites Organizations that meet the direct end site assignment criteria are eligible to receive a direct assignment. The minimum size of the assignment is /48. Organizations requesting a larger assignment must provide documentation justifying the need for additional subnets. 6.5.8.3. Subsequent Assignment Size Additional assignments may be made when the need for additional subnets is justified. When possible assignments will be made from an adjacent address block. Rationale: In IPv4 policy there are three main types of organizations that addresses are delegated to. o ISP's receive allocations directly from ARIN or from other ISP's o End Users receive assignments from ISP's o Large and/or multihomed End Users receive assignments directly from ARIN. The third category is currently missing from IPv6 policy and this is believed to be severely hindering deployment by those organizations. In IPv6 policy-speak: o LIR's receive allocations directly from ARIN o End Sites receive assignments from LIR's This policy proposes: o Large and/or multihomed End Sites receive assignments directly from ARIN. This policy applies to organizations with networks that are large and/or multihomed. Like their IPv4 counterparts they do not make assignments to external organizations. They instead assign space internally to their own facilities. Similarly to IPv4 These internal assignments are not submitted to ARIN via swip/rwhois. For transition purposes an organization that qualifies for IPv4 space today is considered elligible, regardless of whether they were considered an ISP or End User under IPv4 policy. It is expected that the IPv6 only (non transition) requirements will be developed as experience is gained. It is reommended that these assignments be made from a separate address block set aside for this purpose and that at least a /44 be reserved around each assignment for possible expansion. One bit should be reserved around assignments /44 and larger. Timetable for implementation: immediately From william at elan.net Fri Feb 10 12:47:56 2006 From: william at elan.net (william(at)elan.net) Date: Fri, 10 Feb 2006 09:47:56 -0800 (PST) Subject: [ppml] Proposed Policy: IPv6 Direct PI Assignments for End Sites In-Reply-To: <43ECB0A1.2060002@arin.net> References: <43ECB0A1.2060002@arin.net> Message-ID: > ### * ### > > > Policy Proposal Name: IPv6 Direct PI Assignments for End Sites > > Author: Andrew Dul > > Proposal type: new > > Policy term: permanent > > Policy statement: > > Add new subsection to the NRPM: > > 6.5.8. Direct assignments to end sites > > 6.5.8.1. To qualify for a direct end site assignment, an > organization must meet all of the following criteria: > > 1. not be an LIR; > 2. be an end site; > 3. be currently multihomed using IPv4; > 4. have a direct assignment from ARIN of at least a IPv4 /19 and > can show the current utilization of 80% of an IPv4 /19 equivalent. /19 is too large to encorage enough of an ipv adoption, please decrease to /22 > 6.5.8.2. Direct assignment size to end sites > > Organizations that meet the direct end site assignment criteria > are eligible to receive a direct assignment of /48 out of a reserved > /44. Direct Assignments shall be allocated from a separate super-block > to allow for LIRs to filter. > > 6.5.8.3. Subse quent direct assignments to end sites ^-- split word > Organizations assignment size may be increased by 1 bit (to a > maximum of /44) when they demonstrate the active usage of 50% of the > assigned /64 subnets. > > Only one direct assignment may be made to an end site > organization under Section 6.5.8. What if organization with large ipv4 net (/16 or larger) has network that is geographically split and chooses to announce part of it from one place and part from another. By this policy they will receive only one ipv6 network block and would not be able to make this work. > Organizations which can demonstrate active usage of more than 50% > of /64 networks from a /44 assignment shall qualify for an additional > allocation as an LIR. ^---- I think "RIR" is meant to be here > Rationale: > > This policy is proposed as an alternative to the existing 2005-1 policy > proposal. This policy is intended to be more conservative that the > existing proposed 2005-1 policy. While this policy does allow PI > assignments to end-sites, it limits the scope to current IPv4 holders > with direct assignments. A more conservative policy is desirable as the > first IPv6 PI policy. I disagree > Current ARIN policy does not permit an end-site from obtaining a > Provider Independent IPv6 address block directly from ARIN. There is > currently no viable IPv6 multihoming method available for these > end-sites. Shim6 & other methods have been proposed as a possible > method to meet multihoming requirements. Today, no implementation or > alternatives exist to ?traditional? IPv4 multihoming which announces > unique address space from an ASN. > > The largest end-sites (corporations & content providers) have the > greatest to gain and/or lose by not having an available method to > multihome. While IPv6 provides for stateless auto configuration for end > hosts, no new methods for renumbering the infrastructure are available. > The cost and complexity of renumbering these large organizations makes > it essential to provide stable address resources which are not assigned > from a LIR. > > The lack of an end-site assignment policy is currently preventing the > real planning and deployment of IPv6 networks in these organizations. > > Other policy proposals (2005-1) addressing this issue have been > presented at the ARIN 15 & 16 meetings. This policy proposal attempts > to address the issues that were raised on the ppml mailing list and at > the public policy meetings for 2005-1. > > Specifically, the main issue surrounding the creation of consensus on > this policy appears to be the criteria for which end-sites should be > able to obtain an endsite assignment. Concerns have been raised about > the creation of a new IPv6 ?swamp? by having a policy that is too > lenient. This issue is addressed in the policy by limiting the endsite > assignments to current organizations with a modest IPv4 assignment. > > The assignment of IPv4 resources is orthogonal to the assignment of IPv6 > addresses. However, the use of existing IPv4 assignments and ARIN > membership are postulated as an appropriate regulator for the initial > assignments under an IPv6 endsite policy. It is reasonable to consider > changes to the membership and IPv4 assignment requirements in the > future. This review should be conducted after the endsite assignment > policy has been in place long enough to understand the demand for > endsite IPv6 assignments and the development of IPv6 networks have matured. > This policy proposal does not attempt to address the assignment needs > for endsites which currently do not have IPv4 assignments. > > Timetable for implementation: within 90 days of approval by the BoT > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From william at elan.net Fri Feb 10 12:52:39 2006 From: william at elan.net (william(at)elan.net) Date: Fri, 10 Feb 2006 09:52:39 -0800 (PST) Subject: [ppml] Proposed Policy: IPv6 Direct PI Assignments for End Sites In-Reply-To: References: <43ECB0A1.2060002@arin.net> Message-ID: On Fri, 10 Feb 2006, william(at)elan.net wrote: >> Organizations which can demonstrate active usage of more than 50% >> of /64 networks from a /44 assignment shall qualify for an additional >> allocation as an LIR. > ^---- I think "RIR" is meant to be here Sorry I misread. My view is that it should be something like: "shall qualify for additional allocation from RIR and is encoraged to consider getting allocation as an LIR" The end-user organization with /44 already has enough usage to qualify as LIR by existing policies I think. -- William Leibzon Elan Networks william at elan.net From dlw+arin at tellme.com Fri Feb 10 13:05:09 2006 From: dlw+arin at tellme.com (David Williamson) Date: Fri, 10 Feb 2006 10:05:09 -0800 Subject: [ppml] Proposed Policy: IPv6 Direct PI Assignments for End Sites In-Reply-To: <200602101620.k1AGK0c1032052@sipregister.delong.com> References: <43ECB0A1.2060002@arin.net> <200602101620.k1AGK0c1032052@sipregister.delong.com> Message-ID: <20060210180509.GQ25038@shell01.corp.tellme.com> On Fri, Feb 10, 2006 at 08:20:00AM -0800, Owen DeLong wrote: > Since I think most people know where I stand and why, I'll keep this short > just to officially get counted as chiming in on the policy... > > I oppose this policy. It is not an improvement over 2005-1. It restores > the bias favoring only the wealthiest organizations and has a very similar > net effect to the version of 2005-1 that was defeated at the last ARIN > meeting. owen beat me to it. I agree, and on the same grounds. Personally, I think this problem has become somewhat intractable. Parts of the community really want to see IPv6 become a reality in the ARIN region, which will require some sort of PI policy. Others are concerned about the impact on routing slots and other resources (or, more cynically, their organization's bottom line). Until the various factions can find some common ground, this is going to keep going around in circles. I don't see any common ground in any of the current proposals. (Nor do I have a proposal in mind that would solve it.) I generally support the current version of 2005-1. As someone once noted to me, a good compromise is the one that makes all parties slightly angry. That proposal seems to have that property...hence my support. -David From andrew.dul at quark.net Fri Feb 10 13:21:34 2006 From: andrew.dul at quark.net (=?iso-8859-1?Q?Andrew=20Dul?=) Date: Fri, 10 Feb 2006 18:21:34 +0000 Subject: [ppml] Proposed Policy: IPv6 Direct PI Assignments for End Sites Message-ID: <20060210182134.27104.qmail@hoster908.com> > -------Original Message------- > From: william(at)elan.net > Subject: Re: [ppml] Proposed Policy: IPv6 Direct PI Assignments for End Sites > Sent: 10 Feb '06 09:47 > > > > Only one direct assignment may be made to an end site > > organization under Section 6.5.8. > > What if organization with large ipv4 net (/16 or larger) has network that > is geographically split and chooses to announce part of it from one place > and part from another. By this policy they will receive only one ipv6 > network block and would not be able to make this work. > This policy draft was not intended to address every case. At this point we have a need for large orgs to be able to obtain IPv6 address space to begin the transition process. I would have a hard time supporting a policy which permited "Joe's Corporation" to get a /48 for each of their 1000 offices and then announce them into the IPv6 default free zone (DFZ). If we did allow the above we truly create a first adoptor advantage, because lots of /48's in the DFZ is not sustainable. Andrew From sleibrand at internap.com Fri Feb 10 14:21:20 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 10 Feb 2006 14:21:20 -0500 (EST) Subject: [ppml] Proposed Policy: IPv4 Micro-allocations for anycast services (experimental) In-Reply-To: <43ECB1DF.4000006@arin.net> References: <43ECB1DF.4000006@arin.net> Message-ID: David, A very similar policy was rejected at the last ARIN meeting in L.A. on the grounds that a subnet of an existing network is adequate for running anycast. Can you clarify why this policy is required, in light of that consensus? I think there is significant disagreement in the community with your statement that "many ISPs also filter routes longer than /22, [so] it is impractical to use a longer mask for any netblock that is utilized for an anycast service." Do you have concrete examples to back up this statement? Thanks, Scott On 02/10/06 at 10:31am -0500, Member Services wrote: > ARIN received the following proposed policy. In accordance with the ARIN > Internet Resource Policy Evaluation Process, the proposal is being > posted to the ARIN Public Policy Mailing List and being placed on ARIN's > website. > > The ARIN Advisory Council (AC) will review the proposal and within ten > working days may decide to: > 1) Support the proposal as is, > 2) Work with the author to clarify, divide or combine one or more > policy proposals, or > 3) Not support the policy proposal. > > If the AC supports the proposal or reaches an agreement to work with the > author, then the proposal will be posted as a formal policy proposal to > the Public Policy Mailing List and it will be presented at the Public > Policy Meeting. If the AC does not support the proposal, then the author > may elect to use the petition process to advance the proposal. If the > author elects not to petition or the petition fails, then the proposed > policy 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: IPv4 Micro-allocations for anycast services > (experimental) > > Author: David Williamson > > Proposal type: new > > Policy term: temporary > > Policy statement: > > In the NRPM IPv4 section, renumber 4.4 to 4.4.1, and add: > > 4.4.2 Micro-allocations for anycast services - ARIN will make > micro-allocations to organizations wishing to deploy anycast based > services, provided they meet the following criteria: > > * All of the criteria normally required to receive IPv4 space, AND > * The organization must have multiple (at least two) discrete > multi-homed networks. > * The organization must advertise directly allocated networks from > each multi-homed site. > > Micro-allocations for anycast services will be no longer than a /24. > These allocations will be made out of blocks reserved for > micro-allocation purposes. ISPs and other organizations receiving these > micro-allocations will be charged under the ISP fee schedule, while > end-users will be charged under the fee schedule for end-users. > > This policy is experimental, and is limited to 16 allocations and two > years from adoption. In addition, organizations may receive no more > than one microallocation under this policy. > > Rationale: > > There are an increasing number of anycast-based applications being > offered by service providers and other organizations. Indeed, many > basic infrastructure services (like the DNS root servers) are already > anycast based. (See RFC 1546 for an authoritative discussion of anycast > services.) > > It's worth noting that IPv6 has anycast built into the protocol itself. > This is a sign that there is significant community interest in anycast > as a technology, and highlights the lack of IPv4 allocation policy for > anycast. > > Deployment of new services is severely hampered by current IPv4 > allocation policies. For organizations that do not have legacy IP > space, justifying a /22 to serve a handful of addresses is effectively > impossible. As many ISPs also filter routes longer than /22, it is > impractical to use a longer mask for any netblock that is utilized for > an anycast service. This situation is also generally unfavorable to > younger organizations, while giving older organizations that do have a > surplus of legacy space a competitive advantage. > > In light of this, some organizations may simply lie about their > addressing needs in order to convince an RIR or LIR that a /22 is > required, when a much smaller network would suffice. This is not a > behavior that should be encouraged by policy. > > The obvious answer is that a micro-allocation scheme needs to be created > to allow organizations deploying anycast services to acquire a network > of more appropriate size. > > It is also clear that a micro-allocation policy that makes it easier for > organizations to acquire small netblocks may lead to additional improper > allocations to organizations that simply wish to acquire additional > small blocks of space. This policy proposal attempts to address that by > requiring more stringent requirements for such allocations. > > A previous policy proposal (2005-6) is similar to this proposal, but > with a few significant changes. There was signficant negative feedback > to that policy based on a couple of key difficulties, which this > proposal attempts to address. > > The primary difficulty is that an anycast network looks much like a > normal multihomed network from the outside. This led to the consensus > belief that the earlier policy proposal would be abused by organizations > that wouldn't otherwise qualify for address space. This proposal futher > restricts allocations such that only organizations that are already > demonstratably multihomed with direct allocations can possibly qualify. > Such organizations will typically have little use for a small > allocation unless they really intend to use it for a specific purpose. > > In addition, this policy is marked as experimental and has a sunset > clause, which will definitively prevent widespread abuse. It is hoped > that operational experience will show that this policy is not seeing > abuse, and it can later be modified to be permanent. In the event that > this policy is widely abused, the total damage is limited and will be > fixed in a relatively short time span. > > Timetable for implementation: immediate > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From owen at delong.com Fri Feb 10 14:49:20 2006 From: owen at delong.com (Owen DeLong) Date: Fri, 10 Feb 2006 11:49:20 -0800 Subject: [ppml] Proposed Policy: IPv6 Direct PI Assignments for End Sites In-Reply-To: References: <43ECB0A1.2060002@arin.net> Message-ID: > Sorry I misread. My view is that it should be something like: > "shall qualify for additional allocation from RIR and is encoraged to > consider getting allocation as an LIR" > > The end-user organization with /44 already has enough usage to qualify > as LIR by existing policies I think. Current policy does not allow an end-organization without external downstream organizations to be treated as an LIR. 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 jdhoule at att.com Fri Feb 10 16:25:55 2006 From: jdhoule at att.com (Houle, Joseph D (Joe), CMO) Date: Fri, 10 Feb 2006 15:25:55 -0600 Subject: [ppml] Version think... was: alternative to 2005-1 Message-ID: Folks: There has been a lot of discussion recently about provider independent addressing as the solution to problems of multi-homing, ISP lock-in, etc. My concern is that we can't afford to ignore the potential impact on the size of global Internet routing tables. If we take a look at the problems that keep coming up: Problem: Multi-homing In IPv4, multi-advertising (i.e., advertising the same address across multiple providers) was the answer to the problem. In IPv6, shouldn't we be thinking of multi-addressing (i.e. multiple addresses for the same sub-net) as the answer? ... Granted Shim6 is not fully baked yet, but that (or something which accomplishes the same basic goal) is where our creative energies should be focused." Problem: ISP lock-in In IPv4, PI was the insurance against "my ISP got run over by a truck". In IPv6, shouldn't the prudent user (enterprise customer, campus, etc.) get addresses from all their service providers? We need to focus some attention on the effect of fragmentation (whether caused by PI or multi-advertising in general) on the Internet routing table size. With the orders of magnitude increases of addresses (IPv6 vs. IPv4) and AS numbers, there is potential for routing table explosion. It's our responsibility to prevent that. Even if someone's favorite policy goal is not satisfied, addressing policy needs to be conservative - and biased heavily against the risk of routing table explosion since we have no data about how IPv6 addressing policies will impact the Internet over the long term. Joe Houle -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of Alec H. Peterson Sent: Thursday, February 09, 2006 4:04 PM To: Daniel Golding Cc: Thomas Narten; PPML Subject: Re: [ppml] alternative to 2005-1 Hi Dan, ... Statements like that tell me that we are still thinking in IPv4 terms. This is precisely why this discussion is happening, because we _need_ to think in non-IPv4 terms. If we are constrained by how things work in the IPv4 world then you are correct. However, if we are constrained by how things work in the IPv4 world then IPv6 will not be worth much anyway. Alec _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From chuegen at cisco.com Fri Feb 10 16:38:15 2006 From: chuegen at cisco.com (Craig Huegen (chuegen)) Date: Fri, 10 Feb 2006 16:38:15 -0500 Subject: [ppml] Proposed Policy: IPv6 Direct PI Assignments for End Sites Message-ID: David Williamson wrote: > owen beat me to it. I agree, and on the same grounds. Personally, I > think this problem has become somewhat intractable. Parts of the > community really want to see IPv6 become a reality in the ARIN region, > which will require some sort of PI policy. Others are concerned about > the impact on routing slots and other resources (or, more cynically, > their organization's bottom line). Until the various I'm concerned about both, to be honest, and a balancing act is required here. Since once off the ground, IPv6 appears to be headed for a fairly long life, we do have to be concerned about the scalability of the infrastructure. In addition, beyond the basic DFZ routing table memory that I hear concerns about, I share concerns about scalability for other services (e.g. security) inside the network (mechanisms such as ACL's via TCAM, etc.) and the technology needed to drive that. We won't need to worry about any of that if we never get adoption. In my opinion, without enterprise businesses adopting IPv6, it will likely remain a research and hobbyist playground. No evidence suggests this is solely an ARIN problem, either. I would like to re-emphasize the notion raised previously that a requirement to use PA space is a de facto perpetual contract with an SP, for an enterprise that has a significant number of subnets. A small business with 6 or 8 segments isn't impacted in the same way as a large enterprise with 60,000+ subnets is impacted. For those large enterprises, it is simply unacceptable to use PA space. I have not observed a strong feeling in these policy discussions against the idea of PI space; most of the arguments I see are related to where we place the line in the sand for eligibility. I offer that the line needs to be drawn based on the pain of renumbering PA space vs. the impact on the DFZ infrastructure. In a relatively large corporate network that I have an association with, renumbering tens of thousands of subnets is extremely painful and it is unlikely that we would extensively deploy IPv6 in the near-term knowing we would have to renumber every one of those subnets in case of a service provider change. When comparing this versus existing IPv4 models, I don't feel that a /22 or /21 generates sufficient renumbering pain to warrant assignment of PI space. I sit on the fence when it comes to /20, and I rather like the idea of using /19 as the guideline (personally). > I generally support the current version of 2005-1. As someone once > noted to me, a good compromise is the one that makes all parties > slightly angry. That proposal seems to have that property...hence my > support. With all that said, I think the most important point here is that adoption of IPv6 in the near term will require some type of PI space. I'm inclined to support / vote for any proposal that implements PI space in the near term with reasonable parameters. I want a longer term solution -- whether it be id/loc split or some other method -- that would eventually phase out PI space. /cah --- Craig A. Huegen, IT Solutions Architect C i s c o S y s t e m s IT - Intelligent Network Solutions || || Cisco Systems, Inc., 400 East Tasman Drive || || San Jose, CA 95134, (408) 526-8104 |||| |||| email: chuegen at cisco.com CCIE #2100 ..:||||||:..:||||||:.. From kloch at hotnic.net Fri Feb 10 17:17:51 2006 From: kloch at hotnic.net (Kevin Loch) Date: Fri, 10 Feb 2006 17:17:51 -0500 Subject: [ppml] Version think... was: alternative to 2005-1 In-Reply-To: References: Message-ID: <43ED110F.8070407@hotnic.net> Houle, Joseph D (Joe), CMO wrote: > Problem: Multi-homing > In IPv4, multi-advertising (i.e., advertising the same address across > multiple providers) was the answer to the problem. > In IPv6, shouldn't we be thinking of multi-addressing (i.e. multiple > addresses for the same sub-net) as the answer? ... Granted Shim6 is not > fully baked yet, but that (or something which accomplishes the same > basic goal) is where our creative energies should be focused." A new new routing architectureis needed if we ever hope to fully utilize the IPv6 address space. 500 Million /32's for LIR's is impossible to imagine with todays architecture. Fortunately there are only about ~21K AS's in use publicly. If we can optimize policy towards one prefix per AS it will help buy time to develop a new architecture. > Problem: ISP lock-in > In IPv4, PI was the insurance against "my ISP got run over by a truck". > In IPv6, shouldn't the prudent user (enterprise customer, campus, etc.) > get addresses from all their service providers? Each additional provider increases the chances of a renumbering event. Despite the original promises, IPv6 still requires just as much manual configuration as IPv4. > We need to focus some attention on the effect of fragmentation (whether > caused by PI or multi-advertising in general) on the Internet routing > table size. Fortunately the large address size of IPv6 has enabled generous minimum assignment sizes. This will hopefully drive the prefix to AS ratio close to 1. In fact that is currently the case (IPv4 = ~8:1, IPv6 = ~1.25:1). The proposed PI policies follow this generous assignment principle so PI should not affect the prefix to AS ratio. A significant benefit of getting PI space in a separate address block is that filtering of deaggregates becomes less painful. We need a compatible migration path for most IPv4 address space holders, and 2005-1 offers that. - Kevin From stephen at sprunk.org Sat Feb 11 01:13:19 2006 From: stephen at sprunk.org (Stephen Sprunk) Date: Sat, 11 Feb 2006 00:13:19 -0600 Subject: [ppml] Comments on revised 2005-1 proposal of 2006-02-03 References: Message-ID: <091b01c62ed2$41ef75e0$feac1cac@ssprunk> Thus spake >> > I do think that a /40 is about the smallest sized block that I would >> > like to see given out as IPv6 PI space at this time. Just how you >> > define who is large enough to justify such a assignment I do not >> > know. >> > >> > I personaly would rather see unique street addresses be considered >> > as justification for space, more so then number of employees... but >> > perhaps either or... or some combination of both, etc... > >> This is a dead end. The last 2005-1 was defeated at the last ARIN >> meeting specifically because of the 100k host requirement. > > I beg to differ with you. Glenn is trying to define how > to justify a specific size of IPv6 address block. This is > something that we have not had to define before since the > IPv6 rules that we now have, only cover allocations to > providers who then make assignments to their subscribers. > > In this case, 2005-1, we have to define rules that ARIN > would use to determine the size of a block to be assigned > to a subscriber who comes directly to ARIN rather than > going to an upstream network operator. We are already in > broad agreement that it is justified to make such an > application to ARIN when there is no single upstream provider > to provide a single assignment. I think some of the ISP folks would disagree but would rather support a somewhat reasonable policy than risk a completely unreasonable one. > Now, how do we measure justification for IPv6. As Glenn has > pointed out, it is more consistent with IPv6 addressing > design and existing policy, if we count the number of physical > locations. He suggests street addresses. Others might suggest > that we count the number of buildings. In either case, the > ARIN analysts could request backup information to confirm these > numbers. There is nothing "consistent with IPv6 addressing design and existing policy" about counting street addresses, buildings, etc. The NRPM specifically defines an end site as a subscriber with no reference to the number of locations; RFC 3177 has similar wording. If you don't like this aspect of _existing_ policy, you're welcome to propose a change, but you can't just ignore it because it doesn't suit your worldview. In any case, what is wrong with giving a /48 by default to each org and using some HD ratio as the trigger for larger blocks? Any org with a significant number of locations will necessarily have a large number of subnets, which in turn will justify a large allocation. > When you say that the last meeting defeated the proposal due > to the 100k host requirement, you seem to ignore the fact that > Glenn has moved the discussion away from host counting and > into location counting, Right, but now Thomas has suggested 100k subnets -- a number that few, if any, orgs in the world have today, and definitely a step in the wrong direction. Even 10k subnets gives you a pretty short list. > with presumably, one /48 being assigned > per location. In any case, if we need to justify the magnitude > of the address block assigned, then we need to measure something > or other in the applicant's situation. The HD ratio for IPv6 PA allocations seems a reasonable metric to adopt until we have more experience. Even then, existing policy requires LIRs to send applications for assignments larger than a /48 to ARIN for review; if we're going to make hard rules for PI assignments, we should amend the PA rules as well. The lack of drive to do so for the latter should indicate the lack of need to do so for the former _at this point in time_. > So the question is, what do we measure? And what is the threshold > at which an end user orgnization qualifies? > > If anything is a dead end at this point, it appears to be the > concept that measurement is unnecessary and a PI block is > justified by the mere fact of multihoming. Everybody seems > to want some measurement, some threshold. I think there's consensus that IPv6 PI is justified for folks that have (or qualify for) IPv4 PI. The matters of debate at this point seem to be: what justifies more than a /48, whether an "end site" should be redefined to mean location, and whether tunnels should count as "full-time connectivity". Perhaps we could propose the part we seem to have consensus on and revisit the latter questions separately, if for no other reason than to get things moving in the meantime... S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin From owen at delong.com Sat Feb 11 10:41:36 2006 From: owen at delong.com (Owen DeLong) Date: Sat, 11 Feb 2006 07:41:36 -0800 Subject: [ppml] Version think... was: alternative to 2005-1 In-Reply-To: References: Message-ID: <10EC6E2B7F67A525F376E075@imac-en0.delong.sj.ca.us> > > Problem: Multi-homing > In IPv4, multi-advertising (i.e., advertising the same address across > multiple providers) was the answer to the problem. > In IPv6, shouldn't we be thinking of multi-addressing (i.e. multiple > addresses for the same sub-net) as the answer? ... Granted Shim6 is not > fully baked yet, but that (or something which accomplishes the same > basic goal) is where our creative energies should be focused." > Respectfully, I disagree. Our creative energies should be focused on finding a long term solution the fundamental problem which underlies all of these issues. The fundamental problem is that we are using IP addresses (v4 or v6) for two mutually incompatible purposes. The telephone companies learned this lesson years ago, solving it with SS7. Purpose 1: End System Identifier IP addresses are well suited to the task of uniquely identifying an end system on the network. This task is necessary and beneficial in that it allows creation of Access Control Lists and targeting datagrams to a particular end node. (Note, I address this from a network identity context, not a security identity context). Purpose 1a: Intradomain Routing Locator In the intradomain world, routing really boils down to a function of end-system delivery, so, the use of the ESI for this purpose is compatible. Purpose 2: Interdomain Routing Locator In the interdomain world, using the entire ESI is non-feasible and using a portion of it comes with a number of increasingly difficult problems. What is needed instead is a way to do routing based on a separate routing locator token and a corresponding method for mapping destination ESIs to Routing Locator at the Interdomain edge. Focusing our creative energies on this solution will yield the greatest benefit overall. > Problem: ISP lock-in > In IPv4, PI was the insurance against "my ISP got run over by a truck". > In IPv6, shouldn't the prudent user (enterprise customer, campus, etc.) > get addresses from all their service providers? > This is an incomplete definition of the problem. The true definition of the problem is: Changing IP addresses for an entire organization is costly and painful for a number of reasons: + Readdressing machines takes effort + Machine addresses often appear in configuration data on other devices which need to be simultaneously updated. + There is no easy mechanism for identifying all such remote configuration data. + Often said configuration data are not under the control of the owner of the network being renumbered. + Even when they are, the "flag day" nature of these changes creates significant end user impact often taking weeks or even months to fully resolve. It is the nature of end systems to change network topology on a somewhat regular basis. In some cases, those changes necessitate a change to the end system identifier. In most, they do not, especially in the cases of end systems which appear in remote configuration data (name servers, VPN gateways, certain service provider operations hosts, etc.). In those cases, the owner will usually take great pains to avoid changing the ESI unless forced to renumber their entire enterprise. As a result, fragmentation is the natural order of things, and, efforts to resist it inflict damage. Instead, we should be focusing our efforts on mitigating or eliminating the effects of such fragmentation. > We need to focus some attention on the effect of fragmentation (whether > caused by PI or multi-advertising in general) on the Internet routing > table size. With the orders of magnitude increases of addresses (IPv6 > vs. IPv4) and AS numbers, there is potential for routing table > explosion. It's our responsibility to prevent that. Even if > someone's favorite policy goal is not satisfied, addressing policy needs > to be conservative - and biased heavily against the risk of routing > table explosion since we have no data about how IPv6 addressing policies > will impact the Internet over the long term. > Here, I disagree. Conservative addressing policy as you call it is inflicting damage on the internet in one area in an effort to mask damage caused by a fundamental scaling design flaw in the way we do routing. The solution in the long run is to change how we do routing. Fortunately, most of the tools necessary to accomplish this were designed into IPv6 in the form of "Extension" headers. There is already an extension header type 53 defined for routing information. All that is needed is a new subtype for interdomain routing locator token data. No other changes to the IPv6 protocol are necessary. Additionally, BGP already exchanges a superset of the information needed to perform routing on this basis, so, existing BGP can be used until such time as the new routing paradigm becomes ubiquitous, at which point, we can make a major reduction in the data exchanged through BGP. Three new things are needed. 1. A mechanism for looking up ESI->RL translations in a secure and reliable way. 2. Edge Routers will require software capable of inserting RL data into packets they are routing. 3. Core routers will require software capable of making forwarding decision based on RL data first with prefix as a fallback. It may be desirable to have RL insertion as part of prefix fallback. Eventually, the prefix fallback capability will become unnecessary, but, benign. All three of these things can be deployed without impacting current routing and can be deployed on a system by system basis without disrupting neighboring systems. 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 tony.li at tony.li Sat Feb 11 12:52:48 2006 From: tony.li at tony.li (Tony Li) Date: Sat, 11 Feb 2006 09:52:48 -0800 Subject: [ppml] Version think... was: alternative to 2005-1 In-Reply-To: <10EC6E2B7F67A525F376E075@imac-en0.delong.sj.ca.us> References: <10EC6E2B7F67A525F376E075@imac-en0.delong.sj.ca.us> Message-ID: <43EE2470.2070106@tony.li> > Respectfully, I disagree. Our creative energies should be focused on > finding > a long term solution the fundamental problem which underlies all of these > issues. Equally respectfully, I'd like to suggest that this is neither the time nor the place to be doing architectural development. Yes, there are a myriad number of delicate issues with the assignment of PI space under the current routing architecture. If we cannot find a reasonable compromise under those circumstances, it is only rational for us to consider whether or not that architecture is practical. If we find that the architecture is impractical, then rather than solve it here, it makes sense to bring the issue to the appropriate forum (IETF). It has been suggested that we are in a situation where we have no choice except to deploy IPv6, and thus this question is moot. I'd invite those folks to consider the amount of investment still to be done in IPv6 and whether, in the long run, any time would be lost by simply skipping over a broken incarnation and the stutter step associated with an aborted, failed deployment. Regards, Tony From paul at vix.com Sat Feb 11 13:31:07 2006 From: paul at vix.com (Paul Vixie) Date: Sat, 11 Feb 2006 18:31:07 +0000 Subject: [ppml] Version think... was: alternative to 2005-1 In-Reply-To: Your message of "Sat, 11 Feb 2006 09:52:48 PST." <43EE2470.2070106@tony.li> References: <10EC6E2B7F67A525F376E075@imac-en0.delong.sj.ca.us> <43EE2470.2070106@tony.li> Message-ID: <20060211183107.E768E11425@sa.vix.com> # ..., I'd like to suggest that this is neither the time nor the place to be # doing architectural development. Yes, there are a myriad number of delicate # issues with the assignment of PI space under the current routing # architecture. If we cannot find a reasonable compromise under those # circumstances, it is only rational for us to consider whether or not that # architecture is practical. If we find that the architecture is impractical, # then rather than solve it here, it makes sense to bring the issue to the # appropriate forum (IETF). It's no less practical than IPv4, and look how much bigger the current IPv4 internet is than could be guessed at by _its_ original architecture. Whether something is practical isn't apriori knowable, it depends on the level of desperate effort that its practicioners are willing to put into it. # It has been suggested that we are in a situation where we have no choice # except to deploy IPv6, and thus this question is moot. I'd invite those # folks to consider the amount of investment still to be done in IPv6 and # whether, in the long run, any time would be lost by simply skipping over # a broken incarnation and the stutter step associated with an aborted, # failed deployment. The decision to poor good money after bad on IPv6 was made early on, and then re-made, and will yet be re-made, many times over its lifetime. I'm struck by the fact that while all practitioners of routing knew that "without rapid renumbering, IPv6 is undeployable", the IAB did not know this and no doubt still does not know this. Perhaps the fundamental flaw in this architecture came about when the RIR communities were _not_ directly involved in vetting it, and if so, simply passing the problem back to the IETF will at best cause the same errors (or compatible errors) to be repeated. (Thomas Narten correctly pointed out that the rapid renumbering requirement wasn't written down anywhere... I guess it felt "too obvious" to bother writing it down... Ouch. I'm hoping Bill Manning's archives are better than mine on this point.) That having been said, I agree that it's out-of-scope for the PPML community to invent technology to make IPv6 more deployable. At best we can invent allocation rules and processes to make it more deployable. In that sense, there is hope. While we expect the absolute number of endpoints to grow under IPv6, most of the growth will be in handhelds and TV remote controls other locked-in devices, not in home LINUX servers or in multihomed enterprises. A policy like 2005-1 that allowed the dwindling (as a share of the total) number of endpoints to receive multihomable/rehomable PI space might actually be "all it'll take" to "solve" this whole problem. Sadly, we won't know what it'll take until we get there or get close, and as long as we reject PI requests for multihomable/rehomable space, we're holding IPv6's head underwater. 2005-1 is experimental, with a limited number of total allocations, and a sunset clause. To that end, I support 2005-1 as written. From tony.li at tony.li Sat Feb 11 15:12:18 2006 From: tony.li at tony.li (Tony Li) Date: Sat, 11 Feb 2006 12:12:18 -0800 Subject: [ppml] Version think... was: alternative to 2005-1 In-Reply-To: <20060211183107.E768E11425@sa.vix.com> References: <10EC6E2B7F67A525F376E075@imac-en0.delong.sj.ca.us> <43EE2470.2070106@tony.li> <20060211183107.E768E11425@sa.vix.com> Message-ID: <43EE4522.1070902@tony.li> Paul, > It's no less practical than IPv4, and look how much bigger the current IPv4 > internet is than could be guessed at by _its_ original architecture. It actually is significantly less practical, in the sense that the routing subsystem overhead for IPv6 is much higher on a per-prefix basis than it is for IPv4, and because so much of the v6 topology is simply a subset of the v4 topology. Since both versions draw from the same finite pool of routing subsystem resources, one has to ask whether those resources are being most efficiently exploited by adding v6 in its current state. It should also be noted that the v4 architecture blossomed and grew precisely because the architecture was adaptable and fungable, with the blessings of the IAB precisely because they understood that mutation was necessary for evolution. The reticence of the current IAB to accept reality and morph to meet the need results in an architectural rigidity that dictates that v6 will never be more than exactly what we have today. > The decision to poor good money after bad on IPv6 was made early on, and then > re-made, and will yet be re-made, many times over its lifetime. I'm struck by > the fact that while all practitioners of routing knew that "without rapid > renumbering, IPv6 is undeployable", the IAB did not know this and no doubt > still does not know this. Perhaps the fundamental flaw in this architecture > came about when the RIR communities were _not_ directly involved in vetting > it, and if so, simply passing the problem back to the IETF will at best cause > the same errors (or compatible errors) to be repeated. The point that I am trying to make is that right here, right now, is an opportunity for the RIR community to vet the result, and return it for revision if necessary. > In that sense, there is hope. While we expect the absolute number of > endpoints to grow under IPv6, most of the growth will be in handhelds and > TV remote controls other locked-in devices, not in home LINUX servers or in > multihomed enterprises. A policy like 2005-1 that allowed the dwindling (as > a share of the total) number of endpoints to receive multihomable/rehomable > PI space might actually be "all it'll take" to "solve" this whole problem. > Sadly, we won't know what it'll take until we get there or get close, and > as long as we reject PI requests for multihomable/rehomable space, we're > holding IPv6's head underwater. 2005-1 is experimental, with a limited number > of total allocations, and a sunset clause. My concern is that the proliferation of wireless technology, the continued rapid deployment in countries that are population dense and Internet poor (e.g., India & China), the increasing reliance of all sites on Internet technology with the subsequent increased interest in multihoming point me to a rapid increase in multihoming, not a decrease. If this does happen while we lack a real multihoming solution, we will end up in a situation of imminent implosion very quickly. I should note that fixing this problem is NOT impossible. The IETF has the technology in its archives to remedy these issues. I know that arguing about what to do and how to do it will take some years, but the actual implementation of what has been suggested (e.g., 8+8, address-agile transport protocols) seems like it still relatively minor compared to the amount of work still to be done in deploying v6. Tony From randy at psg.com Sat Feb 11 15:44:23 2006 From: randy at psg.com (Randy Bush) Date: Sat, 11 Feb 2006 10:44:23 -1000 Subject: [ppml] Version think... was: alternative to 2005-1 References: <10EC6E2B7F67A525F376E075@imac-en0.delong.sj.ca.us> <43EE2470.2070106@tony.li> <20060211183107.E768E11425@sa.vix.com> <43EE4522.1070902@tony.li> Message-ID: <17390.19623.819727.167318@roam.psg.com> > I should note that fixing this problem is NOT impossible. The IETF has > the technology in its archives to remedy these issues. I know that > arguing about what to do and how to do it will take some years, but the > actual implementation of what has been suggested (e.g., 8+8, > address-agile transport protocols) seems like it still relatively minor > compared to the amount of work still to be done in deploying v6. what he said! randy From Michael.Dillon at btradianz.com Mon Feb 13 05:04:43 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Mon, 13 Feb 2006 10:04:43 +0000 Subject: [ppml] Proposed Policy: Capturing Originations in Templates In-Reply-To: Message-ID: > That's what the ARIN RR _is_. ARIN has been operating a routing registry > for several years. As Owen just pointed out. > > > ...they have the potential of solving the stale data problem. > > How so? What policy would you enact to give ARIN the lattitude to "solve > the problem" of the data people publish through routing registries? Think of Rwhois and the ARIN whois directory. Some companies file information with ARIN via SWIP and some run their own rwhois servers. But the information which is published in these directories is defined by ARIN policy and the policy mandates that the information must be published. Now, back to the original policy proposal. They were suggesting an extension of the ARIN mandate to include a list of AS numbers which might announce that prefix. Yes, I know the proposal said it was optional, but the point is that the writer wanted this AS number info included in the whois/rwhois framework. I feel that information about potential route announcements doesn't need to be in whois because there are route registries to cover that sort of thing. But I recognize that the route registries are in some chaos at present and that ARIN does not operate a route registry other than as an afterthought. We could mandate ARIN to operate an authoritative route registry that does not mirror any other route registry, i.e. it is the source to mirrors but does not draw from them. We could mandate address block holders to file information in the ARIN RR and keep that information up to date. If we did this then there would be no need to add new fields to the whois directory. So I guess I am arguing that the information requested has more to do with routing topology than with address block ownership, therefore we should solve it by making changes to routing registry policy, not whois policy. --Michael Dillon From Michael.Dillon at btradianz.com Mon Feb 13 05:14:32 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Mon, 13 Feb 2006 10:14:32 +0000 Subject: [ppml] alternative to 2005-1 In-Reply-To: Message-ID: > > IMHO, a good policy would deal with each case separately. > What if we break this up into two policies? I assume you mean two proposals. That would be bad. You would need to duplicate much of the explanation and justification text. Just structure the policy so that orgs with a pre-existing IPv4 PI block automatically get an IPv6 PI block with no questions asked. Any worries about land rush are dealt with by the IPv4 policy. And any policy which does NOT give out IPv6 PI blocks to existing IPv4 PI holders is penalizing early adopters which is wrong. Then, talk about how orgs with no previous IPv4 blocks can get an IPv6 PI block. After all we don't want them to get IPv4 PI when their real need is for IPv6. In this case, there is some danger of a land rush so the policymakers (us) need to think about how to make some hurdles to keep it manageable. > One could be along the lines > of what Andrew proposed at the beginning of this thread, and would give > IPv6 PI space to those who have (or qualify for) IPv4 PI space. IMO this > is urgent, and should be done at Montreal if possible. A policy structured in two parts, could lead to a straw poll for each separate part if there was a distinct difference in support for each part. I don't believe it is necessary to make separate proposals, just structure the proposal so that it is easier to focus the discussion. On the other hand, if I felt strongly about this I would have submitted my own suggested wording. Since I haven't done so, feel free to carry this forward as you wish. It's politics. --Michael Dillon From sleibrand at internap.com Mon Feb 13 09:10:13 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Mon, 13 Feb 2006 09:10:13 -0500 (EST) Subject: [ppml] Policy Proposal 2005-1: Provider-independent IPv6 Assignments for End Sites - revised text In-Reply-To: <43ECC2E7.3040806@arin.net> References: <43ECC2E7.3040806@arin.net> Message-ID: I support this latest revision of 2005-1, as it addresses most of the concerns raised thus far by myself and others. I would actually prefer that we use Owen & Kevin's 6.5.8.1 wording, combined with Andrew's 6.5.8.2 and 6.5.8.3 wording, but I would also support this revision of 2005-1 as written. -Scott On 02/10/06 at 11:44am -0500, Member Services wrote: > Policy Proposal 2005-1: Provider-independent IPv6 Assignments for End > Sites has been revised by the authors. This proposal is open for > discussion on this mailing list and will be on the agenda at the > upcoming ARIN Public Policy Meeting. > > The current policy proposal text is provided below and is also available > at: http://www.arin.net/policy/proposals/2005_1.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ### * ### > > > Policy Proposal 2005-1: Provider-independent IPv6 Assignments for End Sites > > Author: Owen Delong, Kevin Loch > > Proposal Version: 3 (2006-02-09) > > Proposal type: modify > > Policy term: permanent > > Policy statement: > > Add new subsection in section 6.5 of the NRPM: > > 6.5.8. Direct assignments to end sites > > 6.5.8.1. To qualify for a direct assignment, an > organization must: > > a) not be an IPv6 LIR; and > b) Qualify for an IPv4 assignment or allocation from ARIN under > the IPv4 policy currently in effect. > > 6.5.8.2. Direct assignment size to end sites > > Organizations that meet the direct end site assignment criteria > are eligible to receive a direct assignment. The minimum size > of the assignment is /48. Organizations requesting a larger > assignment must provide documentation justifying the need for > additional subnets. > > 6.5.8.3. Subsequent Assignment Size > > Additional assignments may be made when the need for additional > subnets is justified. When possible assignments will be made > from an adjacent address block. > > Rationale: > > In IPv4 policy there are three main types of organizations that > addresses are delegated to. > > o ISP's receive allocations directly from ARIN or from other ISP's > o End Users receive assignments from ISP's > o Large and/or multihomed End Users receive assignments directly from > ARIN. > > The third category is currently missing from IPv6 policy and this is > believed to be severely hindering deployment by those organizations. In > IPv6 policy-speak: > > o LIR's receive allocations directly from ARIN > o End Sites receive assignments from LIR's > > This policy proposes: > > o Large and/or multihomed End Sites receive assignments directly > from ARIN. > > This policy applies to organizations with networks that are large > and/or multihomed. Like their IPv4 counterparts they do not make > assignments to external organizations. They instead assign space > internally to their own facilities. Similarly to IPv4 These internal > assignments are not submitted to ARIN via swip/rwhois. > > For transition purposes an organization that qualifies for IPv4 space > today is considered elligible, regardless of whether they were > considered an ISP or End User under IPv4 policy. It is expected that > the IPv6 only (non transition) requirements will be developed as > experience is gained. > > It is reommended that these assignments be made from a separate address > block set aside for this purpose and that at least a /44 be reserved > around each assignment for possible expansion. One bit should be > reserved around assignments /44 and larger. > > Timetable for implementation: immediately > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From sleibrand at internap.com Mon Feb 13 09:13:58 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Mon, 13 Feb 2006 09:13:58 -0500 (EST) Subject: [ppml] Proposed Policy: IPv6 Direct PI Assignments for End Sites In-Reply-To: <43ECB0A1.2060002@arin.net> References: <43ECB0A1.2060002@arin.net> Message-ID: I support this policy proposal, though I prefer the latest revision of 2005-1 because IMO it has better conditions in 6.5.8.1. I would ideally prefer a hybrid proposal using 2005-1's 6.5.8.1 wording and Andrew's 6.5.8.2 and 6.5.8.3 wording. -Scott On 02/10/06 at 10:26am -0500, Member Services wrote: > ARIN received the following proposed policy. In accordance with the ARIN > Internet Resource Policy Evaluation Process, the proposal is being > posted to the ARIN Public Policy Mailing List and being placed on ARIN's > website. > > The ARIN Advisory Council (AC) will review the proposal and within ten > working days may decide to: > 1) Support the proposal as is, > 2) Work with the author to clarify, divide or combine one or more > policy proposals, or > 3) Not support the policy proposal. > > If the AC supports the proposal or reaches an agreement to work with the > author, then the proposal will be posted as a formal policy proposal to > the Public Policy Mailing List and it will be presented at the Public > Policy Meeting. If the AC does not support the proposal, then the author > may elect to use the petition process to advance the proposal. If the > author elects not to petition or the petition fails, then the proposed > policy 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: IPv6 Direct PI Assignments for End Sites > > Author: Andrew Dul > > Proposal type: new > > Policy term: permanent > > Policy statement: > > Add new subsection to the NRPM: > > 6.5.8. Direct assignments to end sites > > 6.5.8.1. To qualify for a direct end site assignment, an > organization must meet all of the following criteria: > > 1. not be an LIR; > 2. be an end site; > 3. be currently multihomed using IPv4; > 4. have a direct assignment from ARIN of at least a IPv4 /19 and > can show the current utilization of 80% of an IPv4 /19 equivalent. > > 6.5.8.2. Direct assignment size to end sites > > Organizations that meet the direct end site assignment criteria > are eligible to receive a direct assignment of /48 out of a reserved > /44. Direct Assignments shall be allocated from a separate super-block > to allow for LIRs to filter. > > 6.5.8.3. Subse quent direct assignments to end sites > > Organizations assignment size may be increased by 1 bit (to a > maximum of /44) when they demonstrate the active usage of 50% of the > assigned /64 subnets. > > Only one direct assignment may be made to an end site > organization under Section 6.5.8. > > Organizations which can demonstrate active usage of more than 50% > of /64 networks from a /44 assignment shall qualify for an additional > allocation as an LIR. > > Rationale: > > This policy is proposed as an alternative to the existing 2005-1 policy > proposal. This policy is intended to be more conservative that the > existing proposed 2005-1 policy. While this policy does allow PI > assignments to end-sites, it limits the scope to current IPv4 holders > with direct assignments. A more conservative policy is desirable as the > first IPv6 PI policy. > > Current ARIN policy does not permit an end-site from obtaining a > Provider Independent IPv6 address block directly from ARIN. There is > currently no viable IPv6 multihoming method available for these > end-sites. Shim6 & other methods have been proposed as a possible > method to meet multihoming requirements. Today, no implementation or > alternatives exist to ?traditional? IPv4 multihoming which announces > unique address space from an ASN. > > The largest end-sites (corporations & content providers) have the > greatest to gain and/or lose by not having an available method to > multihome. While IPv6 provides for stateless auto configuration for end > hosts, no new methods for renumbering the infrastructure are available. > The cost and complexity of renumbering these large organizations makes > it essential to provide stable address resources which are not assigned > from a LIR. > > The lack of an end-site assignment policy is currently preventing the > real planning and deployment of IPv6 networks in these organizations. > > Other policy proposals (2005-1) addressing this issue have been > presented at the ARIN 15 & 16 meetings. This policy proposal attempts > to address the issues that were raised on the ppml mailing list and at > the public policy meetings for 2005-1. > > Specifically, the main issue surrounding the creation of consensus on > this policy appears to be the criteria for which end-sites should be > able to obtain an endsite assignment. Concerns have been raised about > the creation of a new IPv6 ?swamp? by having a policy that is too > lenient. This issue is addressed in the policy by limiting the endsite > assignments to current organizations with a modest IPv4 assignment. > > The assignment of IPv4 resources is orthogonal to the assignment of IPv6 > addresses. However, the use of existing IPv4 assignments and ARIN > membership are postulated as an appropriate regulator for the initial > assignments under an IPv6 endsite policy. It is reasonable to consider > changes to the membership and IPv4 assignment requirements in the > future. This review should be conducted after the endsite assignment > policy has been in place long enough to understand the demand for > endsite IPv6 assignments and the development of IPv6 networks have matured. > This policy proposal does not attempt to address the assignment needs > for endsites which currently do not have IPv4 assignments. > > Timetable for implementation: within 90 days of approval by the BoT > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From iggy at merit.edu Mon Feb 13 09:26:55 2006 From: iggy at merit.edu (Glenn Wiltse) Date: Mon, 13 Feb 2006 09:26:55 -0500 (EST) Subject: [ppml] Version think... was: alternative to 2005-1 In-Reply-To: <20060211183107.E768E11425@sa.vix.com> References: <10EC6E2B7F67A525F376E075@imac-en0.delong.sj.ca.us> <43EE2470.2070106@tony.li> <20060211183107.E768E11425@sa.vix.com> Message-ID: Just exactly how does 2005-1 as is currently written limit the total number of allocations and the duration of how long this policy would exist? If this is really the case, I might actualy be able to support it myself, but I just don't see it that way right now. Glenn Wiltse On Sat, 11 Feb 2006, Paul Vixie wrote: > 2005-1 is experimental, with a limited number of total allocations, and > a sunset clause. > > To that end, I support 2005-1 as written. From paul at vix.com Mon Feb 13 10:02:13 2006 From: paul at vix.com (Paul Vixie) Date: Mon, 13 Feb 2006 15:02:13 +0000 Subject: [ppml] Version think... was: alternative to 2005-1 In-Reply-To: Your message of "Mon, 13 Feb 2006 09:26:55 EST." References: <10EC6E2B7F67A525F376E075@imac-en0.delong.sj.ca.us> <43EE2470.2070106@tony.li> <20060211183107.E768E11425@sa.vix.com> Message-ID: <20060213150213.C0E0D1142D@sa.vix.com> # Just exactly how does 2005-1 as is currently written limit the total # number of allocations and the duration of how long this policy would exist? i had my proposals mixed up. this one doesn't have a sunset clause or an experimental limit, and needs one. # If this is really the case, I might actualy be able to support it # myself, but I just don't see it that way right now. "oops." re: # > 2005-1 is experimental, with a limited number of total allocations, and # > a sunset clause. # > # > To that end, I support 2005-1 as written. From sleibrand at internap.com Mon Feb 13 10:07:26 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Mon, 13 Feb 2006 10:07:26 -0500 (EST) Subject: [ppml] Version think... was: alternative to 2005-1 In-Reply-To: <20060213150213.C0E0D1142D@sa.vix.com> References: <10EC6E2B7F67A525F376E075@imac-en0.delong.sj.ca.us> <43EE2470.2070106@tony.li> <20060211183107.E768E11425@sa.vix.com> <20060213150213.C0E0D1142D@sa.vix.com> Message-ID: Paul, The latest revision of 2005-1 only gives out IPv6 PI space to orgs who qualify for IPv4 PI space. It no longer gives it to anyone who's multihomed with IPv6. Do you still think it needs a sunset clause? -Scott On 02/13/06 at 3:02pm -0000, Paul Vixie wrote: > # Just exactly how does 2005-1 as is currently written limit the total > # number of allocations and the duration of how long this policy would exist? > > i had my proposals mixed up. this one doesn't have a sunset clause or an > experimental limit, and needs one. > > # If this is really the case, I might actualy be able to support it > # myself, but I just don't see it that way right now. > > "oops." > > re: > > # > 2005-1 is experimental, with a limited number of total allocations, and > # > a sunset clause. > # > > # > To that end, I support 2005-1 as written. > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From paul at vix.com Mon Feb 13 10:18:28 2006 From: paul at vix.com (Paul Vixie) Date: Mon, 13 Feb 2006 15:18:28 +0000 Subject: [ppml] Version think... was: alternative to 2005-1 In-Reply-To: Your message of "Mon, 13 Feb 2006 10:07:26 EST." References: <10EC6E2B7F67A525F376E075@imac-en0.delong.sj.ca.us> <43EE2470.2070106@tony.li> <20060211183107.E768E11425@sa.vix.com> <20060213150213.C0E0D1142D@sa.vix.com> Message-ID: <20060213151828.BBC1D1142B@sa.vix.com> scott wrote me an open letter: # The latest revision of 2005-1 only gives out IPv6 PI space to orgs who # qualify for IPv4 PI space. It no longer gives it to anyone who's # multihomed with IPv6. Do you still think it needs a sunset clause? sadly, yes i do. there has been reasonable debate here as to the long term viability of a "let ipv6 have an ipv4-like swamp" strategy. until we know either that (a) that won't happen, or (b) it's no big deal, any PI policy for ipv6 really should be experimental/limited. my own belief is that we will see a small number of initial allocations, then nothing for a long time, and that the only real effect of 2005-1 will be to end the complaints about how broken IPv6 is and how PI space is needed. but, let's find out! paul From sleibrand at internap.com Mon Feb 13 10:26:09 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Mon, 13 Feb 2006 10:26:09 -0500 (EST) Subject: [ppml] Version think... was: alternative to 2005-1 In-Reply-To: <20060213151828.BBC1D1142B@sa.vix.com> References: <10EC6E2B7F67A525F376E075@imac-en0.delong.sj.ca.us> <43EE2470.2070106@tony.li> <20060211183107.E768E11425@sa.vix.com> <20060213150213.C0E0D1142D@sa.vix.com> <20060213151828.BBC1D1142B@sa.vix.com> Message-ID: On 02/13/06 at 3:18pm -0000, Paul Vixie wrote: > scott wrote me an open letter: > > # The latest revision of 2005-1 only gives out IPv6 PI space to orgs who > # qualify for IPv4 PI space. It no longer gives it to anyone who's > # multihomed with IPv6. Do you still think it needs a sunset clause? > > sadly, yes i do. there has been reasonable debate here as to the long term > viability of a "let ipv6 have an ipv4-like swamp" strategy. until we know > either that (a) that won't happen, or (b) it's no big deal, any PI policy > for ipv6 really should be experimental/limited. my own belief is that we > will see a small number of initial allocations, then nothing for a long > time So if we assume your belief may prove correct, it would seem that what we need is to limit the number of PI allocations that can be made under the policy, rather than limiting the lifetime of the policy. If we set such a limit high enough, I wouldn't object to that. What number would you propose? > and that the only real effect of 2005-1 will be to end the complaints > about how broken IPv6 is and how PI space is needed. but, let's find > out! Yes, let's. I really think we should pass some sort of IPv6 PI policy at Montreal. If limiting the number of PI allocations allowed under the policy makes that possible by making the policy more palatable to a wider audience, I'm all for it. I just want to make sure that we don't set the limit too low. -Scott From tme at multicasttech.com Mon Feb 13 10:33:18 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Mon, 13 Feb 2006 10:33:18 -0500 Subject: [ppml] Version think... was: alternative to 2005-1 In-Reply-To: <20060213151828.BBC1D1142B@sa.vix.com> References: <10EC6E2B7F67A525F376E075@imac-en0.delong.sj.ca.us> <43EE2470.2070106@tony.li> <20060211183107.E768E11425@sa.vix.com> <20060213150213.C0E0D1142D@sa.vix.com> <20060213151828.BBC1D1142B@sa.vix.com> Message-ID: Hello; On Feb 13, 2006, at 10:18 AM, Paul Vixie wrote: > scott wrote me an open letter: > > # The latest revision of 2005-1 only gives out IPv6 PI space to > orgs who > # qualify for IPv4 PI space. It no longer gives it to anyone who's > # multihomed with IPv6. Do you still think it needs a sunset clause? > I personally think that the proposal is morphing too rapidly for the safety of the debate on it. I missed the part where the consensus swung away from PI space for IPv6 multihomers. I think that's needed. I agree, a sunset clause is needed (or, at least, advisable) either way. > sadly, yes i do. there has been reasonable debate here as to the > long term > viability of a "let ipv6 have an ipv4-like swamp" strategy. until > we know > either that (a) that won't happen, or (b) it's no big deal, any PI > policy > for ipv6 really should be experimental/limited. my own belief is > that we > will see a small number of initial allocations, then nothing for a > long > time, and that the only real effect of 2005-1 will be to end the > complaints Would that not be a good thing ? If all this discussion did were to end some class of complaints, I would feel it was worthwhile. > about how broken IPv6 is and how PI space is needed. but, let's > find out! > Yes, indeed. > paul Marshall > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From iggy at merit.edu Mon Feb 13 10:39:05 2006 From: iggy at merit.edu (Glenn Wiltse) Date: Mon, 13 Feb 2006 10:39:05 -0500 (EST) Subject: [ppml] Version think... was: alternative to 2005-1 In-Reply-To: References: <10EC6E2B7F67A525F376E075@imac-en0.delong.sj.ca.us> <43EE2470.2070106@tony.li> <20060211183107.E768E11425@sa.vix.com> <20060213150213.C0E0D1142D@sa.vix.com> <20060213151828.BBC1D1142B@sa.vix.com> Message-ID: As much as I'd like to join you guys in suggesting that we just pass something no matter how bad it is... I can't. Glenn Wiltse On Mon, 13 Feb 2006, Scott Leibrand wrote: > On 02/13/06 at 3:18pm -0000, Paul Vixie wrote: >> and that the only real effect of 2005-1 will be to end the complaints >> about how broken IPv6 is and how PI space is needed. but, let's find >> out! > > Yes, let's. I really think we should pass some sort of IPv6 PI policy at > Montreal. If limiting the number of PI allocations allowed under the > policy makes that possible by making the policy more palatable to a wider > audience, I'm all for it. I just want to make sure that we don't set the > limit too low. > > -Scott > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > > !DSPAM:43f0a524244761125017983! > > From sleibrand at internap.com Mon Feb 13 10:44:31 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Mon, 13 Feb 2006 10:44:31 -0500 (EST) Subject: [ppml] Version think... was: alternative to 2005-1 In-Reply-To: References: <10EC6E2B7F67A525F376E075@imac-en0.delong.sj.ca.us> <43EE2470.2070106@tony.li> <20060211183107.E768E11425@sa.vix.com> <20060213150213.C0E0D1142D@sa.vix.com> <20060213151828.BBC1D1142B@sa.vix.com> Message-ID: Glenn, What do you think is bad about the current revision of 2005-1? Do you prefer Andrew's /19 threshold? Or do you have broader objections? -Scott On 02/13/06 at 10:39am -0500, Glenn Wiltse wrote: > As much as I'd like to join you guys in suggesting that > we just pass something no matter how bad it is... I can't. > > Glenn Wiltse > > On Mon, 13 Feb 2006, Scott Leibrand wrote: > > > On 02/13/06 at 3:18pm -0000, Paul Vixie wrote: > >> and that the only real effect of 2005-1 will be to end the complaints > >> about how broken IPv6 is and how PI space is needed. but, let's find > >> out! > > > > Yes, let's. I really think we should pass some sort of IPv6 PI policy at > > Montreal. If limiting the number of PI allocations allowed under the > > policy makes that possible by making the policy more palatable to a wider > > audience, I'm all for it. I just want to make sure that we don't set the > > limit too low. > > > > -Scott > > _______________________________________________ > > PPML mailing list > > PPML at arin.net > > http://lists.arin.net/mailman/listinfo/ppml > > > > !DSPAM:43f0a524244761125017983! > > > > > From woody at pch.net Mon Feb 13 10:54:51 2006 From: woody at pch.net (Bill Woodcock) Date: Mon, 13 Feb 2006 07:54:51 -0800 (PST) Subject: [ppml] Proposed Policy: Capturing Originations in Templates In-Reply-To: References: Message-ID: Understand that I'm mostly arguing to tease out specifics, and not because I'm really this ornery. On Mon, 13 Feb 2006 Michael.Dillon at btradianz.com wrote: > We could mandate ARIN to operate an authoritative route > registry that does not mirror any other route registry. Isn't that how it's already run? http://www.arin.net/registration/route_reg/ http://www.arin.net/education/faq/rr.html I don't see any indication that records enter the registry via any method other than direct user submission right now. > We could mandate address block holders to file information > in the ARIN RR and keep that information up to date. What's the carrot? What's the stick? Could they submit anything, or would it have to somehow relate to reality? Whose job is it to check on that? > If we did this then there would be no need to add new fields > to the whois directory. That's arguably the case, anyway. > So I guess I am arguing that the information requested has > more to do with routing topology than with address block > ownership Hm. I hadn't thought about it in those terms before, but I see your point. > therefore we should solve it by making changes > to routing registry policy, not whois policy. Yeah, I agree with that. So much for being devil's advocate. -Bill From Michael.Dillon at btradianz.com Mon Feb 13 11:23:12 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Mon, 13 Feb 2006 16:23:12 +0000 Subject: [ppml] Version think... was: alternative to 2005-1 In-Reply-To: Message-ID: > Just exactly how does 2005-1 as is currently written limit the total > number of allocations and the duration of how long this policy would > exist? ARIN policies typically do not have expiry dates because if there is need for a policy to "expire" this can be accomplished by changing the policy. Since the policy requires the applicant to meet the requirements of the existing IPv4 policy, it interits the limits inherent in that policy. One of the main limits is the time required for ARIN staff to analyze an application an make a decision. They are not likely to greatly increase the number of allocations as compared to historical levels. --Michael Dillon From Michael.Dillon at btradianz.com Mon Feb 13 11:29:59 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Mon, 13 Feb 2006 16:29:59 +0000 Subject: [ppml] Version think... was: alternative to 2005-1 In-Reply-To: <20060213151828.BBC1D1142B@sa.vix.com> Message-ID: > sadly, yes i do. there has been reasonable debate here as to the long term > viability of a "let ipv6 have an ipv4-like swamp" strategy. Until the opponents of an IPv6 swamp define what a "swamp" is and why it is bad, you are likely to gain few supporters. Oh, and it wouldn't hurt to explain why you consider that a particular policy proposal will lead to a bad swamp. In the absence of this type of explanation, few people on this list will understand what you mean. > any PI policy > for ipv6 really should be experimental/limited. All ARIN policies are limited in the sense that no policies are sacred and unchangeable. When things change and a policy needs to go away or change into something else, the PPML can take up the charge. Let's not forget that there are intelligent human beings implementing these policies under an intelligent board of trustees. Can we not assume that these people will limit the damage if there is a run on the bank? If not, then perhaps we need a policy that allows the trustees to suspend allocations in the same way that the New York Stock Exchange can suspend trading of a share in unusual circumstances. --Michael Dillon From Michael.Dillon at btradianz.com Mon Feb 13 11:53:37 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Mon, 13 Feb 2006 16:53:37 +0000 Subject: [ppml] Proposed Policy: Capturing Originations in Templates In-Reply-To: Message-ID: > Understand that I'm mostly arguing to tease out specifics, and not because > I'm really this ornery. ditto. > > We could mandate ARIN to operate an authoritative route > > registry that does not mirror any other route registry. > Isn't that how it's already run? I don't use it so I don't know. But I do know that RRs can and do mirror entries from other RRs. I don't think that is good for ARIN to do unless they mirror other RIR RRs. > > We could mandate address block holders to file information > > in the ARIN RR and keep that information up to date. > What's the carrot? What's the stick? Could they submit anything, or > would it have to somehow relate to reality? Whose job is it to check on > that? Seems to me that there is not much carrot to encourage up to date whois listings either. In any case, the carrot here is that we need a 3rd party to collect and disseminate information about which routes are correct if they appear in BGP announcements. ARIN seems to be an ideal 3rd party because of their pre-existing relationship with all ASN holders and all holders of address blocks. If ARIN and its membership accept this role, then I believe it should be ARIN's job to check the quality of the data going into the RR to ensure that it is as clean as possible. I thnk Sandra's policy has the germ of a good idea in it, but the effort would be better spent in revitalizing the RR rather than adding this info to whois. --Michael Dillon From iggy at merit.edu Mon Feb 13 11:54:38 2006 From: iggy at merit.edu (Glenn Wiltse) Date: Mon, 13 Feb 2006 11:54:38 -0500 (EST) Subject: [ppml] Version think... was: alternative to 2005-1 In-Reply-To: References: <10EC6E2B7F67A525F376E075@imac-en0.delong.sj.ca.us> <43EE2470.2070106@tony.li> <20060211183107.E768E11425@sa.vix.com> <20060213150213.C0E0D1142D@sa.vix.com> <20060213151828.BBC1D1142B@sa.vix.com> Message-ID: I have broader objections. As stated elsewhere... In general I don't think creating IPv6 policy based on IPv4 policy requirements is a good idea. I am not convinced it's a good idea to give IPv6-PI space to any orginization that can not show a imediate need for more then a single /48. I don't like the non-exsistant description of just exactly how a originization would ever qualify for more then a single /48. This seems to give ARIN staff nearly unlimited discretion as to what is acceptable distribution of /64s within a orgization, and takes it out of the hands of public policy groups. I'm not convinced that current routing protocols will handle wide spread use of /48 PI assignments. It seems to me that if ARIN passes this type of policy, it is in effect forcing the internet community as a whole, to deal with the consequences of such assignments. I'm not sure it's ARIN's place to force such a showdown. Perhaps I would feel better about such things, if all RIRs passed simmilar policys simultainously... I just don't feel like ARIN should be the trend setter with what I feel is a very liberal policy of giving out /48 sized blocks of IPv6-PI space. However I don't think you could gain anything aproaching consensus in the world wide community for 2005-1 as it's currently written. If 2005-1 passes at ARIN XVII, I feel it will be largely because people may simply say... 'we must pass something with regard to IPv6 PI space'. I would seriouly hate to think that we start adopting policy simply because we couldn't come up with something better. Glenn Wiltse On Mon, 13 Feb 2006, Scott Leibrand wrote: > Glenn, > > What do you think is bad about the current revision of 2005-1? Do you > prefer Andrew's /19 threshold? Or do you have broader objections? > > -Scott > > On 02/13/06 at 10:39am -0500, Glenn Wiltse wrote: > >> As much as I'd like to join you guys in suggesting that >> we just pass something no matter how bad it is... I can't. >> >> Glenn Wiltse >> >> On Mon, 13 Feb 2006, Scott Leibrand wrote: >> >>> On 02/13/06 at 3:18pm -0000, Paul Vixie wrote: >>>> and that the only real effect of 2005-1 will be to end the complaints >>>> about how broken IPv6 is and how PI space is needed. but, let's find >>>> out! >>> >>> Yes, let's. I really think we should pass some sort of IPv6 PI policy at >>> Montreal. If limiting the number of PI allocations allowed under the >>> policy makes that possible by making the policy more palatable to a wider >>> audience, I'm all for it. I just want to make sure that we don't set the >>> limit too low. >>> >>> -Scott >>> _______________________________________________ >>> PPML mailing list >>> PPML at arin.net >>> http://lists.arin.net/mailman/listinfo/ppml >>> >>> >>> >>> >> > > !DSPAM:43f0acf126183167036266! > > From sleibrand at internap.com Mon Feb 13 12:17:17 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Mon, 13 Feb 2006 12:17:17 -0500 (EST) Subject: [ppml] Version think... was: alternative to 2005-1 In-Reply-To: References: <10EC6E2B7F67A525F376E075@imac-en0.delong.sj.ca.us> <43EE2470.2070106@tony.li> <20060211183107.E768E11425@sa.vix.com> <20060213150213.C0E0D1142D@sa.vix.com> <20060213151828.BBC1D1142B@sa.vix.com> Message-ID: On 02/13/06 at 11:54am -0500, Glenn Wiltse wrote: > I have broader objections. As stated elsewhere... > > In general I don't think creating IPv6 policy based on IPv4 policy > requirements is a good idea. Maybe not in the long term, but I think it's the best way to migrate from IPv4 to IPv6. For users who're starting up with IPv6 in the future we'll need a different policy, but I don't think we're at the point yet where we can reach consensus on what that policy should be. > I am not convinced it's a good idea to give IPv6-PI space to any > organization that can not show a immediate need for more then a single /48. As I and others have stated before, I think the determinant of whether an org needs PI space should be difficulty of renumbering, not strictly the size of the netblock needed. > I don't like the non-existent description of just exactly how a > organization would ever qualify for more then a single /48. This > seems to give ARIN staff nearly unlimited discretion as to what is > acceptable distribution of /64s within a organization, and takes it > out of the hands of public policy groups. How is this different than the rules for LIRs giving out >/48 allocations? > I'm not convinced that current routing protocols will handle wide spread > use of /48 PI assignments. It seems to me that if ARIN passes this type of > policy, it is in effect forcing the internet community as a whole, to deal > with the consequences of such assignments. I'm not sure it's ARIN's place > to force such a showdown. How many IPv4 PI blocks have been assigned? What would happen to the routing table if we introduced that many IPv6 PI blocks? IMO "not much". > Perhaps I would feel better about such things, if all RIRs passed > similar polices simultaneously... I just don't feel like ARIN should be > the trend setter with what I feel is a very liberal policy of giving out > /48 sized blocks of IPv6-PI space. However I don't think you could gain > anything approaching consensus in the world wide community for 2005-1 as > it's currently written. Well, if other RIRs pass different policies, we can look into standardizing with them. But IMO giving IPv6 PI space to those who qualify for IPv4 PI space is not "very liberal", but rather is a conservative first step to allow enterprises currently multihomed with PI space to start implementing IPv6. > If 2005-1 passes at ARIN XVII, I feel it will be largely because people > may simply say... 'we must pass something with regard to IPv6 PI space'. > I would seriously hate to think that we start adopting policy simply > because we couldn't come up with something better. I think a more accurate statement would be that if the latest revision of 2005-1 passes at ARIN XVII, it will be because people acknowledge that the lack of provider independent multihoming capabilities is hindering the adoption of IPv6, and that people agree that allowing orgs that multihome with IPv4 PI space to do so with IPv6 PI space is a good first step to rectifying that problem. It's not a complete solution to the IPv6 multihoming problem, so some people will say we're not going far enough. But IMO moving ahead in a stepwise fashion is the prudent course, and the one most likely to achieve consensus. -Scott > On Mon, 13 Feb 2006, Scott Leibrand wrote: > > > Glenn, > > > > What do you think is bad about the current revision of 2005-1? Do you > > prefer Andrew's /19 threshold? Or do you have broader objections? > > > > -Scott > > > > On 02/13/06 at 10:39am -0500, Glenn Wiltse wrote: > > > >> As much as I'd like to join you guys in suggesting that > >> we just pass something no matter how bad it is... I can't. > >> > >> Glenn Wiltse > >> > >> On Mon, 13 Feb 2006, Scott Leibrand wrote: > >> > >>> On 02/13/06 at 3:18pm -0000, Paul Vixie wrote: > >>>> and that the only real effect of 2005-1 will be to end the complaints > >>>> about how broken IPv6 is and how PI space is needed. but, let's find > >>>> out! > >>> > >>> Yes, let's. I really think we should pass some sort of IPv6 PI policy at > >>> Montreal. If limiting the number of PI allocations allowed under the > >>> policy makes that possible by making the policy more palatable to a wider > >>> audience, I'm all for it. I just want to make sure that we don't set the > >>> limit too low. > >>> > >>> -Scott > >>> _______________________________________________ > >>> PPML mailing list > >>> PPML at arin.net > >>> http://lists.arin.net/mailman/listinfo/ppml > >>> > >>> > >>> > >>> > >> > > > > !DSPAM:43f0acf126183167036266! > > > > > From paul at vix.com Mon Feb 13 12:25:53 2006 From: paul at vix.com (Paul Vixie) Date: Mon, 13 Feb 2006 17:25:53 +0000 Subject: [ppml] Version think... was: alternative to 2005-1 In-Reply-To: Your message of "Mon, 13 Feb 2006 10:26:09 EST." References: <10EC6E2B7F67A525F376E075@imac-en0.delong.sj.ca.us> <43EE2470.2070106@tony.li> <20060211183107.E768E11425@sa.vix.com> <20060213150213.C0E0D1142D@sa.vix.com> <20060213151828.BBC1D1142B@sa.vix.com> Message-ID: <20060213172553.7336C11435@sa.vix.com> # So if we assume your belief may prove correct, it would seem that what we # need is to limit the number of PI allocations that can be made under the # policy, rather than limiting the lifetime of the policy. If we set such a # limit high enough, I wouldn't object to that. What number would you # propose? the usual round number thrown out in times like this is "20". which suits me fine, but a lot of other round numbers would also suit me fine, like "200". ARIN needs to get some utilization experience, and the inevitable side effects of getting that kind of experience are: (a) a swamp of some size, and (b) an early-adopter advantage. # > and that the only real effect of 2005-1 will be to end the complaints # > about how broken IPv6 is and how PI space is needed. but, let's find # > out! # # Yes, let's. I really think we should pass some sort of IPv6 PI policy at # Montreal. If limiting the number of PI allocations allowed under the policy # makes that possible by making the policy more palatable to a wider audience, # I'm all for it. I just want to make sure that we don't set the limit too # low. but how would we know it was too low? it's not obvious to me that running into the upper bound would automatically prove that the upper bound was too low; it could simply indicate that the entire approach is unsound. that's the kind of experience we need to gather if we're going to deploy something which is, by every current measure and every current understanding, undeployable. here's a new question, though: is there enough guideance in 2005-1 to give the ARIN staff the power to detect and prevent hoarding? i'm not against hoarding, necessarily, except that hoarding wouldn't teach us what we're trying to learn from this experiment. From woody at pch.net Mon Feb 13 12:21:02 2006 From: woody at pch.net (Bill Woodcock) Date: Mon, 13 Feb 2006 09:21:02 -0800 (PST) Subject: [ppml] Proposed Policy: Capturing Originations in Templates In-Reply-To: References: Message-ID: On Mon, 13 Feb 2006 Michael.Dillon at btradianz.com wrote: > I thnk Sandra's policy has the germ of a good idea in it, > but the effort would be better spent in revitalizing the > RR rather than adding this info to whois. Yep, I agree entirely. -Bill From dlw+arin at tellme.com Mon Feb 13 12:37:50 2006 From: dlw+arin at tellme.com (David Williamson) Date: Mon, 13 Feb 2006 09:37:50 -0800 Subject: [ppml] Version think... was: alternative to 2005-1 In-Reply-To: <20060213172553.7336C11435@sa.vix.com> References: <10EC6E2B7F67A525F376E075@imac-en0.delong.sj.ca.us> <43EE2470.2070106@tony.li> <20060211183107.E768E11425@sa.vix.com> <20060213150213.C0E0D1142D@sa.vix.com> <20060213151828.BBC1D1142B@sa.vix.com> <20060213172553.7336C11435@sa.vix.com> Message-ID: <20060213173750.GB25038@shell01.corp.tellme.com> On Mon, Feb 13, 2006 at 05:25:53PM +0000, Paul Vixie wrote: > the usual round number thrown out in times like this is "20". which suits me > fine, but a lot of other round numbers would also suit me fine, like "200". > ARIN needs to get some utilization experience, and the inevitable side effects > of getting that kind of experience are: (a) a swamp of some size, and (b) an > early-adopter advantage. Why not pick 256? That gives a constrained size for the possible future swamp, and could put all of the space handed out under such an experiment into a single /40 (assuming /48 assignments). Another advantage of a small swamp - if we decide this was a bad plan, it's a small enough space to have a chance of success at renumbering into some future allocation plan. (Although that's a stiff penalty for the early adopters....) In any case, I'm definitely on the side of "let's gain some experience" of this. I think we need to do something, since nothing isn't working very well. If we limit the damage level, we shouldn't have long-term problems on a massive scale. (That's one of the issues, yes?) Doing nothing (again) would be generally detrimental. -David From paul at vix.com Mon Feb 13 12:38:22 2006 From: paul at vix.com (Paul Vixie) Date: Mon, 13 Feb 2006 17:38:22 +0000 Subject: [ppml] Version think... was: alternative to 2005-1 In-Reply-To: Your message of "Mon, 13 Feb 2006 16:29:59 GMT." References: Message-ID: <20060213173822.C6FBD1145C@sa.vix.com> michael, since you didn't get the hint, i'll say it straight out -- you and i are talking WAY TOO MUCH on this thread, and most folks aren't listening to us, and to the extent that we keep going back and forth on minor nits and wordplay, we're going to make this whole argument unreadable. this is my third PPML post today, and i plan to give it two days rest now. please do the same. # > sadly, yes i do. there has been reasonable debate here as to the long # > term viability of a "let ipv6 have an ipv4-like swamp" strategy. # # Until the opponents of an IPv6 swamp define what a "swamp" is and why it is # bad, you are likely to gain few supporters. Oh, and it wouldn't hurt to # explain why you consider that a particular policy proposal will lead to a # bad swamp. i didn't say it was a swamp and the people likely to support my amendment are not calling it a swamp either. i'm saying there has been reasonable debate on the swamp topic, and the swamp topic is considered contentious enough that if we wade into it we'll be neck deep in muck. (although, "how would we notice?") that's all for me until thursday. i recommend that delong and dillon likewise go into quiet mode and let the less voiciferous among us be heard. From bmanning at vacation.karoshi.com Mon Feb 13 12:52:14 2006 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 13 Feb 2006 17:52:14 +0000 Subject: [ppml] Version think... was: alternative to 2005-1 In-Reply-To: <20060213173750.GB25038@shell01.corp.tellme.com> References: <10EC6E2B7F67A525F376E075@imac-en0.delong.sj.ca.us> <43EE2470.2070106@tony.li> <20060211183107.E768E11425@sa.vix.com> <20060213150213.C0E0D1142D@sa.vix.com> <20060213151828.BBC1D1142B@sa.vix.com> <20060213172553.7336C11435@sa.vix.com> <20060213173750.GB25038@shell01.corp.tellme.com> Message-ID: <20060213175214.GA16772@vacation.karoshi.com.> On Mon, Feb 13, 2006 at 09:37:50AM -0800, David Williamson wrote: > On Mon, Feb 13, 2006 at 05:25:53PM +0000, Paul Vixie wrote: > > the usual round number thrown out in times like this is "20". which suits me > > fine, but a lot of other round numbers would also suit me fine, like "200". > > ARIN needs to get some utilization experience, and the inevitable side effects > > of getting that kind of experience are: (a) a swamp of some size, and (b) an > > early-adopter advantage. > ... > In any case, I'm definitely on the side of "let's gain some experience" > of this. I think we need to do something, since nothing isn't working > very well. If we limit the damage level, we shouldn't have long-term > problems on a massive scale. (That's one of the issues, yes?) Doing > nothing (again) would be generally detrimental. > > -David perhaps i am using a different source, but "experiment" sounds a whole lot like claiming the Internet is still an experiment and with over 10 years under the operational belt, this si a new spin on the term "early adopter" we -are- doing things - numbers are being assigned, wiht justifications that meet -todays- operational demands. changing policy now to conform to an ideal that does not exist now and may not exist for years seems counter productive to me. much of the debate seems to center around how many prefixes can "dance on the head of a pin".... as stewards of the number resources, i am concerned when there are proposals to give delegations for huge tracts without reasonable justification... and am equally concerned when we try to "micro-manage" the processes. reasonable,imho, cares less about getting a prefix into the mythical DMZ, and more along the lines of will my peers accept the prefix i have been able to justify. as usual, YMMV --bill From dlw+arin at tellme.com Mon Feb 13 13:08:32 2006 From: dlw+arin at tellme.com (David Williamson) Date: Mon, 13 Feb 2006 10:08:32 -0800 Subject: [ppml] Version think... was: alternative to 2005-1 In-Reply-To: <20060213175214.GA16772@vacation.karoshi.com.> References: <43EE2470.2070106@tony.li> <20060211183107.E768E11425@sa.vix.com> <20060213150213.C0E0D1142D@sa.vix.com> <20060213151828.BBC1D1142B@sa.vix.com> <20060213172553.7336C11435@sa.vix.com> <20060213173750.GB25038@shell01.corp.tellme.com> <20060213175214.GA16772@vacation.karoshi.com.> Message-ID: <20060213180832.GE25038@shell01.corp.tellme.com> On Mon, Feb 13, 2006 at 05:52:14PM +0000, bmanning at vacation.karoshi.com wrote: > we -are- doing things - numbers are being assigned, wiht justifications > that meet -todays- operational demands. changing policy now to conform to > an ideal that does not exist now and may not exist for years seems > counter productive to me. Yes, numbers are being assigned. If you aren't a provider, though, you aren't getting any numbers except from a provider. I'm not a provider. I don't want to be locked in. If I put on my blinders and act very selfish, the current policy doesn't work. Ergo, policy must change. I simply want to see a reasonable PI policy for IPv6 created. I'm pretty flexible on the 'reasonable' part, too. At this point, I'm willing to compromise to the point where I won't qualify for space...if we need to do some sort of experiment with PI space to soothe the community's concerns, let's do it! The only course of action I find indefensible is to do nothing. This isn't an ideal of some future need. The need is here. (Actually, I'll back away from that. Ignoring the fact that we'll eventually run out of v4 space, I'm happy to stay in v4 and never have to deal with v6 at all. I just think that's an unwise step for my business.) If we ever want to see IPv6 take off in the ARIN region (it seems to be getting traction elsewhere), then we need to do something with PI space. Here's something I havem't seen in this thread yet: what are the other RIR's doing with PI space? Do they have policy regarding alloctions? Has there been a rush for it? Or are the other RIRs in the same boat as ARIN, and other regions are just more inclined towards dealing with PA space? (I admit to a highly US-centric view of how things are run.) -David From bmanning at vacation.karoshi.com Mon Feb 13 13:20:27 2006 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 13 Feb 2006 18:20:27 +0000 Subject: [ppml] Version think... was: alternative to 2005-1 In-Reply-To: <20060213180832.GE25038@shell01.corp.tellme.com> References: <20060211183107.E768E11425@sa.vix.com> <20060213150213.C0E0D1142D@sa.vix.com> <20060213151828.BBC1D1142B@sa.vix.com> <20060213172553.7336C11435@sa.vix.com> <20060213173750.GB25038@shell01.corp.tellme.com> <20060213175214.GA16772@vacation.karoshi.com.> <20060213180832.GE25038@shell01.corp.tellme.com> Message-ID: <20060213182027.GA16987@vacation.karoshi.com.> On Mon, Feb 13, 2006 at 10:08:32AM -0800, David Williamson wrote: > On Mon, Feb 13, 2006 at 05:52:14PM +0000, bmanning at vacation.karoshi.com wrote: > > we -are- doing things - numbers are being assigned, wiht justifications > > that meet -todays- operational demands. changing policy now to conform to > > an ideal that does not exist now and may not exist for years seems > > counter productive to me. > > Yes, numbers are being assigned. If you aren't a provider, though, you > aren't getting any numbers except from a provider. I'm not a provider. > I don't want to be locked in. If I put on my blinders and act very selfish, > the current policy doesn't work. Ergo, policy must change. > > I simply want to see a reasonable PI policy for IPv6 created. I'm > pretty flexible on the 'reasonable' part, too. At this point, I'm > willing to compromise to the point where I won't qualify for space...if > we need to do some sort of experiment with PI space to soothe the > community's concerns, let's do it! > > The only course of action I find indefensible is to do nothing. This > isn't an ideal of some future need. The need is here. (Actually, I'll > back away from that. Ignoring the fact that we'll eventually run out > of v4 space, I'm happy to stay in v4 and never have to deal with v6 at > all. I just think that's an unwise step for my business.) If we ever > want to see IPv6 take off in the ARIN region (it seems to be getting > traction elsewhere), then we need to do something with PI space. > > Here's something I havem't seen in this thread yet: what are the other RIR's > doing with PI space? Do they have policy regarding alloctions? Has there > been a rush for it? Or are the other RIRs in the same boat as ARIN, and other > regions are just more inclined towards dealing with PA space? (I admit to > a highly US-centric view of how things are run.) > > -David k... lets peek here: ) who can get space? ) how much can they get? ) what is everyone else doing? is that about right? presuming so, here are my personal answers ... folks who make policy may have different ideas. ) i don't really know what "everyone else is doing" the ASO/AC should and we have ARIN representation there. I'm sure they will chime in at some point. ) how much? - either exactly what you need or just a little more. ideally, this is what your peers are willing to accept from you. ) who? - everyone who asks. the artifical constraint of "provider" or "ISP" is just that. In many cases its self-fullfilling .. e.g. if i have addresses, i become a provider - QED. If you need space, ARIN ought to be able to provide it to you. again, imho. --bill From william at elan.net Mon Feb 13 13:42:40 2006 From: william at elan.net (william(at)elan.net) Date: Mon, 13 Feb 2006 10:42:40 -0800 (PST) Subject: [ppml] Proposed Policy: Capturing Originations in Templates In-Reply-To: References: Message-ID: On Mon, 13 Feb 2006, Bill Woodcock wrote: > On Mon, 13 Feb 2006 Michael.Dillon at btradianz.com wrote: > > I thnk Sandra's policy has the germ of a good idea in it, > > but the effort would be better spent in revitalizing the > > RR rather than adding this info to whois. > > Yep, I agree entirely. One of the key issues is trust. There is a clear view that RIR data can be trusted where as RR not so much. This is both because RIR data is typically more up to date and because RIRd have (typically financial) relationships with ip address holders and take steps to verify who they are. Now as far as relationship part of this equation it is possible to communicate such trust by electronic means (yes pki signatures) and that is one of the issues SIDR will hopefully look at. But PKI and signing can be considered heavy-weight and idea of adding data directly into trusted authority information service is light-weight and easy to do. -- William Leibzon Elan Networks william at elan.net From Lee.Howard at stanleyassociates.com Mon Feb 13 13:50:55 2006 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Mon, 13 Feb 2006 13:50:55 -0500 Subject: [ppml] Version think... was: alternative to 2005-1 Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB401450C4A@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of David Williamson > Sent: Monday, February 13, 2006 1:09 PM > To: bmanning at vacation.karoshi.com > Cc: PPML > Subject: Re: [ppml] Version think... was: alternative to 2005-1 > > Here's something I havem't seen in this thread yet: what are > the other RIR's > doing with PI space? Do they have policy regarding > alloctions? Has there > been a rush for it? Or are the other RIRs in the same boat > as ARIN, and other > regions are just more inclined towards dealing with PA space? > (I admit to > a highly US-centric view of how things are run.) http://www.ripe.net/rs/ipv6/stats/ shows that RIPE NCC and APNIC are the two largest IPv6 regions, triple and double ARIN's number of allocations. http://www.apnic.net/docs/policy/ipv6-address-policy.html#5.4 "To qualify for an initial allocation of IPv6 address space, an organization must: a. be an LIR; b. not be an end site; " http://www.ripe.net/rs/ipv6/index.html "the RIPE NCC allocates IPv6 address space to its members, the so-called "Local Internet Registries" (LIR's). " http://www.ripe.net/ripe/docs/ipv6policy.html#initial_allocation "To qualify for an initial allocation of IPv6 address space, an organisation must: a) be an LIR; b) not be an End Site;" I don't know whether there is current work underway to provide PI assignments in those regions, but as far as I can tell they do not assign IPv6 space to end users. By the way, the RIRs maintain a comparative policy list, so you can fairly quickly check policies for each region. http://www.arin.net/community/rir_comp_matrix.html (oops: Error 404) http://www.nro.net/documents/nro27.html Lee > > -David > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From iggy at merit.edu Mon Feb 13 14:12:43 2006 From: iggy at merit.edu (Glenn Wiltse) Date: Mon, 13 Feb 2006 14:12:43 -0500 (EST) Subject: [ppml] Version think... was: alternative to 2005-1 In-Reply-To: References: <10EC6E2B7F67A525F376E075@imac-en0.delong.sj.ca.us> <43EE2470.2070106@tony.li> <20060211183107.E768E11425@sa.vix.com> <20060213150213.C0E0D1142D@sa.vix.com> <20060213151828.BBC1D1142B@sa.vix.com> Message-ID: I forgot to include my objection to the use of the term 'end site' in the policy. This term as currently defined in ARIN policy does not apply to ARIN, and ARIN should not be assigning IPv6 space directly to a 'end site' given the current definition of the term. Why should dificulty in renumbering be the determining factor? Perhaps it would be just as easy to create a way to easily renumber IPv6 space as it would be to create new routing protocols to deal with /48s everywhere. Much of my reasoning for wanting to avoid direct assignments of /48s has to do with routing issues, and not wanting to create policy that is surely going to cause problems with routing scalablity. I don't think it's a question of how many direct IPv4 assignments there are now, it's how many direct IPv6 assignments there could be. I guess for the most part, we are going to have to agree to disagree on these matters. Glenn Wiltse On Mon, 13 Feb 2006, Scott Leibrand wrote: > On 02/13/06 at 11:54am -0500, Glenn Wiltse wrote: > >> I have broader objections. As stated elsewhere... >> >> In general I don't think creating IPv6 policy based on IPv4 policy >> requirements is a good idea. > > Maybe not in the long term, but I think it's the best way to migrate from > IPv4 to IPv6. For users who're starting up with IPv6 in the future we'll > need a different policy, but I don't think we're at the point yet where we > can reach consensus on what that policy should be. > >> I am not convinced it's a good idea to give IPv6-PI space to any >> organization that can not show a immediate need for more then a single /48. > > As I and others have stated before, I think the determinant of whether an > org needs PI space should be difficulty of renumbering, not strictly the > size of the netblock needed. > >> I don't like the non-existent description of just exactly how a >> organization would ever qualify for more then a single /48. This >> seems to give ARIN staff nearly unlimited discretion as to what is >> acceptable distribution of /64s within a organization, and takes it >> out of the hands of public policy groups. > > How is this different than the rules for LIRs giving out >/48 allocations? > >> I'm not convinced that current routing protocols will handle wide spread >> use of /48 PI assignments. It seems to me that if ARIN passes this type of >> policy, it is in effect forcing the internet community as a whole, to deal >> with the consequences of such assignments. I'm not sure it's ARIN's place >> to force such a showdown. > > How many IPv4 PI blocks have been assigned? What would happen to the > routing table if we introduced that many IPv6 PI blocks? IMO "not much". From chuegen at cisco.com Mon Feb 13 14:37:03 2006 From: chuegen at cisco.com (Craig Huegen (chuegen)) Date: Mon, 13 Feb 2006 14:37:03 -0500 Subject: [ppml] Version think... was: alternative to 2005-1 Message-ID: On , ppml-bounces at arin.net wrote: (I make no apologies for my quote header as this list tends to have a strange re-write behavior unlike that of most lists...) Both APNIC and RIPE have the following statement in their policies: > "To qualify for an initial allocation of IPv6 address space, an > organization must: a. be an LIR; b. not be an end site; " Down to technicalities... If a large enterprise's IT department has hundreds of sites (remote offices) around the globe and largely acts as a service provider to its own organization, can it qualify as an LIR? Each remote office could be considered a single site. It seems completely backwards to me that companies the size of Cisco, GE, HP, IBM, etc. cannot get IPv6 addressing except through service providers, while Joe's Garage ISP with a couple hundred subscribers can qualify for a /32. These companies can have networks that are much, much larger than most of the ISP's out there. There are a few basic points that I think are important here: 1. For larger networks, PA space is a de-facto service provider lock-in due to the cost of renumbering. From an enterprise viewpoint, this is a significant business risk. Renumbering pain has a pretty significant relationship with an increasing size of the target network, special corner cases excepted. 2. Adoption of IPv6 in larger organizations will require that the de-facto service provider lock-in be solved. In the early days of IPv6 development, it was assumed that with the use of PA-only space, there would be mechanisms available to make renumbering simple. Proposals such as 8+8 came forth. In the end, IPv6 ended up as IPv4 with bigger address fields, and allocation policies and the implementation details of renumbering were considered out-of-scope. There wasn't much rejoicing in enterprise-land. 3. We must indeed be concerned about the long-term viability of IPv6. Granting a "land rush" is inappropriate. We must be measured about the deployment; the good news is that the policy process allows us to start conservatively and slowly open it up as we witness this growth and its effects. The last thing we want to do is give anyone with a class C from the unjustified pre-CIDR days the ability to claim their IPv6 "land". It makes sense to focus first on adoption by those who would have the largest hardship related to renumbering. 4. We must not abandon long-term solution development: we need to continue to work at solutions that will permit smaller routing tables for network scalability, and easy provider changes with very minimal effort in renumbering for end networks. The challenge is that adoption of these long-term solutions will take some time, and the answer is not "wait" -- enterprises have looked at IPv6 for several years and have been "waiting" for a while already. In essence, this spells out the requirement for a PI-based solution in the near term that is conservative and time or space-limited. I support the alternative to 2005-1 that starts more conservatively over a policy that grants IPv6 addresses to anyone with an IPv4 block. Also, while fees are generally outside of the policy spectrum, we must consider that there currently is no fee for IPv6 services -- will this cause more of a land rush than if there were a fee in place? /cah --- Craig A. Huegen, IT Solutions Architect C i s c o S y s t e m s IT - Intelligent Network Solutions || || Cisco Systems, Inc., 400 East Tasman Drive || || San Jose, CA 95134, (408) 526-8104 |||| |||| email: chuegen at cisco.com CCIE #2100 ..:||||||:..:||||||:.. From leo at ripe.net Mon Feb 13 15:38:32 2006 From: leo at ripe.net (leo vegoda) Date: Mon, 13 Feb 2006 21:38:32 +0100 Subject: [ppml] Version think... was: alternative to 2005-1 In-Reply-To: <20060213180832.GE25038@shell01.corp.tellme.com> References: <20060211183107.E768E11425@sa.vix.com> <20060213150213.C0E0D1142D@sa.vix.com> <20060213151828.BBC1D1142B@sa.vix.com> <20060213172553.7336C11435@sa.vix.com> <20060213173750.GB25038@shell01.corp.tellme.com> <20060213175214.GA16772@vacation.karoshi.com.> <20060213180832.GE25038@shell01.corp.tellme.com> Message-ID: <20060213203828.GA6922@ripe.net> Hi, On Mon, Feb 13, 2006 at 10:08:32AM -0800, David Williamson wrote: [...] > Here's something I havem't seen in this thread yet: what are the other RIR's > doing with PI space? Do they have policy regarding alloctions? Has there > been a rush for it? Or are the other RIRs in the same boat as ARIN, and other > regions are just more inclined towards dealing with PA space? (I admit to > a highly US-centric view of how things are run.) There is no general case IPv6 PI policy in RIPE. There are two exceptions to the general case. Root Nameservers are assigned a block of IPv6 address space for purposes of root server operations. The assignment is equal in size to the minimum allocation to Local Internet Registries (LIRs) valid at the time of the root server assignment. The policy document is available at: http://www.ripe.net/ripe/docs/ipv6-rootservers.html Also, Internet Exchange Points can receive either a /64 or a /48 for their networks. The policy document is available at: http://www.ripe.net/ripe/docs/ipv6-policy-ixp.html We've made 55 assignments to IXPs, four of which were made in 2005. There is an active proposal to allow assignments to TLD nameserver operators. You can find details of the proposal on our web site at: http://www.ripe.net/ripe/policies/proposals/2005-2.html If you would like to make a policy proposal in RIPE it is easy to do so. The policy development process in RIPE is described on our web site at: http://www.ripe.net/ripe/docs/pdp.html Regards, -- leo vegoda RIPE NCC Registration Services Manager From owen at delong.com Mon Feb 13 19:40:32 2006 From: owen at delong.com (Owen DeLong) Date: Mon, 13 Feb 2006 16:40:32 -0800 Subject: [ppml] Version think... was: alternative to 2005-1 In-Reply-To: References: Message-ID: > Let's not forget that there are intelligent human > beings implementing these policies under an intelligent > board of trustees. Can we not assume that these people will > limit the damage if there is a run on the bank? If not, > then perhaps we need a policy that allows the trustees > to suspend allocations in the same way that the New York > Stock Exchange can suspend trading of a share in unusual > circumstances. > Such a policy already exists in the form of the emergency authority of the ARIN BOT. 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 Feb 13 19:54:51 2006 From: owen at delong.com (Owen DeLong) Date: Mon, 13 Feb 2006 16:54:51 -0800 Subject: [ppml] Version think... was: alternative to 2005-1 In-Reply-To: References: <10EC6E2B7F67A525F376E075@imac-en0.delong.sj.ca.us> <43EE2470.2070106@tony.li> <20060211183107.E768E11425@sa.vix.com> <20060213150213.C0E0D1142D@sa.vix.com> <20060213151828.BBC1D1142B@sa.vix.com> Message-ID: <9A7EA5D7B625B96453CE8731@imac-en0.delong.sj.ca.us> --On February 13, 2006 11:54:38 AM -0500 Glenn Wiltse wrote: > I have broader objections. As stated elsewhere... > > In general I don't think creating IPv6 policy based on IPv4 policy > requirements is a good idea. > What would you rather base them on instead? To a certain extent, I agree that IPv6 policy shouldn't be based entirely on IPv4 policy, but, absent any other more relevant operational experience, I think that IPv4 experience and policy is at least a reasonable starting point. If you don't, then, please, by all means propose a viable alternative. > I am not convinced it's a good idea to give IPv6-PI space to any > organization that can not show a imediate need for more then a single /48. > Understood. On this we will agree to disagree. > I don't like the non-exsistant description of just exactly how a > originization would ever qualify for more then a single /48. This > seems to give ARIN staff nearly unlimited discretion as to what is > acceptable distribution of /64s within a orgization, and takes it > out of the hands of public policy groups. > Fair enough... I am not opposed to building a better definition of this. Can you propose language or ideas on how you would like to see this aspect of the policy structured? > I'm not convinced that current routing protocols will handle wide spread > use of /48 PI assignments. It seems to me that if ARIN passes this type > of policy, it is in effect forcing the internet community as a whole, to > deal with the consequences of such assignments. I'm not sure it's ARIN's > place to force such a showdown. > I am convinced that: 1. Current routing protocols will not handle wide-spread use of /48 PI assignments. 2. That is not an issue because their use is unlikely to be widespread prior to a time when we will see significant changes to routing protocols and processes. 3. Without a PI policy, it doesn't matter what the routing protocols will support because there won't be anything for them to support. 4. ARIN cannot force anyone to accept anything in their routing table. ARIN has no control over any routers other than those operated by ARIN for their internal networks. As such, not only is it not ARIN's place to force such a showdown, it is impossible for them to do so regardless of policy. 5. People who run routers are intelligent and adaptable. A solution to keep things running will be found. It may result in some PI /48s being unroutable in part of the internet. Policy doesn't guarantee routability. People who apply for addresses under such policies should be aware of that. It's in the ARIN disclaimer that everyone signs when they apply for space. > Perhaps I would feel better about such things, if all RIRs passed > simmilar policys simultainously... I just don't feel like ARIN should be > the trend setter with what I feel is a very liberal policy of giving out > /48 sized blocks of IPv6-PI space. However I don't think you could gain > anything aproaching consensus in the world wide community for 2005-1 as > it's currently written. > Again, I suspect we will agree to disagree. I think it is perfectly OK for ARIN to be a trend setter. It will not be the first time, and, I hope it won't be the last. There is nothing wrong with innovation occurring in North America. I don't know whether the other RIRs would support something like 2005-1 or not. I confess I'm not that worried about it, either, since I don't live or work in those regions and so far, their policies don't really affect me. Certainly if someone from one of those regions asked for my assistance in crafting such a policy, I would be happy to help. > If 2005-1 passes at ARIN XVII, I feel it will be largely because people > may simply say... 'we must pass something with regard to IPv6 PI space'. > I would seriouly hate to think that we start adopting policy simply > because we couldn't come up with something better. > Well... I suppose there are two ways to look at it. I think there is consensus that PI space in IPv6 is needed. I think there is further consensus that neither the original proposed 2005-1 (too liberal), nor the Orlando version of 2005-1 (too restrictive and arbitrary) will address the needs of the community. I think that the current revision of 2005-1 represents significant improvement over prior versions and takes a lot of the community feedback on the issues into account. One way to look at it is as you have above... "Adopting X because we couldn't come up with anything better." Another way to look at it is "Adopting X because we believe it is better than the current situation, and, we feel X is the best we could come to consensus on." Frankly, if what we have on the table is better than what we have in current policy, then, I say let's go for it and improve it down the road. Any improvement is better than no improvement. Future improvement is always possible. 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 Feb 13 20:11:12 2006 From: owen at delong.com (Owen DeLong) Date: Mon, 13 Feb 2006 17:11:12 -0800 Subject: [ppml] Proposed Policy: Capturing Originations in Templates In-Reply-To: References: Message-ID: <26A300715722BFAB7918FA51@imac-en0.delong.sj.ca.us> > > One of the key issues is trust. There is a clear view that RIR data can > be trusted where as RR not so much. This is both because RIR data is > typically more up to date and because RIRd have (typically financial) > relationships with ip address holders and take steps to verify who they > are. > That only makes sense when you compare an independent RR to RIR whois. When you are comparing RIR Whois to RIR RR, the trust issue seems, to me, at least, to be identical. > Now as far as relationship part of this equation it is possible to > communicate such trust by electronic means (yes pki signatures) and that > is one of the issues SIDR will hopefully look at. But PKI and signing can > be considered heavy-weight and idea of adding data directly into trusted > authority information service is light-weight and easy to do. > RRs already use PKI as one way to control authentication for submissions of RR data. I don't know what the ARIN RR uses, but, I do know that is a valid method used by Merit RADB. 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 louie at equinix.com Tue Feb 14 04:01:23 2006 From: louie at equinix.com (Louis Lee) Date: Tue, 14 Feb 2006 01:01:23 -0800 Subject: [ppml] Proposed Policy: MicroAllocations for Internal Infrastructure Message-ID: First off, my compliments to the authors of the policy proposal for a very thorough job of explaining the rationale of the proposal. I may have some questions on that later. You've written in 6.10.3: (full text of 6.10.3 at the bottom) > Internal infrastructure allocations MUST NOT be > routed on global Internet. While this is very well intentioned, we already have precedence in which language regarding whether a given assignment can or cannot be routed on the global Internet was removed from a policy previously adopted. Aside from the argument of whether "internal infrastructure" outside a NAT'ed firewall is considered part of the global Internet, ARIN policies do not dictate or imply routability. I understand from your proposal that if the micro-allocation that is given under 6.10.3 happens to be announced to peers and upstreams, it becomes an annoyance...and at worse, a network security / stability issue. In the previous policy to which I was referring, if that micro-allocation for IXPs was announced to peers & transits, it would actually impact operation directly by causing routing issues due to path selection algorithm. And in that case, the language restricting routability was still removed. (The closest that ARIN policy has to suggesting routability is the reference to RFC1918 space in 4.3.5: Non-connected Networks.) On a different point for consideration, if we are to continue to differentiate between "allocations" and "assignments", then the text should reflect it. We all understand that "micro-allocation" is a misnomer, and ARIN Registration Services has been making *assignments* on IP requests made under the micro-allocation policy. I do not fault you for this at all since the current text of the micro-allocation has the same ambiguity. This may just be a good opportunity to clarify the matter. The term "micro-allocation" should probably remain unaltered, however, due to the fact that "micro-assignment" has already taken to mean a separate policy. I don't want to create *more* confusion! :) At present, I have not decided whether I support this proposal or not. It seems to have merit, and it deserves attention & discussion. Louie -- Louis Lee Sr. Network Architect New Service Development Equinix, Inc. louie at equinix.com desk: 408/360-5253 main: 650/513-7000 -----Original Message----- From: Member Services [mailto:memsvcs at arin.net] Sent: Thursday, February 09, 2006 7:17 AM To: ppml at arin.net Subject: [ppml] Proposed Policy: MicroAllocations for Internal Infrastructure (...) 6.10.3 Micro-allocation for internal infrastructure Organizations that currently hold IPv6 allocations may apply for a micro-allocation for internal infrastructure. Applicant must provide justification indicating why a separate non-routed block is required. Justification must include why a sub-allocation of currently held IP space cannot be utilized. Internal infrastructure allocations MUST NOT be routed on global Internet. Internal infrastructure allocations MUST be allocated from specific blocks reserved only for this purpose. (...) From Michael.Dillon at btradianz.com Tue Feb 14 06:07:29 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 14 Feb 2006 11:07:29 +0000 Subject: [ppml] Version think... was: alternative to 2005-1 In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB401450C4A@CL-S-EX-1.stanleyassociates.com> Message-ID: > I don't know whether there is current work underway to provide > PI assignments in those regions, but as far as I can tell they > do not assign IPv6 space to end users. Looking through the RIPE allocation list I notice some LIRs with no IPv4 allocations that have received an IPv6 allocation. Austria Computer Sciences Corporation AG EUROCONTROL, the European Organisation for the Safety of Air Navigation CERN (European Centre for Nuclear Research) University of Belgrade MGI METRO Group Information Technology GmbH Goethe University, Frankfurt Westphalian William's University Ericsson FMV Sweden (defence equipment supply agency) Of most interest is MGI because they are a subsidiary of a company that owns several retail chains, mostly in Germany but also Poland, Romania, Russia and Turkey. Clearly, a non-ISP company has created a subsidiary to handle their ISP and other IT needs. One could argue that any company which uses a single /48 to service multiple multihomed locations, must operate a network of some sort to do so and therefore they should be able to qualify as an ISP/LIR. --Michael Dillon From leo at ripe.net Tue Feb 14 09:13:48 2006 From: leo at ripe.net (leo vegoda) Date: Tue, 14 Feb 2006 15:13:48 +0100 Subject: [ppml] Version think... was: alternative to 2005-1 In-Reply-To: Message-ID: <005d01c63170$dfd90dc0$1d0200c1@FluffyBunny> Hi Michael, On Tuesday, February 14, 2006 12:07 PM, Michael Dillon wrote: >> I don't know whether there is current work underway to provide >> PI assignments in those regions, but as far as I can tell they >> do not assign IPv6 space to end users. > > Looking through the RIPE allocation list I notice > some LIRs with no IPv4 allocations that have received > an IPv6 allocation. I think you are referring to the list published at: ftp://ftp/pub/stats/ripencc/membership/alloclist.txt This list only includes IPv4 address space that is allocated to an LIR. Most of these organisations have address space from the central registry that preceded the RIRs, or PI assignments requested via another LIR, normally before they became members themselves. You can find the IPv4 address space assigned to these organisations by putting their names in the free text search on our web site at: http://www.ripe.net/db/whois-free.html Regards, -- leo vegoda RIPE NCC Registration Services Manager From iggy at merit.edu Tue Feb 14 11:51:11 2006 From: iggy at merit.edu (Glenn Wiltse) Date: Tue, 14 Feb 2006 11:51:11 -0500 (EST) Subject: [ppml] Version think... was: alternative to 2005-1 In-Reply-To: <005d01c63170$dfd90dc0$1d0200c1@FluffyBunny> References: <005d01c63170$dfd90dc0$1d0200c1@FluffyBunny> Message-ID: Here is my own take on what I think would make more suitable policy that is simmilar to what 2005-1 is/was trying to acomplish. Note, there are no referances to IPv4 policy, there term 'end site' is not used (since it's not really applicable as it is currently defined), and it allows for multi site end-user orginizations a chance to have assignments that can all be aggregated into one routing assignment, etc... It's probably not perfect, but in my opinion it is better then what was currently proposed in 2005-1. (but then I'm admitadly biased) Glenn Wiltse... My alternate proposal/wording follows. -=-=-=-=-=-=-=-=-=-=-=-=-=- 6.5.8. Direct ARIN assignments to end-user organizations 6.5.8.1. To qualify for a direct ARIN assignment, a organization must: a) not be an IPv6 LIR/ISP; and b) have a need for at least 1024 unique address if they are miltihomed, or 2048 if not multi homed. 6.5.8.2. initial assignment size to end-user organizations. a) If a qualifying organization has no plans to have more then one physical site, they shall be given a single /48. This will be referred to as a single site end-user organization. b) Qualifying organizations with plans for more then one physical site, shall be assigned a minimum /44 address block. The standard size initial assignment shall be three times the number of sites they currently have, if they desire more then that, they must provide details about their plans to obtain even larger number of new sites. 6.5.8.3. Subsequent Assignments. a) Requests for additional ARIN assigned space to a multi site end-user organization must be accompanied by evidence that their internal use of /48s per site has exceeded the standard IPv6 HD ratio requirements. Upon such a documented request the multi site end-user organization will immediately be eligible to obtain an additional assignment that results in doubling of the address space assigned to it. Where possible the assignment will from an adjacent address block, meaning that it's existing assignment is extended by one bit to the left. b) Requests for additional ARIN assigned space to single site end-user organizations will be required to give back their initial /48 and will then be eligible for a initial assignment as a multi site end-user organization. They will be given 1 year to return the original /48. From stephen at sprunk.org Tue Feb 14 15:33:42 2006 From: stephen at sprunk.org (Stephen Sprunk) Date: Tue, 14 Feb 2006 14:33:42 -0600 Subject: [ppml] Fw: IRS goes IPv6! Message-ID: <031e01c631aa$563011b0$710016ac@ssprunk> [ Forwarded from NANOG, for those that aren't on it, and edited for brevity ] Thus spake "Jeroen Massar" > I Ar Es, > > At least they have received the 2610:30::/32 allocation from ARIN. > Lets see if they how taxing they find IPv6 ;) ... > OrgName: Internal Revenue Service ... > NetRange: 2610:0030:0000:0000:0000:0000:0000:0000 - > 2610:0030:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF > CIDR: 2610:0030:0000:0000:0000:0000:0000:0000/32 ... > NetType: Direct Allocation How, exactly, did the IRS manage to get a direct allocation from ARIN? Did they somehow qualify as an LIR? Did they snow the staffers? Did the US Govt put some sort of pressure on ARIN? If end sites like the IRS can get direct allocations today, perhaps all this discussion about PI space is moot and we don't need 2005-1 et al. S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin From alh-ietf at tndh.net Tue Feb 14 18:48:36 2006 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 14 Feb 2006 15:48:36 -0800 Subject: [ppml] Geo PI (draft-hain-ipv6-pi-addr-*) In-Reply-To: <082e01c62ae6$74c94530$517ba8c0@tndh.net> Message-ID: <028601c631c1$2c37a050$5402f20a@tndh.net> I realize that ARIN policy does not talk about routability, but would it make sense in the PI case to talk about a get-started approach where PI allocations were made from 1000::/4 using the geo algorithm and limiting the accepted prefixes in that block to /40? Any organization that could not claim unique possession to at least one physical lot of 100 meters in any direction would not make the cut. No exchange points or business practice changes required... If that still feels like too many PI entries, make the limit a /36 which would cut it back to those organizations with a 400 meter footprint. Tony > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of > Tony Hain > Sent: Sunday, February 05, 2006 10:28 PM > To: 'Scott Leibrand'; ppml at arin.net > Subject: Re: [ppml] Geo PI (draft-hain-ipv6-pi-addr-*) > > Scott Leibrand wrote: > > Tony, > > > > I think an approach to lat/long PI addressing such as your > > draft-hain-ipv6-pi-addr-09.txt may be a solid foundation for choosing > the > > PI > > block to assign to each individual organization. However, I think your > > draft-hain-ipv6-pi-addr-use-09.txt proposals, and previous discussion of > > similar ideas on PPML, have over-engineered the use cases and the > > implications for routing and exchange points. In particular, I read > your > > drafts as requiring that all ISPs in a region would have to agree on the > > level of aggregation for the region and that all ISPs in that region > > interconnect at an exchange point, and also encouraging ISPs to filter > > more-specifics heard from their peers based on how many routes each > origin > > AS announces and/or a certain prefix length. I think that all these > > requirements/suggestions are unnecessarily restrictive stipulations that > > encourage unnecessary opposition to the proposal. > > Exchange points are discussed, but would only really be required to > suppress > the basement multi-homer. There are business model issues tied up in this > that will take a long time to resolve if they ever do. In the short term > just basing PI allocations on this model would at least allow for the > option > later where random PI assignments would be difficult to sort out. > > > > > Here's what I see as a more realistic application of Geo PI: > > > > - Implement some sort of geography-based PI addressing scheme, either > one > > like draft-hain-ipv6-pi-addr-09.txt, a population-based scheme like > > Michael > > Dillon has advocated, or something more like our current system, where > > RIRs > > allocate PI blocks to individual companies, but choose the particular > > netblock to allocate based on one of the schemes above. (I'm not sure > > which > > of those approaches is superior, but we can debate the merits of each > > separately.) > > To judge there needs to be some agreed on goals. The IETF effort in that > space showed how there can never be agreement since the requirements of > the > ISP community and the end site community are in direct conflict. > > > - Initially, multihomed organizations allocated PI space would probably > > route them the exact same way they do IPv4 PI space today, announcing it > > in > > BGP to their transit providers, who would advertise it to everyone on > the > > planet with a full BGP feed (the DFZ). > > A presumption for all approaches is that organizations that have an AS > entry > in BGP will have at least one prefix. Hopefully one will be sufficient, > but > I am hearing noise that some organizations want hundreds to deal with > their > VPN scenario. > > > - At some future point, some global tier 1 NSPs* may decide that the > > routing table growth is causing problems for their routers. At that > > point, > > they can begin aggregating PI space within their own network, such that > > within a region (which could be a BGP confederation sub-AS, for example) > > all > > more-specifics for that region are carried, but only the PI aggregate is > > carried outside the region. In order for an tier 1 NSP to do this > > effectively, they would have to ensure that all of their peers have at > > least > > two peering points within the region (private peering or exchanged- > based, > > it > > doesn't matter), so that their peers can reach them and their customers' > > PI > > more-specifics for that region. > > I didn't want to get into the details of engineering the region more than > to > point out that some interchange will have to happen. > > > - For transit customers outside the aggregated region, the tier 1 NSP > > would > > be able to just advertise the PI aggregate. For peers who only peer > > outside > > the region, the NSP could do one of several things: they could simply > > advertise the peer their PI aggregate, which opens the possibility of > > providing transit connectivity to the peer; they could carry all > > more-specifics from the aggregated region to the peering router(s), > which > > would probably require a multihop BGP session or a tunnel; or they could > > simply not advertise routes from the aggregated region to their peer > > outside > > that region, requiring the peer to set up a peering point within the > > aggregated region or buy transit connectivity for traffic to that > region. > > The business models will develop based on what makes sense for that > specific > region. > > > - When two or more NSPs set up such aggregation, a customer multi-homed > > to > > both NSPs would be able to announce their PI deaggregate to their > transit > > providers just as they do now. Anyone trying to reach the customer from > > within the region (or from an NSP that doesn't aggregate) would be able > to > > choose between the two resulting BGP paths. Anyone trying to reach the > > customer from outside the region would see the customer's IP space as > part > > of a regional aggregate, and would route their traffic towards the > region. > > Once the traffic arrived at the region, it would reach a router which > > would > > be able to choose between the two deaggregated paths, based on the BGP > > metrics (localpref, AS path, MEDs, etc.) set by the origin AS. > > - If the two NSPs the customer multi-homes to decide to aggregate > > differently, it might affect the traffic balance inbound to the multi- > > homed > > customer, but the customer will still have the leeway to adjust their > > announcements to compensate. For example, if NSP A aggregates a smaller > > region to a /32, and NSP B aggregates a larger region to a /28, then > > traffic > > from outside the larger region would prefer NSP A, while traffic from > the > > in-between region would prefer NSP B, as the route would still be a > > deaggregate over NSP B in that region. Once traffic reached the smaller > > region, the origin AS's BGP metrics would take over. > > > > My point here is not that NSPs have to do things this way, but rather > that > > a > > geography-based PI allocation scheme allows them to continue operating > > with > > the current model as long as they want to, and also gives them the > > flexibility to begin gradually aggregating PI space within their network > > as > > they see fit (for example by starting with large regions like > continents, > > an > > later aggregating on a more regional basis as needed). We can implement > > such a geography-based PI allocation scheme *without* requiring everyone > > (or > > anyone) in a region to set up new interconnections, and without > requiring > > anyone to coordinate the precise size of aggregated regions (and thereby > > the > > length of aggregate prefixes). IMO that makes it *much* more likely > that > > such a system could reach consensus and actually get implemented. > > I don't expect transit providers to even consider aggregation until there > is > an exchange point in the region acting as their customer and fronting for > the local distribution of traffic. Fortunately it is not required to get > started and can come along when it makes more sense to aggregate than to > buy > bigger routers. > > Thanks for the feedback, > Tony > > > > > > -Scott > > > > * A global tier 1 NSP means one who has a global backbone, don't buy > > transit > > from anyone, and have full reachability to the rest of the Internet via > > peering arrangements). > > > > P.S. Is there an IETF WG mailing list that draft-hain-ipv6-pi-addr* > belong > > to? If so, I'd like to subscribe and cross-post the above message there > > as > > well. TIA. > > > > > > ----- Original Message ----- > > From: "Tony Hain" > > To: > > Sent: Thursday, February 02, 2006 8:20 PM > > Subject: Re: [ppml] 2005-1 status > > > > > > > An alternative to protocol design in either the routing space or host > > > stacks > > > is to reconsider the myth of a global DFZ. The divergence in > routeviews > > > should already trigger the flag that there is no such thing as a > > globally > > > common DFZ, so arguing PI allocation policy in the context of its > impact > > > on > > > this mythical entity is bound to drag on. > > > > > > I just refreshed my geo I-D's > > > http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-09.txt > > > http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-use-09.txt > > > > > > Rather than argue about the topology/geography argument, please > consider > > > that this is: > > > 1) an identifiable block > > > 2) does not require any changes to existing hosts or routers > > > 3) removes any arguments about prefix length vs. organizational size > > > 4) allows for simple proxy aggregation where the detail becomes > > irrelevant > > > 5) debases ITU/national arguments over access to sovereign allocations > > > > > > In the worst case these degenerate to the same number of routing slots > > as > > > an > > > arbitrary RIR allocation process. At the same time they lay a > foundation > > > where alternative business practices can evolve to better align the > > costs > > > involved. > > > > > > Comments are always welcome (particularly thoughts about how to > resolve > > > the > > > altitude problem) > > > > > > Tony > > > > > > > > >> -----Original Message----- > > >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf > Of > > >> Scott Leibrand > > >> Sent: Thursday, February 02, 2006 6:12 AM > > >> To: Bill Darte > > >> Cc: ppml at arin.net > > >> Subject: Re: [ppml] 2005-1 status > > >> > > >> Bill and Owen, > > >> > > >> What if the IETF comes up with a routing architecture / protocol > design > > >> that allows for effective multihoming with PA space? That seems more > > >> likely to me (in the near term) than a complete replacement of BGP4. > > >> > > >> IMO policy should recognize the status quo for what it is: the way > > things > > >> are done. If the status quo needs to change, fine. That's why we're > > >> debating 2005-1. But I think it's dangerous to make policy with the > > goal > > >> of breaking things so that someone else will be forced to fix them > > later. > > >> IMO we should make policy that meets the current needs of our > > >> constituents, and strive to meet their future needs by working > through > > >> the > > >> IETF process to fix the routing architecture, and then modifying > policy > > >> in > > >> the future when future interests have emerged and we have a clearer > > idea > > >> of the tradeoffs. > > >> > > >> -Scott > > >> > > >> On 02/02/06 at 8:15am -0600, Bill Darte wrote: > > >> > > >> > Owen, > > >> > > > >> > My personal belief is that you frame the question(s) appropriately > in > > >> this > > >> > post. > > >> > If the architecture of the Internet no longer serves the emerging > > >> interests > > >> > of the constituents, then the architecture should change, rather > than > > >> trying > > >> > to craft discriminating address policy that preserves the status > quo. > > >> > > > >> > On a slightly different topic, with the PI for endsites policy, > there > > >> > is > > >> no > > >> > stipulation about the v4 blocks that exist in the v6 recipients > > >> > 'possession'. You are assuming that that legacy assignment would > > >> > endure > > >> in > > >> > perpetuity? You have no expectation that the v6 block would require > > the > > >> > legacy v4 blocks, whether PA or PI to be returned? > > >> > > > >> > I'm not suggesting this be the case...just want this issue to be > > >> addressed. > > >> > > > >> > bd > > >> > > > >> > > -----Original Message----- > > >> > > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > > >> > > Behalf Of Owen DeLong > > >> > > Sent: Thursday, February 02, 2006 12:35 AM > > >> > > To: Scott Leibrand; George Kuzmowycz > > >> > > Cc: ppml at arin.net > > >> > > Subject: Re: [ppml] 2005-1 status > > >> > > > > >> > > > > >> > > _______________________________________________ > > >> > > 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 > > >> > > > >> _______________________________________________ > > >> 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 > > > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From william at elan.net Tue Feb 14 20:25:20 2006 From: william at elan.net (william(at)elan.net) Date: Tue, 14 Feb 2006 17:25:20 -0800 (PST) Subject: [ppml] Geo PI (draft-hain-ipv6-pi-addr-*) In-Reply-To: <028601c631c1$2c37a050$5402f20a@tndh.net> References: <028601c631c1$2c37a050$5402f20a@tndh.net> Message-ID: Actually I noticed that even without PI, ARIN most often makes IPv6 allocations to ISPs in the same city/region that they are nearby. On Tue, 14 Feb 2006, Tony Hain wrote: > I realize that ARIN policy does not talk about routability, but would it > make sense in the PI case to talk about a get-started approach where PI > allocations were made from 1000::/4 using the geo algorithm and limiting the > accepted prefixes in that block to /40? Any organization that could not > claim unique possession to at least one physical lot of 100 meters in any > direction would not make the cut. No exchange points or business practice > changes required... > > If that still feels like too many PI entries, make the limit a /36 which > would cut it back to those organizations with a 400 meter footprint. > > Tony > > >> -----Original Message----- >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of >> Tony Hain >> Sent: Sunday, February 05, 2006 10:28 PM >> To: 'Scott Leibrand'; ppml at arin.net >> Subject: Re: [ppml] Geo PI (draft-hain-ipv6-pi-addr-*) >> >> Scott Leibrand wrote: >>> Tony, >>> >>> I think an approach to lat/long PI addressing such as your >>> draft-hain-ipv6-pi-addr-09.txt may be a solid foundation for choosing >> the >>> PI >>> block to assign to each individual organization. However, I think your >>> draft-hain-ipv6-pi-addr-use-09.txt proposals, and previous discussion of >>> similar ideas on PPML, have over-engineered the use cases and the >>> implications for routing and exchange points. In particular, I read >> your >>> drafts as requiring that all ISPs in a region would have to agree on the >>> level of aggregation for the region and that all ISPs in that region >>> interconnect at an exchange point, and also encouraging ISPs to filter >>> more-specifics heard from their peers based on how many routes each >> origin >>> AS announces and/or a certain prefix length. I think that all these >>> requirements/suggestions are unnecessarily restrictive stipulations that >>> encourage unnecessary opposition to the proposal. >> >> Exchange points are discussed, but would only really be required to >> suppress >> the basement multi-homer. There are business model issues tied up in this >> that will take a long time to resolve if they ever do. In the short term >> just basing PI allocations on this model would at least allow for the >> option >> later where random PI assignments would be difficult to sort out. >> >>> >>> Here's what I see as a more realistic application of Geo PI: >>> >>> - Implement some sort of geography-based PI addressing scheme, either >> one >>> like draft-hain-ipv6-pi-addr-09.txt, a population-based scheme like >>> Michael >>> Dillon has advocated, or something more like our current system, where >>> RIRs >>> allocate PI blocks to individual companies, but choose the particular >>> netblock to allocate based on one of the schemes above. (I'm not sure >>> which >>> of those approaches is superior, but we can debate the merits of each >>> separately.) >> >> To judge there needs to be some agreed on goals. The IETF effort in that >> space showed how there can never be agreement since the requirements of >> the >> ISP community and the end site community are in direct conflict. >> >>> - Initially, multihomed organizations allocated PI space would probably >>> route them the exact same way they do IPv4 PI space today, announcing it >>> in >>> BGP to their transit providers, who would advertise it to everyone on >> the >>> planet with a full BGP feed (the DFZ). >> >> A presumption for all approaches is that organizations that have an AS >> entry >> in BGP will have at least one prefix. Hopefully one will be sufficient, >> but >> I am hearing noise that some organizations want hundreds to deal with >> their >> VPN scenario. >> >>> - At some future point, some global tier 1 NSPs* may decide that the >>> routing table growth is causing problems for their routers. At that >>> point, >>> they can begin aggregating PI space within their own network, such that >>> within a region (which could be a BGP confederation sub-AS, for example) >>> all >>> more-specifics for that region are carried, but only the PI aggregate is >>> carried outside the region. In order for an tier 1 NSP to do this >>> effectively, they would have to ensure that all of their peers have at >>> least >>> two peering points within the region (private peering or exchanged- >> based, >>> it >>> doesn't matter), so that their peers can reach them and their customers' >>> PI >>> more-specifics for that region. >> >> I didn't want to get into the details of engineering the region more than >> to >> point out that some interchange will have to happen. >> >>> - For transit customers outside the aggregated region, the tier 1 NSP >>> would >>> be able to just advertise the PI aggregate. For peers who only peer >>> outside >>> the region, the NSP could do one of several things: they could simply >>> advertise the peer their PI aggregate, which opens the possibility of >>> providing transit connectivity to the peer; they could carry all >>> more-specifics from the aggregated region to the peering router(s), >> which >>> would probably require a multihop BGP session or a tunnel; or they could >>> simply not advertise routes from the aggregated region to their peer >>> outside >>> that region, requiring the peer to set up a peering point within the >>> aggregated region or buy transit connectivity for traffic to that >> region. >> >> The business models will develop based on what makes sense for that >> specific >> region. >> >>> - When two or more NSPs set up such aggregation, a customer multi-homed >>> to >>> both NSPs would be able to announce their PI deaggregate to their >> transit >>> providers just as they do now. Anyone trying to reach the customer from >>> within the region (or from an NSP that doesn't aggregate) would be able >> to >>> choose between the two resulting BGP paths. Anyone trying to reach the >>> customer from outside the region would see the customer's IP space as >> part >>> of a regional aggregate, and would route their traffic towards the >> region. >>> Once the traffic arrived at the region, it would reach a router which >>> would >>> be able to choose between the two deaggregated paths, based on the BGP >>> metrics (localpref, AS path, MEDs, etc.) set by the origin AS. >>> - If the two NSPs the customer multi-homes to decide to aggregate >>> differently, it might affect the traffic balance inbound to the multi- >>> homed >>> customer, but the customer will still have the leeway to adjust their >>> announcements to compensate. For example, if NSP A aggregates a smaller >>> region to a /32, and NSP B aggregates a larger region to a /28, then >>> traffic >>> from outside the larger region would prefer NSP A, while traffic from >> the >>> in-between region would prefer NSP B, as the route would still be a >>> deaggregate over NSP B in that region. Once traffic reached the smaller >>> region, the origin AS's BGP metrics would take over. >>> >>> My point here is not that NSPs have to do things this way, but rather >> that >>> a >>> geography-based PI allocation scheme allows them to continue operating >>> with >>> the current model as long as they want to, and also gives them the >>> flexibility to begin gradually aggregating PI space within their network >>> as >>> they see fit (for example by starting with large regions like >> continents, >>> an >>> later aggregating on a more regional basis as needed). We can implement >>> such a geography-based PI allocation scheme *without* requiring everyone >>> (or >>> anyone) in a region to set up new interconnections, and without >> requiring >>> anyone to coordinate the precise size of aggregated regions (and thereby >>> the >>> length of aggregate prefixes). IMO that makes it *much* more likely >> that >>> such a system could reach consensus and actually get implemented. >> >> I don't expect transit providers to even consider aggregation until there >> is >> an exchange point in the region acting as their customer and fronting for >> the local distribution of traffic. Fortunately it is not required to get >> started and can come along when it makes more sense to aggregate than to >> buy >> bigger routers. >> >> Thanks for the feedback, >> Tony >> >> >>> >>> -Scott >>> >>> * A global tier 1 NSP means one who has a global backbone, don't buy >>> transit >>> from anyone, and have full reachability to the rest of the Internet via >>> peering arrangements). >>> >>> P.S. Is there an IETF WG mailing list that draft-hain-ipv6-pi-addr* >> belong >>> to? If so, I'd like to subscribe and cross-post the above message there >>> as >>> well. TIA. >>> >>> >>> ----- Original Message ----- >>> From: "Tony Hain" >>> To: >>> Sent: Thursday, February 02, 2006 8:20 PM >>> Subject: Re: [ppml] 2005-1 status >>> >>> >>>> An alternative to protocol design in either the routing space or host >>>> stacks >>>> is to reconsider the myth of a global DFZ. The divergence in >> routeviews >>>> should already trigger the flag that there is no such thing as a >>> globally >>>> common DFZ, so arguing PI allocation policy in the context of its >> impact >>>> on >>>> this mythical entity is bound to drag on. >>>> >>>> I just refreshed my geo I-D's >>>> http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-09.txt >>>> http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-use-09.txt >>>> >>>> Rather than argue about the topology/geography argument, please >> consider >>>> that this is: >>>> 1) an identifiable block >>>> 2) does not require any changes to existing hosts or routers >>>> 3) removes any arguments about prefix length vs. organizational size >>>> 4) allows for simple proxy aggregation where the detail becomes >>> irrelevant >>>> 5) debases ITU/national arguments over access to sovereign allocations >>>> >>>> In the worst case these degenerate to the same number of routing slots >>> as >>>> an >>>> arbitrary RIR allocation process. At the same time they lay a >> foundation >>>> where alternative business practices can evolve to better align the >>> costs >>>> involved. >>>> >>>> Comments are always welcome (particularly thoughts about how to >> resolve >>>> the >>>> altitude problem) >>>> >>>> Tony >>>> >>>> >>>>> -----Original Message----- >>>>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf >> Of >>>>> Scott Leibrand >>>>> Sent: Thursday, February 02, 2006 6:12 AM >>>>> To: Bill Darte >>>>> Cc: ppml at arin.net >>>>> Subject: Re: [ppml] 2005-1 status >>>>> >>>>> Bill and Owen, >>>>> >>>>> What if the IETF comes up with a routing architecture / protocol >> design >>>>> that allows for effective multihoming with PA space? That seems more >>>>> likely to me (in the near term) than a complete replacement of BGP4. >>>>> >>>>> IMO policy should recognize the status quo for what it is: the way >>> things >>>>> are done. If the status quo needs to change, fine. That's why we're >>>>> debating 2005-1. But I think it's dangerous to make policy with the >>> goal >>>>> of breaking things so that someone else will be forced to fix them >>> later. >>>>> IMO we should make policy that meets the current needs of our >>>>> constituents, and strive to meet their future needs by working >> through >>>>> the >>>>> IETF process to fix the routing architecture, and then modifying >> policy >>>>> in >>>>> the future when future interests have emerged and we have a clearer >>> idea >>>>> of the tradeoffs. >>>>> >>>>> -Scott >>>>> >>>>> On 02/02/06 at 8:15am -0600, Bill Darte wrote: >>>>> >>>>>> Owen, >>>>>> >>>>>> My personal belief is that you frame the question(s) appropriately >> in >>>>> this >>>>>> post. >>>>>> If the architecture of the Internet no longer serves the emerging >>>>> interests >>>>>> of the constituents, then the architecture should change, rather >> than >>>>> trying >>>>>> to craft discriminating address policy that preserves the status >> quo. >>>>>> >>>>>> On a slightly different topic, with the PI for endsites policy, >> there >>>>>> is >>>>> no >>>>>> stipulation about the v4 blocks that exist in the v6 recipients >>>>>> 'possession'. You are assuming that that legacy assignment would >>>>>> endure >>>>> in >>>>>> perpetuity? You have no expectation that the v6 block would require >>> the >>>>>> legacy v4 blocks, whether PA or PI to be returned? >>>>>> >>>>>> I'm not suggesting this be the case...just want this issue to be >>>>> addressed. >>>>>> >>>>>> bd >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On >>>>>>> Behalf Of Owen DeLong >>>>>>> Sent: Thursday, February 02, 2006 12:35 AM >>>>>>> To: Scott Leibrand; George Kuzmowycz >>>>>>> Cc: ppml at arin.net >>>>>>> Subject: Re: [ppml] 2005-1 status >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>> >>>>> _______________________________________________ >>>>> 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 From jdhoule at att.com Tue Feb 14 21:11:11 2006 From: jdhoule at att.com (Houle, Joseph D (Joe), CMO) Date: Tue, 14 Feb 2006 20:11:11 -0600 Subject: [ppml] Geo PI (draft-hain-ipv6-pi-addr-*) Message-ID: Tony: And advertise that block in its entirety only from that one geographic location? Joe Houle -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of Tony Hain Sent: Tuesday, February 14, 2006 5:49 PM To: ppml at arin.net Subject: Re: [ppml] Geo PI (draft-hain-ipv6-pi-addr-*) I realize that ARIN policy does not talk about routability, but would it make sense in the PI case to talk about a get-started approach where PI allocations were made from 1000::/4 using the geo algorithm and limiting the accepted prefixes in that block to /40? Any organization that could not claim unique possession to at least one physical lot of 100 meters in any direction would not make the cut. No exchange points or business practice changes required... If that still feels like too many PI entries, make the limit a /36 which would cut it back to those organizations with a 400 meter footprint. Tony > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of > Tony Hain > Sent: Sunday, February 05, 2006 10:28 PM > To: 'Scott Leibrand'; ppml at arin.net > Subject: Re: [ppml] Geo PI (draft-hain-ipv6-pi-addr-*) > > Scott Leibrand wrote: > > Tony, > > > > I think an approach to lat/long PI addressing such as your > > draft-hain-ipv6-pi-addr-09.txt may be a solid foundation for choosing > the > > PI > > block to assign to each individual organization. However, I think your > > draft-hain-ipv6-pi-addr-use-09.txt proposals, and previous discussion of > > similar ideas on PPML, have over-engineered the use cases and the > > implications for routing and exchange points. In particular, I read > your > > drafts as requiring that all ISPs in a region would have to agree on the > > level of aggregation for the region and that all ISPs in that region > > interconnect at an exchange point, and also encouraging ISPs to filter > > more-specifics heard from their peers based on how many routes each > origin > > AS announces and/or a certain prefix length. I think that all these > > requirements/suggestions are unnecessarily restrictive stipulations that > > encourage unnecessary opposition to the proposal. > > Exchange points are discussed, but would only really be required to > suppress > the basement multi-homer. There are business model issues tied up in this > that will take a long time to resolve if they ever do. In the short term > just basing PI allocations on this model would at least allow for the > option > later where random PI assignments would be difficult to sort out. > > > > > Here's what I see as a more realistic application of Geo PI: > > > > - Implement some sort of geography-based PI addressing scheme, either > one > > like draft-hain-ipv6-pi-addr-09.txt, a population-based scheme like > > Michael > > Dillon has advocated, or something more like our current system, where > > RIRs > > allocate PI blocks to individual companies, but choose the particular > > netblock to allocate based on one of the schemes above. (I'm not sure > > which > > of those approaches is superior, but we can debate the merits of each > > separately.) > > To judge there needs to be some agreed on goals. The IETF effort in that > space showed how there can never be agreement since the requirements of > the > ISP community and the end site community are in direct conflict. > > > - Initially, multihomed organizations allocated PI space would probably > > route them the exact same way they do IPv4 PI space today, announcing it > > in > > BGP to their transit providers, who would advertise it to everyone on > the > > planet with a full BGP feed (the DFZ). > > A presumption for all approaches is that organizations that have an AS > entry > in BGP will have at least one prefix. Hopefully one will be sufficient, > but > I am hearing noise that some organizations want hundreds to deal with > their > VPN scenario. > > > - At some future point, some global tier 1 NSPs* may decide that the > > routing table growth is causing problems for their routers. At that > > point, > > they can begin aggregating PI space within their own network, such that > > within a region (which could be a BGP confederation sub-AS, for example) > > all > > more-specifics for that region are carried, but only the PI aggregate is > > carried outside the region. In order for an tier 1 NSP to do this > > effectively, they would have to ensure that all of their peers have at > > least > > two peering points within the region (private peering or exchanged- > based, > > it > > doesn't matter), so that their peers can reach them and their customers' > > PI > > more-specifics for that region. > > I didn't want to get into the details of engineering the region more than > to > point out that some interchange will have to happen. > > > - For transit customers outside the aggregated region, the tier 1 NSP > > would > > be able to just advertise the PI aggregate. For peers who only peer > > outside > > the region, the NSP could do one of several things: they could simply > > advertise the peer their PI aggregate, which opens the possibility of > > providing transit connectivity to the peer; they could carry all > > more-specifics from the aggregated region to the peering router(s), > which > > would probably require a multihop BGP session or a tunnel; or they could > > simply not advertise routes from the aggregated region to their peer > > outside > > that region, requiring the peer to set up a peering point within the > > aggregated region or buy transit connectivity for traffic to that > region. > > The business models will develop based on what makes sense for that > specific > region. > > > - When two or more NSPs set up such aggregation, a customer multi-homed > > to > > both NSPs would be able to announce their PI deaggregate to their > transit > > providers just as they do now. Anyone trying to reach the customer from > > within the region (or from an NSP that doesn't aggregate) would be able > to > > choose between the two resulting BGP paths. Anyone trying to reach the > > customer from outside the region would see the customer's IP space as > part > > of a regional aggregate, and would route their traffic towards the > region. > > Once the traffic arrived at the region, it would reach a router which > > would > > be able to choose between the two deaggregated paths, based on the BGP > > metrics (localpref, AS path, MEDs, etc.) set by the origin AS. > > - If the two NSPs the customer multi-homes to decide to aggregate > > differently, it might affect the traffic balance inbound to the multi- > > homed > > customer, but the customer will still have the leeway to adjust their > > announcements to compensate. For example, if NSP A aggregates a smaller > > region to a /32, and NSP B aggregates a larger region to a /28, then > > traffic > > from outside the larger region would prefer NSP A, while traffic from > the > > in-between region would prefer NSP B, as the route would still be a > > deaggregate over NSP B in that region. Once traffic reached the smaller > > region, the origin AS's BGP metrics would take over. > > > > My point here is not that NSPs have to do things this way, but rather > that > > a > > geography-based PI allocation scheme allows them to continue operating > > with > > the current model as long as they want to, and also gives them the > > flexibility to begin gradually aggregating PI space within their network > > as > > they see fit (for example by starting with large regions like > continents, > > an > > later aggregating on a more regional basis as needed). We can implement > > such a geography-based PI allocation scheme *without* requiring everyone > > (or > > anyone) in a region to set up new interconnections, and without > requiring > > anyone to coordinate the precise size of aggregated regions (and thereby > > the > > length of aggregate prefixes). IMO that makes it *much* more likely > that > > such a system could reach consensus and actually get implemented. > > I don't expect transit providers to even consider aggregation until there > is > an exchange point in the region acting as their customer and fronting for > the local distribution of traffic. Fortunately it is not required to get > started and can come along when it makes more sense to aggregate than to > buy > bigger routers. > > Thanks for the feedback, > Tony > > > > > > -Scott > > > > * A global tier 1 NSP means one who has a global backbone, don't buy > > transit > > from anyone, and have full reachability to the rest of the Internet via > > peering arrangements). > > > > P.S. Is there an IETF WG mailing list that draft-hain-ipv6-pi-addr* > belong > > to? If so, I'd like to subscribe and cross-post the above message there > > as > > well. TIA. > > > > > > ----- Original Message ----- > > From: "Tony Hain" > > To: > > Sent: Thursday, February 02, 2006 8:20 PM > > Subject: Re: [ppml] 2005-1 status > > > > > > > An alternative to protocol design in either the routing space or host > > > stacks > > > is to reconsider the myth of a global DFZ. The divergence in > routeviews > > > should already trigger the flag that there is no such thing as a > > globally > > > common DFZ, so arguing PI allocation policy in the context of its > impact > > > on > > > this mythical entity is bound to drag on. > > > > > > I just refreshed my geo I-D's > > > http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-09.txt > > > http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-use-09.txt > > > > > > Rather than argue about the topology/geography argument, please > consider > > > that this is: > > > 1) an identifiable block > > > 2) does not require any changes to existing hosts or routers > > > 3) removes any arguments about prefix length vs. organizational size > > > 4) allows for simple proxy aggregation where the detail becomes > > irrelevant > > > 5) debases ITU/national arguments over access to sovereign allocations > > > > > > In the worst case these degenerate to the same number of routing slots > > as > > > an > > > arbitrary RIR allocation process. At the same time they lay a > foundation > > > where alternative business practices can evolve to better align the > > costs > > > involved. > > > > > > Comments are always welcome (particularly thoughts about how to > resolve > > > the > > > altitude problem) > > > > > > Tony > > > > > > > > >> -----Original Message----- > > >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf > Of > > >> Scott Leibrand > > >> Sent: Thursday, February 02, 2006 6:12 AM > > >> To: Bill Darte > > >> Cc: ppml at arin.net > > >> Subject: Re: [ppml] 2005-1 status > > >> > > >> Bill and Owen, > > >> > > >> What if the IETF comes up with a routing architecture / protocol > design > > >> that allows for effective multihoming with PA space? That seems more > > >> likely to me (in the near term) than a complete replacement of BGP4. > > >> > > >> IMO policy should recognize the status quo for what it is: the way > > things > > >> are done. If the status quo needs to change, fine. That's why we're > > >> debating 2005-1. But I think it's dangerous to make policy with the > > goal > > >> of breaking things so that someone else will be forced to fix them > > later. > > >> IMO we should make policy that meets the current needs of our > > >> constituents, and strive to meet their future needs by working > through > > >> the > > >> IETF process to fix the routing architecture, and then modifying > policy > > >> in > > >> the future when future interests have emerged and we have a clearer > > idea > > >> of the tradeoffs. > > >> > > >> -Scott > > >> > > >> On 02/02/06 at 8:15am -0600, Bill Darte wrote: > > >> > > >> > Owen, > > >> > > > >> > My personal belief is that you frame the question(s) appropriately > in > > >> this > > >> > post. > > >> > If the architecture of the Internet no longer serves the emerging > > >> interests > > >> > of the constituents, then the architecture should change, rather > than > > >> trying > > >> > to craft discriminating address policy that preserves the status > quo. > > >> > > > >> > On a slightly different topic, with the PI for endsites policy, > there > > >> > is > > >> no > > >> > stipulation about the v4 blocks that exist in the v6 recipients > > >> > 'possession'. You are assuming that that legacy assignment would > > >> > endure > > >> in > > >> > perpetuity? You have no expectation that the v6 block would require > > the > > >> > legacy v4 blocks, whether PA or PI to be returned? > > >> > > > >> > I'm not suggesting this be the case...just want this issue to be > > >> addressed. > > >> > > > >> > bd > > >> > > > >> > > -----Original Message----- > > >> > > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > > >> > > Behalf Of Owen DeLong > > >> > > Sent: Thursday, February 02, 2006 12:35 AM > > >> > > To: Scott Leibrand; George Kuzmowycz > > >> > > Cc: ppml at arin.net > > >> > > Subject: Re: [ppml] 2005-1 status > > >> > > > > >> > > > > >> > > _______________________________________________ > > >> > > 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 > > >> > > > >> _______________________________________________ > > >> 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 > > > > > _______________________________________________ > 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 From owen at delong.com Tue Feb 14 22:31:03 2006 From: owen at delong.com (Owen DeLong) Date: Tue, 14 Feb 2006 19:31:03 -0800 Subject: [ppml] Version think... was: alternative to 2005-1 In-Reply-To: References: <005d01c63170$dfd90dc0$1d0200c1@FluffyBunny> Message-ID: <97E644DB6D2E5D9019BBC0DD@imac-en0.delong.sj.ca.us> While I still prefer the wording in 2005-1, I can also accept this as a viable alternative. I think 1024 is, however, the largest viable threshold. Any larger number of unique IPs required seems arbitrary and capricious to me. Owen --On February 14, 2006 11:51:11 AM -0500 Glenn Wiltse wrote: > > Here is my own take on what I think would make more suitable > policy that is simmilar to what 2005-1 is/was trying to acomplish. > > Note, there are no referances to IPv4 policy, there term 'end site' > is not used (since it's not really applicable as it is currently defined), > and it allows for multi site end-user orginizations a chance to have > assignments that can all be aggregated into one routing assignment, etc... > > It's probably not perfect, but in my opinion it is better then what > was currently proposed in 2005-1. (but then I'm admitadly biased) > > Glenn Wiltse... > > My alternate proposal/wording follows. > > > -=-=-=-=-=-=-=-=-=-=-=-=-=- > > 6.5.8. Direct ARIN assignments to end-user organizations > > 6.5.8.1. To qualify for a direct ARIN assignment, a organization must: > > a) not be an IPv6 LIR/ISP; and > b) have a need for at least 1024 unique address if they are > miltihomed, or 2048 if not multi homed. > > 6.5.8.2. initial assignment size to end-user organizations. > > a) If a qualifying organization has no plans to have more then one > physical site, they shall be given a single /48. This will be > referred to as a single site end-user organization. > > b) Qualifying organizations with plans for more then one physical > site, shall be assigned a minimum /44 address block. The standard > size initial assignment shall be three times the number of sites > they currently have, if they desire more then that, they must > provide details about their plans to obtain even larger number of > new sites. > > > 6.5.8.3. Subsequent Assignments. > > a) Requests for additional ARIN assigned space to a multi site > end-user organization must be accompanied by evidence that their > internal use of /48s per site has exceeded the standard IPv6 HD > ratio requirements. Upon such a documented request the multi site > end-user organization will immediately be eligible to obtain an > additional assignment that results in doubling of the address > space assigned to it. Where possible the assignment will from an > adjacent address block, meaning that it's existing assignment is > extended by one bit to the left. > > b) Requests for additional ARIN assigned space to single site end-user > organizations will be required to give back their initial /48 and > will then be eligible for a initial assignment as a multi site > end-user organization. They will be given 1 year to return the > original /48. > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml -- 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 jason.schiller at mci.com Wed Feb 15 03:01:11 2006 From: jason.schiller at mci.com (Jason Schiller (schiller@uu.net)) Date: Wed, 15 Feb 2006 03:01:11 -0500 (EST) Subject: [ppml] Proposed Policy: MicroAllocations for Internal Infrastructure In-Reply-To: Message-ID: Louie, Thank you very much for your comments! Your point about ARIN policies not dictating or implying routability is well taken, and I suspect that language will need to be removed or changed to something like "... should NOT be routed on global Internet." What I was trying to accomplish with this sentence, was to prevent this policy from 1. being used to get PI space, and 2. making sure that this policy does not contribute to polluting the global IPv6 routing table. Does any one have any advice on some better language? Or is the policy still strong enough with out that sentence? As for allocation and assignment, I am fine with changing the word, but I guess I am a little confused about the official ARIN definition of allocation and assignment. I thought allocation is something ARIN does to LIRs (or end-sites), and assignment is something LIRs do to end-sites. If this is wrong, then I probably have the wrong words in the policy, and will be happy to change this. Can someone set this straight? ___Jason ========================================================================== Jason Schiller (703)886.6648 Senior Internet Network Engineer fax:(703)886.0512 Public IP Global Network Engineering schiller at uu.net UUNET / Verizon jason.schiller at verizonbusiness.com The good news about having an email address that is twice as long is that it increases traffic on the Internet. On Tue, 14 Feb 2006, Louis Lee wrote: > Date: Tue, 14 Feb 2006 01:01:23 -0800 > From: Louis Lee > To: ppml at arin.net > Subject: Re: [ppml] Proposed Policy: MicroAllocations for Internal > Infrastructure > > First off, my compliments to the authors of the policy > proposal for a very thorough job of explaining the > rationale of the proposal. I may have some questions > on that later. > > You've written in 6.10.3: (full text of 6.10.3 at the > bottom) > > Internal infrastructure allocations MUST NOT be > > routed on global Internet. > > While this is very well intentioned, we already have > precedence in which language regarding whether a given > assignment can or cannot be routed on the global Internet > was removed from a policy previously adopted. Aside from > the argument of whether "internal infrastructure" outside > a NAT'ed firewall is considered part of the global Internet, > ARIN policies do not dictate or imply routability. > > I understand from your proposal that if the micro-allocation > that is given under 6.10.3 happens to be announced to peers > and upstreams, it becomes an annoyance...and at worse, a > network security / stability issue. In the previous policy > to which I was referring, if that micro-allocation for IXPs > was announced to peers & transits, it would actually impact > operation directly by causing routing issues due to path > selection algorithm. And in that case, the language > restricting routability was still removed. > > (The closest that ARIN policy has to suggesting routability > is the reference to RFC1918 space in 4.3.5: Non-connected > Networks.) > > On a different point for consideration, if we are to > continue to differentiate between "allocations" and > "assignments", then the text should reflect it. We all > understand that "micro-allocation" is a misnomer, and > ARIN Registration Services has been making *assignments* > on IP requests made under the micro-allocation policy. I > do not fault you for this at all since the current text > of the micro-allocation has the same ambiguity. This may > just be a good opportunity to clarify the matter. > > The term "micro-allocation" should probably remain unaltered, > however, due to the fact that "micro-assignment" has already > taken to mean a separate policy. I don't want to create > *more* confusion! :) > > At present, I have not decided whether I support this > proposal or not. It seems to have merit, and it deserves > attention & discussion. > > Louie > -- > Louis Lee > Sr. Network Architect > New Service Development > Equinix, Inc. > louie at equinix.com > desk: 408/360-5253 > main: 650/513-7000 > > > -----Original Message----- > From: Member Services [mailto:memsvcs at arin.net] > Sent: Thursday, February 09, 2006 7:17 AM > To: ppml at arin.net > Subject: [ppml] Proposed Policy: MicroAllocations for Internal > Infrastructure > > (...) > > 6.10.3 Micro-allocation for internal infrastructure Organizations that > currently hold IPv6 allocations may apply for a micro-allocation for > internal infrastructure. Applicant must provide justification > indicating why a separate non-routed block is required. > Justification must include why a sub-allocation of currently held IP > space cannot be utilized. > > Internal infrastructure allocations MUST NOT be routed on global > Internet. > > Internal infrastructure allocations MUST be allocated from specific > blocks reserved only for this purpose. > > (...) > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From jason.schiller at mci.com Wed Feb 15 03:16:33 2006 From: jason.schiller at mci.com (Jason Schiller (schiller@uu.net)) Date: Wed, 15 Feb 2006 03:16:33 -0500 (EST) Subject: [ppml] Proposed Policy: MicroAllocations for Internal Infrastructure In-Reply-To: Message-ID: Scott, Thanks for your comments. I totally agree that section 4 should only be about IPv4 and secetion 6 should only be about IPv6. Point well taken. Thanks, ___Jason ========================================================================== Jason Schiller (703)886.6648 Senior Internet Network Engineer fax:(703)886.0512 Public IP Global Network Engineering schiller at uu.net UUNET / Verizon jason.schiller at verizonbusiness.com The good news about having an email address that is twice as long is that it increases traffic on the Internet. On Thu, 9 Feb 2006, Scott Leibrand wrote: > Date: Thu, 09 Feb 2006 18:14:54 -0500 (EST) > From: Scott Leibrand > To: Member Services > Cc: ppml at arin.net > Subject: Re: [ppml] Proposed Policy: MicroAllocations for Internal > Infrastructure > > This seems like a reasonable IPv6 MicroAllocation policy. If we're going > to replace the "/24 using IPv4 or a /48 using IPv6" language of section > 6.10 with the text below, IMO we should also modify section 4.4 to remove > the "/48 using IPv6" language and instead refer users to 6.10 for the IPv6 > MicroAllocation policy. > > Aside from that quibble, I currently support the policy proposal as > written. > > -Scott > From jeroen at unfix.org Wed Feb 15 07:26:14 2006 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 15 Feb 2006 13:26:14 +0100 Subject: [ppml] Fw: IRS goes IPv6! In-Reply-To: <031e01c631aa$563011b0$710016ac@ssprunk> References: <031e01c631aa$563011b0$710016ac@ssprunk> Message-ID: <1140006374.27853.153.camel@firenze.zurich.ibm.com> On Tue, 2006-02-14 at 14:33 -0600, Stephen Sprunk wrote: > [ Forwarded from NANOG, for those that aren't on it, and edited for > brevity ] > > Thus spake "Jeroen Massar" > > I Ar Es, > > > > At least they have received the 2610:30::/32 allocation from ARIN. > > Lets see if they how taxing they find IPv6 ;) > ... > > OrgName: Internal Revenue Service > ... > > NetRange: 2610:0030:0000:0000:0000:0000:0000:0000 - > > 2610:0030:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF > > CIDR: 2610:0030:0000:0000:0000:0000:0000:0000/32 > ... > > NetType: Direct Allocation > > How, exactly, did the IRS manage to get a direct allocation from ARIN? Did > they somehow qualify as an LIR? Did they snow the staffers? Did the US > Govt put some sort of pressure on ARIN? > There are two points I wanted to make with the email, though not many caught it I guess (could be because of the broken sentence ;) : - a pun: 'how taxing the IRS would find IPv6' * difficulty of getting the address space (alloc) * difficulty of setting up and starting to use it (deploy) - the fact that everybody can get address space. It is very simple: Current policy has 1 main entry: - requirement for more than 200 'sites' The word 'site' is very open. Every single office building of the IRS can be counted as a seperate entity. They most likely don't have connectity to the $world, but they do need address space. Thus they request from ARIN their address space, specify that they have 200++ sites and simply get it (after having paid up etc). Most likely it will never pop up on the internet, but that is not what the RIR's are for; they only provide address space and this organisation showed a requirement for address space. > If end sites like the IRS can get direct allocations today, > perhaps all this > discussion about PI space is moot and we don't need 2005-1 et al. The policy doesn't cover 1 case: SMB's who who want their own address space for various reasons (mostly being independent). For these cases their should come a new policy which allows them to get a /48 or upto something like a /40 depending on how much they really need and if they consist out of a lot of networks or just a few. These 'small' blocks should be allocated from a single large block, per RIR or globally chunked into a portion each for a RIR. This would, in case of routing scalability issues to start some aggregation or other weird tricks in those blocks, assuming that they will become the gross of the table. Shim6 and future work could then use the /48 as an ID, while using the /48 they receive from their upstream as the IP which is routed. But that is just keeping in mind the future and that we can't envision what will happen, though the math is pretty easy (every business a /48, X million businesses/other-sites globally...) Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 240 bytes Desc: This is a digitally signed message part URL: From alh-ietf at tndh.net Wed Feb 15 09:07:58 2006 From: alh-ietf at tndh.net (Tony Hain) Date: Wed, 15 Feb 2006 06:07:58 -0800 Subject: [ppml] Geo PI (draft-hain-ipv6-pi-addr-*) In-Reply-To: Message-ID: <035501c63239$39a92970$5402f20a@tndh.net> No, it is just a prefix like any other. While some deployments of PI are simply to avoid lock-in, in others it needs to be announced in multiple places. By restricting the length you limit the potential impact to the routing system. No evaluation of the network topology or plans is necessary because the prefix length is based on building/lot size. Tony > -----Original Message----- > From: Houle, Joseph D (Joe), CMO [mailto:jdhoule at att.com] > Sent: Tuesday, February 14, 2006 6:11 PM > To: Tony Hain; ppml at arin.net > Subject: RE: [ppml] Geo PI (draft-hain-ipv6-pi-addr-*) > > Tony: > And advertise that block in its entirety only from that one > geographic location? > Joe Houle > > > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of > Tony Hain > Sent: Tuesday, February 14, 2006 5:49 PM > To: ppml at arin.net > Subject: Re: [ppml] Geo PI (draft-hain-ipv6-pi-addr-*) > > I realize that ARIN policy does not talk about routability, but would it > make sense in the PI case to talk about a get-started approach where PI > allocations were made from 1000::/4 using the geo algorithm and limiting > the > accepted prefixes in that block to /40? Any organization that could not > claim unique possession to at least one physical lot of 100 meters in > any > direction would not make the cut. No exchange points or business > practice > changes required... > > If that still feels like too many PI entries, make the limit a /36 which > would cut it back to those organizations with a 400 meter footprint. > > Tony > > > > -----Original Message----- > > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf > Of > > Tony Hain > > Sent: Sunday, February 05, 2006 10:28 PM > > To: 'Scott Leibrand'; ppml at arin.net > > Subject: Re: [ppml] Geo PI (draft-hain-ipv6-pi-addr-*) > > > > Scott Leibrand wrote: > > > Tony, > > > > > > I think an approach to lat/long PI addressing such as your > > > draft-hain-ipv6-pi-addr-09.txt may be a solid foundation for > choosing > > the > > > PI > > > block to assign to each individual organization. However, I think > your > > > draft-hain-ipv6-pi-addr-use-09.txt proposals, and previous > discussion of > > > similar ideas on PPML, have over-engineered the use cases and the > > > implications for routing and exchange points. In particular, I read > > your > > > drafts as requiring that all ISPs in a region would have to agree on > the > > > level of aggregation for the region and that all ISPs in that region > > > interconnect at an exchange point, and also encouraging ISPs to > filter > > > more-specifics heard from their peers based on how many routes each > > origin > > > AS announces and/or a certain prefix length. I think that all these > > > requirements/suggestions are unnecessarily restrictive stipulations > that > > > encourage unnecessary opposition to the proposal. > > > > Exchange points are discussed, but would only really be required to > > suppress > > the basement multi-homer. There are business model issues tied up in > this > > that will take a long time to resolve if they ever do. In the short > term > > just basing PI allocations on this model would at least allow for the > > option > > later where random PI assignments would be difficult to sort out. > > > > > > > > Here's what I see as a more realistic application of Geo PI: > > > > > > - Implement some sort of geography-based PI addressing scheme, > either > > one > > > like draft-hain-ipv6-pi-addr-09.txt, a population-based scheme like > > > Michael > > > Dillon has advocated, or something more like our current system, > where > > > RIRs > > > allocate PI blocks to individual companies, but choose the > particular > > > netblock to allocate based on one of the schemes above. (I'm not > sure > > > which > > > of those approaches is superior, but we can debate the merits of > each > > > separately.) > > > > To judge there needs to be some agreed on goals. The IETF effort in > that > > space showed how there can never be agreement since the requirements > of > > the > > ISP community and the end site community are in direct conflict. > > > > > - Initially, multihomed organizations allocated PI space would > probably > > > route them the exact same way they do IPv4 PI space today, > announcing it > > > in > > > BGP to their transit providers, who would advertise it to everyone > on > > the > > > planet with a full BGP feed (the DFZ). > > > > A presumption for all approaches is that organizations that have an AS > > entry > > in BGP will have at least one prefix. Hopefully one will be > sufficient, > > but > > I am hearing noise that some organizations want hundreds to deal with > > their > > VPN scenario. > > > > > - At some future point, some global tier 1 NSPs* may decide that > the > > > routing table growth is causing problems for their routers. At that > > > point, > > > they can begin aggregating PI space within their own network, such > that > > > within a region (which could be a BGP confederation sub-AS, for > example) > > > all > > > more-specifics for that region are carried, but only the PI > aggregate is > > > carried outside the region. In order for an tier 1 NSP to do this > > > effectively, they would have to ensure that all of their peers have > at > > > least > > > two peering points within the region (private peering or exchanged- > > based, > > > it > > > doesn't matter), so that their peers can reach them and their > customers' > > > PI > > > more-specifics for that region. > > > > I didn't want to get into the details of engineering the region more > than > > to > > point out that some interchange will have to happen. > > > > > - For transit customers outside the aggregated region, the tier 1 > NSP > > > would > > > be able to just advertise the PI aggregate. For peers who only peer > > > outside > > > the region, the NSP could do one of several things: they could > simply > > > advertise the peer their PI aggregate, which opens the possibility > of > > > providing transit connectivity to the peer; they could carry all > > > more-specifics from the aggregated region to the peering router(s), > > which > > > would probably require a multihop BGP session or a tunnel; or they > could > > > simply not advertise routes from the aggregated region to their peer > > > outside > > > that region, requiring the peer to set up a peering point within the > > > aggregated region or buy transit connectivity for traffic to that > > region. > > > > The business models will develop based on what makes sense for that > > specific > > region. > > > > > - When two or more NSPs set up such aggregation, a customer > multi-homed > > > to > > > both NSPs would be able to announce their PI deaggregate to their > > transit > > > providers just as they do now. Anyone trying to reach the customer > from > > > within the region (or from an NSP that doesn't aggregate) would be > able > > to > > > choose between the two resulting BGP paths. Anyone trying to reach > the > > > customer from outside the region would see the customer's IP space > as > > part > > > of a regional aggregate, and would route their traffic towards the > > region. > > > Once the traffic arrived at the region, it would reach a router > which > > > would > > > be able to choose between the two deaggregated paths, based on the > BGP > > > metrics (localpref, AS path, MEDs, etc.) set by the origin AS. > > > - If the two NSPs the customer multi-homes to decide to aggregate > > > differently, it might affect the traffic balance inbound to the > multi- > > > homed > > > customer, but the customer will still have the leeway to adjust > their > > > announcements to compensate. For example, if NSP A aggregates a > smaller > > > region to a /32, and NSP B aggregates a larger region to a /28, then > > > traffic > > > from outside the larger region would prefer NSP A, while traffic > from > > the > > > in-between region would prefer NSP B, as the route would still be a > > > deaggregate over NSP B in that region. Once traffic reached the > smaller > > > region, the origin AS's BGP metrics would take over. > > > > > > My point here is not that NSPs have to do things this way, but > rather > > that > > > a > > > geography-based PI allocation scheme allows them to continue > operating > > > with > > > the current model as long as they want to, and also gives them the > > > flexibility to begin gradually aggregating PI space within their > network > > > as > > > they see fit (for example by starting with large regions like > > continents, > > > an > > > later aggregating on a more regional basis as needed). We can > implement > > > such a geography-based PI allocation scheme *without* requiring > everyone > > > (or > > > anyone) in a region to set up new interconnections, and without > > requiring > > > anyone to coordinate the precise size of aggregated regions (and > thereby > > > the > > > length of aggregate prefixes). IMO that makes it *much* more likely > > that > > > such a system could reach consensus and actually get implemented. > > > > I don't expect transit providers to even consider aggregation until > there > > is > > an exchange point in the region acting as their customer and fronting > for > > the local distribution of traffic. Fortunately it is not required to > get > > started and can come along when it makes more sense to aggregate than > to > > buy > > bigger routers. > > > > Thanks for the feedback, > > Tony > > > > > > > > > > -Scott > > > > > > * A global tier 1 NSP means one who has a global backbone, don't buy > > > transit > > > from anyone, and have full reachability to the rest of the Internet > via > > > peering arrangements). > > > > > > P.S. Is there an IETF WG mailing list that draft-hain-ipv6-pi-addr* > > belong > > > to? If so, I'd like to subscribe and cross-post the above message > there > > > as > > > well. TIA. > > > > > > > > > ----- Original Message ----- > > > From: "Tony Hain" > > > To: > > > Sent: Thursday, February 02, 2006 8:20 PM > > > Subject: Re: [ppml] 2005-1 status > > > > > > > > > > An alternative to protocol design in either the routing space or > host > > > > stacks > > > > is to reconsider the myth of a global DFZ. The divergence in > > routeviews > > > > should already trigger the flag that there is no such thing as a > > > globally > > > > common DFZ, so arguing PI allocation policy in the context of its > > impact > > > > on > > > > this mythical entity is bound to drag on. > > > > > > > > I just refreshed my geo I-D's > > > > http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-09.txt > > > > > http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-use-09.txt > > > > > > > > Rather than argue about the topology/geography argument, please > > consider > > > > that this is: > > > > 1) an identifiable block > > > > 2) does not require any changes to existing hosts or routers > > > > 3) removes any arguments about prefix length vs. organizational > size > > > > 4) allows for simple proxy aggregation where the detail becomes > > > irrelevant > > > > 5) debases ITU/national arguments over access to sovereign > allocations > > > > > > > > In the worst case these degenerate to the same number of routing > slots > > > as > > > > an > > > > arbitrary RIR allocation process. At the same time they lay a > > foundation > > > > where alternative business practices can evolve to better align > the > > > costs > > > > involved. > > > > > > > > Comments are always welcome (particularly thoughts about how to > > resolve > > > > the > > > > altitude problem) > > > > > > > > Tony > > > > > > > > > > > >> -----Original Message----- > > > >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf > > Of > > > >> Scott Leibrand > > > >> Sent: Thursday, February 02, 2006 6:12 AM > > > >> To: Bill Darte > > > >> Cc: ppml at arin.net > > > >> Subject: Re: [ppml] 2005-1 status > > > >> > > > >> Bill and Owen, > > > >> > > > >> What if the IETF comes up with a routing architecture / protocol > > design > > > >> that allows for effective multihoming with PA space? That seems > more > > > >> likely to me (in the near term) than a complete replacement of > BGP4. > > > >> > > > >> IMO policy should recognize the status quo for what it is: the > way > > > things > > > >> are done. If the status quo needs to change, fine. That's why > we're > > > >> debating 2005-1. But I think it's dangerous to make policy with > the > > > goal > > > >> of breaking things so that someone else will be forced to fix > them > > > later. > > > >> IMO we should make policy that meets the current needs of our > > > >> constituents, and strive to meet their future needs by working > > through > > > >> the > > > >> IETF process to fix the routing architecture, and then modifying > > policy > > > >> in > > > >> the future when future interests have emerged and we have a > clearer > > > idea > > > >> of the tradeoffs. > > > >> > > > >> -Scott > > > >> > > > >> On 02/02/06 at 8:15am -0600, Bill Darte > wrote: > > > >> > > > >> > Owen, > > > >> > > > > >> > My personal belief is that you frame the question(s) > appropriately > > in > > > >> this > > > >> > post. > > > >> > If the architecture of the Internet no longer serves the > emerging > > > >> interests > > > >> > of the constituents, then the architecture should change, > rather > > than > > > >> trying > > > >> > to craft discriminating address policy that preserves the > status > > quo. > > > >> > > > > >> > On a slightly different topic, with the PI for endsites policy, > > there > > > >> > is > > > >> no > > > >> > stipulation about the v4 blocks that exist in the v6 recipients > > > >> > 'possession'. You are assuming that that legacy assignment > would > > > >> > endure > > > >> in > > > >> > perpetuity? You have no expectation that the v6 block would > require > > > the > > > >> > legacy v4 blocks, whether PA or PI to be returned? > > > >> > > > > >> > I'm not suggesting this be the case...just want this issue to > be > > > >> addressed. > > > >> > > > > >> > bd > > > >> > > > > >> > > -----Original Message----- > > > >> > > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > > > >> > > Behalf Of Owen DeLong > > > >> > > Sent: Thursday, February 02, 2006 12:35 AM > > > >> > > To: Scott Leibrand; George Kuzmowycz > > > >> > > Cc: ppml at arin.net > > > >> > > Subject: Re: [ppml] 2005-1 status > > > >> > > > > > >> > > > > > >> > > _______________________________________________ > > > >> > > 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 > > > >> > > > > >> _______________________________________________ > > > >> 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 > > > > > > > > _______________________________________________ > > 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 From sleibrand at internap.com Wed Feb 15 09:18:39 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 15 Feb 2006 09:18:39 -0500 (EST) Subject: [ppml] Geo PI (draft-hain-ipv6-pi-addr-*) In-Reply-To: <028601c631c1$2c37a050$5402f20a@tndh.net> References: <028601c631c1$2c37a050$5402f20a@tndh.net> Message-ID: Tony, I think a get-started approach is what's needed. In my opinion this kind of approach should avoid any additional restrictions, but would simply direct ARIN to take into account geography in deciding *which* netblock (not how large a netblock) to assign to an org. The simplest case (and therefore the easiest to get consensus for) would be to have ARIN take the street address of the applicant, geo-locate that with available tools like Google|Yahoo Maps, Mapquest, etc., and then allocate the nearest netblock of the required size. In order for this to be possible, it would seem that we'd first need to get your Internet-Draft through the standards process and get IANA to allocate a netblock like 1000::/4 for allocation in a geographic manner. This probably couldn't be done by the cutoff for ARIN 17 (Montreal) policy proposals, but do you think we'd be in a position to make a policy proposal for consideration at ARIN 18? If so, it should be rather simple IMO to modify any PI policy approved at ARIN 17 to add get-started geo language... -Scott On 02/14/06 at 3:48pm -0800, Tony Hain wrote: > I realize that ARIN policy does not talk about routability, but would it > make sense in the PI case to talk about a get-started approach where PI > allocations were made from 1000::/4 using the geo algorithm and limiting the > accepted prefixes in that block to /40? Any organization that could not > claim unique possession to at least one physical lot of 100 meters in any > direction would not make the cut. No exchange points or business practice > changes required... > > If that still feels like too many PI entries, make the limit a /36 which > would cut it back to those organizations with a 400 meter footprint. > > Tony > > > > -----Original Message----- > > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of > > Tony Hain > > Sent: Sunday, February 05, 2006 10:28 PM > > To: 'Scott Leibrand'; ppml at arin.net > > Subject: Re: [ppml] Geo PI (draft-hain-ipv6-pi-addr-*) > > > > Scott Leibrand wrote: > > > Tony, > > > > > > I think an approach to lat/long PI addressing such as your > > > draft-hain-ipv6-pi-addr-09.txt may be a solid foundation for choosing > > the > > > PI > > > block to assign to each individual organization. However, I think your > > > draft-hain-ipv6-pi-addr-use-09.txt proposals, and previous discussion of > > > similar ideas on PPML, have over-engineered the use cases and the > > > implications for routing and exchange points. In particular, I read > > your > > > drafts as requiring that all ISPs in a region would have to agree on the > > > level of aggregation for the region and that all ISPs in that region > > > interconnect at an exchange point, and also encouraging ISPs to filter > > > more-specifics heard from their peers based on how many routes each > > origin > > > AS announces and/or a certain prefix length. I think that all these > > > requirements/suggestions are unnecessarily restrictive stipulations that > > > encourage unnecessary opposition to the proposal. > > > > Exchange points are discussed, but would only really be required to > > suppress > > the basement multi-homer. There are business model issues tied up in this > > that will take a long time to resolve if they ever do. In the short term > > just basing PI allocations on this model would at least allow for the > > option > > later where random PI assignments would be difficult to sort out. > > > > > > > > Here's what I see as a more realistic application of Geo PI: > > > > > > - Implement some sort of geography-based PI addressing scheme, either > > one > > > like draft-hain-ipv6-pi-addr-09.txt, a population-based scheme like > > > Michael > > > Dillon has advocated, or something more like our current system, where > > > RIRs > > > allocate PI blocks to individual companies, but choose the particular > > > netblock to allocate based on one of the schemes above. (I'm not sure > > > which > > > of those approaches is superior, but we can debate the merits of each > > > separately.) > > > > To judge there needs to be some agreed on goals. The IETF effort in that > > space showed how there can never be agreement since the requirements of > > the > > ISP community and the end site community are in direct conflict. > > > > > - Initially, multihomed organizations allocated PI space would probably > > > route them the exact same way they do IPv4 PI space today, announcing it > > > in > > > BGP to their transit providers, who would advertise it to everyone on > > the > > > planet with a full BGP feed (the DFZ). > > > > A presumption for all approaches is that organizations that have an AS > > entry > > in BGP will have at least one prefix. Hopefully one will be sufficient, > > but > > I am hearing noise that some organizations want hundreds to deal with > > their > > VPN scenario. > > > > > - At some future point, some global tier 1 NSPs* may decide that the > > > routing table growth is causing problems for their routers. At that > > > point, > > > they can begin aggregating PI space within their own network, such that > > > within a region (which could be a BGP confederation sub-AS, for example) > > > all > > > more-specifics for that region are carried, but only the PI aggregate is > > > carried outside the region. In order for an tier 1 NSP to do this > > > effectively, they would have to ensure that all of their peers have at > > > least > > > two peering points within the region (private peering or exchanged- > > based, > > > it > > > doesn't matter), so that their peers can reach them and their customers' > > > PI > > > more-specifics for that region. > > > > I didn't want to get into the details of engineering the region more than > > to > > point out that some interchange will have to happen. > > > > > - For transit customers outside the aggregated region, the tier 1 NSP > > > would > > > be able to just advertise the PI aggregate. For peers who only peer > > > outside > > > the region, the NSP could do one of several things: they could simply > > > advertise the peer their PI aggregate, which opens the possibility of > > > providing transit connectivity to the peer; they could carry all > > > more-specifics from the aggregated region to the peering router(s), > > which > > > would probably require a multihop BGP session or a tunnel; or they could > > > simply not advertise routes from the aggregated region to their peer > > > outside > > > that region, requiring the peer to set up a peering point within the > > > aggregated region or buy transit connectivity for traffic to that > > region. > > > > The business models will develop based on what makes sense for that > > specific > > region. > > > > > - When two or more NSPs set up such aggregation, a customer multi-homed > > > to > > > both NSPs would be able to announce their PI deaggregate to their > > transit > > > providers just as they do now. Anyone trying to reach the customer from > > > within the region (or from an NSP that doesn't aggregate) would be able > > to > > > choose between the two resulting BGP paths. Anyone trying to reach the > > > customer from outside the region would see the customer's IP space as > > part > > > of a regional aggregate, and would route their traffic towards the > > region. > > > Once the traffic arrived at the region, it would reach a router which > > > would > > > be able to choose between the two deaggregated paths, based on the BGP > > > metrics (localpref, AS path, MEDs, etc.) set by the origin AS. > > > - If the two NSPs the customer multi-homes to decide to aggregate > > > differently, it might affect the traffic balance inbound to the multi- > > > homed > > > customer, but the customer will still have the leeway to adjust their > > > announcements to compensate. For example, if NSP A aggregates a smaller > > > region to a /32, and NSP B aggregates a larger region to a /28, then > > > traffic > > > from outside the larger region would prefer NSP A, while traffic from > > the > > > in-between region would prefer NSP B, as the route would still be a > > > deaggregate over NSP B in that region. Once traffic reached the smaller > > > region, the origin AS's BGP metrics would take over. > > > > > > My point here is not that NSPs have to do things this way, but rather > > that > > > a > > > geography-based PI allocation scheme allows them to continue operating > > > with > > > the current model as long as they want to, and also gives them the > > > flexibility to begin gradually aggregating PI space within their network > > > as > > > they see fit (for example by starting with large regions like > > continents, > > > an > > > later aggregating on a more regional basis as needed). We can implement > > > such a geography-based PI allocation scheme *without* requiring everyone > > > (or > > > anyone) in a region to set up new interconnections, and without > > requiring > > > anyone to coordinate the precise size of aggregated regions (and thereby > > > the > > > length of aggregate prefixes). IMO that makes it *much* more likely > > that > > > such a system could reach consensus and actually get implemented. > > > > I don't expect transit providers to even consider aggregation until there > > is > > an exchange point in the region acting as their customer and fronting for > > the local distribution of traffic. Fortunately it is not required to get > > started and can come along when it makes more sense to aggregate than to > > buy > > bigger routers. > > > > Thanks for the feedback, > > Tony > > > > > > > > > > -Scott > > > > > > * A global tier 1 NSP means one who has a global backbone, don't buy > > > transit > > > from anyone, and have full reachability to the rest of the Internet via > > > peering arrangements). > > > > > > P.S. Is there an IETF WG mailing list that draft-hain-ipv6-pi-addr* > > belong > > > to? If so, I'd like to subscribe and cross-post the above message there > > > as > > > well. TIA. > > > > > > > > > ----- Original Message ----- > > > From: "Tony Hain" > > > To: > > > Sent: Thursday, February 02, 2006 8:20 PM > > > Subject: Re: [ppml] 2005-1 status > > > > > > > > > > An alternative to protocol design in either the routing space or host > > > > stacks > > > > is to reconsider the myth of a global DFZ. The divergence in > > routeviews > > > > should already trigger the flag that there is no such thing as a > > > globally > > > > common DFZ, so arguing PI allocation policy in the context of its > > impact > > > > on > > > > this mythical entity is bound to drag on. > > > > > > > > I just refreshed my geo I-D's > > > > http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-09.txt > > > > http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-use-09.txt > > > > > > > > Rather than argue about the topology/geography argument, please > > consider > > > > that this is: > > > > 1) an identifiable block > > > > 2) does not require any changes to existing hosts or routers > > > > 3) removes any arguments about prefix length vs. organizational size > > > > 4) allows for simple proxy aggregation where the detail becomes > > > irrelevant > > > > 5) debases ITU/national arguments over access to sovereign allocations > > > > > > > > In the worst case these degenerate to the same number of routing slots > > > as > > > > an > > > > arbitrary RIR allocation process. At the same time they lay a > > foundation > > > > where alternative business practices can evolve to better align the > > > costs > > > > involved. > > > > > > > > Comments are always welcome (particularly thoughts about how to > > resolve > > > > the > > > > altitude problem) > > > > > > > > Tony > > > > > > > > > > > >> -----Original Message----- > > > >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf > > Of > > > >> Scott Leibrand > > > >> Sent: Thursday, February 02, 2006 6:12 AM > > > >> To: Bill Darte > > > >> Cc: ppml at arin.net > > > >> Subject: Re: [ppml] 2005-1 status > > > >> > > > >> Bill and Owen, > > > >> > > > >> What if the IETF comes up with a routing architecture / protocol > > design > > > >> that allows for effective multihoming with PA space? That seems more > > > >> likely to me (in the near term) than a complete replacement of BGP4. > > > >> > > > >> IMO policy should recognize the status quo for what it is: the way > > > things > > > >> are done. If the status quo needs to change, fine. That's why we're > > > >> debating 2005-1. But I think it's dangerous to make policy with the > > > goal > > > >> of breaking things so that someone else will be forced to fix them > > > later. > > > >> IMO we should make policy that meets the current needs of our > > > >> constituents, and strive to meet their future needs by working > > through > > > >> the > > > >> IETF process to fix the routing architecture, and then modifying > > policy > > > >> in > > > >> the future when future interests have emerged and we have a clearer > > > idea > > > >> of the tradeoffs. > > > >> > > > >> -Scott > > > >> > > > >> On 02/02/06 at 8:15am -0600, Bill Darte wrote: > > > >> > > > >> > Owen, > > > >> > > > > >> > My personal belief is that you frame the question(s) appropriately > > in > > > >> this > > > >> > post. > > > >> > If the architecture of the Internet no longer serves the emerging > > > >> interests > > > >> > of the constituents, then the architecture should change, rather > > than > > > >> trying > > > >> > to craft discriminating address policy that preserves the status > > quo. > > > >> > > > > >> > On a slightly different topic, with the PI for endsites policy, > > there > > > >> > is > > > >> no > > > >> > stipulation about the v4 blocks that exist in the v6 recipients > > > >> > 'possession'. You are assuming that that legacy assignment would > > > >> > endure > > > >> in > > > >> > perpetuity? You have no expectation that the v6 block would require > > > the > > > >> > legacy v4 blocks, whether PA or PI to be returned? > > > >> > > > > >> > I'm not suggesting this be the case...just want this issue to be > > > >> addressed. > > > >> > > > > >> > bd > > > >> > > > > >> > > -----Original Message----- > > > >> > > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > > > >> > > Behalf Of Owen DeLong > > > >> > > Sent: Thursday, February 02, 2006 12:35 AM > > > >> > > To: Scott Leibrand; George Kuzmowycz > > > >> > > Cc: ppml at arin.net > > > >> > > Subject: Re: [ppml] 2005-1 status > > > >> > > > > > >> > > > > > >> > > _______________________________________________ > > > >> > > 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 > > > >> > > > > >> _______________________________________________ > > > >> 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 > > > > > > > > _______________________________________________ > > 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 > From Michael.Dillon at btradianz.com Wed Feb 15 09:44:59 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 15 Feb 2006 14:44:59 +0000 Subject: [ppml] Fw: protocols that don't meet the need... Message-ID: The attached message was just posted to the NANOG mailing list. I agree with Per that it is unwise to make policies based on stuff that is in-progress in the IETF and may, or may not, come through the IETF process. This applies to shim6 or anything else that is in an unimplemented Internet draft such as Tony Hain's geo-addressing proposal. We have to make our policies based on what is here today. > It's the lack of reality in operational policies that is the real source > of frustration in ops communities. People are picking on shim6 because > it is used as an argument to back the current policies at a time when it > doesn't even have an early alpha-implementation to show for it. Policies > built around shim6 may be ok in 5 or 10 years if or when it is mature > with supporting technology to handle large networks, but not now. In the > meantime we need a policy that can accomodate the need for multihoming > of end-sites with *existing* technology. Without such a policy we will > have anarchy with LIRs making their own policies (fragmentation) and > people telling lies to qualify as a LIR to obtain independent blocks > (unless there's a way to delay v6 deployment until there is technology > available to back the current policy). > > > //per > -- > Per Heldal > http://heldal.eml.cc/ > From tme at multicasttech.com Wed Feb 15 10:16:36 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Wed, 15 Feb 2006 10:16:36 -0500 Subject: [ppml] Geo PI (draft-hain-ipv6-pi-addr-*) In-Reply-To: <028601c631c1$2c37a050$5402f20a@tndh.net> References: <028601c631c1$2c37a050$5402f20a@tndh.net> Message-ID: Hello; On Feb 14, 2006, at 6:48 PM, Tony Hain wrote: > I realize that ARIN policy does not talk about routability, but > would it > make sense in the PI case to talk about a get-started approach > where PI > allocations were made from 1000::/4 using the geo algorithm and > limiting the > accepted prefixes in that block to /40? Any organization that could > not > claim unique possession to at least one physical lot of 100 meters > in any What does this mean ? That you need a physical space of 10^4 (100 x 100) meters ? Did you mean to say 100 square meters ? Or that you need to be within 100 meters of the center of the block ? And, who would attest to this ? One advantage of, say, zip codes is that there is an outside entity that instantiates them. If I say I have a rack at 103deg32min17.15sec West, 39deg44min22.4sec North, how do I prove that ? Normal surveying methods don't work inside a building, and anyway are pretty expensive in this context. If I am allowed to just make it up (i.e., you trust my GPS reading), then what's the point ? You can bet a lot of people would just make it up. Regards Marshall > direction would not make the cut. No exchange points or business > practice > changes required... > > If that still feels like too many PI entries, make the limit a /36 > which > would cut it back to those organizations with a 400 meter footprint. > > Tony > > >> -----Original Message----- >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On >> Behalf Of >> Tony Hain >> Sent: Sunday, February 05, 2006 10:28 PM >> To: 'Scott Leibrand'; ppml at arin.net >> Subject: Re: [ppml] Geo PI (draft-hain-ipv6-pi-addr-*) >> >> Scott Leibrand wrote: >>> Tony, >>> >>> I think an approach to lat/long PI addressing such as your >>> draft-hain-ipv6-pi-addr-09.txt may be a solid foundation for >>> choosing >> the >>> PI >>> block to assign to each individual organization. However, I >>> think your >>> draft-hain-ipv6-pi-addr-use-09.txt proposals, and previous >>> discussion of >>> similar ideas on PPML, have over-engineered the use cases and the >>> implications for routing and exchange points. In particular, I read >> your >>> drafts as requiring that all ISPs in a region would have to agree >>> on the >>> level of aggregation for the region and that all ISPs in that region >>> interconnect at an exchange point, and also encouraging ISPs to >>> filter >>> more-specifics heard from their peers based on how many routes each >> origin >>> AS announces and/or a certain prefix length. I think that all these >>> requirements/suggestions are unnecessarily restrictive >>> stipulations that >>> encourage unnecessary opposition to the proposal. >> >> Exchange points are discussed, but would only really be required to >> suppress >> the basement multi-homer. There are business model issues tied up >> in this >> that will take a long time to resolve if they ever do. In the >> short term >> just basing PI allocations on this model would at least allow for the >> option >> later where random PI assignments would be difficult to sort out. >> >>> >>> Here's what I see as a more realistic application of Geo PI: >>> >>> - Implement some sort of geography-based PI addressing scheme, >>> either >> one >>> like draft-hain-ipv6-pi-addr-09.txt, a population-based scheme like >>> Michael >>> Dillon has advocated, or something more like our current system, >>> where >>> RIRs >>> allocate PI blocks to individual companies, but choose the >>> particular >>> netblock to allocate based on one of the schemes above. (I'm not >>> sure >>> which >>> of those approaches is superior, but we can debate the merits of >>> each >>> separately.) >> >> To judge there needs to be some agreed on goals. The IETF effort >> in that >> space showed how there can never be agreement since the >> requirements of >> the >> ISP community and the end site community are in direct conflict. >> >>> - Initially, multihomed organizations allocated PI space would >>> probably >>> route them the exact same way they do IPv4 PI space today, >>> announcing it >>> in >>> BGP to their transit providers, who would advertise it to >>> everyone on >> the >>> planet with a full BGP feed (the DFZ). >> >> A presumption for all approaches is that organizations that have >> an AS >> entry >> in BGP will have at least one prefix. Hopefully one will be >> sufficient, >> but >> I am hearing noise that some organizations want hundreds to deal with >> their >> VPN scenario. >> >>> - At some future point, some global tier 1 NSPs* may decide that >>> the >>> routing table growth is causing problems for their routers. At that >>> point, >>> they can begin aggregating PI space within their own network, >>> such that >>> within a region (which could be a BGP confederation sub-AS, for >>> example) >>> all >>> more-specifics for that region are carried, but only the PI >>> aggregate is >>> carried outside the region. In order for an tier 1 NSP to do this >>> effectively, they would have to ensure that all of their peers >>> have at >>> least >>> two peering points within the region (private peering or exchanged- >> based, >>> it >>> doesn't matter), so that their peers can reach them and their >>> customers' >>> PI >>> more-specifics for that region. >> >> I didn't want to get into the details of engineering the region >> more than >> to >> point out that some interchange will have to happen. >> >>> - For transit customers outside the aggregated region, the tier >>> 1 NSP >>> would >>> be able to just advertise the PI aggregate. For peers who only peer >>> outside >>> the region, the NSP could do one of several things: they could >>> simply >>> advertise the peer their PI aggregate, which opens the >>> possibility of >>> providing transit connectivity to the peer; they could carry all >>> more-specifics from the aggregated region to the peering router(s), >> which >>> would probably require a multihop BGP session or a tunnel; or >>> they could >>> simply not advertise routes from the aggregated region to their peer >>> outside >>> that region, requiring the peer to set up a peering point within the >>> aggregated region or buy transit connectivity for traffic to that >> region. >> >> The business models will develop based on what makes sense for that >> specific >> region. >> >>> - When two or more NSPs set up such aggregation, a customer >>> multi-homed >>> to >>> both NSPs would be able to announce their PI deaggregate to their >> transit >>> providers just as they do now. Anyone trying to reach the >>> customer from >>> within the region (or from an NSP that doesn't aggregate) would >>> be able >> to >>> choose between the two resulting BGP paths. Anyone trying to >>> reach the >>> customer from outside the region would see the customer's IP >>> space as >> part >>> of a regional aggregate, and would route their traffic towards the >> region. >>> Once the traffic arrived at the region, it would reach a router >>> which >>> would >>> be able to choose between the two deaggregated paths, based on >>> the BGP >>> metrics (localpref, AS path, MEDs, etc.) set by the origin AS. >>> - If the two NSPs the customer multi-homes to decide to aggregate >>> differently, it might affect the traffic balance inbound to the >>> multi- >>> homed >>> customer, but the customer will still have the leeway to adjust >>> their >>> announcements to compensate. For example, if NSP A aggregates a >>> smaller >>> region to a /32, and NSP B aggregates a larger region to a /28, then >>> traffic >>> from outside the larger region would prefer NSP A, while traffic >>> from >> the >>> in-between region would prefer NSP B, as the route would still be a >>> deaggregate over NSP B in that region. Once traffic reached the >>> smaller >>> region, the origin AS's BGP metrics would take over. >>> >>> My point here is not that NSPs have to do things this way, but >>> rather >> that >>> a >>> geography-based PI allocation scheme allows them to continue >>> operating >>> with >>> the current model as long as they want to, and also gives them the >>> flexibility to begin gradually aggregating PI space within their >>> network >>> as >>> they see fit (for example by starting with large regions like >> continents, >>> an >>> later aggregating on a more regional basis as needed). We can >>> implement >>> such a geography-based PI allocation scheme *without* requiring >>> everyone >>> (or >>> anyone) in a region to set up new interconnections, and without >> requiring >>> anyone to coordinate the precise size of aggregated regions (and >>> thereby >>> the >>> length of aggregate prefixes). IMO that makes it *much* more likely >> that >>> such a system could reach consensus and actually get implemented. >> >> I don't expect transit providers to even consider aggregation >> until there >> is >> an exchange point in the region acting as their customer and >> fronting for >> the local distribution of traffic. Fortunately it is not required >> to get >> started and can come along when it makes more sense to aggregate >> than to >> buy >> bigger routers. >> >> Thanks for the feedback, >> Tony >> >> >>> >>> -Scott >>> >>> * A global tier 1 NSP means one who has a global backbone, don't buy >>> transit >>> from anyone, and have full reachability to the rest of the >>> Internet via >>> peering arrangements). >>> >>> P.S. Is there an IETF WG mailing list that draft-hain-ipv6-pi-addr* >> belong >>> to? If so, I'd like to subscribe and cross-post the above >>> message there >>> as >>> well. TIA. >>> >>> >>> ----- Original Message ----- >>> From: "Tony Hain" >>> To: >>> Sent: Thursday, February 02, 2006 8:20 PM >>> Subject: Re: [ppml] 2005-1 status >>> >>> >>>> An alternative to protocol design in either the routing space or >>>> host >>>> stacks >>>> is to reconsider the myth of a global DFZ. The divergence in >> routeviews >>>> should already trigger the flag that there is no such thing as a >>> globally >>>> common DFZ, so arguing PI allocation policy in the context of its >> impact >>>> on >>>> this mythical entity is bound to drag on. >>>> >>>> I just refreshed my geo I-D's >>>> http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-09.txt >>>> http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr- >>>> use-09.txt >>>> >>>> Rather than argue about the topology/geography argument, please >> consider >>>> that this is: >>>> 1) an identifiable block >>>> 2) does not require any changes to existing hosts or routers >>>> 3) removes any arguments about prefix length vs. organizational >>>> size >>>> 4) allows for simple proxy aggregation where the detail becomes >>> irrelevant >>>> 5) debases ITU/national arguments over access to sovereign >>>> allocations >>>> >>>> In the worst case these degenerate to the same number of routing >>>> slots >>> as >>>> an >>>> arbitrary RIR allocation process. At the same time they lay a >> foundation >>>> where alternative business practices can evolve to better align the >>> costs >>>> involved. >>>> >>>> Comments are always welcome (particularly thoughts about how to >> resolve >>>> the >>>> altitude problem) >>>> >>>> Tony >>>> >>>> >>>>> -----Original Message----- >>>>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On >>>>> Behalf >> Of >>>>> Scott Leibrand >>>>> Sent: Thursday, February 02, 2006 6:12 AM >>>>> To: Bill Darte >>>>> Cc: ppml at arin.net >>>>> Subject: Re: [ppml] 2005-1 status >>>>> >>>>> Bill and Owen, >>>>> >>>>> What if the IETF comes up with a routing architecture / protocol >> design >>>>> that allows for effective multihoming with PA space? That >>>>> seems more >>>>> likely to me (in the near term) than a complete replacement of >>>>> BGP4. >>>>> >>>>> IMO policy should recognize the status quo for what it is: the way >>> things >>>>> are done. If the status quo needs to change, fine. That's why >>>>> we're >>>>> debating 2005-1. But I think it's dangerous to make policy >>>>> with the >>> goal >>>>> of breaking things so that someone else will be forced to fix them >>> later. >>>>> IMO we should make policy that meets the current needs of our >>>>> constituents, and strive to meet their future needs by working >> through >>>>> the >>>>> IETF process to fix the routing architecture, and then modifying >> policy >>>>> in >>>>> the future when future interests have emerged and we have a >>>>> clearer >>> idea >>>>> of the tradeoffs. >>>>> >>>>> -Scott >>>>> >>>>> On 02/02/06 at 8:15am -0600, Bill Darte >>>>> wrote: >>>>> >>>>>> Owen, >>>>>> >>>>>> My personal belief is that you frame the question(s) >>>>>> appropriately >> in >>>>> this >>>>>> post. >>>>>> If the architecture of the Internet no longer serves the emerging >>>>> interests >>>>>> of the constituents, then the architecture should change, rather >> than >>>>> trying >>>>>> to craft discriminating address policy that preserves the status >> quo. >>>>>> >>>>>> On a slightly different topic, with the PI for endsites policy, >> there >>>>>> is >>>>> no >>>>>> stipulation about the v4 blocks that exist in the v6 recipients >>>>>> 'possession'. You are assuming that that legacy assignment would >>>>>> endure >>>>> in >>>>>> perpetuity? You have no expectation that the v6 block would >>>>>> require >>> the >>>>>> legacy v4 blocks, whether PA or PI to be returned? >>>>>> >>>>>> I'm not suggesting this be the case...just want this issue to be >>>>> addressed. >>>>>> >>>>>> bd >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On >>>>>>> Behalf Of Owen DeLong >>>>>>> Sent: Thursday, February 02, 2006 12:35 AM >>>>>>> To: Scott Leibrand; George Kuzmowycz >>>>>>> Cc: ppml at arin.net >>>>>>> Subject: Re: [ppml] 2005-1 status >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >> >> _______________________________________________ >> 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 From iggy at merit.edu Wed Feb 15 11:31:50 2006 From: iggy at merit.edu (Glenn Wiltse) Date: Wed, 15 Feb 2006 11:31:50 -0500 (EST) Subject: [ppml] New Alternative Text... was: version thought In-Reply-To: <97E644DB6D2E5D9019BBC0DD@imac-en0.delong.sj.ca.us> References: <005d01c63170$dfd90dc0$1d0200c1@FluffyBunny> <97E644DB6D2E5D9019BBC0DD@imac-en0.delong.sj.ca.us> Message-ID: On Tue, 14 Feb 2006, Owen DeLong wrote: > While I still prefer the wording in 2005-1, I can also accept this > as a viable alternative. I think 1024 is, however, the largest > viable threshold. Any larger number of unique IPs required seems > arbitrary and capricious to me. > Glad you found it a acceptable alternititave. I think it will be good if we have some options available when it comes time to meet in Canada. The big things I like about my proposal vs. the current 2005-1 text. My text allows for large organizations a clear way to get more space then a very small site could get. This is the part I thought would have been totaly left up to ARIN staff to deal with if the current 2005-1 text should get aproved. To do this required not using the term 'end site', and defining what it would take to get more then a single /48 address block. The use of actual numbers of unique addresses, rather then refering to IPv4 policy... The numbers I used are the exact numbers that would be used today, if a organization was to apply for IPv4 space... I agree that these are basicly arbitrary but it seems the only alternititive would be to say 'anyone' who wants PI space can have it of they are willing to pay for it. I've re-worded the text I submited previously. None of the basic concepts were changed, however I belive this text is more clear on a few points... Perticularly with regard to single-site end-user subsequent requests for space. (6.5.8.3.a in this version). I know it's too late to submit a formal policy proposal at this point, but I would like it if this could at least be used as an alternative text/wording to the current offical 2005-1 text if we can not achive concensus on that offical policy proposal text. Here is a new 'grammaticality' improved version of my suggested text. Glenn Wiltse =-=-=-=-=-=-=-=-=--=-=-=-=-=-===-=-=-=-= (alternative to the current 2005-1 proposal) 6.5.8. Direct ARIN assignments to end-user organizations 6.5.8.1. To qualify for a direct ARIN assignment, a organization must: a) not be an IPv6 LIR/ISP; and b) have a need for at least 1024 unique addresses if they are multihomed, or 2048 if not multihomed. 6.5.8.2. initial assignment size to end-user organizations. a) If a qualifying organization has no plans to have more then one physical site, they shall be given a single /48. This will be referred to as a single-site end-user organization. b) Qualifying organizations with plans for more then one physical site, shall be assigned a minimum /44 address block. Sites with only one current physical site, must provide documentation of their plans to obtain additional sites. The standard size initial assignment shall be three times the number of sites they currently have or the minimum sized block, which ever is larger. If they desire more then the standard initial assignment, they must provide details about their plans to obtain additional sites that would justify a larger assignment. 6.5.8.3. Subsequent Assignments. a) Single-site end-user organizations will not be eligible for any additional assignments from ARIN unless organization has acquired or has plans to acquire additional physical sites. The organization would then be eligible for a initial assignment as a multi-site end-user organization. The organization would be required to return the /48 they had received as a single-site end-user within one year of obtaining space as a multi-site end-user. b) Requests for additional ARIN assigned space to a multi-site end-user organization must be accompanied by evidence that their internal use of /48s per site has exceeded the standard IPv6 HD ratio requirements. Upon such a documented request the multi-site end-user organization will immediately be eligible to obtain an additional assignment that results in doubling of the address space assigned to it. Where possible the assignment will from an adjacent address block, meaning that it's existing assignment is extended by one bit to the left. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-==--== From christopher.morrow at gmail.com Wed Feb 15 19:18:12 2006 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Thu, 16 Feb 2006 00:18:12 +0000 Subject: [ppml] Proposed Policy: Capturing Originations in Templates In-Reply-To: References: Message-ID: <75cb24520602151618w235cfe7fl1ed1e86efa45e49@mail.gmail.com> On 2/13/06, Michael.Dillon at btradianz.com wrote: > > Seems to me that there is not much carrot to encourage > up to date whois listings either. In any case, the carrot > here is that we need a 3rd party to collect and disseminate > information about which routes are correct if they appear > in BGP announcements. ARIN seems to be an ideal 3rd party no where in the policy does it say anything about BGP... where did you leap from to get to this? The policy is simply asking, in the end state, that block owners say: "hey, this might originate out of as 1, 2, 35, 9, 1239" This could be looked upon as a simple method to allow folks doing prefix-list building to verify that sprint has the block owners authority to originate said block. That was the intent atleast... Making a step toward validating that, in an off-line process not really related to BGP, someone who presents you with a block to which they want to announce reachability actually has the owner's permission to make that happen. Currently the process, absent IRR/RADB/RPSL, is left as an exercise to the reader to puzzle through. all discusson of RR usage or quality is moot, it's not relevant to this policy. -Chris From owen at delong.com Thu Feb 16 01:38:22 2006 From: owen at delong.com (Owen DeLong) Date: Wed, 15 Feb 2006 22:38:22 -0800 Subject: [ppml] New Alternative Text... was: version thought In-Reply-To: References: <005d01c63170$dfd90dc0$1d0200c1@FluffyBunny> <97E644DB6D2E5D9019BBC0DD@imac-en0.delong.sj.ca.us> Message-ID: > Glad you found it a acceptable alternititave. I think it will > be good if we have some options available when it comes time to > meet in Canada. > > The big things I like about my proposal vs. the current 2005-1 text. > > My text allows for large organizations a clear way to get more > space then a very small site could get. This is the part I thought > would have been totaly left up to ARIN staff to deal with if the > current 2005-1 text should get aproved. To do this required not > using the term 'end site', and defining what it would take to > get more then a single /48 address block. > I understand. I am actually OK with staff discretion on this, but, I can see both sides of that coin. > The use of actual numbers of unique addresses, rather then > referring to IPv4 policy... The numbers I used are the exact > numbers that would be used today, if a organization was to > apply for IPv4 space... I agree that these are basicly arbitrary > but it seems the only alternititive would be to say 'anyone' > who wants PI space can have it of they are willing to pay for > it. > Actually, they are not. Today, to qualify for a /22 in IPv4, you must show use of a /23 (510 unique addresses), so, technically, you have doubled the requirement (plus a little). > I've re-worded the text I submited previously. None of the > basic concepts were changed, however I belive this text is > more clear on a few points... Perticularly with regard to > single-site end-user subsequent requests for space. (6.5.8.3.a > in this version). > Well... To my reading, you've come a whole lot closer to what I consider acceptable requirements vs. my original interpretation of your use of the term large organizations. > I know it's too late to submit a formal policy proposal at this > point, but I would like it if this could at least be used as > an alternative text/wording to the current offical 2005-1 text > if we can not achive concensus on that offical policy proposal text. > I will here publicly state that I, personally am willing to have both alternatives presented together during the 2005-1 presentation. I don't know how Kevin feels about this, and, I don't know what rules, if any, may preclude it. However, I'd be happy to share the podium with you if that works for the AC/BOT and Kevin, my 2005-1 co-author. Owen -------------- 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 Thu Feb 16 02:57:39 2006 From: owen at delong.com (Owen DeLong) Date: Wed, 15 Feb 2006 23:57:39 -0800 Subject: [ppml] Proposed Policy: Capturing Originations in Templates In-Reply-To: <75cb24520602151618w235cfe7fl1ed1e86efa45e49@mail.gmail.com> References: <75cb24520602151618w235cfe7fl1ed1e86efa45e49@mail.gmail.com> Message-ID: <0F267DF4BB4483535572020B@odpwrbook.hq.netli.lan> > all discusson of RR usage or quality is moot, it's not relevant to this > policy. > Except in so far as RR usage is an existing more complete solution to exactly the problem set you claim to be attempting to solve. There is no need for this in whois and creating yet another repository for the same information is the opposite of a good thing. 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 Michael.Dillon at btradianz.com Thu Feb 16 06:35:18 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Thu, 16 Feb 2006 11:35:18 +0000 Subject: [ppml] Proposed Policy: Capturing Originations in Templates In-Reply-To: <75cb24520602151618w235cfe7fl1ed1e86efa45e49@mail.gmail.com> Message-ID: > Making a step toward validating that, in an off-line process not > really related to BGP, someone who presents you with a block to which > they want to announce reachability actually has the owner's permission > to make that happen. Currently the process, absent IRR/RADB/RPSL, is > left as an exercise to the reader to puzzle through. Whether it is done in the BGP code of your router or in an off-line process, is irrelevant. It is still a BGP issue. People want BGP filters to clean up BGP announcements based on the originating ASN in the BGP path. I agree that this is best implemented off-line in an OSS system and not on the router. I also believe that this should not be viewed as BUILDING BGP filters because in many networks it is wiser to use this information to VALIDATE or CROSS-CHECK filters that are built in another manner. > all discusson of RR usage or quality is moot, it's not relevant to > this policy. I think it is highly relevant because the policy proposal explicitly mentions RRs and the lack of authoritative information in them. This is a problem that ARIN can solve in their RR. It doesn't need to be solved in WHOIS. At the same time, there is nothing wrong with collecting this info on SWIP forms and then updating the RR database rather than the whois database. But since we are dealing with a fundamental RR issue, I think we should focus our efforts on solving it in the RR, not on munging the whois directory to be more RR-like. --Michael Dillon From sleibrand at internap.com Thu Feb 16 09:04:46 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Thu, 16 Feb 2006 09:04:46 -0500 (EST) Subject: [ppml] Proposed Policy: Capturing Originations in Templates In-Reply-To: References: Message-ID: On 02/16/06 at 11:35am -0000, Michael.Dillon at btradianz.com wrote: > I think it is highly relevant because the policy proposal > explicitly mentions RRs and the lack of authoritative information > in them. This is a problem that ARIN can solve in their RR. > It doesn't need to be solved in WHOIS. > > At the same time, there is nothing wrong with collecting > this info on SWIP forms and then updating the RR database > rather than the whois database. But since we are dealing > with a fundamental RR issue, I think we should focus our > efforts on solving it in the RR, not on munging the whois > directory to be more RR-like. So should we revise the proposed policy to have ARIN populate their RR with the data provided on the SWIP forms? I like the idea of using an existing form that people have to fill out anyway to collect information that people are often to lazy to provide otherwise. I also like the idea of presenting said information in several different formats so people can query whichever way is easiest for them. As others have alluded to, there is a real need for an easier way to get authoritative information on who is authorized to originate a block. This policy proposal isn't a panacea, but I think it's helpful, not harmful, in promising to make it easier for netblock owners to provide origination information for their netblocks. -Scott From iggy at merit.edu Thu Feb 16 10:24:46 2006 From: iggy at merit.edu (Glenn Wiltse) Date: Thu, 16 Feb 2006 10:24:46 -0500 (EST) Subject: [ppml] New Alternative Text... was: version thought In-Reply-To: References: <005d01c63170$dfd90dc0$1d0200c1@FluffyBunny> <97E644DB6D2E5D9019BBC0DD@imac-en0.delong.sj.ca.us> Message-ID: Current IPv4 plolicy says 25% imediate use, 50% within a year. I used the number needed within a year... I'm certianly willing to accept just about any number that would allow for consenus, what ever that would be... I just wanted to avoid the use of a pointer to IPv4 policy, so needed a number. That would be great if you could present both, perticularly of AC, BOT, and Kevin would all agree that was OK. Glenn Wiltse On Wed, 15 Feb 2006, Owen DeLong wrote: >> Glad you found it a acceptable alternititave. I think it will >> be good if we have some options available when it comes time to >> meet in Canada. >> >> The big things I like about my proposal vs. the current 2005-1 text. >> >> My text allows for large organizations a clear way to get more >> space then a very small site could get. This is the part I thought >> would have been totaly left up to ARIN staff to deal with if the >> current 2005-1 text should get aproved. To do this required not >> using the term 'end site', and defining what it would take to >> get more then a single /48 address block. >> > I understand. I am actually OK with staff discretion on this, but, > I can see both sides of that coin. > >> The use of actual numbers of unique addresses, rather then >> referring to IPv4 policy... The numbers I used are the exact >> numbers that would be used today, if a organization was to >> apply for IPv4 space... I agree that these are basicly arbitrary >> but it seems the only alternititive would be to say 'anyone' >> who wants PI space can have it of they are willing to pay for >> it. >> > Actually, they are not. Today, to qualify for a /22 in IPv4, > you must show use of a /23 (510 unique addresses), so, technically, > you have doubled the requirement (plus a little). > >> I've re-worded the text I submited previously. None of the >> basic concepts were changed, however I belive this text is >> more clear on a few points... Perticularly with regard to >> single-site end-user subsequent requests for space. (6.5.8.3.a >> in this version). >> > Well... To my reading, you've come a whole lot closer to what I > consider acceptable requirements vs. my original interpretation > of your use of the term large organizations. > >> I know it's too late to submit a formal policy proposal at this >> point, but I would like it if this could at least be used as >> an alternative text/wording to the current offical 2005-1 text >> if we can not achive concensus on that offical policy proposal text. >> > I will here publicly state that I, personally am willing to have both > alternatives presented together during the 2005-1 presentation. I don't > know how Kevin feels about this, and, I don't know what rules, if any, > may preclude it. However, I'd be happy to share the podium with you > if that works for the AC/BOT and Kevin, my 2005-1 co-author. > > Owen > From vaf at cisco.com Thu Feb 16 18:04:31 2006 From: vaf at cisco.com (Vince Fuller) Date: Thu, 16 Feb 2006 15:04:31 -0800 Subject: [ppml] Oxymorons (was: Geo PI) Message-ID: <20060216230431.GB17258@vaf-lnx1.cisco.com> Others who read NANOG suggested that two postings I recently made there are germaine to this discussion. These messages attempt to explain why "geo-topo addresses" and "provider- ndependent addresses" make no sense if the goal is a scalable Internet routing system built on the (flawed) ipv6 routing architecture (fatally flawed in the sense that it confuses the concept of transport identifier and routing locator into a single "address"). --Vince -------------------- From: Vince Fuller To: Fred Baker Cc: nanog at merit.edu Subject: Re: a radical proposal (Re: protocols that don't meet the need...) I'm sure I'm going to regret posting this, if for no other reason than that I will immediately start receiving more spam, and I suspect that I am just re-stating things that TLi and others have been trying to state both here and on PPML, but I guess I just can't resist today... [Disclaimer: I don't work for a provider these days; in fact, I work for the same vendor that Fred does, so it may seem odd that we are arguing... but I did work for university/regional/national/global ISPs from 1988 until 2001 and during this time did participate, to some degree, in the IETF process. I even tried to contribute to the IPNG process early on until it became clear that the political process that drove the selection of ipv6 had very little connection to operational reality. In case it isn't obvious, these views are mine alone and do not represent the position of my or your employer] > Interesting. This is what has been called metropolitan addressing. > I'm certainly not the one who first proposed it, although I have > thought about it for a while, dating at least as far back as 2001. ... > This turns the business model of routing on its head. Typically today > if Alice is using ISP AliceNet and Bob is using ISP BobNet, Alice > hands her packet to AliceNet, AliceNet gets it to BobNet in the > cheapest way it can, and BobNet carries it halfway around the world > to Bob. Bob's ISP carries the burden of most of the work. But in this > model, if AliceNet happens to also provide service in Bob's region, > AliceNet might carry the packet to the region and only give it to > BobNet for the last 500 feet. To address your points: > Whenever I have talked about the model with an ISP, I have gotten > blasted. Basically, I have been told that > > (1) any idea on operations proposed in the IETF is a bad idea because > the IETF doesn't listen to operators Would you disagree that the IPNG process essentially ignored the "hard" issues (multihoming, endpoint-id/routing locator split, easy/transparent renumbering, etc.) that were raised some 10 or more years ago? It may have been "operators" who were most vocal in raising these issues (since they are the ones who are suffering and will suffer the consequences of their not being addressed -- no pun intended) but there were some pretty smart people who didn't work for operators (e.g. JNC, TLi) who also argued for something better than "IP with bigger addresses" as being needed for IPNG. This certainly gave some credence to the idea that the IETF "doesn't listen to operators" or to the others calling for a re-examination of the routing architecture. Slight digression: I recall getting up during the plenary (at the time, I was very public-speaking-averse, so the memory is vivid) at the Amsterdam IETF (July, 1993) back when the whole "IP isn't going to scale; we need to build something better" sentiment was starting. I stated that any solution that didn't deal with transparent renumbering and multihoming was a non- tarter. There was lots of applause then and promises that these issues would definitely be covered. We still wound up with a non-functional ipv6. > (2) the ISPs aren't going to be willing to make settlement payments > among themselves in accordance with the plan > (3) routing isn't good enough to support it > (4) and in any event, this makes it too easy to change ISPs > > In short, "hell no". It's a little more basic than that. I'm no graph theory expert and reading such stuff gives me a headache, but I do understand that abstraction (summarization or aggregation) of routing information is only possible if the identifiers that are used for numbering network elements (the "addresses") are assigned in a manner that is isomporphic to the network topology. TLi started writing a good paper which described this in terms of sets and subsets; unfortunately, I don't think it ever saw the light of day). Those who propose "geo-topological" addressing, an oxymoron if ever there were one, are effectively dictating how the network topology is to be organized, with rather profound implications for provider business models. If addresses are assigned in this manner, then service providers whose networks span multiple address assignment domains (connect to more than one city or however the geograpic areas are split up) must: a) connect to all designated interconnection facilities associated with the address assignment authorities in the geographic areas they wish to serve and 1) carry all more-specific routes for all providers in all of the cities that they serve (which eliminates aggregation) or 2) provide free transit service for any customer of a competitor in a geographic area whose addresses are aggregated or 3) enter into a settlement agreement (which implies a regulatory regime unprecedented in the Internet business) with all other providers in geographic areas which they serve Is it any surprise that large service providers are fundamentally opposed to such a radical change in Internet business practices, one which effectively dictates how they have to build their networks, what interconnection facilities they must join, and how they must interact with competitors, either by offering free transit service or by negotiating settlement contracts? Until the IP "address" is replaced by an endpoint identifier and a routing locator, it will not be possible to design a scalable routing architecture. Years ago, some smart people (much smarter than me) tried to make it clear how vitally important this distinction was. But the IPNG political process ignored those people and the result was the undeployable mess that is ipv6. If you want the Internet to scale to millions of customer sites that have full flexibility to multihome with providers of their choice, the id/locator split is essential; it may be possible to acheive this and still use ipv6 packet formats but incompatible implementation changes to "address" handling semantics are needed at the transport and internetworking layer (think: 8+8/GSE and "agile transport identifier use"). --Vince -------------------- Date: Thu, 16 Feb 2006 14:37:47 -0800 From: Vince Fuller To: Michael.Dillon at btradianz.com Cc: nanog at merit.edu Subject: Re: a radical proposal (Re: protocols that don't meet the need...) Uh-oh, two postings to NANOG in as many days... hopefully, this will be my last. > [[pushed the wrong button last time. This is the complete reply]] Oh, the irony in that statement... this whole argument has certainly pushed "the wrong button" for me. > > > - join a local IXP, which may be a physical switch or > > virtualized by a set of bilateral agreements. > > Why should they join an IXP if they already have > private peering arrangements? > > > - outside the region, they advertise the prefix of the > > regional authority > > Mixing government with operations? If you favor doing > that then why not just give IPv6 addresses to the various > national governments and let the UN sort it out? > > Personally I disagree with any scheme which calls for > national or municipal governments to assign IPv6 addresses > to end users. Dressing it up as a "regional authority" > does not make it any nicer. > > Forcing people to join an unecessary IX is not the way > to solve the problem of regional aggregation of routes. > This is a purely technical problem which can be solved > by the RIR practices in allocating IPv6 addresses. If they > would allocate addresses in a geo-topological manner then > end users and ISPs would be free to aggregate routes > outside of their region without any involvement of governments > or any requirement to join consortia or IXes. It does > require the users of such geo-topological addresses to > ensure that in THEIR region, there is sufficient > interconnectivity (physical and policy) between ISPs for > the addressing to work. But that does not need to be determined > or managed centrally. > > Geo-topological addressing refers to RIRs reserving large > blocks of designated addresses for areas served my large > cities (over 100,000) population. When end users are located > in fringe areas roughly equidistant between two or more such > centers, the RIR simply asks the end user (or ISP) which is > the center to which they want to connect (communicate). > This addressing scheme operates in parallel with the existing > provider-oriented IPv6 addressing scheme but uses a different > block of IPv6 addresses out of the 7/8ths that are currently > reserved. No hardware or software changes are required for this > to work, merely some geographical/economical research to determine > the relative sizes of the address pool to be reserved for each > of the world's 5000 largest cities. The routing system doesn't particularly care whether your "geo-topo" addressing is imposed by governments, RIRs, or a beneveolent dictator; in all cases, the result is Soviet-style central planning to force the network topology to conform to your idea of what it "should" be rather than following the economic realities of the those who would build the network. A "geo-topo" addressing scheme works great for address assignment *within* a single AS and it even could have worked pretty well back in 1990, when there was a "core" NSFNET and a bunch of regional networks. But the key attribute of these scanerios is the existance of centralized control of the topology. There is no such control of the topology today; those who wish to impose such control are asking for a regulatory environment that would radically change the nature of the Internet. > > > Whenever I have talked about the model with an ISP, I have gotten > > blasted. Basically, I have been told that > > > > (1) any idea on operations proposed in the IETF is a bad idea because > > the IETF doesn't listen to operators > > This is true. Top-down does not work in Internet operations. > We need bottom-up, i.e. customer demand. The IETF needs to > view their role as enablers of customer demand. If the IETF > can create something that will work for ISP customers, then > ISPs will be happy to go along, once the customers demand > the service. Interesting to see an argument for bottom-up design in a post which otherwise calls for top-down planning of the network architecture. What the IETF, and more specifically the IAB, really needs to do is to acknowledge that there is a very real problem with the ipv6 routing architecture (which is identical to the IPv4 routing architecture), one that cannot be fixed without making incompatible changes to protocol implementation. Band-aids like shim6 just aren't going to cut it if the goal is to build a highly-scalable network of autonomous routing domains (in other worse, a really big network where end sites have very flexible choices of providers). The first step to finding a solution is to admit that there is a problem. > > (2) the ISPs aren't going to be willing to make settlement payments > > among themselves in accordance with the plan > > Wait until this starts appearing as a requirement in > custome RFPs. Then wait until governmental bodies step in to offer their help in the form of regulation. The two go hand-in-hand. If you want to re-invent the telco model of interconnection, this is a pretty big step in that direction. ... > > Note 2: Provider-provisioned addresses continue to make sense for > > folks that don't plan to multihome. > > Indeed they do. But the current IPv6 addressing model is completely > slanted towards provider-provisioned addresses for single-homed > entities. Calling a small block of these provider-provisioned > addresses PI (provider independent) does not really make the addresses > provider independent and does not help small enterprises to implement > meaningful multihoming. The IETF has imposed this provider-provisioned > model on IPv4 and is thus directly responsible for the ISP cartel > which now exists. Methinks we are re-interpreting history here. The IETF didn't create an "ISP cartel" for IPv4. What CIDR did, and I think I can speak with some degree of authority on this subject, was to allow routing state to scale in a non-exponential manner by encouraging address assignment to follow topology. Of course, the fact is that it is the providers which determine network topology because it is they who create it (this is something of a tautology). There are consequences of this, namely that provider changes imply renumbering, but this really isn't some grand scheme to lock customers in to providers; it is an unfortunate consequence of the combination of addressing following topology and a poor, late-1960's design decision to combine endpoint identification and routing locator into a single quantity known as an IP address. It is important to note that CIDR was explicitly specified as a short-term measure to prevent the explosion of routing state from causing the Internet to become unmanageable, which was the alternative to its adoption back in the early-to-mid-1990s. It was also explicitly intended to be replaced by a scalable, long-term solution which, unfortunately, has yet to be designed. If you don't believe me, go read the documents for yourself - they say exactly the same thing. In the interests of demonstrating why "geo-topo" addressing can't possibly work without radical changes to the business and regulatory models of the Internet, consider the simple example of a provider who has connections to two popular "geo-topo" addressing domains, say the Bay Area and the DC area. Let's say that 10.0.0.0/8 is the "geo-topo" address block in the Bay Area and 172.16.0.0/12 is the "geo-topo" block in the DC area. This provider has four customers in the Bay Area: 10.1.1.0/24 10.10.4.0/22 10.100.8.0/21 10.200.0.0/16 How is the provider supposed to make use of the 10.0.0.0/8 aggregate? Does he advertise it to other providers in the DC area or anywhere else where he offers service (Asia, Europe, etc.)? By doing so, he is stating that he can provide connectivity to all hosts which are numbered in that address range. But he only provides transit service to the address ranges associated with his customers. For him to provide connectivity to all the address range, he must a) have full routing connectivity to all other providers that have addresses in the same range; this implies that he connects to all IXs within the region and maintaines a full-mesh of routing information (today, BGP sessions) to all of these providers and b) must be willing to provide connectivity to all sites within the region to any place that he advertises the prefix 10.0.0.0/8 through routing exchanges; if he advertises this prefix to non-customers, it implies that he is will provide free transit to his competitors' customers which are numbered out of this block Both of these requirements defy business sense, so absent the imposition of strong regulation and negotiated settlements, they are unlikely to appeal to any provider which wishes to offer service to and between multiple cities; without such providers, you don't have a global Internet. I'm not sure how I can make this much more clear. It seems appropriate to re-state Dave's quote Yakov: "Addressing can follow topology or topology can follow addressing. Choose one." and I'd offer a corollary: Transit relationships (i.e money) must follow topological relationships (and thus addressing); the alternative is some combination of inefficient or non-scalable routing, black holes, settlements, regulation, or other undesireable things. If you really want to combine transport identifier and routing locator into a single "address", you give up a lot of flexibility. For routing to scale, addressing must follow topology, so in such a network architecture the term "topology independent address" (aka "provider independent address") is truly an oxymoron. --Vince From owen at delong.com Thu Feb 16 18:36:42 2006 From: owen at delong.com (Owen DeLong) Date: Thu, 16 Feb 2006 15:36:42 -0800 Subject: [ppml] Proposed Policy: Capturing Originations in Templates In-Reply-To: References: Message-ID: <60A1740A627D0C8D0FCFAA86@imac-en0.delong.sj.ca.us> The rub here is that the RR requires things specified in RPSL and allows much finer grained control of routing policy specification. However, perhaps we should look into generating a simplified process for creating RPSL to simply define valid origin ASs for a given prefix and make that available to registrants. Probably one of the significant hurdles to better use of the RRs is the difficulty of correctly coding things in RPSL. Owen -------------- 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 Thu Feb 16 18:41:11 2006 From: owen at delong.com (Owen DeLong) Date: Thu, 16 Feb 2006 15:41:11 -0800 Subject: [ppml] New Alternative Text... was: version thought In-Reply-To: References: <005d01c63170$dfd90dc0$1d0200c1@FluffyBunny> <97E644DB6D2E5D9019BBC0DD@imac-en0.delong.sj.ca.us> Message-ID: <9003950BF182BEB2D5DD1766@imac-en0.delong.sj.ca.us> --On February 16, 2006 10:24:46 AM -0500 Glenn Wiltse wrote: > > Current IPv4 plolicy says 25% imediate use, 50% within a year. I used > the number needed within a year... I'm certianly willing to accept just > about any number that would allow for consenus, what ever that would > be... I just wanted to avoid the use of a pointer to IPv4 policy, so > needed a number. > OK... My point was that 50% of a /22 (current IPv4 policy) is a 510 hosts. I can accept any number <=1024 as well, so, I think we're making good progress here. Perhaps we can do shows of hands to gauge consensus on this at the various levels. > That would be great if you could present both, perticularly > of AC, BOT, and Kevin would all agree that was OK. > Well... What I was really suggesting was splitting our time and Kevin and/or I would present the current 2005-1 and you could present yours for side-by-side comparison and consensus. I'm willing to do whatever works for the group in general. 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 william at elan.net Thu Feb 16 18:42:54 2006 From: william at elan.net (william(at)elan.net) Date: Thu, 16 Feb 2006 15:42:54 -0800 (PST) Subject: [ppml] Proposed Policy: Capturing Originations in Templates In-Reply-To: <60A1740A627D0C8D0FCFAA86@imac-en0.delong.sj.ca.us> References: <60A1740A627D0C8D0FCFAA86@imac-en0.delong.sj.ca.us> Message-ID: On Thu, 16 Feb 2006, Owen DeLong wrote: > Probably one of the significant hurdles to better use of the RRs is the > difficulty of correctly coding things in RPSL. Really? Please explain to me any difficulties you might have had in correctly coding this entry: [whois.radb.net] route: 192.159.10.0/24 descr: Owen Delong network origin: AS10565 mnt-by: MAINT-AS10565 changed: ipadmin at meer.net 20050706 source: RADB -- William Leibzon Elan Networks william at elan.net From woody at pch.net Thu Feb 16 18:40:17 2006 From: woody at pch.net (Bill Woodcock) Date: Thu, 16 Feb 2006 15:40:17 -0800 (PST) Subject: [ppml] Proposed Policy: Capturing Originations in Templates In-Reply-To: <60A1740A627D0C8D0FCFAA86@imac-en0.delong.sj.ca.us> References: <60A1740A627D0C8D0FCFAA86@imac-en0.delong.sj.ca.us> Message-ID: On Thu, 16 Feb 2006, Owen DeLong wrote: > Perhaps we should look into generating a simplified process for > creating RPSL to simply define valid origin ASs for a given prefix and > make that available to registrants. Yay! -Bill From woody at pch.net Thu Feb 16 18:41:47 2006 From: woody at pch.net (Bill Woodcock) Date: Thu, 16 Feb 2006 15:41:47 -0800 (PST) Subject: [ppml] Proposed Policy: Capturing Originations in Templates In-Reply-To: References: <60A1740A627D0C8D0FCFAA86@imac-en0.delong.sj.ca.us> Message-ID: On Thu, 16 Feb 2006, william(at)elan.net wrote: > Really? Please explain to me any difficulties you might have had in > correctly coding this entry: By definition, that wa the one that didn't have difficulties. The three _prior_ to that, which got bounced by the auto-responder, might have had difficulties, like the dozens from other people who gave up in frustration. Web forms are good, simplified formatting better. -Bill From william at elan.net Thu Feb 16 18:56:19 2006 From: william at elan.net (william(at)elan.net) Date: Thu, 16 Feb 2006 15:56:19 -0800 (PST) Subject: [ppml] Proposed Policy: Capturing Originations in Templates In-Reply-To: <60A1740A627D0C8D0FCFAA86@imac-en0.delong.sj.ca.us> References: <60A1740A627D0C8D0FCFAA86@imac-en0.delong.sj.ca.us> Message-ID: [On a less sarcastic note...] On Thu, 16 Feb 2006, Owen DeLong wrote: > The rub here is that the RR requires things specified in RPSL and allows > much finer grained control of routing policy specification. You do not need to use those controls if you do not have to. The simple things like what ASN is going to announce that ipblock is very easy to both enter and understand. The issue is that RRs at least in North America are run separate from registrars and there is no way to be certain that whoever entered something in RR is authorized to have done it. > However, perhaps we should look into generating a simplified process for > creating RPSL to simply define valid origin ASs for a given prefix and > make that available to registrants. The process is available to registrants. Most of us don't use it unless we begin to do peering on such a scale where it matters. What RPSL needs to see wider use is marketing toward both the ISPs that can use it for filtering and ASN holders. Another issue is also that RRs get to be out of date where as whois is slightly better maintained. Both of those are primarily due to human factors. > Probably one of the significant hurdles to better use of the RRs is the > difficulty of correctly coding things in RPSL. RPSL is no more difficult then SWIP templates are. And there are mote tools available for it. -- William Leibzon Elan Networks william at elan.net From owen at delong.com Thu Feb 16 19:02:38 2006 From: owen at delong.com (Owen DeLong) Date: Thu, 16 Feb 2006 16:02:38 -0800 Subject: [ppml] Proposed Policy: Capturing Originations in Templates In-Reply-To: References: <60A1740A627D0C8D0FCFAA86@imac-en0.delong.sj.ca.us> Message-ID: <7D7A90C5DCAA1554B77CC91A@imac-en0.delong.sj.ca.us> --On February 16, 2006 3:42:54 PM -0800 "william(at)elan.net" wrote: > > On Thu, 16 Feb 2006, Owen DeLong wrote: > >> Probably one of the significant hurdles to better use of the RRs is the >> difficulty of correctly coding things in RPSL. > > Really? Please explain to me any difficulties you might have had in > correctly coding this entry: > > [whois.radb.net] > route: 192.159.10.0/24 > descr: Owen Delong network > origin: AS10565 > mnt-by: MAINT-AS10565 > changed: ipadmin at meer.net 20050706 > source: RADB 1. I didn't code this entry, so, I didn't have any difficulty at all. You'll notice it is maintained by one of my ISPs, not by me. 2. I'm not sure what your point is, but, my particular situation, a single entry with no policy information whatsoever is, I suspect an exception rather than a rule. 3. It might interest you to know that the single AS shown in that entry is not necessarily a complete reflection of my connectivity, although that is the only one currently advertised in BGP. In general, coding things up to get them through the RPSL parser and into the database has, in my experience, been a frustrating exercise in trial and error with rather esoteric response back from the parser and a lot of time spent hunting for subtle syntax errors. 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 Thu Feb 16 19:12:40 2006 From: owen at delong.com (Owen DeLong) Date: Thu, 16 Feb 2006 16:12:40 -0800 Subject: [ppml] Proposed Policy: Capturing Originations in Templates In-Reply-To: References: <60A1740A627D0C8D0FCFAA86@imac-en0.delong.sj.ca.us> Message-ID: <01BF55B637F25B87C727AE78@imac-en0.delong.sj.ca.us> --On February 16, 2006 3:56:19 PM -0800 "william(at)elan.net" wrote: > > [On a less sarcastic note...] > > On Thu, 16 Feb 2006, Owen DeLong wrote: > >> The rub here is that the RR requires things specified in RPSL and allows >> much finer grained control of routing policy specification. > > You do not need to use those controls if you do not have to. The simple > things like what ASN is going to announce that ipblock is very easy to > both enter and understand. > While that is true, it doesn't change the fact that RPSL is a finicky and esoteric syntax as a result of it's need to do those things. > The issue is that RRs at least in North America are run separate from > registrars and there is no way to be certain that whoever entered > something in RR is authorized to have done it. > This simply isn't true. Some of the RRs are run separate from registrars, but, there is an ARIN run RR run by ARIN which is the only registrar in North America. >> However, perhaps we should look into generating a simplified process for >> creating RPSL to simply define valid origin ASs for a given prefix and >> make that available to registrants. > > The process is available to registrants. Most of us don't use it unless > we begin to do peering on such a scale where it matters. > Really... Where is the simplified RPSL generator based on a web form or other process? As a registrant, I'd like to know. > What RPSL needs to see wider use is marketing toward both the ISPs that > can use it for filtering and ASN holders. Another issue is also that RRs > get to be out of date where as whois is slightly better maintained. Both > of those are primarily due to human factors. > All of those statements are assumptions. There are lots of ancient whois entries. RPSL suffers from a chicken and egg problem. The RPSL data available in the RRs is not sufficiently accurate for ISPs to reliably risk filtering on that basis. The data is not maintained because most people don't worry about maintaining data that doesn't have operational impact. >> Probably one of the significant hurdles to better use of the RRs is the >> difficulty of correctly coding things in RPSL. > > RPSL is no more difficult then SWIP templates are. And there are mote > tools available for it. > I disagree completely. I've never had trouble filling out a SWIP template and it's never taken me more than one try to get one accepted. I cannot even come close to this claim on an RPSL entry. In fact, it has usually taken me at least three attempts. 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 william at elan.net Thu Feb 16 19:20:22 2006 From: william at elan.net (william(at)elan.net) Date: Thu, 16 Feb 2006 16:20:22 -0800 (PST) Subject: [ppml] Proposed Policy: Capturing Originations in Templates In-Reply-To: <7D7A90C5DCAA1554B77CC91A@imac-en0.delong.sj.ca.us> References: <60A1740A627D0C8D0FCFAA86@imac-en0.delong.sj.ca.us> <7D7A90C5DCAA1554B77CC91A@imac-en0.delong.sj.ca.us> Message-ID: On Thu, 16 Feb 2006, Owen DeLong wrote: >>> Probably one of the significant hurdles to better use of the RRs is the >>> difficulty of correctly coding things in RPSL. >> >> Really? Please explain to me any difficulties you might have had in >> correctly coding this entry: >> >> [whois.radb.net] >> route: 192.159.10.0/24 >> descr: Owen Delong network >> origin: AS10565 >> mnt-by: MAINT-AS10565 >> changed: ipadmin at meer.net 20050706 >> source: RADB > > 1. I didn't code this entry, so, I didn't have any difficulty at all. > You'll notice it is maintained by one of my ISPs, not by me. > 2. I'm not sure what your point is, but, my particular situation, > a single entry with no policy information whatsoever is, I > suspect an exception rather than a rule. No its not an "exception". In fact it would be a lot more common then anything else with complex policies if all those who advertised their blocks actually did anything with RRs. But current use of RRs is primarily between peering transit ISPs with only few entries directly by those representing leaf-nodes (of global BGP). For transit ISPs the policies get to be more complex, but on the other hand the people who work at those ISPs are more adapt to those complexities and on what can be entered in RRs and how. > 3. It might interest you to know that the single AS shown in that > entry is not necessarily a complete reflection of my connectivity, > although that is the only one currently advertised in BGP. Well, then as far as I'm concerned it is then a complete reflection. > In general, coding things up to get them through the RPSL parser and > into the database has, in my experience, been a frustrating exercise > in trial and error with rather esoteric response back from the parser > and a lot of time spent hunting for subtle syntax errors. Have you had less difficulties with first time you submitted SWIP to ARIN or Internic? But your point about need for simple tool/template for just entering ASNs that will announce the block is understood and is valid. I suppose it can be one of the task for ARIN to create web tools to help in use of its RR database for newcomers - ARIN definitely has extra money for such development work. And obviously ARIN can also help in marketing and advertise its RR to all those who got new ASN and/or new direct allocation or assignment. I'm not sure any of this can be a policy issue but hopefully ARIN staff is listening and taking notes. -- William Leibzon Elan Networks william at elan.net From sandy at tislabs.com Thu Feb 16 20:40:47 2006 From: sandy at tislabs.com (sandy at tislabs.com) Date: Thu, 16 Feb 2006 20:40:47 -0500 (EST) Subject: [ppml] Proposed Policy: Capturing Originations in Templates Message-ID: <200602170140.k1H1eloM010376@tislabs.com> >> The issue is that RRs at least in North America are run separate from >> registrars and there is no way to be certain that whoever entered >> something in RR is authorized to have done it. >> >This simply isn't true. Some of the RRs are run separate from >registrars, but, there is an ARIN run RR run by ARIN which is the >only registrar in North America. ARIN does indeed run an RR. If you look at www.irr.net you will see that there are many other RR's in North America, including the very widely known RADB. And Verio. And SAVVIS. Coincidentally, I mentioned the authentication problem for route objects stored in RRs in a presentation in the Lighning talks at NANOG yesterday. RIR run IRRs have internal access to their authentication mechanism for the prefix holders and can authenticate the route object as being from the authorized holder. Note: the ARIN site says that they will check the email address from the sumbitted RR object against the POC in the template for the associated address block. OK, so that's a weak authentication, but at least the hook is there for a check. However, I'm told by an informed source that this is done for inetnum and aut-num but not for the route objects. Non-RIR run IRRs would have to find a way to get that authentication check from the RIR or get it done by the RIR. When the authentication check is MAIL-FROM, anyone can do the check. But... it's MAIL-FROM ;-{ (I understand that RADB does no checking, anyway.) RIR run IRRs are in the same position if they are allowing registration of objects associated with non-member resources. They wouldn't be able to do the authorization/authentication checking themselves; they would have to rely on the remote RIR for that resource. --Sandy P.S. There is an RFC (2725) that defines a security model for who should be allowed to register types of RR objects. For route objects it say they should be registered by the person/org allocated the prefix. {Truth in Advertising: I am listed as an author. Truth in Reality: Curtis Villamizar *is* the author; I contributed little.} Actually, RFC2725 says a route object should be authenticated from both the prefix holder *and* the AS holder - and I think RIPE does this. But then RIPE holds both the allocation data and the registry data, so they can. From sandy at tislabs.com Thu Feb 16 20:41:58 2006 From: sandy at tislabs.com (sandy at tislabs.com) Date: Thu, 16 Feb 2006 20:41:58 -0500 (EST) Subject: [ppml] Proposed Policy: Capturing Originations in Templates Message-ID: <200602170141.k1H1fwKK010406@tislabs.com> >>> However, perhaps we should look into generating a simplified process for >>> creating RPSL to simply define valid origin ASs for a given prefix and >>> make that available to registrants. >> >> The process is available to registrants. Most of us don't use it unless >> we begin to do peering on such a scale where it matters. >> >Really... Where is the simplified RPSL generator based on a web form >or other process? As a registrant, I'd like to know. Richard Steenbergen talked about his IRR Power Tools at the NANOG on Tuesday. There and at the Tools BOF he mentioned that he would like to work on a web form to generate RPSL objects, just to address this ease of use problem. His presentation (but not the slides from the Tool BOF) are at: http://www.nanog.org/mtg-0602/pdf/steenbergen.pdf He points at the end to: http://www.irrweb.com But that seems to require a login. --Sandy From sandy at tislabs.com Thu Feb 16 20:54:21 2006 From: sandy at tislabs.com (sandy at tislabs.com) Date: Thu, 16 Feb 2006 20:54:21 -0500 (EST) Subject: [ppml] Proposed Policy: Capturing Originations in Templates Message-ID: <200602170154.k1H1sLf8010794@tislabs.com> >The issue is that RRs at least in North America are run separate from >registrars and there is no way to be certain that whoever entered >something in RR is authorized to have done it. And I forgot to mention the currency problem -- RIR run IRRs have another advantage in currency - they can be purged of registered objects when the associated resources are reclaimed or returned or transfered, etc. non-RIR IRRs and IRRs registering objects for non-member resources would have trouble staying current with that sort of info. Of course, RR objects have even bigger currency problems already. Why isn't there a sunshine law/ ttl/ timeout for RR objects, anyway? --Sandy From hannigan at renesys.com Fri Feb 17 01:25:15 2006 From: hannigan at renesys.com (Martin Hannigan) Date: Fri, 17 Feb 2006 01:25:15 -0500 Subject: [ppml] Proposed Policy: Capturing Originations in Templates In-Reply-To: <200602170141.k1H1fwKK010406@tislabs.com> References: <200602170141.k1H1fwKK010406@tislabs.com> Message-ID: <7.0.1.0.0.20060217011255.01aa63f8@renesys.com> At 08:41 PM 2/16/2006, sandy at tislabs.com wrote: > >>> However, perhaps we should look into generating a simplified process for > >>> creating RPSL to simply define valid origin ASs for a given prefix and > >>> make that available to registrants. > >> > >> The process is available to registrants. Most of us don't use it unless > >> we begin to do peering on such a scale where it matters. > >> > >Really... Where is the simplified RPSL generator based on a web form > >or other process? As a registrant, I'd like to know. > > > >Richard Steenbergen talked about his IRR Power Tools at the NANOG on >Tuesday. There and at the Tools BOF he mentioned that he would like >to work on a web form to generate RPSL objects, just to address this >ease of use problem. > >His presentation (but not the slides from the Tool BOF) are at: >http://www.nanog.org/mtg-0602/pdf/steenbergen.pdf > Do you have the support of any providers in North America? Without mandatory compliance, on initial registration and add/move/drop, I'm not sure this is worth our effort. (see above URL, page 4) -M< From hannigan at renesys.com Fri Feb 17 01:25:15 2006 From: hannigan at renesys.com (Martin Hannigan) Date: Fri, 17 Feb 2006 01:25:15 -0500 Subject: [ppml] Proposed Policy: Capturing Originations in Templates In-Reply-To: <200602170141.k1H1fwKK010406@tislabs.com> References: <200602170141.k1H1fwKK010406@tislabs.com> Message-ID: <7.0.1.0.0.20060217011255.01aa63f8@renesys.com> At 08:41 PM 2/16/2006, sandy at tislabs.com wrote: > >>> However, perhaps we should look into generating a simplified process for > >>> creating RPSL to simply define valid origin ASs for a given prefix and > >>> make that available to registrants. > >> > >> The process is available to registrants. Most of us don't use it unless > >> we begin to do peering on such a scale where it matters. > >> > >Really... Where is the simplified RPSL generator based on a web form > >or other process? As a registrant, I'd like to know. > > > >Richard Steenbergen talked about his IRR Power Tools at the NANOG on >Tuesday. There and at the Tools BOF he mentioned that he would like >to work on a web form to generate RPSL objects, just to address this >ease of use problem. > >His presentation (but not the slides from the Tool BOF) are at: >http://www.nanog.org/mtg-0602/pdf/steenbergen.pdf > Do you have the support of any providers in North America? Without mandatory compliance, on initial registration and add/move/drop, I'm not sure this is worth our effort. (see above URL, page 4) -M< From Michael.Dillon at btradianz.com Fri Feb 17 05:06:05 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Fri, 17 Feb 2006 10:06:05 +0000 Subject: [ppml] Proposed Policy: Capturing Originations in Templates In-Reply-To: <60A1740A627D0C8D0FCFAA86@imac-en0.delong.sj.ca.us> Message-ID: > However, perhaps we should look into generating a simplified process for > creating RPSL to simply define valid origin ASs for a given prefix and > make that available to registrants. Web pages perhaps? If we can put whois queries on a web page, why can't we put SWIP submissions there too? --Michael Dillon From owen at delong.com Fri Feb 17 07:28:40 2006 From: owen at delong.com (Owen DeLong) Date: Fri, 17 Feb 2006 04:28:40 -0800 Subject: [ppml] Proposed Policy: Capturing Originations in Templates In-Reply-To: References: <60A1740A627D0C8D0FCFAA86@imac-en0.delong.sj.ca.us> <7D7A90C5DCAA1554B77CC91A@imac-en0.delong.sj.ca.us> Message-ID: [snip] > Have you had less difficulties with first time you submitted SWIP to > ARIN or Internic? > Yes... As I've stated before, I've never had a SWIP rejected. > But your point about need for simple tool/template for just entering > ASNs that will announce the block is understood and is valid. I suppose > it can be one of the task for ARIN to create web tools to help in use > of its RR database for newcomers - ARIN definitely has extra money for > such development work. And obviously ARIN can also help in marketing > and advertise its RR to all those who got new ASN and/or new direct > allocation or assignment. I'm not sure any of this can be a policy > issue but hopefully ARIN staff is listening and taking notes. > Exactly. And, my point was that rather than adopting this policy, effort would be better spent if it were focused in these areas. I'm glad we've come to agreement. 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 iggy at merit.edu Fri Feb 17 07:38:09 2006 From: iggy at merit.edu (Glenn Wiltse) Date: Fri, 17 Feb 2006 07:38:09 -0500 (EST) Subject: [ppml] New Alternative Text... was: version thought In-Reply-To: <9003950BF182BEB2D5DD1766@imac-en0.delong.sj.ca.us> References: <005d01c63170$dfd90dc0$1d0200c1@FluffyBunny> <97E644DB6D2E5D9019BBC0DD@imac-en0.delong.sj.ca.us> <9003950BF182BEB2D5DD1766@imac-en0.delong.sj.ca.us> Message-ID: Your right... my mistake. My original intent was to use the 50% of /22, which is indeed 512. While I do feel 512 is a bit low I'd be willing to accept what ever number might have consensus. I'm not really very good at public speaking... so I'd rather not have to present... Perhaps someone could do it on my behalf. I could take a bit more time and write up some of my Rationale for my wording, which could help anyone who might be willing to volenteer to present my text and/or rationale for it.. I too just want what is good for the group, although getting up in front of the PP meeting is a bit out of my comfort range. Glenn Wiltse On Thu, 16 Feb 2006, Owen DeLong wrote: > > > --On February 16, 2006 10:24:46 AM -0500 Glenn Wiltse > wrote: > >> >> Current IPv4 plolicy says 25% imediate use, 50% within a year. I used >> the number needed within a year... I'm certianly willing to accept just >> about any number that would allow for consenus, what ever that would >> be... I just wanted to avoid the use of a pointer to IPv4 policy, so >> needed a number. >> > OK... My point was that 50% of a /22 (current IPv4 policy) is a 510 hosts. > I can accept any number <=1024 as well, so, I think we're making good > progress here. Perhaps we can do shows of hands to gauge consensus on > this at the various levels. > >> That would be great if you could present both, perticularly >> of AC, BOT, and Kevin would all agree that was OK. >> > Well... What I was really suggesting was splitting our time and Kevin > and/or I would present the current 2005-1 and you could present yours > for side-by-side comparison and consensus. I'm willing to do whatever > works for the group in general. > > Owen > > > -- > If it wasn't crypto-signed, it probably didn't come from me. > From memsvcs at arin.net Fri Feb 17 14:31:06 2006 From: memsvcs at arin.net (Member Services) Date: Fri, 17 Feb 2006 14:31:06 -0500 Subject: [ppml] Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure Message-ID: <43F6247A.8040406@arin.net> On February 16, 2006, the ARIN Advisory Council concluded its review of 'Micro-allocations for Internal Infrastructure' and accepted it as a formal policy proposal for discussion by the community. This proposal is designated Policy Proposal 2006-2: Micro-allocations for Internal infrastructure. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/2006_2.html All persons in the community are encouraged to discuss Policy Proposal 2006-2 in the weeks leading to the ARIN Public Policy Meeting in Montreal scheduled for April 10-11, 2006. Both the discussion on the Public Policy Mailing List and at the Public Policy Meeting will be used to determine the community consensus regarding this policy proposal. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html ARIN's Policy Proposal Archive can be found at: http://www.arin.net/policy/proposals/proposal_archive.html Regards, Member Services American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure Author: Jason Schiller, Chris Morrow, Heather Skanks, Greg Stilwell, Beth Vu Proposal type: modify Policy term: permanent Policy statement: To replace section 6.10 6.10 Micro-allocation ARIN will make micro-allocations for critical infrastructure, and the RIRs and IANA as defined in the sub-sections below. These allocations will be no longer (more specific) than a IPv6 /48. Multiple allocations may be granted in certain situations. Micro-allocations MUST be provided from a specific range of addresses. ARIN will make a list of these blocks publicly available. ISPs and other organizations receiving these micro-allocations will be charged under the ISP fee schedule, while end-users will be charged under the fee schedule for end-users. This policy does not preclude organizations from requesting address space under other policies. 6.10.1 Micro-allocation for public exchange points Public Internet exchange point operators must provide justification for the micro-allocation, including: connection policy, location, other participants (minimum of two total), ASN, and contact information. Exchange point allocations MUST be allocated from specific blocks reserved only for this purpose. 6.10.2 Micro-allocation for core DNS service providers Core DNS service providers (e.g. ICANN-sanctioned root, gTLD, and ccTLD operators) must provide justification for the micro-allocation, including: name of core DNS server, location, ASN, and contact information. Core DNS server allocations MUST be allocated from the micro-allocation block. This block must be separate from the exchange point micro-allocation block and the internal infrastructure micro-allocation block. 6.10.3 Micro-allocation for internal infrastructure Organizations that currently hold IPv6 allocations may apply for a micro-allocation for internal infrastructure. Applicant must provide justification indicating why a separate non-routed block is required. Justification must include why a sub-allocation of currently held IP space cannot be utilized. Internal infrastructure allocations MUST NOT be routed on global Internet. Internal infrastructure allocations MUST be allocated from specific blocks reserved only for this purpose. Rationale: Organizations that have only a single aggregate may require additional noncontiguous IP space for their internal infrastructure. This space should not be routed in the global Internet routing table. This will provide for the protection of internal infrastructure and support for applications that are sensitive to long convergence times like VoIP. It is important to note that the additional prefix allocation will not negatively impact the global routing table size as the additional prefix should not be routed. BGP Re-Convergence ------------------ ISPs use BGP to originate their aggregate from multiple nodes within their infrastructure. They do this by routing their aggregate to discard on multiple devices. This ensures the Internet can reach the aggregate even when one or more nodes fail. If the next hop for a route is reachable via an aggregate that is in the routing table, then failures affecting the reachability of the next hop are subject to BGP hold timers, which can cause traffic to be dropped for the length of the bgp hold time (typically 3 minutes) The BGP re-convergence problem results when a multi-homed customer is announcing the same route to two different edge routers. When the edge router sourcing the primary path fails, the local address which is acting as the next hop, is removed from the IGP. If the next hop is still reachable through an aggregate or covering route, then the route will not be immediately invalidated in bgp. Until the bgp session with the failed device times out, traffic will be drawn to the device originating the aggregate, which is routed to discard and traffic will be dropped. After the bgp session with the failed device times out, the route will be removed and the next best route will be used. To minimize route failover time, you must ensure that the local addresses of the infrastructure, that act as next-hops for Internet routes, are NOT numbered with addresses that are a more specific than the aggregate. A detailed description of the problem space follows in the next three paragraphs. Having BGP next-hops that are not aggregated can cause faster convergence for customers who have multiple links to multiple routers of a single upstream AS. Take the case where a customer has two connections, link1 to edge-router1 and link2 to edge-router2, to a single upstream AS. The customer has an eBGP session with the loopback 2001:DB8::1/128 on edge-router1 and with loopback 2001:DB8::2/128 on edge-router2. The customer advertises a single prefix 2001:DB8:1000::/48 to both edge-router1 and edge-router2. The edge routers set next-hop self. The upstream ISP will have two paths to the prefix 2001:DB8:1000::/48, one with a protocol next-hop of 2001:DB8::1 and one with a protocol next-hop of 2001:DB8::2. Assume the upstream ISP's entire network prefers the path to 2001:DB8:1000::/48 with a protocol next-hop of 2001:DB8::1 due to lower BGP MED value. Also assume that all of the address space owned by the upstream ISP is 2001:DB8::/32, and the loopbacks of both edge routers are a more specific of the aggregate /32. The upstream ISP has a pull-up route for 2001:DB8::/32 in the core of the network. This allows for the aggregation of all the more specific routes of 2001:DB8::/32. It insures the stability of the 2001:DB8::/32 announcement, while preventing an isolated edge router from advertising reachability to the network. If edge-router1 fails then 2001:DB8::1/128 will be immediately removed from the IGP. The preferred prefix for 2001:DB8:1000::/48 with a next-hop of 2001:DB8::1 will remain a valid bgp route and will continue to be the best path because 2001:DB8::1 is reachable through the pull-up route 2001:DB8::/32. Traffic will get blackholed for up to three minutes (BGP default hold time) until the BGP prefix 2001:DB8:1000::/48 with a protocol next-hop of 2001:DB8::1 times out. Only then will traffic get forwarded to the next best path for 2001:DB8:1000::/48 with a protocol next-hop of 2001:DB8::2. If instead the loopbacks of the edge routers (or any BGP protocol next-hop addresses) are not part of the 2001:DB8::/32 aggregate, and there is no aggregate that covers the edge router loopbacks, then convergence will be much quicker. Assume that edge-router1 is using 2001:408::1 and edge-router2 is using 2001:408::2, and the only pull-up route is 2001:DB8::/32. In this case once edge-router1 fails, the IGP will detect it and remove 2001:408::1/128 from the IGP. This will invalidate the preferred path to 201:DB8:1000::/48 with a protocol next-hop of 2001:408:1 as there will be no route to the next hop (or even a less specific of this address). Once the path is invalidated, then the next best path to 2001:DB8:1000::/48 with a protocol next-hop of 2001:408::2 will be declared best. Convergence times will be on the order of magnitude of the IGP failure detection and path re-calculation, typically less than one second. --------------- | Core Router |static route | |2001:DB8::/32 discard ----+------+--- | | / \ /-------------/ \--------\ / \ / /----------------------------\ \ | | | | ------+---+-- --+---+------ |Core Router|static route |Core Router|static route | |2001:DB8::/32 discard | |2001:DB8::/32 discard ---------+--- ---------+--- | | ---------+--------- ---------+--------- | edge-router1 | | edge-router2 | | 2001:DB8::1/128 | | 2001:DB8::2/128 | ---------+--------- ---------+--------- | | \ link1 link2 / \------------\ /----------/ \ / | | ----+---------+---- | CPE | | | ---------+--------- | LAN 2001:DB8:1000::/48 Internal Infrastructure Security Considerations ----------------------------------------------- Internal infrastructure could be numbered out of space that is not routed or reachable by the public Internet. This could be used to secure internal only services in a multi-layered approach by filtering direct network connections in the forwarding plane, and not routing the network in the global Internet routing table. Internal services which could take advantage of these layers of protection include: SNMP services, iBGP mesh, Out-of-Band management network(s), remote access to the network devices that make up the network in question. A layered security approach will help to prevent breaches in security via singular config management problems. Additionally, having all of the services out of an aggregate block will simplify the configuration management situation. In essence, this allows for a two tier approach of protecting infrastructure, both in the control plane by not routing the network, and in the forwarding plane by utilizing packet filters which are easily constructed and managed due to the uniqueness of the internal infrastructure block. Private Address Considerations ------------------------------ Private addresses are not appropriate for a number of reasons. A public Internet network using private addresses internally may create confusion if trace routes contain private addresses. Additional problems may result due to wide spread filtering of private address space. ICMP messages may get dropped due to such a policy. This can lead to perceived odd behavior and make troubleshooting difficult. Additionally, the consequences of accidentally routing private ip space that is not globally unique, are potentially worse than if you accidentally announced globally unique space. DNS for private address space is today provided by blackhole-1.iana.org. and blackhole-2.iana.org. A provider who wants to maintain forward and reverse DNS sanity has to hijack those ip addresses to provide consistent DNS resolution. This will cause any users who's traffic transits that provider's network to also get 'inconsistent' answers with respect to the private address space in question. For management and troubleshooting purposes, it is important that infrastructure which provides Internet route reachability be numbered with addresses that resolve through DNS. Also, global uniqueness of addressing is important in minimizing renumbering efforts as organizations (and their networks) merge. RFC 4193 provides for neither of these needs. Timetable for implementation: Immediate From memsvcs at arin.net Fri Feb 17 14:32:21 2006 From: memsvcs at arin.net (Member Services) Date: Fri, 17 Feb 2006 14:32:21 -0500 Subject: [ppml] Policy Proposal 2006-3: Capturing Originations in Templates Message-ID: <43F624C5.30300@arin.net> On February 16, 2006, the ARIN Advisory Council concluded its review of 'Capturing Originations in Templates' and accepted it as a formal policy proposal for discussion by the community. This proposal is designated Policy Proposal 2006-3: Capturing Originations in Templates. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/2006_3.html All persons in the community are encouraged to discuss Policy Proposal 2006-3 in the weeks leading to the ARIN Public Policy Meeting in Montreal scheduled for April 10-11, 2006. Both the discussion on the Public Policy Mailing List and at the Public Policy Meeting will be used to determine the community consensus regarding this policy proposal. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html ARIN's Policy Proposal Archive can be found at: http://www.arin.net/policy/proposals/proposal_archive.html Regards, Member Services American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal 2006-3: Capturing Originations in Templates Author: Sandra Murphy Proposal type: new Policy term: permanent Policy statement: ARIN will collect an optional field in all IPv4 and IPv6 address block transactions (allocation and assignment requests, reallocation and reassignment actions, transfer and experimental requests). This additional field will be used to record a list of the ASes that the user permits to originate address prefixes within the address block. ARIN will produce a collection of the mappings from address blocks to ASes permitted to originate that address block, The collection will consist of a list where each entry will consist, at a minimum, of an address block, a list of AS numbers, and a tag indicating the type of delegation of the address block. This collection will be produced at least daily. ARIN will make the collected mappings from address blocks to AS numbers available for bulk transfer in one or more formats chosen at its own discretion, informed by the community's current needs. This data will not be subject to any redistribution restrictions -- it may be republished or repackaged it any form. Should ARIN choose to use WHOIS bulk transfer as the bulk form of data access required by this paragraph, the address block to AS mappings will not be subject to any redistribution restrictions, but the remainder of the WHOIS data will remain subject to the terms of the then-current AUP regarding bulk access to WHOIS data. ARIN may also make the collected or individual mappings from address blocks to AS numbers available in other forms, possibly query services, chosen at its own discretion, informed by the community's current needs. ARIN may require agreement to an acceptable use policy for access to the data in these forms. Rationale: Origination of prefixes by ASes that have no authority for the origination is a recurring problem in the Internet routing system. A list of authorized prefix originations would be beneficial to operators in constructing routing filter lists to counter bogus originations, interacting with customers requesting routing of a prefix, and diagnosing routing problems. A list of authorized prefix originations is also the necessary first step for any known solution for securing the routing system. Prefix originations can be stored in routing registry RPSL route objects. However, the authority for addresses and for ASes belongs to the RIRs. There is presently no mechanism to translate ARIN's authority for number resources to an IRR. Furthermore, operators have been less than diligent in creating and maintaining route objects. Capturing the prefix origination authorization in number resource registrations with ARIN has two main goals: benefit from the scrutiny with which ARIN verifies initial requests and authenticates subsequent transactions, and inherit the operators' self-discipline in completing resource requests and transactions. As an additional benefit, this could take a step toward populating the IRR with data known to be accurate. The intended use of this data means that both query for individual entries and bulk access to a list of the collected entries, without restriction on redistribution, is required. This policy requires that the additional data be provided through the usual whois query service and some bulk access service that has no restrictions. It permits ARIN to provide the bulk access through the existing bulk whois service if the new additional data is not subject to the bulk whois AUP restrictions. The policy does not limit ARIN to providing only those two services (whois query and unrestricted bulk access); other additional services may be developed at ARIN's discretion. It is expected that entries in the list of collected entries will include at a minimum the present NetRange and NetType attributes, with a new attribute, perhaps named OriginatingASList, for the list of permitted originating ASes. This policy will presumably be incorporated into NRPM section 3.4. Timetable for implementation: Within sixty (60) days of approval. From memsvcs at arin.net Fri Feb 17 14:34:21 2006 From: memsvcs at arin.net (Member Services) Date: Fri, 17 Feb 2006 14:34:21 -0500 Subject: [ppml] Policy Proposal 2006-4: IPv6 Direct PI Assignments for End Sites Message-ID: <43F6253D.10700@arin.net> On February 16, 2006, the ARIN Advisory Council concluded its review of 'IPv6 Direct PI Assignments for End Sites' and accepted it as a formal policy proposal for discussion by the community. This proposal is designated Policy Proposal 2006-4: IPv6 Direct PI Assignments for End Sites. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/2006_4.html All persons in the community are encouraged to discuss Policy Proposal 2006-4 in the weeks leading to the ARIN Public Policy Meeting in Montreal scheduled for April 10-11, 2006. Both the discussion on the Public Policy Mailing List and at the Public Policy Meeting will be used to determine the community consensus regarding this policy proposal. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html ARIN's Policy Proposal Archive can be found at: http://www.arin.net/policy/proposals/proposal_archive.html Regards, Member Services American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal 2006-4: IPv6 Direct PI Assignments for End Sites Author: Andrew Dul Proposal type: new Policy term: permanent Policy statement: Add new subsection to the NRPM: 6.5.8. Direct assignments to end sites 6.5.8.1. To qualify for a direct end site assignment, an organization must meet all of the following criteria: 1. not be an LIR; 2. be an end site; 3. be currently multihomed using IPv4; 4. have a direct assignment from ARIN of at least a IPv4 /19 and can show the current utilization of 80% of an IPv4 /19 equivalent. 6.5.8.2. Direct assignment size to end sites Organizations that meet the direct end site assignment criteria are eligible to receive a direct assignment of /48 out of a reserved /44. Direct Assignments shall be allocated from a separate super-block to allow for LIRs to filter. 6.5.8.3. Subsequent direct assignments to end sites Organizations assignment size may be increased by 1 bit (to a maximum of /44) when they demonstrate the active usage of 50% of the assigned /64 subnets. Only one direct assignment may be made to an end site organization under Section 6.5.8. Organizations which can demonstrate active usage of more than 50% of /64 networks from a /44 assignment shall qualify for an additional allocation as an LIR. Rationale: This policy is proposed as an alternative to the existing 2005-1 policy proposal. This policy is intended to be more conservative that the existing proposed 2005-1 policy. While this policy does allow PI assignments to end-sites, it limits the scope to current IPv4 holders with direct assignments. A more conservative policy is desirable as the first IPv6 PI policy. Current ARIN policy does not permit an end-site from obtaining a Provider Independent IPv6 address block directly from ARIN. There is currently no viable IPv6 multihoming method available for these end-sites. Shim6 & other methods have been proposed as a possible method to meet multihoming requirements. Today, no implementation or alternatives exist to ?traditional? IPv4 multihoming which announces unique address space from an ASN. The largest end-sites (corporations & content providers) have the greatest to gain and/or lose by not having an available method to multihome. While IPv6 provides for stateless auto configuration for end hosts, no new methods for renumbering the infrastructure are available. The cost and complexity of renumbering these large organizations makes it essential to provide stable address resources which are not assigned from a LIR. The lack of an end-site assignment policy is currently preventing the real planning and deployment of IPv6 networks in these organizations. Other policy proposals (2005-1) addressing this issue have been presented at the ARIN 15 & 16 meetings. This policy proposal attempts to address the issues that were raised on the ppml mailing list and at the public policy meetings for 2005-1. Specifically, the main issue surrounding the creation of consensus on this policy appears to be the criteria for which end-sites should be able to obtain an endsite assignment. Concerns have been raised about the creation of a new IPv6 ?swamp? by having a policy that is too lenient. This issue is addressed in the policy by limiting the endsite assignments to current organizations with a modest IPv4 assignment. The assignment of IPv4 resources is orthogonal to the assignment of IPv6 addresses. However, the use of existing IPv4 assignments and ARIN membership are postulated as an appropriate regulator for the initial assignments under an IPv6 endsite policy. It is reasonable to consider changes to the membership and IPv4 assignment requirements in the future. This review should be conducted after the endsite assignment policy has been in place long enough to understand the demand for endsite IPv6 assignments and the development of IPv6 networks have matured. This policy proposal does not attempt to address the assignment needs for endsites which currently do not have IPv4 assignments. Timetable for implementation: within 90 days of approval by the BoT From memsvcs at arin.net Fri Feb 17 14:35:04 2006 From: memsvcs at arin.net (Member Services) Date: Fri, 17 Feb 2006 14:35:04 -0500 Subject: [ppml] Policy Proposal 2006-5: IPv4 Micro-allocations for anycast services (temporary) Message-ID: <43F62568.7090503@arin.net> On February 16, 2006, the ARIN Advisory Council concluded its review of 'IPv4 Micro-allocations for anycast services (temporary)' and accepted it as a formal policy proposal for discussion by the community. This proposal is designated Policy Proposal 2006-5: IPv4 Micro-allocations for anycast services (temporary). The proposal text is below and can be found at: http://www.arin.net/policy/proposals/2006_5.html All persons in the community are encouraged to discuss Policy Proposal 2006-5 in the weeks leading to the ARIN Public Policy Meeting in Montreal scheduled for April 10-11, 2006. Both the discussion on the Public Policy Mailing List and at the Public Policy Meeting will be used to determine the community consensus regarding this policy proposal. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html ARIN's Policy Proposal Archive can be found at: http://www.arin.net/policy/proposals/proposal_archive.html Regards, Member Services American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal 2006-5: IPv4 Micro-allocations for anycast services (temporary) Author: David Williamson Proposal type: new Policy term: temporary Policy statement: In the NRPM IPv4 section, renumber 4.4 to 4.4.1, and add: 4.4.2 Micro-allocations for anycast services - ARIN will make micro-allocations to organizations wishing to deploy anycast based services, provided they meet the following criteria: * All of the criteria normally required to receive IPv4 space, AND * The organization must have multiple (at least two) discrete multi-homed networks. * The organization must advertise directly allocated networks from each multi-homed site. Micro-allocations for anycast services will be no longer than a /24. These allocations will be made out of blocks reserved for micro-allocation purposes. ISPs and other organizations receiving these micro-allocations will be charged under the ISP fee schedule, while end-users will be charged under the fee schedule for end-users. This policy is experimental, and is limited to 16 allocations and two years from adoption. In addition, organizations may receive no more than one microallocation under this policy. Rationale: There are an increasing number of anycast-based applications being offered by service providers and other organizations. Indeed, many basic infrastructure services (like the DNS root servers) are already anycast based. (See RFC 1546 for an authoritative discussion of anycast services.) It's worth noting that IPv6 has anycast built into the protocol itself. This is a sign that there is significant community interest in anycast as a technology, and highlights the lack of IPv4 allocation policy for anycast. Deployment of new services is severely hampered by current IPv4 allocation policies. For organizations that do not have legacy IP space, justifying a /22 to serve a handful of addresses is effectively impossible. As many ISPs also filter routes longer than /22, it is impractical to use a longer mask for any netblock that is utilized for an anycast service. This situation is also generally unfavorable to younger organizations, while giving older organizations that do have a surplus of legacy space a competitive advantage. In light of this, some organizations may simply lie about their addressing needs in order to convince an RIR or LIR that a /22 is required, when a much smaller network would suffice. This is not a behavior that should be encouraged by policy. The obvious answer is that a micro-allocation scheme needs to be created to allow organizations deploying anycast services to acquire a network of more appropriate size. It is also clear that a micro-allocation policy that makes it easier for organizations to acquire small netblocks may lead to additional improper allocations to organizations that simply wish to acquire additional small blocks of space. This policy proposal attempts to address that by requiring more stringent requirements for such allocations. A previous policy proposal (2005-6) is similar to this proposal, but with a few significant changes. There was significant negative feedback to that policy based on a couple of key difficulties, which this proposal attempts to address. The primary difficulty is that an anycast network looks much like a normal multihomed network from the outside. This led to the consensus belief that the earlier policy proposal would be abused by organizations that wouldn't otherwise qualify for address space. This proposal further restricts allocations such that only organizations that are already demonstratably multihomed with direct allocations can possibly qualify. Such organizations will typically have little use for a small allocation unless they really intend to use it for a specific purpose. In addition, this policy is marked as experimental and has a sunset clause, which will definitively prevent widespread abuse. It is hoped that operational experience will show that this policy is not seeing abuse, and it can later be modified to be permanent. In the event that this policy is widely abused, the total damage is limited and will be fixed in a relatively short time span. Timetable for implementation: immediate From dlw+arin at tellme.com Fri Feb 17 15:14:21 2006 From: dlw+arin at tellme.com (David Williamson) Date: Fri, 17 Feb 2006 12:14:21 -0800 Subject: [ppml] Proposed Policy: IPv4 Micro-allocations for anycast services (experimental) In-Reply-To: References: <43ECB1DF.4000006@arin.net> Message-ID: <20060217201421.GA20563@shell01.corp.tellme.com> Hey! Sorry for taking so long to reply. In my opinion, the possibility for abuse of the policy to acquire /24s for multihoming was the primary grounds for rejection. The length argument struck me as somewhat secondary. Still, it's an interesting argument. I did a bit of an experiment, and picked one of the three /24s I have free and announced it. While it's true that some providers seem to happily forward any /24 that falls into their routing table, there are definitely route-servers out there that aren't seeing that route. To be honest, I can't see why that route isn't appearing. It's clearly getting filtered, but that could be because it's a longer prefix out of a netblock that has shorter (i.e., /22) allocations. It could also be that someone picks up route policy from a routing database that we aren't presently in. That said, I'd love to hear feedback from folks at other major ISPs. Has *everyone* relaxed the /22 route filtering limit? The intent of this policy is to have blocks of an appropriate size for the application handed out in a way that will ensure global reachability. If *any* of the top volume ISPs do filter based on RIR policy guidelines (and several have historically), then longer prefixes from 'normal' blocks won't really suffice. That desire for global reachability is the one of the primary motivations for this policy. -David On Fri, Feb 10, 2006 at 02:21:20PM -0500, Scott Leibrand wrote: > David, > > A very similar policy was rejected at the last ARIN meeting in L.A. on > the grounds that a subnet of an existing network is adequate for running > anycast. Can you clarify why this policy is required, in light of that > consensus? I think there is significant disagreement in the community > with your statement that "many ISPs also filter routes longer than /22, > [so] it is impractical to use a longer mask for any netblock that is > utilized for an anycast service." Do you have concrete examples to back > up this statement? > > Thanks, > Scott > > On 02/10/06 at 10:31am -0500, Member Services wrote: > > > ARIN received the following proposed policy. In accordance with the ARIN > > Internet Resource Policy Evaluation Process, the proposal is being > > posted to the ARIN Public Policy Mailing List and being placed on ARIN's > > website. > > > > The ARIN Advisory Council (AC) will review the proposal and within ten > > working days may decide to: > > 1) Support the proposal as is, > > 2) Work with the author to clarify, divide or combine one or more > > policy proposals, or > > 3) Not support the policy proposal. > > > > If the AC supports the proposal or reaches an agreement to work with the > > author, then the proposal will be posted as a formal policy proposal to > > the Public Policy Mailing List and it will be presented at the Public > > Policy Meeting. If the AC does not support the proposal, then the author > > may elect to use the petition process to advance the proposal. If the > > author elects not to petition or the petition fails, then the proposed > > policy 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: IPv4 Micro-allocations for anycast services > > (experimental) > > > > Author: David Williamson > > > > Proposal type: new > > > > Policy term: temporary > > > > Policy statement: > > > > In the NRPM IPv4 section, renumber 4.4 to 4.4.1, and add: > > > > 4.4.2 Micro-allocations for anycast services - ARIN will make > > micro-allocations to organizations wishing to deploy anycast based > > services, provided they meet the following criteria: > > > > * All of the criteria normally required to receive IPv4 space, AND > > * The organization must have multiple (at least two) discrete > > multi-homed networks. > > * The organization must advertise directly allocated networks from > > each multi-homed site. > > > > Micro-allocations for anycast services will be no longer than a /24. > > These allocations will be made out of blocks reserved for > > micro-allocation purposes. ISPs and other organizations receiving these > > micro-allocations will be charged under the ISP fee schedule, while > > end-users will be charged under the fee schedule for end-users. > > > > This policy is experimental, and is limited to 16 allocations and two > > years from adoption. In addition, organizations may receive no more > > than one microallocation under this policy. > > > > Rationale: > > > > There are an increasing number of anycast-based applications being > > offered by service providers and other organizations. Indeed, many > > basic infrastructure services (like the DNS root servers) are already > > anycast based. (See RFC 1546 for an authoritative discussion of anycast > > services.) > > > > It's worth noting that IPv6 has anycast built into the protocol itself. > > This is a sign that there is significant community interest in anycast > > as a technology, and highlights the lack of IPv4 allocation policy for > > anycast. > > > > Deployment of new services is severely hampered by current IPv4 > > allocation policies. For organizations that do not have legacy IP > > space, justifying a /22 to serve a handful of addresses is effectively > > impossible. As many ISPs also filter routes longer than /22, it is > > impractical to use a longer mask for any netblock that is utilized for > > an anycast service. This situation is also generally unfavorable to > > younger organizations, while giving older organizations that do have a > > surplus of legacy space a competitive advantage. > > > > In light of this, some organizations may simply lie about their > > addressing needs in order to convince an RIR or LIR that a /22 is > > required, when a much smaller network would suffice. This is not a > > behavior that should be encouraged by policy. > > > > The obvious answer is that a micro-allocation scheme needs to be created > > to allow organizations deploying anycast services to acquire a network > > of more appropriate size. > > > > It is also clear that a micro-allocation policy that makes it easier for > > organizations to acquire small netblocks may lead to additional improper > > allocations to organizations that simply wish to acquire additional > > small blocks of space. This policy proposal attempts to address that by > > requiring more stringent requirements for such allocations. > > > > A previous policy proposal (2005-6) is similar to this proposal, but > > with a few significant changes. There was signficant negative feedback > > to that policy based on a couple of key difficulties, which this > > proposal attempts to address. > > > > The primary difficulty is that an anycast network looks much like a > > normal multihomed network from the outside. This led to the consensus > > belief that the earlier policy proposal would be abused by organizations > > that wouldn't otherwise qualify for address space. This proposal futher > > restricts allocations such that only organizations that are already > > demonstratably multihomed with direct allocations can possibly qualify. > > Such organizations will typically have little use for a small > > allocation unless they really intend to use it for a specific purpose. > > > > In addition, this policy is marked as experimental and has a sunset > > clause, which will definitively prevent widespread abuse. It is hoped > > that operational experience will show that this policy is not seeing > > abuse, and it can later be modified to be permanent. In the event that > > this policy is widely abused, the total damage is limited and will be > > fixed in a relatively short time span. > > > > Timetable for implementation: immediate > > > > > > _______________________________________________ > > 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 From ppml at rsuc.gweep.net Fri Feb 17 18:29:03 2006 From: ppml at rsuc.gweep.net (Joe Provo) Date: Fri, 17 Feb 2006 18:29:03 -0500 Subject: [ppml] Proposed Policy: Capturing Originations in Templates In-Reply-To: References: <60A1740A627D0C8D0FCFAA86@imac-en0.delong.sj.ca.us> <7D7A90C5DCAA1554B77CC91A@imac-en0.delong.sj.ca.us> Message-ID: <20060217232903.GA27608@gweep.net> [take two - sent from wrong address yesterday] On Thu, Feb 16, 2006 at 04:20:22PM -0800, william(at)elan.net wrote: > On Thu, 16 Feb 2006, Owen DeLong wrote: [difficulty of 'coding' rpsl data] > > 2. I'm not sure what your point is, but, my particular situation, > > a single entry with no policy information whatsoever is, I > > suspect an exception rather than a rule. > > No its not an "exception". In fact it would be a lot more common then > anything else with complex policies if all those who advertised their > blocks actually did anything with RRs. But current use of RRs is primarily > between peering transit ISPs with only few entries directly by those > representing leaf-nodes (of global BGP). For transit ISPs the policies > get to be more complex, but on the other hand the people who work at > those ISPs are more adapt to those complexities and on what can be > entered in RRs and how. There are several ISPs (small and large) who will not propagate any unregistered prefixes. The cary team at 3561 demonstrated it was Not Hard to have webby provisioning as part of daily life back in ripe-181 days on/around the NSF transition. (Yes, I know they were up and running while NACRs were being processed, I just can't recall when 3561-customers had a pointy-clicky web form though I know if was prior to 96.) Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From memsvcs at arin.net Fri Feb 17 18:33:35 2006 From: memsvcs at arin.net (Member Services) Date: Fri, 17 Feb 2006 18:33:35 -0500 Subject: [ppml] NRPM version 2006.1 - New Policy Implementations Message-ID: <43F65D4F.3000205@arin.net> On February 12, 2006, the ARIN Board of Trustees, based on the recommendations of the Advisory Council and noting that the Internet Resource Policy Evaluation Process had been followed, adopted the policy proposals listed below. These policy proposals take effect today, February 17, 2006. * 2005-4: AfriNIC Recognition Policy * 2005-5: IPv6 HD ratio * 2005-7: Rationalize Multi-Homing Definition and Requirement Version 2006.1 of the ARIN Number Resource Policy Manual (NRPM) is effective today, February 17, 2006. This version supersedes all previous versions. See Appendix A of the NRPM for information regarding changes to the manual. The NRPM can be found at: http://www.arin.net/policy/nrpm.html Appendix A can be found at: http://www.arin.net/policy/nrpm_changelog.html Regards, Member Services American Registry for Internet Numbers (ARIN) From sleibrand at internap.com Sat Feb 18 11:13:25 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Sat, 18 Feb 2006 08:13:25 -0800 Subject: [ppml] Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure References: <43F6247A.8040406@arin.net> Message-ID: <008901c634aa$3c7a4ad0$9f00a8c0@LeibrandLaptop> Re-statement for the record (nothing new here): This seems like a reasonable IPv6 MicroAllocation policy. If we're going to replace the "/24 using IPv4 or a /48 using IPv6" language of section 6.10 with the text below, IMO we should also modify section 4.4 to remove the "/48 using IPv6" language and instead refer users to 6.10 for the IPv6 MicroAllocation policy. Aside from that quibble, I currently support the policy proposal as written. -Scott ----- Original Message ----- From: "Member Services" To: Sent: Friday, February 17, 2006 11:31 AM Subject: [ppml] Policy Proposal 2006-2: Micro-allocations for InternalInfrastructure > On February 16, 2006, the ARIN Advisory Council concluded its review of > 'Micro-allocations for Internal Infrastructure' and accepted it as a > formal policy proposal for discussion by the community. This proposal is > designated Policy Proposal 2006-2: Micro-allocations for Internal > infrastructure. The proposal text is below and can be found at: > > http://www.arin.net/policy/proposals/2006_2.html > > All persons in the community are encouraged to discuss Policy Proposal > 2006-2 in the weeks leading to the ARIN Public Policy Meeting in > Montreal scheduled for April 10-11, 2006. Both the discussion on the > Public Policy Mailing List and at the Public Policy Meeting will be used > to determine the community consensus regarding this policy proposal. > > The ARIN Internet Resource Policy Evaluation Process can be found at: > http://www.arin.net/policy/irpep.html > > ARIN's Policy Proposal Archive can be found at: > http://www.arin.net/policy/proposals/proposal_archive.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ### * ### > > > Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure > > Author: Jason Schiller, Chris Morrow, Heather Skanks, Greg Stilwell, Beth > Vu > > Proposal type: modify > > Policy term: permanent > > Policy statement: > > To replace section 6.10 > > 6.10 Micro-allocation > > ARIN will make micro-allocations for critical infrastructure, and the > RIRs and IANA as defined in the sub-sections below. These allocations > will be no longer (more specific) than a IPv6 /48. Multiple allocations > may be granted in certain situations. Micro-allocations MUST be provided > from a specific range of addresses. ARIN will make a list of these > blocks publicly available. ISPs and other organizations receiving these > micro-allocations will be charged under the ISP fee schedule, while > end-users will be charged under the fee schedule for end-users. This > policy does not preclude organizations from requesting address space > under other policies. > > 6.10.1 Micro-allocation for public exchange points Public Internet > exchange point operators must provide justification for the > micro-allocation, including: connection policy, location, other > participants (minimum of two total), ASN, and contact information. > > Exchange point allocations MUST be allocated from specific blocks > reserved only for this purpose. > > 6.10.2 Micro-allocation for core DNS service providers Core DNS service > providers (e.g. ICANN-sanctioned root, gTLD, and ccTLD operators) must > provide justification for the micro-allocation, including: name of core > DNS server, location, ASN, and contact information. > > Core DNS server allocations MUST be allocated from the micro-allocation > block. This block must be separate from the exchange point > micro-allocation block and the internal infrastructure micro-allocation > block. > > 6.10.3 Micro-allocation for internal infrastructure Organizations that > currently hold IPv6 allocations may apply for a micro-allocation for > internal infrastructure. Applicant must provide justification > indicating why a separate non-routed block is required. > Justification must include why a sub-allocation of currently held IP > space cannot be utilized. > > Internal infrastructure allocations MUST NOT be routed on global Internet. > > Internal infrastructure allocations MUST be allocated from specific > blocks reserved only for this purpose. > > Rationale: > > Organizations that have only a single aggregate may require > additional noncontiguous IP space for their internal infrastructure. > This space should not be routed in the global Internet routing table. > This will provide for the protection of internal infrastructure and > support for applications that are sensitive to long convergence times > like VoIP. > > It is important to note that the additional prefix allocation will not > negatively impact the global routing table size as the additional prefix > should not be routed. > > BGP Re-Convergence > ------------------ > > ISPs use BGP to originate their aggregate from multiple nodes within > their infrastructure. They do this by routing their aggregate to > discard on multiple devices. This ensures the Internet can reach the > aggregate even when one or more nodes fail. > > If the next hop for a route is reachable via an aggregate that is in the > routing table, then failures affecting the reachability of the next hop > are subject to BGP hold timers, which can cause traffic to be dropped > for the length of the bgp hold time > > (typically 3 minutes) > > The BGP re-convergence problem results when a multi-homed customer is > announcing the same route to two different edge routers. When the edge > router sourcing the primary path fails, the local address which is > acting as the next hop, is removed from the IGP. If the next hop is > still reachable through an aggregate or covering route, then the route > will not be immediately invalidated in bgp. Until the bgp session with > the failed device times out, traffic will be drawn to the device > originating the aggregate, which is routed to discard and traffic will > be dropped. After the bgp session with the failed device times out, the > route will be removed and the next best route will be used. To minimize > route failover time, you must ensure that the local addresses of the > infrastructure, that act as next-hops for Internet routes, are NOT > numbered with addresses that are a more specific than the aggregate. > > A detailed description of the problem space follows in the next three > paragraphs. > > Having BGP next-hops that are not aggregated can cause faster > convergence for customers who have multiple links to multiple routers of > a single upstream AS. > Take the case where a customer has two connections, link1 to > edge-router1 and link2 to edge-router2, to a single upstream AS. The > customer has an eBGP session with the loopback 2001:DB8::1/128 on > edge-router1 and with loopback 2001:DB8::2/128 on edge-router2. The > customer advertises a single prefix 2001:DB8:1000::/48 to both > edge-router1 and edge-router2. The edge routers set next-hop self. The > upstream ISP will have two paths to the prefix 2001:DB8:1000::/48, one > with a protocol next-hop of 2001:DB8::1 and one with a protocol next-hop > of 2001:DB8::2. Assume the upstream ISP's entire network prefers the > path to 2001:DB8:1000::/48 with a protocol next-hop of 2001:DB8::1 due > to lower BGP MED value. Also assume that all of the address space owned > by the upstream ISP is 2001:DB8::/32, and the loopbacks of both edge > routers are a more specific of the aggregate /32. The upstream ISP has > a pull-up route for 2001:DB8::/32 in the core of the network. This > allows for the aggregation of all the more specific routes of > 2001:DB8::/32. It insures the stability of the 2001:DB8::/32 > announcement, while preventing an isolated edge router from advertising > reachability to the network. > > If edge-router1 fails then 2001:DB8::1/128 will be immediately removed > from the IGP. The preferred prefix for 2001:DB8:1000::/48 with a > next-hop of 2001:DB8::1 will remain a valid bgp route and will continue > to be the best path because 2001:DB8::1 is reachable through the pull-up > route 2001:DB8::/32. Traffic will get blackholed for up to three > minutes (BGP default hold time) until the BGP prefix 2001:DB8:1000::/48 > with a protocol next-hop of 2001:DB8::1 times out. Only then will > traffic get forwarded to the next best path for 2001:DB8:1000::/48 with > a protocol next-hop of 2001:DB8::2. > > If instead the loopbacks of the edge routers (or any BGP protocol > next-hop addresses) are not part of the 2001:DB8::/32 aggregate, and > there is no aggregate that covers the edge router loopbacks, then > convergence will be much quicker. Assume that edge-router1 is using > 2001:408::1 and edge-router2 is using 2001:408::2, and the only pull-up > route is 2001:DB8::/32. In this case once edge-router1 fails, the IGP > will detect it and remove 2001:408::1/128 from the IGP. This will > invalidate the preferred path to 201:DB8:1000::/48 with a protocol > next-hop of 2001:408:1 as there will be no route to the next hop (or > even a less specific of this address). Once the path is invalidated, > then the next best path to 2001:DB8:1000::/48 with a protocol next-hop > of 2001:408::2 will be declared best. Convergence times will be on the > order of magnitude of the IGP failure detection and path re-calculation, > typically less than one second. > > > --------------- > | Core Router |static route > | |2001:DB8::/32 discard > ----+------+--- > | | > / \ > /-------------/ \--------\ > / \ > / /----------------------------\ \ > | | | | > ------+---+-- --+---+------ > |Core Router|static route |Core Router|static route > | |2001:DB8::/32 discard | |2001:DB8::/32 discard > ---------+--- ---------+--- > | | > ---------+--------- ---------+--------- > | edge-router1 | | edge-router2 | > | 2001:DB8::1/128 | | 2001:DB8::2/128 | > ---------+--------- ---------+--------- > | | > \ link1 link2 / > \------------\ /----------/ > \ / > | | > ----+---------+---- > | CPE | > | | > ---------+--------- > | > LAN 2001:DB8:1000::/48 > > > Internal Infrastructure Security Considerations > ----------------------------------------------- > > Internal infrastructure could be numbered out of space that is not > routed or reachable by the public Internet. This could be used to > secure internal only services in a multi-layered approach by filtering > direct network connections in the forwarding plane, and not routing the > network in the global Internet routing table. Internal services which > could take advantage of these layers of protection include: SNMP > services, iBGP mesh, Out-of-Band management network(s), remote access to > the network devices that make up the network in question. A layered > security approach will help to prevent breaches in security via singular > config management problems. Additionally, having all of the services out > of an aggregate block will simplify the configuration management > situation. > > In essence, this allows for a two tier approach of protecting > infrastructure, both in the control plane by not routing the network, > and in the forwarding plane by utilizing packet filters which are easily > constructed and managed due to the uniqueness of the internal > infrastructure block. > > Private Address Considerations > ------------------------------ > > Private addresses are not appropriate for a number of reasons. A public > Internet network using private addresses internally may create confusion > if trace routes contain private addresses. Additional problems may > result due to wide spread filtering of private address space. ICMP > messages may get dropped due to such a policy. This can lead to > perceived odd behavior and make troubleshooting difficult. > > Additionally, the consequences of accidentally routing private ip space > that is not globally unique, are potentially worse than if you > accidentally announced globally unique space. > > DNS for private address space is today provided by blackhole-1.iana.org. > and blackhole-2.iana.org. A provider who wants to maintain forward and > reverse DNS sanity has to hijack those ip addresses to provide > consistent DNS resolution. > This will cause any users who's traffic transits that provider's network > to also get 'inconsistent' answers with respect to the private address > space in question. > > For management and troubleshooting purposes, it is important that > infrastructure which provides Internet route reachability be numbered > with addresses that resolve through DNS. Also, global uniqueness of > addressing is important in minimizing renumbering efforts as > organizations (and their networks) merge. RFC 4193 provides for neither > of these needs. > > Timetable for implementation: Immediate > > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From sleibrand at internap.com Sat Feb 18 11:18:53 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Sat, 18 Feb 2006 08:18:53 -0800 Subject: [ppml] Policy Proposal 2006-3: Capturing Originations in Templates References: <43F624C5.30300@arin.net> Message-ID: <008a01c634aa$401ced00$9f00a8c0@LeibrandLaptop> I support this policy under the condition that ARIN takes the origin AS information provided and populates/updates the ARIN RR with that information (possibly in addition to making it available by whois or other means). My reading of the policy below indicates that use of the data to populate the ARIN RR would be an allowed use of the data (at the discretion of ARIN staff), but would not be required. While I would prefer that the policy specifically direct ARIN to populate the RR, I would also support the policy as written (unless ARIN interprets the policy to not allow them to update their RR with the data). -Scott ----- Original Message ----- From: "Member Services" To: Sent: Friday, February 17, 2006 11:32 AM Subject: [ppml] Policy Proposal 2006-3: Capturing Originations in Templates > On February 16, 2006, the ARIN Advisory Council concluded its review of > 'Capturing Originations in Templates' and accepted it as a formal policy > proposal for discussion by the community. This proposal is designated > Policy Proposal 2006-3: Capturing Originations in Templates. The > proposal text is below and can be found at: > > http://www.arin.net/policy/proposals/2006_3.html > > All persons in the community are encouraged to discuss Policy Proposal > 2006-3 in the weeks leading to the ARIN Public Policy Meeting in > Montreal scheduled for April 10-11, 2006. Both the discussion on the > Public Policy Mailing List and at the Public Policy Meeting will be used > to determine the community consensus regarding this policy proposal. > > The ARIN Internet Resource Policy Evaluation Process can be found at: > http://www.arin.net/policy/irpep.html > > ARIN's Policy Proposal Archive can be found at: > http://www.arin.net/policy/proposals/proposal_archive.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ### * ### > > > Policy Proposal 2006-3: Capturing Originations in Templates > > Author: Sandra Murphy > > Proposal type: new > > Policy term: permanent > > Policy statement: > > ARIN will collect an optional field in all IPv4 and IPv6 address block > transactions (allocation and assignment requests, reallocation and > reassignment actions, transfer and experimental requests). This > additional field will be used to record a list of the ASes that the user > permits to originate address prefixes within the address block. > > ARIN will produce a collection of the mappings from address blocks to > ASes permitted to originate that address block, The collection will > consist of a list where each entry will consist, at a minimum, of > an address block, a list of AS numbers, and a tag indicating the type of > delegation of the address block. This collection will be produced at > least daily. > > ARIN will make the collected mappings from address blocks to AS numbers > available for bulk transfer in one or more formats chosen at its own > discretion, informed by the community's current needs. This data will > not be subject to any redistribution restrictions -- it may be > republished or repackaged it any form. Should ARIN choose to use WHOIS > bulk transfer as the bulk form of data access required by this > paragraph, the address block to AS mappings will not be subject to any > redistribution restrictions, but the remainder of the WHOIS data will > remain subject to the terms of the then-current AUP regarding bulk > access to WHOIS data. > > ARIN may also make the collected or individual mappings from address > blocks to AS numbers available in other forms, possibly query > services, chosen at its own discretion, informed by the community's > current needs. ARIN may require agreement to an acceptable use policy > for access to the data in these forms. > > Rationale: > > Origination of prefixes by ASes that have no authority for the > origination is a recurring problem in the Internet routing system. A > list of authorized prefix originations would be beneficial to operators in > constructing routing filter lists to counter bogus > originations, > interacting with customers requesting routing of a prefix, and > diagnosing routing problems. > > A list of authorized prefix originations is also the necessary first > step for any known solution for securing the routing system. > > Prefix originations can be stored in routing registry RPSL route > objects. However, the authority for addresses and for ASes belongs to > the RIRs. There is presently no mechanism to translate ARIN's authority > for number resources to an IRR. Furthermore, operators have been less > than diligent in creating and maintaining route objects. Capturing the > prefix origination authorization in number resource registrations with > ARIN has two main goals: > benefit from the scrutiny with which ARIN verifies initial > requests and authenticates subsequent transactions, and > inherit the operators' self-discipline in completing resource > requests and transactions. > As an additional benefit, this could take a step toward populating the > IRR with data known to be accurate. > > The intended use of this data means that both query for individual > entries and bulk access to a list of the collected entries, without > restriction on redistribution, is required. This policy requires that > the additional data be provided through the usual whois query service > and some bulk access service that has no restrictions. It permits ARIN > to provide the bulk access through the existing bulk whois service if > the new additional data is not subject to the bulk whois AUP > restrictions. The policy does not limit ARIN to providing only those > two services (whois query and unrestricted bulk access); other > additional services may be developed at ARIN's discretion. > > It is expected that entries in the list of collected entries will > include at a minimum the present NetRange and NetType attributes, with a > new attribute, perhaps named OriginatingASList, for the list of > permitted originating ASes. > > This policy will presumably be incorporated into NRPM section 3.4. > > Timetable for implementation: Within sixty (60) days of approval. > > > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From sleibrand at internap.com Sat Feb 18 11:20:53 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Sat, 18 Feb 2006 08:20:53 -0800 Subject: [ppml] Policy Proposal 2006-4: IPv6 Direct PI Assignments for End Sites References: <43F6253D.10700@arin.net> Message-ID: <008b01c634aa$423ce6d0$9f00a8c0@LeibrandLaptop> Restatement for the record (nothing new here): I support this policy proposal, though I prefer the latest revision of 2005-1 because IMO it has better conditions in 6.5.8.1. I would ideally prefer a hybrid proposal using 2005-1's 6.5.8.1 wording and 2006-4's 6.5.8.2 and 6.5.8.3 wording. -Scott ----- Original Message ----- From: "Member Services" To: Sent: Friday, February 17, 2006 11:34 AM Subject: [ppml] Policy Proposal 2006-4: IPv6 Direct PI Assignments for EndSites On February 16, 2006, the ARIN Advisory Council concluded its review of 'IPv6 Direct PI Assignments for End Sites' and accepted it as a formal policy proposal for discussion by the community. This proposal is designated Policy Proposal 2006-4: IPv6 Direct PI Assignments for End Sites. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/2006_4.html All persons in the community are encouraged to discuss Policy Proposal 2006-4 in the weeks leading to the ARIN Public Policy Meeting in Montreal scheduled for April 10-11, 2006. Both the discussion on the Public Policy Mailing List and at the Public Policy Meeting will be used to determine the community consensus regarding this policy proposal. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html ARIN's Policy Proposal Archive can be found at: http://www.arin.net/policy/proposals/proposal_archive.html Regards, Member Services American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal 2006-4: IPv6 Direct PI Assignments for End Sites Author: Andrew Dul Proposal type: new Policy term: permanent Policy statement: Add new subsection to the NRPM: 6.5.8. Direct assignments to end sites 6.5.8.1. To qualify for a direct end site assignment, an organization must meet all of the following criteria: 1. not be an LIR; 2. be an end site; 3. be currently multihomed using IPv4; 4. have a direct assignment from ARIN of at least a IPv4 /19 and can show the current utilization of 80% of an IPv4 /19 equivalent. 6.5.8.2. Direct assignment size to end sites Organizations that meet the direct end site assignment criteria are eligible to receive a direct assignment of /48 out of a reserved /44. Direct Assignments shall be allocated from a separate super-block to allow for LIRs to filter. 6.5.8.3. Subsequent direct assignments to end sites Organizations assignment size may be increased by 1 bit (to a maximum of /44) when they demonstrate the active usage of 50% of the assigned /64 subnets. Only one direct assignment may be made to an end site organization under Section 6.5.8. Organizations which can demonstrate active usage of more than 50% of /64 networks from a /44 assignment shall qualify for an additional allocation as an LIR. Rationale: This policy is proposed as an alternative to the existing 2005-1 policy proposal. This policy is intended to be more conservative that the existing proposed 2005-1 policy. While this policy does allow PI assignments to end-sites, it limits the scope to current IPv4 holders with direct assignments. A more conservative policy is desirable as the first IPv6 PI policy. Current ARIN policy does not permit an end-site from obtaining a Provider Independent IPv6 address block directly from ARIN. There is currently no viable IPv6 multihoming method available for these end-sites. Shim6 & other methods have been proposed as a possible method to meet multihoming requirements. Today, no implementation or alternatives exist to ?traditional? IPv4 multihoming which announces unique address space from an ASN. The largest end-sites (corporations & content providers) have the greatest to gain and/or lose by not having an available method to multihome. While IPv6 provides for stateless auto configuration for end hosts, no new methods for renumbering the infrastructure are available. The cost and complexity of renumbering these large organizations makes it essential to provide stable address resources which are not assigned from a LIR. The lack of an end-site assignment policy is currently preventing the real planning and deployment of IPv6 networks in these organizations. Other policy proposals (2005-1) addressing this issue have been presented at the ARIN 15 & 16 meetings. This policy proposal attempts to address the issues that were raised on the ppml mailing list and at the public policy meetings for 2005-1. Specifically, the main issue surrounding the creation of consensus on this policy appears to be the criteria for which end-sites should be able to obtain an endsite assignment. Concerns have been raised about the creation of a new IPv6 ?swamp? by having a policy that is too lenient. This issue is addressed in the policy by limiting the endsite assignments to current organizations with a modest IPv4 assignment. The assignment of IPv4 resources is orthogonal to the assignment of IPv6 addresses. However, the use of existing IPv4 assignments and ARIN membership are postulated as an appropriate regulator for the initial assignments under an IPv6 endsite policy. It is reasonable to consider changes to the membership and IPv4 assignment requirements in the future. This review should be conducted after the endsite assignment policy has been in place long enough to understand the demand for endsite IPv6 assignments and the development of IPv6 networks have matured. This policy proposal does not attempt to address the assignment needs for endsites which currently do not have IPv4 assignments. Timetable for implementation: within 90 days of approval by the BoT _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From sleibrand at internap.com Sat Feb 18 11:55:29 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Sat, 18 Feb 2006 11:55:29 -0500 (EST) Subject: [ppml] Proposed Policy: IPv4 Micro-allocations for anycast services (experimental) In-Reply-To: <20060217201421.GA20563@shell01.corp.tellme.com> References: <43ECB1DF.4000006@arin.net> <20060217201421.GA20563@shell01.corp.tellme.com> Message-ID: On 02/17/06 at 12:14pm -0800, David Williamson wrote: > In my opinion, the possibility for abuse of the policy to acquire /24s > for multihoming was the primary grounds for rejection. The length > argument struck me as somewhat secondary. Still, it's an interesting > argument. > > I did a bit of an experiment, and picked one of the three /24s I have > free and announced it. While it's true that some providers seem to > happily forward any /24 that falls into their routing table, there are > definitely route-servers out there that aren't seeing that route. To > be honest, I can't see why that route isn't appearing. It's clearly > getting filtered, but that could be because it's a longer prefix out of > a netblock that has shorter (i.e., /22) allocations. It could also be > that someone picks up route policy from a routing database that we > aren't presently in. This matches what I would expect, and IMO is insufficient evidence of unreachability to support a new IPv4 Micro-allocation policy. I would modify your experiment slightly as follows: - Announce the /24 while continuing to announce the larger block. - Register the /24 in RADB or an RR it mirrors. - Check the route-servers as you did before. Note the AS paths seen for the /24. Also note the AS paths seen for the /22 (or whatever your larger allocation is). - Pull out all the AS paths seen for the /22 but not for the /24. Using the assumption that any such networks will forward your traffic based on their route for the /22, reconstruct the AS path the traffic will take, and determine where in that AS path it will reach a network which does have your /24. The idea here is this: say you have PA space from NSP X, and are multihomed to NSP Y and Z as well, possibly in two different locations. You want to run anycast using a /24 (A) you got from NSP X. For argument's sake, let's say that prefix A is a subnet of NSP X's /8 aggregate, and there are no other overlapping subnets of A in BGP. In my experience, NSPs X, Y, and Z will all accept your /24 from each other. In addition, most other NSPs with a global presence will also accept it. Some regional networks on other continents will filter your /24, but will still accept NSP X's /8 aggregate. Ditto for some smaller domestic ISPs who buy transit from NSPs. In this case, a foreign NSP F, which filters /24's, will not see your /24. Instead, they will send traffic to that netblock towards NSP X. Let's assume that your link to NSP X is down. In that case, NSP X will get the traffic, and see that their best route for it is your /24, which they're hearing from NSP Y or Z. They'll forward the traffic along to you, and the only minor ill effect will be that NSP F sent the traffic via NSP X instead of direct to Y or Z. Now, let's consider the case where you get a /24 micro-allocation from ARIN. Let's assume that at least initially, some netblocks will fail to update their filters to allow /24 announcements from ARIN's anycast micro-allocation block. In that case, there will be no larger aggregate for them to fall back on, and therefore traffic to your /24 will be blackholed. Given these scenarios, I think it is better to do anycast out of a larger PA or PI netblock, rather than trying to get a /24 directly from ARIN for the purpose. > That said, I'd love to hear feedback from folks at other major ISPs. > Has *everyone* relaxed the /22 route filtering limit? The intent of > this policy is to have blocks of an appropriate size for the > application handed out in a way that will ensure global reachability. > If *any* of the top volume ISPs do filter based on RIR policy guidelines > (and several have historically), then longer prefixes from 'normal' > blocks won't really suffice. As argued above, I don't think that /24 filtering equals unreachability in most cases. > That desire for global reachability is the one of the primary > motivations for this policy. And IMO you should already have global reachability today. Any attempts to use PI /24 micro-allocations would IMO reduce your reachability, not improve it. Given all that, I will be opposed to 2006-5 unless you can show me that an anycasted /24 out of a larger netblock is truly unreachable from somewhere. Given the widespread acceptance of /24 subnets, and the overlapping coverage of a larger aggregate, I don't suspect you'll find any such situations. -Scott > On Fri, Feb 10, 2006 at 02:21:20PM -0500, Scott Leibrand wrote: > > David, > > > > A very similar policy was rejected at the last ARIN meeting in L.A. on > > the grounds that a subnet of an existing network is adequate for running > > anycast. Can you clarify why this policy is required, in light of that > > consensus? I think there is significant disagreement in the community > > with your statement that "many ISPs also filter routes longer than /22, > > [so] it is impractical to use a longer mask for any netblock that is > > utilized for an anycast service." Do you have concrete examples to back > > up this statement? > > > > Thanks, > > Scott > > > > On 02/10/06 at 10:31am -0500, Member Services wrote: > > > > > ARIN received the following proposed policy. In accordance with the ARIN > > > Internet Resource Policy Evaluation Process, the proposal is being > > > posted to the ARIN Public Policy Mailing List and being placed on ARIN's > > > website. > > > > > > The ARIN Advisory Council (AC) will review the proposal and within ten > > > working days may decide to: > > > 1) Support the proposal as is, > > > 2) Work with the author to clarify, divide or combine one or more > > > policy proposals, or > > > 3) Not support the policy proposal. > > > > > > If the AC supports the proposal or reaches an agreement to work with the > > > author, then the proposal will be posted as a formal policy proposal to > > > the Public Policy Mailing List and it will be presented at the Public > > > Policy Meeting. If the AC does not support the proposal, then the author > > > may elect to use the petition process to advance the proposal. If the > > > author elects not to petition or the petition fails, then the proposed > > > policy 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: IPv4 Micro-allocations for anycast services > > > (experimental) > > > > > > Author: David Williamson > > > > > > Proposal type: new > > > > > > Policy term: temporary > > > > > > Policy statement: > > > > > > In the NRPM IPv4 section, renumber 4.4 to 4.4.1, and add: > > > > > > 4.4.2 Micro-allocations for anycast services - ARIN will make > > > micro-allocations to organizations wishing to deploy anycast based > > > services, provided they meet the following criteria: > > > > > > * All of the criteria normally required to receive IPv4 space, AND > > > * The organization must have multiple (at least two) discrete > > > multi-homed networks. > > > * The organization must advertise directly allocated networks from > > > each multi-homed site. > > > > > > Micro-allocations for anycast services will be no longer than a /24. > > > These allocations will be made out of blocks reserved for > > > micro-allocation purposes. ISPs and other organizations receiving these > > > micro-allocations will be charged under the ISP fee schedule, while > > > end-users will be charged under the fee schedule for end-users. > > > > > > This policy is experimental, and is limited to 16 allocations and two > > > years from adoption. In addition, organizations may receive no more > > > than one microallocation under this policy. > > > > > > Rationale: > > > > > > There are an increasing number of anycast-based applications being > > > offered by service providers and other organizations. Indeed, many > > > basic infrastructure services (like the DNS root servers) are already > > > anycast based. (See RFC 1546 for an authoritative discussion of anycast > > > services.) > > > > > > It's worth noting that IPv6 has anycast built into the protocol itself. > > > This is a sign that there is significant community interest in anycast > > > as a technology, and highlights the lack of IPv4 allocation policy for > > > anycast. > > > > > > Deployment of new services is severely hampered by current IPv4 > > > allocation policies. For organizations that do not have legacy IP > > > space, justifying a /22 to serve a handful of addresses is effectively > > > impossible. As many ISPs also filter routes longer than /22, it is > > > impractical to use a longer mask for any netblock that is utilized for > > > an anycast service. This situation is also generally unfavorable to > > > younger organizations, while giving older organizations that do have a > > > surplus of legacy space a competitive advantage. > > > > > > In light of this, some organizations may simply lie about their > > > addressing needs in order to convince an RIR or LIR that a /22 is > > > required, when a much smaller network would suffice. This is not a > > > behavior that should be encouraged by policy. > > > > > > The obvious answer is that a micro-allocation scheme needs to be created > > > to allow organizations deploying anycast services to acquire a network > > > of more appropriate size. > > > > > > It is also clear that a micro-allocation policy that makes it easier for > > > organizations to acquire small netblocks may lead to additional improper > > > allocations to organizations that simply wish to acquire additional > > > small blocks of space. This policy proposal attempts to address that by > > > requiring more stringent requirements for such allocations. > > > > > > A previous policy proposal (2005-6) is similar to this proposal, but > > > with a few significant changes. There was signficant negative feedback > > > to that policy based on a couple of key difficulties, which this > > > proposal attempts to address. > > > > > > The primary difficulty is that an anycast network looks much like a > > > normal multihomed network from the outside. This led to the consensus > > > belief that the earlier policy proposal would be abused by organizations > > > that wouldn't otherwise qualify for address space. This proposal futher > > > restricts allocations such that only organizations that are already > > > demonstratably multihomed with direct allocations can possibly qualify. > > > Such organizations will typically have little use for a small > > > allocation unless they really intend to use it for a specific purpose. > > > > > > In addition, this policy is marked as experimental and has a sunset > > > clause, which will definitively prevent widespread abuse. It is hoped > > > that operational experience will show that this policy is not seeing > > > abuse, and it can later be modified to be permanent. In the event that > > > this policy is widely abused, the total damage is limited and will be > > > fixed in a relatively short time span. > > > > > > Timetable for implementation: immediate > > > > > > > > > _______________________________________________ > > > 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 > From christopher.morrow at gmail.com Sat Feb 18 13:05:42 2006 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Sat, 18 Feb 2006 18:05:42 +0000 Subject: [ppml] Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure In-Reply-To: <008901c634aa$3c7a4ad0$9f00a8c0@LeibrandLaptop> References: <43F6247A.8040406@arin.net> <008901c634aa$3c7a4ad0$9f00a8c0@LeibrandLaptop> Message-ID: <75cb24520602181005p17123a49i63d524201d7a0b8c@mail.gmail.com> On 2/18/06, Scott Leibrand wrote: > Re-statement for the record (nothing new here): > > This seems like a reasonable IPv6 MicroAllocation policy. If we're going > to replace the "/24 using IPv4 or a /48 using IPv6" language of section > 6.10 with the text below, IMO we should also modify section 4.4 to remove > the "/48 using IPv6" language and instead refer users to 6.10 for the IPv6 > MicroAllocation policy. > > Aside from that quibble, I currently support the policy proposal as > written. > I am not certain on the process... but Heather was going to update with the better wording, since it doesn't change the spirit of the content :) Uhm... so, does one just re-submit the proposal prior to the meeting or re-post to PPML? or the AC or ??? -Chris From stephen at sprunk.org Sat Feb 18 17:13:15 2006 From: stephen at sprunk.org (Stephen Sprunk) Date: Sat, 18 Feb 2006 16:13:15 -0600 Subject: [ppml] Fw: IRS goes IPv6! References: <031e01c631aa$563011b0$710016ac@ssprunk> <1140006374.27853.153.camel@firenze.zurich.ibm.com> Message-ID: <01f901c634e7$9894b4d0$6b01a8c0@ssprunk> Thus spake "Jeroen Massar" >On Tue, 2006-02-14 at 14:33 -0600, Stephen Sprunk wrote: >> How, exactly, did the IRS manage to get a direct allocation from >> ARIN? Did they somehow qualify as an LIR? Did they snow the >> staffers? Did the US Govt put some sort of pressure on ARIN? > > There are two points I wanted to make with the email, though not > many caught it I guess (could be because of the broken sentence ;) : > - a pun: 'how taxing the IRS would find IPv6' > * difficulty of getting the address space (alloc) > * difficulty of setting up and starting to use it (deploy) > - the fact that everybody can get address space. > > It is very simple: Current policy has 1 main entry: > - requirement for more than 200 'sites' Not exactly. 6.5.1.1. Initial allocation criteria To qualify for an initial allocation of IPv6 address space, an organization must: ... d) be an existing, known ISP in the ARIN region or have a plan for making at least 200 /48 assignments to other organizations within five years. There are several different ways to read that, but one can't interpret that as merely requiring "200 sites". > The word 'site' is very open. No, it is not: 6.2.9. End site An end site is defined as an end user (subscriber) who has a business relationship with a service provider that involves: 1. that service provider assigning address space to the end user 2. that service provider providing transit service for the end user to other sites 3. that service provider carrying the end user's traffic. 4. that service provider advertising an aggregate prefix route that contains the end user's assignment > Every single office building of the IRS can be counted as a seperate > entity. They most likely don't have connectity to the $world, but they > do need address space. Thus they request from ARIN their address > space, specify that they have 200++ sites and simply get it (after > having paid up etc). They'd have to prove that either they were a known ISP (which I doubt) or that they planned to assign 200 /48s to other organizations (which I also doubt). My reading of this is that ARIN allowed them to claim each physical location was a separate "organization" because there was no other way to fulfill their request, which was probably reasonable otherwise. If this sort of game passes muster with ARIN, that means any company with at least 200 locations (or at least a plan to have that many) or that pays a few bucks to create 200 shell companies can get a LIR allocation. This is a very slippery slope, and IMHO we need a true PI policy to put a stop to this nonsense. I've gotten a few private emails that list dozens of companies and other govt orgs that have supposedly done exactly this; it's apparently the best-known hole in IPv6 address policy. If end users are going to be getting space, though, we should provide a more appropriate policy for them (and assign from a dedicated block). > Most likely it will never pop up on the internet, but that is not what > the RIR's are for; they only provide address space and this > organisation showed a requirement for address space. No, we assume they did. We're not privvy to what the ARIN staff saw or did not see. Nor do I see why you assume that the IRS's computers will never talk to the Internet; I agree it's irrelevant to the v6 allocation/assignment process, but I see no basis for your claim. Do IRS auditors not surf the web on their lunch break like everyone else? > > If end sites like the IRS can get direct allocations today, perhaps > > all this discussion about PI space is moot and we don't need > > 2005-1 et al. > > The policy doesn't cover 1 case: SMB's who who want their own > address space for various reasons (mostly being independent). For > these cases their should come a new policy which allows them to > get a /48 or upto something like a /40 depending on how much > they really need and if they consist out of a lot of networks or just > a few. See my note above about shell companies and the slippery slope. I don't know about your SMB, but mine could easily file some papers at the courthouse Monday morning and qualify for an LIR allocation by that afternoon. > These 'small' blocks should be allocated from a single large block, > per RIR or globally chunked into a portion each for a RIR. This would, > in case of routing scalability issues to start some aggregation or > other weird tricks in those blocks, assuming that they will become > the gross of the table. Shim6 and future work could then use the > /48 as an ID, while using the /48 they receive from their upstream > as the IP which is routed. But that is just keeping in mind the > future and that we can't envision what will happen, though the > math is pretty easy (every business a /48, X million businesses/ > other-sites globally...) There are some folks here who think every location within an end user org should get its own /48, so that is potentially off by several bits, but otherwise I agree with you. S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin From randy at psg.com Sat Feb 18 19:16:54 2006 From: randy at psg.com (Randy Bush) Date: Sat, 18 Feb 2006 14:16:54 -1000 Subject: [ppml] Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure References: <43F6247A.8040406@arin.net> Message-ID: <17399.47350.210452.764141@roam.psg.com> 6.10.2 other than root servers, i see no need for golden space for dns servers, as one can look them up in the dns. this has been gone over a thousand times. there is some discussion of anycasted servers, 6.10.3 specify that these MUST NOT be announced to the internet and that they will be revoked if they are. randy From heather.skanks at gmail.com Sat Feb 18 20:59:14 2006 From: heather.skanks at gmail.com (heather skanks) Date: Sat, 18 Feb 2006 20:59:14 -0500 Subject: [ppml] Wiki experiment for policy proposals Message-ID: <616812070602181759s7dfe587cgdb9ffad0f10e8040@mail.gmail.com> At the last ARIN meeting, a few of us kicked around the idea of using a wiki to discuss and track changes to policy proposals. A wiki would allow us to play with the wording, and have a discussion area for each proposal. I figured what better place to experiment than with our own proposal, 2006-2 Microallocations for Internal Infrastructure. Below is a link to a wiki we set up. On the page containing the policy, there is a tab for discussion. http://wiki.secsup.org Heather -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeroen at unfix.org Sun Feb 19 09:46:27 2006 From: jeroen at unfix.org (Jeroen Massar) Date: Sun, 19 Feb 2006 15:46:27 +0100 Subject: [ppml] Fw: IRS goes IPv6! In-Reply-To: <01f901c634e7$9894b4d0$6b01a8c0@ssprunk> References: <031e01c631aa$563011b0$710016ac@ssprunk> <1140006374.27853.153.camel@firenze.zurich.ibm.com> <01f901c634e7$9894b4d0$6b01a8c0@ssprunk> Message-ID: <1140360388.30974.38.camel@firenze.zurich.ibm.com> On Sat, 2006-02-18 at 16:13 -0600, Stephen Sprunk wrote: > Thus spake "Jeroen Massar" > >On Tue, 2006-02-14 at 14:33 -0600, Stephen Sprunk wrote: [..] > > It is very simple: Current policy has 1 main entry: > > - requirement for more than 200 'sites' > > Not exactly. > > 6.5.1.1. Initial allocation criteria > > To qualify for an initial allocation of IPv6 address space, an > organization must: > ... > d) be an existing, known ISP in the ARIN region or have a plan for > making at least 200 /48 assignments to other organizations within five > years. > > There are several different ways to read that, but one can't interpret that > as merely requiring "200 sites". This is how I interpret it and many other folks too. > > The word 'site' is very open. > > No, it is not: > > 6.2.9. End site [..] These points show exactly that it is very open; because what do you define as an 'end user': 8<----- 2.6 An end-user is an organization receiving assignments of IP addresses exclusively for use in its operational networks. ----->8 Any 'branch' of a company is already a (seperate) organization, in most cases legally and financially. > > Every single office building of the IRS can be counted as a seperate > > entity. They most likely don't have connectity to the $world, but they > > do need address space. Thus they request from ARIN their address > > space, specify that they have 200++ sites and simply get it (after > > having paid up etc). > > They'd have to prove that either they were a known ISP (which I doubt) Why? They are most likely a very known Internet Service Provider to their own sub-organizations. The definition here is also very open. > or > that they planned to assign 200 /48s to other organizations (which I also > doubt). Depends on how one define organization. The "Dallas Chapter" is already a different organization (different director, accounting etc). > My reading of this is that ARIN allowed them to claim each physical > location was a separate "organization" because there was no other way to > fulfill their request, which was probably reasonable otherwise. Indeed. > If this sort of game passes muster with ARIN, that means any company with at > least 200 locations (or at least a plan to have that many) or that pays a > few bucks to create 200 shell companies can get a LIR allocation. This is a > very slippery slope, and IMHO we need a true PI policy to put a stop to this > nonsense. The nonsense part is that this big "loophole" exists and that organisations that need address space are not using it. > I've gotten a few private emails that list dozens of companies and other > govt orgs that have supposedly done exactly this; it's apparently the > best-known hole in IPv6 address policy. There are indeed *loads* of allocations made to companies which will never use the amount of address space they requested, but in most cases them getting the address space is a reasonable thing. It depends on the viewpoint though: do those organisations need address space or do they need independent routing. If they only need the latter they should fall under a new small-site policy, otherwise the /32 or so is fine for them. > If end users are going to be > getting space, though, we should provide a more appropriate policy for them > (and assign from a dedicated block). Full-ack. > > Most likely it will never pop up on the internet, but that is not what > > the RIR's are for; they only provide address space and this > > organisation showed a requirement for address space. > > No, we assume they did. We're not privvy to what the ARIN staff saw or did > not see. Nor do I see why you assume that the IRS's computers will never > talk to the Internet; I agree it's irrelevant to the v6 > allocation/assignment process, but I see no basis for your claim. Do IRS > auditors not surf the web on their lunch break like everyone else? I dunno, they most likely like that like everybody else. But from a 'security through obscurity' point of view I would not make the resources that use that address space available directly routed onto the internet (of course there is a thing called a firewall but that is not entiry safe in most misconfig cases either). Another reason would be the distribution of traffic. Where do you announce the aggregate and how do you get the packets from the branches to those places and back. They could thus use the allocation for their internal resources while using a local ISP for actually surfing the web and sending mail etc. All theoretical assumptions of course. > > > If end sites like the IRS can get direct allocations today, perhaps > > > all this discussion about PI space is moot and we don't need > > > 2005-1 et al. > > > > The policy doesn't cover 1 case: SMB's who who want their own > > address space for various reasons (mostly being independent). For > > these cases their should come a new policy which allows them to > > get a /48 or upto something like a /40 depending on how much > > they really need and if they consist out of a lot of networks or just > > a few. > > See my note above about shell companies and the slippery slope. I don't > know about your SMB, but mine could easily file some papers at the > courthouse Monday morning and qualify for an LIR allocation by that > afternoon. It's indeed quite slippery and that needs to be fixed. It does currently already allow most organisations to get an allocation, even without a court to come in betwween ;) I have not seen a landrush yet, but the hole should be closed before the dam breaks. > > These 'small' blocks should be allocated from a single large block, > > per RIR or globally chunked into a portion each for a RIR. This would, > > in case of routing scalability issues to start some aggregation or > > other weird tricks in those blocks, assuming that they will become > > the gross of the table. Shim6 and future work could then use the > > /48 as an ID, while using the /48 they receive from their upstream > > as the IP which is routed. But that is just keeping in mind the > > future and that we can't envision what will happen, though the > > math is pretty easy (every business a /48, X million businesses/ > > other-sites globally...) > > There are some folks here who think every location within an end user org > should get its own /48, so that is potentially off by several bits, but > otherwise I agree with you. The /48 is indeed very up for debate. According to some calculations I've seen and also my own usage, a /56 seems to be better covering and also allows more future growth. Eg a SMB could get a /48 and give /56's or so to it's sub-organisations. I do think though that having global routing entries From stephen at sprunk.org Sun Feb 19 16:12:48 2006 From: stephen at sprunk.org (Stephen Sprunk) Date: Sun, 19 Feb 2006 15:12:48 -0600 Subject: [ppml] Fw: IRS goes IPv6! References: <031e01c631aa$563011b0$710016ac@ssprunk> <1140006374.27853.153.camel@firenze.zurich.ibm.com> <01f901c634e7$9894b4d0$6b01a8c0@ssprunk> <1140360388.30974.38.camel@firenze.zurich.ibm.com> Message-ID: <009f01c63599$5575f4e0$6b01a8c0@ssprunk> Thus spake "Jeroen Massar" > On Sat, 2006-02-18 at 16:13 -0600, Stephen Sprunk wrote: > > d) be an existing, known ISP in the ARIN region or have a plan for > > making at least 200 /48 assignments to other organizations within five > > years. > > > > There are several different ways to read that, but one can't interpret > > that > > as merely requiring "200 sites". > > This is how I interpret it and many other folks too. If you do multiple (IMHO dubious) substitutions of terms, yes, but I think there's still room for debate on that (below). > > > The word 'site' is very open. > > > > No, it is not: > > > > 6.2.9. End site > [..] > These points show exactly that it is very open; because what do you > define as an 'end user': > > 8<----- > 2.6 > An end-user is an organization receiving assignments of IP addresses > exclusively for use in its operational networks. > ----->8 > > Any 'branch' of a company is already a (seperate) organization, in most > cases legally and financially. I don't buy that. In the case of a franchise, it's clear that the location is a separate legal entity (i.e. organization), but in the case of an IRS office (or other integral property of some parent org), I have trouble seeing any legal separation. The separation is only logical or physical, which IMHO does not meet the standard. > > > Every single office building of the IRS can be counted as a seperate > > > entity. They most likely don't have connectity to the $world, but they > > > do need address space. Thus they request from ARIN their address > > > space, specify that they have 200++ sites and simply get it (after > > > having paid up etc). > > > > They'd have to prove that either they were a known ISP (which I doubt) > > Why? They are most likely a very known Internet Service Provider to > their own sub-organizations. The definition here is also very open. Absent a comment from the author, a reasonable reading of the text gives the original intent not as "some small closed group of people know the org is an ISP" but rather "is known to the public as an ISP". IRS-IT fails the latter. > > or that they planned to assign 200 /48s to other organizations (which I > > also doubt). > > Depends on how one define organization. The "Dallas Chapter" is > already a different organization (different director, accounting etc). A middle manager and his/her budget does not a distinct organization make. > > If this sort of game passes muster with ARIN, that means any > > company with at least 200 locations (or at least a plan to have that > > many) or that pays a few bucks to create 200 shell companies can > > get a LIR allocation. This is a very slippery slope, and IMHO we > > need a true PI policy to put a stop to this nonsense. > > The nonsense part is that this big "loophole" exists and that > organisations that need address space are not using it. I suppose that's one way to look at it. Hey, ISP guys: the big bad enterprises can already get all the precious routing slots they want today; how about you support 2005-1 or 2006-4 so that we can limit the potential for problems (and segregate them into a different block)? Maybe that'll work better than the "Please Sir, may I have another?" we've been using to date. > > I've gotten a few private emails that list dozens of companies and other > > govt orgs that have supposedly done exactly this; it's apparently the > > best-known hole in IPv6 address policy. > > There are indeed *loads* of allocations made to companies which will > never use the amount of address space they requested, but in most > cases them getting the address space is a reasonable thing. I wasn't arguing that it was unreasonable for the various orgs with dubious IPv6 allocations to get them, merely that they had abused the ISP policy due to lack of an end-site one. > It depends on the viewpoint though: do those organisations need > address space or do they need independent routing. If they only > need the latter they should fall under a new small-site policy, > otherwise the /32 or so is fine for them. > > If end users are going to be getting space, though, we should provide > > a more appropriate policy for them (and assign from a dedicated block). > > Full-ack. At least we agree on that much. > > > Most likely it will never pop up on the internet, but that is not what > > > the RIR's are for; they only provide address space and this > > > organisation showed a requirement for address space. > > > > No, we assume they did. We're not privvy to what the ARIN staff > > saw or did not see. Nor do I see why you assume that the IRS's > > computers will never talk to the Internet; I agree it's irrelevant to > > the > > v6 allocation/assignment process, but I see no basis for your claim. > > Do IRS auditors not surf the web on their lunch break like everyone > > else? > > I dunno, they most likely like that like everybody else. But from a > 'security through obscurity' point of view I would not make the > resources that use that address space available directly routed onto the > internet (of course there is a thing called a firewall but that is not > entiry safe in most misconfig cases either). If they didn't want to use globally-reachable addresses inside the firewall, they could use ULAs. That, of course, opens the door for things like NAT, in which case they might as well just stick to IPv4. The main driving factor for IPv6 is that you're able to give a unique global address to every host. There's no challenge to putting all of their addresses behind a firewall minus one or two for the DMZ. Pleanty of folks with pre-CIDR assignments do that with IPv4, even. > Another reason would be the distribution of traffic. Where do you > announce the aggregate and how do you get the packets from the > branches to those places and back. They could thus use the > allocation for their internal resources while using a local ISP for > actually surfing the web and sending mail etc. All theoretical > assumptions of course. Based on my experience with similar large orgs, I find that unlikely, but if true they've got problems regardless of what type of addresses are where. > > See my note above about shell companies and the slippery slope. > > I don't know about your SMB, but mine could easily file some > > papers at the courthouse Monday morning and qualify for an LIR > > allocation by that afternoon. > > It's indeed quite slippery and that needs to be fixed. It does currently > already allow most organisations to get an allocation, even without > a court to come in betwween ;) I have not seen a landrush yet, but > the hole should be closed before the dam breaks. I don't agree with "most organizations", though if that were "most organizations that have the resources to multihome" I would. There's millions of SMBs out there, most with under 50 employees and a single location. BGP-capable sites are few and far between, relatively speaking, and the IPv4 table confirms that. > > There are some folks here who think every location within an end > > user org should get its own /48, so that is potentially off by several > > bits, but otherwise I agree with you. > > The /48 is indeed very up for debate. According to some calculations > I've seen and also my own usage, a /56 seems to be better covering > and also allows more future growth. Eg a SMB could get a /48 and > give /56's or so to it's sub-organisations. I think it'd be simpler to define an acceptable HD ratio based purely on subnet count. There is little sense in delegating /48s (or /56s) to various sub-organizations which share the same network; let topology (not arbitrary org-charts) dictate where the addresses go, and give people more if they need them. > I do think though that having global routing entries avoided. Though address space requirements != routing, which is > something that should be kept in mind too. The expected routing > problem should not cause limit anyone to get the correct amount of > address space that they would need. I don't have a problem with shorter prefixes -- I just don't see a point in gratuitously wasting address space, no matter how much we have. The standards for justification of more than the minimum can be fairly lax, but if a /48 meets 95% of applicants' needs, why make the minimum any larger? S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin From owen at delong.com Sun Feb 19 19:44:08 2006 From: owen at delong.com (Owen DeLong) Date: Sun, 19 Feb 2006 16:44:08 -0800 Subject: [ppml] Wiki experiment for policy proposals In-Reply-To: <616812070602181759s7dfe587cgdb9ffad0f10e8040@mail.gmail.com> References: <616812070602181759s7dfe587cgdb9ffad0f10e8040@mail.gmail.com> Message-ID: FWIW, I am not terribly keen on the idea of Wiki as a policy forum. I find the interface provided by wiki to be clunky and poor in featureset when it comes to editing. If you want to go to a group-writeable policy whiteboard, I'd much rather use something like CVS or SVN. They have web-based interfaces, but, don't penalize those of us that prefer more feature-rich editing envirnoments. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From stephen at sprunk.org Mon Feb 20 14:43:15 2006 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 20 Feb 2006 13:43:15 -0600 Subject: [ppml] Fw: IRS goes IPv6! References: <031e01c631aa$563011b0$710016ac@ssprunk><1140006374.27853.153.camel@firenze.zurich.ibm.com><01f901c634e7$9894b4d0$6b01a8c0@ssprunk><1140360388.30974.38.camel@firenze.zurich.ibm.com><009f01c63599$5575f4e0$6b01a8c0@ssprunk> <87mzgmn91p.fsf@valhalla.seastrom.com> Message-ID: <01d201c63655$e4855060$6d0016ac@ssprunk> Thus spake "Robert E.Seastrom" > "Stephen Sprunk" writes: >> Absent a comment from the author, a reasonable reading of the text >> gives the original intent not as "some small closed group of people >> know the org is an ISP" but rather "is known to the public as an ISP". >> IRS-IT fails the latter. > > Careful there, you're dangerously close to disenfranchising > organizations such as SITA and DISA by advocating that requirement. Okay, perhaps "to the public" would be going a little too far, but SITA is known as an carrier in the telecom world (though I didn't realize they're an ISP too -- or is that Equant?), as is DISA. DISA is certainly well-known to ARIN and IANA, having received several /8s dating back to 1993, and similarly SITA has one from 1995. Undoubtedly both could qualify under the "200 other organizations" clause in any case, though, so it doesn't matter if they're "known". Clearly, both fit well as LIRs, probably better than as end-sites (which are the current topic). S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin From dgolding at burtongroup.com Mon Feb 20 18:34:37 2006 From: dgolding at burtongroup.com (Daniel Golding) Date: Mon, 20 Feb 2006 18:34:37 -0500 Subject: [ppml] Fw: IRS goes IPv6! In-Reply-To: <01d201c63655$e4855060$6d0016ac@ssprunk> Message-ID: On 2/20/06 2:43 PM, "Stephen Sprunk" wrote: > Thus spake "Robert E.Seastrom" >> "Stephen Sprunk" writes: >>> Absent a comment from the author, a reasonable reading of the text >>> gives the original intent not as "some small closed group of people >>> know the org is an ISP" but rather "is known to the public as an ISP". >>> IRS-IT fails the latter. >> >> Careful there, you're dangerously close to disenfranchising >> organizations such as SITA and DISA by advocating that requirement. > > Okay, perhaps "to the public" would be going a little too far, but SITA is > known as an carrier in the telecom world (though I didn't realize they're an > ISP too -- or is that Equant?), as is DISA. DISA is certainly well-known to > ARIN and IANA, having received several /8s dating back to 1993, and > similarly SITA has one from 1995. > > Undoubtedly both could qualify under the "200 other organizations" clause in > any case, though, so it doesn't matter if they're "known". Clearly, both > fit well as LIRs, probably better than as end-sites (which are the current > topic). > This is almost like obscenity - "I know it when I see it". ARIN needs to come up with a real definition for a service provider, or at least have some clear examples for their folks to use as a guideline. Google? Yahoo? DISA? SITA? Walmart? IBM? EDS? It makes my head hurt. > S > > Stephen Sprunk "Stupid people surround themselves with smart > CCIE #3723 people. Smart people surround themselves with > K5SSS smart people who disagree with them." --Aaron Sorkin > - Dan From william at elan.net Mon Feb 20 18:39:30 2006 From: william at elan.net (william(at)elan.net) Date: Mon, 20 Feb 2006 15:39:30 -0800 (PST) Subject: [ppml] Fw: IRS goes IPv6! In-Reply-To: References: Message-ID: On Mon, 20 Feb 2006, Daniel Golding wrote: > > This is almost like obscenity - "I know it when I see it". ARIN needs to > come up with a real definition for a service provider, or at least have some > clear examples for their folks to use as a guideline. > > Google? > Yahoo? > DISA? > SITA? > Walmart? > IBM? > EDS? Maybe it would be easier of ARIN allows any organization that has network that extends to multiple sites (the network end-points maybe customers but can also be offices in corporate net) to become an LIR. That is what RIPE does if I'm not mistaken... -- William Leibzon Elan Networks william at elan.net From terry.l.davis at boeing.com Mon Feb 20 18:59:43 2006 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Mon, 20 Feb 2006 15:59:43 -0800 Subject: [ppml] Fw: IRS goes IPv6! Message-ID: <0D090F1E0F5536449C7E6527AFFA280A21BB65@XCH-NW-8V1.nw.nos.boeing.com> I would hope that no one questioned whether SITA, Arinc, and Inmarsat were "service providers"! Yes their networks and clients (airlines and air traffic control providers) are still mostly OSI based, but they probably cover more of the globe with their services than any but a handful of ISP's. And they are beginning to support IP as the aviation industry requires it! Take care Terry -----Original Message----- From: Daniel Golding [mailto:dgolding at burtongroup.com] Sent: Monday, February 20, 2006 3:35 PM To: Stephen Sprunk; Rob Seastrom Cc: PPML Subject: Re: [ppml] Fw: IRS goes IPv6! On 2/20/06 2:43 PM, "Stephen Sprunk" wrote: > Thus spake "Robert E.Seastrom" >> "Stephen Sprunk" writes: >>> Absent a comment from the author, a reasonable reading of the text >>> gives the original intent not as "some small closed group of people >>> know the org is an ISP" but rather "is known to the public as an ISP". >>> IRS-IT fails the latter. >> >> Careful there, you're dangerously close to disenfranchising >> organizations such as SITA and DISA by advocating that requirement. > > Okay, perhaps "to the public" would be going a little too far, but SITA is > known as an carrier in the telecom world (though I didn't realize they're an > ISP too -- or is that Equant?), as is DISA. DISA is certainly well-known to > ARIN and IANA, having received several /8s dating back to 1993, and > similarly SITA has one from 1995. > > Undoubtedly both could qualify under the "200 other organizations" clause in > any case, though, so it doesn't matter if they're "known". Clearly, both > fit well as LIRs, probably better than as end-sites (which are the current > topic). > This is almost like obscenity - "I know it when I see it". ARIN needs to come up with a real definition for a service provider, or at least have some clear examples for their folks to use as a guideline. Google? Yahoo? DISA? SITA? Walmart? IBM? EDS? It makes my head hurt. > S > > Stephen Sprunk "Stupid people surround themselves with smart > CCIE #3723 people. Smart people surround themselves with > K5SSS smart people who disagree with them." --Aaron Sorkin > - Dan _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From randy at psg.com Mon Feb 20 19:44:29 2006 From: randy at psg.com (Randy Bush) Date: Mon, 20 Feb 2006 14:44:29 -1000 Subject: [ppml] Fw: IRS goes IPv6! References: <0D090F1E0F5536449C7E6527AFFA280A21BB65@XCH-NW-8V1.nw.nos.boeing.com> Message-ID: <17402.25197.986039.98079@roam.psg.com> > I would hope that no one questioned whether SITA, Arinc, and Inmarsat > were "service providers"! definitely not, along with the us post, ups, and consolidated freightways just in case you missed it, the "i" in "arin" stands for "internet" randy From christopher.morrow at gmail.com Mon Feb 20 20:21:31 2006 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Tue, 21 Feb 2006 01:21:31 +0000 Subject: [ppml] Fw: IRS goes IPv6! In-Reply-To: References: Message-ID: <75cb24520602201721h71501d9gbdbc281dc1fe894d@mail.gmail.com> On 2/20/06, william(at)elan.net wrote: > > On Mon, 20 Feb 2006, Daniel Golding wrote: > > > > This is almost like obscenity - "I know it when I see it". ARIN needs to > > come up with a real definition for a service provider, or at least have some > > clear examples for their folks to use as a guideline. > > > > Google? > > Yahoo? > > DISA? > > SITA? > > Walmart? > > IBM? > > EDS? > > Maybe it would be easier of ARIN allows any organization that has network > that extends to multiple sites (the network end-points maybe customers > but can also be offices in corporate net) to become an LIR. That is what > RIPE does if I'm not mistaken... what's interesting is that USPS (for instance) has disparate points of presense, not always with 'internal' connnectivity. So, even with a /32 they have to either: 1) use PA space inn some locations 2) setup a full back-side/internal network and route accordingly 3) convince everyone to leak /48's around All other examples above fall into the same set of problems :( Google's datacenters around the world MIGHT NOT have 'internal' network connectivity, yahoo, eds, blah all have the same problem. This leads us to a discussion about PI space again :( Folks like DISA might have use for a /32 on a network NOT CONNECTED to the Internet of course, which brings up another discussion entirely :) Though, DISA is the DoD's "official NSP" as I recall... From hannigan at renesys.com Mon Feb 20 22:54:41 2006 From: hannigan at renesys.com (Martin Hannigan) Date: Mon, 20 Feb 2006 22:54:41 -0500 Subject: [ppml] Fw: IRS goes IPv6! In-Reply-To: <75cb24520602201721h71501d9gbdbc281dc1fe894d@mail.gmail.com > References: <75cb24520602201721h71501d9gbdbc281dc1fe894d@mail.gmail.com> Message-ID: <7.0.1.0.0.20060220224636.01b0b960@renesys.com> At 08:21 PM 2/20/2006, Christopher Morrow wrote: >Folks like DISA might have use for a /32 on a network NOT CONNECTED to >the Internet of course, which brings up another discussion entirely :) >Though, DISA is the DoD's "official NSP" as I recall... DISA is a very large service provider based on advertised space[1]. I also see the Interior Service as one of the fastest growing providers, although I'm guessing it's the age old bjork-ness at the Park Service. Classifying by status doesn't seem to make a lot of sense based on the data I'm looking at. Not because it's provider centric, but because you don't have to be a provider, per se, to make the "top $" list. -M< 1. Our databases. From terry.l.davis at boeing.com Tue Feb 21 00:41:19 2006 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Mon, 20 Feb 2006 21:41:19 -0800 Subject: [ppml] Fw: IRS goes IPv6! Message-ID: <0D090F1E0F5536449C7E6527AFFA280A21BB67@XCH-NW-8V1.nw.nos.boeing.com> Randy And yup they are moving to "internet"; it'll just take a few years assuming you all want to always have global "air traffic management" system in place, up and operational. Since I fly a lot, I tend to like that idea.. Take care Terry -----Original Message----- From: Randy Bush [mailto:randy at psg.com] Sent: Monday, February 20, 2006 4:44 PM To: Davis, Terry L Cc: Daniel Golding; Stephen Sprunk; Rob Seastrom; PPML Subject: Re: [ppml] Fw: IRS goes IPv6! > I would hope that no one questioned whether SITA, Arinc, and Inmarsat > were "service providers"! definitely not, along with the us post, ups, and consolidated freightways just in case you missed it, the "i" in "arin" stands for "internet" randy From christopher.morrow at gmail.com Tue Feb 21 02:12:35 2006 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Tue, 21 Feb 2006 07:12:35 +0000 Subject: [ppml] Fw: IRS goes IPv6! In-Reply-To: <7.0.1.0.0.20060220224636.01b0b960@renesys.com> References: <75cb24520602201721h71501d9gbdbc281dc1fe894d@mail.gmail.com> <7.0.1.0.0.20060220224636.01b0b960@renesys.com> Message-ID: <75cb24520602202312h5722ef35m9ecc86065d988ffd@mail.gmail.com> On 2/21/06, Martin Hannigan wrote: > At 08:21 PM 2/20/2006, Christopher Morrow wrote: > > > >Folks like DISA might have use for a /32 on a network NOT CONNECTED to > >the Internet of course, which brings up another discussion entirely :) > >Though, DISA is the DoD's "official NSP" as I recall... > > > DISA is a very large service provider based on advertised > space[1]. > > I also see the Interior Service as one of the fastest growing > providers, although I'm guessing it's the age old bjork-ness at the > Park Service. actually, Interior just got the greenlight from GAO to re-enter the 20'th century and re-connect to the Internet didn't they? Perhaps that's a reason for the growth curve? Either way, they too have a very large internal network... From Michael.Dillon at btradianz.com Tue Feb 21 05:46:47 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 21 Feb 2006 10:46:47 +0000 Subject: [ppml] Fw: IRS goes IPv6! In-Reply-To: <17402.25197.986039.98079@roam.psg.com> Message-ID: > > I would hope that no one questioned whether SITA, Arinc, and Inmarsat > > were "service providers"! > > definitely not, along with the us post, ups, and consolidated freightways > > just in case you missed it, the "i" in "arin" stands for "internet" And in case you missed it, we have only 6 years supply of IPv4 addresses left. http://www.potaroo.net/tools/ipv4/index.html We should be applauding any organization that is taking the initiative to implement IPv6 and we should be making it easy for these organizations to get the IPv6 addresses that they want. There is no shortage of IPv6 addresses in the foreseeable future. If an organization with multiple sites considers themselves to be a network operator, give them a /32. But let's not stop there. Let's do direct allocations to smaller organizations with multiple sites. Let's allocate one /48 per site to any organization that has the intention of multihoming their Internet connectivity using IPv6. We have the addresses to spare so why skimp at this stage? It makes sense to round up allocations to nibble boundaries such as /44, /40, and /36 because there is no shortage of IPv6 addresses. There is no good reason to hold back on this. Anybody who points to problems with the global routing table is missing the point. ARIN does not mandate how ISPs operate and it does not mandate how end users contract for ISP services. If ARIN actions create a problem between ISPs and their customers then let the ISPs and their customer solve the problem, not ARIN. There are far more intelligent and creative people available in the ISPs and the end user organizations so let us not try to patronize them by telling them that /48 route announcements cannot work. --Michael Dillon From hannigan at renesys.com Tue Feb 21 08:08:30 2006 From: hannigan at renesys.com (Martin Hannigan) Date: Tue, 21 Feb 2006 08:08:30 -0500 Subject: [ppml] Fw: IRS goes IPv6! In-Reply-To: <75cb24520602202312h5722ef35m9ecc86065d988ffd@mail.gmail.co m> References: <75cb24520602201721h71501d9gbdbc281dc1fe894d@mail.gmail.com> <7.0.1.0.0.20060220224636.01b0b960@renesys.com> <75cb24520602202312h5722ef35m9ecc86065d988ffd@mail.gmail.com> Message-ID: <7.0.1.0.0.20060221075627.01af02f0@renesys.com> At 02:12 AM 2/21/2006, Christopher Morrow wrote: >On 2/21/06, Martin Hannigan wrote: > > At 08:21 PM 2/20/2006, Christopher Morrow wrote: > > > > > > >Folks like DISA might have use for a /32 on a network NOT CONNECTED to > > >the Internet of course, which brings up another discussion entirely :) > > >Though, DISA is the DoD's "official NSP" as I recall... > > > > > > DISA is a very large service provider based on advertised > > space[1]. > > > > I also see the Interior Service as one of the fastest growing > > providers, although I'm guessing it's the age old bjork-ness at the > > Park Service. > >actually, Interior just got the greenlight from GAO to re-enter the >20'th century and re-connect to the Internet didn't they? Perhaps >that's a reason for the growth curve? Either way, they too have a very >large internal network... I dont doubt it. I remember them popping up in the CIDR report before they got shut down. That problem is an operator problem. In the top 100 global, all are service providers and the 1 Gov entity. In the top 100 North America, all are service providers and 3 Gov entities. The classical definition of service provider is safe for now. -M< -- Martin Hannigan (c) 617-388-2663 Renesys Corporation (w) 617-395-8574 Member of Technical Staff Network Operations hannigan at renesys.com From Lee.Howard at stanleyassociates.com Tue Feb 21 09:44:07 2006 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Tue, 21 Feb 2006 09:44:07 -0500 Subject: [ppml] Fw: IRS goes IPv6! Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB4015C438E@CL-S-EX-1.stanleyassociates.com> > Behalf Of Daniel Golding > ARIN needs to > come up with a real definition for a service provider, or at > least have some > clear examples for their folks to use as a guideline. Send words. Lee From chuegen at cisco.com Tue Feb 21 16:09:57 2006 From: chuegen at cisco.com (Craig Huegen (chuegen)) Date: Tue, 21 Feb 2006 16:09:57 -0500 Subject: [ppml] Fw: IRS goes IPv6! Message-ID: Chris Morrow wrote: > what's interesting is that USPS (for instance) has disparate points of > presense, not always with 'internal' connnectivity. So, even with a > /32 they have to either: 1) use PA space inn some locations > 2) setup a full back-side/internal network and route accordingly > 3) convince everyone to leak /48's around As another example, Cisco IT's network is arranged in the same way: it uses regional addressing and announces only a portion of its total address space from various points of presence. Some enterprises can get around this by using consistent vendors around the globe; announcing more regional specifics with no-export provisions and the larger block for export. There are some important restrictions using this model, but it does allow chunks to be sub-divided and regionalized by the enterprise network. /cah --- Craig A. Huegen, IT Solutions Architect C i s c o S y s t e m s IT - Intelligent Network Solutions || || Cisco Systems, Inc., 400 East Tasman Drive || || San Jose, CA 95134, (408) 526-8104 |||| |||| email: chuegen at cisco.com CCIE #2100 ..:||||||:..:||||||:.. From chuegen at cisco.com Tue Feb 21 16:36:55 2006 From: chuegen at cisco.com (Craig Huegen (chuegen)) Date: Tue, 21 Feb 2006 16:36:55 -0500 Subject: [ppml] Fw: IRS goes IPv6! Message-ID: Michael Dillon wrote: > Anybody who points to problems with the global routing table > is missing the point. ARIN does not mandate how ISPs operate > and it does not mandate how end users contract for ISP services. > If ARIN actions create a problem between ISPs and their customers > then let the ISPs and their customer solve the problem, not ARIN. > There are far more intelligent and creative people available > in the ISPs and the end user organizations so let us not try > to patronize them by telling them that /48 route announcements cannot > work. I respectfully disagree. The reason for an organization to get space under this policy is so they can use it... Most organizations looking for space from ARIN aren't doing it for internal-only use -- they expect to be connected to the IPv6 Internet. As such, policies need to be congruent with expectations and best practice. Sticking our collective heads into the sand and claiming it is someone else's problem to solve is contrary to that congruency. Perhaps market conditions (prefix count settlements between peers, etc.) might change in the future, but for now that's where we stand. As such, I cannot advocate such a policy. It is likely to create a TWD or swamp of relatively large proportions as every man, woman, and child makes a run on IPv6 address space. The goal of a small routing table must remain; there are some great technology ideas behind that goal. A policy for PI space must support reasonable adoption today where renumbering costs are very high, while balancing the future solution space for multihoming using PA-oriented locators to maintain scalable routing tables. /cah --- Craig A. Huegen, IT Solutions Architect C i s c o S y s t e m s IT - Intelligent Network Solutions || || Cisco Systems, Inc., 400 East Tasman Drive || || San Jose, CA 95134, (408) 526-8104 |||| |||| email: chuegen at cisco.com CCIE #2100 ..:||||||:..:||||||:.. From Michael.Dillon at btradianz.com Wed Feb 22 04:51:19 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 22 Feb 2006 09:51:19 +0000 Subject: [ppml] Fw: IRS goes IPv6! In-Reply-To: Message-ID: > As such, I cannot advocate such a policy. It is likely to create a TWD > or swamp of relatively large proportions as every man, woman, and child > makes a run on IPv6 address space. Here we go again. Somebody declares that a policy will create a swamp and that is a bad thing. But no definition is offered for the term "swamp" except a cryptic acronym. All I know about IPv4 is that there was a swamp and it must have been a good thing because it happened during the exponential growth phase of the IPv4 network when the Internet moved out of the universities and laboratories to become a USEFUL NETWORK for businesses and ordinary folks. If we need a swamp to do that, then I vote for this swamp thingy, whatever it is. > The goal of a small routing table > must remain; there are some great technology ideas behind that goal. We all know that ISPs control the size of their routing table through BGP filters. ARIN does not need to be concerned with limiting the size of this table through policy. IP address blocks are useful even if they do not appear in every ISP's routing table. Not all companies require global connectivity. For instance, in China many businesses are satisfied if they have access to the national Internet. And in America many ISPs are satisfied if they have access to an Internet that does not include China. Those are the facts of Internet life today. ARIN policies cannot mandate anyone to accept a route prefix and the techniques of BGP routing are so complex, that it is madness for ARIN to try to predict how ISPs will react to a particular ARIN policy. ARIN exists to serve the public, not to serve ISPs. If there is public demand for IP address allocations direct from ARIN then we must meet that demand until such time as it is demonstrated that such address prefixes are useless. --Michael Dillon From narten at us.ibm.com Wed Feb 22 07:44:10 2006 From: narten at us.ibm.com (Thomas Narten) Date: Wed, 22 Feb 2006 07:44:10 -0500 Subject: [ppml] Fw: IRS goes IPv6! In-Reply-To: Message from Michael.Dillon@btradianz.com of "Wed, 22 Feb 2006 09:51:19 GMT." Message-ID: <200602221244.k1MCiAUB030102@cichlid.raleigh.ibm.com> Michael.Dillon at btradianz.com writes: > > The goal of a small routing table > > must remain; there are some great technology ideas behind that goal. > We all know that ISPs control the size of their routing > table through BGP filters. ARIN does not need to be concerned > with limiting the size of this table through policy. Sorry, this is nonsense, and saying it over and over again doesn't make it otherwise. I'm tempted to say something about not worrying about passing laws that defy physics, under the theory that physics is a problem for someone other than lawmakers to worry about... If the routing table gets too big, ISPs will be forced to take steps, like impose filters. When that happens, somebody loses. I.e., somebody's connectivity can go away. If there are steps that ARIN can take (when making policy) that significantly reduce the odds that this will happen, or that help ensure that there alternative mechanisms in place so that those losing connectivity are not left out in the cold, we should take them. That is what this discussion is all about. How can we introduce PI assignments to end sites without opening the door so wide that we create a mess we don't really know how (from an operations and technology perspective) to handle? Saying we don't have to worry about this problem one iota is not helpful, because it is rather clear that a significant chunk of the community _is_ concerned about this issue (even if you are not). > Those are the facts of Internet life today. ARIN policies > cannot mandate anyone to accept a route prefix Correct. But at the same time, it would serious foolishness to adopt policies that are likely to cause significant problems down the road for which we do not have a reasonable fix. In other words, ARIN should not adopt a policy in which users assume they are getting a routable address block, when in fact, there is a real possibility that it will not be routable in the future. > ARIN exists to serve the public, not to serve ISPs. It is really unhelpful to couch this in "public" vs. "ISP" tones, since things are not that simple. I care about having an Internet that works (for everyone) and having a bloated route table in which ISPs are forced to filter with the end result being loss of connectivity for certain classes of end users is not something I want to see happen and is not something I believe would serve the public. Thomas From Michael.Dillon at btradianz.com Wed Feb 22 09:00:32 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 22 Feb 2006 14:00:32 +0000 Subject: [ppml] Fw: IRS goes IPv6! In-Reply-To: <200602221244.k1MCiAUB030102@cichlid.raleigh.ibm.com> Message-ID: > In other words, ARIN should > not adopt a policy in which users assume they are getting a routable > address block, when in fact, there is a real possibility that it will > not be routable in the future. Routability is not a feature that ARIN includes with address blocks today. In particular NPRM 4.4 offers /24 microallocations of IPv4 space when it is known that ISPs do filter /24 prefix lengths. In addition, some applicants for address space have no intention of announcing it on the global Internet and therefore routability is not an issue. In the past, when ARIN reduced the initial ISP allocation from /19 to /20, the /20 prefixes were NOT routable because many ISPs filtered such prefixes. Within a short time after ARIN changed the policy, ISPs adjusted their filtering to make the addresses routable. Thus, I believe that routability should not be a responsible of ARIN but should be left squarely in the hands of the ISPs. If I understand the substance of the routability argument, it is that if ARIN gives out lots of small IPv6 PI allocations then each one of these allocations will use up a routing table slot. At some point in time, too many slots will be used up and ISPs will be forced to remove the ROUTABILITY feature for many of these addresses. The question that we have to ask, as policymakers, is can we mitigate against this eventuality in our policy. The answer is cleary, YES WE CAN. The only reason why each one of these small allocations would need a slot in the routing table is because ARIN allocates them more-or-less at random, first come, first served. If, however, ARIN would allocate such addresses in a way that they could be agregated into a smaller number of routing table slots and still maintain routability, then the policy problem is solved. I suggest that the ARIN region be divided as follows Northwest Central Plains Northern Midwest Northeast Northern Calif. DC and region Southern Calif. Southwest Southern Midwest Southeast IPv6 PI allocations will be allocated out of larger reserved blocks so that they can be aggregated under the larger regional block. The following explains the boundaries of the regions. Northwest (Oregon, Washington, Idaho, British Columbia, Alaska, Yukon) Central Plains (Alberta, Saskatchewan, Manitoba, Northwest Terr., Nunavut, Great Plains states) Southwest (Nevada, Arizona, NM, Texas) Northern Midwest (Chicago and surrounding states) Southern Midwest (St. Louis and surrounding states) Southeast (American Southeast plus Caribbean) Rather than worry about precise boundary lines for these regions, ARIN should suggest the region to the applicant and ask their approval. Of course, the concept of aggregation of addresses based on the geographical location of their upstream ISP's PoP should be explained. > > ARIN exists to serve the public, not to serve ISPs. > > It is really unhelpful to couch this in "public" vs. "ISP" tones, > since things are not that simple. I care about having an Internet that > works (for everyone) and having a bloated route table in which ISPs > are forced to filter with the end result being loss of connectivity > for certain classes of end users is not something I want to see happen > and is not something I believe would serve the public. Of course a bloated routing table would not serve the public but it also does not serve the public when ISPs pretend that the routing technology used today is unable to solve this problem. The problem IS SOLVABLE and if customers demand it then ISPs will solve it. --Michael Dillon From jeroen at unfix.org Wed Feb 22 09:12:45 2006 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 22 Feb 2006 15:12:45 +0100 Subject: [ppml] Fw: IRS goes IPv6! In-Reply-To: References: Message-ID: <1140617566.1227.67.camel@firenze.zurich.ibm.com> On Wed, 2006-02-22 at 14:00 +0000, Michael.Dillon at btradianz.com wrote: > > In other words, ARIN should > > not adopt a policy in which users assume they are getting a routable > > address block, when in fact, there is a real possibility that it will > > not be routable in the future. > > Routability is not a feature that ARIN includes with address > blocks today. [..] No RIR guarantees routability. RIPE at least has a beacon project to give it a try, but none of them guarantee anything. > If I understand the substance of the routability argument, it > is that if ARIN gives out lots of small IPv6 PI allocations then > each one of these allocations will use up a routing table slot. > At some point in time, too many slots will be used up and ISPs > will be forced to remove the ROUTABILITY feature for many of these > addresses. That is indeed the substance. To solve this 'easy' and sort of future-proof, having a special /16 or similar where /48's to end-sites can be allocated from for routing or non-routable purposes already solves the problem. When there are too many routing slots this /16 can be filtered out by ISP's who don't want to see it, the only thing is that the end site (and it's peers) will have to start using something like shim6 then to overcome this... [..] > I suggest that the ARIN region be divided as follows The big problem with geo-addressing (which is more or less what you mean here) is the big question: Who pays for what traffic and when. Next to that people tend to want to do traffic engineering and other tricks which are not easily applicable to Geo PI setups. Also see Tony Hain's document about Geo PI (draft-hain-ipv6-pi-addr-*). Greets, Jeroen PS: Micheal, could you keep attribution for replies you make to people that would make following the thread much easier instead having to look up who actually said what on what you are replying to. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 240 bytes Desc: This is a digitally signed message part URL: From narten at us.ibm.com Wed Feb 22 09:14:32 2006 From: narten at us.ibm.com (Thomas Narten) Date: Wed, 22 Feb 2006 09:14:32 -0500 Subject: [ppml] Fw: IRS goes IPv6! In-Reply-To: Message from Michael.Dillon@btradianz.com of "Wed, 22 Feb 2006 14:00:32 GMT." Message-ID: <200602221414.k1MEEWBB032281@cichlid.raleigh.ibm.com> Michael.Dillon at btradianz.com writes: > > In other words, ARIN should > > not adopt a policy in which users assume they are getting a routable > > address block, when in fact, there is a real possibility that it will > > not be routable in the future. > Routability is not a feature that ARIN includes with address > blocks today. ARIN makes no guarantees (as it can't). But that does not mean that there aren't general expectations, or that the adopted policies are understood to have certain (general) results. We shoudl not be blind to the implications or consequences of our policies. > If I understand the substance of the routability argument, it > is that if ARIN gives out lots of small IPv6 PI allocations then > each one of these allocations will use up a routing table slot. > At some point in time, too many slots will be used up and ISPs > will be forced to remove the ROUTABILITY feature for many of these > addresses. Bingo! > The question that we have to ask, as policymakers, is can we mitigate > against this eventuality in our policy. The answer is cleary, > YES WE CAN. Small correction: You believe we can. Unfortunately, others are not convinced. I certainly have some doubts. Rather than to continue shouting "YES WE CAN", I'd suggest listening to what others are saying and try to work through the implications of that. > The only reason why each one of these small allocations > would need a slot in the routing table is because ARIN allocates > them more-or-less at random, first come, first served. If, however, > ARIN would allocate such addresses in a way that they could be agregated > into a smaller number of routing table slots and still maintain > routability, then the policy problem is solved. In order for these prefixes to be aggregated, you'd have to convince ISPs to aggregate them and carry traffic for the aggregates. Smells a bit like ARIN telling ISPs what to do. You are also reinventing geographical addressing (or metro, or whatever variant it is). Again, this is an old horse, on which the community does not have agreement that it solves the problem. Or rather, agreement that ISPs would ever agree to adopt such an approach. Saying it obviously solves the problem, when others continue to point out serious issues with actually deploying such an approach, isn't helpful. > Of course a bloated routing table would not serve the public > but it also does not serve the public when ISPs pretend that > the routing technology used today is unable to solve this > problem. The problem IS SOLVABLE and if customers demand it > then ISPs will solve it. You are much more optimistic than I. I'd prefer to actually see a viable approach (or outline of an approach) than just assume "we'll figure it out somehow." Been there, done that. Thomas From Michael.Dillon at btradianz.com Wed Feb 22 09:35:50 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 22 Feb 2006 14:35:50 +0000 Subject: [ppml] Fw: IRS goes IPv6! In-Reply-To: <1140617566.1227.67.camel@firenze.zurich.ibm.com> Message-ID: > > I suggest that the ARIN region be divided as follows > > The big problem with geo-addressing (which is more or less what you mean > here) is the big question: Who pays for what traffic and when. Next to > that people tend to want to do traffic engineering and other tricks > which are not easily applicable to Geo PI setups. It is not for ARIN to say who pays for what. All we can do is to create the possibility and then it is up to the public whether or not they want to solve the other issues. > Also see Tony Hain's document about Geo PI (draft-hain-ipv6-pi-addr-*). Tony's document and my suggestion are just about diametrically opposed. He wants to encode physical location in IPv6 addresses. I don't care about encoding anything more than the general vicinity of the address user and I only want to do that because users in the same general vicinity have the possibility of easily building a network architecture that allows aggregation of that vicinity into a route announcement. In fact, if the end user believes that an address from the neighboring vicinity would serve them better, then I am happy for ARIN to give them that address. As long as the end user knows the purpose of assigning addresses out of a reserved block for their geographical region, then I am willing to let them choose. > PS: Micheal, could you keep attribution for replies you make to people > that would make following the thread much easier instead having to look > up who actually said what on what you are replying to. Sorry, but I don't care who said what. I'm interested in ideas, not personalities and popularity contests. I strip out everything that I feel is unecessary to maintain the context. In fact, by the end of my message, I have usually forgotten whose words I am replying to. --Michael Dillon From Michael.Dillon at btradianz.com Wed Feb 22 09:40:50 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 22 Feb 2006 14:40:50 +0000 Subject: [ppml] Fw: IRS goes IPv6! In-Reply-To: <200602221414.k1MEEWBB032281@cichlid.raleigh.ibm.com> Message-ID: > You are much more optimistic than I. I'd prefer to actually see a > viable approach (or outline of an approach) than just assume "we'll > figure it out somehow." Been there, done that. Then you are asking for ARIN to be the IETF. Sorry to disappoint you but that is not in our charter. I am merely suggesting an intelligent algorithm for allocating these IPv6 PI blocks. It is within ARIN's power to adopt a particular algorithm and to request, from IANA, the address space needed to manage the address space according to a new algorithm. It has been done before. --Michael Dillon From alh-ietf at tndh.net Wed Feb 22 15:47:31 2006 From: alh-ietf at tndh.net (Tony Hain) Date: Wed, 22 Feb 2006 12:47:31 -0800 Subject: [ppml] Fw: IRS goes IPv6! In-Reply-To: <17402.25197.986039.98079@roam.psg.com> Message-ID: <016a01c637f1$337c7bc0$d247190a@tndh.net> Randy Bush wrote: > > I would hope that no one questioned whether SITA, Arinc, and Inmarsat > > were "service providers"! > > definitely not, along with the us post, ups, and consolidated freightways > > just in case you missed it, the "i" in "arin" stands for "internet" Precluding organizations from entering a different business than they traditionally operate is consider restraint of trade... From alh-ietf at tndh.net Wed Feb 22 15:45:22 2006 From: alh-ietf at tndh.net (Tony Hain) Date: Wed, 22 Feb 2006 12:45:22 -0800 Subject: [ppml] Fw: IRS goes IPv6! In-Reply-To: Message-ID: <016601c637f0$e76dcf90$d247190a@tndh.net> Michael.Dillon wrote: > Tony's document and my suggestion are just about diametrically > opposed. He wants to encode physical location in IPv6 addresses. > I don't care about encoding anything more than the general > vicinity of the address user and I only want to do that because > users in the same general vicinity have the possibility of > easily building a network architecture that allows aggregation > of that vicinity into a route announcement. In fact, if the > end user believes that an address from the neighboring vicinity > would serve them better, then I am happy for ARIN to give them > that address. As long as the end user knows the purpose of > assigning addresses out of a reserved block for their geographical > region, then I am willing to let them choose. The approaches are not all that different. Other proposals based on cities have been floated. In a PSTN context yours is effectively an area-code where previous ones have been city-code. The details about how the addresses are handed out are minor in context. The real issue with any geo approach is that providers have to interconnect and hand off the traffic they picked up via the aggregate to the carrier that has the customer. This is a telco business model and the 'ISPs are different' mindset refuses to go there. My approach of going to /48 essentially pre-allocates space so there is no continuing need to justify or otherwise deal with process. It is completely devoid of political context so it is not subject to population shifts or the whims of the UN. If continuing justification is a goal, then stopping at a /12 would create the prefixes that fit your regional model. The biggest thing to keep in mind is that while this discussion is occurring in the ARIN region, there are global implications. It really doesn't help if ARIN adopts a PI based on area-codes while China and/or India put 1B PI entries into their BGP announcements. We don't have to have a single global approach to PI, but this is a difficult enough problem that reinventing for use outside the ARIN region doesn't make sense. Tony From randy at psg.com Wed Feb 22 16:15:24 2006 From: randy at psg.com (Randy Bush) Date: Wed, 22 Feb 2006 11:15:24 -1000 Subject: [ppml] Fw: IRS goes IPv6! References: <17402.25197.986039.98079@roam.psg.com> <016a01c637f1$337c7bc0$d247190a@tndh.net> Message-ID: <17404.54380.929460.317985@roam.psg.com> >>> I would hope that no one questioned whether SITA, Arinc, and Inmarsat >>> were "service providers"! >> >> definitely not, along with the us post, ups, and consolidated freightways >> >> just in case you missed it, the "i" in "arin" stands for "internet" > > Precluding organizations from entering a different business than they > traditionally operate is consider restraint of trade... then you should not preclude them, tony. that would be bad of you. even worse than accusing others of saying what they did not. blechhh From alh-ietf at tndh.net Wed Feb 22 16:35:51 2006 From: alh-ietf at tndh.net (Tony Hain) Date: Wed, 22 Feb 2006 13:35:51 -0800 Subject: [ppml] Fw: IRS goes IPv6! In-Reply-To: <17404.54380.929460.317985@roam.psg.com> Message-ID: <020801c637f7$f3e9e680$d247190a@tndh.net> You effectively said they would not be considered 'service providers' when applying for IPv6 space because they do not currently operate using the 'internet' protocol (implies IPv4). They are clearly providing a service that interconnects multiple customers, so their crime of historically using a different protocol appears to be excluding them from the club with access to address space for the new protocol. > -----Original Message----- > From: Randy Bush [mailto:randy at psg.com] > Sent: Wednesday, February 22, 2006 1:15 PM > To: Tony Hain > Cc: 'Davis, Terry L'; 'Rob Seastrom'; 'PPML' > Subject: RE: [ppml] Fw: IRS goes IPv6! > > >>> I would hope that no one questioned whether SITA, Arinc, and Inmarsat > >>> were "service providers"! > >> > >> definitely not, along with the us post, ups, and consolidated > freightways > >> > >> just in case you missed it, the "i" in "arin" stands for "internet" > > > > Precluding organizations from entering a different business than they > > traditionally operate is consider restraint of trade... > > then you should not preclude them, tony. that would be bad of you. > even worse than accusing others of saying what they did not. > > blechhh From randy at psg.com Wed Feb 22 16:42:14 2006 From: randy at psg.com (Randy Bush) Date: Wed, 22 Feb 2006 11:42:14 -1000 Subject: [ppml] Fw: IRS goes IPv6! References: <17404.54380.929460.317985@roam.psg.com> <020801c637f7$f3e9e680$d247190a@tndh.net> Message-ID: <17404.55990.895908.641846@roam.psg.com> > You effectively said they would not be considered 'service providers' when > applying for IPv6 space because they do not currently operate using the > 'internet' protocol (implies IPv4). s/implies/you imply/ > They are clearly providing a service that interconnects multiple > customers, so their crime of historically using a different > protocol appears to be excluding them from the club with access > to address space for the new protocol. what ever are you smoking? we have pretty good policies where folk who actually need internet address space get it according to their needs. having four wheeled vehicles that go between places is currently not in the set of methods used to justify those needs. if you think that trucking should be part of the ipv6 address architecture, then the ivtf would be a great place to discuss that, as ops clue and simplicity would get in the way. randy >> -----Original Message----- >> From: Randy Bush [mailto:randy at psg.com] >> Sent: Wednesday, February 22, 2006 1:15 PM >> To: Tony Hain >> Cc: 'Davis, Terry L'; 'Rob Seastrom'; 'PPML' >> Subject: RE: [ppml] Fw: IRS goes IPv6! >> >> >>> I would hope that no one questioned whether SITA, Arinc, and Inmarsat >> >>> were "service providers"! >> >> >> >> definitely not, along with the us post, ups, and consolidated >> freightways >> >> >> >> just in case you missed it, the "i" in "arin" stands for "internet" >> > >> > Precluding organizations from entering a different business than they >> > traditionally operate is consider restraint of trade... >> >> then you should not preclude them, tony. that would be bad of you. >> even worse than accusing others of saying what they did not. >> >> blechhh From randy at psg.com Wed Feb 22 12:02:55 2006 From: randy at psg.com (Randy Bush) Date: Wed, 22 Feb 2006 07:02:55 -1000 Subject: [ppml] RIPE 2005-01 - Last Call for Comments (HD-ratio Proposal) Message-ID: <17404.39231.284858.924259@roam.psg.com> the stunning paragraph is From the simulations of registry allocations, the use of an HD Ratio of 0.96 for IPv4 address allocations made by the RIPE NCC is predicted to increase total address consumption by 46% over the existing flat 80% utilization allocation policy framework. randy --- From: Geoff Huston To: address-policy-wg at ripe.net Cc: gih at apnic.net Subject: Re: [address-policy-wg] 2005-01 - Last Call for Comments (HD-ratio Proposal) Date: Wed, 22 Feb 2006 19:44:06 +1100 Here is the promised report on the address consumption implications of the policy proposal 2005-1 (HD-Ratio Proposal) If there is any other aspect of implications of adoption of this proposal that folk may want investigated I'd be happy to see what I can do. Also if any part of this report is unclear I'd be happy to attempt to clarify further the process I've used here. I trust that this report is helpful in terms of assessing some of the impacts of the proposal. regards, Geoff Huston An Analysis of the Sensitivity of using the HD Ratio for IPv4 Address Allocations Geoff Huston V1.0 22 February 2005 This document describes the outcomes of an analytical process intended to describe the sensitivity of the use of HD Ratio metrics as the means of assessing address utilization efficiency, and the relation between the use of HD Ratio values and projected lifetimes of the unallocated IPv4 address pool. This document is a commentary on RIPE Policy Proposal 2005-1 1. Methodology -------------- The methodology used here uses only published RIR allocation data. The primary data source for RIPE NCC data is the delegated file: ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-latest All IPv4 allocation records with an allocation date on or after 1-Jan-2000 are collected. The allocation sizes are rounded up to the next largest power of 2, or 256, which is the greatest. The relative proportion of each allocation size is also calculated. This is shown in the table below (Table 1). ---------------------------------------------------------------- Table 1 - RIPE NCC IPV4 Address Allocations (since 1-Jan-2000) Size Number Relative Cumulative Frequency Relative Frequency /24 2637 23.04 23.04 /23 1383 12.09 35.13 /22 934 8.16 43.29 /21 545 4.76 48.06 /20 2247 19.64 67.69 /19 1713 14.97 82.66 /18 784 6.85 89.51 /17 407 3.56 93.07 /16 499 4.36 97.43 /15 135 1.18 98.61 /14 75 0.66 99.27 /13 44 0.38 99.65 /12 21 0.18 99.83 /11 15 0.13 99.97 /10 4 0.03 100.00 ---------------------------------------------------------------- The assumption made here is that these allocations are made under a policy of a uniform 80% utilization efficiency. From this can be calculated the inferred maximum end use count for each prefix size (Table 2). ---------------------------------------------------------------- Table 2 - Inferred Maximum End Population Count for each Prefix Size under the uniform 80% efficiency policy /24 205 /23 410 /22 819 /21 1638 /20 3277 /19 6554 /18 13107 /17 26214 /16 52429 /15 104858 /14 209715 /13 419430 /12 838861 /11 1677722 /10 3355443 /9 6710886 /8 13421773 ---------------------------------------------------------------- The HD ratio is calculated by the function: HD = log(used)/log(addresses). This implies that the population can be inferred for any given prefix size using the equation: used = 10**(HD x log_base_10(addresses). The inferred maximum end use count for each prefix size using an HD Ratio value of 0.96 is shown below (Table 3). ---------------------------------------------------------------- Table 3 - Inferred Maximum End Population Count for each Prefix Size under an HD = 0.96 allocation policy /24 205 /23 399 /22 776 /21 1510 /20 2937 /19 5713 /18 11113 /17 21619 /16 42055 /15 81811 /14 159147 /13 309590 /12 602249 /11 1171560 /10 2279048 /9 4433455 /8 8624444 ---------------------------------------------------------------- The next step is to determine the relative impact on address consumption by changing from a uniform 80% utilization efficiency metric to one determined by an HD Ratio setting of 0.96. To do this a sequence of 10,000 allocations are simulated. with each allocation being in the range of a /24 to a /10 prefix. with a probability of any particular prefix being selected based on the relatively frequency distribution of Table 1. The inferred population lies between the maximum population of this prefix and that of the population of the next smaller prefix in Table 2. A random value is drawn from this population range (this is a uniform probability selection between the two extreme population values, so that any population value is equally likely to be selected). This population value is used as a lookup key into Table 3, and the next highest population count is used to determine the equivalent HD Ratio allocated prefix. In effect, this approach generates a series of demand populations that would generate the existing RIR allocation prefix distribution, and then uses this population set to generate a HD-Ratio- based set of allocations that would correspond to this population distribution. The total amount of allocated address space is calculated in each case, and the ratio of the two address pool sizes is recorded. This experiment has been repeated 1,000 times in order to determine a stable average value for the relative increase in address consumption corresponding to a change in the address allocation policies from uniform 80% to an HD Ratio of 0.96, assuming constant demand for addresses. This relative change in address demands can then be added into the IPv4 address consumption projection (see http://ipv4.potaroo.net). The change here is in the simulation of the address consumption model, where in the base model all RIR's are assumed to be operating a uniform address efficiency metric of a uniform 80% utilization target. The same exponential growth model in advertised address growth is used, but this model is augmented by the relative increase in address consumption as contributed by the HD Ratio allocation metric. The unadvertised address ratio is then derived from this higher advertised address count, and this, in turn, generates a more rapid overall address consumption model. The measure under investigation in this case is the change in predicted date of the exhaustion of the IANA unallocated address pool 2. Results --------- The relative distribution of allocated prefixes by the RIPE NCC using an HD Ratio of 0.96 as an allocation efficiency metric would be as shown in Table 4. ---------------------------------------------------------------- Table 4 - RIPE NCC IPV4 Address Allocations Size 2000-2006 HD Ratio Relative Relative Frequency Frequency /24 23.04 23.23 /23 12.09 11.37 /22 8.16 7.87 /21 4.76 4.85 /20 19.64 16.33 /19 14.97 15.21 /18 6.85 8.58 /17 3.56 4.39 /16 4.36 3.88 /15 1.18 2.39 /14 0.66 0.86 /13 0.38 0.50 /12 0.18 0.28 /11 0.13 0.15 /10 0.03 0.09 /9 0.00 0.02 /8 0.00 0.00 ---------------------------------------------------------------- >From the simulations of registry allocations, the use of an HD Ratio of 0.96 for IPv4 address allocations made by the RIPE NCC is predicted to increase total address consumption by 46% over the existing flat 80% utilization allocation policy framework. The current prediction for the data of exhaustion of the IANA unallocated address pool is 12 January 2012, assuming, among other factors, a continued application of the constant 80% address utilization metric. If the RIPE NCC were to adopt an allocation policy of using an HD Ratio of 0.96 to access IPv4 address allocations, and no other changes were made to the mode, and no other RIRs were to adopt such a policy to use the HS Ratio as a utilization metric, then the impact on the predicted exhaustion date is an overall change in address consumption rates by approximately 17% (as the RIPE NCC is responsible for some 38% of all allocated IPv4 addresses), and a predicted unallocated IANA pool exhaustion date of 9 December 2010 under these conditions (or approximately 1 year earlier than the predictions using the current address allocation policy framework A related consideration is that of the adoption of such a policy proposal by all 5 RIRs. If this were the case, and the adoption of this policy was to be effective immediately, then the relative increase in overall address consumption for each RIR would be: Afrinic 39%, APNIC 47%, ARIN 46%, LACNIC 47%. The simulation of IPv4 address consumption under these conditions predicts that the IANA pool of unallocated addresses would be exhausted by 22 March 2010 (or approximately 2 years earlier than the predictions using the current address allocation policy framework). -------------------------------------------------- At 05:34 PM 21/02/2006, Geoff Huston wrote: >Hi, > >I was wondering if it would help to look at the potential impact of this policy on IPv4 address consumption predictions. I have built a model of projection IPv4 address consumption based on continuity of current address allocation policies http://ipv4.potaroo.net, and it may be useful to look at the impact of using the HD ratio on this model. I'll try and get some results posted by the end of this week on a simulation of the effects of adoption of this policy proposal > >thanks, > > Geoff > > > > >On 2/7/06, RIPE NCC Policy Coordinator <adrian at ripe.net> wrote: >PDP Number: 2005-01 >HD-ratio Proposal > >Dear Colleagues > >The proposal to change to RIPE Document ripe-324 is now at its final stage. > >You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2005-1.html > >Please e-mail any final comments about this proposal to address-policy-wg at ripe.net before 7 March 2006. > >We will publish the new policy after this date if we receive no objections. > >Regards > >Adrian Bedford >RIPE NCC From George.Kuzmowycz at aipso.com Wed Feb 22 10:54:28 2006 From: George.Kuzmowycz at aipso.com (George Kuzmowycz) Date: Wed, 22 Feb 2006 10:54:28 -0500 Subject: [ppml] Fw: IRS goes IPv6! Message-ID: Thomas Narten wrote on 02/22/2006 9:14 AM: > Michael.Dillon at btradianz.com writes: > >> > In other words, ARIN should >> > not adopt a policy in which users assume they are getting a routable >> > address block, when in fact, there is a real possibility that it will >> > not be routable in the future. > >> Routability is not a feature that ARIN includes with address >> blocks today. > > ARIN makes no guarantees (as it can't). But that does not mean that > there aren't general expectations, or that the adopted policies are > understood to have certain (general) results. We shoudl not be blind > to the implications or consequences of our policies. This is where the discussion gets interesting, at least to me. Are these "general expectations" or "understood results" handed down on stone tablets, or is there room for such expectations to change? I understand that "end-to-end" is dogma, but will the market continue to want that? If my business (an end-user customer) is willing to pay for an address allocation understanding that at some undefined time in the future its routability may become more problematic, is that a decision that ARIN policy will allow us to make? Should ARIN policy even speak to that issue? Perhaps the market will decide differently a few years from now, if or when routing tables become more bloated than then-prevalent hardware can handle. Again, ignoring the religious aspect of protocol design, if my business is perfectly happy with the idea that IPv4 or IPv6 or IPv8 packets cannot reach us from, say, China, and our packets cannot get there, will there be a viable business model and - perhaps more importantly - address assignment policies allowing the providing of that sort of connectivity? The instant question, I think, is should today's allocation policy proceed on the assumption that every packet will have to be able to reach every destination forever? Or can it say these ranges, or these sizes, may have a problem 5 years from now, caveat emptor? Isn't ARIN already telling ISP's what to do? From randy at psg.com Wed Feb 22 16:52:35 2006 From: randy at psg.com (Randy Bush) Date: Wed, 22 Feb 2006 11:52:35 -1000 Subject: [ppml] RIPE 2005-01 - Last Call for Comments (HD-ratio Proposal) References: <17404.39231.284858.924259@roam.psg.com> Message-ID: <17404.56611.260005.399929@roam.psg.com> to continue the thread From: Randy Bush To: Geoff Huston Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2005-01 - Last Call for Comments (HD-ratio Proposal) Date: Wed, 22 Feb 2006 07:00:43 -1000 > I trust that this report is helpful in terms of assessing some of the > impacts of the proposal. > > ... > > From the simulations of registry allocations, the use of an HD Ratio of > 0.96 for IPv4 address allocations made by the RIPE NCC is predicted to > increase total address consumption by 46% over the existing flat 80% > utilization allocation policy framework. YIKES!!!! and, aside from that, how was the play, mrs. lincoln? randy ----- Date: Thu, 23 Feb 2006 07:59:02 +1100 To: Randy Bush From: Geoff Huston Subject: Re: [address-policy-wg] 2005-01 - Last Call for Comments (HD-ratio Proposal) Cc: address-policy-wg at ripe.net At 04:00 AM 23/02/2006, Randy Bush wrote: > > I trust that this report is helpful in terms of assessing some of the > > impacts of the proposal. > > > > ... > > > > From the simulations of registry allocations, the use of an HD Ratio of > > 0.96 for IPv4 address allocations made by the RIPE NCC is predicted to > > increase total address consumption by 46% over the existing flat 80% > > utilization allocation policy framework. > >YIKES!!!! > >and, aside from that, how was the play, mrs. lincoln? I was also surprised by this number when I first saw it in the output. Looking behind this 46% number, the outcome is a result of the amplified effects of the HD Ratio for large allocations. 50% of this increased address consumption is in allocations of /9 and /10 prefixes, which only account for 1% of all actual allocations, but 20% of the allocated addresses. The other effect is a shift from /16 to /15 allocations in this HDR regime - /16s and /15s together contribute a further 15% to this increased address consumption. Here's the table that shows the shifts when using the HD Ratio (fixed width font will help here) Prefix RIPE NCC Equivalent Allocations Allocations 2000-2006 0.96 HD (Relative %) (Relative %) /24 23.04 23.23 /23 12.09 11.37 /22 8.16 7.87 /21 4.76 4.85 /20 19.64 16.33 /19 14.97 15.21 /18 6.85 8.58 /17 3.56 4.39 /16 4.36 3.88 /15 1.18 2.39 /14 0.66 0.86 /13 0.38 0.5 /12 0.18 0.28 /11 0.13 0.15 /10 0.03 0.09 /9 0 0.02 /8 0 0 Power of Address Address Difference Relative Relative Relative 2 Span Span Difference Address Address Actual HDR Span Span Actual HDR 8 5898 5947 49 0% 0% 0% 9 6190 5821 -369 0% 0% 0% 10 8356 8059 -297 0% 0% 0% 11 9748 9933 184 0% 1% 0% 12 80445 66888 -13558 -2% 4% 2% 13 122634 124600 1966 0% 7% 5% 14 112230 140575 28344 3% 6% 5% 15 116654 143852 27197 3% 6% 5% 16 285737 254280 -31457 -4% 15% 9% 17 154665 313262 158597 19% 8% 12% 18 173015 225444 52429 6% 9% 8% 19 199229 262144 62915 7% 11% 10% 20 188744 293601 104858 12% 10% 11% 21 272630 314573 41943 5% 15% 12% 22 125829 377487 251658 30% 7% 14% 23 0 167772 167772 20% 0% 6% 24 0 0 0 0% 0% 0% Total 1862005.76 2714237.44 852231.68 -------- From: Randy Bush To: Geoff Huston Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2005-01 - Last Call for Comments (HD-ratio Proposal) Date: Wed, 22 Feb 2006 11:35:26 -1000 > I was also surprised by this number when I first saw it in the output. > > Looking behind this 46% number, the outcome is a result of the amplified > effects of the HD Ratio for large allocations. 50% of this increased > address consumption is in allocations of /9 and /10 prefixes, which only > account for 1% of all actual allocations, but 20% of the allocated addresses. > > The other effect is a shift from /16 to /15 allocations in this HDR regime > - /16s and /15s together contribute a further 15% to this increased address > consumption. i.e., this is what the conservatives and smaller folk have been intuiting all along, the big players get more than a fair (as we think of it today) share and the small folk lose. grrrrrrrr. could we please add ppml at arin.net to the cc:s? thanks. randy ------- Date: Thu, 23 Feb 2006 08:29:30 +1100 To: Randy Bush From: Geoff Huston Subject: Re: [address-policy-wg] 2005-01 - Last Call for Comments (HD-ratio Proposal) Cc: address-policy-wg at ripe.net I should correct a typo in the note below. Under the HD scheme /9 and /10 allocation will account for 0.11% of the actual allocations, not 1% as I said below. This correction probably amplifies the comment that its the small number of large allocations that are critical in assessing the total impact of the HD Ratio framework. thanks, Geoff >I was also surprised by this number when I first saw it in the output. > >Looking behind this 46% number, the outcome is a result of the amplified >effects of the HD Ratio for large allocations. 50% of this increased >address consumption is in allocations of /9 and /10 prefixes, which only >account for 1% of all actual allocations, but 20% of the allocated addresses. > >The other effect is a shift from /16 to /15 allocations in this HDR regime >- /16s and /15s together contribute a further 15% to this increased >address consumption. -30- From alh-ietf at tndh.net Wed Feb 22 14:55:48 2006 From: alh-ietf at tndh.net (Tony Hain) Date: Wed, 22 Feb 2006 11:55:48 -0800 Subject: [ppml] Fw: IRS goes IPv6! In-Reply-To: <200602221414.k1MEEWBB032281@cichlid.raleigh.ibm.com> Message-ID: <014e01c637e9$fa44fa50$d247190a@tndh.net> Thomas Narten wrote: > > The only reason why each one of these small allocations > > would need a slot in the routing table is because ARIN allocates > > them more-or-less at random, first come, first served. If, however, > > ARIN would allocate such addresses in a way that they could be agregated > > into a smaller number of routing table slots and still maintain > > routability, then the policy problem is solved. > > In order for these prefixes to be aggregated, you'd have to convince > ISPs to aggregate them and carry traffic for the aggregates. Smells a > bit like ARIN telling ISPs what to do. > > You are also reinventing geographical addressing (or metro, or > whatever variant it is). Again, this is an old horse, on which the > community does not have agreement that it solves the problem. Or > rather, agreement that ISPs would ever agree to adopt such an > approach. There is a business model change that will have to happen to resolve the brokenness caused by filtering no matter what allocation approach is used. There is no agreement on making this business model change, but that should not preclude allocation policy from setting the stage for when it becomes necessary. Random allocations will be difficult to resolve in any case, so going down the first-come path should be avoided. I don't really care where we end up, but the approach in draft-hain-ipv6-pi* allows filtering whenever, wherever, and on whatever scale makes sense. The filtering does not have to be done globally, but wherever there is filtering there will need to be different business models than are used in current practice. > > Saying it obviously solves the problem, when others continue to point > out serious issues with actually deploying such an approach, isn't > helpful. The 'serious issues' generally boil down to 'we don't want to change business practice' because everyone wants the ability to have a global impact. > > > Of course a bloated routing table would not serve the public > > but it also does not serve the public when ISPs pretend that > > the routing technology used today is unable to solve this > > problem. The problem IS SOLVABLE and if customers demand it > > then ISPs will solve it. > > You are much more optimistic than I. I'd prefer to actually see a > viable approach (or outline of an approach) than just assume "we'll > figure it out somehow." Been there, done that. The problem is not with the routing technology, it is in its use. The continuing fantasy about a single DFZ does not help people sort through the issues either. BGP has evolved considerably to deal with just about every topology we know how to build. What it doesn't do is deal with the case where details are filtered when the business process and interconnects are not in place to make sure the traffic gets delivered. Stepping back and looking at the problem in a technology independent way ... 1) keeping the cost of routers within reason requires limiting the amount of global topology detail 2) actually delivering packets requires explicit topology detail by the set of providers directly connected to the recipient 3) traffic engineering projects the delivery detail on a wider scale than the directly connected providers 4) a traffic engineering policy that sorts between equal paths uses less detail for closest to source and more detail for closest to destination 5) private interconnects and exchange points allow providers that need the explicit detail to interact without the rest of the world having to know There is probably more to this list but it covers enough for the discussion: PA based allocations are nothing more than filtering that is strictly aligned with the provider business unit. PI of any flavor forces providers into the unnatural act of acknowledging that they can not meet all of their customer's needs. Access providers want more outgoing detail so they avoid handling the incoming traffic until it gets near their destination customer, and less incoming detail to dump outgoing traffic as quickly as possible. Transit providers want less detail for scale reasons, though they will flip between more and less to achieve the highest revenue to bit-mile ratio. Exchange points exist globally, though by current business practice they are not considered to be transit providers between access and long-haul transit providers. The neutral regional interconnect between access providers is an important aspect to maintain, but bolting on a transit AS to aggregate all the non-traffic engineered PI would solve the business related complaints about any geo approach. That step is not one the existing provider community is ready to take. Despite their reluctance to go down that path we should be setting the stage through PI allocation policy because it appears to be the only way to sort between traffic-engineered PI and simple redundancy/independence PI. Traffic-engineered PI will always take up global routing slots, other uses don't need to. Tony From sleibrand at internap.com Wed Feb 22 17:12:43 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 22 Feb 2006 17:12:43 -0500 (EST) Subject: [ppml] Fw: IRS goes IPv6! In-Reply-To: <016601c637f0$e76dcf90$d247190a@tndh.net> References: <016601c637f0$e76dcf90$d247190a@tndh.net> Message-ID: On 02/22/06 at 12:45pm -0800, Tony Hain wrote: > The approaches are not all that different. Other proposals based on cities > have been floated. In a PSTN context yours is effectively an area-code where > previous ones have been city-code. The details about how the addresses are > handed out are minor in context. Agreed. > The real issue with any geo approach is that providers have to > interconnect and hand off the traffic they picked up via the aggregate > to the carrier that has the customer. Here I disagree. IMO Geo-PI, however granular, in and of itself imposes no requirements on providers/carriers. Interconnecting as you describe is one way to make such geo-based allocation useful for reducing table sizes, but there's no reason why everyone carrying geo-PI space has to interconnect or coordinate aggregation policies. Details below. > This is a telco business model and the 'ISPs are different' mindset > refuses to go there. IMO that's because Geo-PI advocates keep asserting a mandatory interconnect/coordination requirement where there shouldn't be one. IMO if we can design a geo-PI system that makes no additional requirements of anyone but the RIRs (who would need to use the geo-PI system to decide which block to allocate, but would otherwise operate normally), there's a chance of getting such a system implemented. If we continue asserting mandatory interconnect/coordination requirements, consensus is unlikely any time soon. Let's say ARIN starts using a geo-based method to allocate PI space. As a result, everyone in New York gets PI space out of the same IPv6 /24 (for example), and everyone in Eastern North America gets PI space out of the same IPv6 /16. Now let's say NSP A wants to aggregate aggressively, and aggregates geo-PI space on a /24 boundary. NSPs B and C are less aggressive, because their peering is less dense for example, and aggregate on a /16 boundary. Since these are tier 1 transit-free NSPs, they interconnect in multiple places. NSP A interconnects with NSPs B and C within the NY /24 area and in the D.C. area. NSPs B and C only interconnect in the D.C. area, which is outside the NY /24, but within the /16. At its NY interconnects, NSP A announces B and C all their NY routes. NSPs B and C announce A all their East Coast routes at both NY and D.C. NSPs B and C announce each other all their East Coast routes at D.C. - If a customer of NSP A in NY wants to reach a customer of NSP B in NY, they have each other's local routes. - If a customer of NSP A outside NY wants to reach a customer of NSP B in NY, NSP A will carry the traffic toward their NY /24 PI aggregate. Once the traffic gets to NY, A will hand it off to B for delivery. - If a customer of NSP B in D.C. wants to reach a customer of NSP A in NY, NSP B will have all of NSP A's NY routes in its table and can hand off either in D.C. or NY. - Outside the East Coast region, NSP B will carry the traffic to the East Coast before handing it off. - If a customer is multihomed to NSPs A and B, traffic to/from D.C. will prefer NSP B due to longest match rules. Traffic to/from outside the East Coast region will prefer NSP A, unless NSP A does a second level of aggregation at /16 or shorter. So in summary, there's no requirement for coordinated/mandatory interconnection or aggregation policies between competing NSPs. There are some traffic engineering implications to disparate aggregation policies, so loose coordination or BCPs may develop on their own, but is by no means required to ensure reachability, and therefore non-coordinated transition states do not create significant unreachability risks. -Scott From alh-ietf at tndh.net Wed Feb 22 17:50:09 2006 From: alh-ietf at tndh.net (Tony Hain) Date: Wed, 22 Feb 2006 14:50:09 -0800 Subject: [ppml] Fw: IRS goes IPv6! In-Reply-To: Message-ID: <024d01c63802$552f4890$d247190a@tndh.net> You just refuted your own argument because all the carriers in your example are interconnected. Note I did not say where the interconnect had to happen, just that there has to be one because the aggregate will pick up traffic that a more specific will not. As you note traffic destined toward aggregates will follow whatever path a service provider defines to get it to the place where they are willing to support additional detail and interconnect with a provider advertising a more granular prefix. Those interconnect points can be anywhere and be public or private. The only interconnect requirement is that anyone announcing an aggregate prefix has to be able to deliver any received traffic to someone that can get it toward the destination. The whole tier-mumble concept also has to be dropped. Too many egos are wrapped around that particular axle, and that simply gets in the way of any aggregation discussion. It is not possible to 'know everything' at the same time as 'limiting knowledge' to manage the routing table size. You either have wild-and-woolly unabated routing tables, or someone will have to defer to someone else to worry about the details. This tier-mumble model is forcing all the detail toward the center with less at the edges, while scaling the routing system requires exactly the opposite. Tony > -----Original Message----- > From: Scott Leibrand [mailto:sleibrand at internap.com] > Sent: Wednesday, February 22, 2006 2:13 PM > To: Tony Hain > Cc: Michael.Dillon at btradianz.com; ppml at arin.net > Subject: Re: [ppml] Fw: IRS goes IPv6! > > On 02/22/06 at 12:45pm -0800, Tony Hain wrote: > > > The approaches are not all that different. Other proposals based on > cities > > have been floated. In a PSTN context yours is effectively an area-code > where > > previous ones have been city-code. The details about how the addresses > are > > handed out are minor in context. > > Agreed. > > > The real issue with any geo approach is that providers have to > > interconnect and hand off the traffic they picked up via the aggregate > > to the carrier that has the customer. > > Here I disagree. IMO Geo-PI, however granular, in and of itself imposes > no requirements on providers/carriers. Interconnecting as you describe is > one way to make such geo-based allocation useful for reducing table sizes, > but there's no reason why everyone carrying geo-PI space has to > interconnect or coordinate aggregation policies. Details below. > > > This is a telco business model and the 'ISPs are different' mindset > > refuses to go there. > > IMO that's because Geo-PI advocates keep asserting a mandatory > interconnect/coordination requirement where there shouldn't be one. IMO > if we can design a geo-PI system that makes no additional requirements of > anyone but the RIRs (who would need to use the geo-PI system to decide > which block to allocate, but would otherwise operate normally), there's a > chance of getting such a system implemented. If we continue asserting > mandatory interconnect/coordination requirements, consensus is unlikely > any time soon. > > Let's say ARIN starts using a geo-based method to allocate PI space. As a > result, everyone in New York gets PI space out of the same IPv6 /24 (for > example), and everyone in Eastern North America gets PI space out of the > same IPv6 /16. Now let's say NSP A wants to aggregate aggressively, and > aggregates geo-PI space on a /24 boundary. NSPs B and C are less > aggressive, because their peering is less dense for example, and > aggregate on a /16 boundary. > > Since these are tier 1 transit-free NSPs, they interconnect in multiple > places. NSP A interconnects with NSPs B and C within the NY /24 area and > in the D.C. area. NSPs B and C only interconnect in the D.C. area, which > is outside the NY /24, but within the /16. At its NY interconnects, NSP A > announces B and C all their NY routes. NSPs B and C announce A all their > East Coast routes at both NY and D.C. NSPs B and C announce each other > all their East Coast routes at D.C. > > - If a customer of NSP A in NY wants to reach a customer of NSP B in NY, > they have each other's local routes. > - If a customer of NSP A outside NY wants to reach a customer of NSP B in > NY, NSP A will carry the traffic toward their NY /24 PI aggregate. Once > the traffic gets to NY, A will hand it off to B for delivery. > - If a customer of NSP B in D.C. wants to reach a customer of NSP A in > NY, NSP B will have all of NSP A's NY routes in its table and can hand > off either in D.C. or NY. > - Outside the East Coast region, NSP B will carry the traffic to the East > Coast before handing it off. > - If a customer is multihomed to NSPs A and B, traffic to/from D.C. will > prefer NSP B due to longest match rules. Traffic to/from outside the East > Coast region will prefer NSP A, unless NSP A does a second level of > aggregation at /16 or shorter. > > So in summary, there's no requirement for coordinated/mandatory > interconnection or aggregation policies between competing NSPs. There are > some traffic engineering implications to disparate aggregation policies, > so loose coordination or BCPs may develop on their own, but is by no means > required to ensure reachability, and therefore non-coordinated transition > states do not create significant unreachability risks. > > -Scott From owen at delong.com Wed Feb 22 20:41:15 2006 From: owen at delong.com (Owen DeLong) Date: Wed, 22 Feb 2006 17:41:15 -0800 Subject: [ppml] Fw: IRS goes IPv6! In-Reply-To: References: Message-ID: --On February 22, 2006 9:51:19 AM +0000 Michael.Dillon at btradianz.com wrote: >> As such, I cannot advocate such a policy. It is likely to create a TWD >> or swamp of relatively large proportions as every man, woman, and child >> makes a run on IPv6 address space. > > Here we go again. Somebody declares that a policy will > create a swamp and that is a bad thing. But no definition > is offered for the term "swamp" except a cryptic acronym. > > All I know about IPv4 is that there was a swamp and it > must have been a good thing because it happened during > the exponential growth phase of the IPv4 network when > the Internet moved out of the universities and laboratories > to become a USEFUL NETWORK for businesses and ordinary > folks. If we need a swamp to do that, then I vote for this > swamp thingy, whatever it is. > Actually, that's technically not true. The swamp was created during the period leading up to said exponential growth. At a very early stage prior to the actual exponential growth, the AGS routers running the backbone started to have trouble containing the routing table and the CIDR hack was inflicted on the internet as the only rapidly available solution. Don't get me wrong, I think it was the right thing to do at the time. I just think that now it is time to come up with a more permanent and less debilitating solution. 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 sleibrand at internap.com Wed Feb 22 21:37:48 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 22 Feb 2006 21:37:48 -0500 (EST) Subject: [ppml] Fw: IRS goes IPv6! In-Reply-To: <024d01c63802$552f4890$d247190a@tndh.net> References: <024d01c63802$552f4890$d247190a@tndh.net> Message-ID: On 02/22/06 at 2:50pm -0800, Tony Hain wrote: > You just refuted your own argument because all the carriers in your example > are interconnected. Note I did not say where the interconnect had to happen, > just that there has to be one because the aggregate will pick up traffic > that a more specific will not. Ah. You want to talk about non-interconnected ISPs? I didn't include them in my argument this time, but I mentioned them before. (If you think I've missed any other corner cases here, please point them out.) In short, anyone who buys transit from an NSP will get all of that NSPs routes, including aggregates. Peers generally will not get announcements of aggregates. As a result, all ISPs in a region do not need to interconnect: they just need to buy transit from someone who does. Sounds a lot like what we have now, huh? > As you note traffic destined toward aggregates will follow whatever path a > service provider defines to get it to the place where they are willing to > support additional detail and interconnect with a provider advertising a > more granular prefix. Those interconnect points can be anywhere and be > public or private. The only interconnect requirement is that anyone > announcing an aggregate prefix has to be able to deliver any received > traffic to someone that can get it toward the destination. I agree 100%. > The whole tier-mumble concept also has to be dropped. Too many egos are > wrapped around that particular axle, and that simply gets in the way of any > aggregation discussion. I disagree. While tier1 status is indeed a lot about ego, it is quite useful in a lot of technical discussions. For example, the definition of a tier1 NSP is someone who peers (interconnects) with all other tier1's. (I'll leave settlement out of my definition, as it's not useful in technical discussions, just political and ego ones.) If you'd prefer a less overloaded term, perhaps "transit-free NSP" would work. > It is not possible to 'know everything' at the same time as 'limiting > knowledge' to manage the routing table size. You either have > wild-and-woolly unabated routing tables, or someone will have to defer > to someone else to worry about the details. Not necessarily. You can know everything somewhere, while never knowing everything everywhere. In my idea of how geo-PI would evolve, all transit-free NSPs would carry all routes in each region where they operate, but would aggregate those routes such that each region would only know full local detail. Since the packets have to get to the other region anyway, there's no requirement for full knowledge to be spread globally in a homogeneous DFZ. In short, you don't have to trust the details "to someone else" if you simply trust them to different routers in your own network. > This tier-mumble model is forcing all the detail toward the center with > less at the edges, while scaling the routing system requires exactly the > opposite. Agreed. Right now the more-or-less homogeneous DFZ does exactly that. But if we enable sane aggregatability with some sort of geo-based PI, NSPs can split their network into lots of centers such that any one center need only know its local details. -Scott > > -----Original Message----- > > From: Scott Leibrand [mailto:sleibrand at internap.com] > > Sent: Wednesday, February 22, 2006 2:13 PM > > To: Tony Hain > > Cc: Michael.Dillon at btradianz.com; ppml at arin.net > > Subject: Re: [ppml] Fw: IRS goes IPv6! > > > > On 02/22/06 at 12:45pm -0800, Tony Hain wrote: > > > > > The approaches are not all that different. Other proposals based on > > cities > > > have been floated. In a PSTN context yours is effectively an area-code > > where > > > previous ones have been city-code. The details about how the addresses > > are > > > handed out are minor in context. > > > > Agreed. > > > > > The real issue with any geo approach is that providers have to > > > interconnect and hand off the traffic they picked up via the aggregate > > > to the carrier that has the customer. > > > > Here I disagree. IMO Geo-PI, however granular, in and of itself imposes > > no requirements on providers/carriers. Interconnecting as you describe is > > one way to make such geo-based allocation useful for reducing table sizes, > > but there's no reason why everyone carrying geo-PI space has to > > interconnect or coordinate aggregation policies. Details below. > > > > > This is a telco business model and the 'ISPs are different' mindset > > > refuses to go there. > > > > IMO that's because Geo-PI advocates keep asserting a mandatory > > interconnect/coordination requirement where there shouldn't be one. IMO > > if we can design a geo-PI system that makes no additional requirements of > > anyone but the RIRs (who would need to use the geo-PI system to decide > > which block to allocate, but would otherwise operate normally), there's a > > chance of getting such a system implemented. If we continue asserting > > mandatory interconnect/coordination requirements, consensus is unlikely > > any time soon. > > > > Let's say ARIN starts using a geo-based method to allocate PI space. As a > > result, everyone in New York gets PI space out of the same IPv6 /24 (for > > example), and everyone in Eastern North America gets PI space out of the > > same IPv6 /16. Now let's say NSP A wants to aggregate aggressively, and > > aggregates geo-PI space on a /24 boundary. NSPs B and C are less > > aggressive, because their peering is less dense for example, and > > aggregate on a /16 boundary. > > > > Since these are tier 1 transit-free NSPs, they interconnect in multiple > > places. NSP A interconnects with NSPs B and C within the NY /24 area and > > in the D.C. area. NSPs B and C only interconnect in the D.C. area, which > > is outside the NY /24, but within the /16. At its NY interconnects, NSP A > > announces B and C all their NY routes. NSPs B and C announce A all their > > East Coast routes at both NY and D.C. NSPs B and C announce each other > > all their East Coast routes at D.C. > > > > - If a customer of NSP A in NY wants to reach a customer of NSP B in NY, > > they have each other's local routes. > > - If a customer of NSP A outside NY wants to reach a customer of NSP B in > > NY, NSP A will carry the traffic toward their NY /24 PI aggregate. Once > > the traffic gets to NY, A will hand it off to B for delivery. > > - If a customer of NSP B in D.C. wants to reach a customer of NSP A in > > NY, NSP B will have all of NSP A's NY routes in its table and can hand > > off either in D.C. or NY. > > - Outside the East Coast region, NSP B will carry the traffic to the East > > Coast before handing it off. > > - If a customer is multihomed to NSPs A and B, traffic to/from D.C. will > > prefer NSP B due to longest match rules. Traffic to/from outside the East > > Coast region will prefer NSP A, unless NSP A does a second level of > > aggregation at /16 or shorter. > > > > So in summary, there's no requirement for coordinated/mandatory > > interconnection or aggregation policies between competing NSPs. There are > > some traffic engineering implications to disparate aggregation policies, > > so loose coordination or BCPs may develop on their own, but is by no means > > required to ensure reachability, and therefore non-coordinated transition > > states do not create significant unreachability risks. > > > > -Scott > > From gih at apnic.net Wed Feb 22 22:04:02 2006 From: gih at apnic.net (Geoff Huston) Date: Thu, 23 Feb 2006 14:04:02 +1100 Subject: [ppml] [address-policy-wg] 2005-01 - Last Call for Comments (HD-ratio Proposal) In-Reply-To: <02de01c6381c$3b972a00$d247190a@tndh.net> References: <20060223014347.437182F593@herring.ripe.net> <02de01c6381c$3b972a00$d247190a@tndh.net> Message-ID: <6.2.0.14.2.20060223135555.02e56f38@kahuna.telstra.net> At 12:55 PM 23/02/2006, Tony Hain wrote: >Have either of you run the simulations with other HDR values? Would .97 make >a significant difference? Good question... Heres a table of the ratio of total address allocations using the RIPE NCC data, comparing the address consumption under the current 80% utilization criteria with a number of values for an HD Ratio criteria. I've included the mean standard deviation to give you a sense of the stability of these results. (Again, the technique here is to conduct an "experiment" consisting of 1000 separate simulations of a batch of 10,000 allocations, and the "result" is the ratio of the address space allocated under an HD Ratio framework, as compared to the same simulated end use populations being served under the current fixed 80% criteria) (fixed width font may help here) HD Ratio Ratio Mean Std Dev 0.98 1.04868 0.02285 0.97 1.25899 0.03363 0.96 1.45854 0.03371 0.95 1.63073 0.02848 0.94 1.78332 0.01859 regards, Geoff From randy at psg.com Wed Feb 22 22:07:25 2006 From: randy at psg.com (Randy Bush) Date: Wed, 22 Feb 2006 17:07:25 -1000 Subject: [ppml] [address-policy-wg] 2005-01 - Last Call for Comments (HD-ratio Proposal) References: <20060223014347.437182F593@herring.ripe.net> <02de01c6381c$3b972a00$d247190a@tndh.net> <6.2.0.14.2.20060223135555.02e56f38@kahuna.telstra.net> Message-ID: <17405.9965.791554.900320@roam.psg.com> > HD Ratio Ratio Mean Std Dev > 0.98 1.04868 0.02285 > 0.97 1.25899 0.03363 > 0.96 1.45854 0.03371 > 0.95 1.63073 0.02848 > 0.94 1.78332 0.01859 and what does .98 do to the flight ceiling of small folk? randy From gih at apnic.net Wed Feb 22 22:43:47 2006 From: gih at apnic.net (Geoff Huston) Date: Thu, 23 Feb 2006 14:43:47 +1100 Subject: [ppml] [address-policy-wg] 2005-01 - Last Call for Comments (HD-ratio Proposal) In-Reply-To: <17405.9965.791554.900320@roam.psg.com> References: <20060223014347.437182F593@herring.ripe.net> <02de01c6381c$3b972a00$d247190a@tndh.net> <6.2.0.14.2.20060223135555.02e56f38@kahuna.telstra.net> <17405.9965.791554.900320@roam.psg.com> Message-ID: <6.2.0.14.2.20060223142502.02c90330@kahuna.telstra.net> At 02:07 PM 23/02/2006, Randy Bush wrote: > > HD Ratio Ratio Mean Std Dev > > 0.98 1.04868 0.02285 > > 0.97 1.25899 0.03363 > > 0.96 1.45854 0.03371 > > 0.95 1.63073 0.02848 > > 0.94 1.78332 0.01859 > >and what does .98 do to the flight ceiling of small folk? > >randy I'll respond to this question, but in the interests of not wishing to overwhelming a whole swag of mailing lists I'll make this my last posting on this topic today. An HD Ratio of 0.98 imposes a higher efficiency target than the existing 80% rate for all prefix sizes smaller than a /16, and lower than 80% for allocations greater than a /16 (e.g. an HD Ratio of 0.98 implies an efficiency threshold of 72% for a /9 allocation.) As an example, if you had an end use population of between 3,277 and 6,554 numbered devices you would qualify for a /19 allocation under an 80% rule, while under an HD Ratio of 0.98 the end use population is between 3,468 and 6,841, corresponding to a required address efficiency level of 84% on this address block in order to qualify for a further address allocation. The use of an HD Ratio of 0.96 corresponds to an 80% efficiency level for a /24, so that 0.96 is no worse than 80% for all allocations, whereas HD Ratios greater than 0.96 impose an efficiency constraint greater than 80% on the smaller address blocks (/16 through to /24) - this can be easily modelled on any spreadsheet of course. regards, Geoff From Michael.Dillon at btradianz.com Thu Feb 23 05:40:40 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Thu, 23 Feb 2006 10:40:40 +0000 Subject: [ppml] Fw: IRS goes IPv6! In-Reply-To: Message-ID: > Perhaps the market will decide differently a few years from now, if > or when routing tables become more bloated than then-prevalent > hardware can handle. Again, ignoring the religious aspect of > protocol design, if my business is perfectly happy with the idea > that IPv4 or IPv6 or IPv8 packets cannot reach us from, say, China, > and our packets cannot get there, will there be a viable business > model and - perhaps more importantly - address assignment policies > allowing the providing of that sort of connectivity? > > The instant question, I think, is should today's allocation policy > proceed on the assumption that every packet will have to be > able to reach every destination forever? Or can it say these > ranges, or these sizes, may have a problem 5 years from now, > caveat emptor? Isn't ARIN already telling ISP's what to do? Who says that routing tables have to be stored in routers? There was a time, when the diameter of the Internet was quite a bit larger than 30 hops. This created a problem because people in the periphery could not make IP connections to distant sites. However, there was still a way to send email. I remember helping a researcher in Peru contact a colleague in the Ukraine by sending email to colleague%university.ua at aol.com. The mail server at aol.com, relayed the message onward to colleague at university.ua. This worked because AOL was near the center of the Internet in terms of hopcount. And because spam was a problem that only bothered USENET users. Why couldn't we do something similar with IP. An ISP could contract with a provider near the center of the Internet to deliver any packets that they don't know how to deliver. These central providers have humungous routing tables, perhaps stored on servers, not routers, and can handle every single PI route known to man. This is another way that business negotiations and creative use of existing technology could sidestep the problem of mushrooming route tables. Instead of upgrading every router in your network, you outsource some packet delivery to a specialist. This specialist, knowing that your packets are not to well-known destinations, can process them through servers containing much larger amounts of memory than a typical core router. The main packet volume goes to well-known destinations, thus these proxy shunts need not carry the same traffic levels as a core router. I simply do not believe that giving out PI space creates an insurmountable problem. Instead it creates opportunities for new business models. It stimulates the industry rather than restraining trade. --Michael Dillon From Michael.Dillon at btradianz.com Thu Feb 23 06:02:05 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Thu, 23 Feb 2006 11:02:05 +0000 Subject: [ppml] Fw: IRS goes IPv6! In-Reply-To: Message-ID: > So in summary, there's no requirement for coordinated/mandatory > interconnection or aggregation policies between competing NSPs. Agreed. There is more than one way to maintain reachability using existing protocols and technologies. In any case, if ARIN were to use a geographical allocation plan for PI addressing, nobody would need to take immediate action because everything will continue to work as before. The technique you described is one way that ISPs can mitigate the problems caused by too many PI allocations. However, no-one is certain that there ever will be too many PI allocations because the multihoming requirement is a significant barrier to entry. --Michael Dillon From Michael.Dillon at btradianz.com Thu Feb 23 06:06:00 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Thu, 23 Feb 2006 11:06:00 +0000 Subject: [ppml] Fw: IRS goes IPv6! In-Reply-To: Message-ID: >At a > very early stage prior to the actual exponential growth, the > AGS routers running the backbone started to have trouble containing > the routing table and the CIDR hack was inflicted on the internet > as the only rapidly available solution. You never actually defined what the swamp is. However, you seem to imply that it is a large block of address space that is randomly divided into smaller PI prefixes. My suggestion of imposing a geographical plan on the PI addressing will avert a swamp because it enables the use of CIDR aggregates based on the geographical plan. --Michael Dillon From jeroen at unfix.org Thu Feb 23 07:55:58 2006 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 23 Feb 2006 13:55:58 +0100 Subject: [ppml] Fw: IRS goes IPv6! Message-ID: <1140699359.1227.124.camel@firenze.zurich.ibm.com> On Thu, 2006-02-23 at 10:40 +0000, Michael.Dillon at btradianz.com wrote: [..] > Why couldn't we do something similar with IP. An ISP could > contract with a provider near the center of the Internet > to deliver any packets that they don't know how to deliver. > [..] The main packet > volume goes to well-known destinations, thus these proxy > shunts need not carry the same traffic levels as a core router. Good that you use the word 'shunt' here, because what you describe here is one of the ideas behind something that can be done with SHIM6: * endsites (what you call outer-perimeter) has PI space, say a /48 * when a packet gets routed onto the internet, outside the site, the exit router translates it to the core-prefix, that is provided by the upstream provider. The upstream ISP's routes are in the "global routing table", these can thus become quite small with multiple layers. * when the packet arrives at a outer-perimeter, these place the outer-address back again to restore the globaly-unique property. Also the address can be passed around as it is globally unique, no rewriting needed, doesn't break end-to-end and makes many people, except most likely TE folks who only get a outer-perimiter IP, happy. The latter group really just have to face that they are not big enough unforunately (unless somebody comes up with a cool solution(tm) :) Sort of tunneling over the core, or double-NAT. The IETF is already working on these kinds of ideas ;) Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 240 bytes Desc: This is a digitally signed message part URL: From terry.l.davis at boeing.com Thu Feb 23 11:51:34 2006 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Thu, 23 Feb 2006 08:51:34 -0800 Subject: [ppml] [address-policy-wg] 2005-01 - Last Call for Comments(HD-ratio Proposal) Message-ID: <0D090F1E0F5536449C7E6527AFFA280A21BB90@XCH-NW-8V1.nw.nos.boeing.com> Geoff/Randy Just as an aside, efficiency targets probably won't work when applied to mobile networks. Most large global mobile (ships & planes) platforms won't use but a much smaller fraction of the assignment. /24 is the smallest workable unit for global movement with any currently defined schemes. Localized mobility (trains/ferries/trucking) within a small geographical area (or even possibly even a region) may be able to get higher efficiencies depending on strategy/architecture. Take care Terry -----Original Message----- From: Geoff Huston [mailto:gih at apnic.net] Sent: Wednesday, February 22, 2006 7:44 PM To: Randy Bush Cc: ppml at arin.net; address-policy-wg at ripe.net; sig-policy at apnic.net Subject: Re: [ppml] [address-policy-wg] 2005-01 - Last Call for Comments(HD-ratio Proposal) At 02:07 PM 23/02/2006, Randy Bush wrote: > > HD Ratio Ratio Mean Std Dev > > 0.98 1.04868 0.02285 > > 0.97 1.25899 0.03363 > > 0.96 1.45854 0.03371 > > 0.95 1.63073 0.02848 > > 0.94 1.78332 0.01859 > >and what does .98 do to the flight ceiling of small folk? > >randy I'll respond to this question, but in the interests of not wishing to overwhelming a whole swag of mailing lists I'll make this my last posting on this topic today. An HD Ratio of 0.98 imposes a higher efficiency target than the existing 80% rate for all prefix sizes smaller than a /16, and lower than 80% for allocations greater than a /16 (e.g. an HD Ratio of 0.98 implies an efficiency threshold of 72% for a /9 allocation.) As an example, if you had an end use population of between 3,277 and 6,554 numbered devices you would qualify for a /19 allocation under an 80% rule, while under an HD Ratio of 0.98 the end use population is between 3,468 and 6,841, corresponding to a required address efficiency level of 84% on this address block in order to qualify for a further address allocation. The use of an HD Ratio of 0.96 corresponds to an 80% efficiency level for a /24, so that 0.96 is no worse than 80% for all allocations, whereas HD Ratios greater than 0.96 impose an efficiency constraint greater than 80% on the smaller address blocks (/16 through to /24) - this can be easily modelled on any spreadsheet of course. regards, Geoff _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From christopher.morrow at gmail.com Thu Feb 23 23:08:30 2006 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Fri, 24 Feb 2006 04:08:30 +0000 Subject: [ppml] Fw: IRS goes IPv6! In-Reply-To: <1140699359.1227.124.camel@firenze.zurich.ibm.com> References: <1140699359.1227.124.camel@firenze.zurich.ibm.com> Message-ID: <75cb24520602232008p51026277ocfb24b5489747030@mail.gmail.com> On 2/23/06, Jeroen Massar wrote: > * when a packet gets routed onto the internet, outside the site, the > exit router translates it to the core-prefix, that is provided by the > upstream provider. The upstream ISP's routes are in the "global routing > table", these can thus become quite small with multiple layers. > hurrah! NAT! wasn't NAT one of the reasons that ipv6 was a 'saviour' ? oh... > * when the packet arrives at a outer-perimeter, these place the > outer-address back again to restore the globaly-unique property. > could we just use ipv4 and tunnel over gre? or ip-in-ip? or ipsec? oh... > Also the address can be passed around as it is globally unique, no > rewriting needed, doesn't break end-to-end and makes many people, except > most likely TE folks who only get a outer-perimiter IP, happy. The > latter group really just have to face that they are not big enough > unforunately (unless somebody comes up with a cool solution(tm) :) 'not big enough' doesn't matter for TE considerations. If a large enough sink or source is in the 'wrong' place, game-over. without working TE you are stuck. > > Sort of tunneling over the core, or double-NAT. see comment #1 and comment #2. Combine those with comment #3 and I see no compelling reason to make any strides toward ipv6 deployment. Were you trying to make v6 more palatable? If so you really ought to work on delivery and message... > > The IETF is already working on these kinds of ideas ;) > hurray, why do we need the IETF working on NAT and Tunneling? > Greets, and to you as well. From owen at delong.com Thu Feb 23 23:09:05 2006 From: owen at delong.com (Owen DeLong) Date: Thu, 23 Feb 2006 20:09:05 -0800 Subject: [ppml] Fw: IRS goes IPv6! In-Reply-To: References: Message-ID: --On February 23, 2006 11:06:00 AM +0000 Michael.Dillon at btradianz.com wrote: >> At a >> very early stage prior to the actual exponential growth, the >> AGS routers running the backbone started to have trouble containing >> the routing table and the CIDR hack was inflicted on the internet >> as the only rapidly available solution. > > You never actually defined what the swamp is. > However, you seem to imply that it is a large block of > address space that is randomly divided into smaller PI > prefixes. > As I understand the generally accepted meaning of the term SWAMP: The collection of IPv4 non-CIDR allocations and assignments made by legacy registries prior to implementation of CIDR, supernets, and classless routing. So... The swamp is, as I understand it, a significant portion of the IPv4 address space including most of the assigned A space less than 64, most of the B space below 171, and most of the C space below 204. > My suggestion of imposing a geographical plan on the > PI addressing will avert a swamp because it enables the > use of CIDR aggregates based on the geographical plan. > Only if topology follows geography _AND_ PI!=portable in the event that the organization relocates. There are other fundamental flaws (geographically diverse organizations either need separate PI space for each area or must pick one area and accept suboptimal routing as likely for all others, etc.). Nonetheless, I understand that you are determined to push the geographical addressing agenda. I think everyone on PPML is aware of your position on this issue. My intent was only to correct your historical inaccuracy insofar as it placed effect before cause and attempted a role reversal between them. 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 jeroen at unfix.org Fri Feb 24 07:58:02 2006 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 24 Feb 2006 13:58:02 +0100 Subject: [ppml] Fw: IRS goes IPv6! In-Reply-To: <75cb24520602232008p51026277ocfb24b5489747030@mail.gmail.com> References: <1140699359.1227.124.camel@firenze.zurich.ibm.com> <75cb24520602232008p51026277ocfb24b5489747030@mail.gmail.com> Message-ID: <1140785882.1227.212.camel@firenze.zurich.ibm.com> On Fri, 2006-02-24 at 04:08 +0000, Christopher Morrow wrote: > On 2/23/06, Jeroen Massar wrote: > > > * when a packet gets routed onto the internet, outside the site, the > > exit router translates it to the core-prefix, that is provided by the > > upstream provider. The upstream ISP's routes are in the "global routing > > table", these can thus become quite small with multiple layers. > > > > hurrah! NAT! wasn't NAT one of the reasons that ipv6 was a 'saviour' ? oh... > > > * when the packet arrives at a outer-perimeter, these place the > > outer-address back again to restore the globaly-unique property. > > > > could we just use ipv4 and tunnel over gre? or ip-in-ip? or ipsec? oh... NAT in itself is not bad, as long as you transform the packet back to it's original contents on the other end. Similar to tunneling, but without the overhead and transparent to the network it is crossing. It is also something that people are using nowadays already for crossing networks that don't want to cooperate with them. > > Also the address can be passed around as it is globally unique, no > > rewriting needed, doesn't break end-to-end and makes many people, except > > most likely TE folks who only get a outer-perimiter IP, happy. The > > latter group really just have to face that they are not big enough > > unforunately (unless somebody comes up with a cool solution(tm) :) > > 'not big enough' doesn't matter for TE considerations. If a large > enough sink or source is in the 'wrong' place, game-over. without > working TE you are stuck. The 'not big enough' means that that entity won't be participating in the global routing table, when it turns out to become to big. That is the same as that a small company won't be running it's own fibers, if they where big enough they could do it (money-wise). Same here. Also a site in the outer-perimeter can still do quite some traffic engineering in the sense that it can choose to use the one upstream or one of the others. The same as the power they have currently. They can also still request their upstream ISP's to provide BGP tables and other informations they think would be suitable to accomplish this. > > > > Sort of tunneling over the core, or double-NAT. > > see comment #1 and comment #2. Combine those with comment #3 and I see > no compelling reason to make any strides toward ipv6 deployment. Only and biggest advantage of IPv6: bigger address space. You won't hear me say anything else. > Were > you trying to make v6 more palatable? If so you really ought to work > on delivery and message... I don't have anything to gain finanicially or any other way, so I don't need to deliver anything. You as an ISP, at least assuming that the gmail version of the you is the same as the other you, might want to. Then again, giving more address space to end-users, and giving them more power for less cash is probably not something that most ISP's want to see happening. My IPv6 connectivity is working perfectly fine already for quite some years, thanks to the ISP's that do provide it ;) > > The IETF is already working on these kinds of ideas ;) > > > > hurray, why do we need the IETF working on NAT and Tunneling? Vendors can also do it, you could also do it. IETF is officially still a group of independent volunteers, so you can also choose to join in. But why did you ask that question, you should know the answer by now. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 240 bytes Desc: This is a digitally signed message part URL: From Michael.Dillon at btradianz.com Fri Feb 24 09:52:37 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Fri, 24 Feb 2006 14:52:37 +0000 Subject: [ppml] New role for NRO Message-ID: Have a look at this: http://www.fbo.gov/spg/DOC/OS/OAM/Reference-Number-DOCNTIARFI0001/SynopsisR.html Perhaps NRO could bid for the role of allocating IPv4 and IPv6 addresses to registries? ------------------------------------------------------- Michael Dillon Capacity Management, 66 Prescot St., London, E1 8HG, UK Mobile: +44 7900 823 672 Internet: michael.dillon at btradianz.com Phone: +44 20 7650 9493 Fax: +44 20 7650 9030 http://www.btradianz.com One Community One Connection One Focus From william at elan.net Fri Feb 24 10:41:52 2006 From: william at elan.net (william(at)elan.net) Date: Fri, 24 Feb 2006 07:41:52 -0800 (PST) Subject: [ppml] New role for NRO In-Reply-To: References: Message-ID: On Fri, 24 Feb 2006 Michael.Dillon at btradianz.com wrote: > Have a look at this: > http://www.fbo.gov/spg/DOC/OS/OAM/Reference-Number-DOCNTIARFI0001/SynopsisR.html > > Perhaps NRO could bid for the role of allocating IPv4 and IPv6 addresses > to registries? Looks to me like its regularly scheduled resigning of IANA contract. Likely per policies of USG, they can not simply automaticly renew the contract and have to allow for others to submit for this role. And I suspect rebidding on part of this "contract" is not allowed either. What does interest me though is that they list assignment of both ipv4 AND ipv6 addresses to registries. IPv6 was really supposed to be independent creation of internet community and not part of what was developed under [D]ARPA and which thereafter was transformed to become a symbolic contract with USG DoC. -- William Leibzon Elan Networks william at elan.net From german at lacnic.net Fri Feb 24 11:41:12 2006 From: german at lacnic.net (German Valdez) Date: Fri, 24 Feb 2006 13:41:12 -0300 Subject: [ppml] [address-policy-wg] 2005-01 - Last Call for Comments(HD-ratio Proposal) In-Reply-To: <0D090F1E0F5536449C7E6527AFFA280A21BB90@XCH-NW-8V1.nw.nos.boeing.com> Message-ID: <200602241820.k1OIJJlF099998@micron.lacnic.net.uy> Friends >From LACNIC we have been following closely the discussion of this proposal. This proposal was shared in LACNIC community, since then we have received comments from members in LAC region. The comments in general show a concern about the possibility that the adoption of this policy in other regions may cause an excesive consume of IP addresses. The outcome of this would produce a bigger disparity and unfairness in the distribution of address space among the regions. It is not our intention to influence in the policy in other regions, however we call for caution and we exhort that all the elements involved be thoroughly examined and also those potential consequences in other regions be considered. . Regards German Valdez Policy and External Relations Manager LACNIC > -----Mensaje original----- > De: address-policy-wg-admin at ripe.net > [mailto:address-policy-wg-admin at ripe.net] En nombre de Davis, Terry L > Enviado el: Jueves, 23 de Febrero de 2006 01:52 p.m. > Para: Geoff Huston; Randy Bush > CC: ppml at arin.net; address-policy-wg at ripe.net; sig-policy at apnic.net > Asunto: RE: [ppml] [address-policy-wg] 2005-01 - Last Call > for Comments(HD-ratio Proposal) > > Geoff/Randy > > Just as an aside, efficiency targets probably won't work when > applied to mobile networks. Most large global mobile (ships > & planes) platforms won't use but a much smaller fraction of > the assignment. /24 is the smallest workable unit for global > movement with any currently defined schemes. > > Localized mobility (trains/ferries/trucking) within a small > geographical area (or even possibly even a region) may be > able to get higher efficiencies depending on strategy/architecture. > > Take care > Terry > > -----Original Message----- > From: Geoff Huston [mailto:gih at apnic.net] > Sent: Wednesday, February 22, 2006 7:44 PM > To: Randy Bush > Cc: ppml at arin.net; address-policy-wg at ripe.net; sig-policy at apnic.net > Subject: Re: [ppml] [address-policy-wg] 2005-01 - Last Call > for Comments(HD-ratio Proposal) > > At 02:07 PM 23/02/2006, Randy Bush wrote: > > > HD Ratio Ratio Mean Std Dev > > > 0.98 1.04868 0.02285 > > > 0.97 1.25899 0.03363 > > > 0.96 1.45854 0.03371 > > > 0.95 1.63073 0.02848 > > > 0.94 1.78332 0.01859 > > > >and what does .98 do to the flight ceiling of small folk? > > > >randy > > > I'll respond to this question, but in the interests of not > wishing to overwhelming a whole swag of mailing lists I'll > make this my last posting on this topic today. > > An HD Ratio of 0.98 imposes a higher efficiency target than > the existing 80% rate for all prefix sizes smaller than a > /16, and lower than 80% for > > allocations greater than a /16 (e.g. an HD Ratio of 0.98 > implies an efficiency threshold of 72% for a /9 allocation.) > > As an example, if you had an end use population of between 3,277 and > 6,554 > numbered devices you would qualify for a /19 allocation under > an 80% rule, while under an HD Ratio of 0.98 the end use > population is between 3,468 and 6,841, corresponding to a > required address efficiency level of 84% on this address > block in order to qualify for a further address allocation. > > The use of an HD Ratio of 0.96 corresponds to an 80% > efficiency level for a /24, so that 0.96 is no worse than 80% > for all allocations, whereas HD Ratios greater than 0.96 > impose an efficiency constraint greater than 80% on the > smaller address blocks (/16 through to /24) - this can be > easily modelled on any spreadsheet of course. > > regards, > > Geoff > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From ppml at rsuc.gweep.net Sat Feb 25 09:58:19 2006 From: ppml at rsuc.gweep.net (Joe Provo) Date: Sat, 25 Feb 2006 09:58:19 -0500 Subject: [ppml] Fw: IRS goes IPv6! In-Reply-To: References: <024d01c63802$552f4890$d247190a@tndh.net> Message-ID: <20060225145819.GA93823@gweep.net> On Wed, Feb 22, 2006 at 09:37:48PM -0500, Scott Leibrand wrote: > On 02/22/06 at 2:50pm -0800, Tony Hain wrote: [snip] > > The whole tier-mumble concept also has to be dropped. Too many egos are > > wrapped around that particular axle, and that simply gets in the way of any > > aggregation discussion. > > I disagree. While tier1 status is indeed a lot about ego, it is quite > useful in a lot of technical discussions. For example, the definition of > a tier1 NSP is someone who peers (interconnects) with all other tier1's. > (I'll leave settlement out of my definition, as it's not useful in > technical discussions, just political and ego ones.) If you'd prefer a > less overloaded term, perhaps "transit-free NSP" would work. Those terms both fail. ISPs are business entities which receive registry allocations. These business entities operate many ASNs with differing policies, unfortunately not always delineated by AS boundary. While an ARIN-sphere business entity may operate a transit-free network or portion of their network in the ARIN sphere, it may operate a transit-using network or portion of their network outside of said sphere... and vice-versa. It seems to me that trying to tie an allocation policy to a routing policy (which will change over time) is merely adding: - admin overhead to the registry - more stuff which the registry will have as rules and yet have no method of enforcement (revocation anyone? great stability there) - more admin overhead (cost) for the receiving ISPs that play along and - zero incentive for the receiving ISPs to actually play along. We've seen that work *so* well before. In the Internet-wide scope, why is being transit-free --or more accurately, backup-free and disaster-vulnerable-- important? Those networks are *just* as reliant on third parties for carrying their traffic as transit-buying networks. Multiples of those networks have had serious financial problems resulting in previous and current acqusition by networks built along different policies that have been successful in business. I guess I'm wondering why we'd want to encourage f[l]ailing models. The set of networks carrying a DFZ is larger. The set of networks ARIN represents is even larger. Pushing to centralize forwarding decisions affecting all of them in a manner counter to their economic and stablisity concerns is poorly thought-out, not to mention casts a shadow of a bell-shaped head. Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From sleibrand at internap.com Sat Feb 25 11:02:00 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Sat, 25 Feb 2006 11:02:00 -0500 (EST) Subject: [ppml] Fw: IRS goes IPv6! In-Reply-To: <20060225145819.GA93823@gweep.net> References: <024d01c63802$552f4890$d247190a@tndh.net> <20060225145819.GA93823@gweep.net> Message-ID: On 02/25/06 at 9:58am -0500, Joe Provo wrote: > On Wed, Feb 22, 2006 at 09:37:48PM -0500, Scott Leibrand wrote: > > While tier1 status is indeed a lot about ego, it is quite > > useful in a lot of technical discussions. For example, the definition of > > a tier1 NSP is someone who peers (interconnects) with all other tier1's. > > (I'll leave settlement out of my definition, as it's not useful in > > technical discussions, just political and ego ones.) If you'd prefer a > > less overloaded term, perhaps "transit-free NSP" would work. > > Those terms both fail. > > ISPs are business entities which receive registry allocations. These > business entities operate many ASNs with differing policies, > unfortunately not always delineated by AS boundary. While an ARIN-sphere > business entity may operate a transit-free network or portion of their > network in the ARIN sphere, it may operate a transit-using network or > portion of their network outside of said sphere... and vice-versa. Ok. I'll agree that "tier1 NSP" and "transit-free NSP" don't fully describe the world we live in. But pretty much any label break down for some cases: that doesn't mean we stop using labels when talking in generalities. > It seems to me that trying to tie an allocation policy to a routing > policy (which will change over time) is merely adding: > - admin overhead to the registry > - more stuff which the registry will have as rules and yet have no > method of enforcement (revocation anyone? great stability there) > - more admin overhead (cost) for the receiving ISPs that play along > and > - zero incentive for the receiving ISPs to actually play along. > We've seen that work *so* well before. Ok. I would agree with everything you say, but I'm not sure why you're saying it. I'm certainly not proposing to tie allocation policy to routing policy, nor have I seen anyone else suggest that recently. I'm simply proposing that ARIN allocate PI space in a systematic manner rather than on a random (chronological) basis. Any system based even loosely on topology or geography will allow well-connected NSP/ISPs to aggregate within their own network if/when they feel the need. In such a system, RIRs will not have to have rules or enforce anything. Overhead can be minimal: as simple as providing the address provided by the applicant and the netblock size needed to a simple algorithm that returns the best free netblock to allocate. There need not be any overhead whatsoever for receiving ISPs. No one need "play along", so no one would need to encourage anyone to do so. ISP/NSPs need not change their routing policies unless they feel it would save them money to do so (in delaying the need for CapEx spent on router upgrades). > In the Internet-wide scope, why is being transit-free --or more > accurately, backup-free and disaster-vulnerable-- important? Those > networks are *just* as reliant on third parties for carrying their > traffic as transit-buying networks. Multiples of those networks > have had serious financial problems resulting in previous and current > acquisition by networks built along different policies that have > been successful in business. I guess I'm wondering why we'd want to > encourage f[l]ailing models. There's no need to treat transit-free peering-only networks differently from anyone else. However, since such networks provide transit for everyone else, we do need to ensure that we aren't asking them to do anything that would prevent them from maintaining global reachability. > The set of networks carrying a DFZ is larger. The set of networks > ARIN represents is even larger. Pushing to centralize forwarding > decisions affecting all of them in a manner counter to their economic > and stability concerns is poorly thought-out, not to mention casts > a shadow of a bell-shaped head. Heh. I've never been accused of talking like a bell-head before. Ma Bell was broken up before I was born, and by the time I got to high school, the Internet boom/bubble was in full swing. I'm not pushing to centralize everyone's forwarding decisions. I fully appreciate the benefits of being able to interconnect and peer with anyone you want, and getting all of their routes to ensure you use the most direct path. Aggregation by transit-providing networks wouldn't change that in the slightest. However, there's a reason ISPs buy transit: they can't afford to build out the global network required to interconnect with everyone they might wish to exchange traffic with, so they pay someone to deliver their traffic where it needs to go. Keeping that in mind, I don't care whether my transit providers use an aggregate or deaggregates to take my traffic to non-local destinations. -Scott