From spiffnolee at yahoo.com Sun Nov 1 09:27:53 2009 From: spiffnolee at yahoo.com (Lee Howard) Date: Sun, 1 Nov 2009 06:27:53 -0800 (PST) Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <3c3e3fca0910311024x7ef383ddp810a6b199c49fb6b@mail.gmail.com> References: <4AE9D572.6080608@Dilkie.com> <3c3e3fca0910291140s1a4ea9b6l51776fa6f1ae56b6@mail.gmail.com> <139257.98318.qm@web63306.mail.re1.yahoo.com> <3c3e3fca0910300831q5e130dd8xd94c99797f737fd9@mail.gmail.com> <6652861E-150B-4E95-9298-D6CC048E5E5B@delong.com> <3c3e3fca0910301107i1699a390q6c52f81b5f2bd17b@mail.gmail.com> <332596.31946.qm@web63301.mail.re1.yahoo.com> <3c3e3fca0910311024x7ef383ddp810a6b199c49fb6b@mail.gmail.com> Message-ID: <589084.11764.qm@web63308.mail.re1.yahoo.com> > > Sounds like there may be some dollars to be waived under the noses > > of some transit providers. "Give me production-grade IPv6 transit > > or my IPv6 bits go elsewhere." > > Lee, > > I assure you it only sounds that way. The investment is a cumulative > effect measured not just in terms of my transit connection but > simultaneously in terms of yous and the transit for every other > individual who would use IPv6 to talk to me. I could wave Bill Gates' > fortune at the transit providers and it would still be years before > the IPv4 and IPv6 DFZs' standard of quality reached parity. I understand and agree that the "network effect" is at work here. But I hope that transit providers on this list are noticing that reliability of IPv6 connectivity is high on a list of reasons not to use IPv6. If they also believe IPv6 will be used to any extent, and want to compete for bits (=dollars) they'll have to work on that reliability. > > Maybe in six months, > > conditions will have changed enough for you not to worry. > > Not possible. Not even in 3 years. I'd like to dig into that denial some more, preferably without argument by toilet analogy. :-) Your objections, as I recall (maybe you could list them again, so we can discuss what needs to happen on each one): 1. IPv6 transit is unreliable 2. An dual-stacked client with IPv4-only connectivity may try IPv6 first, and wait for timeout before successfully using IPv6. IPv6 transit may not be as reliable as IPv4. If that's true, I think the reasons are: 1. IPv6 has not been properly "productized," so it doesn't have the same level of monitoring, alerting, and general urgency as IPv4. This will change as revenue is associated with it (i.e., as people who bill per bit notice they're losing bits), and as more traffic uses IPv6. 2. IPv6 has not been deployed by enough reliable transit providers, so you don't have as many choices for connectivity. 3. Those who do offer IPv6 transit don't have enough peers yet to ensure connectvity. Those could all be resolved fairly quickly. None of them is a three year project. > > Question born of ignorance: > > can you track unique web views if thousands of users are behind a > > single IPv4 address? It might not be an issue for your servers, but > > many websites use that as their primary metric for selling ads, don't > > they? > > Depends on your methodology. comScore, for example, offers prizes to So, sometimes yes, sometimes no? Sounds like that might still be important. Applications, including counters, that use IP address will have to use IPv6 address or figure out how to sort through NAT. I would think that content providers who use those applications (or the application developers) would be lobbying for deployment of IPv6. > You also have to understand that the metrics folks aren't interested > in use by machine so much as use by *person*. Users have demographics > and areas of interest. Machines are mostly just machines. NAT or no > NAT, tell me how you separate Mom, Dad and Child on the family PC > evaluating only the packets. I don't know, that's why I was asking. Lee From bill at herrin.us Sun Nov 1 13:47:13 2009 From: bill at herrin.us (William Herrin) Date: Sun, 1 Nov 2009 14:47:13 -0400 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <589084.11764.qm@web63308.mail.re1.yahoo.com> References: <4AE9D572.6080608@Dilkie.com> <3c3e3fca0910291140s1a4ea9b6l51776fa6f1ae56b6@mail.gmail.com> <139257.98318.qm@web63306.mail.re1.yahoo.com> <3c3e3fca0910300831q5e130dd8xd94c99797f737fd9@mail.gmail.com> <6652861E-150B-4E95-9298-D6CC048E5E5B@delong.com> <3c3e3fca0910301107i1699a390q6c52f81b5f2bd17b@mail.gmail.com> <332596.31946.qm@web63301.mail.re1.yahoo.com> <3c3e3fca0910311024x7ef383ddp810a6b199c49fb6b@mail.gmail.com> <589084.11764.qm@web63308.mail.re1.yahoo.com> Message-ID: <3c3e3fca0911011047g50377456mc7297ebfad6bf342@mail.gmail.com> On Sun, Nov 1, 2009 at 10:27 AM, Lee Howard wrote: >> Not possible. Not even in 3 years. > > I'd like to dig into that denial some more, preferably without argument > by toilet analogy. :-) > Your objections, as I recall (maybe you could list them again, so we > can discuss what needs to happen on each one): > 1. ?IPv6 transit is unreliable > 2. ?An dual-stacked client with IPv4-only connectivity may try IPv6 > first, and wait for timeout before successfully using IPv6. Lee, I think if I abstract my complaint it'll make a little more sense: 1. Nothing inherent to IPv6's design acts to make it more reliable than IPv4. 2. Given two systems whose theoretical reliability is identical, the practical difference in reliability will tend to be a function of the relative experience and investment in each. 3. The investment in and experience with IPv6 is paltry compared to the investment in IPv4 and the gap is widening, not closing. 4. From 1-3, I expect (and in fact observe) that IPv6's standard of reliability in virtually all of its aspects is significantly behind IPv4. 5. Due to a poor architectural decision by the IETF (IPv6 first, fall back to IPv4), I can't make effective use of IPv6 *at all* unless I deliberately ignore #4 and choose to accept degraded functionality on my system. Arguably the massive deployment of NAT necessary to extend IPv4 will alter point #1, with the result propagating through the logic chain. Arguably the address acquisition cost of continuing IPv4 post depletion will tip the scales so that the reliability/cost ratio tips in favor of IPv6. Arguably some unusually valuable capability will be identified in IPv6 that doesn't exist identically in IPv6, altering the benefit/cost ratio between IPv4 and IPv6. I'm prepared to act, but I'll believe it when I see it. #2 can be observed in the details. Tools like NAT and RA-guard which don't properly exist yet in IPv6. Complications figuring out who will talk to who and how in the backbone. Etc. Etc. For every detail cleared up, there are another handful waiting behind it. If not for #5, IPv6 would have a much easier time getting past the "worthy enough to deploy" barrier. There's a moderate risk-cost associated with only being able to use IPv4 given the uncertainty surrounding the end of the free pool. Weighed against the risk-cost of crashes, malfunctions and security breaches due to configuration and software changes to enable IPv6, the costs are almost in parity. But the fact that the systems so-enabled will attempt IPv6 first and only fall back to IPv4 just kills the whole equation. Of course, that pendulum could swing the other way too. When whatever happens post-depletion settles out into a routine, the risk-cost of continuing with only IPv4 could go way down. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From pwilson at apnic.net Sun Nov 1 19:16:59 2009 From: pwilson at apnic.net (Paul Wilson) Date: Mon, 02 Nov 2009 10:16:59 +1000 Subject: [arin-ppml] More smartgrid applications Message-ID: <64446ECC687A82530910ABB1@as-paul-l-1813.local> Dear all, A development here which is related to the previous discussion of IPv6 on Smartgrids. Nice application. Paul ==== http://www.guardian.co.uk/environment/2009/oct/28/google-powermeter-home-energy-monitor Powermeter: Google's household energy monitor arrives in UK Online tool allows householders to monitor energy use and greenhouse gas emissions, thereby reducing consumption and saving money Adam Vaughan Wednesday 28 October 2009 05.00 GMT [Image: "Google powermeter"] A sample page showing the energy-tracking Powermeter gadget on iGoogle. Photograph: Google Google may be best known for helping you find things on the web, but the online search company's latest move is a bid to make futuristic low-energy eco-homes a reality. Launching for the first time in the UK today, Google Powermeter is an online tool that allows householders to monitor their home's energy use and greenhouse gas emissions via the web, and so reduce their consumption and save money. Already being trialled in the US, the free energy-monitoring service uses new smart meters, or an add-on clip for conventional meters, to send electricity consumption to a personalised iGoogle web page. Users will be able to check their energy use anywhere in the world via a computer or mobile phone. The idea is that householders will be persuaded to stop overfilling kettles, switch appliances off standby and turn off unused lights after being confronted with their daily energy use. Studies by organisations including the government's Energy Saving Trust have suggested such energy monitoring leads people to cut their bills by 3-15%, potentially saving the average UK household ?75 a year. Google Powermeter is itself free, but will initially be available to British homeowners either by buying a gadget called AlertMe Energy or switching to first:utility, a small energy supplier. AlertMe's device works using a broadband hub and a clip for your electricity meter. It can be bought from today for ?69 with a ?3 monthly subscription fee. First:utility customers will have to wait until next month to try the service. Powermeter works by showing graphs of a user's energy consumption over time ? by day, week or month ? and comparing it to their previous usage and regional averages. Ben Coppin, an employee at AlertMe who has trialled it for the last six months, said using the software had led him to switch off an unnecessary immersion heater that was costing ?300-400 annually, and to halve his tumble dryer's energy use by switching from its highest setting to its lowest. Jens Redmer, director for business development at Google, said Powermeter's value came from "immediate feedback". He told of testers in California discovering pool pumps they hadn't used for years but that were draining energy, and one woman who saved her apartment from burning down by detecting a burning toaster while at work and alerting a neighbour. Redmer added that a social element could be a next step for the service, which keeps users' energy usage private. "In the future, one new feature could be friendly competition ? why can't I challenge my friends to say I'll save 10% over a year, and then trigger alerts when they're falling behind, so I could ping them to encourage them?" Pilgrim Beart, the founder and CEO of AlertMe, said: "Many consumers feel they can't protect themselves from rising energy costs or do anything to stop climate change. However, more than a quarter of all energy use happens in our homes and this gives consumers the power to monitor, control, and reduce the energy they use." Heating and power for UK homes account for 27% of the UK's carbon footprint. Powermeter's move into the UK puts it a step ahead of Microsoft's rival project, Hohm, which is in a US-only beta trial and works by creating an online dashboard of energy data from partnered utility companies. Unlike Google's software, it covers both electricity and gas use, and you can enter your usage manually. Enthusiasts have previously developed kits using open-source code that allow homes to post their energy usage to Twitter, and several companies sell energy monitors ? such as the OWL and Wattson ? which show real-time electricity consumption on wireless handheld displays. One such gadget available in the US, the TED 5000, already works with Powermeter. The UK government is consulting on the specification for smart meters ? whether they should feature wireless displays, for example ? which will be fitted in every home by 2020. ________________________________________________________________________ Paul Wilson, Director-General, APNIC http://www.apnic.net ph/fx +61 7 3858 3100/99 From spiffnolee at yahoo.com Mon Nov 2 09:53:23 2009 From: spiffnolee at yahoo.com (Lee Howard) Date: Mon, 2 Nov 2009 06:53:23 -0800 (PST) Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <3c3e3fca0911011047g50377456mc7297ebfad6bf342@mail.gmail.com> References: <4AE9D572.6080608@Dilkie.com> <3c3e3fca0910291140s1a4ea9b6l51776fa6f1ae56b6@mail.gmail.com> <139257.98318.qm@web63306.mail.re1.yahoo.com> <3c3e3fca0910300831q5e130dd8xd94c99797f737fd9@mail.gmail.com> <6652861E-150B-4E95-9298-D6CC048E5E5B@delong.com> <3c3e3fca0910301107i1699a390q6c52f81b5f2bd17b@mail.gmail.com> <332596.31946.qm@web63301.mail.re1.yahoo.com> <3c3e3fca0910311024x7ef383ddp810a6b199c49fb6b@mail.gmail.com> <589084.11764.qm@web63308.mail.re1.yahoo.com> <3c3e3fca0911011047g50377456mc7297ebfad6bf342@mail.gmail.com> Message-ID: <619507.62356.qm@web63306.mail.re1.yahoo.com> ----- Original Message ---- > From: William Herrin > To: Lee Howard > Cc: "arin-ppml at arin.net" > Sent: Sun, November 1, 2009 1:47:13 PM > Subject: Re: [arin-ppml] IPv4 Depletion as an ARIN policy concern > > On Sun, Nov 1, 2009 at 10:27 AM, Lee Howard wrote: > >> Not possible. Not even in 3 years. > > > > I'd like to dig into that denial some more, preferably without argument > > by toilet analogy. :-) > > Your objections, as I recall (maybe you could list them again, so we > > can discuss what needs to happen on each one): > > 1. IPv6 transit is unreliable > > 2. An dual-stacked client with IPv4-only connectivity may try IPv6 > > first, and wait for timeout before successfully using IPv6. > > Lee, > > I think if I abstract my complaint it'll make a little more sense: > > 1. Nothing inherent to IPv6's design acts to make it more reliable than IPv4. > 2. Given two systems whose theoretical reliability is identical, the > practical difference in reliability will tend to be a function of the > relative experience and investment in each. > 3. The investment in and experience with IPv6 is paltry compared to > the investment in IPv4 and the gap is widening, not closing. > 4. From 1-3, I expect (and in fact observe) that IPv6's standard of > reliability in virtually all of its aspects is significantly behind > IPv4. > 5. Due to a poor architectural decision by the IETF (IPv6 first, fall > back to IPv4), I can't make effective use of IPv6 *at all* unless I > deliberately ignore #4 and choose to accept degraded functionality on > my system. > > > Arguably the massive deployment of NAT necessary to extend IPv4 will > alter point #1, with the result propagating through the logic chain. Yes, I make that argument. > If not for #5, IPv6 would have a much easier time getting past the > "worthy enough to deploy" barrier. I disagree with you. I think there's a larger population who have been hearing about IPv6 for so long that they've decided it will never happen (or who are otherwise ignorant of IPv6), and the only way to convince them that networks will use IPv6 is if networks use IPv6. Otherwise, nobody will know if IPv6 is working until IPv4 connectivity is shut off, which is a little late to find out. > Of course, that pendulum could swing the other way too. When whatever > happens post-depletion settles out into a routine, the risk-cost of > continuing with only IPv4 could go way down. It sounds like you've done your research and built your contingency plans. Maybe you've only done engineering, and not systems work. If everyone waits until we achieve a steady state, then it will take years to achieve a stable, reliable Internet. Lee From spiffnolee at yahoo.com Mon Nov 2 10:03:33 2009 From: spiffnolee at yahoo.com (Lee Howard) Date: Mon, 2 Nov 2009 07:03:33 -0800 (PST) Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <1091030123109.40467B-100000@Ives.egh.com> References: <1091030123109.40467B-100000@Ives.egh.com> Message-ID: <530001.42966.qm@web63301.mail.re1.yahoo.com> > > Yes, if you don't have IPv6 connectivity, you can't connect over IPv6. > > That's a careless LAN administrator. > > Why are you libeling me? You say I'm a careless if I turn on IPv6 on my > LAN before my ISP offers IPv6 connectivity, so how the hell am I supposed > to test whether our applications work with IPv6, as some of my customers > are demanding? (By "our applications", I mean applications that we write > for our customers. How are our programmers supposed to write network- > agnostic applications without ever seeing an actual IPv6 network?) "Libel"? Seriously? That's not libel, it's just name-calling. I would suggest you test your applications on a test network, not your production network. Otherwise, your testing might interfere with your production connectivity, and not just in the case of IPv6. Lee From marty at akamai.com Mon Nov 2 10:12:16 2009 From: marty at akamai.com (Martin Hannigan) Date: Mon, 2 Nov 2009 10:12:16 -0500 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <530001.42966.qm@web63301.mail.re1.yahoo.com> References: <1091030123109.40467B-100000@Ives.egh.com> <530001.42966.qm@web63301.mail.re1.yahoo.com> Message-ID: On Nov 2, 2009, at 10:03 AM, Lee Howard wrote: > >>> Yes, if you don't have IPv6 connectivity, you can't connect over >>> IPv6. >>> That's a careless LAN administrator. >> >> Why are you libeling me? You say I'm a careless if I turn on IPv6 >> on my >> LAN before my ISP offers IPv6 connectivity, so how the hell am I >> supposed >> to test whether our applications work with IPv6, as some of my >> customers >> are demanding? (By "our applications", I mean applications that we >> write >> for our customers. How are our programmers supposed to write >> network- >> agnostic applications without ever seeing an actual IPv6 network?) > > "Libel"? Seriously? That's not libel, it's just name-calling. > I would suggest you test your applications on a test network, not your > production network. Otherwise, your testing might interfere with your > production connectivity, and not just in the case of IPv6. > > I'd like to suggest that this thread is misguided, useless and pretty much dead and y'all should get a room. :-) Best, Martin From warren at wholesaleinternet.com Mon Nov 2 10:13:46 2009 From: warren at wholesaleinternet.com (Warren Johnson) Date: Mon, 2 Nov 2009 09:13:46 -0600 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <3c3e3fca0911011047g50377456mc7297ebfad6bf342@mail.gmail.com> References: <4AE9D572.6080608@Dilkie.com><3c3e3fca0910291140s1a4ea9b6l51776fa6f1ae56b6@mail.gmail.com><139257.98318.qm@web63306.mail.re1.yahoo.com><3c3e3fca0910300831q5e130dd8xd94c99797f737fd9@mail.gmail.com><6652861E-150B-4E95-9298-D6CC048E5E5B@delong.com><3c3e3fca0910301107i1699a390q6c52f81b5f2bd17b@mail.gmail.com><332596.31946.qm@web63301.mail.re1.yahoo.com><3c3e3fca0910311024x7ef383ddp810a6b199c49fb6b@mail.gmail.com><589084.11764.qm@web63308.mail.re1.yahoo.com> <3c3e3fca0911011047g50377456mc7297ebfad6bf342@mail.gmail.com> Message-ID: <4CB03139E50F434A9EAF3B143FE760CC@johnsonvhjjf8v> [wears flame retardant under-roos] There is also the very real possibility that we never get to ipv6 and ipv4 simply becomes a closed system with only 4 billion "chips" into the big game (at least until some technology comes along to supercede everything). In the 30's New York City started requiring licenses for taxi's to pick up fares. 70 years later, the same amount of licenses existed (they did auction some more off in the last few years). The system simply adjusted to that circumstances. There are other forms of mass transit in that city but the very specific need of point-to-point pickup (if you're standing on a street corner) was only doable through those licensed taxis. As I see it, we can work on policy based on the assumption that we're going to get to ipv6, or we can work on policy based on the assumption we're never getting there. How do we go about picking a direction for policy development without looking schizophrenic? Also, does picking the "Dark side" (meaning never getting to ipv6) totally devestate the migration and make it a complete non-starter? -----Original Message----- If not for #5, IPv6 would have a much easier time getting past the "worthy enough to deploy" barrier. There's a moderate risk-cost associated with only being able to use IPv4 given the uncertainty surrounding the end of the free pool. Weighed against the risk-cost of crashes, malfunctions and security breaches due to configuration and software changes to enable IPv6, the costs are almost in parity. But the fact that the systems so-enabled will attempt IPv6 first and only fall back to IPv4 just kills the whole equation. Of course, that pendulum could swing the other way too. When whatever happens post-depletion settles out into a routine, the risk-cost of continuing with only IPv4 could go way down. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From cengel at sponsordirect.com Mon Nov 2 11:19:14 2009 From: cengel at sponsordirect.com (Chris Engel) Date: Mon, 2 Nov 2009 11:19:14 -0500 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: Message-ID: IPv6's best chance of adoption is to make the transition from IPv4 as seamless as possible for everyone involved. Which also largely means not necessitating a change of the methodologies and practices that people currently use with IPv4 more then is really required. It also means not tying other agenda's to IPv6's bandwagon. The one thing that I think pretty much everyone can agree is a positive with IPv6 is more address space available....at least I certainly don't think anyone would perceive that as a negative. The more things that you require people surrender in order to achieve that additional address space (in my case it would be primarily NAT... but it could be anything else for some-one else).... the less likely it is they are to determine the positives outweigh the negatives of adoption. If an argument is worthy of making (such as the idea that NAT is bad and need be eliminated).... let that crusade be fought SEPARATELY from IPv6. The same holds true for things ARIN is directly responsible for...such as rules for the justification of IP address space. IPv6 may ALLOW for those issues to be addressed (such as some make the case it allows for the obsolescence of NAT or far more liberal requirements for receiving address space)..... however it should not NECESSITATE that they be....unless IPv6 itself cannot be made to function without them..... and if it does, then it's design is poorly conceived. Christopher Engel From kkargel at polartel.com Mon Nov 2 11:54:38 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Mon, 2 Nov 2009 10:54:38 -0600 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: References: Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601F4A4DC@mail> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Chris Engel > Sent: Monday, November 02, 2009 10:19 AM > To: 'arin-ppml at arin.net' > Subject: Re: [arin-ppml] IPv4 Depletion as an ARIN policy concern > > IPv6's best chance of adoption is to make the transition from IPv4 as > seamless as possible for everyone involved. Which also largely means not > necessitating a change of the methodologies and practices that people > currently use with IPv4 more then is really required. It also means not > tying other agenda's to IPv6's bandwagon. > > The one thing that I think pretty much everyone can agree is a positive > with IPv6 is more address space available....at least I certainly don't > think anyone would perceive that as a negative. The more things that you > require people surrender in order to achieve that additional address space > (in my case it would be primarily NAT... but it could be anything else for > some-one else).... the less likely it is they are to determine the > positives outweigh the negatives of adoption. > > If an argument is worthy of making (such as the idea that NAT is bad and > need be eliminated).... let that crusade be fought SEPARATELY from IPv6. > The same holds true for things ARIN is directly responsible for...such as > rules for the justification of IP address space. > > IPv6 may ALLOW for those issues to be addressed (such as some make the > case it allows for the obsolescence of NAT or far more liberal > requirements for receiving address space)..... however it should not > NECESSITATE that they be....unless IPv6 itself cannot be made to function > without them..... and if it does, then it's design is poorly conceived. > > > Christopher Engel NAT started out as a kludgy local workaround and will always pretty much be a local workaround. NAT is nothing more than a silly router trick. Administrators can do whatever they darn well please within their own networks. NAT affects only the internal operation of a network. NAT does not affect global routing one iota. There is no information passed to the world that allows the far end to de-obfuscate NAT, except perhaps machine identifiers sent as a proprietary attribute. Just because NAT is not "built in" to the IPv6 protocols does not mean it can or will not be done. I do not think we should or even have the ability to do something like outlawing NAT. If an administrator decides he wants to NAT he is going to be able to do it no matter what any of us say or do unless you are going to get all of the major players to rip NAT code out of all of the router OS's and server OS's. Even then people will just patch it back in if they want it. Discussions about whether to allow or proscribe NAT are pointless. NAT is not within the ARIN sphere of influence. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3224 bytes Desc: not available URL: From michael.dillon at bt.com Mon Nov 2 12:05:25 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 2 Nov 2009 17:05:25 -0000 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <4CB03139E50F434A9EAF3B143FE760CC@johnsonvhjjf8v> Message-ID: <28E139F46D45AF49A31950F88C49745803D87399@E03MVZ2-UKDY.domain1.systemhost.net> > There is also the very real possibility that we never get to > ipv6 and ipv4 simply becomes a closed system with only 4 > billion "chips" into the big game (at least until some > technology comes along to supercede everything). No way. There are too many lessons learned from other areas. > In the 30's > New York City started requiring licenses for taxi's to pick > up fares. 70 years later, the same amount of licenses > existed (they did auction some more off in the last few > years). The system simply adjusted to that circumstances. > There are other forms of mass transit in that city but the > very specific need of point-to-point pickup (if you're > standing on a street corner) was only doable through those > licensed taxis. That's one of the lessons learned. By the way, in London England, the barrier wasn't badges, but "The Knowledge", a tough test that requires the potential taxi driver to know their way through every part of the city, most of which is still a warren of medieval villages connected by narrow twisting medieval roads. In order to get from point A to point B, the potential taxi driver needs to learn which alleyways to use as shortcuts, where to make U-turns to avoid congestion, and which times of day the various routes will work. Not to mention all the street names which can be repeated numerous times in different parts of the city. Also oddities like Cannon Street Road which is nowhere near Cannon Street. The solution that was developed in London was the mini-cab. This is just an ordinary car that you can hire to travel point-to-point except that they cannot pick up fares in the street, because that is illegal without a licence. But lots of them do it anyway and in addition, people will mobile phones hang around near bars whispering "taxi" to anyone who walks by. If someone wants a taxi they call up on the mobile and the driver who was waiting around the corner shows up. There were so many of these illegal mini-cabs with drivers who often knew little English, and sometimes even had no driving licence, they outnumbered the legals. I remember my first day in London at the new job 10 years ago when the mini-cab driver was trying to look at a map while driving down busy roads. I had to grab the map from him, figure out where I was going and give him directions. In the end, the government decided to licence the mini-cabs in order to get the worst drivers off the road, perhaps even into jail. What's the IP addressing analogy to London? NAT and middleboxes. Where there is demand for a service, people will figure out a way to do it even if the designers and architects don't feel it is necessary. Don't worry about IPv6 and IPv4 coexistence because it will work itself out. It's not necessary to know how this will happen up front, nor is it necessary to impose some well-meaning solution today. There is no question about whether or not IPv6 will happen. It has already happened, and is now ramping up growth. --Michael Dillon From marquis at roble.com Mon Nov 2 12:58:13 2009 From: marquis at roble.com (Roger Marquis) Date: Mon, 2 Nov 2009 09:58:13 -0800 (PST) Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: References: Message-ID: <20091102175813.DE35D2B2113@mx5.roble.com> Kevin Kargel wrote: > NAT started out as a kludgy local workaround and will always pretty much be > a local workaround. NAT is nothing more than a silly router trick. Whether or not NAT is "kludgy", a "workaround", or "silly" is an opinion. It is an opinion not supported by fact i.e., the market for end-node network gear without NAT, which is effectively zero. As a result arguments against NAT are irrelevant. > Just because NAT is not "built in" to the IPv6 protocols does not mean it > can or will not be done. This wasn't the case for v4, why would v6 be different? Applications like SIP hack (workaround, kludge, ...) the ISO 7 layer model in ways it was not intended to be hacked, and will need to be accommodated. To keep NAT implementations and libraries from being numerous, and to avoid incompatibilities, a standard is required. To state this another way, those of us who manage end-nodes will not be purchasing IPv6 network gear that fails to support a standardized version of NAT. Manufacturers will in turn not offer such equipment knowing it will not sell. How anyone can continue to argue that IPv6 does not require NAT in light of this is beyond me, but I do hope you work for a competitor. Roger Marquis From kkargel at polartel.com Mon Nov 2 13:17:27 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Mon, 2 Nov 2009 12:17:27 -0600 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <20091102175813.DE35D2B2113@mx5.roble.com> References: <20091102175813.DE35D2B2113@mx5.roble.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A0631410660251F175@mail> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Roger Marquis > Sent: Monday, November 02, 2009 11:58 AM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] IPv4 Depletion as an ARIN policy concern > > Kevin Kargel wrote: > > NAT started out as a kludgy local workaround and will always pretty much > be > > a local workaround. NAT is nothing more than a silly router trick. > > Whether or not NAT is "kludgy", a "workaround", or "silly" is an opinion. > It is an opinion not supported by fact i.e., the market for end-node > network gear without NAT, which is effectively zero. As a result > arguments > against NAT are irrelevant. Precisely my point. > > > Just because NAT is not "built in" to the IPv6 protocols does not mean > it > > can or will not be done. > > This wasn't the case for v4, why would v6 be different? Applications like > SIP hack (workaround, kludge, ...) the ISO 7 layer model in ways it was > not > intended to be hacked, and will need to be accommodated. To keep NAT > implementations and libraries from being numerous, and to avoid > incompatibilities, a standard is required. I agree wholeheartedly. IPv4 was not originally implemented with NAT in mind, then people had a need and "kludged" a solution. IPv6 will be the same. If for whatever reason some administrator feels a need for IPv6 NAT they will figure out a way to implement it, whether it is 'recommended' or 'allowed' or whatever. The history of internet is resplendent with examples of hacks that worked and became SOP. That is not going to stop because the numbering scheme changes. > > To state this another way, those of us who manage end-nodes will not be > purchasing IPv6 network gear that fails to support a standardized version > of NAT. Manufacturers will in turn not offer such equipment knowing it > will not sell. How anyone can continue to argue that IPv6 does not > require I am by no means arguing that IPv6 does not require NAT, I am arguing that NAT is something that will run over and under NAT and is separate from the global protocol. I don't think it will be possible to write NAT out of the picture. People will continue to do what they want with their networks and I am sure in many cases that will include NAT. > NAT in light of this is beyond me, but I do hope you work for a > competitor. Wow, a little sensitive are we? It seems I struck a glancing blow to a nerve here. I hope you read again, I was not arguing that NAT is not needed, just that it is beside the point. Why argue about something that is going to happen no matter what we say? There will always be people who want NAT, if for no other reason than they are comfortable with and enjoy the 'pseudo' security layer. > > Roger Marquis > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3224 bytes Desc: not available URL: From cgrundemann at gmail.com Mon Nov 2 13:31:55 2009 From: cgrundemann at gmail.com (Chris Grundemann) Date: Mon, 2 Nov 2009 11:31:55 -0700 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <4CB03139E50F434A9EAF3B143FE760CC@johnsonvhjjf8v> References: <139257.98318.qm@web63306.mail.re1.yahoo.com> <3c3e3fca0910300831q5e130dd8xd94c99797f737fd9@mail.gmail.com> <6652861E-150B-4E95-9298-D6CC048E5E5B@delong.com> <3c3e3fca0910301107i1699a390q6c52f81b5f2bd17b@mail.gmail.com> <332596.31946.qm@web63301.mail.re1.yahoo.com> <3c3e3fca0910311024x7ef383ddp810a6b199c49fb6b@mail.gmail.com> <589084.11764.qm@web63308.mail.re1.yahoo.com> <3c3e3fca0911011047g50377456mc7297ebfad6bf342@mail.gmail.com> <4CB03139E50F434A9EAF3B143FE760CC@johnsonvhjjf8v> Message-ID: <443de7ad0911021031l11cfc4cfo67dd8adf546e2dc4@mail.gmail.com> On Mon, Nov 2, 2009 at 08:13, Warren Johnson wrote: > [wears flame retardant under-roos] > > There is also the very real possibility that we never get to ipv6 and ipv4 > simply becomes a closed system with only 4 billion "chips" into the big game > (at least until some technology comes along to supercede everything). ?In > the 30's New York City started requiring licenses for taxi's to pick up > fares. ?70 years later, the same amount of licenses existed (they did > auction some more off in the last few years). ?The system simply adjusted to > that circumstances. ?There are other forms of mass transit in that city but > the very specific need ?of point-to-point pickup (if you're standing on a > street corner) was only doable through ?those licensed taxis. I kind of like that analogy, with one problem. There is no _legal_ alternative to licensed taxi's in New York City today. Ignoring the folks who operate illegal taxi services in NYC, let's add an IPv6 equivalent: the hovercab. The hovercab has been invented and NYC has decided that they will issue 1 million hovercab licenses for free (or close enough to free that it doesn't really matter). The problem is that you need a ladder or some such to board a hocvercab, and very few people, businesses, street-corners, etc. are so equipped today. If I am one of the folks without a regular taxi license but I want to run a taxi company, I have options now. I can purchase a medallion for $700k+ or I can go get a free hovercab license. If I take a free hovercab license, I am left with an unspent $700k (the cabs cost about the same either way). Maybe I give out free step-laddders to as many building owners as I can with that money. Maybe I just charge WAY lower fares than regular taxi's do and let my customers buy their own ladders. Maybe I find some other, more creative way to push adoption - develop a new and better (cheaper) way to board the hovercab perhaps? The higher the cost of taxi medallions, the more incentive everyone has to move toward the cheaper/easier-to-get hovercabs. > As I see it, we can work on policy based on the assumption that we're going > to get to ipv6, or we can work on policy based on the assumption we're never > getting there. ?How do we go about picking a direction for policy > development without looking schizophrenic? ?Also, does picking the "Dark > side" (meaning never getting to ipv6) totally devestate the migration and > make it a complete non-starter? > Getting back to the point of these seemingly endless threads: IPv4 depletion as an ARIN policy concern: 1) Irregardless of IPv6 adoption, we (the ARIN community) need to deal with IPv4 return, allocation, assignment and transfers in the lead up to, and especially after, IPv4 free-pool depletion. I think it is clear to everyone, no matter their stance on IPv6 or NAT, that there will be at least some demand for IPv4 after there are no unallocated prefix' available. This raises a few questions in my mind: a) What are ARIN's responsibilities to the community, specifically? - Needs-based distribution? - Fair distribution? - Minimization of route table growth? - Maximization of access for individual end-users? - Maximization of access for organizational end-users? - Efficient utilization of address space? b) What are ARIN's responsibilities to the rest of the world? - Re-distribution of addresses? - Others? - Nothing? c) What is this communities responsibility to ARIN? - Should we consider the preservation of ARIN as a policy concern? If we can develop definitions of and answers to these questions (and probably many more that I am overlooking) then we will have a strong base upon which to build policy around the impending depletion of IPv4 resources. The bottom line is that in almost all combinations of possible answers, _something_ needs to be done policy-wise. 2) The next thing that should influence policy designed to meet the needs of this community in the run up to and after depletion is the possible technical paths forward. In this regard I think we must weigh all the possibilities but plan for the most likely. IPv6 _is_ going to be the next Internet Protocol. IPv4 will _not_ live on forever as the primary Internet protocol. These are facts that we must consider when writing policy. I think our best next step (aside from getting off the wholly irrelevant NAT66 discussion) is to build a list of these questions, address each of them collectively and then build scenarios based on the top answers (as I am sure we will not have one agreed upon answer for all of these questions - likely not even one). The resulting framework will allow truly intelligent and relevant policy discussions. If we can agree on the questions, then we can create a thread for each and maybe start having some much more list-relevant debate. Or maybe I just drank too much tea this morning... ~Chris > > > > > > -----Original Message----- > > > If not for #5, IPv6 would have a much easier time getting past the "worthy > enough to deploy" barrier. There's a moderate risk-cost associated with only > being able to use IPv4 given the uncertainty surrounding the end of the free > pool. Weighed against the risk-cost of crashes, malfunctions and security > breaches due to configuration and software changes to enable IPv6, the costs > are almost in parity. But the fact that the systems so-enabled will attempt > IPv6 first and only fall back to IPv4 just kills the whole equation. > > Of course, that pendulum could swing the other way too. When whatever > happens post-depletion settles out into a routine, the risk-cost of > continuing with only IPv4 could go way down. > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com ?bill at herrin.us > 3005 Crane Dr. ...................... Web: Falls > Church, VA 22042-3004 _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public > Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org From scottleibrand at gmail.com Mon Nov 2 14:00:25 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 02 Nov 2009 11:00:25 -0800 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: References: Message-ID: <4AEF2C49.7020401@gmail.com> Chris Engel wrote: > IPv6's best chance of adoption is to make the transition from IPv4 as seamless as possible for everyone involved. Which also largely means not necessitating a change of the methodologies and practices that people currently use with IPv4 more then is really required. It also means not tying other agenda's to IPv6's bandwagon. > > The one thing that I think pretty much everyone can agree is a positive with IPv6 is more address space available....at least I certainly don't think anyone would perceive that as a negative. The more things that you require people surrender in order to achieve that additional address space (in my case it would be primarily NAT... but it could be anything else for some-one else).... the less likely it is they are to determine the positives outweigh the negatives of adoption. > > If an argument is worthy of making (such as the idea that NAT is bad and need be eliminated).... let that crusade be fought SEPARATELY from IPv6. The same holds true for things ARIN is directly responsible for...such as rules for the justification of IP address space. > > IPv6 may ALLOW for those issues to be addressed (such as some make the case it allows for the obsolescence of NAT or far more liberal requirements for receiving address space)..... however it should not NECESSITATE that they be....unless IPv6 itself cannot be made to function without them..... and if it does, then it's design is poorly conceived. > Well put. In light of that, where do you see the need for policy work? Are there places where ARIN policy is interfering with transition by unnecessarily bundling other considerations into addressing policy? Are there areas (such as the rules for justification of IP address space) where we haven't yet done enough to make the transition as painless as possible for everyone involved? Thanks, Scott From bill at herrin.us Mon Nov 2 14:50:02 2009 From: bill at herrin.us (William Herrin) Date: Mon, 2 Nov 2009 15:50:02 -0400 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <619507.62356.qm@web63306.mail.re1.yahoo.com> References: <139257.98318.qm@web63306.mail.re1.yahoo.com> <3c3e3fca0910300831q5e130dd8xd94c99797f737fd9@mail.gmail.com> <6652861E-150B-4E95-9298-D6CC048E5E5B@delong.com> <3c3e3fca0910301107i1699a390q6c52f81b5f2bd17b@mail.gmail.com> <332596.31946.qm@web63301.mail.re1.yahoo.com> <3c3e3fca0910311024x7ef383ddp810a6b199c49fb6b@mail.gmail.com> <589084.11764.qm@web63308.mail.re1.yahoo.com> <3c3e3fca0911011047g50377456mc7297ebfad6bf342@mail.gmail.com> <619507.62356.qm@web63306.mail.re1.yahoo.com> Message-ID: <3c3e3fca0911021150g6c51d93bw4dadfed4b120a9b0@mail.gmail.com> On Mon, Nov 2, 2009 at 10:53 AM, Lee Howard wrote: >> From: William Herrin >> 1. Nothing inherent to IPv6's design acts to make it more reliable than IPv4. >> Arguably the massive deployment of NAT necessary to extend IPv4 will >> alter point #1. > > Yes, I make that argument. Lee, I accept the possibility and include it in my risk assessment. Still adds up to watchful waiting. >> 5. Due to a poor architectural decision by the IETF (IPv6 first, fall >> back to IPv4), I can't make effective use of IPv6 *at all* unless I >> deliberately ignore #4 and choose to accept degraded functionality on >> my system. >> >> If not for #5, IPv6 would have a much easier time getting past the >> "worthy enough to deploy" barrier. > > I disagree with you. ?I think there's a larger population who have been > hearing about IPv6 for so long that they've decided it will never > happen (or who are otherwise ignorant of IPv6), and the only way to > convince them that networks will use IPv6 is if networks use IPv6. > > Otherwise, nobody will know if IPv6 is working until IPv4 > connectivity is shut off, which is a little late to find out. You can force me to choose between IPv4-only and IPv6-fall-back-to-IPv4 but you probably can't force me to choose the latter and probably won't like the lip-service I give it if you try. Systemic effects of IPv4-fall-back-to-IPv6 notwithstanding, IPv6-fall-back-to-IPv4 is a powerful disincentive to early movement on IPv6. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From scottleibrand at gmail.com Mon Nov 2 14:55:24 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 02 Nov 2009 11:55:24 -0800 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <3c3e3fca0911021150g6c51d93bw4dadfed4b120a9b0@mail.gmail.com> References: <139257.98318.qm@web63306.mail.re1.yahoo.com> <3c3e3fca0910300831q5e130dd8xd94c99797f737fd9@mail.gmail.com> <6652861E-150B-4E95-9298-D6CC048E5E5B@delong.com> <3c3e3fca0910301107i1699a390q6c52f81b5f2bd17b@mail.gmail.com> <332596.31946.qm@web63301.mail.re1.yahoo.com> <3c3e3fca0910311024x7ef383ddp810a6b199c49fb6b@mail.gmail.com> <589084.11764.qm@web63308.mail.re1.yahoo.com> <3c3e3fca0911011047g50377456mc7297ebfad6bf342@mail.gmail.com> <619507.62356.qm@web63306.mail.re1.yahoo.com> <3c3e3fca0911021150g6c51d93bw4dadfed4b120a9b0@mail.gmail.com> Message-ID: <4AEF392C.3020107@gmail.com> William Herrin wrote: >>> 5. Due to a poor architectural decision by the IETF (IPv6 first, fall >>> back to IPv4), I can't make effective use of IPv6 *at all* unless I >>> deliberately ignore #4 and choose to accept degraded functionality on >>> my system. >>> >>> If not for #5, IPv6 would have a much easier time getting past the >>> "worthy enough to deploy" barrier. >>> >> I disagree with you. I think there's a larger population who have been >> hearing about IPv6 for so long that they've decided it will never >> happen (or who are otherwise ignorant of IPv6), and the only way to >> convince them that networks will use IPv6 is if networks use IPv6. >> >> Otherwise, nobody will know if IPv6 is working until IPv4 >> connectivity is shut off, which is a little late to find out. >> > > You can force me to choose between IPv4-only and > IPv6-fall-back-to-IPv4 but you probably can't force me to choose the > latter and probably won't like the lip-service I give it if you try. > > Systemic effects of IPv4-fall-back-to-IPv6 notwithstanding, > IPv6-fall-back-to-IPv4 is a powerful disincentive to early movement on > IPv6. > Standardization issues aside, I think there is definitely some interesting work being done by pragmatic operator types to work around this problem, as was shared at NANOG 47 in Dearborn. However, that seems mostly OT for this list. In any event, do you see any particular areas where we could potentially improve address policy in light of the issues raised in this thread? Thanks, Scott From cengel at sponsordirect.com Mon Nov 2 15:05:09 2009 From: cengel at sponsordirect.com (Chris Engel) Date: Mon, 2 Nov 2009 15:05:09 -0500 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <4AEF2C49.7020401@gmail.com> Message-ID: Scott, I really didn't mean to stir up the NAT hornets nest again. I was speaking in more general terms that things which do not specificaly NEED to be tied to IPv6 to make it function should not be. NAT was simply an example of my own particular pet-peeve area of this....I'm sure others here have thier own....some of which MAY actually involve ARIN policy. About the only thing that could be done policy-wise in regards the feasability of NAT in IPv6 is simply ensure that certain address space is reserved for Private Networks and will NEVER be handed out to anyone to be publicaly routed... just as the 10.x.x.x /8 and 192.168.x.x /16 spaces are currently reseved under IPv4. However, that seems to already be covered by rfc4193.... so I'm not sure there is a specific issue here.....other then to realize that the speed of IPv6 adoption may not be as quick as many here would hope for. Christopher Engel -----Original Message----- From: Scott Leibrand [mailto:scottleibrand at gmail.com] Sent: Monday, November 02, 2009 2:00 PM To: Chris Engel Cc: 'arin-ppml at arin.net' Subject: Re: [arin-ppml] IPv4 Depletion as an ARIN policy concern Chris Engel wrote: > IPv6's best chance of adoption is to make the transition from IPv4 as > seamless as possible for everyone involved. Which also largely means > not necessitating a change of the methodologies and practices that > people currently use with IPv4 more then is really required. It also > means not tying other agenda's to IPv6's bandwagon. > > The one thing that I think pretty much everyone can agree is a > positive with IPv6 is more address space available....at least I > certainly don't think anyone would perceive that as a negative. The > more things that you require people surrender in order to achieve that > additional address space (in my case it would be primarily NAT... but > it could be anything else for some-one else).... the less likely it is > they are to determine the positives outweigh the negatives of > adoption. > > If an argument is worthy of making (such as the idea that NAT is bad > and need be eliminated).... let that crusade be fought SEPARATELY from > IPv6. The same holds true for things ARIN is directly responsible > for...such as rules for the justification of IP address space. > > IPv6 may ALLOW for those issues to be addressed (such as some make the > case it allows for the obsolescence of NAT or far more liberal > requirements for receiving address space)..... however it should not > NECESSITATE that they be....unless IPv6 itself cannot be made to > function without them..... and if it does, then it's design is poorly > conceived. > Well put. In light of that, where do you see the need for policy work? Are there places where ARIN policy is interfering with transition by unnecessarily bundling other considerations into addressing policy? Are there areas (such as the rules for justification of IP address space) where we haven't yet done enough to make the transition as painless as possible for everyone involved? Thanks, Scott From owen at delong.com Mon Nov 2 15:15:01 2009 From: owen at delong.com (Owen DeLong) Date: Mon, 2 Nov 2009 12:15:01 -0800 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <20091102175813.DE35D2B2113@mx5.roble.com> References: <20091102175813.DE35D2B2113@mx5.roble.com> Message-ID: On Nov 2, 2009, at 9:58 AM, Roger Marquis wrote: > Kevin Kargel wrote: >> NAT started out as a kludgy local workaround and will always pretty >> much be >> a local workaround. NAT is nothing more than a silly router trick. > > Whether or not NAT is "kludgy", a "workaround", or "silly" is an > opinion. > It is an opinion not supported by fact i.e., the market for end-node > network gear without NAT, which is effectively zero. As a result > arguments > against NAT are irrelevant. > True... More accurately, in IPv4, NAT is a necessary evil which is tolerated because of the serious shortage of IPv4 addresses. However, in IPv6, that shortage is not present and therefore, NAT moves from being a necessary evil to an UNnecessary evil. Owen From marquis at roble.com Mon Nov 2 15:17:51 2009 From: marquis at roble.com (Roger Marquis) Date: Mon, 2 Nov 2009 12:17:51 -0800 (PST) Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A0631410660251F175@mail> References: <20091102175813.DE35D2B2113@mx5.roble.com> <70DE64CEFD6E9A4EB7FAF3A0631410660251F175@mail> Message-ID: <20091102201751.C074A2B2110@mx5.roble.com> Kevin Kargel wrote: >> To state this another way, those of us who manage end-nodes will not be >> purchasing IPv6 network gear that fails to support a standardized version >> of NAT. Manufacturers will in turn not offer such equipment knowing it >> will not sell. How anyone can continue to argue that IPv6 does not >> require > I am by no means arguing that IPv6 does not require NAT Didn't mean to imply that you were, just that the implementation will need to be standardized in order to avoid interoperability issues, and that lack of interoperability is one of the two primary issues preventing IPv6 adoption. Didn't mean to imply that you were, just that the implementation will need to be standardized in order to avoid interoperability issues, and that lack or interoperability is preventing IPv6 adoption. >> NAT in light of this is beyond me, but I do hope you work for a >> competitor. > Wow, a little sensitive are we? It seems I struck a glancing blow to a > nerve here. I hope you read again, I was not arguing that NAT is not > needed, just that it is beside the point. Why argue about something that is > going to happen no matter what we say? Apologies Kevin. What I should have said is that I hope those who oppose NAT in IPv6 (on an abstract technical basis, see Lee Dilkie's post of 10/28 for a good example) are employed at competitors. Roger Marquis From scottleibrand at gmail.com Mon Nov 2 15:27:54 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 02 Nov 2009 12:27:54 -0800 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: References: Message-ID: <4AEF40CA.30502@gmail.com> So I take it you consider the existing ULA's "statistical uniqueness) to be sufficient? One thing I've heard a small amount of support for is to have RIRs register unique addresses that are intended to be used for private addressing, and assign them out of a range dedicated for that purpose. I'm not sure if that's necessary, myself, but I'm open to arguments from anyone who thinks so. -Scott Chris Engel wrote: > Scott, > > I really didn't mean to stir up the NAT hornets nest again. I was speaking in more general terms that things which do not specificaly NEED to be tied to IPv6 to make it function should not be. NAT was simply an example of my own particular pet-peeve area of this....I'm sure others here have thier own....some of which MAY actually involve ARIN policy. > > About the only thing that could be done policy-wise in regards the feasability of NAT in IPv6 is simply ensure that certain address space is reserved for Private Networks and will NEVER be handed out to anyone to be publicaly routed... just as the 10.x.x.x /8 and 192.168.x.x /16 spaces are currently reseved under IPv4. However, that seems to already be covered by rfc4193.... so I'm not sure there is a specific issue here.....other then to realize that the speed of IPv6 adoption may not be as quick as many here would hope for. > > > > Christopher Engel > > > -----Original Message----- > From: Scott Leibrand [mailto:scottleibrand at gmail.com] > Sent: Monday, November 02, 2009 2:00 PM > To: Chris Engel > Cc: 'arin-ppml at arin.net' > Subject: Re: [arin-ppml] IPv4 Depletion as an ARIN policy concern > > > Chris Engel wrote: > >> IPv6's best chance of adoption is to make the transition from IPv4 as >> seamless as possible for everyone involved. Which also largely means >> not necessitating a change of the methodologies and practices that >> people currently use with IPv4 more then is really required. It also >> means not tying other agenda's to IPv6's bandwagon. >> >> The one thing that I think pretty much everyone can agree is a >> positive with IPv6 is more address space available....at least I >> certainly don't think anyone would perceive that as a negative. The >> more things that you require people surrender in order to achieve that >> additional address space (in my case it would be primarily NAT... but >> it could be anything else for some-one else).... the less likely it is >> they are to determine the positives outweigh the negatives of >> adoption. >> >> If an argument is worthy of making (such as the idea that NAT is bad >> and need be eliminated).... let that crusade be fought SEPARATELY from >> IPv6. The same holds true for things ARIN is directly responsible >> for...such as rules for the justification of IP address space. >> >> IPv6 may ALLOW for those issues to be addressed (such as some make the >> case it allows for the obsolescence of NAT or far more liberal >> requirements for receiving address space)..... however it should not >> NECESSITATE that they be....unless IPv6 itself cannot be made to >> function without them..... and if it does, then it's design is poorly >> conceived. >> >> > > Well put. In light of that, where do you see the need for policy work? Are there places where ARIN policy is interfering with transition by unnecessarily bundling other considerations into addressing policy? Are there areas (such as the rules for justification of IP address space) where we haven't yet done enough to make the transition as painless as possible for everyone involved? > > Thanks, > Scott > From joelja at bogus.com Mon Nov 2 15:29:44 2009 From: joelja at bogus.com (joel jaeggli) Date: Mon, 02 Nov 2009 12:29:44 -0800 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern Message-ID: ULA-L is a v6 /8. that seems like enough private address space for most local network numbering needs... Chris Engel wrote: >Scott, > >I really didn't mean to stir up the NAT hornets nest again. I was speaking in more general terms that things which do not specificaly NEED to be tied to IPv6 to make it function should not be. NAT was simply an example of my own particular pet-peeve area of this....I'm sure others here have thier own....some of which MAY actually involve ARIN policy. > >About the only thing that could be done policy-wise in regards the feasability of NAT in IPv6 is simply ensure that certain address space is reserved for Private Networks and will NEVER be handed out to anyone to be publicaly routed... just as the 10.x.x.x /8 and 192.168.x.x /16 spaces are currently reseved under IPv4. However, that seems to already be covered by rfc4193.... so I'm not sure there is a specific issue here.....other then to realize that the speed of IPv6 adoption may not be as quick as many here would hope for. > > > >Christopher Engel > > >-----Original Message----- >From: Scott Leibrand [mailto:scottleibrand at gmail.com] >Sent: Monday, November 02, 2009 2:00 PM >To: Chris Engel >Cc: 'arin-ppml at arin.net' >Subject: Re: [arin-ppml] IPv4 Depletion as an ARIN policy concern > > >Chris Engel wrote: >> IPv6's best chance of adoption is to make the transition from IPv4 as >> seamless as possible for everyone involved. Which also largely means >> not necessitating a change of the methodologies and practices that >> people currently use with IPv4 more then is really required. It also >> means not tying other agenda's to IPv6's bandwagon. >> >> The one thing that I think pretty much everyone can agree is a >> positive with IPv6 is more address space available....at least I >> certainly don't think anyone would perceive that as a negative. The >> more things that you require people surrender in order to achieve that >> additional address space (in my case it would be primarily NAT... but >> it could be anything else for some-one else).... the less likely it is >> they are to determine the positives outweigh the negatives of >> adoption. >> >> If an argument is worthy of making (such as the idea that NAT is bad >> and need be eliminated).... let that crusade be fought SEPARATELY from >> IPv6. The same holds true for things ARIN is directly responsible >> for...such as rules for the justification of IP address space. >> >> IPv6 may ALLOW for those issues to be addressed (such as some make the >> case it allows for the obsolescence of NAT or far more liberal >> requirements for receiving address space)..... however it should not >> NECESSITATE that they be....unless IPv6 itself cannot be made to >> function without them..... and if it does, then it's design is poorly >> conceived. >> > >Well put. In light of that, where do you see the need for policy work? Are there places where ARIN policy is interfering with transition by unnecessarily bundling other considerations into addressing policy? Are there areas (such as the rules for justification of IP address space) where we haven't yet done enough to make the transition as painless as possible for everyone involved? > >Thanks, >Scott >_______________________________________________ >PPML >You are receiving this message because you are subscribed to >the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >Unsubscribe or manage your mailing list subscription at: >http://lists.arin.net/mailman/listinfo/arin-ppml >Please contact info at arin.net if you experience any issues. > From bill at herrin.us Mon Nov 2 16:07:43 2009 From: bill at herrin.us (William Herrin) Date: Mon, 2 Nov 2009 17:07:43 -0400 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <4AEF392C.3020107@gmail.com> References: <6652861E-150B-4E95-9298-D6CC048E5E5B@delong.com> <3c3e3fca0910301107i1699a390q6c52f81b5f2bd17b@mail.gmail.com> <332596.31946.qm@web63301.mail.re1.yahoo.com> <3c3e3fca0910311024x7ef383ddp810a6b199c49fb6b@mail.gmail.com> <589084.11764.qm@web63308.mail.re1.yahoo.com> <3c3e3fca0911011047g50377456mc7297ebfad6bf342@mail.gmail.com> <619507.62356.qm@web63306.mail.re1.yahoo.com> <3c3e3fca0911021150g6c51d93bw4dadfed4b120a9b0@mail.gmail.com> <4AEF392C.3020107@gmail.com> Message-ID: <3c3e3fca0911021307r730ee9a0vd02b4092b5fec5a1@mail.gmail.com> On Mon, Nov 2, 2009 at 3:55 PM, Scott Leibrand wrote: > In any event, do you see any particular areas where we could potentially > improve address policy in light of the issues raised in this thread? Scott, Not especially, no. I don't see any solutions to these issues within the scope of address policy. I do see unrelated avenues for improvement in policy. Expect a draft. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From cengel at sponsordirect.com Mon Nov 2 16:37:43 2009 From: cengel at sponsordirect.com (Chris Engel) Date: Mon, 2 Nov 2009 16:37:43 -0500 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <4AEF40CA.30502@gmail.com> Message-ID: >From what I understand the space covered by rfc4193 should be fine for the use in private networks.....assuming that ISP's don't try to consider themselves as "private networks" and use that space as routable within the bounds of their own subscriber networks.....and then stick some sort of services on there which their subscribers might need (like access to account status, etc). On the other hand what would be the consequences of the RIR's registering a unique address space in addition to that which could be utilized for private addressing? I assume it would reduce the size of the assignable IPv6 address pool.... but by how much actually? Given the size of the IPv6 address pool... would doing so have that significant an effect on it? Not that I know of any current justification for it now. However, I'm one of those people who would rather hold something back upfront (if the impact isn't significant) and risk that there may not be a use for it down the line...then not hold it back and discover later on that there was a good use that wasn't contemplated. Christopher Engel -----Original Message----- From: Scott Leibrand [mailto:scottleibrand at gmail.com] Sent: Monday, November 02, 2009 3:28 PM To: Chris Engel Cc: 'arin-ppml at arin.net' Subject: Re: [arin-ppml] IPv4 Depletion as an ARIN policy concern So I take it you consider the existing ULA's "statistical uniqueness) to be sufficient? One thing I've heard a small amount of support for is to have RIRs register unique addresses that are intended to be used for private addressing, and assign them out of a range dedicated for that purpose. I'm not sure if that's necessary, myself, but I'm open to arguments from anyone who thinks so. -Scott Chris Engel wrote: > Scott, > > I really didn't mean to stir up the NAT hornets nest again. I was > speaking in more general terms that things which do not specificaly > NEED to be tied to IPv6 to make it function should not be. NAT was > simply an example of my own particular pet-peeve area of this....I'm > sure others here have thier own....some of which MAY actually involve > ARIN policy. > > About the only thing that could be done policy-wise in regards the > feasability of NAT in IPv6 is simply ensure that certain address space > is reserved for Private Networks and will NEVER be handed out to > anyone to be publicaly routed... just as the 10.x.x.x /8 and > 192.168.x.x /16 spaces are currently reseved under IPv4. However, that > seems to already be covered by rfc4193.... so I'm not sure there is a > specific issue here.....other then to realize that the speed of IPv6 > adoption may not be as quick as many here would hope for. > > > > Christopher Engel > > > -----Original Message----- > From: Scott Leibrand [mailto:scottleibrand at gmail.com] > Sent: Monday, November 02, 2009 2:00 PM > To: Chris Engel > Cc: 'arin-ppml at arin.net' > Subject: Re: [arin-ppml] IPv4 Depletion as an ARIN policy concern > > > Chris Engel wrote: > >> IPv6's best chance of adoption is to make the transition from IPv4 as >> seamless as possible for everyone involved. Which also largely means >> not necessitating a change of the methodologies and practices that >> people currently use with IPv4 more then is really required. It also >> means not tying other agenda's to IPv6's bandwagon. >> >> The one thing that I think pretty much everyone can agree is a >> positive with IPv6 is more address space available....at least I >> certainly don't think anyone would perceive that as a negative. The >> more things that you require people surrender in order to achieve >> that additional address space (in my case it would be primarily >> NAT... but it could be anything else for some-one else).... the less >> likely it is they are to determine the positives outweigh the >> negatives of adoption. >> >> If an argument is worthy of making (such as the idea that NAT is bad >> and need be eliminated).... let that crusade be fought SEPARATELY >> from IPv6. The same holds true for things ARIN is directly >> responsible for...such as rules for the justification of IP address >> space. >> >> IPv6 may ALLOW for those issues to be addressed (such as some make >> the case it allows for the obsolescence of NAT or far more liberal >> requirements for receiving address space)..... however it should not >> NECESSITATE that they be....unless IPv6 itself cannot be made to >> function without them..... and if it does, then it's design is poorly >> conceived. >> >> > > Well put. In light of that, where do you see the need for policy > work? Are there places where ARIN policy is interfering with > transition by unnecessarily bundling other considerations into > addressing policy? Are there areas (such as the rules for > justification of IP address space) where we haven't yet done enough to > make the transition as painless as possible for everyone involved? > > Thanks, > Scott > From marquis at roble.com Mon Nov 2 16:54:27 2009 From: marquis at roble.com (Roger Marquis) Date: Mon, 2 Nov 2009 13:54:27 -0800 (PST) Subject: [arin-ppml] ARIN-PPML Digest, Vol 53, Issue 5 In-Reply-To: References: Message-ID: <20091102215427.5D84C2B2119@mx5.roble.com> he.net's Owen DeLong wrote: > ... in IPv4, NAT is a necessary evil which is tolerated because > of the serious shortage of IPv4 addresses. That is the one of the opinions not supported by the facts. You may not have been around before NAT Owen, but those of us who were had no problem getting address space. We still assigned illegal addresses because there was no business case for allowing internal networks to be publically routable. But I do understand where you are coming from, a large ISP who will monitize its IPv4 address space in the event of an IPv4 shortage. > However, in IPv6, that shortage is not present and therefore, > NAT moves from being a necessary evil to an UNnecessary evil. Amazing how network engineers can insist that real world managers, with real world issues, do not have a valid need for NAT. I wonder if he.net's Board of Directors concurs? Roger Marquis From owen at delong.com Mon Nov 2 17:15:22 2009 From: owen at delong.com (Owen DeLong) Date: Mon, 2 Nov 2009 14:15:22 -0800 Subject: [arin-ppml] ARIN-PPML Digest, Vol 53, Issue 5 In-Reply-To: <20091102215427.5D84C2B2119@mx5.roble.com> References: <20091102215427.5D84C2B2119@mx5.roble.com> Message-ID: <7B8D83E6-7BD2-4F6E-B28D-042FCE186C32@delong.com> On Nov 2, 2009, at 1:54 PM, Roger Marquis wrote: > he.net's Owen DeLong wrote: >> ... in IPv4, NAT is a necessary evil which is tolerated because >> of the serious shortage of IPv4 addresses. > > That is the one of the opinions not supported by the facts. You may > not > have been around before NAT Owen, but those of us who were had no > problem > getting address space. We still assigned illegal addresses because > there > was no business case for allowing internal networks to be publically > routable. > I was around before NAT. I was around well before NAT and I remember when NAT first hit the streets. I remember the networks with bogon addresses and the nightmares they caused when they suddenly found themselves trying to integrate with real networks that played by the rules. I don't expect it to be any different going forward with ULA or any of the other private address and/or NAT proposals out there. That doesn't make it any better of an idea now than it was then. > But I do understand where you are coming from, a large ISP who will > monitize its IPv4 address space in the event of an IPv4 shortage. > Uh, Say what? 1. While I work for an organization that may be considered a large ISP, I can tell you that as an organization, we think that the address market is a bad idea. 2. I was the ONLY vote on the ARIN AC in opposition to the transfer market policy. How, exactly, does that put me in the perspective of monetizing my IPv4 space? 3. NAT would actually make it easier for us to monetize our address space if that's what we wanted to do. >> However, in IPv6, that shortage is not present and therefore, >> NAT moves from being a necessary evil to an UNnecessary evil. > > Amazing how network engineers can insist that real world managers, > with > real world issues, do not have a valid need for NAT. I wonder if he.net > 's > Board of Directors concurs? I have no idea what HE.NET's board of directors thinks on the subject of NAT. I haven't asked them. I am not speaking here for HE.NET, and, the opinions expressed are the result of my 20+ years experience doing networking ranging from small enterprise to major corporation and from tiny ISP to major backbone provider. There are lots of valid needs for private addressing or non-routed addresses. There are lots of valid needs for filtration and stateful inspection firewalls. There are even valid needs for the ability to support VIP-like functionality. Not one of those things actually requires NAT. Owen Just my opinion, not necessarily agreed with by anyone. From bill at herrin.us Mon Nov 2 18:41:34 2009 From: bill at herrin.us (William Herrin) Date: Mon, 2 Nov 2009 19:41:34 -0400 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601F4A4DC@mail> References: <70DE64CEFD6E9A4EB7FAF3A06314106601F4A4DC@mail> Message-ID: <3c3e3fca0911021541k2b85bdb1s4617b29f18f4acb2@mail.gmail.com> On Mon, Nov 2, 2009 at 12:54 PM, Kevin Kargel wrote: > NAT started out as a kludgy local workaround and will always pretty much be > a local workaround. NAT started out as an improvement on SOCKS that allowed most applications to work unmodified. Understand why folks wanted the latter and you'll understand why they want the former. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From alh-ietf at tndh.net Mon Nov 2 19:17:34 2009 From: alh-ietf at tndh.net (Tony Hain) Date: Mon, 2 Nov 2009 16:17:34 -0800 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <4AEF40CA.30502@gmail.com> References: <4AEF40CA.30502@gmail.com> Message-ID: <000c01ca5c1b$0b249660$216dc320$@net> Scott Leibrand wrote: > So I take it you consider the existing ULA's "statistical uniqueness) > to > be sufficient? One thing I've heard a small amount of support for is > to > have RIRs register unique addresses that are intended to be used for > private addressing, and assign them out of a range dedicated for that > purpose. I'm not sure if that's necessary, myself, but I'm open to > arguments from anyone who thinks so. For many organizations the risks associated with 'statistical' are unacceptable, either based on bad experiences with IPv4 mergers, or based on interpretation of regulatory requirements to mitigate such risks. The original ULA-C work was tabled due to lack of PI policy, so it looked like an end-run around the RIR policy framework. Now that PI policy is in place it is time to complete that part of the story. I have resurrected the effort with the draft http://www.ietf.org/internet-drafts/draft-hain-ipv6-ulac-01.txt . Rather than focus on the process of managing that space, for the moment I just want to get the technical requirements clearly established. If ARIN (or any RIR) chooses not to participate in the allocation of this space, that is a separable policy discussion for another day. Until the ULA-C space is clearly allocated to IANA, that discussion can't reasonably happen. Tony From owen at delong.com Mon Nov 2 19:33:13 2009 From: owen at delong.com (Owen DeLong) Date: Mon, 2 Nov 2009 16:33:13 -0800 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <3c3e3fca0911021541k2b85bdb1s4617b29f18f4acb2@mail.gmail.com> References: <70DE64CEFD6E9A4EB7FAF3A06314106601F4A4DC@mail> <3c3e3fca0911021541k2b85bdb1s4617b29f18f4acb2@mail.gmail.com> Message-ID: On Nov 2, 2009, at 3:41 PM, William Herrin wrote: > On Mon, Nov 2, 2009 at 12:54 PM, Kevin Kargel > wrote: >> NAT started out as a kludgy local workaround and will always pretty >> much be >> a local workaround. > > NAT started out as an improvement on SOCKS that allowed most > applications to work unmodified. Understand why folks wanted the > latter and you'll understand why they want the former. > I don't buy this... SI started out as an improvement on SOCKS that allowed most applications to work unmodified. I can understand why folks wanted this, having run some SOCKS gateways and having worked with the guys at NEC that originally developed SOCKS. NAT was a kludge added to SI which allowed you to pack more addresses behind fewer addresses (or one address) by, essentially doing a statistical multiplexing of IP address+protocol+port number into a single 49 bit field which was dynamically assigned by the gateway. NAT restored the need to do application-specific weirdness to many applications which did not need such modifications for SI. If you look at it from this perspective, considering all the dysfunction created by overloading end system identifier semantics with network locator semantics (an error which was, unfortunately, preserved in IPv6), then, you can begin to see why further overloading is not necessarily a good thing. Owen From tedm at ipinc.net Mon Nov 2 20:16:38 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 02 Nov 2009 17:16:38 -0800 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: References: <70DE64CEFD6E9A4EB7FAF3A06314106601F4A4DC@mail> <3c3e3fca0911021541k2b85bdb1s4617b29f18f4acb2@mail.gmail.com> Message-ID: <4AEF8476.8030103@ipinc.net> Owen DeLong wrote: > > On Nov 2, 2009, at 3:41 PM, William Herrin wrote: > >> On Mon, Nov 2, 2009 at 12:54 PM, Kevin Kargel >> wrote: >>> NAT started out as a kludgy local workaround and will always pretty >>> much be >>> a local workaround. >> >> NAT started out as an improvement on SOCKS that allowed most >> applications to work unmodified. Understand why folks wanted the >> latter and you'll understand why they want the former. >> > I don't buy this... > Neither do I. > SI started out as an improvement on SOCKS that allowed most > applications to work unmodified. I can understand why folks wanted > this, having run some SOCKS gateways and having worked with > the guys at NEC that originally developed SOCKS. > > NAT was a kludge added to SI which allowed you to pack more > addresses behind fewer addresses (or one address) by, essentially > doing a statistical multiplexing of IP address+protocol+port number > into a single 49 bit field which was dynamically assigned by the > gateway. > > NAT restored the need to do application-specific weirdness to many > applications which did not need such modifications for SI. > > If you look at it from this perspective, considering all the dysfunction > created by overloading end system identifier semantics with network > locator semantics (an error which was, unfortunately, preserved in > IPv6), then, you can begin to see why further overloading is not > necessarily a good thing. > As I recall - having setup my then-employer behind a roll-your-own NAT on FreeBSD (using the kernel patches available then) back in 1997, the biggest advantage of NAT at the time was because so much stuff was statically assigned in the corporate network. It wasn't so much the typing of the IP addresses into the clients. It was because so many APPLICATIONS used statics. I STILL to this day see this - as an example, take the Rosetta foreign language learning software. To this very day when you setup a Rosetta client in a network with a floating license server, the client configuration software demands you key in the IP address of the license server during the setup of the client. (on the OSX clients at least) They use flexlm for that, by the way. The problem as I see it is that a tremendously significant number of corporate software application developers don't know squat about networking. They may know how to write a network application but their knowledge of it's interface to the network is restricted to the OS APIs and they often will take shortcuts - such as not allowing for a user to fill in a name, then doing a DNS query for it - if they think they can get away with them. I fully expect that some of these boneheads will be expecting the users to key in the entire 128 bit address when they are finally forced to write in IPv6 compatibility. NATs allowed me to statically assign an IP number to a server then I knew that years later I wouldn't have to renumber it and find all of the clients that had it hard-coded, just because I decided to switch ISPs Otherwise, NATs in a corporate environment are a royal PIA. Most everyone uses 192.168.1.x or 192.168.0.x because that's the default address on their router, and then when you try to setup a VPN from company to company (which happens a lot more than you think) you have trouble. I had a customer of the ISP call me the other day and complain about this - she was a consultant who worked out of her home and she was trying to VPN into 3 different clients of hers at once - all 3 running 192.168.1.x She tends to duplicate templates and such across clients and now she has to disconnect from one and connect to another then disconnect from that one and connect to the first again just to copy over a template file. Really stupid, drives up her time, drives up their bills. Ted From bill at herrin.us Mon Nov 2 21:15:08 2009 From: bill at herrin.us (William Herrin) Date: Mon, 2 Nov 2009 21:15:08 -0500 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: References: <70DE64CEFD6E9A4EB7FAF3A06314106601F4A4DC@mail> <3c3e3fca0911021541k2b85bdb1s4617b29f18f4acb2@mail.gmail.com> Message-ID: <3c3e3fca0911021815o15b22dc4n6b38b24362485ca8@mail.gmail.com> On Mon, Nov 2, 2009 at 7:33 PM, Owen DeLong wrote: > On Nov 2, 2009, at 3:41 PM, William Herrin wrote: >> On Mon, Nov 2, 2009 at 12:54 PM, Kevin Kargel >> wrote: >>> NAT started out as a kludgy local workaround and will always pretty much >>> be >>> a local workaround. >> >> NAT started out as an improvement on SOCKS that allowed most >> applications to work unmodified. Understand why folks wanted the >> latter and you'll understand why they want the former. >> > I don't buy this... Owen, IIRC, SOCKS came out in '92, TIS came along in '94 with a DARPA-funded set of ALG's which were better. Then they improved those ALGs into something they called "transparent proxyies" in their expensive commercial firewall. That was the first thing that looked like what we today call a NAT and what Cisco still insists on calling PAT. Non-overloaded NAT came from a different direction, I'm not sure where. I'm almost willing to buy the notion that stateful firewalls with decent dynamic address management provides comparable capability to non-overloaded NAT. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From joelja at bogus.com Mon Nov 2 22:12:13 2009 From: joelja at bogus.com (joel jaeggli) Date: Mon, 02 Nov 2009 19:12:13 -0800 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <4AEF40CA.30502@gmail.com> References: <4AEF40CA.30502@gmail.com> Message-ID: <4AEF9F8D.5020902@bogus.com> Scott Leibrand wrote: > So I take it you consider the existing ULA's "statistical uniqueness) to > be sufficient? One thing I've heard a small amount of support for is to > have RIRs register unique addresses that are intended to be used for > private addressing, and assign them out of a range dedicated for that > purpose. I'm not sure if that's necessary, myself, but I'm open to > arguments from anyone who thinks so. Private address space isn't unique in v4 or v6 if you follow the ula-l guidelines you get statistically non-intersecting but your uniqueness guarantee isn't present. just like it isn't in ipv4. if this where a problem in ipv4 no one would use it... ula-c is dead. joel > -Scott > > Chris Engel wrote: >> Scott, >> >> I really didn't mean to stir up the NAT hornets nest again. I was >> speaking in more general terms that things which do not specificaly >> NEED to be tied to IPv6 to make it function should not be. NAT was >> simply an example of my own particular pet-peeve area of this....I'm >> sure others here have thier own....some of which MAY actually involve >> ARIN policy. >> >> About the only thing that could be done policy-wise in regards the >> feasability of NAT in IPv6 is simply ensure that certain address space >> is reserved for Private Networks and will NEVER be handed out to >> anyone to be publicaly routed... just as the 10.x.x.x /8 and >> 192.168.x.x /16 spaces are currently reseved under IPv4. However, that >> seems to already be covered by rfc4193.... so I'm not sure there is a >> specific issue here.....other then to realize that the speed of IPv6 >> adoption may not be as quick as many here would hope for. >> >> >> >> Christopher Engel >> >> >> -----Original Message----- >> From: Scott Leibrand [mailto:scottleibrand at gmail.com] >> Sent: Monday, November 02, 2009 2:00 PM >> To: Chris Engel >> Cc: 'arin-ppml at arin.net' >> Subject: Re: [arin-ppml] IPv4 Depletion as an ARIN policy concern >> >> >> Chris Engel wrote: >> >>> IPv6's best chance of adoption is to make the transition from IPv4 as >>> seamless as possible for everyone involved. Which also largely means >>> not necessitating a change of the methodologies and practices that >>> people currently use with IPv4 more then is really required. It also >>> means not tying other agenda's to IPv6's bandwagon. >>> >>> The one thing that I think pretty much everyone can agree is a >>> positive with IPv6 is more address space available....at least I >>> certainly don't think anyone would perceive that as a negative. The >>> more things that you require people surrender in order to achieve that >>> additional address space (in my case it would be primarily NAT... but >>> it could be anything else for some-one else).... the less likely it is >>> they are to determine the positives outweigh the negatives of >>> adoption. >>> >>> If an argument is worthy of making (such as the idea that NAT is bad >>> and need be eliminated).... let that crusade be fought SEPARATELY from >>> IPv6. The same holds true for things ARIN is directly responsible >>> for...such as rules for the justification of IP address space. >>> >>> IPv6 may ALLOW for those issues to be addressed (such as some make the >>> case it allows for the obsolescence of NAT or far more liberal >>> requirements for receiving address space)..... however it should not >>> NECESSITATE that they be....unless IPv6 itself cannot be made to >>> function without them..... and if it does, then it's design is poorly >>> conceived. >>> >>> >> >> Well put. In light of that, where do you see the need for policy >> work? Are there places where ARIN policy is interfering with >> transition by unnecessarily bundling other considerations into >> addressing policy? Are there areas (such as the rules for >> justification of IP address space) where we haven't yet done enough to >> make the transition as painless as possible for everyone involved? >> >> Thanks, >> Scott >> > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From joelja at bogus.com Tue Nov 3 00:05:55 2009 From: joelja at bogus.com (joel jaeggli) Date: Mon, 02 Nov 2009 21:05:55 -0800 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <000c01ca5c1b$0b249660$216dc320$@net> References: <4AEF40CA.30502@gmail.com> <000c01ca5c1b$0b249660$216dc320$@net> Message-ID: <4AEFBA33.1080201@bogus.com> Tony Hain wrote: > Scott Leibrand wrote: >> So I take it you consider the existing ULA's "statistical uniqueness) >> to >> be sufficient? One thing I've heard a small amount of support for is >> to >> have RIRs register unique addresses that are intended to be used for >> private addressing, and assign them out of a range dedicated for that >> purpose. I'm not sure if that's necessary, myself, but I'm open to >> arguments from anyone who thinks so. > > > For many organizations the risks associated with 'statistical' are > unacceptable, either based on bad experiences with IPv4 mergers, or based on > interpretation of regulatory requirements to mitigate such risks. it's no worse than what they do with ipv4 today, along many dimensions it's better. > The > original ULA-C work was tabled due to lack of PI policy, so it looked like > an end-run around the RIR policy framework. Now that PI policy is in place > it is time to complete that part of the story. I have resurrected the effort > with the draft > http://www.ietf.org/internet-drafts/draft-hain-ipv6-ulac-01.txt . I'm not sure that the existance of proof longer prefix assignments than a /32 (we're happy with our /43 btw) obviates the principle objection to ula-c namely that if there exists a lower barrier to entry on the availability of ula-c space then there is for pi-space that the temptation to shop for an upstream willing to route it is extremely high. Private address space needs to be sufficiently toxic that no-one will consider routing it... ula-l actually achieves that. > Rather than focus on the process of managing that space, for the moment I > just want to get the technical requirements clearly established. If ARIN (or > any RIR) chooses not to participate in the allocation of this space, that is > a separable policy discussion for another day. Until the ULA-C space is > clearly allocated to IANA, that discussion can't reasonably happen. using unique public addresses for my private application, confers the salubrious benefit of being able to advertise and then black hole all traffic bound for those prefixes externally which I find quite attractive personally. > Tony > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From alh-ietf at tndh.net Thu Nov 5 12:51:55 2009 From: alh-ietf at tndh.net (Tony Hain) Date: Thu, 5 Nov 2009 09:51:55 -0800 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <4AEFBA33.1080201@bogus.com> References: <4AEF40CA.30502@gmail.com> <000c01ca5c1b$0b249660$216dc320$@net> <4AEFBA33.1080201@bogus.com> Message-ID: <004c01ca5e40$aa22b680$fe682380$@net> joel jaeggli wrote: > Tony Hain wrote: > > Scott Leibrand wrote: > >> So I take it you consider the existing ULA's "statistical > uniqueness) > >> to > >> be sufficient? One thing I've heard a small amount of support for > is > >> to > >> have RIRs register unique addresses that are intended to be used for > >> private addressing, and assign them out of a range dedicated for > that > >> purpose. I'm not sure if that's necessary, myself, but I'm open to > >> arguments from anyone who thinks so. > > > > > > For many organizations the risks associated with 'statistical' are > > unacceptable, either based on bad experiences with IPv4 mergers, or > based on > > interpretation of regulatory requirements to mitigate such risks. > > it's no worse than what they do with ipv4 today, along many dimensions > it's better. Current IPv4 practice is insufficient for many, but all that is technically possible. There is no reason to artificially deny the technical capacity to do better than current practice. > > > The > > original ULA-C work was tabled due to lack of PI policy, so it looked > like > > an end-run around the RIR policy framework. Now that PI policy is in > place > > it is time to complete that part of the story. I have resurrected the > effort > > with the draft > > http://www.ietf.org/internet-drafts/draft-hain-ipv6-ulac-01.txt . > > I'm not sure that the existance of proof longer prefix assignments than > a /32 (we're happy with our /43 btw) obviates the principle objection > to > ula-c namely that if there exists a lower barrier to entry on the > availability of ula-c space then there is for pi-space that the > temptation to shop for an upstream willing to route it is extremely > high. > > Private address space needs to be sufficiently toxic that no-one will > consider routing it... ula-l actually achieves that. Or conversely, PI availability needs to have a sufficiently low barrier to make it the preferred path for people that really want public routing. > > > Rather than focus on the process of managing that space, for the > moment I > > just want to get the technical requirements clearly established. If > ARIN (or > > any RIR) chooses not to participate in the allocation of this space, > that is > > a separable policy discussion for another day. Until the ULA-C space > is > > clearly allocated to IANA, that discussion can't reasonably happen. > > using unique public addresses for my private application, confers the > salubrious benefit of being able to advertise and then black hole all > traffic bound for those prefixes externally which I find quite > attractive personally. Then do that for your network. Others have different requirements where use of a ula-c for private interconnects with PI for the public interconnect is operationally simpler and lower cost. There is nothing about the existence of ula-c that mandates its use. The FUD about ula-c being a source of routing table bloat is really about an overly restrictive PI policy. The simplest solution to mitigate misuse of ula-c is to have the same organization deal with allocations, then if misuse becomes widespread revise the PI policy to make that be the lowest cost path for the abusers. > > > Tony > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > From info at arin.net Thu Nov 5 13:46:45 2009 From: info at arin.net (Member Services) Date: Thu, 05 Nov 2009 13:46:45 -0500 Subject: [arin-ppml] Policy Proposal 102: Reduce and Simplify IPv4 Initial Allocations Message-ID: <4AF31D95.9050605@arin.net> ARIN received the following policy proposal and is posting it to the Public Policy Mailing List (PPML) in accordance with Policy Development Process. This proposal is in the first stage of the Policy Development Process. ARIN staff will perform the Clarity and Understanding step. Staff does not evaluate the proposal at this time, their goal is to make sure that they understand the proposal and believe the community will as well. Staff will report their results to the ARIN Advisory Council (AC) within 10 days. The AC will review the proposal at their next regularly scheduled meeting (if the period before the next regularly scheduled meeting is less than 10 days, then the period may be extended to the subsequent regularly scheduled meeting). The AC will decide how to utilize the proposal and announce the decision to the PPML. In the meantime, the AC invites everyone to comment on the proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Mailing list subscription information can be found at: https://www.arin.net/mailing_lists/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 102: Reduce and Simplify IPv4 Initial Allocations Proposal Originator: Chris Grundemann & Ted Mittelstaedt Proposal Version: 1 Date: 5 November 2009 Proposal type: modify Policy term: permanent Policy statement: Modify section 4.2.1.5. Minimum allocation: In general, ARIN allocates IP address prefixes no longer than /23 to ISPs. If allocations smaller than /23 are needed, ISPs should request address space from their upstream provider. When prefixes are assigned which are longer than /20, they will be from a block reserved for that purpose whenever that is feasible. And Replace the contents of section 4.2.2. Initial allocation to ISPs: 4.2.2.1. Use of /24 The efficient utilization of an entire previously allocated /24 from their upstream ISP. 4.2.2.2. Efficient utilization Demonstrate efficient use of IP address space allocations by providing appropriate documentation, including assignment histories, showing their efficient use. ISPs must provide reassignment information on the entire previously allocated block(s) via SWIP or RWHOIS server for /29 or larger blocks. For blocks smaller than /29 and for internal space, ISPs should provide utilization data either via SWIP or RWHOIS server or by using the table format described in Section 4.2.3.7.5. 4.2.2.3. Three months Provide detailed information showing specifically how the initial allocation will be utilized within three months. 4.2.2.4. Renumber and return ISPs receiving an initial allocation smaller than /20 must agree that the newly requested IP address space will be used to renumber out of the current addresses which will be returned to the assigning organization within 12 months. ISPs receiving an initial allocation equal to or larger than /20 may wish to renumber out of their previously allocated space. In this case, an ISP must use the new prefix to renumber out of that previously allocated block of address space and must return the space to its upstream provider. 4.2.2.5. Replacement initial allocation Any ISP which has received an initial allocation, or previous replacement initial allocation, smaller than /20 who wishes to receive additional address space must request a replacement initial allocation. To receive a replacement initial allocation, an ISP must agree to renumber out of and return the existing allocation in it's entirety within 12 months of receiving a new allocation and provide justification for the new allocation as described in section 4.2.4. Rationale: This policy proposal fundamentally changes and simplifies the initial IPv4 allocations to ISPs by doing the following: 1) Makes moot whether the requesting ISP is multihomed or not, with this policy change all initial ISPs request under the same minimums. 2) Lowers the minimums, making it easier for smaller ISPs to qualify for direct allocations from ARIN. 3) Reduces fragmentation of the allocated IPv4 pool by forcing smaller ISPs who do qualify under the minimum to return the small allocation when they outgrow it. Note particularly that this does not "change the bar" for ISPs who have already received small allocations, as they will have not agreed to return those smaller allocations when they get larger allocations. 4) Indirectly encourages the adoption of IPv6 as the ISPs that now qualify for numbering under this policy change will be considered an LIR and thus satisfy one of the IPv6 requirements in section 6.5.1.1 This policy proposal idea grew out of Proposal 98 and 100 and the discussions surrounding those proposals as well as many discussions on the ppml and on arin-discuss mailing lists. For starters, it's well known that while transit networks have the ability to filter IPv4 BGP advertisements, few to none filter anything larger than a /24 (any who do filter /24 or larger have a default route to fall back on), and a /24 (for perhaps no better reason than it happens to be a "class C") has become the de-facto standard minimum. As a result, assigning blocks smaller than a /22 (the current minimum under 4.2.2) isn't going to break anything. Secondly, the primary motivator for denying smaller ISPs an initial allocation from ARIN is to slow the growth of the DFZ, due to concerns that growth of the so-called "IPv4 global routing table" would exceed memory requirements in routers operated by transit networks. This is why Section 4.2.2 was split into multihomed and non-multihomed in the first place, to help "raise the bar" and prevent a land rush. Section 4.2.2.1 makes it so that only really large ISPs qualify for an initial allocation, Section 4.2.2.2 makes it so that only ISPs with the financial ability to bring in multiple feeds can qualify. Basically, your either big and poor or small and rich - whereas the typical "garage operator" ISP would be small and poor. Our belief is that while this may have worked a decade ago, it's a moot issue now. For one thing, nothing prevents orgs that obtain larger allocations from splitting their advertisements. For example an org that has a /22 and 2 feeds, one larger than the other, might choose to advertise 2 /23's so they can prepend one of the /23's towards the smaller feed, so as to reduce traffic. Orgs that have distributed NOCS and even larger allocations have also done this for traffic flow reasons. There is no real guarantee than an org getting a contiguous block will actually advertise it under a single route entry, so it seems somewhat hypocritical to deny smaller ISPs an initial allocation because of the reason that small allocations clog up the so-called "global route table" when larger ISPs can and sometimes do clog it up by subnetting. The Internet landscape has changed tremendously, it is much more expensive now for "garage operators" to initiate operations, and the ISP industry has had a lot of consolidation. These factors are much more of a deterrent to small operators getting started and wanting an initial allocation. And, with small operators, labor is costly and renumbering out of an upstream-assigned IPv4 block is a big barrier as well. We feel that allowing smaller ISPs to qualify now for IPv4 will have a number of benefits: 1) It's possible that post-IPv4 runout, financial pressure to justify assignments will develop among transit networks as the "market rate" of IPv4 rises. That may lead to smaller ISPs who don't have their own assignments to be pressured to shrink operations (or be pushed out completely), by upstreams eager to sell IPv4 blocks on the transfer market. 2) Sometimes an issue is helped more by being "nibbled to death by ducks". If a large number of small ISPs were to obtain IPv4 and follow up by obtaining IPv6 at the same time, the cumulative effect of many small operators calling their upstreams and pressuring their upstreams to supply native IPv6 routing might be much stronger - and might cause more of them to get on the ball with IPv6 deployments. 3) Small IPv4 subnets that a /23 or /22 allocation can be made from will be increasingly available to ARIN from reclamation efforts, thus allocating small subnets that the RIR generates from these efforts to legitimate ISPs will help to prevent "squatting" on them from spammers and other network criminals, without consuming "virgin" blocks in the free pool. It might even be possible for ARIN to use portions of the "old swamp" (ie: 192.5.0.0/16, 192.12.0.0/16, 192.16.0.0/16, etc.) for this. Timetable for implementation: immediate From BillD at cait.wustl.edu Thu Nov 5 13:52:37 2009 From: BillD at cait.wustl.edu (Bill Darte) Date: Thu, 5 Nov 2009 12:52:37 -0600 Subject: [arin-ppml] Election Results - Congratulations Message-ID: Congratulations to all those elected on the ARIN Board and Advisory Council.. I look forward to working with each of you in the coming months and years! Bill Darte ARIN Ac From sethm at rollernet.us Thu Nov 5 17:46:59 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 05 Nov 2009 14:46:59 -0800 Subject: [arin-ppml] Policy Proposal 102: Reduce and Simplify IPv4 Initial Allocations In-Reply-To: <4AF31D95.9050605@arin.net> References: <4AF31D95.9050605@arin.net> Message-ID: <4AF355E3.4010901@rollernet.us> Member Services wrote: > > 4.2.2.5. Replacement initial allocation > > Any ISP which has received an initial allocation, or previous > replacement initial allocation, smaller than /20 who wishes to receive > additional address space must request a replacement initial > allocation. To receive a replacement initial allocation, an ISP must > agree to renumber out of and return the existing allocation in it's > entirety within 12 months of receiving a new allocation and provide > justification for the new allocation as described in section 4.2.4. > OPPOSE. A small org might expect to grow and can be punished multiple times (until they get a /20) by forced renumbering. An end-site office building, sure, force them to renumber, but not an ISP who is assigning address blocks to downstream orgs and customers. ~Seth From jweyand at computerdata.com Thu Nov 5 18:06:52 2009 From: jweyand at computerdata.com (Jim Weyand) Date: Thu, 5 Nov 2009 18:06:52 -0500 Subject: [arin-ppml] Policy Proposal 102: Reduce and Simplify IPv4 Initial Allocations References: <4AF31D95.9050605@arin.net> <4AF355E3.4010901@rollernet.us> Message-ID: <1582DCBFF968F044A9A910C0AB177C90461521@cliff.cdi.local> +1 -----Original Message----- From: Seth Mattinen [mailto:sethm at rollernet.us] Sent: Thursday, November 05, 2009 5:47 PM To: arin-ppml at arin.net Subject: Re: [arin-ppml] Policy Proposal 102: Reduce and Simplify IPv4 Initial Allocations Member Services wrote: > > 4.2.2.5. Replacement initial allocation > > Any ISP which has received an initial allocation, or previous > replacement initial allocation, smaller than /20 who wishes to receive > additional address space must request a replacement initial > allocation. To receive a replacement initial allocation, an ISP must > agree to renumber out of and return the existing allocation in it's > entirety within 12 months of receiving a new allocation and provide > justification for the new allocation as described in section 4.2.4. > OPPOSE. A small org might expect to grow and can be punished multiple times (until they get a /20) by forced renumbering. An end-site office building, sure, force them to renumber, but not an ISP who is assigning address blocks to downstream orgs and customers. ~Seth _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From owen at delong.com Thu Nov 5 18:55:01 2009 From: owen at delong.com (Owen DeLong) Date: Thu, 5 Nov 2009 15:55:01 -0800 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <004c01ca5e40$aa22b680$fe682380$@net> References: <4AEF40CA.30502@gmail.com> <000c01ca5c1b$0b249660$216dc320$@net> <4AEFBA33.1080201@bogus.com> <004c01ca5e40$aa22b680$fe682380$@net> Message-ID: <49BB5082-EA12-429E-9806-6B9B04387996@delong.com> >> > > Then do that for your network. Others have different requirements > where use of a ula-c for private interconnects with PI for the > public interconnect is operationally simpler and lower cost. There > is nothing about the existence of ula-c that mandates its use. The > FUD about ula-c being a source of routing table bloat is really > about an overly restrictive PI policy. The simplest solution to > mitigate misuse of ula-c is to have the same organization deal with > allocations, then if misuse becomes widespread revise the PI policy > to make that be the lowest cost path for the abusers. > I agree that the PI barriers should be lower. However, ULA-C is definitely a potential end-run on the public policy process and, mark my words, will end up being routed as soon as there are $$$ behind the desire to route it. The only way to prevent such abuse of ULA-C in most cases (and still not all) would be for ULA-C and PI to have identical policies administered by the same organizations. At that point, what would be the advantage of ULA-C vs. standard assignments? Nothing about receiving a standard prefix mandates you routing it. Owen From cgrundemann at gmail.com Fri Nov 6 00:06:15 2009 From: cgrundemann at gmail.com (Chris Grundemann) Date: Thu, 5 Nov 2009 22:06:15 -0700 Subject: [arin-ppml] Policy Proposal 102: Reduce and Simplify IPv4 Initial Allocations In-Reply-To: <4AF355E3.4010901@rollernet.us> References: <4AF31D95.9050605@arin.net> <4AF355E3.4010901@rollernet.us> Message-ID: <443de7ad0911052106p1e300089j376cd7c2334187a5@mail.gmail.com> On Thu, Nov 5, 2009 at 15:46, Seth Mattinen wrote: > Member Services wrote: >> >> 4.2.2.5. Replacement initial allocation >> >> Any ISP which has received an initial allocation, or previous >> replacement initial allocation, smaller than /20 who wishes to receive >> additional address space must request a replacement initial >> allocation. To receive a replacement initial allocation, an ISP must >> agree to renumber out of and return the existing allocation in it's >> entirety within 12 months of receiving a new allocation and provide >> justification for the new allocation as described in section 4.2.4. >> > > OPPOSE. A small org might expect to grow and can be punished multiple > times (until they get a /20) by forced renumbering. An end-site office > building, sure, force them to renumber, but not an ISP who is assigning > address blocks to downstream orgs and customers. So, just to be clear Seth; you would rather that small ISP not be able to get resources from ARIN at all then for them to be eligible but have to renumber? ~Chris > > ~Seth > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org From sethm at rollernet.us Fri Nov 6 01:31:29 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 05 Nov 2009 22:31:29 -0800 Subject: [arin-ppml] Policy Proposal 102: Reduce and Simplify IPv4 Initial Allocations In-Reply-To: <443de7ad0911052106p1e300089j376cd7c2334187a5@mail.gmail.com> References: <4AF31D95.9050605@arin.net> <4AF355E3.4010901@rollernet.us> <443de7ad0911052106p1e300089j376cd7c2334187a5@mail.gmail.com> Message-ID: <4AF3C2C1.70105@rollernet.us> Chris Grundemann wrote: > On Thu, Nov 5, 2009 at 15:46, Seth Mattinen wrote: >> Member Services wrote: >>> 4.2.2.5. Replacement initial allocation >>> >>> Any ISP which has received an initial allocation, or previous >>> replacement initial allocation, smaller than /20 who wishes to receive >>> additional address space must request a replacement initial >>> allocation. To receive a replacement initial allocation, an ISP must >>> agree to renumber out of and return the existing allocation in it's >>> entirety within 12 months of receiving a new allocation and provide >>> justification for the new allocation as described in section 4.2.4. >>> >> OPPOSE. A small org might expect to grow and can be punished multiple >> times (until they get a /20) by forced renumbering. An end-site office >> building, sure, force them to renumber, but not an ISP who is assigning >> address blocks to downstream orgs and customers. > > So, just to be clear Seth; you would rather that small ISP not be able > to get resources from ARIN at all then for them to be eligible but > have to renumber? > ~Chris > If I'm reading the policy correctly, PA->23 is a renumber, 23->22 is a renumber, 22->21 is a renumber, and 21->20 is a renumber. That's four potential renumbering cycles, each one exponentially harder. Renumbering sucks. I still have people trying to reference PA addresses I returned over half a decade ago (and complaining about it) in spite of every humanly effort possible. It's relatively easy to get PI space under the current policy. A PA /24 can be had like candy if you say the magic word "multihoming", and another /24 can be easily justified with proper planning if you're for real. Or just tell two different upstreams you're multihoming and ta-da, you have two /24's. Looking at myself, had such a policy been in place when I just recently needed to get more space after my initial /22 to open up the floor for more colos, it very well could have broken my business. Ignoring the aspect of forcing customers you've reassigned space to to renumber, I've worked very, very hard to defend and establish what I hope is a good reputation for my PI space. Then there's whatever static whitelists it may be in out there in the world (that I could never hope to find or update) plus everything customers have configured in their systems. To throw it all away and start over would be a nightmare. I'd rather only have to renumber once out of PA into PI space (which I did over the span of 6 months). This may or may not be unique to me. I like the idea as it would apply to an end-site office or something - they can eat the renumbers 'til the cows come home if they want more space and return the smaller piece. But for any service provider who may be reassigning address space to systems/networks/entities beyond their reasonable control or have a guarded reputation attached to it, you could end up losing customers to someone who has stable addressing if the customer realizes they have to renumber either way. ~Seth From cgrundemann at gmail.com Fri Nov 6 04:57:51 2009 From: cgrundemann at gmail.com (Chris Grundemann) Date: Fri, 6 Nov 2009 02:57:51 -0700 Subject: [arin-ppml] Policy Proposal 102: Reduce and Simplify IPv4 Initial Allocations In-Reply-To: <4AF3C2C1.70105@rollernet.us> References: <4AF31D95.9050605@arin.net> <4AF355E3.4010901@rollernet.us> <443de7ad0911052106p1e300089j376cd7c2334187a5@mail.gmail.com> <4AF3C2C1.70105@rollernet.us> Message-ID: <443de7ad0911060157r763c9995nc4e6f681816e1397@mail.gmail.com> On Thu, Nov 5, 2009 at 23:31, Seth Mattinen wrote: > Chris Grundemann wrote: >> On Thu, Nov 5, 2009 at 15:46, Seth Mattinen wrote: >>> Member Services wrote: >>>> 4.2.2.5. Replacement initial allocation >>>> >>>> Any ISP which has received an initial allocation, or previous >>>> replacement initial allocation, smaller than /20 who wishes to receive >>>> additional address space must request a replacement initial >>>> allocation. To receive a replacement initial allocation, an ISP must >>>> agree to renumber out of and return the existing allocation in it's >>>> entirety within 12 months of receiving a new allocation and provide >>>> justification for the new allocation as described in section 4.2.4. >>>> >>> OPPOSE. A small org might expect to grow and can be punished multiple >>> times (until they get a /20) by forced renumbering. An end-site office >>> building, sure, force them to renumber, but not an ISP who is assigning >>> address blocks to downstream orgs and customers. >> >> So, just to be clear Seth; you would rather that small ISP not be able >> to get resources from ARIN at all then for them to be eligible but >> have to renumber? >> ~Chris >> > > > If I'm reading the policy correctly, PA->23 is a renumber, 23->22 is a > renumber, 22->21 is a renumber, and 21->20 is a renumber. That's four > potential renumbering cycles, each one exponentially harder. Renumbering > sucks. I still have people trying to reference PA addresses I returned > over half a decade ago (and complaining about it) in spite of every > humanly effort possible. > > It's relatively easy to get PI space under the current policy. A PA /24 > can be had like candy if you say the magic word "multihoming", and > another /24 can be easily justified with proper planning if you're for > real. Or just tell two different upstreams you're multihoming and ta-da, > you have two /24's. > > Looking at myself, had such a policy been in place when I just recently > needed to get more space after my initial /22 to open up the floor for > more colos, it very well could have broken my business. Ignoring the > aspect of forcing customers you've reassigned space to to renumber, I've > worked very, very hard to defend and establish what I hope is a good > reputation for my PI space. Then there's whatever static whitelists it > may be in out there in the world (that I could never hope to find or > update) plus everything customers have configured in their systems. To > throw it all away and start over would be a nightmare. I'd rather only > have to renumber once out of PA into PI space (which I did over the span > of 6 months). This may or may not be unique to me. Would you support the proposal if it only had a renumbering requirement up to /22 (the current minimum initial allocation for multihomed ISPs)? That would still help keep the impact of lowering the minimum initial allocation on the routing table down but would not introduce any new barriers to ISPs qualify under current policy either. The general intent of this policy is to make things easier for very small ISPs while balancing any side effects for the rest of the community. ~Chris > > I like the idea as it would apply to an end-site office or something - > they can eat the renumbers 'til the cows come home if they want more > space and return the smaller piece. But for any service provider who may > be reassigning address space to systems/networks/entities beyond their > reasonable control or have a guarded reputation attached to it, you > could end up losing customers to someone who has stable addressing if > the customer realizes they have to renumber either way. > > ~Seth > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org From rudi.daniel at gmail.com Fri Nov 6 07:41:53 2009 From: rudi.daniel at gmail.com (RudOlph Daniel) Date: Fri, 6 Nov 2009 07:41:53 -0500 Subject: [arin-ppml] ARIN Board/AC Message-ID: <8aeeaff60911060441g408fb1d2j3770bf0a1b5a3021@mail.gmail.com> I would like to thank all those persons who supported me and also congratulate those were were elected to serve on the Board and the AC. Rudi Daniel > Congratulations to all those elected on the ARIN Board and Advisory > Council.. > > I look forward to working with each of you in the coming months and > years! > > Bill Darte > ARIN Ac > -------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Fri Nov 6 09:34:03 2009 From: bill at herrin.us (William Herrin) Date: Fri, 6 Nov 2009 09:34:03 -0500 Subject: [arin-ppml] Policy Proposal 102: Reduce and Simplify IPv4 Initial Allocations In-Reply-To: <4AF31D95.9050605@arin.net> References: <4AF31D95.9050605@arin.net> Message-ID: <3c3e3fca0911060634u4a5b11c1g7fc3371d0158c2ae@mail.gmail.com> On Thu, Nov 5, 2009 at 1:46 PM, Member Services wrote: > Policy Proposal 102: Reduce and Simplify IPv4 Initial Allocations Hi folks, Some comments: 1. The proposal neither reduces nor simplifies IPv4 allocations. Arguably it improves them but you should consider finding a better title. 2. A replacement allocation is no longer an initial allocation. Initial means "first" not "only one still held." > 4.2.2.1. Use of /24 > > The efficient utilization of an entire previously allocated /24 from > their upstream ISP. Do you intend the explicit use of a /24 or do you intend the use of address space which adds up to at least a /24? > 1) Makes moot whether the requesting ISP is multihomed or not, with > this policy change all initial ISPs request under the same minimums. I disagree with offering small PI blocks to entities which are not multihomed. While any registrants benefit from receiving a PI block, only multihomed entities do so without creating new overhead cost for everybody else. I OPPOSE the proposal as written because it fails to restrict itself to multihomed entities. I would support the proposal if it restricted itself to multihomed registrants. On Thu, Nov 5, 2009 at 5:46 PM, Seth Mattinen wrote: >> 4.2.2.5. Replacement initial allocation > > OPPOSE. A small org might expect to grow and can be punished multiple > times (until they get a /20) by forced renumbering. An end-site office > building, sure, force them to renumber, but not an ISP who is assigning > address blocks to downstream orgs and customers. Hi Seth, Would you clarify: do you mean that you oppose the proposal solely because it *doesn't go far enough* loosening the rules on IPv4 allocation? As I read the proposal, nothing there would act to restrict allocations that ARIN or others may presently make. Have I missed something? I would respectfully suggest that the looming end of the IANA free pool makes this a particularly inopportune time to "hold out for something better." Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mark at visuallink.com Fri Nov 6 09:39:59 2009 From: mark at visuallink.com (Mark Bayliss) Date: Fri, 06 Nov 2009 09:39:59 -0500 Subject: [arin-ppml] ARIN Board/AC In-Reply-To: References: Message-ID: <20091106143959.1753F6E800EF@mail1.visuallink.com> I would like to thank all of the Arin members who supported me and too congratulate those who were elected to serve on the Advisory Council. Mark Bayliss At 01:52 PM 11/5/2009, you wrote: >Congratulations to all those elected on the ARIN Board and Advisory >Council.. > >I look forward to working with each of you in the coming months and >years! > >Bill Darte >ARIN Ac >_______________________________________________ >PPML >You are receiving this message because you are subscribed to >the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >Unsubscribe or manage your mailing list subscription at: >http://lists.arin.net/mailman/listinfo/arin-ppml >Please contact info at arin.net if you experience any issues. E-mail message checked by Spyware Doctor (6.1.0.447) Database version: 6.13650 http://www.pctools.com/en/spyware-doctor-antivirus/ From tedm at ipinc.net Fri Nov 6 15:58:31 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 06 Nov 2009 12:58:31 -0800 Subject: [arin-ppml] Policy Proposal 102: Reduce and Simplify IPv4 Initial Allocations In-Reply-To: <3c3e3fca0911060634u4a5b11c1g7fc3371d0158c2ae@mail.gmail.com> References: <4AF31D95.9050605@arin.net> <3c3e3fca0911060634u4a5b11c1g7fc3371d0158c2ae@mail.gmail.com> Message-ID: <4AF48DF7.2030207@ipinc.net> William Herrin wrote: > On Thu, Nov 5, 2009 at 1:46 PM, Member Services wrote: >> Policy Proposal 102: Reduce and Simplify IPv4 Initial Allocations > > Hi folks, > > Some comments: > > 1. The proposal neither reduces nor simplifies IPv4 allocations. > Arguably it improves them but you should consider finding a better > title. > Many proposal titles don't adequately convey the intent of the proposal. Suggestions on a title change are welcome. > 2. A replacement allocation is no longer an initial allocation. > Initial means "first" not "only one still held." > Interesting argument. However, keep in mind that what this proposal does is creates a brand new class of requesters - ISP's who WOULD NOT qualify under the CURRENT rules, and puts them into a special class that is what you would term an "extended initial requestor" In short, right now they don't qualify at all. Under this proposal they qualify for what might be termed a "temporary" allocation. If they never grow, they never renumber. If they grow, they renumber into a larger allocation that reduces the burden of carrying their routes - same as the current requirements. As long as they are requesting UNDER a /20 they are NOT getting a true "Initial Allocation" they are getting a temporary allocation. Thus they are not really "Initial requesters" However, since they are getting their first allocation, they ARE "Initial requesters" - from a certain point of view. > >> 4.2.2.1. Use of /24 >> >> The efficient utilization of an entire previously allocated /24 from >> their upstream ISP. > > Do you intend the explicit use of a /24 or do you intend the use of > address space which adds up to at least a /24? > You should ask ARIN staff that since this line is lifted straight from the existing text. Are you looking at this proposal as an opportunity to clarify existing policy? > > >> 1) Makes moot whether the requesting ISP is multihomed or not, with >> this policy change all initial ISPs request under the same minimums. > > I disagree with offering small PI blocks to entities which are not > multihomed. While any registrants benefit from receiving a PI block, > only multihomed entities do so without creating new overhead cost for > everybody else. Multihomed entities are already obtaining larger allocations and subnetting them, as I stated in the Rationale. Your making a claim here that the simple property of being multihomed somehow acts as a deterrent to an org for subnetting, and splitting their advertisements, thus creating new overhead cost for everyone else. The fact is that entities that are NOT multihomed have far more incentive to advertise all their space as a single block, with the lowest overhead to everyone else - and entities that ARE multihomed have an incentive to split their advertisements - and create more overhead cost for everyone else. In short, logic seems to indicate that it's completely opposite from what your suggesting. > I OPPOSE the proposal as written because it fails to > restrict itself to multihomed entities. I would support the proposal > if it restricted itself to multihomed registrants. > In other words, leave 4.2.2.1 intact, and add in the "return and renumber with lower minimums" into 4.2.2.2? Would you support a policy proposal that went down to a /24 for 4.2.2.2 as a minimum? Ted > > > On Thu, Nov 5, 2009 at 5:46 PM, Seth Mattinen wrote: >>> 4.2.2.5. Replacement initial allocation >> OPPOSE. A small org might expect to grow and can be punished multiple >> times (until they get a /20) by forced renumbering. An end-site office >> building, sure, force them to renumber, but not an ISP who is assigning >> address blocks to downstream orgs and customers. > > Hi Seth, > > Would you clarify: do you mean that you oppose the proposal solely > because it *doesn't go far enough* loosening the rules on IPv4 > allocation? > > As I read the proposal, nothing there would act to restrict > allocations that ARIN or others may presently make. Have I missed > something? > > I would respectfully suggest that the looming end of the IANA free > pool makes this a particularly inopportune time to "hold out for > something better." > > Regards, > Bill Herrin > > From bill at herrin.us Fri Nov 6 16:44:13 2009 From: bill at herrin.us (William Herrin) Date: Fri, 6 Nov 2009 16:44:13 -0500 Subject: [arin-ppml] Policy Proposal 102: Reduce and Simplify IPv4 Initial Allocations In-Reply-To: <4AF48DF7.2030207@ipinc.net> References: <4AF31D95.9050605@arin.net> <3c3e3fca0911060634u4a5b11c1g7fc3371d0158c2ae@mail.gmail.com> <4AF48DF7.2030207@ipinc.net> Message-ID: <3c3e3fca0911061344s39cd476fg6dc7d2d42dbbbade@mail.gmail.com> On Fri, Nov 6, 2009 at 3:58 PM, Ted Mittelstaedt wrote: >> I OPPOSE the proposal as written because it fails to >> restrict itself to multihomed entities. I would support the proposal >> if it restricted itself to multihomed registrants. > > In other words, leave 4.2.2.1 intact, and add in the "return and > renumber with lower minimums" into 4.2.2.2? Yes. > Would you support a policy proposal that went down to a /24 for > 4.2.2.2 as a minimum? Yes. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From cgrundemann at gmail.com Fri Nov 6 19:24:08 2009 From: cgrundemann at gmail.com (Chris Grundemann) Date: Fri, 6 Nov 2009 17:24:08 -0700 Subject: [arin-ppml] Policy Proposal 102: Reduce and Simplify IPv4 Initial Allocations In-Reply-To: <3c3e3fca0911060634u4a5b11c1g7fc3371d0158c2ae@mail.gmail.com> References: <4AF31D95.9050605@arin.net> <3c3e3fca0911060634u4a5b11c1g7fc3371d0158c2ae@mail.gmail.com> Message-ID: <443de7ad0911061624wde63ae2t1ac2881d8bb14fb1@mail.gmail.com> On Fri, Nov 6, 2009 at 07:34, William Herrin wrote: > On Thu, Nov 5, 2009 at 1:46 PM, Member Services wrote: >> Policy Proposal 102: Reduce and Simplify IPv4 Initial Allocations > > Hi folks, > > Some comments: Thanks Bill - Adding on to Ted's response... > > 1. The proposal neither reduces nor simplifies IPv4 allocations. > Arguably it improves them but you should consider finding a better > title. We chose the name because this proposal reduces the minimum allocation and simplifies the NRPM by consolidating the multihomed and non-multihomed sections into one - but we are definitely open to better titles, that was the area which we focused on least. > > 2. A replacement allocation is no longer an initial allocation. > Initial means "first" not "only one still held." I think Ted addressed this well - the idea is that you are renumbering into a larger initial allocation, not receiving new space in addition to your existing initial allocation. > > >> 4.2.2.1. Use of /24 >> >> The efficient utilization of an entire previously allocated /24 from >> their upstream ISP. > > Do you intend the explicit use of a /24 or do you intend the use of > address space which adds up to at least a /24? The current text of section 4.2.2.1.1. does have a second sentence that clarifies and it should probably be added back into this proposal: "This [/24] allocation may have been provided by an ISP's upstream provider(s), and does not have to be contiguous address space." We may have gotten a little too liberal with the scalpel here. > > >> 1) Makes moot whether the requesting ISP is multihomed or not, with >> this policy change all initial ISPs request under the same minimums. > > I disagree with offering small PI blocks to entities which are not > multihomed. While any registrants benefit from receiving a PI block, > only multihomed entities do so without creating new overhead cost for > everybody else. I OPPOSE the proposal as written because it fails to > restrict itself to multihomed entities. I would support the proposal > if it restricted itself to multihomed registrants. > Again, Ted addressed this point well but I would add that the renumbering requirement is meant to help alleviate this concern. I fully agree with Ted's assessment that multihomed entities are _far_ more likely to split whatever allocation they do have for TE or other purposes than a single homed entity. Furthermore, one of the primary objectives of this policy is to provide a bit of a safety net for small ISPs who may have limited choices for upstream ISPs - a remote rural WISP who only has access to a singe provider for instance - as we enter a time where IPv4 may very well become monetized to the point that such ISPs will be forced out of business without an allocation from ARIN. Also remember that we are approaching the end of the IPv4 free pool, and as such, this policy allows smaller ISPs to use their current IPv4 status to become a "known ISP" by receiving an initial allocation from ARIN and therefore qualify for an IPv6 allocation, which is where real growth must take place in any case. > > > On Thu, Nov 5, 2009 at 5:46 PM, Seth Mattinen wrote: >>> 4.2.2.5. Replacement initial allocation >> >> OPPOSE. A small org might expect to grow and can be punished multiple >> times (until they get a /20) by forced renumbering. An end-site office >> building, sure, force them to renumber, but not an ISP who is assigning >> address blocks to downstream orgs and customers. > > Hi Seth, > > Would you clarify: do you mean that you oppose the proposal solely > because it *doesn't go far enough* loosening the rules on IPv4 > allocation? > > As I read the proposal, nothing there would act to restrict > allocations that ARIN or others may presently make. Have I missed > something? > > I would respectfully suggest that the looming end of the IANA free > pool makes this a particularly inopportune time to "hold out for > something better." I too would like to hear the response to this - the aim of this proposal was certainly to make it easier for smaller ISPs to get PI allocations from ARIN (for several reasons), not the other way around... ~Chris > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com ?bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org From bill at herrin.us Fri Nov 6 20:29:23 2009 From: bill at herrin.us (William Herrin) Date: Fri, 6 Nov 2009 20:29:23 -0500 Subject: [arin-ppml] Policy Proposal 102: Reduce and Simplify IPv4 Initial Allocations In-Reply-To: <4AF48DF7.2030207@ipinc.net> References: <4AF31D95.9050605@arin.net> <3c3e3fca0911060634u4a5b11c1g7fc3371d0158c2ae@mail.gmail.com> <4AF48DF7.2030207@ipinc.net> Message-ID: <3c3e3fca0911061729v63b896a6hff2c27e947f4b4cd@mail.gmail.com> On Fri, Nov 6, 2009 at 3:58 PM, Ted Mittelstaedt wrote: > William Herrin wrote: >>> 1) Makes moot whether the requesting ISP is multihomed or not, with >>> this policy change all initial ISPs request under the same minimums. >> >> I disagree with offering small PI blocks to entities which are not >> multihomed. ?While any registrants benefit from receiving a PI block, >> only multihomed entities do so without creating new overhead cost for >> everybody else. > > Multihomed entities are already obtaining larger allocations > and subnetting them, as I stated in the Rationale. > > Your making a claim here that the simple property of > being multihomed somehow acts as a deterrent to an org for > subnetting, and splitting their advertisements, thus > creating new overhead cost for everyone else. > > The fact is that entities that are NOT multihomed have > far more incentive to advertise all their space as a > single block, with the lowest overhead to everyone else - > and entities that ARE multihomed have an incentive to > split their advertisements - and create more overhead cost > for everyone else. > > In short, logic seems to indicate that it's completely opposite from what > your suggesting. Hi Ted, That's why I'm an engineer and not a philosopher. Logic alone leads to all sorts of falsehoods. The above, for example, is a straw man argument. A single homed entity can't engineer traffic to take one path or another since there is only one path. Hence they won't tend to disaggregate for TE like a multihomed entity might. Hence multihomed entities are more likely to disaggregate whatever sized block. But that's entirely beside the point. Single-homed entities require zero routes in the DFZ to function as designed on a day to day basis while multihomed entities require at least one. That was the point. Not talking convenience here, not even typical practice, just basic minimum function. Excluding single-homers discourages the group whose systems will still work right from announcing any routes at all while multihomers will announce as many if not more routes regardless, just not using addresses directly allocated from ARIN. To be completely honest, it's no skin off my back either way. When the DFZ passes 1M entries, I only have to replace a few $1500 routers. I suspect, however, that the folks who spend half a million per router may see things from a different perspective... one that would prefer to see few folks in the "zero routes required" category actually showing up in the table. If I hear different from the likes of Verizon and AT&T, I'll drop my objection. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mysidia at gmail.com Fri Nov 6 20:42:22 2009 From: mysidia at gmail.com (James Hess) Date: Fri, 6 Nov 2009 19:42:22 -0600 Subject: [arin-ppml] Policy Proposal 102: Reduce and Simplify IPv4 Initial Allocations In-Reply-To: <4AF48DF7.2030207@ipinc.net> References: <4AF31D95.9050605@arin.net> <3c3e3fca0911060634u4a5b11c1g7fc3371d0158c2ae@mail.gmail.com> <4AF48DF7.2030207@ipinc.net> Message-ID: <6eb799ab0911061742p37a51bd7w520cebca8482bd9c@mail.gmail.com> I find myself undecided in regards to this proposal at the present time, with regards to support/oppose... On Fri, Nov 6, 2009 at 2:58 PM, Ted Mittelstaedt wrote: > William Herrin wrote: >> On Thu, Nov 5, 2009 at 1:46 PM, Member Services wrote: > Under this proposal they qualify for what might be termed a > "temporary" allocation. ?If they never grow, they never renumber. Then it's not temporary at all.. it's more like a provisional allocation. > If they grow, they renumber into a larger allocation that reduces > the burden of carrying their routes - same as the current requirements. Under the current requirements, they might choose not to renumber.. > Thus they are not really "Initial requesters" ? However, since > they are getting their first allocation, they ARE "Initial > requesters" - from a certain point of view. Um.. they can't be both "not really 'Initial requestors'" and Initial requestors at the same time... It's a confusing and contrived thing to suggest "initial allocation" is anything other than the very first allocation they get. > Your making a claim here that the simple property of > being multihomed somehow acts as a deterrent to an org for > subnetting, and splitting their advertisements, thus > creating new overhead cost for everyone else. The cost is not based solely on whether they subnet or not, it's also based on whether other providers can effectively filter the additional noise out. A small ISP gets IPs from upstream providers out of PA blocks from which ARIN allocates prefixes no longer than /20. Providers who need table size reduction to avoid increased cost may have that option of filtering, discarding announcements with prefixes longer than /20, rely on the non-customer's ISP's covering route to provide connectivity. For the blocks ARIN assigns /22s from, for multi-homed users, /22s definitely need be accepted or connectivity would be quite broken. If ARIN were to allocate smaller blocks such as /23, these could not be filtered, since there is no upstream provider announcing an overall /20 PA that contains the /23. The smaller an allocation ARIN makes from any given block, the less effective that an aggressive filtering strategy could be. When single-homed ISPs get a /23 from an upstream provider the DFZ _MIGHT_ see 1 additional /23 and 2 additional /24s being broadcast, for a total of 3 new table entries, but then again they might not.. the single-homed ISP may not announce a thing... When single-homed ISPs get a /23 from ARIN, you can be assured, almost guaranteed an additional /23 appearing, and 2 additional /24s getting announced cannot be ruled out. It seems like a plausible scenario, that the costs to others would be much greater, in the scenario where ARIN allocates a significant number of /23s to single-homed providers. I couldn't think of any plausible scenario where the costs to others would be less or the same, if single-homed entities are allowed to receive small direct allocations. -- -J From cgrundemann at gmail.com Sat Nov 7 10:18:17 2009 From: cgrundemann at gmail.com (Chris Grundemann) Date: Sat, 7 Nov 2009 08:18:17 -0700 Subject: [arin-ppml] Policy Proposal 102: Reduce and Simplify IPv4 Initial Allocations In-Reply-To: <6eb799ab0911061742p37a51bd7w520cebca8482bd9c@mail.gmail.com> References: <4AF31D95.9050605@arin.net> <3c3e3fca0911060634u4a5b11c1g7fc3371d0158c2ae@mail.gmail.com> <4AF48DF7.2030207@ipinc.net> <6eb799ab0911061742p37a51bd7w520cebca8482bd9c@mail.gmail.com> Message-ID: <443de7ad0911070718o5d9662ffl5b877f4c9498de07@mail.gmail.com> On Fri, Nov 6, 2009 at 18:42, James Hess wrote: > I ?find myself ?undecided ?in regards to this proposal at the present > time, ?with regards to ?support/oppose... > > > On Fri, Nov 6, 2009 at 2:58 PM, Ted Mittelstaedt wrote: >> William Herrin wrote: >>> On Thu, Nov 5, 2009 at 1:46 PM, Member Services wrote: >> Under this proposal they qualify for what might be termed a >> "temporary" allocation. ?If they never grow, they never renumber. > > Then it's not temporary at all.. ?it's more like a provisional allocation. > >> If they grow, they renumber into a larger allocation that reduces >> the burden of carrying their routes - same as the current requirements. > > Under the current requirements, they might ?choose not to renumber.. Under the current requirements, they would not be eligible to receive an initial allocation at all. > >> Thus they are not really "Initial requesters" ? However, since >> they are getting their first allocation, they ARE "Initial >> requesters" - from a certain point of view. > > Um.. ?they can't be both ?"not really 'Initial requestors'" and > Initial requestors at the same time... > > It's a ?confusing ?and contrived thing to suggest ?"initial allocation" > is anything other than the very first allocation they get. > Under this proposal, if you are an ISP and you have utilized a /24 equivalent of space, you can get an initial allocation of a /23. Later, if you need (and can justify) more space, you are given a replacement initial allocation. This is in contrast to an _additional_ allocation. You are required to return the original allocation in exchange for a larger allocation - it is a replacement, hence the wording in the proposal text. > >> Your making a claim here that the simple property of >> being multihomed somehow acts as a deterrent to an org for >> subnetting, and splitting their advertisements, thus >> creating new overhead cost for everyone else. > > The cost is not based solely on whether they subnet or not, ?it's also > based on whether other providers ? can effectively ?filter ?the > additional noise out. Understood, this is why we very deliberately included the line "When prefixes are assigned which are longer than /20, they will be from a block reserved for that purpose whenever that is feasible." This way, you only need to adjust your filters for a given block, not across the board. > > A small ISP gets IPs from upstream providers out of PA blocks from > which ARIN ?allocates ?prefixes ? no longer than ?/20. > > Providers who need table size reduction to avoid increased cost may > have that ?option of filtering, discarding announcements with prefixes > ?longer than /20, ?rely on the ?non-customer's ?ISP's ?covering route > to provide connectivity. This has been discussed at length (both on this list and elsewhere) and it appears that everyone who filters at anything larger than the /24 boundary understands that they must include some form of a default route when doing so. Even in PA space, there is no guarantee that the upstream provider is announcing a covering aggregate. Should they be? Yes, but no one with any clue is going to bet their customer's connectivity on that - with or without this proposal. > > For the ?blocks ?ARIN assigns /22s ?from, ?for multi-homed users, > /22s ?definitely ?need be accepted ?or ?connectivity would be quite > broken. > > If ?ARIN ?were to ? allocate ?smaller blocks such as /23, ?these could > not be filtered, since there is no upstream provider ?announcing an > overall /20 PA ?that contains the /23. This is already true for multihomers with /22s and the critical infrastructure or legacy blocks which go down to /24. > > The smaller an allocation ARIN makes ?from any ?given ?block, ?the > less effective that an aggressive filtering ?strategy could ?be. > Again, this proposal requires that all allocations smaller than /20 be from a dedicated block (as long as that is possible) so that you can adjust such filters accordingly. Also, if you are not using the whole table, you probably need a default (or perhaps a process by which you determine which routes have covering aggregates and which do not). > > When ?single-homed ?ISPs ?get a /23 ?from ?an ? upstream provider ?the > DFZ ? _MIGHT_ ? see ? ? ?1 additional /23 ?and 2 ?additional ?/24s > being broadcast, for a total of ?3 new table entries, ? ? but then > again they might not.. ? the single-homed ISP ? may not announce a > thing... > > When ?single-homed ISPs ?get a /23 ?from ARIN, ?you can be ?assured, > almost ?guaranteed ? an additional ?/23 ?appearing, ? and ?2 > additional /24s ? getting announced cannot be ruled out. > > > It seems like a plausible scenario, ?that the costs ?to others would > be much greater, ? in the scenario ?where ?ARIN ?allocates ? a > significant number of ?/23s ?to single-homed providers. > > I ?couldn't ?think of any plausible scenario ?where the costs to > others would be less or the same, ?if single-homed entities ?are > allowed to ?receive ?small ? direct allocations. > I agree - with or without this proposal, it is hard to find a likely scenario where the cost to everyone with regard to the routing table ever becomes less than it is now. Also, allowing a new class of organizations access to direct allocations will likely increase the consumption of routing table slots at least a little bit. The real question is: In comparison with all of the other things (policy and otherwise) that are bloating the table, is this a worthy purpose for adding a few more entries? ~Chris > > -- > -J > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org From tedm at ipinc.net Mon Nov 9 14:24:01 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 09 Nov 2009 11:24:01 -0800 Subject: [arin-ppml] Policy Proposal 102: Reduce and Simplify IPv4 Initial Allocations In-Reply-To: <3c3e3fca0911061729v63b896a6hff2c27e947f4b4cd@mail.gmail.com> References: <4AF31D95.9050605@arin.net> <3c3e3fca0911060634u4a5b11c1g7fc3371d0158c2ae@mail.gmail.com> <4AF48DF7.2030207@ipinc.net> <3c3e3fca0911061729v63b896a6hff2c27e947f4b4cd@mail.gmail.com> Message-ID: <4AF86C51.1040804@ipinc.net> William Herrin wrote: > On Fri, Nov 6, 2009 at 3:58 PM, Ted Mittelstaedt wrote: >> William Herrin wrote: >>>> 1) Makes moot whether the requesting ISP is multihomed or not, with >>>> this policy change all initial ISPs request under the same minimums. >>> I disagree with offering small PI blocks to entities which are not >>> multihomed. While any registrants benefit from receiving a PI block, >>> only multihomed entities do so without creating new overhead cost for >>> everybody else. >> Multihomed entities are already obtaining larger allocations >> and subnetting them, as I stated in the Rationale. >> >> Your making a claim here that the simple property of >> being multihomed somehow acts as a deterrent to an org for >> subnetting, and splitting their advertisements, thus >> creating new overhead cost for everyone else. >> >> The fact is that entities that are NOT multihomed have >> far more incentive to advertise all their space as a >> single block, with the lowest overhead to everyone else - >> and entities that ARE multihomed have an incentive to >> split their advertisements - and create more overhead cost >> for everyone else. >> >> In short, logic seems to indicate that it's completely opposite from what >> your suggesting. > > Hi Ted, > > That's why I'm an engineer and not a philosopher. Logic alone leads to > all sorts of falsehoods. > > The above, for example, is a straw man argument. A single homed entity > can't engineer traffic to take one path or another since there is only > one path. Hence they won't tend to disaggregate for TE like a > multihomed entity might. Hence multihomed entities are more likely to > disaggregate whatever sized block. > > But that's entirely beside the point. Single-homed entities require > zero routes in the DFZ to function as designed on a day to day basis > while multihomed entities require at least one. That was the point. Except that there are significant business/economic problems with it working the way your describing. While it is true that a single homed entity that qualifies under 4.2.2.1 for a /20 CAN have their single upstream feed advertise that /20 under the upstream's AS, in practice this is almost never done. One big reason ISPs obtain portable numbering so they have the freedom to be able to tell their upstream to go stuff themselves if they decide the upstream is screwing them over, without the fear of renumbering pain. Thus if they are going to go through the pain of a renumber into a portable /20 the very last thing they are going to do is just turn that /20 over to their upstream to aggregate in it's own advertisements. Instead they are going to get their own AS and do BGP to their upstream. Thus, consuming "at least one" route in the DFZ. This allows them to shift upstreams within minutes. > Not talking convenience here, not even typical practice, just basic > minimum function. Excluding single-homers discourages the group whose > systems will still work right from announcing any routes at all while > multihomers will announce as many if not more routes regardless, just > not using addresses directly allocated from ARIN. > > To be completely honest, it's no skin off my back either way. When the > DFZ passes 1M entries, I only have to replace a few $1500 routers. I > suspect, however, that the folks who spend half a million per router > may see things from a different perspective... one that would prefer > to see few folks in the "zero routes required" category actually > showing up in the table. > Bill, this proposal only lowers the bar a little bit, that bar is still there. They still have to show efficient utilization of at least 400 IP addresses. And, if their goal is to renumber into a portable ONLY so as to "never have to ever do another renumber ever again" well that isn't going to exist, either. A small ISP that has friendly relations with their upstream really doesn't have much incentive to request numbering under this policy for a "provisional" allocation. They have much more incentive to simply keep plugging away, growing their business, until they qualify for a /20, since that's the minimum allocation that's a permanent allocation, rather than a provisional allocation. It's only the small ISP's who have upstreams who are screwing them over, either by NOT supplying products (like native IPv6) that they want, or by raising their rates far in excess of the market rate for their area, who are going to be wanting to renumber into a portable allocation that they can move elsewhere. Look, you know that a small ISP that cannot afford to multihome isn't going to be able to afford move to a different upstream, if that upstream has supplied them numbers. A renumbering project can take months, and they would have to maintain 2 feeds during the transition, they can't afford that. If this policy is put into effect I would guess that it's very existence will act as a check on the large upstream feeds from jerking their small ISP customers around, and that will very likely end up helping to discourage the smaller ISPs from trying to obtain portable numbering in the first place. > If I hear different from the likes of Verizon and AT&T, I'll drop my objection. > Would you be willing to drop your opposition if you DON'T hear opposition from the likes of Verizon and AT&T? After all, if they figure it isn't going to make much difference to the DFZ, then they have every incentive to remain neutral. Ted > Regards, > Bill Herrin > > From info at arin.net Mon Nov 9 14:31:33 2009 From: info at arin.net (Member Services) Date: Mon, 09 Nov 2009 14:31:33 -0500 Subject: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process Message-ID: <4AF86E15.2060307@arin.net> ARIN received the following policy proposal and is posting it to the Public Policy Mailing List (PPML) in accordance with Policy Development Process. This proposal is in the first stage of the Policy Development Process. ARIN staff will perform the Clarity and Understanding step. Staff does not evaluate the proposal at this time, their goal is to make sure that they understand the proposal and believe the community will as well. Staff will report their results to the ARIN Advisory Council (AC) within 10 days. The AC will review the proposal at their next regularly scheduled meeting (if the period before the next regularly scheduled meeting is less than 10 days, then the period may be extended to the subsequent regularly scheduled meeting). The AC will decide how to utilize the proposal and announce the decision to the PPML. In the meantime, the AC invites everyone to comment on the proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Mailing list subscription information can be found at: https://www.arin.net/mailing_lists/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 103: Change IPv6 Allocation Process Proposal Originator: William Herrin Proposal Version: 1.0 Date: 9 November 2009 Proposal type: new Policy term: permanent. Policy statement: Strike NRPM sections: 6.2.3, 6.2.4, 6.2.6-6.2.9, 6.4.3, 6.4.4, 6.5.1-6.5.5, 6.5.8, 6.7, 6.10 Strike NRPM section 6.9 paragraph 2. Replace 6.2.5 as follows: 6.2.5 Allocate and Assign For the purposes of NRPM section 6, allocate and assign are synonymous. Both terms describe any or all use identified in section 2.5. Replace 6.5.7 with: 6.5.7. Existing IPv6 address space holders Organizations that received IPv6 allocations under the previous IPv6 address policy are entitled to either retain those allocations as is or trade them in for an allocation under 6.5.9. Add NRPM section 6.5.9 as follows: 6.5.9 IPv6 Allocations 6.5.9.1 ARIN shall allocate IPv6 address blocks in exactly and only the following denominations: /56, /48, /40, /32, /24 6.5.9.2 No utilization-based eligibility requirements shall apply to IPv6 allocations. 6.5.9.3 ARIN shall accept registration of no more than one address block of each size for any single organization. 6.5.9.4 ARIN shall allocate IPv6 addresses from pools such that the identity of the allocation pool serves to classify the expected size of allocations within. ISPs may use that classification to filter or otherwise manage their routing tables. 6.5.9.5 For each allocation size, ARIN shall further manage the allocation pools such that the pool identity serves to classify whether or not the registrant is Multihomed. 6.5.9.6 ARIN shall offer addresses from pools classified as multihomed only to organizations which ARIN has verified are multihomed on the public Internet per NRPM 2.7. 6.5.9.7 Where an organization ceases to be Multihomed it shall surrender all address allocations from within pools classified as multihomed within 3 months. Rationale: See the implementation notes section below for what should replace utilization-based eligibility. The existing IPv6 allocation policy under section 6.5 makes a number of unproven assumptions about how IPv6 allocations will work. Unproven: we can make a reasonable guess about how many IPv6 subnets an organization will need at the outset when they first request IP addresses. When in all of human history has this ever proven true of any resource? Unproven: with sparse allocation, we can allow organizations to expand by just changing their subnet mask so that they don't have to announce additional routes into the DFZ. This claim is questionable. With sparse allocation, we either consume much larger blocks that what we assign (so why not just assign the larger block?) or else we don't consume them in which case the org either has to renumber to expand or he has to announce a second route. Worse, because routes of various sizes are all scattered inside the same address space, its impractical to filter out the traffic engineering routes. Unproven: we can force organizations not to disaggregate for traffic engineering purposes. Neither any of our experience with IPv4 nor any of the research in the IRTF Routing Research Group suggests that this is even remotely practical so long as BGP or any similar system rules the roost. Unproven: all non-ISPs can be reasonably expected to get their address space from ISPs instead of from ARIN. We can certainly operate that way, but it could prove deadly to the routing table. Any organization multihomed between two ISPs will need to announce that route via BGP, regardless of where they get the address space from. We have knobs and dials in the routers that let us easily filter disaggregates from distant announcements, but we don't dare do so if there is a possibility that one of those disaggregates is a multihomed customer rather than traffic engineering. Benefits of this proposal: A. Efficient allocation of IP addresses. Orgs get what they need when they need it without a great deal of guesswork. B. Efficient utilization of BGP routing slots. No multihomed orgs will announce more than five unfilterable routes, and that only if they're so large that they can afford the price tag for the biggest address blocks. That's a good thing since IPv6 routes that propagate worldwide may impose an annual systemic overhead cost on ISPs of as much as US $16,000 each. C. Traffic engineering routes are trivially filterable. Any route longer than the published allocation size can be presumed to be traffic engineering, not a downstream multihomed customer, thus you can filter distant small routes with confidence and ease. D. Fair. No need to define the difference between ISP and not ISP. Everybody plays by the same rules. E. No complicated analysis for allocation. You pay for what you want and get what you pay for. You're either multihomed or you're not. F. Gets ARIN out of the business of being the gatekeeper for Internet routing policy. By classifying allocations instead of making eligibility decisions, ARIN empowers the ISPs to set appropriate routing eligibility policies instead. FAQ Q. Isn't this classfull addressing all over again? A. Yes. Classful addressing had a lot of virtues with respect to route filtering and management. We had to abandon it because there weren't enough B's for everyone who needed more than one C and there weren't enough A's period. With IPv6, we don't have that problem. Not yet and maybe not ever. Perhaps we can have our cake and eat it too. Q. What if I don't want to accept /56 routes for single-homed users? A. This policy proposal intentionally and fully places backbone routing policy in the hands of the ISPs who operate the Internet's "Default-Free Zone (DFZ)," colloquially known as the Internet backbone. The author expects that some of the allocations, especially some of the single-homed allocations, *will not* be routable on the public Internet. When we hold a general expectation that all of ARIN's allocations will be routable, we effectively mean that ARIN decides what the Internet routing policy will be. That's precisely the role this proposal removes from ARIN's hands and restores to the ISPs. Q. Spell it out for me. How exactly will pools and size classifications enable route filtering? A. Suppose ARIN holds 4000::/12. ARIN might split it up as follows: 4000::/13 -- reserved 4008::/15 -- multihomed /24 allocations 400a::/15 -- non-multihomed /24 allocations 400c::/16 -- multihomed /32 allocations 400d::/16 -- non-multihomed /32 allocations 400e:0000::/18 -- multihomed /40 allocations 400e:4000::/18 -- non-multihomed /40 allocations 400e:8000::/24 -- multihomed /48 allocations 400e:8100::/24 -- non-multihomed /48 allocations 400e:8200::/24 -- multihomed /56 allocations 400e:8300::/24 -- non-multihomed /56 allocations 400e:8400::/22 -- reserved 400e:8800::/21 -- reserved 400e:9000::/20 -- reserved 400e:a000::/19 -- reserved 400e:c000::/18 -- reserved 400f::/16 -- reserved Now, you're an ISP. Here's a sample routing policy you might choose: Accept any routes to /32 because anyone paying $10k per year for addresses is big enough to ride. For /24 allow 2 bits of traffic engineering too. Single-homers who won't spend $10k/year on their addresses (smaller than /32) must use addresses from their ISP. Tough luck. Accept multihomers down to /48. The folks paying only $10/year for /56's aren't serious. Your route filter looks like this: accept 400e:8000::/24 equal 48 accept 400e:0000::/18 equal 40 accept 400c::/15 equal 32 accept 4008::/14 le 26 reject 4000::/12 le 128 Note how 400e:8000::/24 contains only /48 allocations and you're allowing only /48 announcements. Since there aren't any /47 or /46 allocations there, nobody in the pool can slip TE routes past you. On the other hand, you'll get some benefit of traffic engineering from the super-massive /24 registrants up in 4008::/14 because you're allowing them to disaggregate down to /26. Q. If its so expensive to announce routes into the DFZ, why not use something better than BGP? A. In 2008 the IRTF Routing Research Group compiled an exhaustive study attempting to identify the possible ways to improve the routing system. A draft of the results is at http://tools.ietf.org/html/draft-irtf-rrg-recommendation-02 . While there are many promising ideas for how to replace BGP with something that scales better, we're at least a decade away and probably more from any significant deployment of a BGP replacement. Q. Is it really true that multihoming requires announcing a route via BGP? A. The short answer is yes. The long answer is more complicated. Folks have tried very hard to devise multi-vendor multihomed systems which don't rely on BGP. The only approach that has ever come near success is dynamically changing DNS records to favor the currently working Internet connection. "Near" is a relative term here. Such network architectures are enormously complex and they don't work especially well. The DNS protocol itself supports quick changes but the applications which use it often don't. It takes hours to achieve two-nines recovery from an address change in the DNS and it takes months to achieve five-nines recovery. Web browsers, for example, don't immediately recover. Search google for "DNS Pinning." Q. So the Internet's resulting route policy will be to allow all the sizes that no major ISP decides to filter and restrict the rest? A. That's one possible outcome. On the other hand, research in the routing field suggests that with a sufficiently rich classification scheme, it may be possible to implement lower priority systems with provider-independent addresses yet without a global route. Hints for how such a thing might work can be found in http://www.cs.cornell.edu/people/francis/va-wp.pdf and http://bill.herrin.us/network/trrp.html. Such schemes need a rich classification process at the address allocation level that makes it possible for ISPs to make reasonable and simple decisions about which routes should be distributed to every DFZ router and which should not. Wouldn't that be something: IPv6 provider independent addresses for everybody without materially increasing the cost of the routing system. Q. Why allocate the /48's from a pool only for /48's, /32's from a /32 pool, etc.? Why not allocate from just one pool? A. If all assignments in a particular pool are /32 then any route in the /32 pool which is longer than /32 is a traffic engineering (TE) route. As a router operator you can filter and discard TE routes if you find they give you insufficient benefit. The routes you filter don't cost you any money; only the routes you keep carry a price tag. You can only filter if you're sure they're TE routes... If they're distinct downstream customer routes and you filter them, there goes the Internet. Or at least there goes your part of it. See customers. See customers run... straight to your competitor. Setting up the distinct pools makes it practical to know with certainty whether the routes you're filtering are only for TE. Q. Why allow only one allocation of each particular size? A. Without the address scarcity issue which drives IPv4 policy, the primary criteria for IPv6 addressing policy is suppressing the disaggregation that drives route count in the IPv4 DFZ (NRPM 6.3.8). Such a criteria is not well served if an organization holds dozens of discontiguous address spaces as a result of acquisitions, mergers and and growing a little bit at a time. This proposal says, in effect, once you've consumed your smaller allocation it's time for you to get a *much* bigger allocation. The rest of us don't want to pay the routing table price for you coming back again and again and again. The proposal could require some renumbering as a result of mergers and acquisitions. However, with only modest planning on the registrant's part, the policy its flexible enough to allow that renumbering to occur over a long period of time so that both cost and disruption are minimized. In many cases, customer churn can be expected to take care of much of the renumbering activity all by itself. Q. What about the IETF recommendations? A. RFC 3177 recommends that ISPs receive a /32 while downstream customers receive a /48 assignment by default with so-called "sparse allocation" to allow those assignments to expand by changing the netmask. While this proposal supports organizations who wish to follow those recommendations, it is not this proposal's intention that ARIN follow RFC 3177. RFC 3177 is not the gospel truth. It was written back in 2001 when there was little IPv6 outside of academia and, indeed, little IPv6 at all. It's an engineers' SWAG about what operations folk should do that's now 8-years-stale. This proposal attempts to slow-start IPv6 allocations instead, while still maintaining the principle of suppressing the routing table size. As an ISP, consider implementing a slow start for your downstream customers as well: Give them a /60 initially, add a /56 when they need it and add a /52 when they run out of the /56. A /60 is 16 /64 subnets. That's an internal LAN, a DMZ and 14 more subnets. Just how many subnets do you think your normal downstream customer will actually use? Q. What happens when organizations merge or split? A. Entities which merge may renumber out of and return conflicting allocations, or they may maintain the existence of the acquired organization in order to keep it's addresses. Either way it should be a minor hardship. Entities which split have a bigger problem since the practical effect of route filtering may be that only one of them can keep the addresses. To a large extent, that problem already exists and is a pain in the rump for IPv4 operations today. This policy doesn't solve it but it doesn't make it a whole lot worse either. Because disaggregates are likely to be filtered, this IPv6 policy does gives us a slightly better guarantee that the rest of us won't get stuck with the check (in the form of routing slot consumption) when an ISP goes bankrupt and gets split up. Q. What about IPv6 addresses for uses which will not be connected to the Internet at all? A. Folks are welcome to get non-multihomed addresses for any purpose whatsoever. If they do eventually decide to connect to the Internet, the routes will follow whatever rules the ISPs have imposed for routes within the single-homed pools. Q. What about reporting requirements for downstream assignments? A. Reporting requirements were instituted for the purpose of verifying eligibility for additional allocations. They have proven useful for other purposes and the author encourages ARIN to maintain the SWIP system. Nevertheless, this proposal renders the use of SWIP for IPv6 optional since it is no longer needed to verify eligibility for allocations. Q. What if I need more than a /24? A. This proposal's author asserts as obvious: anyone who defines a need for more than a trillion subnets should make their case publicly on PPML, seeking a follow-on proposal that establishes address pools at the /16 level. Q. What are the struck sections of the current IPv6 policy and why should they be struck? A. 6.2.3 - 6.2.9 define terms that have no meaning or use in the policy as revised by this proposal. The 6.4.3 notion of a minimum allocation is obsoleted by the allocation pools of specific size in this proposal. 6.4.4 is moot as this proposal does not expect registrants to justify their IPv6 allocation size. 6.5.1 - 6.5.4 and 6.5.8 are replaced entirely by 6.5.9. 6.5.5 is largely moot since it's no longer necessary to confirm downstream assignments in order to determine eligibility for additional addresses. 6.7 is moot as it is unnecessary to compute utilization to justify addresses under this proposal. 6.9 paragraph 2 is moot since utilization is not a factor in IPv6 policy under this proposal. 6.10 is redundant since micro-allocations are trivially accomplished under 6.5.9. Implementation notes: To prevent wasteful consumption of IPv6 address space without a complicated eligibility regime, the author recommends an initial and annual fee regime for IPv6 address allocations similar to: /56 -- $10 USD /48 -- $100 USD /40 -- $1000 USD /32 -- $10,000 USD /24 -- $100,000 USD Legacy -- the lesser of the cost of the next larger size or the cost of the next smaller size times the number encompassed by the registration. The above notwithstanding, it may be advisable to discount /40s and /32s to a much lower price during IPv6's general deployment process in order to encourage adoption. Folks who already hold /31's should probably also get a big break on the $20k fee for a good long while, perhaps until the first time they request an additional block without offering a plan to return the legacy addresses. For verification of multihoming, the current way ARIN verifies multihoming for other parts of it's policy appears satisfactory. Should that change, the author suggests requiring that the AS# contacts for at least two AS#'s submit a template indicating that they intend to originate or propagate IPv6 BGP routes from the registrant's ORG. Timetable for implementation: immediate From bill at herrin.us Mon Nov 9 14:51:08 2009 From: bill at herrin.us (William Herrin) Date: Mon, 9 Nov 2009 14:51:08 -0500 Subject: [arin-ppml] Policy Proposal 102: Reduce and Simplify IPv4 Initial Allocations In-Reply-To: <4AF86C51.1040804@ipinc.net> References: <4AF31D95.9050605@arin.net> <3c3e3fca0911060634u4a5b11c1g7fc3371d0158c2ae@mail.gmail.com> <4AF48DF7.2030207@ipinc.net> <3c3e3fca0911061729v63b896a6hff2c27e947f4b4cd@mail.gmail.com> <4AF86C51.1040804@ipinc.net> Message-ID: <3c3e3fca0911091151i13a97eccge254c54cf5dc715@mail.gmail.com> On Mon, Nov 9, 2009 at 2:24 PM, Ted Mittelstaedt wrote: > William Herrin wrote: >> But that's entirely beside the point. Single-homed entities require >> zero routes in the DFZ to function as designed on a day to day basis >> while multihomed entities require at least one. That was the point. > > Except that there are significant business/economic problems with it > working the way your describing. > > While it is true that a single homed entity that qualifies under 4.2.2.1 for > a /20 CAN have their single upstream feed advertise that /20 under > the upstream's AS, in practice this is almost never done. Ted, You misrepresent my position. Single-homed ISPs who can't justify a /20 generally consume -zero- routes in the DFZ today. Each one who gets IP addresses under your proposal consumes at least one more route than zero. Contrarily, multihomed ISPs each consume at least one route in the table today, despite not getting addresses from ARIN. They're likely to consume the same or fewer routes after getting ARIN addresses and renumbering out of their ISP /24's (as required by your proposal). I respectfully decline to debate whether /20 is a wise boundary above which orgs should be able to get PI space regardless of multihoming. Good or bad, it is the starting point from which your proposal is judged. >> If I hear different from the likes of Verizon and AT&T, I'll drop my >> objection. > > Would you be willing to drop your opposition if you DON'T hear opposition > from the likes of Verizon and AT&T? After all, if they figure it isn't > going to make much difference to the DFZ, then they have every incentive to > remain neutral. If I hear support from ISPs that are spending millions on DFZ routers every year, I'll change my position to support. Otherwise, I'll imagine myself in their shoes and ask: what would Bill Herrin want? Bill Herrin wouldn't want to buy expensive new equipment any sooner than he has to, especially not because someone else changed the rules. Regards, Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From sethm at rollernet.us Mon Nov 9 15:10:07 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 09 Nov 2009 12:10:07 -0800 Subject: [arin-ppml] Policy Proposal 102: Reduce and Simplify IPv4 Initial Allocations In-Reply-To: <443de7ad0911060157r763c9995nc4e6f681816e1397@mail.gmail.com> References: <4AF31D95.9050605@arin.net> <4AF355E3.4010901@rollernet.us> <443de7ad0911052106p1e300089j376cd7c2334187a5@mail.gmail.com> <4AF3C2C1.70105@rollernet.us> <443de7ad0911060157r763c9995nc4e6f681816e1397@mail.gmail.com> Message-ID: <4AF8771F.9050100@rollernet.us> Chris Grundemann wrote: > > Would you support the proposal if it only had a renumbering > requirement up to /22 (the current minimum initial allocation for > multihomed ISPs)? That would still help keep the impact of lowering > the minimum initial allocation on the routing table down but would not > introduce any new barriers to ISPs qualify under current policy > either. Sure. If we hand out PI /23 and /24 I agree that they should have to give them back when they grow into the current policy. I hate, *hate*, sites that get a /20 and then advertise it all as /24's for "traffic engineering". If they don't want to renumber during growth then they need to make a case for a /22 or use PA space until they can. ~Seth From sethm at rollernet.us Mon Nov 9 15:19:35 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 09 Nov 2009 12:19:35 -0800 Subject: [arin-ppml] Policy Proposal 102: Reduce and Simplify IPv4 Initial Allocations In-Reply-To: <3c3e3fca0911060634u4a5b11c1g7fc3371d0158c2ae@mail.gmail.com> References: <4AF31D95.9050605@arin.net> <3c3e3fca0911060634u4a5b11c1g7fc3371d0158c2ae@mail.gmail.com> Message-ID: <4AF87957.8020404@rollernet.us> William Herrin wrote: > > Hi Seth, > > Would you clarify: do you mean that you oppose the proposal solely > because it *doesn't go far enough* loosening the rules on IPv4 > allocation? > > As I read the proposal, nothing there would act to restrict > allocations that ARIN or others may presently make. Have I missed > something? > > I would respectfully suggest that the looming end of the IANA free > pool makes this a particularly inopportune time to "hold out for > something better." > I think the current /22 policy is a good boundary between PI and PA land for multihomers. As I read other comments in this thread maybe I'm misunderstanding the policy in that this is creating a separate class of "temporary allocations" and not really changing existing policy? ~Seth From tedm at ipinc.net Mon Nov 9 15:20:48 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 09 Nov 2009 12:20:48 -0800 Subject: [arin-ppml] Policy Proposal 102: Reduce and Simplify IPv4 Initial Allocations In-Reply-To: <6eb799ab0911061742p37a51bd7w520cebca8482bd9c@mail.gmail.com> References: <4AF31D95.9050605@arin.net> <3c3e3fca0911060634u4a5b11c1g7fc3371d0158c2ae@mail.gmail.com> <4AF48DF7.2030207@ipinc.net> <6eb799ab0911061742p37a51bd7w520cebca8482bd9c@mail.gmail.com> Message-ID: <4AF879A0.5030300@ipinc.net> James Hess wrote: > I find myself undecided in regards to this proposal at the present > time, with regards to support/oppose... > We wrote this proposal with an eye to keeping it's effects somewhat neutral to the Internet in general. If your not of the size that this change would affect you, then our hope would be that you would regard this as a neutral proposal and be undecided. Let's explore the argument that this will increase the DFZ by letting more small ISPs into it. You have to ask, why would a small ISP -want- to be in the DFZ to begin with? Keep in mind that a couple /24's cost large ISP's practically nothing - to see why, divide out the cost for larger and larger allocations in the ARIN fee structure and you will quickly see the more numbering you qualify for, the cheaper it is. A large ISP can afford to give a small ISP 2 or 3 /24's for far, far, cheaper than that small ISP can afford to go to ARIN under this policy and get them themselves. So, why don't the large ISP's simply do that for their small ISP customers? Well, right now, that's exactly what they do. The problem becomes post-IPv4 runout. You can argue all you want that a large ISP who wants to be a good Internet community member will continue to give their small ISP customers those handful of /24s for the cost that they are paying ARIN for them - basically, nothing. But, what's going to happen when these stockholder activists, the Warren Buffets of the world, get wind that their large ISPs that they sit on the boards of, have a lot of low-usage subnets allocated out to small customers - when those same subnets are fetching a couple million dollars on the transfer market - and the Internet community is out there beating the drum that IPv4 is dead and we all need to upgrade to IPv6? We all know what will happen. They won't hesitate, on the boards of AT&T, Comcast, Verizon and the like, to order that those companies consolidate their IPv4 holdings and get them up on the auction block ASAP, before the other guy does, in order to make the Johnny-come-latelies who wern't paying attention to IPv4 runout, to pay and pay and pay again. And if a few small ISP customers get squeezed, well that's just business, sorry folks. The fact is that a large increase of IPv4 in the DFZ is coming no matter what we do about it. The IPv4 end-game post-IPv4 runout will be to delay IPv6 for as long as possible - because of the simple fact that the later you migrate, the cheaper it will be. You will be taking advantage of all of the work done by those who went in front of you - countless hours of it - and we all know that the people in the front of the IPv6 migration are all going to be dual-stacked. So, many orgs - and I'm not talking the really large ones that cannot do this, I'm talking the medium-sized ones big enough to qualify for additional allocations but small enough to survive with IPv4-only for a few years past the large orgs - will be obtaining transfer subnets that will not be contiguous with their existing ones, and will not be aggregating them. In a dual-stack Internet, the IPv4-only holders will be able to reach everyone. Until we see the day that some of the dual-stacker networks start going to IPv6 only, prices for IPv4 via a transfer policy will continue to rise. There is going to be a transfer of IPv4 numbering from larger orgs to smaller orgs, via the transfer mechanism, and this will increase the DFZ even if those blocks aren't subnetted, since they will be advertised under different ASs. Further, the various reclamation efforts - and the POC Cleanup is one - will generate "un-virgin" IPv4 from within the RIR's existing assignments from IANA that isn't contiguous to anything, and it will be handed out in the future. The very Rationale in this policy proposal contains 3 "un-virgin" IPv4 subnets, for example. Do you think they WON'T be handed back out, post-IPv4 runout? What Chris and I are trying to do is divert some of those subnets into the hands of small ISPs before this turns into a commercial pay-for IPv4 addressing market. Once the RIR's are out of blocks in the virgin free pool, and out of "de-flowered" blocks from the "used" pool, then the opportunity for the smaller ISPs to get initial assignments will be gone. Most will never be able to afford to pay for the transfer blocks, and their upstream LIR's will be applying increasing pricing pressure on them for what they do have from them. > > On Fri, Nov 6, 2009 at 2:58 PM, Ted Mittelstaedt wrote: >> William Herrin wrote: >>> On Thu, Nov 5, 2009 at 1:46 PM, Member Services wrote: >> Under this proposal they qualify for what might be termed a >> "temporary" allocation. If they never grow, they never renumber. > > Then it's not temporary at all.. it's more like a provisional allocation. > It is - until IPv4 runout happens. Once IPv4 runout happens, any of those provisional allocations that were handed out will very likely become permanent, they will in essence become the only portable IPv4 that those smaller ISP's will ever get. >> If they grow, they renumber into a larger allocation that reduces >> the burden of carrying their routes - same as the current requirements. > > Under the current requirements, they might choose not to renumber.. > Once IPv4 runout happens, they may not even have the option to get more assignments. >> Thus they are not really "Initial requesters" However, since >> they are getting their first allocation, they ARE "Initial >> requesters" - from a certain point of view. > > Um.. they can't be both "not really 'Initial requestors'" and > Initial requestors at the same time... > > It's a confusing and contrived thing to suggest "initial allocation" > is anything other than the very first allocation they get. > > >> Your making a claim here that the simple property of >> being multihomed somehow acts as a deterrent to an org for >> subnetting, and splitting their advertisements, thus >> creating new overhead cost for everyone else. > > The cost is not based solely on whether they subnet or not, it's also > based on whether other providers can effectively filter the > additional noise out. > > A small ISP gets IPs from upstream providers out of PA blocks from > which ARIN allocates prefixes no longer than /20. > > Providers who need table size reduction to avoid increased cost may > have that option of filtering, discarding announcements with prefixes > longer than /20, rely on the non-customer's ISP's covering route > to provide connectivity. > > For the blocks ARIN assigns /22s from, for multi-homed users, > /22s definitely need be accepted or connectivity would be quite > broken. > > If ARIN were to allocate smaller blocks such as /23, these could > not be filtered, since there is no upstream provider announcing an > overall /20 PA that contains the /23. > > The smaller an allocation ARIN makes from any given block, the > less effective that an aggressive filtering strategy could be. > > > When single-homed ISPs get a /23 from an upstream provider the > DFZ _MIGHT_ see 1 additional /23 and 2 additional /24s > being broadcast, for a total of 3 new table entries, but then > again they might not.. the single-homed ISP may not announce a > thing... > > When single-homed ISPs get a /23 from ARIN, you can be assured, > almost guaranteed an additional /23 appearing, and 2 > additional /24s getting announced cannot be ruled out. > > > It seems like a plausible scenario, that the costs to others would > be much greater, in the scenario where ARIN allocates a > significant number of /23s to single-homed providers. > > I couldn't think of any plausible scenario where the costs to > others would be less or the same, if single-homed entities are > allowed to receive small direct allocations. > OK, try this one. In the ISP market, the fewer ISPs you have the less competition among them, and the less choices that consumers have. If we do nothing, and IPv4 runout forces a decrease in the number of smaller ISP's, then prices will rise for consumers due to monopoly actions in markets with a single remaining provider. Ted From tedm at ipinc.net Mon Nov 9 15:48:25 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 09 Nov 2009 12:48:25 -0800 Subject: [arin-ppml] Policy Proposal 102: Reduce and Simplify IPv4 Initial Allocations In-Reply-To: <3c3e3fca0911091151i13a97eccge254c54cf5dc715@mail.gmail.com> References: <4AF31D95.9050605@arin.net> <3c3e3fca0911060634u4a5b11c1g7fc3371d0158c2ae@mail.gmail.com> <4AF48DF7.2030207@ipinc.net> <3c3e3fca0911061729v63b896a6hff2c27e947f4b4cd@mail.gmail.com> <4AF86C51.1040804@ipinc.net> <3c3e3fca0911091151i13a97eccge254c54cf5dc715@mail.gmail.com> Message-ID: <4AF88019.8010309@ipinc.net> William Herrin wrote: > On Mon, Nov 9, 2009 at 2:24 PM, Ted Mittelstaedt wrote: >> William Herrin wrote: >>> But that's entirely beside the point. Single-homed entities require >>> zero routes in the DFZ to function as designed on a day to day basis >>> while multihomed entities require at least one. That was the point. >> Except that there are significant business/economic problems with it >> working the way your describing. >> >> While it is true that a single homed entity that qualifies under 4.2.2.1 for >> a /20 CAN have their single upstream feed advertise that /20 under >> the upstream's AS, in practice this is almost never done. > > Ted, > > You misrepresent my position. Single-homed ISPs who can't justify a > /20 generally consume -zero- routes in the DFZ today. Each one who > gets IP addresses under your proposal consumes at least one more route > than zero. Contrarily, multihomed ISPs each consume at least one route > in the table today, despite not getting addresses from ARIN. They're > likely to consume the same or fewer routes after getting ARIN > addresses and renumbering out of their ISP /24's (as required by your > proposal). Bill, I hate to point it out to you but you did not make any statement of /20 in your post of the 6th, you were speaking generally and I responded by pointing out out that everything /20 and above didn't follow this general statement. So, I didn't misrepresent your statement , I merely only responded to the part of it concerning ISP's ABOVE the /21 boundary. :-) Seriously, sure - ISP's who hold a /21 or below from an upstream AND who take advantage of this policy will cause a new DFZ entry where there was none before. However, multihomers who qualify for a /22 right now are completely free to KEEP that /22 and go get another /22, when requesting an additional allocation. Thus, creating 2 DFZ entries. Under this proposal we put a stop to that. Multihomers no longer exist as a special class, when ANYONE gets a /22 and then goes and requests an additional allocation, they will have to return that first /22 to get their /21. Thus, knocking then back down to 1 DFZ entry. This policy giveth with the left hand and taketh away with the right hand. It is, as they say, "a wash" > > I respectfully decline to debate whether /20 is a wise boundary above > which orgs should be able to get PI space regardless of multihoming. > Good or bad, it is the starting point from which your proposal is > judged. > Some would look at this discussion and make the observation that the ARIN community doesn't give much beyond a rat's ass about slimming the DFZ down. ;-) Because if they did, then ALL increasing allocations up to a /8 would MANDATE renumber and return. > >>> If I hear different from the likes of Verizon and AT&T, I'll drop my >>> objection. >> Would you be willing to drop your opposition if you DON'T hear opposition >> from the likes of Verizon and AT&T? After all, if they figure it isn't >> going to make much difference to the DFZ, then they have every incentive to >> remain neutral. > > If I hear support from ISPs that are spending millions on DFZ routers > every year, I'll change my position to support. Otherwise, I'll > imagine myself in their shoes and ask: what would Bill Herrin want? > > Bill Herrin wouldn't want to buy expensive new equipment any sooner > than he has to, especially not because someone else changed the rules. > Now come, now Bill. We all change the rules to help each other out, that is the point of this. You and your ISP or your employers or whatever all cost the rest of us money, too - your existence costs people money. Please don't circle the wagons here, we are going to have enough of that post-IPv4 runout. Ted From sethm at rollernet.us Mon Nov 9 16:08:43 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 09 Nov 2009 13:08:43 -0800 Subject: [arin-ppml] [arin-announce] [Fwd: Policy Proposal 103: Change IPv6 Allocation Process] In-Reply-To: <4AF86EE1.2010502@arin.net> References: <4AF86EE1.2010502@arin.net> Message-ID: <4AF884DB.9000000@rollernet.us> Member Services wrote: > > Q. Why allocate the /48's from a pool only for /48's, /32's from a /32 > pool, etc.? Why not allocate from just one pool? > > A. If all assignments in a particular pool are /32 then any route in > the /32 pool which is longer than /32 is a traffic engineering (TE) > route. As a router operator you can filter and discard TE routes if > you find they give you insufficient benefit. The routes you filter > don't cost you any money; only the routes you keep carry a price tag. > Hallelujah, I dislike TE with a passion. Overall I like this policy. I agree that the utilization concept should be abandoned for IPv6 and there's nothing inherently wrong with classful addressing other than there simply wasn't enough space to go around under IPv4. > The above notwithstanding, it may be advisable to discount /40s and > /32s to a much lower price during IPv6's general deployment process in > order to encourage adoption. Folks who already hold /31's should > probably also get a big break on the $20k fee for a good long while, > perhaps until the first time they request an additional block without > offering a plan to return the legacy addresses. To encourage adoption it should be as cheap as possible for the early adopters. How would this integrate with IPv4 fees? Or would we pay totally separate IPv4 and IPv6 fees? I have a question: is there any reason to trade an existing /32 for one under this policy? ~Seth From bill at herrin.us Mon Nov 9 16:23:26 2009 From: bill at herrin.us (William Herrin) Date: Mon, 9 Nov 2009 16:23:26 -0500 Subject: [arin-ppml] Policy Proposal 102: Reduce and Simplify IPv4 Initial Allocations In-Reply-To: <4AF88019.8010309@ipinc.net> References: <4AF31D95.9050605@arin.net> <3c3e3fca0911060634u4a5b11c1g7fc3371d0158c2ae@mail.gmail.com> <4AF48DF7.2030207@ipinc.net> <3c3e3fca0911061729v63b896a6hff2c27e947f4b4cd@mail.gmail.com> <4AF86C51.1040804@ipinc.net> <3c3e3fca0911091151i13a97eccge254c54cf5dc715@mail.gmail.com> <4AF88019.8010309@ipinc.net> Message-ID: <3c3e3fca0911091323q11ccf53du3151dfebf3a1eb91@mail.gmail.com> On Mon, Nov 9, 2009 at 3:48 PM, Ted Mittelstaedt wrote: > William Herrin wrote: >> >> On Mon, Nov 9, 2009 at 2:24 PM, Ted Mittelstaedt wrote: >>> >>> William Herrin wrote: >>>> >>>> But that's entirely beside the point. Single-homed entities require >>>> zero routes in the DFZ to function as designed on a day to day basis >>>> while multihomed entities require at least one. That was the point. > Bill, I hate to point it out to you but you did not make any statement of > /20 in your post of the 6th, you were speaking generally and I > responded by pointing out out that everything /20 and above didn't > follow this general statement. Does it help you better understand my position if you adjust the above to read "Singled-homed entities which do not currently hold addresses directly from ARIN require zero routes?" > However, multihomers who qualify for a /22 right now are completely > free to KEEP that /22 and go get another /22, when requesting an > additional allocation. ?Thus, creating 2 DFZ entries. > > Under this proposal we put a stop to that. ?Multihomers no longer exist > as a special class, when ANYONE gets a /22 and then goes and requests > an additional allocation, they will have to return that first /22 to get > their /21. ?Thus, knocking then back down to 1 DFZ entry. Hmm. I missed that on the first read. Not sure what I think of it. Regards, Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From sethm at rollernet.us Mon Nov 9 16:26:48 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 09 Nov 2009 13:26:48 -0800 Subject: [arin-ppml] Policy Proposal 102: Reduce and Simplify IPv4 Initial Allocations In-Reply-To: <3c3e3fca0911091323q11ccf53du3151dfebf3a1eb91@mail.gmail.com> References: <4AF31D95.9050605@arin.net> <3c3e3fca0911060634u4a5b11c1g7fc3371d0158c2ae@mail.gmail.com> <4AF48DF7.2030207@ipinc.net> <3c3e3fca0911061729v63b896a6hff2c27e947f4b4cd@mail.gmail.com> <4AF86C51.1040804@ipinc.net> <3c3e3fca0911091151i13a97eccge254c54cf5dc715@mail.gmail.com> <4AF88019.8010309@ipinc.net> <3c3e3fca0911091323q11ccf53du3151dfebf3a1eb91@mail.gmail.com> Message-ID: <4AF88918.7080604@rollernet.us> William Herrin wrote: > On Mon, Nov 9, 2009 at 3:48 PM, Ted Mittelstaedt wrote: >> However, multihomers who qualify for a /22 right now are completely >> free to KEEP that /22 and go get another /22, when requesting an >> additional allocation. Thus, creating 2 DFZ entries. >> >> Under this proposal we put a stop to that. Multihomers no longer exist >> as a special class, when ANYONE gets a /22 and then goes and requests >> an additional allocation, they will have to return that first /22 to get >> their /21. Thus, knocking then back down to 1 DFZ entry. > > Hmm. I missed that on the first read. Not sure what I think of it. > That's what I was opposing, not availability to small entities. ~Seth From tedm at ipinc.net Mon Nov 9 18:14:36 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 09 Nov 2009 15:14:36 -0800 Subject: [arin-ppml] Policy Proposal 102: Reduce and Simplify IPv4 Initial Allocations In-Reply-To: <4AF88918.7080604@rollernet.us> References: <4AF31D95.9050605@arin.net> <3c3e3fca0911060634u4a5b11c1g7fc3371d0158c2ae@mail.gmail.com> <4AF48DF7.2030207@ipinc.net> <3c3e3fca0911061729v63b896a6hff2c27e947f4b4cd@mail.gmail.com> <4AF86C51.1040804@ipinc.net> <3c3e3fca0911091151i13a97eccge254c54cf5dc715@mail.gmail.com> <4AF88019.8010309@ipinc.net> <3c3e3fca0911091323q11ccf53du3151dfebf3a1eb91@mail.gmail.com> <4AF88918.7080604@rollernet.us> Message-ID: <4AF8A25C.9060603@ipinc.net> Seth Mattinen wrote: > William Herrin wrote: >> On Mon, Nov 9, 2009 at 3:48 PM, Ted Mittelstaedt wrote: >>> However, multihomers who qualify for a /22 right now are completely >>> free to KEEP that /22 and go get another /22, when requesting an >>> additional allocation. Thus, creating 2 DFZ entries. >>> >>> Under this proposal we put a stop to that. Multihomers no longer exist >>> as a special class, when ANYONE gets a /22 and then goes and requests >>> an additional allocation, they will have to return that first /22 to get >>> their /21. Thus, knocking then back down to 1 DFZ entry. >> Hmm. I missed that on the first read. Not sure what I think of it. >> > > That's what I was opposing, not availability to small entities. > Seth, Well, then, here's the crux of the issue. When a small entity obtains multiple /22's under section 4.2.2.2, they create multiple advertisements in the DFZ, in Bill's words - costing all of the rest of us more money. Bill's assertion is that small entities costing us all money is unfair, which is why he opposes modification to 4.2.2.1. Bill refuses to discuss his opinion on the CURRENT 4.2.2.2, but clearly he must oppose the current minimums in 4.2.2.2 also - or he would be inconsistent - which is why when I pointed out that the policy proposal gets rid of that loophole (for smal multihomers) he says now that he no longer has an opinion. In short, he's being consistent - his basic position is anything that increases the DFZ is bad. You, by contrast, are making a different argument. Your opposition isn't based on what is or isn't good for the DFZ, your basic position - clarify me if I'm wrong - is that once ARIN hands out a sub-/20 allocation, the receiving org should be able to regard it as a permanent assignment. If you were being consistent then you would NOT oppose this proposal if it only affected orgs under section 4.2.2.1 (ie: the single-homers) The problem I see (and I am guessing that Chris sees as well) is that there's no way that someone coming from Bill's position of anti-DFZ growth could ever be satisfied with a proposal that made someone from your position, (the permanent assignment position) happy. These 2 positions are incompatible. If we rewrite a proposal that only affects 4.2.2.1 (for example, suppose I modified Proposal 98 to get rid of the triggers and just make it apply immediately) so that the permanent assignment people are happy, then the anti-DFZ-growth people are going to oppose it because it would increase the DFZ, because the multihomer loophole will still be around. If we rewrite Section 4.2.2.2 to include forced return-and-renumber, (essentially what this proposal does) then the anti-DFZ-growth people will be happy but the permanent assignment people will not be. The anti-DFZ-growth people are already unhappy about the DFZ loophole in 4.2.2.2 as it is. And the small single-homers who are currently tied to LIR-assignments that they are afraid will go away post-IPv4 runout, are EXTREMELY unhappy about things as it is now - and would be overjoyed to get anything at all - like this proposal. So, like Chris, I have to basically say that the most we could do is possibly respond to your criticism of it by playing around with the math a bit - like for example a renumbering requirement of /22 like Chris was suggesting - but even then we risk opposition from the anti-DFZ-growth people, so if playing around with the math isn't enough for the permanent assignment people to change their opposition to support, then it would be pointless to bother trying even that. As I see it, the small sub-/20 multihomer ISPs out there have had plenty of time to get their initial allocations under Section 4.2.2.2. They know IPv4-runout is coming, the bar was made lower for them to get their portable IPv4 a long time ago. If there's any of them out there who absolutely must get their "never-will-need-to-renumber-/22" then since this policy proposal change is going to take a half a year to implement, they are going to have PLENTY of warning. And, in 2-3 years it won't matter anyway, since there won't be virgin IPv4 at the RIR's left. As much as I'd like to accommodate the permanent assignment people, I think there's a lot more of the anti-DFZ-growth people out there, and in this proposal I'm frankly more interested in looking out for the small single-homers who I really believe are going to be jacked around once the IPv4 transfer market starts up. Ted From sethm at rollernet.us Mon Nov 9 19:19:49 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 09 Nov 2009 16:19:49 -0800 Subject: [arin-ppml] Policy Proposal 102: Reduce and Simplify IPv4 Initial Allocations In-Reply-To: <4AF8A25C.9060603@ipinc.net> References: <4AF31D95.9050605@arin.net> <3c3e3fca0911060634u4a5b11c1g7fc3371d0158c2ae@mail.gmail.com> <4AF48DF7.2030207@ipinc.net> <3c3e3fca0911061729v63b896a6hff2c27e947f4b4cd@mail.gmail.com> <4AF86C51.1040804@ipinc.net> <3c3e3fca0911091151i13a97eccge254c54cf5dc715@mail.gmail.com> <4AF88019.8010309@ipinc.net> <3c3e3fca0911091323q11ccf53du3151dfebf3a1eb91@mail.gmail.com> <4AF88918.7080604@rollernet.us> <4AF8A25C.9060603@ipinc.net> Message-ID: <4AF8B1A5.1010602@rollernet.us> Ted Mittelstaedt wrote: > If we rewrite a proposal that only affects 4.2.2.1 (for example, > suppose I modified Proposal 98 to get rid of the triggers and just > make it apply immediately) so that the permanent assignment people > are happy, then the anti-DFZ-growth people are going > to oppose it because it would increase the DFZ, because the multihomer > loophole will still be around. > > If we rewrite Section 4.2.2.2 to include forced return-and-renumber, > (essentially what this proposal does) then the anti-DFZ-growth people > will be happy but the permanent assignment people will not be. Neither will my customers if they're forced to renumber more than never. Remember, an incoming colo customer may have already had to renumber to come to me and will have to renumber to leave me. My concern is the hardship to customers and if they say "screw this, if I have to renumber anyway, goodbye". A small entity like myself may not be able to survive that. But my space will be reclaimed if I fold, so is that the point? > The anti-DFZ-growth people are already unhappy about the DFZ loophole > in 4.2.2.2 as it is. And the small single-homers who are currently > tied to LIR-assignments that they are afraid will go away post-IPv4 > runout, are EXTREMELY unhappy about things as it is now - and would > be overjoyed to get anything at all - like this proposal. Why would their assigned space go away post runout? Are they forced to give it back or something? I must have missed something. > So, like Chris, I have to basically say that the most we could do > is possibly respond to your criticism of it by playing around with > the math a bit - like for example a renumbering requirement of /22 > like Chris was suggesting - but even then we risk opposition from > the anti-DFZ-growth people, so if playing around with the math isn't > enough for the permanent assignment people to change their opposition to > support, then it would be pointless to bother trying even that. > > As I see it, the small sub-/20 multihomer ISPs out there have had > plenty of time to get their initial allocations under Section 4.2.2.2. > They know IPv4-runout is coming, the bar was made lower for them to > get their portable IPv4 a long time ago. If there's any of them out > there who absolutely must get their "never-will-need-to-renumber-/22" > then since this policy proposal change is going to take a half a year to > implement, they are going to have PLENTY of warning. And, in 2-3 years > it won't matter anyway, since there won't be virgin IPv4 at the RIR's > left. > > As much as I'd like to accommodate the permanent assignment people, I > think there's a lot more of the anti-DFZ-growth people out there, and in > this proposal I'm frankly more interested in looking out for the small > single-homers who I really believe are going to be jacked around once > the IPv4 transfer market starts up. > So then let me ask a practical question. I have a /22 - been using it for a few years now since renumbering from two PA /24's. I just got a /21 because I moved to a new, larger place only last month giving me the physical space to take on more colos. What happens when I need to apply for more space? Do I just tell my customers too bad you can't expand and close up shop when too many leave? I guess I really don't understand this at all and as long as I'm protected as legacy, so I withdraw my original opposition and neither support nor oppose this policy. ~Seth From tedm at ipinc.net Mon Nov 9 20:21:47 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 09 Nov 2009 17:21:47 -0800 Subject: [arin-ppml] Policy Proposal 102: Reduce and Simplify IPv4 Initial Allocations In-Reply-To: <4AF8B1A5.1010602@rollernet.us> References: <4AF31D95.9050605@arin.net> <3c3e3fca0911060634u4a5b11c1g7fc3371d0158c2ae@mail.gmail.com> <4AF48DF7.2030207@ipinc.net> <3c3e3fca0911061729v63b896a6hff2c27e947f4b4cd@mail.gmail.com> <4AF86C51.1040804@ipinc.net> <3c3e3fca0911091151i13a97eccge254c54cf5dc715@mail.gmail.com> <4AF88019.8010309@ipinc.net> <3c3e3fca0911091323q11ccf53du3151dfebf3a1eb91@mail.gmail.com> <4AF88918.7080604@rollernet.us> <4AF8A25C.9060603@ipinc.net> <4AF8B1A5.1010602@rollernet.us> Message-ID: <4AF8C02B.9000502@ipinc.net> Seth Mattinen wrote: > Ted Mittelstaedt wrote: >> If we rewrite a proposal that only affects 4.2.2.1 (for example, >> suppose I modified Proposal 98 to get rid of the triggers and just >> make it apply immediately) so that the permanent assignment people >> are happy, then the anti-DFZ-growth people are going >> to oppose it because it would increase the DFZ, because the multihomer >> loophole will still be around. >> >> If we rewrite Section 4.2.2.2 to include forced return-and-renumber, >> (essentially what this proposal does) then the anti-DFZ-growth people >> will be happy but the permanent assignment people will not be. > > Neither will my customers if they're forced to renumber more than never. > Remember, an incoming colo customer may have already had to renumber to > come to me and will have to renumber to leave me. My concern is the > hardship to customers and if they say "screw this, if I have to renumber > anyway, goodbye". I think the most important thing you can convey to your customers is that renumbering is inevitable, no matter what ISP they select. Even if they quit you and go to a larger ISP, what do they think is going to happen when the IPv4 shortage a few years after runout is so bad that even the large ISP's have programs to cleanup sparse assignments so they can offer IPv4 blocks for sale? But in any case, you always have the choice to continue using your LIR-assigned IPv4 and NOT filing for an initial allocation. If your very happy with your upstream and are sure they will always be nice to you, then it would make the best sense to just keep using their numbers and let them deal with having to dig around on the transfer market post-IPv4 runout to find more. It seems to me that your describing only one side of the proverbial "between a rock and a hard place" A small ISP that gets a provisional assignment from ARIN is no worse than a small ISP that has LIR-assigned numbers. If their upstream LIR decides to jack up their rates, and their only option is to go to another upstream feed, they are going to have to renumber anyway, thus downstream customers will have to renumber. The only small ISPs that would come out worse under this are the ones who qualify NOW under the multihomer section, and are sitting on their hands doing nothing - and the ONLY THING they lose is that they know that if they file for an initial allocation sometime in the next 2 years, that is under a /20 in size, that it might be permanent if they upgrade later. But if they don't qualify now, in 2009, then when do they think they will qualify under Section 4.2.2.2? Next year? Two years from now? I got news for them - by then the virgin IPv4 will be gone. And if they DO qualify now and are doing nothing, then why are you wanting to allow them to continue to do nothing for the next 2-3 years until IPv4 runout makes it so they definitely won't be able to get numbers from the RIR? > A small entity like myself may not be able to survive > that. But my space will be reclaimed if I fold, so is that the point? > > >> The anti-DFZ-growth people are already unhappy about the DFZ loophole >> in 4.2.2.2 as it is. And the small single-homers who are currently >> tied to LIR-assignments that they are afraid will go away post-IPv4 >> runout, are EXTREMELY unhappy about things as it is now - and would >> be overjoyed to get anything at all - like this proposal. > > Why would their assigned space go away post runout? Are they forced to > give it back or something? I must have missed something. > It won't go away but you can imagine that in a few years after IPv4 runout, that LIR's who are having to pay a lot of money for IPv4 transfers for new blocks are going to pass those costs along to their customers, particularly customers who have a lot of IPv4 from them. And in some cases, suppose a customer has a /22 from an ISP that went bankrupt, and was sold to a second ISP, and that second ISP already has a /17 with space available in it, well that second ISP may go to that customer and tell them they have to renumber into the /17 so that they can vacate the /22 and sell it. > >> So, like Chris, I have to basically say that the most we could do >> is possibly respond to your criticism of it by playing around with >> the math a bit - like for example a renumbering requirement of /22 >> like Chris was suggesting - but even then we risk opposition from >> the anti-DFZ-growth people, so if playing around with the math isn't >> enough for the permanent assignment people to change their opposition to >> support, then it would be pointless to bother trying even that. >> >> As I see it, the small sub-/20 multihomer ISPs out there have had >> plenty of time to get their initial allocations under Section 4.2.2.2. >> They know IPv4-runout is coming, the bar was made lower for them to >> get their portable IPv4 a long time ago. If there's any of them out >> there who absolutely must get their "never-will-need-to-renumber-/22" >> then since this policy proposal change is going to take a half a year to >> implement, they are going to have PLENTY of warning. And, in 2-3 years >> it won't matter anyway, since there won't be virgin IPv4 at the RIR's >> left. >> >> As much as I'd like to accommodate the permanent assignment people, I >> think there's a lot more of the anti-DFZ-growth people out there, and in >> this proposal I'm frankly more interested in looking out for the small >> single-homers who I really believe are going to be jacked around once >> the IPv4 transfer market starts up. >> > > So then let me ask a practical question. > > I have a /22 - been using it for a few years now since renumbering from > two PA /24's. I just got a /21 because I moved to a new, larger place > only last month giving me the physical space to take on more colos. What > happens when I need to apply for more space? Do I just tell my customers > too bad you can't expand and close up shop when too many leave? > You did not get your numbers when a policy like this was in force so you never agreed to renumber and return that /21 in order to get a larger additional allocation. It's only the people who haven't filed by the time a policy change like this goes into effect who are going to have to agree to renumber and return their small holdings. > I guess I really don't understand this at all and as long as I'm > protected as legacy, so I withdraw my original opposition and neither > support nor oppose this policy. > I can't guarantee you will be protected as legacy, as there's been discussion in the past about the old legacy holders from pre-ARIN days and possibly getting some of their /8's and such back. But, I think that the very largest players on the Internet are totally uninterested in participating in an IPv4 transfer market because they know that as they have the deepest pockets, they will get the most screwed over - and as a result, they all are planning on being ready with IPv6 when IPv4 runs out. Once the big players are doing IPv6 at the retail level, it's going to put huge pressure on everyone to get on the stick and do IPv6, and I suspect that the IPv4 transfer market won't last more than 5-10 years at the most. Ted From sethm at rollernet.us Mon Nov 9 21:27:15 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 09 Nov 2009 18:27:15 -0800 Subject: [arin-ppml] Policy Proposal 102: Reduce and Simplify IPv4 Initial Allocations In-Reply-To: <4AF8C02B.9000502@ipinc.net> References: <4AF31D95.9050605@arin.net> <3c3e3fca0911060634u4a5b11c1g7fc3371d0158c2ae@mail.gmail.com> <4AF48DF7.2030207@ipinc.net> <3c3e3fca0911061729v63b896a6hff2c27e947f4b4cd@mail.gmail.com> <4AF86C51.1040804@ipinc.net> <3c3e3fca0911091151i13a97eccge254c54cf5dc715@mail.gmail.com> <4AF88019.8010309@ipinc.net> <3c3e3fca0911091323q11ccf53du3151dfebf3a1eb91@mail.gmail.com> <4AF88918.7080604@rollernet.us> <4AF8A25C.9060603@ipinc.net> <4AF8B1A5.1010602@rollernet.us> <4AF8C02B.9000502@ipinc.net> Message-ID: <4AF8CF83.4020807@rollernet.us> Ted Mittelstaedt wrote: > Seth Mattinen wrote: >> >> Neither will my customers if they're forced to renumber more than never. >> Remember, an incoming colo customer may have already had to renumber to >> come to me and will have to renumber to leave me. My concern is the >> hardship to customers and if they say "screw this, if I have to renumber >> anyway, goodbye". > > I think the most important thing you can convey to your customers is > that renumbering is inevitable, no matter what ISP they select. Even > if they quit you and go to a larger ISP, what do they think is going > to happen when the IPv4 shortage a few years after runout is so bad that > even the large ISP's have programs to cleanup sparse assignments so > they can offer IPv4 blocks for sale? The point I was trying to make was that the large ISP will still survive whereas the small one won't. > But in any case, you always have the choice to continue using your > LIR-assigned IPv4 and NOT filing for an initial allocation. If your > very happy with your upstream and are sure they will always be nice > to you, then it would make the best sense to just keep using their > numbers and let them deal with having to dig around on the transfer > market post-IPv4 runout to find more. Having recently has a glimpse into the world snowshoe I have a different view. There is so much space being "rented" right now it's not even funny. A huge amount of it sits around idle so it will "clean up". I can get multiple /18's and up with a phone call and enough money. We don't have to wait for runout, these guys will be ready and willing to sell addresses to a brand new market when the time comes. > It seems to me that your describing only one side of the proverbial > "between a rock and a hard place" > > A small ISP that gets a provisional assignment from ARIN is no worse > than a small ISP that has LIR-assigned numbers. If their upstream > LIR decides to jack up their rates, and their only option is to > go to another upstream feed, they are going to have to renumber anyway, > thus downstream customers will have to renumber. If I had PA space (I don't) and that happened, I would just pass it on to the customer as a fee. I believe we will see the routing table explode as people grab PA space and multihome it, sending everyone scrambling to damp it with new prefix filters. > The only small ISPs that would come out worse under this are the > ones who qualify NOW under the multihomer section, and are sitting on > their hands doing nothing - and the ONLY THING they lose is that > they know that if they file for an initial allocation sometime in > the next 2 years, that is under a /20 in size, that it might be > permanent if they upgrade later. But if they don't qualify now, in > 2009, then when do they think they will qualify under Section 4.2.2.2? > Next year? Two years from now? I got news for them - by then the > virgin IPv4 will be gone. And if they DO qualify now and are doing > nothing, then why are you wanting to allow them to continue to do > nothing for the next 2-3 years until IPv4 runout makes it so they > definitely won't be able to get numbers from the RIR? Are there really any ISP's out there operating on a single /24 anymore? (serious question) The days of small ISP's with a rack-o-modems in the back room is long gone. No policy change we make will motivate anyone. >> >> Why would their assigned space go away post runout? Are they forced to >> give it back or something? I must have missed something. >> > > It won't go away but you can imagine that in a few years after IPv4 > runout, that LIR's who are having to pay a lot of money for IPv4 > transfers for new blocks are going to pass those costs along to > their customers, particularly customers who have a lot of IPv4 > from them. > > And in some cases, suppose a customer has a /22 from an ISP that > went bankrupt, and was sold to a second ISP, and that second ISP > already has a /17 with space available in it, well that second > ISP may go to that customer and tell them they have to renumber > into the /17 so that they can vacate the /22 and sell it. I'd "sell" my /22 and /21 on a transfer if this kind of policy hurts me enough to where I need to money to close up without a bankruptcy, so keep that in mind when crafting policies that could potentially drive someone of my size out of business and help create supply. Maybe shell it out to the brokers I mentioned earlier. >> >> So then let me ask a practical question. >> >> I have a /22 - been using it for a few years now since renumbering from >> two PA /24's. I just got a /21 because I moved to a new, larger place >> only last month giving me the physical space to take on more colos. What >> happens when I need to apply for more space? Do I just tell my customers >> too bad you can't expand and close up shop when too many leave? >> > > You did not get your numbers when a policy like this was in force so you > never agreed to renumber and return that /21 in order to get a larger > additional allocation. It's only the people who haven't filed by > the time a policy change like this goes into effect who are going to > have to agree to renumber and return their small holdings. Can't this possibly trigger people starting to horde addresses earlier? First thing that came to mind for me is "crap, I'd better think about latching on to some additional space right now if this passes." >> I guess I really don't understand this at all and as long as I'm >> protected as legacy, so I withdraw my original opposition and neither >> support nor oppose this policy. >> > > I can't guarantee you will be protected as legacy, as there's been > discussion in the past about the old legacy holders from pre-ARIN days > and possibly getting some of their /8's and such back. But, I > think that the very largest players on the Internet are totally > uninterested in participating in an IPv4 transfer market because > they know that as they have the deepest pockets, they will get the > most screwed over - and as a result, they all are planning on being > ready with IPv6 when IPv4 runs out. > We can't really do anything about pre-ARIN or existing agreements, so it's best to forget about it and move on and up. But I don't believe they are all planning on IPv6 in the near term. See my recent somewhat public fight with Verizon re: exactly that. Maybe if someone could convince the world to route IPv6 as fully as IPv4... but no, they're trying to keep costs down, and *not* supporting IPv6 completely is part of that goal. ~Seth From michael at rancid.berkeley.edu Tue Nov 10 01:08:07 2009 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Mon, 09 Nov 2009 22:08:07 -0800 Subject: [arin-ppml] [arin-announce] [Fwd: Policy Proposal 103: Change IPv6 Allocation Process] In-Reply-To: <4AF884DB.9000000@rollernet.us> References: <4AF86EE1.2010502@arin.net> <4AF884DB.9000000@rollernet.us> Message-ID: <4AF90347.3090201@rancid.berkeley.edu> On 11/09/09 13:08, Seth Mattinen wrote: > Member Services wrote: >> Q. Why allocate the /48's from a pool only for /48's, /32's from a /32 >> pool, etc.? Why not allocate from just one pool? >> >> A. If all assignments in a particular pool are /32 then any route in >> the /32 pool which is longer than /32 is a traffic engineering (TE) >> route. As a router operator you can filter and discard TE routes if >> you find they give you insufficient benefit. The routes you filter >> don't cost you any money; only the routes you keep carry a price tag. >> > > Hallelujah, I dislike TE with a passion. > > Overall I like this policy. I agree that the utilization concept should > be abandoned for IPv6 and there's nothing inherently wrong with classful > addressing other than there simply wasn't enough space to go around > under IPv4. I have to say that this policy is kind of refreshing, in that it attempts to do away with IPv4-style thinking. In IPv4, we have to worry about conservation of IP addresses. In IPv6, we should be worrying about conservation of IP address *allocations/assignments*. The policy recognizes that both allocations (from ARIN) and assignments (from LIRs) can cause routing table bloat. IPv6 allocation strategies have been unspokenly classful since their inception. ("You mean I have to give you a /56 on your home network just because you need two subnets? Or even a /48??") It's time to call a spade a spade and acknowledge that we really are going (sort of) back to classful addressing. And we need to come to terms with the fact that massive aggregation just isn't a viable strategy for IPv6 adoption in today's internet. Give multihomed organizations the one prefix that they will have for the lifetime of IPv6 and be done with it. I'd definitely like to see more debate, but I think the AC should give a close look to this proposal. michael From bill at herrin.us Tue Nov 10 11:47:35 2009 From: bill at herrin.us (William Herrin) Date: Tue, 10 Nov 2009 11:47:35 -0500 Subject: [arin-ppml] [arin-announce] [Fwd: Policy Proposal 103: Change IPv6 Allocation Process] In-Reply-To: <4AF884DB.9000000@rollernet.us> References: <4AF86EE1.2010502@arin.net> <4AF884DB.9000000@rollernet.us> Message-ID: <3c3e3fca0911100847g4cc107cbu8b8ea3b19c1d0011@mail.gmail.com> On Mon, Nov 9, 2009 at 4:08 PM, Seth Mattinen wrote: > Hallelujah, I dislike TE with a passion. > > Overall I like this policy. I agree that the utilization concept should > be abandoned for IPv6 and there's nothing inherently wrong with classful > addressing other than there simply wasn't enough space to go around > under IPv4. Hi Seth, Thanks. :) >> The above notwithstanding, it may be advisable to discount /40s and >> /32s to a much lower price during IPv6's general deployment process in >> order to encourage adoption. Folks who already hold /31's should >> probably also get a big break on the $20k fee for a good long while, >> perhaps until the first time they request an additional block without >> offering a plan to return the legacy addresses. > > To encourage adoption it should be as cheap as possible for the early > adopters. How would this integrate with IPv4 fees? Or would we pay > totally separate IPv4 and IPv6 fees? I don't know. The proposal offers some suggestions and guidance about fees but fees are not properly the domain of a policy proposal. I'm reluctant to make a more specific recommendation than I already have lest the folks who *are* responsible for setting ARIN fees decide I should take a flying leap. > I have a question: is there any reason to trade an existing /32 for one > under this policy? The existing /32 shares a pool with /31's and /30's which are, as a result, disaggregable. I doubt anyone will ever filter that pool, it'll be just like the IPv4 swamp, but you never know. On the other hand, there's a respectable chance that Verizon will stick to their guns about not routing /48's that share a pool with /40's and /44's. Should they decide that a multihomed /48 *is* routeable when the absence of TE and single-homers is guaranteed, registrants in the old /48 pool may well want to trade up. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From tedm at ipinc.net Tue Nov 10 16:58:22 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 10 Nov 2009 13:58:22 -0800 Subject: [arin-ppml] Policy Proposal 102: Reduce and Simplify IPv4 Initial Allocations In-Reply-To: <4AF8CF83.4020807@rollernet.us> References: <4AF31D95.9050605@arin.net> <3c3e3fca0911060634u4a5b11c1g7fc3371d0158c2ae@mail.gmail.com> <4AF48DF7.2030207@ipinc.net> <3c3e3fca0911061729v63b896a6hff2c27e947f4b4cd@mail.gmail.com> <4AF86C51.1040804@ipinc.net> <3c3e3fca0911091151i13a97eccge254c54cf5dc715@mail.gmail.com> <4AF88019.8010309@ipinc.net> <3c3e3fca0911091323q11ccf53du3151dfebf3a1eb91@mail.gmail.com> <4AF88918.7080604@rollernet.us> <4AF8A25C.9060603@ipinc.net> <4AF8B1A5.1010602@rollernet.us> <4AF8C02B.9000502@ipinc.net> <4AF8CF83.4020807@rollernet.us> Message-ID: <4AF9E1FE.8020409@ipinc.net> Seth Mattinen wrote: > Ted Mittelstaedt wrote: >> Seth Mattinen wrote: >>> Neither will my customers if they're forced to renumber more than never. >>> Remember, an incoming colo customer may have already had to renumber to >>> come to me and will have to renumber to leave me. My concern is the >>> hardship to customers and if they say "screw this, if I have to renumber >>> anyway, goodbye". >> I think the most important thing you can convey to your customers is >> that renumbering is inevitable, no matter what ISP they select. Even >> if they quit you and go to a larger ISP, what do they think is going >> to happen when the IPv4 shortage a few years after runout is so bad that >> even the large ISP's have programs to cleanup sparse assignments so >> they can offer IPv4 blocks for sale? > > The point I was trying to make was that the large ISP will still survive > whereas the small one won't. > Well, one of the unspoken assumptions of the policy proposal is that in a post-IPv4-runout world, all ISP's will still need some IPv4 around even if they are going full-scale IPv6 deployment. Even if they are completely fully IPv6 and have it deployed everywhere, to all customers, they still are going to need a few IPv4 numbers to put on an IPv4 translator to supply IPv4 to their customers that need it. That is why we feel that the small ISPs that don't have portable IPv4 numbers now because they cannot qualify, are going to be at the mercy of the larger ISPs post-IPv4 runout. Thus, let's help them get those assignments now, before IPv4-runout - understanding that due to concerns with dfz growth, a lot of people aren't going to support just dropping the minimums unless there's something in it that will mitigate the growth of the dfz. > >> But in any case, you always have the choice to continue using your >> LIR-assigned IPv4 and NOT filing for an initial allocation. If your >> very happy with your upstream and are sure they will always be nice >> to you, then it would make the best sense to just keep using their >> numbers and let them deal with having to dig around on the transfer >> market post-IPv4 runout to find more. > > Having recently has a glimpse into the world snowshoe I have a different > view. There is so much space being "rented" right now it's not even > funny. A huge amount of it sits around idle so it will "clean up". I can > get multiple /18's and up with a phone call and enough money. We don't > have to wait for runout, these guys will be ready and willing to sell > addresses to a brand new market when the time comes. > If your right and the hoarders flood the market with IPv4 once the RIR's run out, then so be it - I guarantee that if what they do causes a problem, the ARIN community will shut it down. That's the problem with designing a business plan around hoarding - it's going to be tolerated only as long as you don't make a nuisance of yourself. > >> It seems to me that your describing only one side of the proverbial >> "between a rock and a hard place" >> >> A small ISP that gets a provisional assignment from ARIN is no worse >> than a small ISP that has LIR-assigned numbers. If their upstream >> LIR decides to jack up their rates, and their only option is to >> go to another upstream feed, they are going to have to renumber anyway, >> thus downstream customers will have to renumber. > > If I had PA space (I don't) and that happened, I would just pass it on > to the customer as a fee. which then triggers the scenario you originally described, the "screw this, if I have to renumber anyway, goodbye" which your trying to avoid, I thought. > I believe we will see the routing table > explode as people grab PA space and multihome it, sending everyone > scrambling to damp it with new prefix filters. > Could be. > >> The only small ISPs that would come out worse under this are the >> ones who qualify NOW under the multihomer section, and are sitting on >> their hands doing nothing - and the ONLY THING they lose is that >> they know that if they file for an initial allocation sometime in >> the next 2 years, that is under a /20 in size, that it might be >> permanent if they upgrade later. But if they don't qualify now, in >> 2009, then when do they think they will qualify under Section 4.2.2.2? >> Next year? Two years from now? I got news for them - by then the >> virgin IPv4 will be gone. And if they DO qualify now and are doing >> nothing, then why are you wanting to allow them to continue to do >> nothing for the next 2-3 years until IPv4 runout makes it so they >> definitely won't be able to get numbers from the RIR? > > Are there really any ISP's out there operating on a single /24 anymore? > (serious question) The days of small ISP's with a rack-o-modems in the > back room is long gone. No policy change we make will motivate anyone. > I think there's WISP's operating out there with 2 or 3 /24's. > > >>> Why would their assigned space go away post runout? Are they forced to >>> give it back or something? I must have missed something. >>> >> It won't go away but you can imagine that in a few years after IPv4 >> runout, that LIR's who are having to pay a lot of money for IPv4 >> transfers for new blocks are going to pass those costs along to >> their customers, particularly customers who have a lot of IPv4 >> from them. >> >> And in some cases, suppose a customer has a /22 from an ISP that >> went bankrupt, and was sold to a second ISP, and that second ISP >> already has a /17 with space available in it, well that second >> ISP may go to that customer and tell them they have to renumber >> into the /17 so that they can vacate the /22 and sell it. > > I'd "sell" my /22 and /21 on a transfer if this kind of policy hurts me > enough to where I need to money to close up without a bankruptcy, so > keep that in mind when crafting policies that could potentially drive > someone of my size out of business and help create supply. Maybe shell > it out to the brokers I mentioned earlier. > I don't think our idea is to try driving someone small out, rather the reverse. Our idea is that the small ISP's are going to get hit with this IPv4-to-IPv6 transition and it's going to be painful for them, more painful than for the large ISPs - yet, it wasn't the small ISPs out there chewing up IPv4 space lickty-split that is causing the IPv4 runout to begin with. It's a bit unfair. > >>> So then let me ask a practical question. >>> >>> I have a /22 - been using it for a few years now since renumbering from >>> two PA /24's. I just got a /21 because I moved to a new, larger place >>> only last month giving me the physical space to take on more colos. What >>> happens when I need to apply for more space? Do I just tell my customers >>> too bad you can't expand and close up shop when too many leave? >>> >> You did not get your numbers when a policy like this was in force so you >> never agreed to renumber and return that /21 in order to get a larger >> additional allocation. It's only the people who haven't filed by >> the time a policy change like this goes into effect who are going to >> have to agree to renumber and return their small holdings. > > Can't this possibly trigger people starting to horde addresses earlier? > First thing that came to mind for me is "crap, I'd better think about > latching on to some additional space right now if this passes." > I think the looming IPv4 shortage has already caused a lot of people to think this. I just yesterday setup a brand shiny new T1 for a customer to a national ISP (not us, unfortunately) and they were applying a /30 to the span itself - separate from the /29 that went to the customer. It was public IPs, not private, not unnumbered. Of course there's tons of legitimate technical reasons that they might choose to do this. But, it's POSSIBLE to do it unnumbered. I would think that post-IPv4 runout in about 5-10 years, that this national ISP will be running unnumbered on these links. Does this national ISP's use of a public /30 today on a span constitute hoarding? Well, let's just say that if 5-10 years from now their policy is to run unnumbered on T1 spans, then there seems to be no technical reason they can't do it today. Sure it's only 4 numbers - but this is one of the largest national ISPs out there, and I'm sure they have tens of thousands of spans. I think in 5-10 years we will be looking at this particular ISP and be saying "yep, they were hoarding" And they won't be the only ones. Likely there will be a horde of hoarders. ;-) > >>> I guess I really don't understand this at all and as long as I'm >>> protected as legacy, so I withdraw my original opposition and neither >>> support nor oppose this policy. >>> >> I can't guarantee you will be protected as legacy, as there's been >> discussion in the past about the old legacy holders from pre-ARIN days >> and possibly getting some of their /8's and such back. But, I >> think that the very largest players on the Internet are totally >> uninterested in participating in an IPv4 transfer market because >> they know that as they have the deepest pockets, they will get the >> most screwed over - and as a result, they all are planning on being >> ready with IPv6 when IPv4 runs out. >> > > We can't really do anything about pre-ARIN or existing agreements, so > it's best to forget about it and move on and up. But I don't believe > they are all planning on IPv6 in the near term. See my recent somewhat > public fight with Verizon re: exactly that. Maybe if someone could > convince the world to route IPv6 as fully as IPv4... but no, they're > trying to keep costs down, and *not* supporting IPv6 completely is part > of that goal. > There is a famous old quote (which I can't find the source to right now) "My enemies make their plans out of wire, I make my plans out of string, because string is a lot more flexible than wire" I suspect that a lot of them are making their IPv6 deployment plans out of string. Ted > ~Seth > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From sethm at rollernet.us Tue Nov 10 17:43:49 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 10 Nov 2009 14:43:49 -0800 Subject: [arin-ppml] Policy Proposal 102: Reduce and Simplify IPv4 Initial Allocations In-Reply-To: <4AF9E1FE.8020409@ipinc.net> References: <4AF31D95.9050605@arin.net> <3c3e3fca0911060634u4a5b11c1g7fc3371d0158c2ae@mail.gmail.com> <4AF48DF7.2030207@ipinc.net> <3c3e3fca0911061729v63b896a6hff2c27e947f4b4cd@mail.gmail.com> <4AF86C51.1040804@ipinc.net> <3c3e3fca0911091151i13a97eccge254c54cf5dc715@mail.gmail.com> <4AF88019.8010309@ipinc.net> <3c3e3fca0911091323q11ccf53du3151dfebf3a1eb91@mail.gmail.com> <4AF88918.7080604@rollernet.us> <4AF8A25C.9060603@ipinc.net> <4AF8B1A5.1010602@rollernet.us> <4AF8C02B.9000502@ipinc.net> <4AF8CF83.4020807@rollernet.us> <4AF9E1FE.8020409@ipinc.net> Message-ID: <4AF9ECA5.6080405@rollernet.us> Ted Mittelstaedt wrote: > Seth Mattinen wrote: >> >> Having recently has a glimpse into the world snowshoe I have a different >> view. There is so much space being "rented" right now it's not even >> funny. A huge amount of it sits around idle so it will "clean up". I can >> get multiple /18's and up with a phone call and enough money. We don't >> have to wait for runout, these guys will be ready and willing to sell >> addresses to a brand new market when the time comes. >> > > If your right and the hoarders flood the market with IPv4 once the RIR's > run out, then so be it - I guarantee that if what they do causes a > problem, the ARIN community will shut it down. That's the problem with > designing a business plan around hoarding - it's going to > be tolerated only as long as you don't make a nuisance of yourself. That's the fun thing I learned. They're borrowing space from people who have a surplus for a fee. Normally this surplus should be returned to ARIN especially since we're all panicky about IPv4 runout, right? Wrong. This is a bit OT, but here's what I know. Mr. W needs some address space at his colo. He can't qualify via the colo's rules or ARIN's. Mr. X calls himself an IP broker. All he does is arrange people that have spare IP space with people who need some IP space for whatever reason. Let's say me the ISP has an /18 that's unused. Mr. X will give me $Y to borrow that /18 for Z amount of time. He will turn around and tell Mr. W that he can advertise that /18 at his colo for $Y+markup. One of my friends who does consulting somehow got involved with Mr. X and started to see dollar signs. It took me several weeks of being totally confused to get behind the curtain and tell everyone I wasn't interested in letting other people reannounce my space outside of my AS. Wasn't there a policy to encourage return of resources? I don't remember. ARIN would have to find these orgs who are renting their space out to brokers and revoke it somehow to put a stop to it. >> >> If I had PA space (I don't) and that happened, I would just pass it on >> to the customer as a fee. > > which then triggers the scenario you originally described, the > "screw this, if I have to renumber anyway, goodbye" which your > trying to avoid, I thought. Yes, but I'm between a rock and a hard place, as you said. Can't afford to absorb the fee, can't pass it on. I don't have an answer. >> >> Are there really any ISP's out there operating on a single /24 anymore? >> (serious question) The days of small ISP's with a rack-o-modems in the >> back room is long gone. No policy change we make will motivate anyone. >> > > I think there's WISP's operating out there with 2 or 3 /24's. Then they probably already qualify as is unless they're single-homed. If they're multihomed and running on a lot of PA space due to lack of education >> >> We can't really do anything about pre-ARIN or existing agreements, so >> it's best to forget about it and move on and up. But I don't believe >> they are all planning on IPv6 in the near term. See my recent somewhat >> public fight with Verizon re: exactly that. Maybe if someone could >> convince the world to route IPv6 as fully as IPv4... but no, they're >> trying to keep costs down, and *not* supporting IPv6 completely is part >> of that goal. >> > > There is a famous old quote (which I can't find the source to right now) > > "My enemies make their plans out of wire, I make my plans out of string, > because string is a lot more flexible than wire" > > I suspect that a lot of them are making their IPv6 deployment plans > out of string. > Well, I've been IPv6 ready since 2005. It's still a horrible struggle to get upstream support though, which makes the quality suffer a bit more than IPv4, which means people aren't as interested, etc. all the way downhill. ~Seth From cgrundemann at gmail.com Tue Nov 10 18:01:06 2009 From: cgrundemann at gmail.com (Chris Grundemann) Date: Tue, 10 Nov 2009 16:01:06 -0700 Subject: [arin-ppml] Policy Proposal 102: Reduce and Simplify IPv4 Initial Allocations In-Reply-To: <4AF9ECA5.6080405@rollernet.us> References: <4AF31D95.9050605@arin.net> <4AF88019.8010309@ipinc.net> <3c3e3fca0911091323q11ccf53du3151dfebf3a1eb91@mail.gmail.com> <4AF88918.7080604@rollernet.us> <4AF8A25C.9060603@ipinc.net> <4AF8B1A5.1010602@rollernet.us> <4AF8C02B.9000502@ipinc.net> <4AF8CF83.4020807@rollernet.us> <4AF9E1FE.8020409@ipinc.net> <4AF9ECA5.6080405@rollernet.us> Message-ID: <443de7ad0911101501g6edecc35o3ce052ea8855e8fd@mail.gmail.com> On Tue, Nov 10, 2009 at 15:43, Seth Mattinen wrote: > Ted Mittelstaedt wrote: >> >> Seth Mattinen wrote: >>> >>> Having recently has a glimpse into the world snowshoe I have a different >>> view. There is so much space being "rented" right now it's not even >>> funny. A huge amount of it sits around idle so it will "clean up". I can >>> get multiple /18's and up with a phone call and enough money. We don't >>> have to wait for runout, these guys will be ready and willing to sell >>> addresses to a brand new market when the time comes. >>> >> >> If your right and the hoarders flood the market with IPv4 once the RIR's >> run out, then so be it - I guarantee that if what they do causes a >> problem, the ARIN community will shut it down. ?That's the problem with >> designing a business plan around hoarding - it's going to >> be tolerated only as long as you don't make a nuisance of yourself. > > That's the fun thing I learned. They're borrowing space from people who have > a surplus for a fee. Normally this surplus should be returned to ARIN > especially since we're all panicky about IPv4 runout, right? Wrong. > > This is a bit OT, but here's what I know. Mr. W needs some address space at > his colo. He can't qualify via the colo's rules or ARIN's. Mr. X calls > himself an IP broker. All he does is arrange people that have spare IP space > with people who need some IP space for whatever reason. Let's say me the ISP > has an /18 that's unused. Mr. X will give me $Y to borrow that /18 for Z > amount of time. He will turn around and tell Mr. W that he can advertise > that /18 at his colo for $Y+markup. One of my friends who does consulting > somehow got involved with Mr. X and started to see dollar signs. It took me > several weeks of being totally confused to get behind the curtain and tell > everyone I wasn't interested in letting other people reannounce my space > outside of my AS. > > Wasn't there a policy to encourage return of resources? I don't remember. > ARIN would have to find these orgs who are renting their space out to > brokers and revoke it somehow to put a stop to it. > > >>> >>> If I had PA space (I don't) and that happened, I would just pass it on >>> to the customer as a fee. >> >> which then triggers the scenario you originally described, the >> "screw this, if I have to renumber anyway, goodbye" which your >> trying to avoid, I thought. > > Yes, but I'm between a rock and a hard place, as you said. Can't afford to > absorb the fee, can't pass it on. I don't have an answer. > Do you still not see this policy as an answer to that problem? Is getting portable space that you may have to renumber out of worse than being at the whim of your upstream provider? ~Chris > > >>> >>> Are there really any ISP's out there operating on a single /24 anymore? >>> (serious question) The days of small ISP's with a rack-o-modems in the >>> back room is long gone. No policy change we make will motivate anyone. >>> >> >> I think there's WISP's operating out there with 2 or 3 /24's. > > Then they probably already qualify as is unless they're single-homed. If > they're multihomed and running on a lot of PA space due to lack of education > > >>> >>> We can't really do anything about pre-ARIN or existing agreements, so >>> it's best to forget about it and move on and up. But I don't believe >>> they are all planning on IPv6 in the near term. See my recent somewhat >>> public fight with Verizon re: exactly that. Maybe if someone could >>> convince the world to route IPv6 as fully as IPv4... but no, they're >>> trying to keep costs down, and *not* supporting IPv6 completely is part >>> of that goal. >>> >> >> There is a famous old quote (which I can't find the source to right now) >> >> "My enemies make their plans out of wire, I make my plans out of string, >> because string is a lot more flexible than wire" >> >> I suspect that a lot of them are making their IPv6 deployment plans >> out of string. >> > > Well, I've been IPv6 ready since 2005. It's still a horrible struggle to get > upstream support though, which makes the quality suffer a bit more than > IPv4, which means people aren't as interested, etc. all the way downhill. > > ~Seth > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org From tedm at ipinc.net Tue Nov 10 18:06:28 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 10 Nov 2009 15:06:28 -0800 Subject: [arin-ppml] Policy Proposal 102: Reduce and Simplify IPv4 Initial Allocations In-Reply-To: <4AF9ECA5.6080405@rollernet.us> References: <4AF31D95.9050605@arin.net> <3c3e3fca0911060634u4a5b11c1g7fc3371d0158c2ae@mail.gmail.com> <4AF48DF7.2030207@ipinc.net> <3c3e3fca0911061729v63b896a6hff2c27e947f4b4cd@mail.gmail.com> <4AF86C51.1040804@ipinc.net> <3c3e3fca0911091151i13a97eccge254c54cf5dc715@mail.gmail.com> <4AF88019.8010309@ipinc.net> <3c3e3fca0911091323q11ccf53du3151dfebf3a1eb91@mail.gmail.com> <4AF88918.7080604@rollernet.us> <4AF8A25C.9060603@ipinc.net> <4AF8B1A5.1010602@rollernet.us> <4AF8C02B.9000502@ipinc.net> <4AF8CF83.4020807@rollernet.us> <4AF9E1FE.8020409@ipinc.net> <4AF9ECA5.6080405@rollernet.us> Message-ID: <4AF9F1F4.20908@ipinc.net> Seth Mattinen wrote: > Ted Mittelstaedt wrote: >> Seth Mattinen wrote: >>> >>> Having recently has a glimpse into the world snowshoe I have a different >>> view. There is so much space being "rented" right now it's not even >>> funny. A huge amount of it sits around idle so it will "clean up". I can >>> get multiple /18's and up with a phone call and enough money. We don't >>> have to wait for runout, these guys will be ready and willing to sell >>> addresses to a brand new market when the time comes. >>> >> >> If your right and the hoarders flood the market with IPv4 once the RIR's >> run out, then so be it - I guarantee that if what they do causes a >> problem, the ARIN community will shut it down. That's the problem >> with designing a business plan around hoarding - it's going to >> be tolerated only as long as you don't make a nuisance of yourself. > > That's the fun thing I learned. They're borrowing space from people who > have a surplus for a fee. Normally this surplus should be returned to > ARIN especially since we're all panicky about IPv4 runout, right? Wrong. > > This is a bit OT, but here's what I know. Mr. W needs some address space > at his colo. He can't qualify via the colo's rules or ARIN's. Mr. X > calls himself an IP broker. All he does is arrange people that have > spare IP space with people who need some IP space for whatever reason. > Let's say me the ISP has an /18 that's unused. Mr. X will give me $Y to > borrow that /18 for Z amount of time. He will turn around and tell Mr. W > that he can advertise that /18 at his colo for $Y+markup. One of my > friends who does consulting somehow got involved with Mr. X and started > to see dollar signs. It took me several weeks of being totally confused > to get behind the curtain and tell everyone I wasn't interested in > letting other people reannounce my space outside of my AS. > > Wasn't there a policy to encourage return of resources? Yes, it's called "fees" > I don't > remember. ARIN would have to find these orgs who are renting their space > out to brokers and revoke it somehow to put a stop to it. > No reason to. ARIN charges org X with the spare space a fee, org X charges org Y who needs space, a fee. The main thing is that the IP addressing is in use. All Org's X responsibility to ARIN is that they keep it utilized and maintain the SWIPS on it. Those people aren't the problem. The problem are the orgs getting the space then doing nothing with it. > >>> >>> If I had PA space (I don't) and that happened, I would just pass it on >>> to the customer as a fee. >> >> which then triggers the scenario you originally described, the >> "screw this, if I have to renumber anyway, goodbye" which your >> trying to avoid, I thought. > > Yes, but I'm between a rock and a hard place, as you said. Can't afford > to absorb the fee, can't pass it on. I don't have an answer. > Yes, you do, but you won't like it. That is, you make a business decision to keep paying the LIR who assigned you space, so your customer doesn't have to renumber. You recognize that as long as your paying less to the LIR in fees than your charging the customer, your making money. If the LIR comes to you and says "we are going to raise rates" you tell them "I will cut service if you raise rates" (this assumes you know your customer won't pay anymore) Then the LIR has to decide if they are going to raise rates or not. If they do, then you cut service, and tell your customer that either vendor loyalty has meaning or it don't, and if it don't, well there's plenty of other customers out there where it does, and your going to service them. Obviously, you do it in a nice way with the usual offers of assistance to ease the pain of staying with you, but under the velvet, that's what it is. Ultimately, your not really making the decision - your customer is. Granted, they may make a decision disadvantageous to you. But in the long run if you know that's probably going to happen sometime in the future years, you can plan now to find other customers or do whatever so that when they leave, you will have something else to make money on. My employer purchased an ISP many years ago named "Clacknet" We knew when we bought it that all the customers would eventually leave. (it was small, 100 customers on the books, 30 of them freebies) And eventually they did. But, that's a perfectly legitimate business plan when there is no hope of building the business, due to how it's structured. It can be depressing, of course, but look at all of those outsource houses that handle dialup today for ISPs. Dialup is shrinking, but those guys are making money by aggregating all of the shrunken dialups from different ISP's together. Undoubtedly some of them won't survive as dialup use gets smaller and smaller, and the bigger ones will buy out the smaller ones. > > >>> >>> Are there really any ISP's out there operating on a single /24 anymore? >>> (serious question) The days of small ISP's with a rack-o-modems in the >>> back room is long gone. No policy change we make will motivate anyone. >>> >> >> I think there's WISP's operating out there with 2 or 3 /24's. > > Then they probably already qualify as is unless they're single-homed. If > they're multihomed and running on a lot of PA space due to lack of > education > > >>> >>> We can't really do anything about pre-ARIN or existing agreements, so >>> it's best to forget about it and move on and up. But I don't believe >>> they are all planning on IPv6 in the near term. See my recent somewhat >>> public fight with Verizon re: exactly that. Maybe if someone could >>> convince the world to route IPv6 as fully as IPv4... but no, they're >>> trying to keep costs down, and *not* supporting IPv6 completely is part >>> of that goal. >>> >> >> There is a famous old quote (which I can't find the source to right now) >> >> "My enemies make their plans out of wire, I make my plans out of >> string, because string is a lot more flexible than wire" >> >> I suspect that a lot of them are making their IPv6 deployment plans >> out of string. >> > > Well, I've been IPv6 ready since 2005. It's still a horrible struggle to > get upstream support though, which makes the quality suffer a bit more > than IPv4, which means people aren't as interested, etc. all the way > downhill. > Just keep plugging and don't let the bastards get you down. Ted > ~Seth > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From owen at delong.com Tue Nov 10 18:04:16 2009 From: owen at delong.com (Owen DeLong) Date: Tue, 10 Nov 2009 15:04:16 -0800 Subject: [arin-ppml] Policy Proposal 102: Reduce and Simplify IPv4 Initial Allocations In-Reply-To: <4AF9ECA5.6080405@rollernet.us> References: <4AF31D95.9050605@arin.net> <3c3e3fca0911060634u4a5b11c1g7fc3371d0158c2ae@mail.gmail.com> <4AF48DF7.2030207@ipinc.net> <3c3e3fca0911061729v63b896a6hff2c27e947f4b4cd@mail.gmail.com> <4AF86C51.1040804@ipinc.net> <3c3e3fca0911091151i13a97eccge254c54cf5dc715@mail.gmail.com> <4AF88019.8010309@ipinc.net> <3c3e3fca0911091323q11ccf53du3151dfebf3a1eb91@mail.gmail.com> <4AF88918.7080604@rollernet.us> <4AF8A25C.9060603@ipinc.net> <4AF8B1A5.1010602@rollernet.us> <4AF8C02B.9000502@ipinc.net> <4AF8CF83.4020807@rollernet.us> <4AF9E1FE.8020409@ipinc.net> <4AF9ECA5.6080405@rollernet.us> Message-ID: On Nov 10, 2009, at 2:43 PM, Seth Mattinen wrote: > Ted Mittelstaedt wrote: >> Seth Mattinen wrote: >>> >>> Having recently has a glimpse into the world snowshoe I have a >>> different >>> view. There is so much space being "rented" right now it's not even >>> funny. A huge amount of it sits around idle so it will "clean up". >>> I can >>> get multiple /18's and up with a phone call and enough money. We >>> don't >>> have to wait for runout, these guys will be ready and willing to >>> sell >>> addresses to a brand new market when the time comes. >>> >> If your right and the hoarders flood the market with IPv4 once the >> RIR's >> run out, then so be it - I guarantee that if what they do causes a >> problem, the ARIN community will shut it down. That's the problem >> with designing a business plan around hoarding - it's going to >> be tolerated only as long as you don't make a nuisance of yourself. > > That's the fun thing I learned. They're borrowing space from people > who have a surplus for a fee. Normally this surplus should be > returned to ARIN especially since we're all panicky about IPv4 > runout, right? Wrong. > > This is a bit OT, but here's what I know. Mr. W needs some address > space at his colo. He can't qualify via the colo's rules or ARIN's. > Mr. X calls himself an IP broker. All he does is arrange people that > have spare IP space with people who need some IP space for whatever > reason. Let's say me the ISP has an /18 that's unused. Mr. X will > give me $Y to borrow that /18 for Z amount of time. He will turn > around and tell Mr. W that he can advertise that /18 at his colo for > $Y+markup. One of my friends who does consulting somehow got > involved with Mr. X and started to see dollar signs. It took me > several weeks of being totally confused to get behind the curtain > and tell everyone I wasn't interested in letting other people > reannounce my space outside of my AS. > > Wasn't there a policy to encourage return of resources? I don't > remember. ARIN would have to find these orgs who are renting their > space out to brokers and revoke it somehow to put a stop to it. > I strongly encourage ANYONE who encounters such an arrangement to report it to ARIN. Organizations who are leasing their space in this manner could well be subject to a review under section 12 of the NRPM. ARIN can't resolve what it does not know about. This should be done through: https://www.arin.net/resources/fraud/ By submitting a report at: https://www.arin.net/public/fraud/index.xhtml Be as specific as possible, and, try to identify the organization and the IP addresses in question. Owen From scottleibrand at gmail.com Tue Nov 10 18:27:20 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 10 Nov 2009 15:27:20 -0800 Subject: [arin-ppml] Policy Proposal 102: Reduce and Simplify IPv4 Initial Allocations In-Reply-To: References: <4AF31D95.9050605@arin.net> <3c3e3fca0911060634u4a5b11c1g7fc3371d0158c2ae@mail.gmail.com> <4AF48DF7.2030207@ipinc.net> <3c3e3fca0911061729v63b896a6hff2c27e947f4b4cd@mail.gmail.com> <4AF86C51.1040804@ipinc.net> <3c3e3fca0911091151i13a97eccge254c54cf5dc715@mail.gmail.com> <4AF88019.8010309@ipinc.net> <3c3e3fca0911091323q11ccf53du3151dfebf3a1eb91@mail.gmail.com> <4AF88918.7080604@rollernet.us> <4AF8A25C.9060603@ipinc.net> <4AF8B1A5.1010602@rollernet.us> <4AF8C02B.9000502@ipinc.net> <4AF8CF83.4020807@rollernet.us> <4AF9E1FE.8020409@ipinc.net> <4AF9ECA5.6080405@rollernet.us> Message-ID: <4AF9F6D8.6040409@gmail.com> Owen DeLong wrote: > > On Nov 10, 2009, at 2:43 PM, Seth Mattinen wrote: > >> >> This is a bit OT, but here's what I know. Mr. W needs some address >> space at his colo. He can't qualify via the colo's rules or ARIN's. >> Mr. X calls himself an IP broker. All he does is arrange people that >> have spare IP space with people who need some IP space for whatever >> reason. Let's say me the ISP has an /18 that's unused. Mr. X will >> give me $Y to borrow that /18 for Z amount of time. He will turn >> around and tell Mr. W that he can advertise that /18 at his colo for >> $Y+markup. One of my friends who does consulting somehow got involved >> with Mr. X and started to see dollar signs. It took me several weeks >> of being totally confused to get behind the curtain and tell everyone >> I wasn't interested in letting other people reannounce my space >> outside of my AS. >> >> Wasn't there a policy to encourage return of resources? I don't >> remember. ARIN would have to find these orgs who are renting their >> space out to brokers and revoke it somehow to put a stop to it. >> > I strongly encourage ANYONE who encounters such an arrangement to report > it to ARIN. Organizations who are leasing their space in this manner > could > well be subject to a review under section 12 of the NRPM. > > ARIN can't resolve what it does not know about. > > This should be done through: > > https://www.arin.net/resources/fraud/ > > By submitting a report at: > > https://www.arin.net/public/fraud/index.xhtml > > Be as specific as possible, and, try to identify the organization and > the IP addresses in question. > If you have evidence of fraud, then by all means report it. But keep in mind that if the organization getting the space from ARIN is an LIR, then this may well be a legitimate use of the space. -Scott From sethm at rollernet.us Tue Nov 10 19:42:24 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 10 Nov 2009 16:42:24 -0800 Subject: [arin-ppml] Alternate ways to get IPv4 (Re: Policy Proposal 102: Reduce and Simplify IPv4 Initial Allocations) Message-ID: <4AFA0870.4070104@rollernet.us> Ted Mittelstaedt wrote: > Seth Mattinen wrote: >> I don't remember. ARIN would have to find these orgs who are renting >> their space out to brokers and revoke it somehow to put a stop to it. >> > > No reason to. ARIN charges org X with the spare space a fee, org X > charges org Y who needs space, a fee. The main thing is that the IP > addressing is in use. All Org's X responsibility to ARIN is that they > keep it utilized and maintain the SWIPS on it. > > Those people aren't the problem. The problem are the orgs getting > the space then doing nothing with it. > I thought we weren't supposed to bypass ARIN to obtain IP addresses? i.e. I can't qualify for an /18 via ARIN and probably not my upstreams without lying, but I can via these guys because they don't care about utilization plans. ~Seth From sethm at rollernet.us Tue Nov 10 19:44:51 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 10 Nov 2009 16:44:51 -0800 Subject: [arin-ppml] Policy Proposal 102: Reduce and Simplify IPv4 Initial Allocations In-Reply-To: <443de7ad0911101501g6edecc35o3ce052ea8855e8fd@mail.gmail.com> References: <4AF31D95.9050605@arin.net> <4AF88019.8010309@ipinc.net> <3c3e3fca0911091323q11ccf53du3151dfebf3a1eb91@mail.gmail.com> <4AF88918.7080604@rollernet.us> <4AF8A25C.9060603@ipinc.net> <4AF8B1A5.1010602@rollernet.us> <4AF8C02B.9000502@ipinc.net> <4AF8CF83.4020807@rollernet.us> <4AF9E1FE.8020409@ipinc.net> <4AF9ECA5.6080405@rollernet.us> <443de7ad0911101501g6edecc35o3ce052ea8855e8fd@mail.gmail.com> Message-ID: <4AFA0903.9070309@rollernet.us> Chris Grundemann wrote: > > Do you still not see this policy as an answer to that problem? Is > getting portable space that you may have to renumber out of worse than > being at the whim of your upstream provider? > I suppose it's reasonable to assume that one could mix and match if you didn't want to renumber or just do it on your own terms, so I would support that. ~Seth From scottleibrand at gmail.com Tue Nov 10 19:54:57 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 10 Nov 2009 16:54:57 -0800 Subject: [arin-ppml] Alternate ways to get IPv4 (Re: Policy Proposal 102: Reduce and Simplify IPv4 Initial Allocations) In-Reply-To: <4AFA0870.4070104@rollernet.us> References: <4AFA0870.4070104@rollernet.us> Message-ID: <4AFA0B61.40608@gmail.com> Seth Mattinen wrote: > Ted Mittelstaedt wrote: > > Seth Mattinen wrote: > >> I don't remember. ARIN would have to find these orgs who are renting > >> their space out to brokers and revoke it somehow to put a stop to it. > >> > > > > No reason to. ARIN charges org X with the spare space a fee, org X > > charges org Y who needs space, a fee. The main thing is that the IP > > addressing is in use. All Org's X responsibility to ARIN is that they > > keep it utilized and maintain the SWIPS on it. > > > > Those people aren't the problem. The problem are the orgs getting > > the space then doing nothing with it. > > > > I thought we weren't supposed to bypass ARIN to obtain IP addresses? > i.e. I can't qualify for an /18 via ARIN and probably not my upstreams > without lying, but I can via these guys because they don't care about > utilization plans. The problem there is not that you're getting IPs from org X, it's that you're doing so while ignoring ARIN policy regarding reassignment of space to downstreams. If org X gives out space on a justified basis, they can do so all they want. It's when they (or an ISP, or any other LIR) decide that they don't care about utilization plans that we have a violation of ARIN policy. -Scott From tedm at ipinc.net Tue Nov 10 22:38:01 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 10 Nov 2009 19:38:01 -0800 Subject: [arin-ppml] Alternate ways to get IPv4 (Re: Policy Proposal 102: Reduce and Simplify IPv4 Initial Allocations) In-Reply-To: <4AFA0B61.40608@gmail.com> References: <4AFA0870.4070104@rollernet.us> <4AFA0B61.40608@gmail.com> Message-ID: <4AFA3199.7090208@ipinc.net> Scott Leibrand wrote: > Seth Mattinen wrote: >> Ted Mittelstaedt wrote: >> > Seth Mattinen wrote: >> >> I don't remember. ARIN would have to find these orgs who are renting >> >> their space out to brokers and revoke it somehow to put a stop to it. >> >> >> > >> > No reason to. ARIN charges org X with the spare space a fee, org X >> > charges org Y who needs space, a fee. The main thing is that the IP >> > addressing is in use. All Org's X responsibility to ARIN is that they >> > keep it utilized and maintain the SWIPS on it. >> > >> > Those people aren't the problem. The problem are the orgs getting >> > the space then doing nothing with it. >> > >> >> I thought we weren't supposed to bypass ARIN to obtain IP addresses? >> i.e. I can't qualify for an /18 via ARIN and probably not my upstreams >> without lying, but I can via these guys because they don't care about >> utilization plans. > > The problem there is not that you're getting IPs from org X, it's that > you're doing so while ignoring ARIN policy regarding reassignment of > space to downstreams. Technically, org X is ignoring the policy by not doing due diligence, org X should assume as a matter of course that potential "renters" or customers will be ignorant of the ARIN requirements. > If org X gives out space on a justified basis, > they can do so all they want. It's when they (or an ISP, or any other > LIR) decide that they don't care about utilization plans that we have a > violation of ARIN policy. > Exactly. Furthermore, for anything larger than a /19, section 4.2.3.5 applies and ARIN must approve it, thus if the downstream is falsifying info, that's a falsification of data to ARIN, (in addition to the assigning ISP) and I would hope that ARIN would hold the assigning ISP's feet to the fire, since it would almost certainly take collusion between the assigning ISP and it's customer on falsified data for an assignment of that size. Ted From sethm at rollernet.us Tue Nov 10 22:50:04 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 10 Nov 2009 19:50:04 -0800 Subject: [arin-ppml] Alternate ways to get IPv4 (Re: Policy Proposal 102: Reduce and Simplify IPv4 Initial Allocations) In-Reply-To: <4AFA3199.7090208@ipinc.net> References: <4AFA0870.4070104@rollernet.us> <4AFA0B61.40608@gmail.com> <4AFA3199.7090208@ipinc.net> Message-ID: <4AFA346C.3050708@rollernet.us> Ted Mittelstaedt wrote: > > Technically, org X is ignoring the policy by not doing due diligence, > org X should assume as a matter of course that potential "renters" or > customers will be ignorant of the ARIN requirements. > They were all very aware of ARIN requirements - the entire goal was to get around them via the broker. Like I said, not something I wanted to be a part of. ~Seth From rudi.daniel at gmail.com Wed Nov 11 19:55:45 2009 From: rudi.daniel at gmail.com (RudOlph Daniel) Date: Wed, 11 Nov 2009 19:55:45 -0500 Subject: [arin-ppml] ARIN-PPML Digest, Vol 53, Issue 16 In-Reply-To: References: Message-ID: <8aeeaff60911111655k462591ebwd1a0ffda89606ff1@mail.gmail.com> The first ICANN meet I went to was in San Juan. One evening I sat at the bar of the hotel over a glass of wine collecting my thoughts about the day's proceedings when up walks a man with blond hair who introduces himself to me.In the conversation that resulted he turned out to be someone who had been around ICANN from its inception. To cut a long story short, he offered me a little advice about the business of the Internet, but what what was particularity significant in his remarks was this: "When there is money on the table, *all* the rules change." Arin arguably has the most unused v4 space under the "return policy" and knowledge of that would seem to already have created a market ( IMO ) acting against widespread adoption of v6. The Caribbean is a small outpost of ARIN and we are, I would suggest, way behind with regards to understanding the real challenges of run out and transition to v6. What I am suggesting here is that the network and its policies is not yet mature/homogeneous enough to provide a safety net for developing economies like the Caribbean in the face of the majority of this RIR with its far superior knowledge and experience, but yet not able to foresee the future black market shenanigans of a creative first world business professional class leveraging the scarcity value of a resource for considerable profit. The possible result is that we, who can scarcely afford it, will end up paying through our noses with high connectivity charges and never realizing the potential so eloquently promised... "ICT 4 development" Policy ok, but lets be realistic, implementation includes policing and providing the right incentives to drive that policy home to the community in the interests of ALL the community. I am beginning to think that the Caribbean portion of ARIN is so far removed from what exists in North America and Canada that we should petition for a sub regional RIR. Food for thought. Rudi Daniel > > Wasn't there a policy to encourage return of resources? I don't > > remember. ARIN would have to find these orgs who are renting their > > space out to brokers and revoke it somehow to put a stop to it. > > > I strongly encourage ANYONE who encounters such an arrangement to report > it to ARIN. Organizations who are leasing their space in this manner > could > well be subject to a review under section 12 of the NRPM. > > ARIN can't resolve what it does not know about. > > This should be done through: > > https://www.arin.net/resources/fraud/ > > By submitting a report at: > > https://www.arin.net/public/fraud/index.xhtml > > Be as specific as possible, and, try to identify the organization and > the IP addresses in question. > > Owen > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mueller at syr.edu Thu Nov 12 13:54:01 2009 From: mueller at syr.edu (Milton L Mueller) Date: Thu, 12 Nov 2009 13:54:01 -0500 Subject: [arin-ppml] Policy Proposal 102: Reduce and Simplify IPv4 Initial Allocations In-Reply-To: <4AF9ECA5.6080405@rollernet.us> References: <4AF31D95.9050605@arin.net> <3c3e3fca0911060634u4a5b11c1g7fc3371d0158c2ae@mail.gmail.com> <4AF48DF7.2030207@ipinc.net> <3c3e3fca0911061729v63b896a6hff2c27e947f4b4cd@mail.gmail.com> <4AF86C51.1040804@ipinc.net> <3c3e3fca0911091151i13a97eccge254c54cf5dc715@mail.gmail.com> <4AF88019.8010309@ipinc.net> <3c3e3fca0911091323q11ccf53du3151dfebf3a1eb91@mail.gmail.com> <4AF88918.7080604@rollernet.us> <4AF8A25C.9060603@ipinc.net> <4AF8B1A5.1010602@rollernet.us> <4AF8C02B.9000502@ipinc.net> <4AF8CF83.4020807@rollernet.us> <4AF9E1FE.8020409@ipinc.net> <4AF9ECA5.6080405@rollernet.us> Message-ID: <75822E125BCB994F8446858C4B19F0D790FD1767@SUEX07-MBX-04.ad.syr.edu> > -----Original Message----- > Mr. W needs some address space > at his colo. He can't qualify via the colo's rules or ARIN's. Interesting that in this thread, no one has interrogated this disjunction. Mr. W thinks he "needs" address space but ARIN and the colo don't. Isn't it worth considering for just a few moments what causes that gap in perception/definition of "need"? And if that gap is wide and persistent across many situations and actors or a few isolated instances? Also, how much thought has gone into justification and evidence for the proposition that applying ARIN's (apparently more restrictive and less contextual) definition of need serves the industry better than the brokerage arrangement? --MM From jcurran at arin.net Fri Nov 13 04:07:51 2009 From: jcurran at arin.net (John Curran) Date: Fri, 13 Nov 2009 04:07:51 -0500 Subject: [arin-ppml] Safety net for developing economies... In-Reply-To: <8aeeaff60911111655k462591ebwd1a0ffda89606ff1@mail.gmail.com> References: <8aeeaff60911111655k462591ebwd1a0ffda89606ff1@mail.gmail.com> Message-ID: <5A08D828-3C81-49FF-BF54-36311E848F8B@arin.net> On Nov 12, 2009, at 2:55 AM, RudOlph Daniel wrote: > ... > What I am suggesting here is that the network and its policies is not yet mature/homogeneous enough to provide a safety net for developing economies like the Caribbean in the face of the majority of this RIR with its far superior knowledge and experience, but yet not able to foresee the future black market shenanigans of a creative first world business professional class leveraging the scarcity value of a resource for considerable profit. Rudi - How should ARIN provide a safety net for developing economies in this region? To the extent that you have a suggestion, this is definitely the right place to discuss it. /John John Curran President and CEO ARIN From rudi.daniel at gmail.com Fri Nov 13 10:26:48 2009 From: rudi.daniel at gmail.com (RudOlph Daniel) Date: Fri, 13 Nov 2009 10:26:48 -0500 Subject: [arin-ppml] Safety net for developing economies... In-Reply-To: <5A08D828-3C81-49FF-BF54-36311E848F8B@arin.net> References: <8aeeaff60911111655k462591ebwd1a0ffda89606ff1@mail.gmail.com> <5A08D828-3C81-49FF-BF54-36311E848F8B@arin.net> Message-ID: <8aeeaff60911130726uf5e10e6md172007f2dfefcdb@mail.gmail.com> This goes right to the heart of v4/v6 transistion. If we accept what Jeff Houston at APNIC reported : that only 40 % of legacy space is routed and that 3.6 % of allocated addresses are actually occupied by visible hosts, then it is perhaps worth speculating that there are out there, market makers who are laying the foundation to profit from "runout". The ideology of stewardship of a common pool, whilst displaying good economic and social properties, does not prevent hoarding by one party thereby restricting use by another party. Remember that allocation is based on case by case demonstration of need. Such a procedure is more akin to your central city planning function and therefore relies heavily on the accuracy of the information or should I say the symmetry of information between the requestor and the registry. So when you get the kind of market conditions suggested by Houston, it become a major challenge to the case by case administration process. In other words, your staff begin to complain of headaches :) Because of the legacy space situation, ARIN's policies have more impact than any other RIR. So it can also be argued that how legacy space is managed at "runout" directly affects not only the timely adoption of v6, but also Internet development and capacity building in the RIRs region. ARIN as a region possibly has the widest digital divide of the RIRs: contrasting, the USA, Canada, and the 22 small Caribbean states. Supposing we accept the existence of a v4 runout market, good stewardship of the resource should therefore prevent application and innovation in developing markets from becoming too expensive due to scarcity value of the resource. Arin already provides support for developing countries in its region so it is not so difficult to develop policy to use those portions of its region seeking internet development and capacity building to promote v6 adoption in a myriad of practical ways, since it not only address the digital divide but also brings them up to speed in the face of market challenges. Did someone propose IPv6 in a box at a public meeting? The runout market makers are also going to be challenged by new fledging v6 networks which in themselves are going to act as a test bed for a host of network technical issues which currently confront easy adoption of v6. It also provides an opportunity to close the digital divide by providing subsidies at the bottom where the rate of return is far greater in the medium to long term than fighting a protracted war with deeply entrenched IP racketeers. There is also another perspective here, The ARINCaribbean is not unlike Africa, in that it has a very high penetration of Mobile; and so quick adoption of v6 is probably beneficial to economic growth in the region especially since the global economic downturn. But v6 adoption requires good planning, investment and collaboration: All of these are in short supply where the digital divide is a wide one. Even without a v4 runout headache, there are still big challenges confronting broadband access in rural areas and low income populations and it is interesting to note (from an opinion expressed to me) that these challenges are probably greater than those for the voice telephony of old. Rudi Daniel On Fri, Nov 13, 2009 at 4:07 AM, John Curran wrote: > On Nov 12, 2009, at 2:55 AM, RudOlph Daniel wrote: > > ... > > What I am suggesting here is that the network and its policies is not yet > mature/homogeneous enough to provide a safety net for developing economies > like the Caribbean in the face of the majority of this RIR with its far > superior knowledge and experience, but yet not able to foresee the future > black market shenanigans of a creative first world business professional > class leveraging the scarcity value of a resource for considerable profit. > > Rudi - > > How should ARIN provide a safety net for developing economies in this > region? To the extent that you have a suggestion, this is definitely the > right place to discuss it. > > /John > > John Curran > President and CEO > ARIN > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tedm at ipinc.net Fri Nov 13 20:49:53 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 13 Nov 2009 17:49:53 -0800 Subject: [arin-ppml] Safety net for developing economies... In-Reply-To: <8aeeaff60911130726uf5e10e6md172007f2dfefcdb@mail.gmail.com> References: <8aeeaff60911111655k462591ebwd1a0ffda89606ff1@mail.gmail.com> <5A08D828-3C81-49FF-BF54-36311E848F8B@arin.net> <8aeeaff60911130726uf5e10e6md172007f2dfefcdb@mail.gmail.com> Message-ID: <4AFE0CC1.5090305@ipinc.net> RudOlph Daniel wrote: > This goes right to the heart of v4/v6 transistion. > If we accept what Jeff Houston at APNIC reported : that only 40 % of > legacy space is routed and that 3.6 % of allocated addresses are > actually occupied by visible hosts, then it is perhaps worth speculating > that there are out there, market makers who are laying the foundation to > profit from "runout". > I'm sure there are. > The ideology of stewardship of a common pool, whilst displaying good > economic and social properties, does not prevent hoarding by one party > thereby restricting use by another party. > Correct. > Remember that allocation is based on case by case demonstration of need. > Such a procedure is more akin to your central city planning function and > therefore relies heavily on the accuracy of the information or should I > say the symmetry of information between the requestor and the registry. > So when you get the kind of market conditions suggested by Houston, it > become a major challenge to the case by case administration process. In > other words, your staff begin to complain of headaches :) > > Because of the legacy space situation, ARIN's policies have more impact > than any other RIR. > So it can also be argued that how legacy space is managed at "runout" > directly affects not only the timely adoption of v6, but also Internet > development and capacity building in the RIRs region. > You can make that argument regardless of whether ARIN's policies have more impact than any other RIR, ARIN is not unique in having some unused space in it's IPv4 allocations. But, go on, > ARIN as a region possibly has the widest digital divide of the RIRs: > contrasting, the USA, Canada, and the 22 small Caribbean states. > > Supposing we accept the existence of a v4 runout market, good > stewardship of the resource should therefore prevent application and > innovation in developing markets from becoming too expensive due to > scarcity value of the resource. > > Arin already provides support for developing countries in its region so > it is not so difficult to develop policy to use those portions of its > region seeking internet development and capacity building to promote v6 > adoption in a myriad of practical ways, since it not only address the > digital divide but also brings them up to speed in the face of market > challenges. Did someone propose IPv6 in a box at a public meeting? > Are you advocating that ARIN offer developing countries in it's region IPv4 resources in exchange for deploying IPv6? > The runout market makers are also going to be challenged by new fledging > v6 networks which in themselves are going to act as a test bed for a > host of network technical issues which currently confront easy adoption > of v6. It also provides an opportunity to close the digital divide by > providing subsidies at the bottom where the rate of return is far > greater in the medium to long term than fighting a protracted war with > deeply entrenched IP racketeers. > Is this advocating ARIN make payments to orgs who don't have any IP deployed because then they will build out IPv6, instead of trying to build out IPv4? > There is also another perspective here, The ARINCaribbean is not unlike > Africa, in that it has a very high penetration of Mobile; and so quick > adoption of v6 is probably beneficial to economic growth in the region > especially since the global economic downturn. But v6 adoption requires > good planning, investment and collaboration: All of these are in short > supply where the digital divide is a wide one. Are you saying good IPv6 planning, investment and collaboration is in short supply in the ARIN region? > Even without a v4 runout headache, there are still big challenges > confronting broadband access in rural areas and low income populations > and it is interesting to note (from an opinion expressed to me) that > these challenges are probably greater than those for the voice telephony > of old. > I think there's a lot of implications here your making. I happen to agree with some of them, but I think that the problem isn't solvable in the way I think your implying. Here is my $0.02 on why; With the old POTS telephoney the biggest challenge was running a pair of copper wires for miles. Out in the sticks you had the freedom of running a 10 mile copper pair subscriber line stuck to barbed wire cow pasture fences, with the appropriate load coils in it. You could cover very large distances with a very DUMB network, where all the expensive intelligence is located in a single CO. This gives huge savings when you can do this. With any kind of higher speed broadband, you have to run DSL, or cable TV cable, or fiber - all of which require repeaters, which require power, and maintainence, and so on and so on. These push the intelligence out into the field, out into the network. The model of a single large central office with concentrated intelligence and a dumb network doesn't hold. Instead, a new model of distributed intelligence is used. And, such a model is much more expensive, much more labor intensive, than the old concentrated intelligence model. Thus, with the old model you could afford to subsidize the rural and low income populations. You could strategically place the CO's on the edge of the low income regions, so that the CO served a mix of low income and high income areas, and thus, you would essentially subsidize the low income areas. Because serving the low income areas was so cheap (since the network cost practically nothing) and you had to have the CO there serving the high-income areas anyway, there was little objection. In the new model, since every region that the network is in has to be funded, it is very easy for the high-income but unschooled-in-networking types to understand that when you were sending expensive intelligence into low-income regions, that they were funding these areas. And, the costs are far far higher than the old model. So naturally, they objected to this. This is why the digital divide exists at all. To put it simply, it costs a lot more money to hand out free Internet access than to hand out free voice access, and Internet access is not a health-and-safety issue, the way that 911-emergency access is on voice. So, you cannot use moral persuasion to convince the high-income types that they must fund Internet Access for the have-nots, and since doing this funding is so expensive, there is no way to slip in these subsidies under the table without the high-income types figuring it out. And more importantly, since Internet Access is so new (it's only been around for 15 years for the masses, after all) the societal structures to prevent undesirable behavior on it (such as piracy, child exploitation, etc.) do not yet exist and are still being figured out - as a result we have a LOT of objectionable behavior on the Internet, behavior PARTICULARLY objectionable to someone subsidizing Internet access for one of the not-haves. To put it succinctly, why should the rich subsidize a have-not's porno surfing Playboy and watching episodes of Lost off hulu? This is why, IMHO, the digital divide isn't currently a solvable problem. In voice service today, we can provide a voice line that will ONLY take 911 calls, to someone who is so dirt poor that they cannot even afford an extra $10 a month for a POTS line. The societal structures exist to do this and get the have's to pay for it, and the haves mostly agree that there's a moral imperative for them to do this. But, in Internet service today it's an all-or-nothing proposition. We cannot provide an Internet connection that will ONLY allow the have-nots to access educational stuff, or job-hunting stuff, or other pull-yourself-up-by-the-bootstraps stuff that the haves would all agree that there's a moral imperative to supply to the have-nots. Instead, if we supply it, they get everything, including the stuff that they shouldn't be wasting their time on. One of the biggest objections I hear about the food stamp program in the United States comes from when "the poor" who are on food stamps walk though the grocery store checkout line, carrying food and beer - and pay cash for the beer and cigarettes, and food stamps for the food. This gives the impression that taxpayer dollars are funding alcohol and smoking, and turns every taxpayer who sees this happening in the grocery store against the food stamp program. So much so, in fact, that many states have gone to a credit card system, that is unobtrusive, so that "the poor" who are using this can get through the checkout line without anyone realizing they are using public assistance. Ostensibly this is to protect the privacy of the poor, but it also helps to reduce public outrage at the perceived abuse of the program, which is almost certainly the main reason the politicians went for it. I suspect that if there would ever be a serious movement (at least in the United States) to make the same claim that Internet Access was on par with voiceline access as a moral imperative for the have-nots, that the outrage over public subsidies to the have-nots for using publically-paid Internet service to access playboy.com would make the complaints about the food stamp program look like a match next to a forest fire. The digital divide isn't going to be solvable until the Internet is cleaned up, and the worthless content (ie: all the sex stuff) is behind lock and key, and the next-to-worthless stuff (ie: the episodes of Lost on hulu.com) is behind a door that can be closed if needed. The day you can allow your 10-year-old kid onto the Internet, unsupervised, is the day the digital divide CAN be closed. Until then, Internet Service is electronic beer and cigarettes, and the poor are gonna have to pay cash. Just my $0.02 Ted > Rudi Daniel > > > > On Fri, Nov 13, 2009 at 4:07 AM, John Curran > wrote: > > On Nov 12, 2009, at 2:55 AM, RudOlph Daniel wrote: > > ... > > What I am suggesting here is that the network and its policies is > not yet mature/homogeneous enough to provide a safety net for > developing economies like the Caribbean in the face of the majority > of this RIR with its far superior knowledge and experience, but yet > not able to foresee the future black market shenanigans of a > creative first world business professional class leveraging the > scarcity value of a resource for considerable profit. > > Rudi - > > How should ARIN provide a safety net for developing economies in > this region? To the extent that you have a suggestion, this is > definitely the right place to discuss it. > > /John > > John Curran > President and CEO > ARIN > > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From tedm at ipinc.net Fri Nov 13 21:03:42 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 13 Nov 2009 18:03:42 -0800 Subject: [arin-ppml] Policy Proposal 102: Reduce and Simplify IPv4 Initial Allocations In-Reply-To: <75822E125BCB994F8446858C4B19F0D790FD1767@SUEX07-MBX-04.ad.syr.edu> References: <4AF31D95.9050605@arin.net> <3c3e3fca0911060634u4a5b11c1g7fc3371d0158c2ae@mail.gmail.com> <4AF48DF7.2030207@ipinc.net> <3c3e3fca0911061729v63b896a6hff2c27e947f4b4cd@mail.gmail.com> <4AF86C51.1040804@ipinc.net> <3c3e3fca0911091151i13a97eccge254c54cf5dc715@mail.gmail.com> <4AF88019.8010309@ipinc.net> <3c3e3fca0911091323q11ccf53du3151dfebf3a1eb91@mail.gmail.com> <4AF88918.7080604@rollernet.us> <4AF8A25C.9060603@ipinc.net> <4AF8B1A5.1010602@rollernet.us> <4AF8C02B.9000502@ipinc.net> <4AF8CF83.4020807@rollernet.us> <4AF9E1FE.8020409@ipinc.net> <4AF9ECA5.6080405@rollernet.us> <75822E125BCB994F8446858C4B19F0D790FD1767@SUEX07-MBX-04.ad.syr.edu> Message-ID: <4AFE0FFE.7090304@ipinc.net> Milton L Mueller wrote: > >> -----Original Message----- Mr. W needs some address space at his >> colo. He can't qualify via the colo's rules or ARIN's. > > Interesting that in this thread, no one has interrogated this > disjunction. Mr. W thinks he "needs" address space but ARIN and the > colo don't. Isn't it worth considering for just a few moments what > causes that gap in perception/definition of "need"? And if that gap > is wide and persistent across many situations and actors or a few > isolated instances? > They probably haven't brought it up because they didn't think it was germane to the proposal. I am not, however, saying that I have an opinion one way or another about that. > Also, how much thought has gone into justification and evidence for > the proposition that applying ARIN's (apparently more restrictive and > less contextual) definition of need serves the industry better than > the brokerage arrangement? > Keep in mind that this policy proposal, and a good deal of the NRPM that deals with IPv4, may have little practical value after IPv4 runout. I think we will probably be rewriting those sections for quite a while. Plenty of time to argue about which way of handling IPv4 allocations is better. Also, if the goal is to prolong IPv4 and create organizations that will actively spend money in opposition to rolling out IPv6 more rapidly, then promoting IPv4 brokerages is a superb way to accomplish that. Never forget that brokerages are ONLY viable as long as IPv4 is. Ted > --MM > > _______________________________________________ PPML You are > receiving this message because you are subscribed to the ARIN Public > Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your > mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml Please contact > info at arin.net if you experience any issues. From steve at ibctech.ca Fri Nov 13 23:20:24 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Fri, 13 Nov 2009 23:20:24 -0500 Subject: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process In-Reply-To: <4AF86E15.2060307@arin.net> References: <4AF86E15.2060307@arin.net> Message-ID: <4AFE3008.3000904@ibctech.ca> Member Services wrote: > Policy Proposal 103: Change IPv6 Allocation Process I'm very, very interested in this proposal, and would like to give it a bump in hopes that it will spur more feedback and discussion than what it's received thus far. Truthfully, I would like to get a feel on the number of people who like it (I certainly do). If anyone has disregarded or overlooked the proposal because of the recommended financial figures, please let that be known as well. Complete original proposal message has been left intact below. Steve > Proposal Originator: William Herrin > > Proposal Version: 1.0 > > Date: 9 November 2009 > > Proposal type: new > > Policy term: permanent. > > Policy statement: > > Strike NRPM sections: 6.2.3, 6.2.4, 6.2.6-6.2.9, 6.4.3, 6.4.4, > 6.5.1-6.5.5, 6.5.8, 6.7, 6.10 > > Strike NRPM section 6.9 paragraph 2. > > Replace 6.2.5 as follows: > > 6.2.5 Allocate and Assign > > For the purposes of NRPM section 6, allocate and assign are > synonymous. Both terms describe any or all use identified in section > 2.5. > > Replace 6.5.7 with: > > 6.5.7. Existing IPv6 address space holders > > Organizations that received IPv6 allocations under the previous IPv6 > address policy are entitled to either retain those allocations as is > or trade them in for an allocation under 6.5.9. > > Add NRPM section 6.5.9 as follows: > > 6.5.9 IPv6 Allocations > > 6.5.9.1 ARIN shall allocate IPv6 address blocks in exactly and only > the following denominations: /56, /48, /40, /32, /24 > > 6.5.9.2 No utilization-based eligibility requirements shall apply to > IPv6 allocations. > > 6.5.9.3 ARIN shall accept registration of no more than one address > block of each size for any single organization. > > 6.5.9.4 ARIN shall allocate IPv6 addresses from pools such that the > identity of the allocation pool serves to classify the expected size > of allocations within. ISPs may use that classification to filter or > otherwise manage their routing tables. > > 6.5.9.5 For each allocation size, ARIN shall further manage the > allocation pools such that the pool identity serves to classify > whether or not the registrant is Multihomed. > > 6.5.9.6 ARIN shall offer addresses from pools classified as multihomed > only to organizations which ARIN has verified are multihomed on the > public Internet per NRPM 2.7. > > 6.5.9.7 Where an organization ceases to be Multihomed it shall > surrender all address allocations from within pools classified as > multihomed within 3 months. > > > Rationale: > > See the implementation notes section below for what should replace > utilization-based eligibility. > > The existing IPv6 allocation policy under section 6.5 makes a number > of unproven assumptions about how IPv6 allocations will work. > > Unproven: we can make a reasonable guess about how many IPv6 subnets > an organization will need at the outset when they first request IP > addresses. When in all of human history has this ever proven true of > any resource? > > Unproven: with sparse allocation, we can allow organizations to expand > by just changing their subnet mask so that they don't have to announce > additional routes into the DFZ. This claim is questionable. With > sparse allocation, we either consume much larger blocks that what we > assign (so why not just assign the larger block?) or else we don't > consume them in which case the org either has to renumber to expand or > he has to announce a second route. Worse, because routes of various > sizes are all scattered inside the same address space, its impractical > to filter out the traffic engineering routes. > > Unproven: we can force organizations not to disaggregate for traffic > engineering purposes. Neither any of our experience with IPv4 nor any > of the research in the IRTF Routing Research Group suggests that this > is even remotely practical so long as BGP or any similar system rules > the roost. > > Unproven: all non-ISPs can be reasonably expected to get their address > space from ISPs instead of from ARIN. We can certainly operate that > way, but it could prove deadly to the routing table. Any organization > multihomed between two ISPs will need to announce that route via BGP, > regardless of where they get the address space from. We have knobs and > dials in the routers that let us easily filter disaggregates from > distant announcements, but we don't dare do so if there is a > possibility that one of those disaggregates is a multihomed customer > rather than traffic engineering. > > Benefits of this proposal: > > A. Efficient allocation of IP addresses. Orgs get what they need when > they need it without a great deal of guesswork. > > B. Efficient utilization of BGP routing slots. No multihomed orgs will > announce more than five unfilterable routes, and that only if they're > so large that they can afford the price tag for the biggest address > blocks. That's a good thing since IPv6 routes that propagate worldwide > may impose an annual systemic overhead cost on ISPs of as much as US > $16,000 each. > > C. Traffic engineering routes are trivially filterable. Any route > longer than the published allocation size can be presumed to be > traffic engineering, not a downstream multihomed customer, thus you > can filter distant small routes with confidence and ease. > > D. Fair. No need to define the difference between ISP and not ISP. > Everybody plays by the same rules. > > E. No complicated analysis for allocation. You pay for what you want > and get what you pay for. You're either multihomed or you're not. > > F. Gets ARIN out of the business of being the gatekeeper for Internet > routing policy. By classifying allocations instead of making > eligibility decisions, ARIN empowers the ISPs to set appropriate > routing eligibility policies instead. > > FAQ > Q. Isn't this classfull addressing all over again? > A. Yes. > Classful addressing had a lot of virtues with respect to route > filtering and management. We had to abandon it because there weren't > enough B's for everyone who needed more than one C and there weren't > enough A's period. With IPv6, we don't have that problem. Not yet and > maybe not ever. Perhaps we can have our cake and eat it too. > > Q. What if I don't want to accept /56 routes for single-homed users? > > A. This policy proposal intentionally and fully places backbone > routing policy in the hands of the ISPs who operate the Internet's > "Default-Free Zone (DFZ)," colloquially known as the Internet > backbone. The author expects that some of the allocations, especially > some of the single-homed allocations, *will not* be routable on the > public Internet. When we hold a general expectation that all of ARIN's > allocations will be routable, we effectively mean that ARIN decides > what the Internet routing policy will be. That's precisely the role > this proposal removes from ARIN's hands and restores to the ISPs. > > Q. Spell it out for me. How exactly will pools and size > classifications enable route filtering? > > A. Suppose ARIN holds 4000::/12. ARIN might split it up as follows: > > 4000::/13 -- reserved > 4008::/15 -- multihomed /24 allocations > 400a::/15 -- non-multihomed /24 allocations > 400c::/16 -- multihomed /32 allocations > 400d::/16 -- non-multihomed /32 allocations > 400e:0000::/18 -- multihomed /40 allocations > 400e:4000::/18 -- non-multihomed /40 allocations > 400e:8000::/24 -- multihomed /48 allocations > 400e:8100::/24 -- non-multihomed /48 allocations > 400e:8200::/24 -- multihomed /56 allocations > 400e:8300::/24 -- non-multihomed /56 allocations > 400e:8400::/22 -- reserved > 400e:8800::/21 -- reserved > 400e:9000::/20 -- reserved > 400e:a000::/19 -- reserved > 400e:c000::/18 -- reserved > 400f::/16 -- reserved > > Now, you're an ISP. Here's a sample routing policy you might choose: > > Accept any routes to /32 because anyone paying $10k per year for > addresses is big enough to ride. > For /24 allow 2 bits of traffic engineering too. > Single-homers who won't spend $10k/year on their addresses (smaller > than /32) must use addresses from their ISP. Tough luck. > Accept multihomers down to /48. > The folks paying only $10/year for /56's aren't serious. > > Your route filter looks like this: > > accept 400e:8000::/24 equal 48 > accept 400e:0000::/18 equal 40 > accept 400c::/15 equal 32 > accept 4008::/14 le 26 > reject 4000::/12 le 128 > > Note how 400e:8000::/24 contains only /48 allocations and you're > allowing only /48 announcements. Since there aren't any /47 or /46 > allocations there, nobody in the pool can slip TE routes past you. On > the other hand, you'll get some benefit of traffic engineering from > the super-massive /24 registrants up in 4008::/14 because you're > allowing them to disaggregate down to /26. > > Q. If its so expensive to announce routes into the DFZ, why not use > something better than BGP? > > A. In 2008 the IRTF Routing Research Group compiled an exhaustive > study attempting to identify the possible ways to improve the routing > system. A draft of the results is at > http://tools.ietf.org/html/draft-irtf-rrg-recommendation-02 . While > there are many promising ideas for how to replace BGP with something > that scales better, we're at least a decade away and probably more > from any significant deployment of a BGP replacement. > > Q. Is it really true that multihoming requires announcing a route via > BGP? > > A. The short answer is yes. The long answer is more complicated. > > Folks have tried very hard to devise multi-vendor multihomed systems > which don't rely on BGP. The only approach that has ever come near > success is dynamically changing DNS records to favor the currently > working Internet connection. "Near" is a relative term here. Such > network architectures are enormously complex and they don't work > especially well. The DNS protocol itself supports quick changes but > the applications which use it often don't. It takes hours to achieve > two-nines recovery from an address change in the DNS and it takes > months to achieve five-nines recovery. Web browsers, for example, > don't immediately recover. Search google for "DNS Pinning." > > Q. So the Internet's resulting route policy will be to allow all the > sizes that no major ISP decides to filter and restrict the rest? > > A. That's one possible outcome. On the other hand, research in the > routing field suggests that with a sufficiently rich classification > scheme, it may be possible to implement lower priority systems with > provider-independent addresses yet without a global route. Hints for > how such a thing might work can be found in > http://www.cs.cornell.edu/people/francis/va-wp.pdf and > http://bill.herrin.us/network/trrp.html. Such schemes need a rich > classification process at the address allocation level that makes it > possible for ISPs to make reasonable and simple decisions about which > routes should be distributed to every DFZ router and which should not. > > Wouldn't that be something: IPv6 provider independent addresses for > everybody without materially increasing the cost of the routing > system. > > Q. Why allocate the /48's from a pool only for /48's, /32's from a /32 > pool, etc.? Why not allocate from just one pool? > > A. If all assignments in a particular pool are /32 then any route in > the /32 pool which is longer than /32 is a traffic engineering (TE) > route. As a router operator you can filter and discard TE routes if > you find they give you insufficient benefit. The routes you filter > don't cost you any money; only the routes you keep carry a price tag. > > You can only filter if you're sure they're TE routes... If they're > distinct downstream customer routes and you filter them, there goes > the Internet. Or at least there goes your part of it. See customers. > See customers run... straight to your competitor. Setting up the > distinct pools makes it practical to know with certainty whether the > routes you're filtering are only for TE. > > Q. Why allow only one allocation of each particular size? > > A. Without the address scarcity issue which drives IPv4 policy, the > primary criteria for IPv6 addressing policy is suppressing the > disaggregation that drives route count in the IPv4 DFZ (NRPM 6.3.8). > Such a criteria is not well served if an organization holds dozens of > discontiguous address spaces as a result of acquisitions, mergers and > and growing a little bit at a time. This proposal says, in effect, > once you've consumed your smaller allocation it's time for you to get > a *much* bigger allocation. The rest of us don't want to pay the > routing table price for you coming back again and again and again. > > The proposal could require some renumbering as a result of mergers and > acquisitions. However, with only modest planning on the registrant's > part, the policy its flexible enough to allow that renumbering to > occur over a long period of time so that both cost and disruption are > minimized. In many cases, customer churn can be expected to take care > of much of the renumbering activity all by itself. > > Q. What about the IETF recommendations? > > A. RFC 3177 recommends that ISPs receive a /32 while downstream > customers receive a /48 assignment by default with so-called "sparse > allocation" to allow those assignments to expand by changing the > netmask. While this proposal supports organizations who wish to follow > those recommendations, it is not this proposal's intention that ARIN > follow RFC 3177. > > RFC 3177 is not the gospel truth. It was written back in 2001 when > there was little IPv6 outside of academia and, indeed, little IPv6 at > all. It's an engineers' SWAG about what operations folk should do > that's now 8-years-stale. > > This proposal attempts to slow-start IPv6 allocations instead, while > still maintaining the principle of suppressing the routing table size. > As an ISP, consider implementing a slow start for your downstream > customers as well: Give them a /60 initially, add a /56 when they need > it and add a /52 when they run out of the /56. A /60 is 16 /64 > subnets. That's an internal LAN, a DMZ and 14 more subnets. Just how > many subnets do you think your normal downstream customer will > actually use? > > Q. What happens when organizations merge or split? > > A. Entities which merge may renumber out of and return conflicting > allocations, or they may maintain the existence of the acquired > organization in order to keep it's addresses. Either way it should be > a minor hardship. > > Entities which split have a bigger problem since the practical effect > of route filtering may be that only one of them can keep the > addresses. To a large extent, that problem already exists and is a > pain in the rump for IPv4 operations today. This policy doesn't solve > it but it doesn't make it a whole lot worse either. Because > disaggregates are likely to be filtered, this IPv6 policy does gives > us a slightly better guarantee that the rest of us won't get stuck > with the check (in the form of routing slot consumption) when an ISP > goes bankrupt and gets split up. > > Q. What about IPv6 addresses for uses which will not be connected to > the Internet at all? > > A. Folks are welcome to get non-multihomed addresses for any purpose > whatsoever. If they do eventually decide to connect to the Internet, > the routes will follow whatever rules the ISPs have imposed for routes > within the single-homed pools. > > Q. What about reporting requirements for downstream assignments? > > A. Reporting requirements were instituted for the purpose of verifying > eligibility for additional allocations. They have proven useful for > other purposes and the author encourages ARIN to maintain the SWIP > system. Nevertheless, this proposal renders the use of SWIP for IPv6 > optional since it is no longer needed to verify eligibility for > allocations. > > Q. What if I need more than a /24? > > A. This proposal's author asserts as obvious: anyone who defines a > need for more than a trillion subnets should make their case publicly > on PPML, seeking a follow-on proposal that establishes address pools > at the /16 level. > > Q. What are the struck sections of the current IPv6 policy and why > should they be struck? > > A. 6.2.3 - 6.2.9 define terms that have no meaning or use in the > policy as revised by this proposal. > > The 6.4.3 notion of a minimum allocation is obsoleted by the > allocation pools of specific size in this proposal. > > 6.4.4 is moot as this proposal does not expect registrants to justify > their IPv6 allocation size. > > 6.5.1 - 6.5.4 and 6.5.8 are replaced entirely by 6.5.9. > > 6.5.5 is largely moot since it's no longer necessary to confirm > downstream assignments in order to determine eligibility for > additional addresses. > > 6.7 is moot as it is unnecessary to compute utilization to justify > addresses under this proposal. > > 6.9 paragraph 2 is moot since utilization is not a factor in IPv6 > policy under this proposal. > > 6.10 is redundant since micro-allocations are trivially accomplished > under 6.5.9. > > > Implementation notes: > > To prevent wasteful consumption of IPv6 address space without a > complicated eligibility regime, the author recommends an initial and > annual fee regime for IPv6 address allocations similar to: > > /56 -- $10 USD > /48 -- $100 USD > /40 -- $1000 USD > /32 -- $10,000 USD > /24 -- $100,000 USD > Legacy -- the lesser of the cost of the next larger size or the cost > of the next smaller size times the number encompassed by the > registration. > > The above notwithstanding, it may be advisable to discount /40s and > /32s to a much lower price during IPv6's general deployment process in > order to encourage adoption. Folks who already hold /31's should > probably also get a big break on the $20k fee for a good long while, > perhaps until the first time they request an additional block without > offering a plan to return the legacy addresses. > > For verification of multihoming, the current way ARIN verifies > multihoming for other parts of it's policy appears satisfactory. > Should that change, the author suggests requiring that the AS# > contacts for at least two AS#'s submit a template indicating that they > intend to originate or propagate IPv6 BGP routes from the registrant's > ORG. > > Timetable for implementation: immediate > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From rudi.daniel at gmail.com Sat Nov 14 23:36:33 2009 From: rudi.daniel at gmail.com (RudOlph Daniel) Date: Sat, 14 Nov 2009 23:36:33 -0500 Subject: [arin-ppml] Safety net for developing economies... (Ted Mittelstaedt) Message-ID: <8aeeaff60911142036p8a6fc1fgcc35f774b02dd5ba@mail.gmail.com> Ted In the face of runout there is good reason to build out, there are many new and proposed networks. CARICOM, OECS, Disaster and Public Safety, Financial and Business, Education. Provision of incentives to ensure timely transition in the face of a possible secondary market would depend on how its possibly going to affect you in the long run. Especially in areas of the region with first time infrastructure costs and planning and investment shortfalls in relation to the whole. < RudOlph Daniel wrote: > > This goes right to the heart of v4/v6 transistion. > > If we accept what Jeff Houston at APNIC reported : that only 40 % of > > legacy space is routed and that 3.6 % of allocated addresses are > > actually occupied by visible hosts, then it is perhaps worth speculating > > that there are out there, market makers who are laying the foundation to > > profit from "runout". > > > > I'm sure there are. > > > The ideology of stewardship of a common pool, whilst displaying good > > economic and social properties, does not prevent hoarding by one party > > thereby restricting use by another party. > > > > Correct. > > > Remember that allocation is based on case by case demonstration of need. > > Such a procedure is more akin to your central city planning function and > > therefore relies heavily on the accuracy of the information or should I > > say the symmetry of information between the requestor and the registry. > > So when you get the kind of market conditions suggested by Houston, it > > become a major challenge to the case by case administration process. In > > other words, your staff begin to complain of headaches :) > > > > Because of the legacy space situation, ARIN's policies have more impact > > than any other RIR. > > So it can also be argued that how legacy space is managed at "runout" > > directly affects not only the timely adoption of v6, but also Internet > > development and capacity building in the RIRs region. > > > > You can make that argument regardless of whether ARIN's policies have > more impact than any other RIR, ARIN is not unique in having some > unused space in it's IPv4 allocations. But, go on, > > > ARIN as a region possibly has the widest digital divide of the RIRs: > > contrasting, the USA, Canada, and the 22 small Caribbean states. > > > > Supposing we accept the existence of a v4 runout market, good > > stewardship of the resource should therefore prevent application and > > innovation in developing markets from becoming too expensive due to > > scarcity value of the resource. > > > > Arin already provides support for developing countries in its region so > > it is not so difficult to develop policy to use those portions of its > > region seeking internet development and capacity building to promote v6 > > adoption in a myriad of practical ways, since it not only address the > > digital divide but also brings them up to speed in the face of market > > challenges. Did someone propose IPv6 in a box at a public meeting? > > > > Are you advocating that ARIN offer developing countries in it's region > IPv4 resources in exchange for deploying IPv6? > > > The runout market makers are also going to be challenged by new fledging > > v6 networks which in themselves are going to act as a test bed for a > > host of network technical issues which currently confront easy adoption > > of v6. It also provides an opportunity to close the digital divide by > > providing subsidies at the bottom where the rate of return is far > > greater in the medium to long term than fighting a protracted war with > > deeply entrenched IP racketeers. > > > > Is this advocating ARIN make payments to orgs who don't have any > IP deployed because then they will build out IPv6, instead of trying > to build out IPv4? > > > There is also another perspective here, The ARINCaribbean is not unlike > > Africa, in that it has a very high penetration of Mobile; and so quick > > adoption of v6 is probably beneficial to economic growth in the region > > especially since the global economic downturn. But v6 adoption requires > > good planning, investment and collaboration: All of these are in short > > supply where the digital divide is a wide one. > > Are you saying good IPv6 planning, investment and collaboration is in > short supply in the ARIN region? > > > Even without a v4 runout headache, there are still big challenges > > confronting broadband access in rural areas and low income populations > > and it is interesting to note (from an opinion expressed to me) that > > these challenges are probably greater than those for the voice telephony > > of old. > > > > I think there's a lot of implications here your making. I happen to > agree with some of them, but I think that the problem isn't solvable > in the way I think your implying. Here is my $0.02 on why; > > With the old POTS telephoney the biggest challenge > was running a pair of copper wires for miles. Out in the sticks you had > the freedom of running a 10 mile copper pair subscriber line stuck to > barbed wire cow pasture fences, with the appropriate load coils in it. > You could cover very large distances with a very DUMB network, where all > the expensive intelligence is located in a single CO. > > This gives huge savings when you can do this. > > With any kind of higher speed broadband, you have to run DSL, or cable > TV cable, or fiber - all of which require repeaters, which require > power, and maintainence, and so on and so on. These push the > intelligence out into the field, out into the network. > > The model of a single large central office with concentrated > intelligence and a dumb network doesn't hold. Instead, a new model > of distributed intelligence is used. > > And, such a model is much more expensive, much more labor intensive, > than the old concentrated intelligence model. > > Thus, with the old model you could afford to subsidize the rural and low > income populations. You could strategically place the CO's on the edge > of the low income regions, so that the CO served a mix of low income and > high income areas, and thus, you would essentially subsidize the low > income areas. Because serving the low income areas was so cheap (since > the network cost practically nothing) and you had to have the CO there > serving the high-income areas anyway, there was little objection. > > In the new model, since every region that the network is in has to be > funded, it is very easy for the high-income but unschooled-in-networking > types to understand that when you were sending expensive intelligence > into low-income regions, that they were funding these areas. And, the > costs are far far higher than the old model. So naturally, they > objected to this. > > This is why the digital divide exists at all. To put it simply, it > costs a lot more money to hand out free Internet access than to hand out > free voice access, and Internet access is not a health-and-safety issue, > the way that 911-emergency access is on voice. So, you cannot use moral > persuasion to convince the high-income types that they must fund > Internet Access for the have-nots, and since doing this funding is so > expensive, there is no way to slip in these subsidies under the table > without the high-income types figuring it out. > > And more importantly, since Internet Access is so new (it's only > been around for 15 years for the masses, after all) the societal > structures to prevent undesirable behavior on it (such as piracy, > child exploitation, etc.) do not yet exist and are still being figured > out - as a result we have a LOT of objectionable behavior on the > Internet, behavior PARTICULARLY objectionable to someone subsidizing > Internet access for one of the not-haves. To put it succinctly, why > should the rich subsidize a have-not's porno surfing Playboy and > watching episodes of Lost off hulu? > > This is why, IMHO, the digital divide isn't currently a solvable > problem. In voice service today, we can provide a voice line that > will ONLY take 911 calls, to someone who is so dirt poor that > they cannot even afford an extra $10 a month for a POTS line. > The societal structures exist to do this and get the have's to > pay for it, and the haves mostly agree that there's a moral > imperative for them to do this. > > But, in Internet service today it's an all-or-nothing proposition. > We cannot provide an Internet connection that will ONLY > allow the have-nots to access educational stuff, or job-hunting > stuff, or other pull-yourself-up-by-the-bootstraps stuff that > the haves would all agree that there's a moral imperative to supply > to the have-nots. Instead, if we supply it, they get everything, > including the stuff that they shouldn't be wasting their time on. > > One of the biggest objections I hear about the food stamp program > in the United States comes from when "the poor" who are on food > stamps walk though the grocery store checkout line, carrying > food and beer - and pay cash for the beer and cigarettes, and > food stamps for the food. This gives the impression that taxpayer > dollars are funding alcohol and smoking, and turns every taxpayer > who sees this happening in the grocery store against the food stamp > program. So much so, in fact, that many states have gone to a > credit card system, that is unobtrusive, so that "the poor" who > are using this can get through the checkout line without anyone > realizing they are using public assistance. Ostensibly this is > to protect the privacy of the poor, but it also helps to reduce > public outrage at the perceived abuse of the program, which is > almost certainly the main reason the politicians went for it. > > I suspect that if there would ever be a serious movement (at least > in the United States) to make the same claim that Internet Access > was on par with voiceline access as a moral imperative for the > have-nots, that the outrage over public subsidies to the have-nots > for using publically-paid Internet service to access playboy.com > would make the complaints about the food stamp program look like > a match next to a forest fire. > > The digital divide isn't going to be solvable until the Internet > is cleaned up, and the worthless content (ie: all the sex stuff) > is behind lock and key, and the next-to-worthless stuff (ie: the > episodes of Lost on hulu.com) is behind a door that can be closed > if needed. > > The day you can allow your 10-year-old kid onto the Internet, > unsupervised, is the day the digital divide CAN be closed. Until > then, Internet Service is electronic beer and cigarettes, and > the poor are gonna have to pay cash. > > Just my $0.02 > > Ted > > > > Rudi Daniel > > > > > > > > On Fri, Nov 13, 2009 at 4:07 AM, John Curran > > wrote: > > > > On Nov 12, 2009, at 2:55 AM, RudOlph Daniel wrote: > > > ... > > > What I am suggesting here is that the network and its policies is > > not yet mature/homogeneous enough to provide a safety net for > > developing economies like the Caribbean in the face of the majority > > of this RIR with its far superior knowledge and experience, but yet > > not able to foresee the future black market shenanigans of a > > creative first world business professional class leveraging the > > scarcity value of a resource for considerable profit. > > > > Rudi - > > > > How should ARIN provide a safety net for developing economies in > > this region? To the extent that you have a suggestion, this is > > definitely the right place to discuss it. > > > > /John > > > > John Curran > > President and CEO > > ARIN > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tedm at ipinc.net Mon Nov 16 12:41:58 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 16 Nov 2009 09:41:58 -0800 Subject: [arin-ppml] Safety net for developing economies... (Ted Mittelstaedt) In-Reply-To: <8aeeaff60911142036p8a6fc1fgcc35f774b02dd5ba@mail.gmail.com> References: <8aeeaff60911142036p8a6fc1fgcc35f774b02dd5ba@mail.gmail.com> Message-ID: <4B018EE6.4080601@ipinc.net> RudOlph Daniel wrote: > Ted > In the face of runout there is good reason to build out, there are many > new and proposed networks. CARICOM, OECS, Disaster and Public Safety, > Financial and Business, Education. > > Provision of incentives to ensure timely transition in the face of a > possible secondary market would depend on how its possibly going to > affect you in the long run. Especially in areas of the region with first > time infrastructure costs and planning and investment shortfalls in > relation to the whole. The Internet is rapidly going feudal, you might say. I recall back in the early 80's when the Internet first began to be extended to overseas links to the original NSFnet backbone. EVERYONE who plugged in then spoke English - because English was (and still is) the language of Science and Engineering. Back then it was very easy to get everyone from every country to agree that when something smart needed to be done, to do it. (for example, the Great Renaming) Once we let the unwashed masses on, and foreign languages started to appear, that's when the nationalistic cultures started exerting their control over things. And, many governments see this as a bonus as it lets them exert control over information their citizens see. Heck, Egypt just filed for the first non-latin character domain name this weekend. 25 years ago it was a given that ANY node added to the Internet had something to offer everyone else on the network. That was the golden age of subsidizes. This isn't true today anymore. > < < > Offering direct incentives for v6 deployment. The returns policy is not > a direct incentive, it a measure of control in addition to incentives > already employed and to be employed? > I don't know what you mean by the returns policy. > I don't get hulu in my region, :) Textbook example of what I'm referring to. Technically, if you used a proxy server located in one of the "blessed" IP networks you could get hulu. This is well within the means of anyone with any technical knowledge of the Internet. But, it's insurmountable to the majority of users on the Internet today which is why hulu does this. The same issue exists for streaming ESPN. As you probably know, Disney charges ISP's extortion fees to add their networks into the allowed list of "blessed" networks that can go to espn.com and stream video from the site. They do this instead of charging individual Internet users fees to access ESPN so they can maintain the fiction that the ESPN users are getting something "free" out of the goodness of their corporate hearts. Any individual user from an ISP that doesn't pay the extortion fee (and is therefore blocked) can access a proxy on a "blessed" network, and get ESPN. But, it's insurmountable to the unwashed masses which is why Disney does it. These are examples of the feudalization of the Internet. The more of that that goes on, the more that the "haves" will be unwilling to subsidize the "have nots" Ted > and 10year olds will probably always > have to be supervised and it is already a challenge in the Internet age. > > I think, the meteoric rise in Internet use suggest that the > poor among us are very willing to pay, best thing we have had since > slice bread I would say. > > Rudi Daniel > > > > RudOlph Daniel wrote: > > This goes right to the heart of v4/v6 transistion. > > If we accept what Jeff Houston at APNIC reported : that only 40 % of > > legacy space is routed and that 3.6 % of allocated addresses are > > actually occupied by visible hosts, then it is perhaps worth > speculating > > that there are out there, market makers who are laying the > foundation to > > profit from "runout". > > > > I'm sure there are. > > > The ideology of stewardship of a common pool, whilst displaying good > > economic and social properties, does not prevent hoarding by one > party > > thereby restricting use by another party. > > > > Correct. > > > Remember that allocation is based on case by case demonstration > of need. > > Such a procedure is more akin to your central city planning > function and > > therefore relies heavily on the accuracy of the information or > should I > > say the symmetry of information between the requestor and the > registry. > > So when you get the kind of market conditions suggested by > Houston, it > > become a major challenge to the case by case administration > process. In > > other words, your staff begin to complain of headaches :) > > > > Because of the legacy space situation, ARIN's policies have more > impact > > than any other RIR. > > So it can also be argued that how legacy space is managed at "runout" > > directly affects not only the timely adoption of v6, but also > Internet > > development and capacity building in the RIRs region. > > > > You can make that argument regardless of whether ARIN's policies have > more impact than any other RIR, ARIN is not unique in having some > unused space in it's IPv4 allocations. But, go on, > > > ARIN as a region possibly has the widest digital divide of the RIRs: > > contrasting, the USA, Canada, and the 22 small Caribbean states. > > > > Supposing we accept the existence of a v4 runout market, good > > stewardship of the resource should therefore prevent application and > > innovation in developing markets from becoming too expensive due to > > scarcity value of the resource. > > > > Arin already provides support for developing countries in its > region so > > it is not so difficult to develop policy to use those portions of its > > region seeking internet development and capacity building to > promote v6 > > adoption in a myriad of practical ways, since it not only address the > > digital divide but also brings them up to speed in the face of market > > challenges. Did someone propose IPv6 in a box at a public meeting? > > > > Are you advocating that ARIN offer developing countries in it's region > IPv4 resources in exchange for deploying IPv6? > > > The runout market makers are also going to be challenged by new > fledging > > v6 networks which in themselves are going to act as a test bed for a > > host of network technical issues which currently confront easy > adoption > > of v6. It also provides an opportunity to close the digital divide by > > providing subsidies at the bottom where the rate of return is far > > greater in the medium to long term than fighting a protracted war > with > > deeply entrenched IP racketeers. > > > > Is this advocating ARIN make payments to orgs who don't have any > IP deployed because then they will build out IPv6, instead of trying > to build out IPv4? > > > There is also another perspective here, The ARINCaribbean is not > unlike > > Africa, in that it has a very high penetration of Mobile; and so > quick > > adoption of v6 is probably beneficial to economic growth in the > region > > especially since the global economic downturn. But v6 adoption > requires > > good planning, investment and collaboration: All of these are in > short > > supply where the digital divide is a wide one. > > Are you saying good IPv6 planning, investment and collaboration is in > short supply in the ARIN region? > > > Even without a v4 runout headache, there are still big challenges > > confronting broadband access in rural areas and low income > populations > > and it is interesting to note (from an opinion expressed to me) that > > these challenges are probably greater than those for the voice > telephony > > of old. > > > > I think there's a lot of implications here your making. I happen to > agree with some of them, but I think that the problem isn't solvable > in the way I think your implying. Here is my $0.02 on why; > > With the old POTS telephoney the biggest challenge > was running a pair of copper wires for miles. Out in the sticks you had > the freedom of running a 10 mile copper pair subscriber line stuck to > barbed wire cow pasture fences, with the appropriate load coils in it. > You could cover very large distances with a very DUMB network, where all > the expensive intelligence is located in a single CO. > > This gives huge savings when you can do this. > > With any kind of higher speed broadband, you have to run DSL, or cable > TV cable, or fiber - all of which require repeaters, which require > power, and maintainence, and so on and so on. These push the > intelligence out into the field, out into the network. > > The model of a single large central office with concentrated > intelligence and a dumb network doesn't hold. Instead, a new model > of distributed intelligence is used. > > And, such a model is much more expensive, much more labor intensive, > than the old concentrated intelligence model. > > Thus, with the old model you could afford to subsidize the rural and low > income populations. You could strategically place the CO's on the edge > of the low income regions, so that the CO served a mix of low income and > high income areas, and thus, you would essentially subsidize the low > income areas. Because serving the low income areas was so cheap (since > the network cost practically nothing) and you had to have the CO there > serving the high-income areas anyway, there was little objection. > > In the new model, since every region that the network is in has to be > funded, it is very easy for the high-income but unschooled-in-networking > types to understand that when you were sending expensive intelligence > into low-income regions, that they were funding these areas. And, the > costs are far far higher than the old model. So naturally, they > objected to this. > > This is why the digital divide exists at all. To put it simply, it > costs a lot more money to hand out free Internet access than to hand out > free voice access, and Internet access is not a health-and-safety issue, > the way that 911-emergency access is on voice. So, you cannot use moral > persuasion to convince the high-income types that they must fund > Internet Access for the have-nots, and since doing this funding is so > expensive, there is no way to slip in these subsidies under the table > without the high-income types figuring it out. > > And more importantly, since Internet Access is so new (it's only > been around for 15 years for the masses, after all) the societal > structures to prevent undesirable behavior on it (such as piracy, > child exploitation, etc.) do not yet exist and are still being figured > out - as a result we have a LOT of objectionable behavior on the > Internet, behavior PARTICULARLY objectionable to someone subsidizing > Internet access for one of the not-haves. To put it succinctly, why > should the rich subsidize a have-not's porno surfing Playboy and > watching episodes of Lost off hulu? > > This is why, IMHO, the digital divide isn't currently a solvable > problem. In voice service today, we can provide a voice line that > will ONLY take 911 calls, to someone who is so dirt poor that > they cannot even afford an extra $10 a month for a POTS line. > The societal structures exist to do this and get the have's to > pay for it, and the haves mostly agree that there's a moral > imperative for them to do this. > > But, in Internet service today it's an all-or-nothing proposition. > We cannot provide an Internet connection that will ONLY > allow the have-nots to access educational stuff, or job-hunting > stuff, or other pull-yourself-up-by-the-bootstraps stuff that > the haves would all agree that there's a moral imperative to supply > to the have-nots. Instead, if we supply it, they get everything, > including the stuff that they shouldn't be wasting their time on. > > One of the biggest objections I hear about the food stamp program > in the United States comes from when "the poor" who are on food > stamps walk though the grocery store checkout line, carrying > food and beer - and pay cash for the beer and cigarettes, and > food stamps for the food. This gives the impression that taxpayer > dollars are funding alcohol and smoking, and turns every taxpayer > who sees this happening in the grocery store against the food stamp > program. So much so, in fact, that many states have gone to a > credit card system, that is unobtrusive, so that "the poor" who > are using this can get through the checkout line without anyone > realizing they are using public assistance. Ostensibly this is > to protect the privacy of the poor, but it also helps to reduce > public outrage at the perceived abuse of the program, which is > almost certainly the main reason the politicians went for it. > > I suspect that if there would ever be a serious movement (at least > in the United States) to make the same claim that Internet Access > was on par with voiceline access as a moral imperative for the > have-nots, that the outrage over public subsidies to the have-nots > for using publically-paid Internet service to access playboy.com > > would make the complaints about the food stamp program look like > a match next to a forest fire. > > The digital divide isn't going to be solvable until the Internet > is cleaned up, and the worthless content (ie: all the sex stuff) > is behind lock and key, and the next-to-worthless stuff (ie: the > episodes of Lost on hulu.com ) is behind a door > that can be closed > if needed. > > The day you can allow your 10-year-old kid onto the Internet, > unsupervised, is the day the digital divide CAN be closed. Until > then, Internet Service is electronic beer and cigarettes, and > the poor are gonna have to pay cash. > > Just my $0.02 > > Ted > > > > Rudi Daniel > > > > > > > > On Fri, Nov 13, 2009 at 4:07 AM, John Curran > > >> wrote: > > > > On Nov 12, 2009, at 2:55 AM, RudOlph Daniel wrote: > > > ... > > > What I am suggesting here is that the network and its > policies is > > not yet mature/homogeneous enough to provide a safety net for > > developing economies like the Caribbean in the face of the > majority > > of this RIR with its far superior knowledge and experience, > but yet > > not able to foresee the future black market shenanigans of a > > creative first world business professional class leveraging the > > scarcity value of a resource for considerable profit. > > > > Rudi - > > > > How should ARIN provide a safety net for developing > economies in > > this region? To the extent that you have a suggestion, this is > > definitely the right place to discuss it. > > > > /John > > > > John Curran > > President and CEO > > ARIN > > > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From Wesley.E.George at sprint.com Mon Nov 16 13:30:49 2009 From: Wesley.E.George at sprint.com (George, Wes E [NTK]) Date: Mon, 16 Nov 2009 12:30:49 -0600 Subject: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process In-Reply-To: <4AF86E15.2060307@arin.net> References: <4AF86E15.2060307@arin.net> Message-ID: I'm opposed to this proposal. I like the spirit behind it. However, I'm not sure how well it would actually work in practice (as you have alluded to regarding things like preventing deaggregation), - I simply don't think that it's really practical to filter traffic-engineering deaggregations without providing networks an alternate method to manage their traffic - there's a real quagmire in determining what is "distant" and therefore ok to filter vs what is not, especially when you're trying to do it with standardized route-policies. While I agree that RFC3177 is outdated and ARIN already isn't following it to the letter, ARIN doing this sort of radical change on their own would have near zero of the claimed benefits, so this would at the very least need to be a global policy. In my opinion, an IETF draft that updates RFC3177 would be even more helpful, since that would help to discuss the implications to the routing system within the body most equipped to evaluate it. There are also fundamental questions in my mind around the execution of this proposal. I have a major problem with the fact that this proposal as written doesn't seem to give any guidance as to how ARIN staff would determine who gets what size allocation, nor how to manage when it is ok to give a single org more than one block (of a different size). The rationale seems to imply that we're no good at predicting use, so let's stop trying, and just give everyone whatever size block they're willing to pay for. Until people have really gotten away from the scarcity mentality that accompanies IPv4 addressing, barring any sort of justification requirement, most entities that can afford it will ask for a /24 simply because they can. It will take years for people not to view IPv6 as a scarce resource, especially if the IPv4 runout is nasty. Raising the price won't work, because you don't want to punish those that have a network that is actually big enough to justify that size, and you'd have to raise it significantly to actually change behavior for those who don't. Your recommendation of increasing the high-end fees to well north of where they are today means that you are actually creating a disincentive to building big networks under one block - instead of getting a /24 because I need a bit more than a /32, I might get a /32 and a /40, thereby adding an entry in the routing table to save money. While $100K isn't a lot of money compared with your average cable company or mobile operator's annual capital budget, it *is* punitive given the increase over the previous size. This is especially true assuming that IP address resources are still supposed to be allocated based on need, and the primary thought here is that we have an embarrassment of riches and therefore no reason to constrict our allocations like we did in IPv4. Maybe you end up with two different fee structures, one for those who can justify the space based on usage and one for those who can't, but that's awfully complicated for what is largely an unproven benefit. It also ends up that the few large block holders are subsidizing the smaller block holders, because your suggested fees likely don't even cover ARINs costs of administration at the low end. Then, allowing the same org to go back to the well for another block of a different size with the same (zero) justification, encourages wasteful and lazy use of address space, and will actually result in more addresses in the table; instead of having to subnet my current /24 so that I have space available for some new project, I might just go ask for another /40 or /32. It's so cheap under your proposed fee structure, it's easier to buy more than it is to free up what I have via renumbering. Not saying that people can't play the H-D ratio to end up with that result anyway, but I think this makes it worse. Also, I think this moves towards a system where there really is no concept of/use for PD space anymore. What incentive is there to get PD space and be forced to renumber if you change ISPs when you can so easily (and under your suggested fee structure, cheaply!) qualify for PI space? This means that a lot of the existing aggregation that takes place in the DFZ today due to larger ISPs aggregating blocks that they allocate to small, statically routed or singly-homed BGP-speaking networks downstream of them would just disappear, to be replaced with discrete blocks in the routing table. I think this is far worse than any benefit derived from reducing the need for some networks to come back to get a second block because they have used up their first one, or easier filtering on address boundaries. Even if you increase the small block prices, it's still justified against the cost of renumbering to change upstreams, so there's a big incentive for small companies to get their own blocks, if the discussion on some of the other "open IPv6" policies are any indicator. Contrary to what is claimed in this proposal, I view this specific side effect as very much ARIN dictating routing policy. Maybe not overtly, but the end result is the same - you're enabling a lot of networks that would otherwise use PD space to become PI and therefore occupy its own slot in the routing table, because I have no way to aggregate it, and no choice but to carry it. You also need to address how existing allocations that don't fall on those rigid boundaries would be handled. My organization, for example, has a /29. That means ARIN needs to be able to give me the extra bits in order to magically make that into a /24. If ARIN didn't allocate sparsely enough to make that work and I have to renumber, how long do I have? How do I justify the cost of triggering a renumber on a network I *just* rolled out? If I'm reading your fee recommendations right you have a grandfather clause, and that would make a lot of the supposed benefits of this proposal go away too, because no one will want to renumber, especially if it means going from $16K in annual fees to $100K, meaning that we've just lost our deterministic filtering. Another question I do think is largely unanswered is some manner of estimate of how much address space (in terms of number of networks) going back to something like classful address allocation would cost us, bumped up against what we think the world might look like (in terms of rough numbers of IPv6 blocks in use) in 10 years time, and compared with other options like sparse allocation. Your basic supposition is that there was nothing wrong with classful addressing, we just didn't have enough bits to match the number of networks that we would have needed. Since you don't seem to be advocating the rigidity of routing (no subnetting) that came with classful routing, I more or less agree, but I am one of those who is worried about us not learning from history. How many times in the past has someone uttered some variance of the phrase "but this is more than we could need in a hundred years!" only to be very, very wrong. While IPv6 is a *lot* of address space, it's not infinite. I think we need to be careful with changes such as this unless we have some defensible math that tells us we won't be back here in a few years' time looking to undo this and reclaim address space from our new "class A holders" because we've run out of addresses due to the number of /24s we had to allocate. It's far easier to fill in the sparsely populated allocations that were reserved for existing networks to grow with new requestors than it is to reclaim address space that's already allocated, so I'm not buying the argument that this is no more wasteful than sparse allocation. FWIW, The entirety of the IANA available space right now is a /3. That works out to 2M /24s. ARIN has 5 /23s and a /12 - that's 4K /24s, assuming nothing was allocated, or 1M /32s. Like I said... A lot, but not infinite. Sorry for the book. Thanks, Wes George -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services Sent: Monday, November 09, 2009 2:32 PM To: arin-ppml at arin.net Subject: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process ARIN received the following policy proposal and is posting it to the Public Policy Mailing List (PPML) in accordance with Policy Development Process. This proposal is in the first stage of the Policy Development Process. ARIN staff will perform the Clarity and Understanding step. Staff does not evaluate the proposal at this time, their goal is to make sure that they understand the proposal and believe the community will as well. Staff will report their results to the ARIN Advisory Council (AC) within 10 days. The AC will review the proposal at their next regularly scheduled meeting (if the period before the next regularly scheduled meeting is less than 10 days, then the period may be extended to the subsequent regularly scheduled meeting). The AC will decide how to utilize the proposal and announce the decision to the PPML. In the meantime, the AC invites everyone to comment on the proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Mailing list subscription information can be found at: https://www.arin.net/mailing_lists/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 103: Change IPv6 Allocation Process Proposal Originator: William Herrin Proposal Version: 1.0 Date: 9 November 2009 Proposal type: new Policy term: permanent. Policy statement: Strike NRPM sections: 6.2.3, 6.2.4, 6.2.6-6.2.9, 6.4.3, 6.4.4, 6.5.1-6.5.5, 6.5.8, 6.7, 6.10 Strike NRPM section 6.9 paragraph 2. Replace 6.2.5 as follows: 6.2.5 Allocate and Assign For the purposes of NRPM section 6, allocate and assign are synonymous. Both terms describe any or all use identified in section 2.5. Replace 6.5.7 with: 6.5.7. Existing IPv6 address space holders Organizations that received IPv6 allocations under the previous IPv6 address policy are entitled to either retain those allocations as is or trade them in for an allocation under 6.5.9. Add NRPM section 6.5.9 as follows: 6.5.9 IPv6 Allocations 6.5.9.1 ARIN shall allocate IPv6 address blocks in exactly and only the following denominations: /56, /48, /40, /32, /24 6.5.9.2 No utilization-based eligibility requirements shall apply to IPv6 allocations. 6.5.9.3 ARIN shall accept registration of no more than one address block of each size for any single organization. 6.5.9.4 ARIN shall allocate IPv6 addresses from pools such that the identity of the allocation pool serves to classify the expected size of allocations within. ISPs may use that classification to filter or otherwise manage their routing tables. 6.5.9.5 For each allocation size, ARIN shall further manage the allocation pools such that the pool identity serves to classify whether or not the registrant is Multihomed. 6.5.9.6 ARIN shall offer addresses from pools classified as multihomed only to organizations which ARIN has verified are multihomed on the public Internet per NRPM 2.7. 6.5.9.7 Where an organization ceases to be Multihomed it shall surrender all address allocations from within pools classified as multihomed within 3 months. Rationale: See the implementation notes section below for what should replace utilization-based eligibility. The existing IPv6 allocation policy under section 6.5 makes a number of unproven assumptions about how IPv6 allocations will work. Unproven: we can make a reasonable guess about how many IPv6 subnets an organization will need at the outset when they first request IP addresses. When in all of human history has this ever proven true of any resource? Unproven: with sparse allocation, we can allow organizations to expand by just changing their subnet mask so that they don't have to announce additional routes into the DFZ. This claim is questionable. With sparse allocation, we either consume much larger blocks that what we assign (so why not just assign the larger block?) or else we don't consume them in which case the org either has to renumber to expand or he has to announce a second route. Worse, because routes of various sizes are all scattered inside the same address space, its impractical to filter out the traffic engineering routes. Unproven: we can force organizations not to disaggregate for traffic engineering purposes. Neither any of our experience with IPv4 nor any of the research in the IRTF Routing Research Group suggests that this is even remotely practical so long as BGP or any similar system rules the roost. Unproven: all non-ISPs can be reasonably expected to get their address space from ISPs instead of from ARIN. We can certainly operate that way, but it could prove deadly to the routing table. Any organization multihomed between two ISPs will need to announce that route via BGP, regardless of where they get the address space from. We have knobs and dials in the routers that let us easily filter disaggregates from distant announcements, but we don't dare do so if there is a possibility that one of those disaggregates is a multihomed customer rather than traffic engineering. Benefits of this proposal: A. Efficient allocation of IP addresses. Orgs get what they need when they need it without a great deal of guesswork. B. Efficient utilization of BGP routing slots. No multihomed orgs will announce more than five unfilterable routes, and that only if they're so large that they can afford the price tag for the biggest address blocks. That's a good thing since IPv6 routes that propagate worldwide may impose an annual systemic overhead cost on ISPs of as much as US $16,000 each. C. Traffic engineering routes are trivially filterable. Any route longer than the published allocation size can be presumed to be traffic engineering, not a downstream multihomed customer, thus you can filter distant small routes with confidence and ease. D. Fair. No need to define the difference between ISP and not ISP. Everybody plays by the same rules. E. No complicated analysis for allocation. You pay for what you want and get what you pay for. You're either multihomed or you're not. F. Gets ARIN out of the business of being the gatekeeper for Internet routing policy. By classifying allocations instead of making eligibility decisions, ARIN empowers the ISPs to set appropriate routing eligibility policies instead. FAQ Q. Isn't this classfull addressing all over again? A. Yes. Classful addressing had a lot of virtues with respect to route filtering and management. We had to abandon it because there weren't enough B's for everyone who needed more than one C and there weren't enough A's period. With IPv6, we don't have that problem. Not yet and maybe not ever. Perhaps we can have our cake and eat it too. Q. What if I don't want to accept /56 routes for single-homed users? A. This policy proposal intentionally and fully places backbone routing policy in the hands of the ISPs who operate the Internet's "Default-Free Zone (DFZ)," colloquially known as the Internet backbone. The author expects that some of the allocations, especially some of the single-homed allocations, *will not* be routable on the public Internet. When we hold a general expectation that all of ARIN's allocations will be routable, we effectively mean that ARIN decides what the Internet routing policy will be. That's precisely the role this proposal removes from ARIN's hands and restores to the ISPs. Q. Spell it out for me. How exactly will pools and size classifications enable route filtering? A. Suppose ARIN holds 4000::/12. ARIN might split it up as follows: 4000::/13 -- reserved 4008::/15 -- multihomed /24 allocations 400a::/15 -- non-multihomed /24 allocations 400c::/16 -- multihomed /32 allocations 400d::/16 -- non-multihomed /32 allocations 400e:0000::/18 -- multihomed /40 allocations 400e:4000::/18 -- non-multihomed /40 allocations 400e:8000::/24 -- multihomed /48 allocations 400e:8100::/24 -- non-multihomed /48 allocations 400e:8200::/24 -- multihomed /56 allocations 400e:8300::/24 -- non-multihomed /56 allocations 400e:8400::/22 -- reserved 400e:8800::/21 -- reserved 400e:9000::/20 -- reserved 400e:a000::/19 -- reserved 400e:c000::/18 -- reserved 400f::/16 -- reserved Now, you're an ISP. Here's a sample routing policy you might choose: Accept any routes to /32 because anyone paying $10k per year for addresses is big enough to ride. For /24 allow 2 bits of traffic engineering too. Single-homers who won't spend $10k/year on their addresses (smaller than /32) must use addresses from their ISP. Tough luck. Accept multihomers down to /48. The folks paying only $10/year for /56's aren't serious. Your route filter looks like this: accept 400e:8000::/24 equal 48 accept 400e:0000::/18 equal 40 accept 400c::/15 equal 32 accept 4008::/14 le 26 reject 4000::/12 le 128 Note how 400e:8000::/24 contains only /48 allocations and you're allowing only /48 announcements. Since there aren't any /47 or /46 allocations there, nobody in the pool can slip TE routes past you. On the other hand, you'll get some benefit of traffic engineering from the super-massive /24 registrants up in 4008::/14 because you're allowing them to disaggregate down to /26. Q. If its so expensive to announce routes into the DFZ, why not use something better than BGP? A. In 2008 the IRTF Routing Research Group compiled an exhaustive study attempting to identify the possible ways to improve the routing system. A draft of the results is at http://tools.ietf.org/html/draft-irtf-rrg-recommendation-02 . While there are many promising ideas for how to replace BGP with something that scales better, we're at least a decade away and probably more from any significant deployment of a BGP replacement. Q. Is it really true that multihoming requires announcing a route via BGP? A. The short answer is yes. The long answer is more complicated. Folks have tried very hard to devise multi-vendor multihomed systems which don't rely on BGP. The only approach that has ever come near success is dynamically changing DNS records to favor the currently working Internet connection. "Near" is a relative term here. Such network architectures are enormously complex and they don't work especially well. The DNS protocol itself supports quick changes but the applications which use it often don't. It takes hours to achieve two-nines recovery from an address change in the DNS and it takes months to achieve five-nines recovery. Web browsers, for example, don't immediately recover. Search google for "DNS Pinning." Q. So the Internet's resulting route policy will be to allow all the sizes that no major ISP decides to filter and restrict the rest? A. That's one possible outcome. On the other hand, research in the routing field suggests that with a sufficiently rich classification scheme, it may be possible to implement lower priority systems with provider-independent addresses yet without a global route. Hints for how such a thing might work can be found in http://www.cs.cornell.edu/people/francis/va-wp.pdf and http://bill.herrin.us/network/trrp.html. Such schemes need a rich classification process at the address allocation level that makes it possible for ISPs to make reasonable and simple decisions about which routes should be distributed to every DFZ router and which should not. Wouldn't that be something: IPv6 provider independent addresses for everybody without materially increasing the cost of the routing system. Q. Why allocate the /48's from a pool only for /48's, /32's from a /32 pool, etc.? Why not allocate from just one pool? A. If all assignments in a particular pool are /32 then any route in the /32 pool which is longer than /32 is a traffic engineering (TE) route. As a router operator you can filter and discard TE routes if you find they give you insufficient benefit. The routes you filter don't cost you any money; only the routes you keep carry a price tag. You can only filter if you're sure they're TE routes... If they're distinct downstream customer routes and you filter them, there goes the Internet. Or at least there goes your part of it. See customers. See customers run... straight to your competitor. Setting up the distinct pools makes it practical to know with certainty whether the routes you're filtering are only for TE. Q. Why allow only one allocation of each particular size? A. Without the address scarcity issue which drives IPv4 policy, the primary criteria for IPv6 addressing policy is suppressing the disaggregation that drives route count in the IPv4 DFZ (NRPM 6.3.8). Such a criteria is not well served if an organization holds dozens of discontiguous address spaces as a result of acquisitions, mergers and and growing a little bit at a time. This proposal says, in effect, once you've consumed your smaller allocation it's time for you to get a *much* bigger allocation. The rest of us don't want to pay the routing table price for you coming back again and again and again. The proposal could require some renumbering as a result of mergers and acquisitions. However, with only modest planning on the registrant's part, the policy its flexible enough to allow that renumbering to occur over a long period of time so that both cost and disruption are minimized. In many cases, customer churn can be expected to take care of much of the renumbering activity all by itself. Q. What about the IETF recommendations? A. RFC 3177 recommends that ISPs receive a /32 while downstream customers receive a /48 assignment by default with so-called "sparse allocation" to allow those assignments to expand by changing the netmask. While this proposal supports organizations who wish to follow those recommendations, it is not this proposal's intention that ARIN follow RFC 3177. RFC 3177 is not the gospel truth. It was written back in 2001 when there was little IPv6 outside of academia and, indeed, little IPv6 at all. It's an engineers' SWAG about what operations folk should do that's now 8-years-stale. This proposal attempts to slow-start IPv6 allocations instead, while still maintaining the principle of suppressing the routing table size. As an ISP, consider implementing a slow start for your downstream customers as well: Give them a /60 initially, add a /56 when they need it and add a /52 when they run out of the /56. A /60 is 16 /64 subnets. That's an internal LAN, a DMZ and 14 more subnets. Just how many subnets do you think your normal downstream customer will actually use? Q. What happens when organizations merge or split? A. Entities which merge may renumber out of and return conflicting allocations, or they may maintain the existence of the acquired organization in order to keep it's addresses. Either way it should be a minor hardship. Entities which split have a bigger problem since the practical effect of route filtering may be that only one of them can keep the addresses. To a large extent, that problem already exists and is a pain in the rump for IPv4 operations today. This policy doesn't solve it but it doesn't make it a whole lot worse either. Because disaggregates are likely to be filtered, this IPv6 policy does gives us a slightly better guarantee that the rest of us won't get stuck with the check (in the form of routing slot consumption) when an ISP goes bankrupt and gets split up. Q. What about IPv6 addresses for uses which will not be connected to the Internet at all? A. Folks are welcome to get non-multihomed addresses for any purpose whatsoever. If they do eventually decide to connect to the Internet, the routes will follow whatever rules the ISPs have imposed for routes within the single-homed pools. Q. What about reporting requirements for downstream assignments? A. Reporting requirements were instituted for the purpose of verifying eligibility for additional allocations. They have proven useful for other purposes and the author encourages ARIN to maintain the SWIP system. Nevertheless, this proposal renders the use of SWIP for IPv6 optional since it is no longer needed to verify eligibility for allocations. Q. What if I need more than a /24? A. This proposal's author asserts as obvious: anyone who defines a need for more than a trillion subnets should make their case publicly on PPML, seeking a follow-on proposal that establishes address pools at the /16 level. Q. What are the struck sections of the current IPv6 policy and why should they be struck? A. 6.2.3 - 6.2.9 define terms that have no meaning or use in the policy as revised by this proposal. The 6.4.3 notion of a minimum allocation is obsoleted by the allocation pools of specific size in this proposal. 6.4.4 is moot as this proposal does not expect registrants to justify their IPv6 allocation size. 6.5.1 - 6.5.4 and 6.5.8 are replaced entirely by 6.5.9. 6.5.5 is largely moot since it's no longer necessary to confirm downstream assignments in order to determine eligibility for additional addresses. 6.7 is moot as it is unnecessary to compute utilization to justify addresses under this proposal. 6.9 paragraph 2 is moot since utilization is not a factor in IPv6 policy under this proposal. 6.10 is redundant since micro-allocations are trivially accomplished under 6.5.9. Implementation notes: To prevent wasteful consumption of IPv6 address space without a complicated eligibility regime, the author recommends an initial and annual fee regime for IPv6 address allocations similar to: /56 -- $10 USD /48 -- $100 USD /40 -- $1000 USD /32 -- $10,000 USD /24 -- $100,000 USD Legacy -- the lesser of the cost of the next larger size or the cost of the next smaller size times the number encompassed by the registration. The above notwithstanding, it may be advisable to discount /40s and /32s to a much lower price during IPv6's general deployment process in order to encourage adoption. Folks who already hold /31's should probably also get a big break on the $20k fee for a good long while, perhaps until the first time they request an additional block without offering a plan to return the legacy addresses. For verification of multihoming, the current way ARIN verifies multihoming for other parts of it's policy appears satisfactory. Should that change, the author suggests requiring that the AS# contacts for at least two AS#'s submit a template indicating that they intend to originate or propagate IPv6 BGP routes from the registrant's ORG. Timetable for implementation: immediate _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. From terry.l.davis at boeing.com Mon Nov 16 15:03:20 2009 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Mon, 16 Nov 2009 12:03:20 -0800 Subject: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process In-Reply-To: <4AFE3008.3000904@ibctech.ca> References: <4AF86E15.2060307@arin.net> <4AFE3008.3000904@ibctech.ca> Message-ID: <0267B5481DCC474D8088BF4A25C7F1DF55127B074A@XCH-NW-05V.nw.nos.boeing.com> Steve I like it also. One of our biggest problems is that we simply do not have enough really large scale IPv6 deployments around the globe to begin to understand all the problems or to come up with better migration/integration plans between v4 and v6. This should spur more use IPv6; as it is today, not even the green field startups are using v6 and this should tell us something about our current assumptions and policies. In retrospect, by not having a seamless, easy to use method, of allowing v4 to v6 communications, we have made deploying v6 very costly; migrating our millions of v4 based apps to v6 comes with both a huge price tag for opening and dual-stacking them and a corresponding "risk" factor for business continuity associated with that work. Take care Terry > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Steve Bertrand > Sent: Friday, November 13, 2009 8:20 PM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation > Process > > Member Services wrote: > > > Policy Proposal 103: Change IPv6 Allocation Process > > I'm very, very interested in this proposal, and would like to give it a > bump in hopes that it will spur more feedback and discussion than what > it's received thus far. > > Truthfully, I would like to get a feel on the number of people who like > it (I certainly do). If anyone has disregarded or overlooked the > proposal because of the recommended financial figures, please let that > be known as well. > > Complete original proposal message has been left intact below. > > Steve > > > > Proposal Originator: William Herrin > > > > Proposal Version: 1.0 > > > > Date: 9 November 2009 > > > > Proposal type: new > > > > Policy term: permanent. > > > > Policy statement: > > > > Strike NRPM sections: 6.2.3, 6.2.4, 6.2.6-6.2.9, 6.4.3, 6.4.4, > > 6.5.1-6.5.5, 6.5.8, 6.7, 6.10 > > > > Strike NRPM section 6.9 paragraph 2. > > > > Replace 6.2.5 as follows: > > > > 6.2.5 Allocate and Assign > > > > For the purposes of NRPM section 6, allocate and assign are > > synonymous. Both terms describe any or all use identified in section > > 2.5. > > > > Replace 6.5.7 with: > > > > 6.5.7. Existing IPv6 address space holders > > > > Organizations that received IPv6 allocations under the previous IPv6 > > address policy are entitled to either retain those allocations as is > > or trade them in for an allocation under 6.5.9. > > > > Add NRPM section 6.5.9 as follows: > > > > 6.5.9 IPv6 Allocations > > > > 6.5.9.1 ARIN shall allocate IPv6 address blocks in exactly and only > > the following denominations: /56, /48, /40, /32, /24 > > > > 6.5.9.2 No utilization-based eligibility requirements shall apply to > > IPv6 allocations. > > > > 6.5.9.3 ARIN shall accept registration of no more than one address > > block of each size for any single organization. > > > > 6.5.9.4 ARIN shall allocate IPv6 addresses from pools such that the > > identity of the allocation pool serves to classify the expected size > > of allocations within. ISPs may use that classification to filter or > > otherwise manage their routing tables. > > > > 6.5.9.5 For each allocation size, ARIN shall further manage the > > allocation pools such that the pool identity serves to classify > > whether or not the registrant is Multihomed. > > > > 6.5.9.6 ARIN shall offer addresses from pools classified as multihomed > > only to organizations which ARIN has verified are multihomed on the > > public Internet per NRPM 2.7. > > > > 6.5.9.7 Where an organization ceases to be Multihomed it shall > > surrender all address allocations from within pools classified as > > multihomed within 3 months. > > > > > > Rationale: > > > > See the implementation notes section below for what should replace > > utilization-based eligibility. > > > > The existing IPv6 allocation policy under section 6.5 makes a number > > of unproven assumptions about how IPv6 allocations will work. > > > > Unproven: we can make a reasonable guess about how many IPv6 subnets > > an organization will need at the outset when they first request IP > > addresses. When in all of human history has this ever proven true of > > any resource? > > > > Unproven: with sparse allocation, we can allow organizations to expand > > by just changing their subnet mask so that they don't have to announce > > additional routes into the DFZ. This claim is questionable. With > > sparse allocation, we either consume much larger blocks that what we > > assign (so why not just assign the larger block?) or else we don't > > consume them in which case the org either has to renumber to expand or > > he has to announce a second route. Worse, because routes of various > > sizes are all scattered inside the same address space, its impractical > > to filter out the traffic engineering routes. > > > > Unproven: we can force organizations not to disaggregate for traffic > > engineering purposes. Neither any of our experience with IPv4 nor any > > of the research in the IRTF Routing Research Group suggests that this > > is even remotely practical so long as BGP or any similar system rules > > the roost. > > > > Unproven: all non-ISPs can be reasonably expected to get their address > > space from ISPs instead of from ARIN. We can certainly operate that > > way, but it could prove deadly to the routing table. Any organization > > multihomed between two ISPs will need to announce that route via BGP, > > regardless of where they get the address space from. We have knobs and > > dials in the routers that let us easily filter disaggregates from > > distant announcements, but we don't dare do so if there is a > > possibility that one of those disaggregates is a multihomed customer > > rather than traffic engineering. > > > > Benefits of this proposal: > > > > A. Efficient allocation of IP addresses. Orgs get what they need when > > they need it without a great deal of guesswork. > > > > B. Efficient utilization of BGP routing slots. No multihomed orgs will > > announce more than five unfilterable routes, and that only if they're > > so large that they can afford the price tag for the biggest address > > blocks. That's a good thing since IPv6 routes that propagate worldwide > > may impose an annual systemic overhead cost on ISPs of as much as US > > $16,000 each. > > > > C. Traffic engineering routes are trivially filterable. Any route > > longer than the published allocation size can be presumed to be > > traffic engineering, not a downstream multihomed customer, thus you > > can filter distant small routes with confidence and ease. > > > > D. Fair. No need to define the difference between ISP and not ISP. > > Everybody plays by the same rules. > > > > E. No complicated analysis for allocation. You pay for what you want > > and get what you pay for. You're either multihomed or you're not. > > > > F. Gets ARIN out of the business of being the gatekeeper for Internet > > routing policy. By classifying allocations instead of making > > eligibility decisions, ARIN empowers the ISPs to set appropriate > > routing eligibility policies instead. > > > > FAQ > > Q. Isn't this classfull addressing all over again? > > A. Yes. > > Classful addressing had a lot of virtues with respect to route > > filtering and management. We had to abandon it because there weren't > > enough B's for everyone who needed more than one C and there weren't > > enough A's period. With IPv6, we don't have that problem. Not yet and > > maybe not ever. Perhaps we can have our cake and eat it too. > > > > Q. What if I don't want to accept /56 routes for single-homed users? > > > > A. This policy proposal intentionally and fully places backbone > > routing policy in the hands of the ISPs who operate the Internet's > > "Default-Free Zone (DFZ)," colloquially known as the Internet > > backbone. The author expects that some of the allocations, especially > > some of the single-homed allocations, *will not* be routable on the > > public Internet. When we hold a general expectation that all of ARIN's > > allocations will be routable, we effectively mean that ARIN decides > > what the Internet routing policy will be. That's precisely the role > > this proposal removes from ARIN's hands and restores to the ISPs. > > > > Q. Spell it out for me. How exactly will pools and size > > classifications enable route filtering? > > > > A. Suppose ARIN holds 4000::/12. ARIN might split it up as follows: > > > > 4000::/13 -- reserved > > 4008::/15 -- multihomed /24 allocations > > 400a::/15 -- non-multihomed /24 allocations > > 400c::/16 -- multihomed /32 allocations > > 400d::/16 -- non-multihomed /32 allocations > > 400e:0000::/18 -- multihomed /40 allocations > > 400e:4000::/18 -- non-multihomed /40 allocations > > 400e:8000::/24 -- multihomed /48 allocations > > 400e:8100::/24 -- non-multihomed /48 allocations > > 400e:8200::/24 -- multihomed /56 allocations > > 400e:8300::/24 -- non-multihomed /56 allocations > > 400e:8400::/22 -- reserved > > 400e:8800::/21 -- reserved > > 400e:9000::/20 -- reserved > > 400e:a000::/19 -- reserved > > 400e:c000::/18 -- reserved > > 400f::/16 -- reserved > > > > Now, you're an ISP. Here's a sample routing policy you might choose: > > > > Accept any routes to /32 because anyone paying $10k per year for > > addresses is big enough to ride. > > For /24 allow 2 bits of traffic engineering too. > > Single-homers who won't spend $10k/year on their addresses (smaller > > than /32) must use addresses from their ISP. Tough luck. > > Accept multihomers down to /48. > > The folks paying only $10/year for /56's aren't serious. > > > > Your route filter looks like this: > > > > accept 400e:8000::/24 equal 48 > > accept 400e:0000::/18 equal 40 > > accept 400c::/15 equal 32 > > accept 4008::/14 le 26 > > reject 4000::/12 le 128 > > > > Note how 400e:8000::/24 contains only /48 allocations and you're > > allowing only /48 announcements. Since there aren't any /47 or /46 > > allocations there, nobody in the pool can slip TE routes past you. On > > the other hand, you'll get some benefit of traffic engineering from > > the super-massive /24 registrants up in 4008::/14 because you're > > allowing them to disaggregate down to /26. > > > > Q. If its so expensive to announce routes into the DFZ, why not use > > something better than BGP? > > > > A. In 2008 the IRTF Routing Research Group compiled an exhaustive > > study attempting to identify the possible ways to improve the routing > > system. A draft of the results is at > > http://tools.ietf.org/html/draft-irtf-rrg-recommendation-02 . While > > there are many promising ideas for how to replace BGP with something > > that scales better, we're at least a decade away and probably more > > from any significant deployment of a BGP replacement. > > > > Q. Is it really true that multihoming requires announcing a route via > > BGP? > > > > A. The short answer is yes. The long answer is more complicated. > > > > Folks have tried very hard to devise multi-vendor multihomed systems > > which don't rely on BGP. The only approach that has ever come near > > success is dynamically changing DNS records to favor the currently > > working Internet connection. "Near" is a relative term here. Such > > network architectures are enormously complex and they don't work > > especially well. The DNS protocol itself supports quick changes but > > the applications which use it often don't. It takes hours to achieve > > two-nines recovery from an address change in the DNS and it takes > > months to achieve five-nines recovery. Web browsers, for example, > > don't immediately recover. Search google for "DNS Pinning." > > > > Q. So the Internet's resulting route policy will be to allow all the > > sizes that no major ISP decides to filter and restrict the rest? > > > > A. That's one possible outcome. On the other hand, research in the > > routing field suggests that with a sufficiently rich classification > > scheme, it may be possible to implement lower priority systems with > > provider-independent addresses yet without a global route. Hints for > > how such a thing might work can be found in > > http://www.cs.cornell.edu/people/francis/va-wp.pdf and > > http://bill.herrin.us/network/trrp.html. Such schemes need a rich > > classification process at the address allocation level that makes it > > possible for ISPs to make reasonable and simple decisions about which > > routes should be distributed to every DFZ router and which should not. > > > > Wouldn't that be something: IPv6 provider independent addresses for > > everybody without materially increasing the cost of the routing > > system. > > > > Q. Why allocate the /48's from a pool only for /48's, /32's from a /32 > > pool, etc.? Why not allocate from just one pool? > > > > A. If all assignments in a particular pool are /32 then any route in > > the /32 pool which is longer than /32 is a traffic engineering (TE) > > route. As a router operator you can filter and discard TE routes if > > you find they give you insufficient benefit. The routes you filter > > don't cost you any money; only the routes you keep carry a price tag. > > > > You can only filter if you're sure they're TE routes... If they're > > distinct downstream customer routes and you filter them, there goes > > the Internet. Or at least there goes your part of it. See customers. > > See customers run... straight to your competitor. Setting up the > > distinct pools makes it practical to know with certainty whether the > > routes you're filtering are only for TE. > > > > Q. Why allow only one allocation of each particular size? > > > > A. Without the address scarcity issue which drives IPv4 policy, the > > primary criteria for IPv6 addressing policy is suppressing the > > disaggregation that drives route count in the IPv4 DFZ (NRPM 6.3.8). > > Such a criteria is not well served if an organization holds dozens of > > discontiguous address spaces as a result of acquisitions, mergers and > > and growing a little bit at a time. This proposal says, in effect, > > once you've consumed your smaller allocation it's time for you to get > > a *much* bigger allocation. The rest of us don't want to pay the > > routing table price for you coming back again and again and again. > > > > The proposal could require some renumbering as a result of mergers and > > acquisitions. However, with only modest planning on the registrant's > > part, the policy its flexible enough to allow that renumbering to > > occur over a long period of time so that both cost and disruption are > > minimized. In many cases, customer churn can be expected to take care > > of much of the renumbering activity all by itself. > > > > Q. What about the IETF recommendations? > > > > A. RFC 3177 recommends that ISPs receive a /32 while downstream > > customers receive a /48 assignment by default with so-called "sparse > > allocation" to allow those assignments to expand by changing the > > netmask. While this proposal supports organizations who wish to follow > > those recommendations, it is not this proposal's intention that ARIN > > follow RFC 3177. > > > > RFC 3177 is not the gospel truth. It was written back in 2001 when > > there was little IPv6 outside of academia and, indeed, little IPv6 at > > all. It's an engineers' SWAG about what operations folk should do > > that's now 8-years-stale. > > > > This proposal attempts to slow-start IPv6 allocations instead, while > > still maintaining the principle of suppressing the routing table size. > > As an ISP, consider implementing a slow start for your downstream > > customers as well: Give them a /60 initially, add a /56 when they need > > it and add a /52 when they run out of the /56. A /60 is 16 /64 > > subnets. That's an internal LAN, a DMZ and 14 more subnets. Just how > > many subnets do you think your normal downstream customer will > > actually use? > > > > Q. What happens when organizations merge or split? > > > > A. Entities which merge may renumber out of and return conflicting > > allocations, or they may maintain the existence of the acquired > > organization in order to keep it's addresses. Either way it should be > > a minor hardship. > > > > Entities which split have a bigger problem since the practical effect > > of route filtering may be that only one of them can keep the > > addresses. To a large extent, that problem already exists and is a > > pain in the rump for IPv4 operations today. This policy doesn't solve > > it but it doesn't make it a whole lot worse either. Because > > disaggregates are likely to be filtered, this IPv6 policy does gives > > us a slightly better guarantee that the rest of us won't get stuck > > with the check (in the form of routing slot consumption) when an ISP > > goes bankrupt and gets split up. > > > > Q. What about IPv6 addresses for uses which will not be connected to > > the Internet at all? > > > > A. Folks are welcome to get non-multihomed addresses for any purpose > > whatsoever. If they do eventually decide to connect to the Internet, > > the routes will follow whatever rules the ISPs have imposed for routes > > within the single-homed pools. > > > > Q. What about reporting requirements for downstream assignments? > > > > A. Reporting requirements were instituted for the purpose of verifying > > eligibility for additional allocations. They have proven useful for > > other purposes and the author encourages ARIN to maintain the SWIP > > system. Nevertheless, this proposal renders the use of SWIP for IPv6 > > optional since it is no longer needed to verify eligibility for > > allocations. > > > > Q. What if I need more than a /24? > > > > A. This proposal's author asserts as obvious: anyone who defines a > > need for more than a trillion subnets should make their case publicly > > on PPML, seeking a follow-on proposal that establishes address pools > > at the /16 level. > > > > Q. What are the struck sections of the current IPv6 policy and why > > should they be struck? > > > > A. 6.2.3 - 6.2.9 define terms that have no meaning or use in the > > policy as revised by this proposal. > > > > The 6.4.3 notion of a minimum allocation is obsoleted by the > > allocation pools of specific size in this proposal. > > > > 6.4.4 is moot as this proposal does not expect registrants to justify > > their IPv6 allocation size. > > > > 6.5.1 - 6.5.4 and 6.5.8 are replaced entirely by 6.5.9. > > > > 6.5.5 is largely moot since it's no longer necessary to confirm > > downstream assignments in order to determine eligibility for > > additional addresses. > > > > 6.7 is moot as it is unnecessary to compute utilization to justify > > addresses under this proposal. > > > > 6.9 paragraph 2 is moot since utilization is not a factor in IPv6 > > policy under this proposal. > > > > 6.10 is redundant since micro-allocations are trivially accomplished > > under 6.5.9. > > > > > > Implementation notes: > > > > To prevent wasteful consumption of IPv6 address space without a > > complicated eligibility regime, the author recommends an initial and > > annual fee regime for IPv6 address allocations similar to: > > > > /56 -- $10 USD > > /48 -- $100 USD > > /40 -- $1000 USD > > /32 -- $10,000 USD > > /24 -- $100,000 USD > > Legacy -- the lesser of the cost of the next larger size or the cost > > of the next smaller size times the number encompassed by the > > registration. > > > > The above notwithstanding, it may be advisable to discount /40s and > > /32s to a much lower price during IPv6's general deployment process in > > order to encourage adoption. Folks who already hold /31's should > > probably also get a big break on the $20k fee for a good long while, > > perhaps until the first time they request an additional block without > > offering a plan to return the legacy addresses. > > > > For verification of multihoming, the current way ARIN verifies > > multihoming for other parts of it's policy appears satisfactory. > > Should that change, the author suggests requiring that the AS# > > contacts for at least two AS#'s submit a template indicating that they > > intend to originate or propagate IPv6 BGP routes from the registrant's > > ORG. > > > > Timetable for implementation: immediate > > > > > > > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From warren at wholesaleinternet.com Mon Nov 16 15:29:46 2009 From: warren at wholesaleinternet.com (Warren Johnson) Date: Mon, 16 Nov 2009 14:29:46 -0600 Subject: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process In-Reply-To: <0267B5481DCC474D8088BF4A25C7F1DF55127B074A@XCH-NW-05V.nw.nos.boeing.com> References: <4AF86E15.2060307@arin.net> <4AFE3008.3000904@ibctech.ca> <0267B5481DCC474D8088BF4A25C7F1DF55127B074A@XCH-NW-05V.nw.nos.boeing.com> Message-ID: <7F1CF82C4623478B8F18B392B94CE37E@johnsonvhjjf8v> Stupid question here: why wasn't v6 designed to be backwards compatible with v4? Just not possible? -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Davis, Terry L Sent: Monday, November 16, 2009 2:03 PM To: 'Steve Bertrand'; arin-ppml at arin.net Subject: Re: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process Steve I like it also. One of our biggest problems is that we simply do not have enough really large scale IPv6 deployments around the globe to begin to understand all the problems or to come up with better migration/integration plans between v4 and v6. This should spur more use IPv6; as it is today, not even the green field startups are using v6 and this should tell us something about our current assumptions and policies. In retrospect, by not having a seamless, easy to use method, of allowing v4 to v6 communications, we have made deploying v6 very costly; migrating our millions of v4 based apps to v6 comes with both a huge price tag for opening and dual-stacking them and a corresponding "risk" factor for business continuity associated with that work. Take care Terry > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] > On Behalf Of Steve Bertrand > Sent: Friday, November 13, 2009 8:20 PM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation > Process > > Member Services wrote: > > > Policy Proposal 103: Change IPv6 Allocation Process > > I'm very, very interested in this proposal, and would like to give it > a bump in hopes that it will spur more feedback and discussion than > what it's received thus far. > > Truthfully, I would like to get a feel on the number of people who > like it (I certainly do). If anyone has disregarded or overlooked the > proposal because of the recommended financial figures, please let that > be known as well. > > Complete original proposal message has been left intact below. > > Steve > > > > Proposal Originator: William Herrin > > > > Proposal Version: 1.0 > > > > Date: 9 November 2009 > > > > Proposal type: new > > > > Policy term: permanent. > > > > Policy statement: > > > > Strike NRPM sections: 6.2.3, 6.2.4, 6.2.6-6.2.9, 6.4.3, 6.4.4, > > 6.5.1-6.5.5, 6.5.8, 6.7, 6.10 > > > > Strike NRPM section 6.9 paragraph 2. > > > > Replace 6.2.5 as follows: > > > > 6.2.5 Allocate and Assign > > > > For the purposes of NRPM section 6, allocate and assign are > > synonymous. Both terms describe any or all use identified in section > > 2.5. > > > > Replace 6.5.7 with: > > > > 6.5.7. Existing IPv6 address space holders > > > > Organizations that received IPv6 allocations under the previous IPv6 > > address policy are entitled to either retain those allocations as is > > or trade them in for an allocation under 6.5.9. > > > > Add NRPM section 6.5.9 as follows: > > > > 6.5.9 IPv6 Allocations > > > > 6.5.9.1 ARIN shall allocate IPv6 address blocks in exactly and only > > the following denominations: /56, /48, /40, /32, /24 > > > > 6.5.9.2 No utilization-based eligibility requirements shall apply to > > IPv6 allocations. > > > > 6.5.9.3 ARIN shall accept registration of no more than one address > > block of each size for any single organization. > > > > 6.5.9.4 ARIN shall allocate IPv6 addresses from pools such that the > > identity of the allocation pool serves to classify the expected size > > of allocations within. ISPs may use that classification to filter or > > otherwise manage their routing tables. > > > > 6.5.9.5 For each allocation size, ARIN shall further manage the > > allocation pools such that the pool identity serves to classify > > whether or not the registrant is Multihomed. > > > > 6.5.9.6 ARIN shall offer addresses from pools classified as > > multihomed only to organizations which ARIN has verified are > > multihomed on the public Internet per NRPM 2.7. > > > > 6.5.9.7 Where an organization ceases to be Multihomed it shall > > surrender all address allocations from within pools classified as > > multihomed within 3 months. > > > > > > Rationale: > > > > See the implementation notes section below for what should replace > > utilization-based eligibility. > > > > The existing IPv6 allocation policy under section 6.5 makes a number > > of unproven assumptions about how IPv6 allocations will work. > > > > Unproven: we can make a reasonable guess about how many IPv6 subnets > > an organization will need at the outset when they first request IP > > addresses. When in all of human history has this ever proven true of > > any resource? > > > > Unproven: with sparse allocation, we can allow organizations to > > expand by just changing their subnet mask so that they don't have to > > announce additional routes into the DFZ. This claim is questionable. > > With sparse allocation, we either consume much larger blocks that > > what we assign (so why not just assign the larger block?) or else we > > don't consume them in which case the org either has to renumber to > > expand or he has to announce a second route. Worse, because routes > > of various sizes are all scattered inside the same address space, > > its impractical to filter out the traffic engineering routes. > > > > Unproven: we can force organizations not to disaggregate for traffic > > engineering purposes. Neither any of our experience with IPv4 nor > > any of the research in the IRTF Routing Research Group suggests that > > this is even remotely practical so long as BGP or any similar system > > rules the roost. > > > > Unproven: all non-ISPs can be reasonably expected to get their > > address space from ISPs instead of from ARIN. We can certainly > > operate that way, but it could prove deadly to the routing table. > > Any organization multihomed between two ISPs will need to announce > > that route via BGP, regardless of where they get the address space > > from. We have knobs and dials in the routers that let us easily > > filter disaggregates from distant announcements, but we don't dare > > do so if there is a possibility that one of those disaggregates is a > > multihomed customer rather than traffic engineering. > > > > Benefits of this proposal: > > > > A. Efficient allocation of IP addresses. Orgs get what they need > > when they need it without a great deal of guesswork. > > > > B. Efficient utilization of BGP routing slots. No multihomed orgs > > will announce more than five unfilterable routes, and that only if > > they're so large that they can afford the price tag for the biggest > > address blocks. That's a good thing since IPv6 routes that propagate > > worldwide may impose an annual systemic overhead cost on ISPs of as > > much as US $16,000 each. > > > > C. Traffic engineering routes are trivially filterable. Any route > > longer than the published allocation size can be presumed to be > > traffic engineering, not a downstream multihomed customer, thus you > > can filter distant small routes with confidence and ease. > > > > D. Fair. No need to define the difference between ISP and not ISP. > > Everybody plays by the same rules. > > > > E. No complicated analysis for allocation. You pay for what you want > > and get what you pay for. You're either multihomed or you're not. > > > > F. Gets ARIN out of the business of being the gatekeeper for > > Internet routing policy. By classifying allocations instead of > > making eligibility decisions, ARIN empowers the ISPs to set > > appropriate routing eligibility policies instead. > > > > FAQ > > Q. Isn't this classfull addressing all over again? > > A. Yes. > > Classful addressing had a lot of virtues with respect to route > > filtering and management. We had to abandon it because there weren't > > enough B's for everyone who needed more than one C and there weren't > > enough A's period. With IPv6, we don't have that problem. Not yet > > and maybe not ever. Perhaps we can have our cake and eat it too. > > > > Q. What if I don't want to accept /56 routes for single-homed users? > > > > A. This policy proposal intentionally and fully places backbone > > routing policy in the hands of the ISPs who operate the Internet's > > "Default-Free Zone (DFZ)," colloquially known as the Internet > > backbone. The author expects that some of the allocations, > > especially some of the single-homed allocations, *will not* be > > routable on the public Internet. When we hold a general expectation > > that all of ARIN's allocations will be routable, we effectively mean > > that ARIN decides what the Internet routing policy will be. That's > > precisely the role this proposal removes from ARIN's hands and restores to the ISPs. > > > > Q. Spell it out for me. How exactly will pools and size > > classifications enable route filtering? > > > > A. Suppose ARIN holds 4000::/12. ARIN might split it up as follows: > > > > 4000::/13 -- reserved > > 4008::/15 -- multihomed /24 allocations > > 400a::/15 -- non-multihomed /24 allocations > > 400c::/16 -- multihomed /32 allocations > > 400d::/16 -- non-multihomed /32 allocations > > 400e:0000::/18 -- multihomed /40 allocations > > 400e:4000::/18 -- non-multihomed /40 allocations > > 400e:8000::/24 -- multihomed /48 allocations > > 400e:8100::/24 -- non-multihomed /48 allocations > > 400e:8200::/24 -- multihomed /56 allocations > > 400e:8300::/24 -- non-multihomed /56 allocations > > 400e:8400::/22 -- reserved > > 400e:8800::/21 -- reserved > > 400e:9000::/20 -- reserved > > 400e:a000::/19 -- reserved > > 400e:c000::/18 -- reserved > > 400f::/16 -- reserved > > > > Now, you're an ISP. Here's a sample routing policy you might choose: > > > > Accept any routes to /32 because anyone paying $10k per year for > > addresses is big enough to ride. > > For /24 allow 2 bits of traffic engineering too. > > Single-homers who won't spend $10k/year on their addresses (smaller > > than /32) must use addresses from their ISP. Tough luck. > > Accept multihomers down to /48. > > The folks paying only $10/year for /56's aren't serious. > > > > Your route filter looks like this: > > > > accept 400e:8000::/24 equal 48 > > accept 400e:0000::/18 equal 40 > > accept 400c::/15 equal 32 > > accept 4008::/14 le 26 > > reject 4000::/12 le 128 > > > > Note how 400e:8000::/24 contains only /48 allocations and you're > > allowing only /48 announcements. Since there aren't any /47 or /46 > > allocations there, nobody in the pool can slip TE routes past you. > > On the other hand, you'll get some benefit of traffic engineering > > from the super-massive /24 registrants up in 4008::/14 because > > you're allowing them to disaggregate down to /26. > > > > Q. If its so expensive to announce routes into the DFZ, why not use > > something better than BGP? > > > > A. In 2008 the IRTF Routing Research Group compiled an exhaustive > > study attempting to identify the possible ways to improve the > > routing system. A draft of the results is at > > http://tools.ietf.org/html/draft-irtf-rrg-recommendation-02 . While > > there are many promising ideas for how to replace BGP with something > > that scales better, we're at least a decade away and probably more > > from any significant deployment of a BGP replacement. > > > > Q. Is it really true that multihoming requires announcing a route > > via BGP? > > > > A. The short answer is yes. The long answer is more complicated. > > > > Folks have tried very hard to devise multi-vendor multihomed systems > > which don't rely on BGP. The only approach that has ever come near > > success is dynamically changing DNS records to favor the currently > > working Internet connection. "Near" is a relative term here. Such > > network architectures are enormously complex and they don't work > > especially well. The DNS protocol itself supports quick changes but > > the applications which use it often don't. It takes hours to achieve > > two-nines recovery from an address change in the DNS and it takes > > months to achieve five-nines recovery. Web browsers, for example, > > don't immediately recover. Search google for "DNS Pinning." > > > > Q. So the Internet's resulting route policy will be to allow all the > > sizes that no major ISP decides to filter and restrict the rest? > > > > A. That's one possible outcome. On the other hand, research in the > > routing field suggests that with a sufficiently rich classification > > scheme, it may be possible to implement lower priority systems with > > provider-independent addresses yet without a global route. Hints for > > how such a thing might work can be found in > > http://www.cs.cornell.edu/people/francis/va-wp.pdf and > > http://bill.herrin.us/network/trrp.html. Such schemes need a rich > > classification process at the address allocation level that makes it > > possible for ISPs to make reasonable and simple decisions about > > which routes should be distributed to every DFZ router and which should not. > > > > Wouldn't that be something: IPv6 provider independent addresses for > > everybody without materially increasing the cost of the routing > > system. > > > > Q. Why allocate the /48's from a pool only for /48's, /32's from a > > /32 pool, etc.? Why not allocate from just one pool? > > > > A. If all assignments in a particular pool are /32 then any route in > > the /32 pool which is longer than /32 is a traffic engineering (TE) > > route. As a router operator you can filter and discard TE routes if > > you find they give you insufficient benefit. The routes you filter > > don't cost you any money; only the routes you keep carry a price tag. > > > > You can only filter if you're sure they're TE routes... If they're > > distinct downstream customer routes and you filter them, there goes > > the Internet. Or at least there goes your part of it. See customers. > > See customers run... straight to your competitor. Setting up the > > distinct pools makes it practical to know with certainty whether the > > routes you're filtering are only for TE. > > > > Q. Why allow only one allocation of each particular size? > > > > A. Without the address scarcity issue which drives IPv4 policy, the > > primary criteria for IPv6 addressing policy is suppressing the > > disaggregation that drives route count in the IPv4 DFZ (NRPM 6.3.8). > > Such a criteria is not well served if an organization holds dozens > > of discontiguous address spaces as a result of acquisitions, mergers > > and and growing a little bit at a time. This proposal says, in > > effect, once you've consumed your smaller allocation it's time for > > you to get a *much* bigger allocation. The rest of us don't want to > > pay the routing table price for you coming back again and again and again. > > > > The proposal could require some renumbering as a result of mergers > > and acquisitions. However, with only modest planning on the > > registrant's part, the policy its flexible enough to allow that > > renumbering to occur over a long period of time so that both cost > > and disruption are minimized. In many cases, customer churn can be > > expected to take care of much of the renumbering activity all by itself. > > > > Q. What about the IETF recommendations? > > > > A. RFC 3177 recommends that ISPs receive a /32 while downstream > > customers receive a /48 assignment by default with so-called "sparse > > allocation" to allow those assignments to expand by changing the > > netmask. While this proposal supports organizations who wish to > > follow those recommendations, it is not this proposal's intention > > that ARIN follow RFC 3177. > > > > RFC 3177 is not the gospel truth. It was written back in 2001 when > > there was little IPv6 outside of academia and, indeed, little IPv6 > > at all. It's an engineers' SWAG about what operations folk should do > > that's now 8-years-stale. > > > > This proposal attempts to slow-start IPv6 allocations instead, while > > still maintaining the principle of suppressing the routing table size. > > As an ISP, consider implementing a slow start for your downstream > > customers as well: Give them a /60 initially, add a /56 when they > > need it and add a /52 when they run out of the /56. A /60 is 16 /64 > > subnets. That's an internal LAN, a DMZ and 14 more subnets. Just how > > many subnets do you think your normal downstream customer will > > actually use? > > > > Q. What happens when organizations merge or split? > > > > A. Entities which merge may renumber out of and return conflicting > > allocations, or they may maintain the existence of the acquired > > organization in order to keep it's addresses. Either way it should > > be a minor hardship. > > > > Entities which split have a bigger problem since the practical > > effect of route filtering may be that only one of them can keep the > > addresses. To a large extent, that problem already exists and is a > > pain in the rump for IPv4 operations today. This policy doesn't > > solve it but it doesn't make it a whole lot worse either. Because > > disaggregates are likely to be filtered, this IPv6 policy does gives > > us a slightly better guarantee that the rest of us won't get stuck > > with the check (in the form of routing slot consumption) when an ISP > > goes bankrupt and gets split up. > > > > Q. What about IPv6 addresses for uses which will not be connected > > to the Internet at all? > > > > A. Folks are welcome to get non-multihomed addresses for any purpose > > whatsoever. If they do eventually decide to connect to the Internet, > > the routes will follow whatever rules the ISPs have imposed for > > routes within the single-homed pools. > > > > Q. What about reporting requirements for downstream assignments? > > > > A. Reporting requirements were instituted for the purpose of > > verifying eligibility for additional allocations. They have proven > > useful for other purposes and the author encourages ARIN to maintain > > the SWIP system. Nevertheless, this proposal renders the use of SWIP > > for IPv6 optional since it is no longer needed to verify eligibility > > for allocations. > > > > Q. What if I need more than a /24? > > > > A. This proposal's author asserts as obvious: anyone who defines a > > need for more than a trillion subnets should make their case > > publicly on PPML, seeking a follow-on proposal that establishes > > address pools at the /16 level. > > > > Q. What are the struck sections of the current IPv6 policy and why > > should they be struck? > > > > A. 6.2.3 - 6.2.9 define terms that have no meaning or use in the > > policy as revised by this proposal. > > > > The 6.4.3 notion of a minimum allocation is obsoleted by the > > allocation pools of specific size in this proposal. > > > > 6.4.4 is moot as this proposal does not expect registrants to > > justify their IPv6 allocation size. > > > > 6.5.1 - 6.5.4 and 6.5.8 are replaced entirely by 6.5.9. > > > > 6.5.5 is largely moot since it's no longer necessary to confirm > > downstream assignments in order to determine eligibility for > > additional addresses. > > > > 6.7 is moot as it is unnecessary to compute utilization to justify > > addresses under this proposal. > > > > 6.9 paragraph 2 is moot since utilization is not a factor in IPv6 > > policy under this proposal. > > > > 6.10 is redundant since micro-allocations are trivially accomplished > > under 6.5.9. > > > > > > Implementation notes: > > > > To prevent wasteful consumption of IPv6 address space without a > > complicated eligibility regime, the author recommends an initial and > > annual fee regime for IPv6 address allocations similar to: > > > > /56 -- $10 USD > > /48 -- $100 USD > > /40 -- $1000 USD > > /32 -- $10,000 USD > > /24 -- $100,000 USD > > Legacy -- the lesser of the cost of the next larger size or the cost > > of the next smaller size times the number encompassed by the > > registration. > > > > The above notwithstanding, it may be advisable to discount /40s and > > /32s to a much lower price during IPv6's general deployment process > > in order to encourage adoption. Folks who already hold /31's should > > probably also get a big break on the $20k fee for a good long while, > > perhaps until the first time they request an additional block > > without offering a plan to return the legacy addresses. > > > > For verification of multihoming, the current way ARIN verifies > > multihoming for other parts of it's policy appears satisfactory. > > Should that change, the author suggests requiring that the AS# > > contacts for at least two AS#'s submit a template indicating that > > they intend to originate or propagate IPv6 BGP routes from the > > registrant's ORG. > > > > Timetable for implementation: immediate > > > > > > > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to the > > ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From terry.l.davis at boeing.com Mon Nov 16 15:50:05 2009 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Mon, 16 Nov 2009 12:50:05 -0800 Subject: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process In-Reply-To: <7F1CF82C4623478B8F18B392B94CE37E@johnsonvhjjf8v> References: <4AF86E15.2060307@arin.net> <4AFE3008.3000904@ibctech.ca><0267B5481DCC474D8088BF4A25C7F1DF55127B074A@XCH-NW-05V.nw.nos.boeing.com> <7F1CF82C4623478B8F18B392B94CE37E@johnsonvhjjf8v> Message-ID: <0267B5481DCC474D8088BF4A25C7F1DF55127B074B@XCH-NW-05V.nw.nos.boeing.com> Warren My answer would be "we didn't have enough software types in the room during the discussions on creating v6" to point out the implications of that fact. Although a long term v6 advocate, I did not fully realize what we had done to ourselves till I did a Master's project paper on v6 migration a few years ago. After doing that, I realized that with current transition technologies, we end up with an ugly v4-v6 transition layer consisting of many different v4-v6 technologies (and some at the individual app level) in our IT infrastructure architecture for probably decades. And that layer also has very severe implications for an IT security infrastructure. If we had a simple straight forward transition mechanism, v6 would have taken off years ago. Hindsight is 20-20; foresight though isn't (maybe 20-2000). Take care Terry > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Warren Johnson > Sent: Monday, November 16, 2009 12:30 PM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation > Process > > Stupid question here: why wasn't v6 designed to be backwards compatible > with > v4? Just not possible? > > > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Davis, Terry L > Sent: Monday, November 16, 2009 2:03 PM > To: 'Steve Bertrand'; arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation > Process > > Steve > > I like it also. One of our biggest problems is that we simply do not have > enough really large scale IPv6 deployments around the globe to begin to > understand all the problems or to come up with better > migration/integration > plans between v4 and v6. This should spur more use IPv6; as it is today, > not even the green field startups are using v6 and this should tell us > something about our current assumptions and policies. > > In retrospect, by not having a seamless, easy to use method, of allowing > v4 > to v6 communications, we have made deploying v6 very costly; migrating our > millions of v4 based apps to v6 comes with both a huge price tag for > opening > and dual-stacking them and a corresponding "risk" factor for business > continuity associated with that work. > > Take care > Terry > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] > > On Behalf Of Steve Bertrand > > Sent: Friday, November 13, 2009 8:20 PM > > To: arin-ppml at arin.net > > Subject: Re: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation > > Process > > > > Member Services wrote: > > > > > Policy Proposal 103: Change IPv6 Allocation Process > > > > I'm very, very interested in this proposal, and would like to give it > > a bump in hopes that it will spur more feedback and discussion than > > what it's received thus far. > > > > Truthfully, I would like to get a feel on the number of people who > > like it (I certainly do). If anyone has disregarded or overlooked the > > proposal because of the recommended financial figures, please let that > > be known as well. > > > > Complete original proposal message has been left intact below. > > > > Steve > > > > > > > Proposal Originator: William Herrin > > > > > > Proposal Version: 1.0 > > > > > > Date: 9 November 2009 > > > > > > Proposal type: new > > > > > > Policy term: permanent. > > > > > > Policy statement: > > > > > > Strike NRPM sections: 6.2.3, 6.2.4, 6.2.6-6.2.9, 6.4.3, 6.4.4, > > > 6.5.1-6.5.5, 6.5.8, 6.7, 6.10 > > > > > > Strike NRPM section 6.9 paragraph 2. > > > > > > Replace 6.2.5 as follows: > > > > > > 6.2.5 Allocate and Assign > > > > > > For the purposes of NRPM section 6, allocate and assign are > > > synonymous. Both terms describe any or all use identified in section > > > 2.5. > > > > > > Replace 6.5.7 with: > > > > > > 6.5.7. Existing IPv6 address space holders > > > > > > Organizations that received IPv6 allocations under the previous IPv6 > > > address policy are entitled to either retain those allocations as is > > > or trade them in for an allocation under 6.5.9. > > > > > > Add NRPM section 6.5.9 as follows: > > > > > > 6.5.9 IPv6 Allocations > > > > > > 6.5.9.1 ARIN shall allocate IPv6 address blocks in exactly and only > > > the following denominations: /56, /48, /40, /32, /24 > > > > > > 6.5.9.2 No utilization-based eligibility requirements shall apply to > > > IPv6 allocations. > > > > > > 6.5.9.3 ARIN shall accept registration of no more than one address > > > block of each size for any single organization. > > > > > > 6.5.9.4 ARIN shall allocate IPv6 addresses from pools such that the > > > identity of the allocation pool serves to classify the expected size > > > of allocations within. ISPs may use that classification to filter or > > > otherwise manage their routing tables. > > > > > > 6.5.9.5 For each allocation size, ARIN shall further manage the > > > allocation pools such that the pool identity serves to classify > > > whether or not the registrant is Multihomed. > > > > > > 6.5.9.6 ARIN shall offer addresses from pools classified as > > > multihomed only to organizations which ARIN has verified are > > > multihomed on the public Internet per NRPM 2.7. > > > > > > 6.5.9.7 Where an organization ceases to be Multihomed it shall > > > surrender all address allocations from within pools classified as > > > multihomed within 3 months. > > > > > > > > > Rationale: > > > > > > See the implementation notes section below for what should replace > > > utilization-based eligibility. > > > > > > The existing IPv6 allocation policy under section 6.5 makes a number > > > of unproven assumptions about how IPv6 allocations will work. > > > > > > Unproven: we can make a reasonable guess about how many IPv6 subnets > > > an organization will need at the outset when they first request IP > > > addresses. When in all of human history has this ever proven true of > > > any resource? > > > > > > Unproven: with sparse allocation, we can allow organizations to > > > expand by just changing their subnet mask so that they don't have to > > > announce additional routes into the DFZ. This claim is questionable. > > > With sparse allocation, we either consume much larger blocks that > > > what we assign (so why not just assign the larger block?) or else we > > > don't consume them in which case the org either has to renumber to > > > expand or he has to announce a second route. Worse, because routes > > > of various sizes are all scattered inside the same address space, > > > its impractical to filter out the traffic engineering routes. > > > > > > Unproven: we can force organizations not to disaggregate for traffic > > > engineering purposes. Neither any of our experience with IPv4 nor > > > any of the research in the IRTF Routing Research Group suggests that > > > this is even remotely practical so long as BGP or any similar system > > > rules the roost. > > > > > > Unproven: all non-ISPs can be reasonably expected to get their > > > address space from ISPs instead of from ARIN. We can certainly > > > operate that way, but it could prove deadly to the routing table. > > > Any organization multihomed between two ISPs will need to announce > > > that route via BGP, regardless of where they get the address space > > > from. We have knobs and dials in the routers that let us easily > > > filter disaggregates from distant announcements, but we don't dare > > > do so if there is a possibility that one of those disaggregates is a > > > multihomed customer rather than traffic engineering. > > > > > > Benefits of this proposal: > > > > > > A. Efficient allocation of IP addresses. Orgs get what they need > > > when they need it without a great deal of guesswork. > > > > > > B. Efficient utilization of BGP routing slots. No multihomed orgs > > > will announce more than five unfilterable routes, and that only if > > > they're so large that they can afford the price tag for the biggest > > > address blocks. That's a good thing since IPv6 routes that propagate > > > worldwide may impose an annual systemic overhead cost on ISPs of as > > > much as US $16,000 each. > > > > > > C. Traffic engineering routes are trivially filterable. Any route > > > longer than the published allocation size can be presumed to be > > > traffic engineering, not a downstream multihomed customer, thus you > > > can filter distant small routes with confidence and ease. > > > > > > D. Fair. No need to define the difference between ISP and not ISP. > > > Everybody plays by the same rules. > > > > > > E. No complicated analysis for allocation. You pay for what you want > > > and get what you pay for. You're either multihomed or you're not. > > > > > > F. Gets ARIN out of the business of being the gatekeeper for > > > Internet routing policy. By classifying allocations instead of > > > making eligibility decisions, ARIN empowers the ISPs to set > > > appropriate routing eligibility policies instead. > > > > > > FAQ > > > Q. Isn't this classfull addressing all over again? > > > A. Yes. > > > Classful addressing had a lot of virtues with respect to route > > > filtering and management. We had to abandon it because there weren't > > > enough B's for everyone who needed more than one C and there weren't > > > enough A's period. With IPv6, we don't have that problem. Not yet > > > and maybe not ever. Perhaps we can have our cake and eat it too. > > > > > > Q. What if I don't want to accept /56 routes for single-homed users? > > > > > > A. This policy proposal intentionally and fully places backbone > > > routing policy in the hands of the ISPs who operate the Internet's > > > "Default-Free Zone (DFZ)," colloquially known as the Internet > > > backbone. The author expects that some of the allocations, > > > especially some of the single-homed allocations, *will not* be > > > routable on the public Internet. When we hold a general expectation > > > that all of ARIN's allocations will be routable, we effectively mean > > > that ARIN decides what the Internet routing policy will be. That's > > > precisely the role this proposal removes from ARIN's hands and > restores > to the ISPs. > > > > > > Q. Spell it out for me. How exactly will pools and size > > > classifications enable route filtering? > > > > > > A. Suppose ARIN holds 4000::/12. ARIN might split it up as follows: > > > > > > 4000::/13 -- reserved > > > 4008::/15 -- multihomed /24 allocations > > > 400a::/15 -- non-multihomed /24 allocations > > > 400c::/16 -- multihomed /32 allocations > > > 400d::/16 -- non-multihomed /32 allocations > > > 400e:0000::/18 -- multihomed /40 allocations > > > 400e:4000::/18 -- non-multihomed /40 allocations > > > 400e:8000::/24 -- multihomed /48 allocations > > > 400e:8100::/24 -- non-multihomed /48 allocations > > > 400e:8200::/24 -- multihomed /56 allocations > > > 400e:8300::/24 -- non-multihomed /56 allocations > > > 400e:8400::/22 -- reserved > > > 400e:8800::/21 -- reserved > > > 400e:9000::/20 -- reserved > > > 400e:a000::/19 -- reserved > > > 400e:c000::/18 -- reserved > > > 400f::/16 -- reserved > > > > > > Now, you're an ISP. Here's a sample routing policy you might choose: > > > > > > Accept any routes to /32 because anyone paying $10k per year for > > > addresses is big enough to ride. > > > For /24 allow 2 bits of traffic engineering too. > > > Single-homers who won't spend $10k/year on their addresses (smaller > > > than /32) must use addresses from their ISP. Tough luck. > > > Accept multihomers down to /48. > > > The folks paying only $10/year for /56's aren't serious. > > > > > > Your route filter looks like this: > > > > > > accept 400e:8000::/24 equal 48 > > > accept 400e:0000::/18 equal 40 > > > accept 400c::/15 equal 32 > > > accept 4008::/14 le 26 > > > reject 4000::/12 le 128 > > > > > > Note how 400e:8000::/24 contains only /48 allocations and you're > > > allowing only /48 announcements. Since there aren't any /47 or /46 > > > allocations there, nobody in the pool can slip TE routes past you. > > > On the other hand, you'll get some benefit of traffic engineering > > > from the super-massive /24 registrants up in 4008::/14 because > > > you're allowing them to disaggregate down to /26. > > > > > > Q. If its so expensive to announce routes into the DFZ, why not use > > > something better than BGP? > > > > > > A. In 2008 the IRTF Routing Research Group compiled an exhaustive > > > study attempting to identify the possible ways to improve the > > > routing system. A draft of the results is at > > > http://tools.ietf.org/html/draft-irtf-rrg-recommendation-02 . While > > > there are many promising ideas for how to replace BGP with something > > > that scales better, we're at least a decade away and probably more > > > from any significant deployment of a BGP replacement. > > > > > > Q. Is it really true that multihoming requires announcing a route > > > via BGP? > > > > > > A. The short answer is yes. The long answer is more complicated. > > > > > > Folks have tried very hard to devise multi-vendor multihomed systems > > > which don't rely on BGP. The only approach that has ever come near > > > success is dynamically changing DNS records to favor the currently > > > working Internet connection. "Near" is a relative term here. Such > > > network architectures are enormously complex and they don't work > > > especially well. The DNS protocol itself supports quick changes but > > > the applications which use it often don't. It takes hours to achieve > > > two-nines recovery from an address change in the DNS and it takes > > > months to achieve five-nines recovery. Web browsers, for example, > > > don't immediately recover. Search google for "DNS Pinning." > > > > > > Q. So the Internet's resulting route policy will be to allow all the > > > sizes that no major ISP decides to filter and restrict the rest? > > > > > > A. That's one possible outcome. On the other hand, research in the > > > routing field suggests that with a sufficiently rich classification > > > scheme, it may be possible to implement lower priority systems with > > > provider-independent addresses yet without a global route. Hints for > > > how such a thing might work can be found in > > > http://www.cs.cornell.edu/people/francis/va-wp.pdf and > > > http://bill.herrin.us/network/trrp.html. Such schemes need a rich > > > classification process at the address allocation level that makes it > > > possible for ISPs to make reasonable and simple decisions about > > > which routes should be distributed to every DFZ router and which > should > not. > > > > > > Wouldn't that be something: IPv6 provider independent addresses for > > > everybody without materially increasing the cost of the routing > > > system. > > > > > > Q. Why allocate the /48's from a pool only for /48's, /32's from a > > > /32 pool, etc.? Why not allocate from just one pool? > > > > > > A. If all assignments in a particular pool are /32 then any route in > > > the /32 pool which is longer than /32 is a traffic engineering (TE) > > > route. As a router operator you can filter and discard TE routes if > > > you find they give you insufficient benefit. The routes you filter > > > don't cost you any money; only the routes you keep carry a price tag. > > > > > > You can only filter if you're sure they're TE routes... If they're > > > distinct downstream customer routes and you filter them, there goes > > > the Internet. Or at least there goes your part of it. See customers. > > > See customers run... straight to your competitor. Setting up the > > > distinct pools makes it practical to know with certainty whether the > > > routes you're filtering are only for TE. > > > > > > Q. Why allow only one allocation of each particular size? > > > > > > A. Without the address scarcity issue which drives IPv4 policy, the > > > primary criteria for IPv6 addressing policy is suppressing the > > > disaggregation that drives route count in the IPv4 DFZ (NRPM 6.3.8). > > > Such a criteria is not well served if an organization holds dozens > > > of discontiguous address spaces as a result of acquisitions, mergers > > > and and growing a little bit at a time. This proposal says, in > > > effect, once you've consumed your smaller allocation it's time for > > > you to get a *much* bigger allocation. The rest of us don't want to > > > pay the routing table price for you coming back again and again and > again. > > > > > > The proposal could require some renumbering as a result of mergers > > > and acquisitions. However, with only modest planning on the > > > registrant's part, the policy its flexible enough to allow that > > > renumbering to occur over a long period of time so that both cost > > > and disruption are minimized. In many cases, customer churn can be > > > expected to take care of much of the renumbering activity all by > itself. > > > > > > Q. What about the IETF recommendations? > > > > > > A. RFC 3177 recommends that ISPs receive a /32 while downstream > > > customers receive a /48 assignment by default with so-called "sparse > > > allocation" to allow those assignments to expand by changing the > > > netmask. While this proposal supports organizations who wish to > > > follow those recommendations, it is not this proposal's intention > > > that ARIN follow RFC 3177. > > > > > > RFC 3177 is not the gospel truth. It was written back in 2001 when > > > there was little IPv6 outside of academia and, indeed, little IPv6 > > > at all. It's an engineers' SWAG about what operations folk should do > > > that's now 8-years-stale. > > > > > > This proposal attempts to slow-start IPv6 allocations instead, while > > > still maintaining the principle of suppressing the routing table size. > > > As an ISP, consider implementing a slow start for your downstream > > > customers as well: Give them a /60 initially, add a /56 when they > > > need it and add a /52 when they run out of the /56. A /60 is 16 /64 > > > subnets. That's an internal LAN, a DMZ and 14 more subnets. Just how > > > many subnets do you think your normal downstream customer will > > > actually use? > > > > > > Q. What happens when organizations merge or split? > > > > > > A. Entities which merge may renumber out of and return conflicting > > > allocations, or they may maintain the existence of the acquired > > > organization in order to keep it's addresses. Either way it should > > > be a minor hardship. > > > > > > Entities which split have a bigger problem since the practical > > > effect of route filtering may be that only one of them can keep the > > > addresses. To a large extent, that problem already exists and is a > > > pain in the rump for IPv4 operations today. This policy doesn't > > > solve it but it doesn't make it a whole lot worse either. Because > > > disaggregates are likely to be filtered, this IPv6 policy does gives > > > us a slightly better guarantee that the rest of us won't get stuck > > > with the check (in the form of routing slot consumption) when an ISP > > > goes bankrupt and gets split up. > > > > > > Q. What about IPv6 addresses for uses which will not be connected > > > to the Internet at all? > > > > > > A. Folks are welcome to get non-multihomed addresses for any purpose > > > whatsoever. If they do eventually decide to connect to the Internet, > > > the routes will follow whatever rules the ISPs have imposed for > > > routes within the single-homed pools. > > > > > > Q. What about reporting requirements for downstream assignments? > > > > > > A. Reporting requirements were instituted for the purpose of > > > verifying eligibility for additional allocations. They have proven > > > useful for other purposes and the author encourages ARIN to maintain > > > the SWIP system. Nevertheless, this proposal renders the use of SWIP > > > for IPv6 optional since it is no longer needed to verify eligibility > > > for allocations. > > > > > > Q. What if I need more than a /24? > > > > > > A. This proposal's author asserts as obvious: anyone who defines a > > > need for more than a trillion subnets should make their case > > > publicly on PPML, seeking a follow-on proposal that establishes > > > address pools at the /16 level. > > > > > > Q. What are the struck sections of the current IPv6 policy and why > > > should they be struck? > > > > > > A. 6.2.3 - 6.2.9 define terms that have no meaning or use in the > > > policy as revised by this proposal. > > > > > > The 6.4.3 notion of a minimum allocation is obsoleted by the > > > allocation pools of specific size in this proposal. > > > > > > 6.4.4 is moot as this proposal does not expect registrants to > > > justify their IPv6 allocation size. > > > > > > 6.5.1 - 6.5.4 and 6.5.8 are replaced entirely by 6.5.9. > > > > > > 6.5.5 is largely moot since it's no longer necessary to confirm > > > downstream assignments in order to determine eligibility for > > > additional addresses. > > > > > > 6.7 is moot as it is unnecessary to compute utilization to justify > > > addresses under this proposal. > > > > > > 6.9 paragraph 2 is moot since utilization is not a factor in IPv6 > > > policy under this proposal. > > > > > > 6.10 is redundant since micro-allocations are trivially accomplished > > > under 6.5.9. > > > > > > > > > Implementation notes: > > > > > > To prevent wasteful consumption of IPv6 address space without a > > > complicated eligibility regime, the author recommends an initial and > > > annual fee regime for IPv6 address allocations similar to: > > > > > > /56 -- $10 USD > > > /48 -- $100 USD > > > /40 -- $1000 USD > > > /32 -- $10,000 USD > > > /24 -- $100,000 USD > > > Legacy -- the lesser of the cost of the next larger size or the cost > > > of the next smaller size times the number encompassed by the > > > registration. > > > > > > The above notwithstanding, it may be advisable to discount /40s and > > > /32s to a much lower price during IPv6's general deployment process > > > in order to encourage adoption. Folks who already hold /31's should > > > probably also get a big break on the $20k fee for a good long while, > > > perhaps until the first time they request an additional block > > > without offering a plan to return the legacy addresses. > > > > > > For verification of multihoming, the current way ARIN verifies > > > multihoming for other parts of it's policy appears satisfactory. > > > Should that change, the author suggests requiring that the AS# > > > contacts for at least two AS#'s submit a template indicating that > > > they intend to originate or propagate IPv6 BGP routes from the > > > registrant's ORG. > > > > > > Timetable for implementation: immediate > > > > > > > > > > > > > > > _______________________________________________ > > > PPML > > > You are receiving this message because you are subscribed to the > > > ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > > Unsubscribe or manage your mailing list subscription at: > > > http://lists.arin.net/mailman/listinfo/arin-ppml > > > Please contact info at arin.net if you experience any issues. > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to the ARIN > > Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public > Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From warren at wholesaleinternet.com Mon Nov 16 15:54:11 2009 From: warren at wholesaleinternet.com (Warren Johnson) Date: Mon, 16 Nov 2009 14:54:11 -0600 Subject: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process In-Reply-To: <0267B5481DCC474D8088BF4A25C7F1DF55127B074B@XCH-NW-05V.nw.nos.boeing.com> References: <4AF86E15.2060307@arin.net> <4AFE3008.3000904@ibctech.ca><0267B5481DCC474D8088BF4A25C7F1DF55127B074A@XCH-NW-05V.nw.nos.boeing.com> <7F1CF82C4623478B8F18B392B94CE37E@johnsonvhjjf8v> <0267B5481DCC474D8088BF4A25C7F1DF55127B074B@XCH-NW-05V.nw.nos.boeing.com> Message-ID: <339F6302D15646D9A29EE3CFF0CF3310@johnsonvhjjf8v> Instead of spending the next two decades trying to get people migrated over maybe we should just scrap v6 and create "v7" and make it backwards compatible with v4. I guess we're not at that point yet because we just don't know what's going to happen post-runout. -----Original Message----- From: Davis, Terry L [mailto:terry.l.davis at boeing.com] Sent: Monday, November 16, 2009 2:50 PM To: 'Warren Johnson'; arin-ppml at arin.net Subject: RE: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process Warren My answer would be "we didn't have enough software types in the room during the discussions on creating v6" to point out the implications of that fact. Although a long term v6 advocate, I did not fully realize what we had done to ourselves till I did a Master's project paper on v6 migration a few years ago. After doing that, I realized that with current transition technologies, we end up with an ugly v4-v6 transition layer consisting of many different v4-v6 technologies (and some at the individual app level) in our IT infrastructure architecture for probably decades. And that layer also has very severe implications for an IT security infrastructure. If we had a simple straight forward transition mechanism, v6 would have taken off years ago. Hindsight is 20-20; foresight though isn't (maybe 20-2000). Take care Terry > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] > On Behalf Of Warren Johnson > Sent: Monday, November 16, 2009 12:30 PM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation > Process > > Stupid question here: why wasn't v6 designed to be backwards > compatible with v4? Just not possible? > > > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] > On Behalf Of Davis, Terry L > Sent: Monday, November 16, 2009 2:03 PM > To: 'Steve Bertrand'; arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation > Process > > Steve > > I like it also. One of our biggest problems is that we simply do not > have enough really large scale IPv6 deployments around the globe to > begin to understand all the problems or to come up with better > migration/integration plans between v4 and v6. This should spur more > use IPv6; as it is today, not even the green field startups are using > v6 and this should tell us something about our current assumptions and > policies. > > In retrospect, by not having a seamless, easy to use method, of > allowing > v4 > to v6 communications, we have made deploying v6 very costly; migrating > our millions of v4 based apps to v6 comes with both a huge price tag > for opening and dual-stacking them and a corresponding "risk" factor > for business continuity associated with that work. > > Take care > Terry > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] > > On Behalf Of Steve Bertrand > > Sent: Friday, November 13, 2009 8:20 PM > > To: arin-ppml at arin.net > > Subject: Re: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation > > Process > > > > Member Services wrote: > > > > > Policy Proposal 103: Change IPv6 Allocation Process > > > > I'm very, very interested in this proposal, and would like to give > > it a bump in hopes that it will spur more feedback and discussion > > than what it's received thus far. > > > > Truthfully, I would like to get a feel on the number of people who > > like it (I certainly do). If anyone has disregarded or overlooked > > the proposal because of the recommended financial figures, please > > let that be known as well. > > > > Complete original proposal message has been left intact below. > > > > Steve > > > > > > > Proposal Originator: William Herrin > > > > > > Proposal Version: 1.0 > > > > > > Date: 9 November 2009 > > > > > > Proposal type: new > > > > > > Policy term: permanent. > > > > > > Policy statement: > > > > > > Strike NRPM sections: 6.2.3, 6.2.4, 6.2.6-6.2.9, 6.4.3, 6.4.4, > > > 6.5.1-6.5.5, 6.5.8, 6.7, 6.10 > > > > > > Strike NRPM section 6.9 paragraph 2. > > > > > > Replace 6.2.5 as follows: > > > > > > 6.2.5 Allocate and Assign > > > > > > For the purposes of NRPM section 6, allocate and assign are > > > synonymous. Both terms describe any or all use identified in > > > section 2.5. > > > > > > Replace 6.5.7 with: > > > > > > 6.5.7. Existing IPv6 address space holders > > > > > > Organizations that received IPv6 allocations under the previous > > > IPv6 address policy are entitled to either retain those > > > allocations as is or trade them in for an allocation under 6.5.9. > > > > > > Add NRPM section 6.5.9 as follows: > > > > > > 6.5.9 IPv6 Allocations > > > > > > 6.5.9.1 ARIN shall allocate IPv6 address blocks in exactly and > > > only the following denominations: /56, /48, /40, /32, /24 > > > > > > 6.5.9.2 No utilization-based eligibility requirements shall apply > > > to > > > IPv6 allocations. > > > > > > 6.5.9.3 ARIN shall accept registration of no more than one address > > > block of each size for any single organization. > > > > > > 6.5.9.4 ARIN shall allocate IPv6 addresses from pools such that > > > the identity of the allocation pool serves to classify the > > > expected size of allocations within. ISPs may use that > > > classification to filter or otherwise manage their routing tables. > > > > > > 6.5.9.5 For each allocation size, ARIN shall further manage the > > > allocation pools such that the pool identity serves to classify > > > whether or not the registrant is Multihomed. > > > > > > 6.5.9.6 ARIN shall offer addresses from pools classified as > > > multihomed only to organizations which ARIN has verified are > > > multihomed on the public Internet per NRPM 2.7. > > > > > > 6.5.9.7 Where an organization ceases to be Multihomed it shall > > > surrender all address allocations from within pools classified as > > > multihomed within 3 months. > > > > > > > > > Rationale: > > > > > > See the implementation notes section below for what should replace > > > utilization-based eligibility. > > > > > > The existing IPv6 allocation policy under section 6.5 makes a > > > number of unproven assumptions about how IPv6 allocations will work. > > > > > > Unproven: we can make a reasonable guess about how many IPv6 > > > subnets an organization will need at the outset when they first > > > request IP addresses. When in all of human history has this ever > > > proven true of any resource? > > > > > > Unproven: with sparse allocation, we can allow organizations to > > > expand by just changing their subnet mask so that they don't have > > > to announce additional routes into the DFZ. This claim is questionable. > > > With sparse allocation, we either consume much larger blocks that > > > what we assign (so why not just assign the larger block?) or else > > > we don't consume them in which case the org either has to renumber > > > to expand or he has to announce a second route. Worse, because > > > routes of various sizes are all scattered inside the same address > > > space, its impractical to filter out the traffic engineering routes. > > > > > > Unproven: we can force organizations not to disaggregate for > > > traffic engineering purposes. Neither any of our experience with > > > IPv4 nor any of the research in the IRTF Routing Research Group > > > suggests that this is even remotely practical so long as BGP or > > > any similar system rules the roost. > > > > > > Unproven: all non-ISPs can be reasonably expected to get their > > > address space from ISPs instead of from ARIN. We can certainly > > > operate that way, but it could prove deadly to the routing table. > > > Any organization multihomed between two ISPs will need to announce > > > that route via BGP, regardless of where they get the address space > > > from. We have knobs and dials in the routers that let us easily > > > filter disaggregates from distant announcements, but we don't dare > > > do so if there is a possibility that one of those disaggregates is > > > a multihomed customer rather than traffic engineering. > > > > > > Benefits of this proposal: > > > > > > A. Efficient allocation of IP addresses. Orgs get what they need > > > when they need it without a great deal of guesswork. > > > > > > B. Efficient utilization of BGP routing slots. No multihomed orgs > > > will announce more than five unfilterable routes, and that only if > > > they're so large that they can afford the price tag for the > > > biggest address blocks. That's a good thing since IPv6 routes that > > > propagate worldwide may impose an annual systemic overhead cost on > > > ISPs of as much as US $16,000 each. > > > > > > C. Traffic engineering routes are trivially filterable. Any route > > > longer than the published allocation size can be presumed to be > > > traffic engineering, not a downstream multihomed customer, thus > > > you can filter distant small routes with confidence and ease. > > > > > > D. Fair. No need to define the difference between ISP and not ISP. > > > Everybody plays by the same rules. > > > > > > E. No complicated analysis for allocation. You pay for what you > > > want and get what you pay for. You're either multihomed or you're not. > > > > > > F. Gets ARIN out of the business of being the gatekeeper for > > > Internet routing policy. By classifying allocations instead of > > > making eligibility decisions, ARIN empowers the ISPs to set > > > appropriate routing eligibility policies instead. > > > > > > FAQ > > > Q. Isn't this classfull addressing all over again? > > > A. Yes. > > > Classful addressing had a lot of virtues with respect to route > > > filtering and management. We had to abandon it because there > > > weren't enough B's for everyone who needed more than one C and > > > there weren't enough A's period. With IPv6, we don't have that > > > problem. Not yet and maybe not ever. Perhaps we can have our cake and eat it too. > > > > > > Q. What if I don't want to accept /56 routes for single-homed users? > > > > > > A. This policy proposal intentionally and fully places backbone > > > routing policy in the hands of the ISPs who operate the Internet's > > > "Default-Free Zone (DFZ)," colloquially known as the Internet > > > backbone. The author expects that some of the allocations, > > > especially some of the single-homed allocations, *will not* be > > > routable on the public Internet. When we hold a general > > > expectation that all of ARIN's allocations will be routable, we > > > effectively mean that ARIN decides what the Internet routing > > > policy will be. That's precisely the role this proposal removes > > > from ARIN's hands and > restores > to the ISPs. > > > > > > Q. Spell it out for me. How exactly will pools and size > > > classifications enable route filtering? > > > > > > A. Suppose ARIN holds 4000::/12. ARIN might split it up as follows: > > > > > > 4000::/13 -- reserved > > > 4008::/15 -- multihomed /24 allocations > > > 400a::/15 -- non-multihomed /24 allocations > > > 400c::/16 -- multihomed /32 allocations > > > 400d::/16 -- non-multihomed /32 allocations > > > 400e:0000::/18 -- multihomed /40 allocations > > > 400e:4000::/18 -- non-multihomed /40 allocations > > > 400e:8000::/24 -- multihomed /48 allocations > > > 400e:8100::/24 -- non-multihomed /48 allocations > > > 400e:8200::/24 -- multihomed /56 allocations > > > 400e:8300::/24 -- non-multihomed /56 allocations > > > 400e:8400::/22 -- reserved > > > 400e:8800::/21 -- reserved > > > 400e:9000::/20 -- reserved > > > 400e:a000::/19 -- reserved > > > 400e:c000::/18 -- reserved > > > 400f::/16 -- reserved > > > > > > Now, you're an ISP. Here's a sample routing policy you might choose: > > > > > > Accept any routes to /32 because anyone paying $10k per year for > > > addresses is big enough to ride. > > > For /24 allow 2 bits of traffic engineering too. > > > Single-homers who won't spend $10k/year on their addresses > > > (smaller than /32) must use addresses from their ISP. Tough luck. > > > Accept multihomers down to /48. > > > The folks paying only $10/year for /56's aren't serious. > > > > > > Your route filter looks like this: > > > > > > accept 400e:8000::/24 equal 48 > > > accept 400e:0000::/18 equal 40 > > > accept 400c::/15 equal 32 > > > accept 4008::/14 le 26 > > > reject 4000::/12 le 128 > > > > > > Note how 400e:8000::/24 contains only /48 allocations and you're > > > allowing only /48 announcements. Since there aren't any /47 or /46 > > > allocations there, nobody in the pool can slip TE routes past you. > > > On the other hand, you'll get some benefit of traffic engineering > > > from the super-massive /24 registrants up in 4008::/14 because > > > you're allowing them to disaggregate down to /26. > > > > > > Q. If its so expensive to announce routes into the DFZ, why not > > > use something better than BGP? > > > > > > A. In 2008 the IRTF Routing Research Group compiled an exhaustive > > > study attempting to identify the possible ways to improve the > > > routing system. A draft of the results is at > > > http://tools.ietf.org/html/draft-irtf-rrg-recommendation-02 . > > > While there are many promising ideas for how to replace BGP with > > > something that scales better, we're at least a decade away and > > > probably more from any significant deployment of a BGP replacement. > > > > > > Q. Is it really true that multihoming requires announcing a route > > > via BGP? > > > > > > A. The short answer is yes. The long answer is more complicated. > > > > > > Folks have tried very hard to devise multi-vendor multihomed > > > systems which don't rely on BGP. The only approach that has ever > > > come near success is dynamically changing DNS records to favor the > > > currently working Internet connection. "Near" is a relative term > > > here. Such network architectures are enormously complex and they > > > don't work especially well. The DNS protocol itself supports quick > > > changes but the applications which use it often don't. It takes > > > hours to achieve two-nines recovery from an address change in the > > > DNS and it takes months to achieve five-nines recovery. Web > > > browsers, for example, don't immediately recover. Search google for "DNS Pinning." > > > > > > Q. So the Internet's resulting route policy will be to allow all > > > the sizes that no major ISP decides to filter and restrict the rest? > > > > > > A. That's one possible outcome. On the other hand, research in the > > > routing field suggests that with a sufficiently rich > > > classification scheme, it may be possible to implement lower > > > priority systems with provider-independent addresses yet without a > > > global route. Hints for how such a thing might work can be found > > > in http://www.cs.cornell.edu/people/francis/va-wp.pdf and > > > http://bill.herrin.us/network/trrp.html. Such schemes need a rich > > > classification process at the address allocation level that makes > > > it possible for ISPs to make reasonable and simple decisions about > > > which routes should be distributed to every DFZ router and which > should > not. > > > > > > Wouldn't that be something: IPv6 provider independent addresses > > > for everybody without materially increasing the cost of the > > > routing system. > > > > > > Q. Why allocate the /48's from a pool only for /48's, /32's from a > > > /32 pool, etc.? Why not allocate from just one pool? > > > > > > A. If all assignments in a particular pool are /32 then any route > > > in the /32 pool which is longer than /32 is a traffic engineering > > > (TE) route. As a router operator you can filter and discard TE > > > routes if you find they give you insufficient benefit. The routes > > > you filter don't cost you any money; only the routes you keep carry a price tag. > > > > > > You can only filter if you're sure they're TE routes... If they're > > > distinct downstream customer routes and you filter them, there > > > goes the Internet. Or at least there goes your part of it. See customers. > > > See customers run... straight to your competitor. Setting up the > > > distinct pools makes it practical to know with certainty whether > > > the routes you're filtering are only for TE. > > > > > > Q. Why allow only one allocation of each particular size? > > > > > > A. Without the address scarcity issue which drives IPv4 policy, > > > the primary criteria for IPv6 addressing policy is suppressing the > > > disaggregation that drives route count in the IPv4 DFZ (NRPM 6.3.8). > > > Such a criteria is not well served if an organization holds dozens > > > of discontiguous address spaces as a result of acquisitions, > > > mergers and and growing a little bit at a time. This proposal > > > says, in effect, once you've consumed your smaller allocation it's > > > time for you to get a *much* bigger allocation. The rest of us > > > don't want to pay the routing table price for you coming back > > > again and again and > again. > > > > > > The proposal could require some renumbering as a result of mergers > > > and acquisitions. However, with only modest planning on the > > > registrant's part, the policy its flexible enough to allow that > > > renumbering to occur over a long period of time so that both cost > > > and disruption are minimized. In many cases, customer churn can be > > > expected to take care of much of the renumbering activity all by > itself. > > > > > > Q. What about the IETF recommendations? > > > > > > A. RFC 3177 recommends that ISPs receive a /32 while downstream > > > customers receive a /48 assignment by default with so-called > > > "sparse allocation" to allow those assignments to expand by > > > changing the netmask. While this proposal supports organizations > > > who wish to follow those recommendations, it is not this > > > proposal's intention that ARIN follow RFC 3177. > > > > > > RFC 3177 is not the gospel truth. It was written back in 2001 when > > > there was little IPv6 outside of academia and, indeed, little IPv6 > > > at all. It's an engineers' SWAG about what operations folk should > > > do that's now 8-years-stale. > > > > > > This proposal attempts to slow-start IPv6 allocations instead, > > > while still maintaining the principle of suppressing the routing table size. > > > As an ISP, consider implementing a slow start for your downstream > > > customers as well: Give them a /60 initially, add a /56 when they > > > need it and add a /52 when they run out of the /56. A /60 is 16 > > > /64 subnets. That's an internal LAN, a DMZ and 14 more subnets. > > > Just how many subnets do you think your normal downstream customer > > > will actually use? > > > > > > Q. What happens when organizations merge or split? > > > > > > A. Entities which merge may renumber out of and return > > > conflicting allocations, or they may maintain the existence of the > > > acquired organization in order to keep it's addresses. Either way > > > it should be a minor hardship. > > > > > > Entities which split have a bigger problem since the practical > > > effect of route filtering may be that only one of them can keep > > > the addresses. To a large extent, that problem already exists and > > > is a pain in the rump for IPv4 operations today. This policy > > > doesn't solve it but it doesn't make it a whole lot worse either. > > > Because disaggregates are likely to be filtered, this IPv6 policy > > > does gives us a slightly better guarantee that the rest of us > > > won't get stuck with the check (in the form of routing slot > > > consumption) when an ISP goes bankrupt and gets split up. > > > > > > Q. What about IPv6 addresses for uses which will not be connected > > > to the Internet at all? > > > > > > A. Folks are welcome to get non-multihomed addresses for any > > > purpose whatsoever. If they do eventually decide to connect to the > > > Internet, the routes will follow whatever rules the ISPs have > > > imposed for routes within the single-homed pools. > > > > > > Q. What about reporting requirements for downstream assignments? > > > > > > A. Reporting requirements were instituted for the purpose of > > > verifying eligibility for additional allocations. They have proven > > > useful for other purposes and the author encourages ARIN to > > > maintain the SWIP system. Nevertheless, this proposal renders the > > > use of SWIP for IPv6 optional since it is no longer needed to > > > verify eligibility for allocations. > > > > > > Q. What if I need more than a /24? > > > > > > A. This proposal's author asserts as obvious: anyone who defines a > > > need for more than a trillion subnets should make their case > > > publicly on PPML, seeking a follow-on proposal that establishes > > > address pools at the /16 level. > > > > > > Q. What are the struck sections of the current IPv6 policy and why > > > should they be struck? > > > > > > A. 6.2.3 - 6.2.9 define terms that have no meaning or use in the > > > policy as revised by this proposal. > > > > > > The 6.4.3 notion of a minimum allocation is obsoleted by the > > > allocation pools of specific size in this proposal. > > > > > > 6.4.4 is moot as this proposal does not expect registrants to > > > justify their IPv6 allocation size. > > > > > > 6.5.1 - 6.5.4 and 6.5.8 are replaced entirely by 6.5.9. > > > > > > 6.5.5 is largely moot since it's no longer necessary to confirm > > > downstream assignments in order to determine eligibility for > > > additional addresses. > > > > > > 6.7 is moot as it is unnecessary to compute utilization to justify > > > addresses under this proposal. > > > > > > 6.9 paragraph 2 is moot since utilization is not a factor in IPv6 > > > policy under this proposal. > > > > > > 6.10 is redundant since micro-allocations are trivially > > > accomplished under 6.5.9. > > > > > > > > > Implementation notes: > > > > > > To prevent wasteful consumption of IPv6 address space without a > > > complicated eligibility regime, the author recommends an initial > > > and annual fee regime for IPv6 address allocations similar to: > > > > > > /56 -- $10 USD > > > /48 -- $100 USD > > > /40 -- $1000 USD > > > /32 -- $10,000 USD > > > /24 -- $100,000 USD > > > Legacy -- the lesser of the cost of the next larger size or the > > > cost of the next smaller size times the number encompassed by the > > > registration. > > > > > > The above notwithstanding, it may be advisable to discount /40s > > > and /32s to a much lower price during IPv6's general deployment > > > process in order to encourage adoption. Folks who already hold > > > /31's should probably also get a big break on the $20k fee for a > > > good long while, perhaps until the first time they request an > > > additional block without offering a plan to return the legacy addresses. > > > > > > For verification of multihoming, the current way ARIN verifies > > > multihoming for other parts of it's policy appears satisfactory. > > > Should that change, the author suggests requiring that the AS# > > > contacts for at least two AS#'s submit a template indicating that > > > they intend to originate or propagate IPv6 BGP routes from the > > > registrant's ORG. > > > > > > Timetable for implementation: immediate > > > > > > > > > > > > > > > _______________________________________________ > > > PPML > > > You are receiving this message because you are subscribed to the > > > ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > > Unsubscribe or manage your mailing list subscription at: > > > http://lists.arin.net/mailman/listinfo/arin-ppml > > > Please contact info at arin.net if you experience any issues. > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to the > > ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From sethm at rollernet.us Mon Nov 16 16:08:20 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 16 Nov 2009 13:08:20 -0800 Subject: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process In-Reply-To: <339F6302D15646D9A29EE3CFF0CF3310@johnsonvhjjf8v> References: <4AF86E15.2060307@arin.net> <4AFE3008.3000904@ibctech.ca><0267B5481DCC474D8088BF4A25C7F1DF55127B074A@XCH-NW-05V.nw.nos.boeing.com> <7F1CF82C4623478B8F18B392B94CE37E@johnsonvhjjf8v> <0267B5481DCC474D8088BF4A25C7F1DF55127B074B@XCH-NW-05V.nw.nos.boeing.com> <339F6302D15646D9A29EE3CFF0CF3310@johnsonvhjjf8v> Message-ID: <4B01BF44.9040505@rollernet.us> Warren Johnson wrote: > Instead of spending the next two decades trying to get people migrated over > maybe we should just scrap v6 and create "v7" and make it backwards > compatible with v4. I guess we're not at that point yet because we just > don't know what's going to happen post-runout. > There's plenty of bits to embed a v4 address into a v6 prefix. ~Seth From terry.l.davis at boeing.com Mon Nov 16 16:13:00 2009 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Mon, 16 Nov 2009 13:13:00 -0800 Subject: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process In-Reply-To: <339F6302D15646D9A29EE3CFF0CF3310@johnsonvhjjf8v> References: <4AF86E15.2060307@arin.net><4AFE3008.3000904@ibctech.ca><0267B54 81DCC474D8088BF4A25C7F1DF55127B074A@XCH-NW-05V.nw.nos.boeing.com><7F1CF82C4 623478B8F18B392B94CE37E@johnsonvhjjf8v><0267B5481DCC474D8088BF4A25C7F1DF55127B074B@XCH-NW-05V.nw.nos.boeing.com> <339F6302D15646D9A29EE3CFF0CF3310@johnsonvhjjf8v> Message-ID: <0267B5481DCC474D8088BF4A25C7F1DF55127B074C@XCH-NW-05V.nw.nos.boeing.com> Warren There are some proposals out there to do that, but there are also folks working hard on the seamless layer too. I can't imagine that developing another network protocol to replace v6 would take less than another decade which is time I don't think we have. My personal hope is that this transition will have forced us to learn (re-learn) basic software engineering. With our current generation of apps, we embedded layer 3 networking in our layer 7 apps; thus we can not change the transport without changing the apps. I'm now a big proponent of "network aware" applications with application level security utilizing an isolation messaging layer which allows routing of message traffic over any transport available. Take care Terry > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Warren Johnson > Sent: Monday, November 16, 2009 12:54 PM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation > Process > > Instead of spending the next two decades trying to get people migrated > over > maybe we should just scrap v6 and create "v7" and make it backwards > compatible with v4. I guess we're not at that point yet because we just > don't know what's going to happen post-runout. > > > > -----Original Message----- > From: Davis, Terry L [mailto:terry.l.davis at boeing.com] > Sent: Monday, November 16, 2009 2:50 PM > To: 'Warren Johnson'; arin-ppml at arin.net > Subject: RE: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation > Process > > Warren > > My answer would be "we didn't have enough software types in the room > during > the discussions on creating v6" to point out the implications of that > fact. > > Although a long term v6 advocate, I did not fully realize what we had done > to ourselves till I did a Master's project paper on v6 migration a few > years > ago. After doing that, I realized that with current transition > technologies, we end up with an ugly v4-v6 transition layer consisting of > many different v4-v6 technologies (and some at the individual app level) > in > our IT infrastructure architecture for probably decades. And that layer > also has very severe implications for an IT security infrastructure. > > If we had a simple straight forward transition mechanism, v6 would have > taken off years ago. Hindsight is 20-20; foresight though isn't (maybe > 20-2000). > > Take care > Terry > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] > > On Behalf Of Warren Johnson > > Sent: Monday, November 16, 2009 12:30 PM > > To: arin-ppml at arin.net > > Subject: Re: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation > > Process > > > > Stupid question here: why wasn't v6 designed to be backwards > > compatible with v4? Just not possible? > > > > > > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] > > On Behalf Of Davis, Terry L > > Sent: Monday, November 16, 2009 2:03 PM > > To: 'Steve Bertrand'; arin-ppml at arin.net > > Subject: Re: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation > > Process > > > > Steve > > > > I like it also. One of our biggest problems is that we simply do not > > have enough really large scale IPv6 deployments around the globe to > > begin to understand all the problems or to come up with better > > migration/integration plans between v4 and v6. This should spur more > > use IPv6; as it is today, not even the green field startups are using > > v6 and this should tell us something about our current assumptions and > > policies. > > > > In retrospect, by not having a seamless, easy to use method, of > > allowing > > v4 > > to v6 communications, we have made deploying v6 very costly; migrating > > our millions of v4 based apps to v6 comes with both a huge price tag > > for opening and dual-stacking them and a corresponding "risk" factor > > for business continuity associated with that work. > > > > Take care > > Terry > > > > > -----Original Message----- > > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] > > > On Behalf Of Steve Bertrand > > > Sent: Friday, November 13, 2009 8:20 PM > > > To: arin-ppml at arin.net > > > Subject: Re: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation > > > Process > > > > > > Member Services wrote: > > > > > > > Policy Proposal 103: Change IPv6 Allocation Process > > > > > > I'm very, very interested in this proposal, and would like to give > > > it a bump in hopes that it will spur more feedback and discussion > > > than what it's received thus far. > > > > > > Truthfully, I would like to get a feel on the number of people who > > > like it (I certainly do). If anyone has disregarded or overlooked > > > the proposal because of the recommended financial figures, please > > > let that be known as well. > > > > > > Complete original proposal message has been left intact below. > > > > > > Steve > > > > > > > > > > Proposal Originator: William Herrin > > > > > > > > Proposal Version: 1.0 > > > > > > > > Date: 9 November 2009 > > > > > > > > Proposal type: new > > > > > > > > Policy term: permanent. > > > > > > > > Policy statement: > > > > > > > > Strike NRPM sections: 6.2.3, 6.2.4, 6.2.6-6.2.9, 6.4.3, 6.4.4, > > > > 6.5.1-6.5.5, 6.5.8, 6.7, 6.10 > > > > > > > > Strike NRPM section 6.9 paragraph 2. > > > > > > > > Replace 6.2.5 as follows: > > > > > > > > 6.2.5 Allocate and Assign > > > > > > > > For the purposes of NRPM section 6, allocate and assign are > > > > synonymous. Both terms describe any or all use identified in > > > > section 2.5. > > > > > > > > Replace 6.5.7 with: > > > > > > > > 6.5.7. Existing IPv6 address space holders > > > > > > > > Organizations that received IPv6 allocations under the previous > > > > IPv6 address policy are entitled to either retain those > > > > allocations as is or trade them in for an allocation under 6.5.9. > > > > > > > > Add NRPM section 6.5.9 as follows: > > > > > > > > 6.5.9 IPv6 Allocations > > > > > > > > 6.5.9.1 ARIN shall allocate IPv6 address blocks in exactly and > > > > only the following denominations: /56, /48, /40, /32, /24 > > > > > > > > 6.5.9.2 No utilization-based eligibility requirements shall apply > > > > to > > > > IPv6 allocations. > > > > > > > > 6.5.9.3 ARIN shall accept registration of no more than one address > > > > block of each size for any single organization. > > > > > > > > 6.5.9.4 ARIN shall allocate IPv6 addresses from pools such that > > > > the identity of the allocation pool serves to classify the > > > > expected size of allocations within. ISPs may use that > > > > classification to filter or otherwise manage their routing tables. > > > > > > > > 6.5.9.5 For each allocation size, ARIN shall further manage the > > > > allocation pools such that the pool identity serves to classify > > > > whether or not the registrant is Multihomed. > > > > > > > > 6.5.9.6 ARIN shall offer addresses from pools classified as > > > > multihomed only to organizations which ARIN has verified are > > > > multihomed on the public Internet per NRPM 2.7. > > > > > > > > 6.5.9.7 Where an organization ceases to be Multihomed it shall > > > > surrender all address allocations from within pools classified as > > > > multihomed within 3 months. > > > > > > > > > > > > Rationale: > > > > > > > > See the implementation notes section below for what should replace > > > > utilization-based eligibility. > > > > > > > > The existing IPv6 allocation policy under section 6.5 makes a > > > > number of unproven assumptions about how IPv6 allocations will work. > > > > > > > > Unproven: we can make a reasonable guess about how many IPv6 > > > > subnets an organization will need at the outset when they first > > > > request IP addresses. When in all of human history has this ever > > > > proven true of any resource? > > > > > > > > Unproven: with sparse allocation, we can allow organizations to > > > > expand by just changing their subnet mask so that they don't have > > > > to announce additional routes into the DFZ. This claim is > questionable. > > > > With sparse allocation, we either consume much larger blocks that > > > > what we assign (so why not just assign the larger block?) or else > > > > we don't consume them in which case the org either has to renumber > > > > to expand or he has to announce a second route. Worse, because > > > > routes of various sizes are all scattered inside the same address > > > > space, its impractical to filter out the traffic engineering routes. > > > > > > > > Unproven: we can force organizations not to disaggregate for > > > > traffic engineering purposes. Neither any of our experience with > > > > IPv4 nor any of the research in the IRTF Routing Research Group > > > > suggests that this is even remotely practical so long as BGP or > > > > any similar system rules the roost. > > > > > > > > Unproven: all non-ISPs can be reasonably expected to get their > > > > address space from ISPs instead of from ARIN. We can certainly > > > > operate that way, but it could prove deadly to the routing table. > > > > Any organization multihomed between two ISPs will need to announce > > > > that route via BGP, regardless of where they get the address space > > > > from. We have knobs and dials in the routers that let us easily > > > > filter disaggregates from distant announcements, but we don't dare > > > > do so if there is a possibility that one of those disaggregates is > > > > a multihomed customer rather than traffic engineering. > > > > > > > > Benefits of this proposal: > > > > > > > > A. Efficient allocation of IP addresses. Orgs get what they need > > > > when they need it without a great deal of guesswork. > > > > > > > > B. Efficient utilization of BGP routing slots. No multihomed orgs > > > > will announce more than five unfilterable routes, and that only if > > > > they're so large that they can afford the price tag for the > > > > biggest address blocks. That's a good thing since IPv6 routes that > > > > propagate worldwide may impose an annual systemic overhead cost on > > > > ISPs of as much as US $16,000 each. > > > > > > > > C. Traffic engineering routes are trivially filterable. Any route > > > > longer than the published allocation size can be presumed to be > > > > traffic engineering, not a downstream multihomed customer, thus > > > > you can filter distant small routes with confidence and ease. > > > > > > > > D. Fair. No need to define the difference between ISP and not ISP. > > > > Everybody plays by the same rules. > > > > > > > > E. No complicated analysis for allocation. You pay for what you > > > > want and get what you pay for. You're either multihomed or you're > not. > > > > > > > > F. Gets ARIN out of the business of being the gatekeeper for > > > > Internet routing policy. By classifying allocations instead of > > > > making eligibility decisions, ARIN empowers the ISPs to set > > > > appropriate routing eligibility policies instead. > > > > > > > > FAQ > > > > Q. Isn't this classfull addressing all over again? > > > > A. Yes. > > > > Classful addressing had a lot of virtues with respect to route > > > > filtering and management. We had to abandon it because there > > > > weren't enough B's for everyone who needed more than one C and > > > > there weren't enough A's period. With IPv6, we don't have that > > > > problem. Not yet and maybe not ever. Perhaps we can have our cake > and > eat it too. > > > > > > > > Q. What if I don't want to accept /56 routes for single-homed users? > > > > > > > > A. This policy proposal intentionally and fully places backbone > > > > routing policy in the hands of the ISPs who operate the Internet's > > > > "Default-Free Zone (DFZ)," colloquially known as the Internet > > > > backbone. The author expects that some of the allocations, > > > > especially some of the single-homed allocations, *will not* be > > > > routable on the public Internet. When we hold a general > > > > expectation that all of ARIN's allocations will be routable, we > > > > effectively mean that ARIN decides what the Internet routing > > > > policy will be. That's precisely the role this proposal removes > > > > from ARIN's hands and > > restores > > to the ISPs. > > > > > > > > Q. Spell it out for me. How exactly will pools and size > > > > classifications enable route filtering? > > > > > > > > A. Suppose ARIN holds 4000::/12. ARIN might split it up as follows: > > > > > > > > 4000::/13 -- reserved > > > > 4008::/15 -- multihomed /24 allocations > > > > 400a::/15 -- non-multihomed /24 allocations > > > > 400c::/16 -- multihomed /32 allocations > > > > 400d::/16 -- non-multihomed /32 allocations > > > > 400e:0000::/18 -- multihomed /40 allocations > > > > 400e:4000::/18 -- non-multihomed /40 allocations > > > > 400e:8000::/24 -- multihomed /48 allocations > > > > 400e:8100::/24 -- non-multihomed /48 allocations > > > > 400e:8200::/24 -- multihomed /56 allocations > > > > 400e:8300::/24 -- non-multihomed /56 allocations > > > > 400e:8400::/22 -- reserved > > > > 400e:8800::/21 -- reserved > > > > 400e:9000::/20 -- reserved > > > > 400e:a000::/19 -- reserved > > > > 400e:c000::/18 -- reserved > > > > 400f::/16 -- reserved > > > > > > > > Now, you're an ISP. Here's a sample routing policy you might choose: > > > > > > > > Accept any routes to /32 because anyone paying $10k per year for > > > > addresses is big enough to ride. > > > > For /24 allow 2 bits of traffic engineering too. > > > > Single-homers who won't spend $10k/year on their addresses > > > > (smaller than /32) must use addresses from their ISP. Tough luck. > > > > Accept multihomers down to /48. > > > > The folks paying only $10/year for /56's aren't serious. > > > > > > > > Your route filter looks like this: > > > > > > > > accept 400e:8000::/24 equal 48 > > > > accept 400e:0000::/18 equal 40 > > > > accept 400c::/15 equal 32 > > > > accept 4008::/14 le 26 > > > > reject 4000::/12 le 128 > > > > > > > > Note how 400e:8000::/24 contains only /48 allocations and you're > > > > allowing only /48 announcements. Since there aren't any /47 or /46 > > > > allocations there, nobody in the pool can slip TE routes past you. > > > > On the other hand, you'll get some benefit of traffic engineering > > > > from the super-massive /24 registrants up in 4008::/14 because > > > > you're allowing them to disaggregate down to /26. > > > > > > > > Q. If its so expensive to announce routes into the DFZ, why not > > > > use something better than BGP? > > > > > > > > A. In 2008 the IRTF Routing Research Group compiled an exhaustive > > > > study attempting to identify the possible ways to improve the > > > > routing system. A draft of the results is at > > > > http://tools.ietf.org/html/draft-irtf-rrg-recommendation-02 . > > > > While there are many promising ideas for how to replace BGP with > > > > something that scales better, we're at least a decade away and > > > > probably more from any significant deployment of a BGP replacement. > > > > > > > > Q. Is it really true that multihoming requires announcing a route > > > > via BGP? > > > > > > > > A. The short answer is yes. The long answer is more complicated. > > > > > > > > Folks have tried very hard to devise multi-vendor multihomed > > > > systems which don't rely on BGP. The only approach that has ever > > > > come near success is dynamically changing DNS records to favor the > > > > currently working Internet connection. "Near" is a relative term > > > > here. Such network architectures are enormously complex and they > > > > don't work especially well. The DNS protocol itself supports quick > > > > changes but the applications which use it often don't. It takes > > > > hours to achieve two-nines recovery from an address change in the > > > > DNS and it takes months to achieve five-nines recovery. Web > > > > browsers, for example, don't immediately recover. Search google for > "DNS Pinning." > > > > > > > > Q. So the Internet's resulting route policy will be to allow all > > > > the sizes that no major ISP decides to filter and restrict the rest? > > > > > > > > A. That's one possible outcome. On the other hand, research in the > > > > routing field suggests that with a sufficiently rich > > > > classification scheme, it may be possible to implement lower > > > > priority systems with provider-independent addresses yet without a > > > > global route. Hints for how such a thing might work can be found > > > > in http://www.cs.cornell.edu/people/francis/va-wp.pdf and > > > > http://bill.herrin.us/network/trrp.html. Such schemes need a rich > > > > classification process at the address allocation level that makes > > > > it possible for ISPs to make reasonable and simple decisions about > > > > which routes should be distributed to every DFZ router and which > > should > > not. > > > > > > > > Wouldn't that be something: IPv6 provider independent addresses > > > > for everybody without materially increasing the cost of the > > > > routing system. > > > > > > > > Q. Why allocate the /48's from a pool only for /48's, /32's from a > > > > /32 pool, etc.? Why not allocate from just one pool? > > > > > > > > A. If all assignments in a particular pool are /32 then any route > > > > in the /32 pool which is longer than /32 is a traffic engineering > > > > (TE) route. As a router operator you can filter and discard TE > > > > routes if you find they give you insufficient benefit. The routes > > > > you filter don't cost you any money; only the routes you keep carry > a > price tag. > > > > > > > > You can only filter if you're sure they're TE routes... If they're > > > > distinct downstream customer routes and you filter them, there > > > > goes the Internet. Or at least there goes your part of it. See > customers. > > > > See customers run... straight to your competitor. Setting up the > > > > distinct pools makes it practical to know with certainty whether > > > > the routes you're filtering are only for TE. > > > > > > > > Q. Why allow only one allocation of each particular size? > > > > > > > > A. Without the address scarcity issue which drives IPv4 policy, > > > > the primary criteria for IPv6 addressing policy is suppressing the > > > > disaggregation that drives route count in the IPv4 DFZ (NRPM 6.3.8). > > > > Such a criteria is not well served if an organization holds dozens > > > > of discontiguous address spaces as a result of acquisitions, > > > > mergers and and growing a little bit at a time. This proposal > > > > says, in effect, once you've consumed your smaller allocation it's > > > > time for you to get a *much* bigger allocation. The rest of us > > > > don't want to pay the routing table price for you coming back > > > > again and again and > > again. > > > > > > > > The proposal could require some renumbering as a result of mergers > > > > and acquisitions. However, with only modest planning on the > > > > registrant's part, the policy its flexible enough to allow that > > > > renumbering to occur over a long period of time so that both cost > > > > and disruption are minimized. In many cases, customer churn can be > > > > expected to take care of much of the renumbering activity all by > > itself. > > > > > > > > Q. What about the IETF recommendations? > > > > > > > > A. RFC 3177 recommends that ISPs receive a /32 while downstream > > > > customers receive a /48 assignment by default with so-called > > > > "sparse allocation" to allow those assignments to expand by > > > > changing the netmask. While this proposal supports organizations > > > > who wish to follow those recommendations, it is not this > > > > proposal's intention that ARIN follow RFC 3177. > > > > > > > > RFC 3177 is not the gospel truth. It was written back in 2001 when > > > > there was little IPv6 outside of academia and, indeed, little IPv6 > > > > at all. It's an engineers' SWAG about what operations folk should > > > > do that's now 8-years-stale. > > > > > > > > This proposal attempts to slow-start IPv6 allocations instead, > > > > while still maintaining the principle of suppressing the routing > table > size. > > > > As an ISP, consider implementing a slow start for your downstream > > > > customers as well: Give them a /60 initially, add a /56 when they > > > > need it and add a /52 when they run out of the /56. A /60 is 16 > > > > /64 subnets. That's an internal LAN, a DMZ and 14 more subnets. > > > > Just how many subnets do you think your normal downstream customer > > > > will actually use? > > > > > > > > Q. What happens when organizations merge or split? > > > > > > > > A. Entities which merge may renumber out of and return > > > > conflicting allocations, or they may maintain the existence of the > > > > acquired organization in order to keep it's addresses. Either way > > > > it should be a minor hardship. > > > > > > > > Entities which split have a bigger problem since the practical > > > > effect of route filtering may be that only one of them can keep > > > > the addresses. To a large extent, that problem already exists and > > > > is a pain in the rump for IPv4 operations today. This policy > > > > doesn't solve it but it doesn't make it a whole lot worse either. > > > > Because disaggregates are likely to be filtered, this IPv6 policy > > > > does gives us a slightly better guarantee that the rest of us > > > > won't get stuck with the check (in the form of routing slot > > > > consumption) when an ISP goes bankrupt and gets split up. > > > > > > > > Q. What about IPv6 addresses for uses which will not be connected > > > > to the Internet at all? > > > > > > > > A. Folks are welcome to get non-multihomed addresses for any > > > > purpose whatsoever. If they do eventually decide to connect to the > > > > Internet, the routes will follow whatever rules the ISPs have > > > > imposed for routes within the single-homed pools. > > > > > > > > Q. What about reporting requirements for downstream assignments? > > > > > > > > A. Reporting requirements were instituted for the purpose of > > > > verifying eligibility for additional allocations. They have proven > > > > useful for other purposes and the author encourages ARIN to > > > > maintain the SWIP system. Nevertheless, this proposal renders the > > > > use of SWIP for IPv6 optional since it is no longer needed to > > > > verify eligibility for allocations. > > > > > > > > Q. What if I need more than a /24? > > > > > > > > A. This proposal's author asserts as obvious: anyone who defines a > > > > need for more than a trillion subnets should make their case > > > > publicly on PPML, seeking a follow-on proposal that establishes > > > > address pools at the /16 level. > > > > > > > > Q. What are the struck sections of the current IPv6 policy and why > > > > should they be struck? > > > > > > > > A. 6.2.3 - 6.2.9 define terms that have no meaning or use in the > > > > policy as revised by this proposal. > > > > > > > > The 6.4.3 notion of a minimum allocation is obsoleted by the > > > > allocation pools of specific size in this proposal. > > > > > > > > 6.4.4 is moot as this proposal does not expect registrants to > > > > justify their IPv6 allocation size. > > > > > > > > 6.5.1 - 6.5.4 and 6.5.8 are replaced entirely by 6.5.9. > > > > > > > > 6.5.5 is largely moot since it's no longer necessary to confirm > > > > downstream assignments in order to determine eligibility for > > > > additional addresses. > > > > > > > > 6.7 is moot as it is unnecessary to compute utilization to justify > > > > addresses under this proposal. > > > > > > > > 6.9 paragraph 2 is moot since utilization is not a factor in IPv6 > > > > policy under this proposal. > > > > > > > > 6.10 is redundant since micro-allocations are trivially > > > > accomplished under 6.5.9. > > > > > > > > > > > > Implementation notes: > > > > > > > > To prevent wasteful consumption of IPv6 address space without a > > > > complicated eligibility regime, the author recommends an initial > > > > and annual fee regime for IPv6 address allocations similar to: > > > > > > > > /56 -- $10 USD > > > > /48 -- $100 USD > > > > /40 -- $1000 USD > > > > /32 -- $10,000 USD > > > > /24 -- $100,000 USD > > > > Legacy -- the lesser of the cost of the next larger size or the > > > > cost of the next smaller size times the number encompassed by the > > > > registration. > > > > > > > > The above notwithstanding, it may be advisable to discount /40s > > > > and /32s to a much lower price during IPv6's general deployment > > > > process in order to encourage adoption. Folks who already hold > > > > /31's should probably also get a big break on the $20k fee for a > > > > good long while, perhaps until the first time they request an > > > > additional block without offering a plan to return the legacy > addresses. > > > > > > > > For verification of multihoming, the current way ARIN verifies > > > > multihoming for other parts of it's policy appears satisfactory. > > > > Should that change, the author suggests requiring that the AS# > > > > contacts for at least two AS#'s submit a template indicating that > > > > they intend to originate or propagate IPv6 BGP routes from the > > > > registrant's ORG. > > > > > > > > Timetable for implementation: immediate > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > PPML > > > > You are receiving this message because you are subscribed to the > > > > ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > > > Unsubscribe or manage your mailing list subscription at: > > > > http://lists.arin.net/mailman/listinfo/arin-ppml > > > > Please contact info at arin.net if you experience any issues. > > > > > > _______________________________________________ > > > PPML > > > You are receiving this message because you are subscribed to the > > > ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > > Unsubscribe or manage your mailing list subscription at: > > > http://lists.arin.net/mailman/listinfo/arin-ppml > > > Please contact info at arin.net if you experience any issues. > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to the ARIN > > Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to the ARIN > > Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From warren at wholesaleinternet.com Mon Nov 16 16:28:12 2009 From: warren at wholesaleinternet.com (Warren Johnson) Date: Mon, 16 Nov 2009 15:28:12 -0600 Subject: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process In-Reply-To: <0267B5481DCC474D8088BF4A25C7F1DF55127B074C@XCH-NW-05V.nw.nos.boeing.com> References: <4AF86E15.2060307@arin.net><4AFE3008.3000904@ibctech.ca><0267B5481DCC474D8088BF4A25C7F1DF55127B074A@XCH-NW-05V.nw.nos.boeing.com><7F1CF82C4623478B8F18B392B94CE37E@johnsonvhjjf8v><0267B5481DCC474D8088BF4A25C7F1DF55127B074B@XCH-NW-05V.nw.nos.boeing.com> <339F6302D15646D9A29EE3CFF0CF3310@johnsonvhjjf8v> <0267B5481DCC474D8088BF4A25C7F1DF55127B074C@XCH-NW-05V.nw.nos.boeing.com> Message-ID: <0CCC765EBA83489D85ABB64F1BB1E15C@johnsonvhjjf8v> I guess at some point post-runout we will have a clearer understanding of the time frames we're dealing with. We could make a decision at that point. -----Original Message----- From: Davis, Terry L [mailto:terry.l.davis at boeing.com] Sent: Monday, November 16, 2009 3:13 PM To: 'Warren Johnson'; arin-ppml at arin.net Subject: RE: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process Warren There are some proposals out there to do that, but there are also folks working hard on the seamless layer too. I can't imagine that developing another network protocol to replace v6 would take less than another decade which is time I don't think we have. My personal hope is that this transition will have forced us to learn (re-learn) basic software engineering. With our current generation of apps, we embedded layer 3 networking in our layer 7 apps; thus we can not change the transport without changing the apps. I'm now a big proponent of "network aware" applications with application level security utilizing an isolation messaging layer which allows routing of message traffic over any transport available. Take care Terry > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] > On Behalf Of Warren Johnson > Sent: Monday, November 16, 2009 12:54 PM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation > Process > > Instead of spending the next two decades trying to get people migrated > over maybe we should just scrap v6 and create "v7" and make it > backwards compatible with v4. I guess we're not at that point yet > because we just don't know what's going to happen post-runout. > > > > -----Original Message----- > From: Davis, Terry L [mailto:terry.l.davis at boeing.com] > Sent: Monday, November 16, 2009 2:50 PM > To: 'Warren Johnson'; arin-ppml at arin.net > Subject: RE: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation > Process > > Warren > > My answer would be "we didn't have enough software types in the room > during the discussions on creating v6" to point out the implications > of that fact. > > Although a long term v6 advocate, I did not fully realize what we had > done to ourselves till I did a Master's project paper on v6 migration > a few years ago. After doing that, I realized that with current > transition technologies, we end up with an ugly v4-v6 transition layer > consisting of many different v4-v6 technologies (and some at the > individual app level) in our IT infrastructure architecture for > probably decades. And that layer also has very severe implications > for an IT security infrastructure. > > If we had a simple straight forward transition mechanism, v6 would > have taken off years ago. Hindsight is 20-20; foresight though isn't > (maybe 20-2000). > > Take care > Terry > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] > > On Behalf Of Warren Johnson > > Sent: Monday, November 16, 2009 12:30 PM > > To: arin-ppml at arin.net > > Subject: Re: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation > > Process > > > > Stupid question here: why wasn't v6 designed to be backwards > > compatible with v4? Just not possible? > > > > > > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] > > On Behalf Of Davis, Terry L > > Sent: Monday, November 16, 2009 2:03 PM > > To: 'Steve Bertrand'; arin-ppml at arin.net > > Subject: Re: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation > > Process > > > > Steve > > > > I like it also. One of our biggest problems is that we simply do > > not have enough really large scale IPv6 deployments around the globe > > to begin to understand all the problems or to come up with better > > migration/integration plans between v4 and v6. This should spur > > more use IPv6; as it is today, not even the green field startups are > > using > > v6 and this should tell us something about our current assumptions > > and policies. > > > > In retrospect, by not having a seamless, easy to use method, of > > allowing > > v4 > > to v6 communications, we have made deploying v6 very costly; > > migrating our millions of v4 based apps to v6 comes with both a huge > > price tag for opening and dual-stacking them and a corresponding > > "risk" factor for business continuity associated with that work. > > > > Take care > > Terry > > > > > -----Original Message----- > > > From: arin-ppml-bounces at arin.net > > > [mailto:arin-ppml-bounces at arin.net] > > > On Behalf Of Steve Bertrand > > > Sent: Friday, November 13, 2009 8:20 PM > > > To: arin-ppml at arin.net > > > Subject: Re: [arin-ppml] Policy Proposal 103: Change IPv6 > > > Allocation Process > > > > > > Member Services wrote: > > > > > > > Policy Proposal 103: Change IPv6 Allocation Process > > > > > > I'm very, very interested in this proposal, and would like to give > > > it a bump in hopes that it will spur more feedback and discussion > > > than what it's received thus far. > > > > > > Truthfully, I would like to get a feel on the number of people who > > > like it (I certainly do). If anyone has disregarded or overlooked > > > the proposal because of the recommended financial figures, please > > > let that be known as well. > > > > > > Complete original proposal message has been left intact below. > > > > > > Steve > > > > > > > > > > Proposal Originator: William Herrin > > > > > > > > Proposal Version: 1.0 > > > > > > > > Date: 9 November 2009 > > > > > > > > Proposal type: new > > > > > > > > Policy term: permanent. > > > > > > > > Policy statement: > > > > > > > > Strike NRPM sections: 6.2.3, 6.2.4, 6.2.6-6.2.9, 6.4.3, 6.4.4, > > > > 6.5.1-6.5.5, 6.5.8, 6.7, 6.10 > > > > > > > > Strike NRPM section 6.9 paragraph 2. > > > > > > > > Replace 6.2.5 as follows: > > > > > > > > 6.2.5 Allocate and Assign > > > > > > > > For the purposes of NRPM section 6, allocate and assign are > > > > synonymous. Both terms describe any or all use identified in > > > > section 2.5. > > > > > > > > Replace 6.5.7 with: > > > > > > > > 6.5.7. Existing IPv6 address space holders > > > > > > > > Organizations that received IPv6 allocations under the previous > > > > IPv6 address policy are entitled to either retain those > > > > allocations as is or trade them in for an allocation under 6.5.9. > > > > > > > > Add NRPM section 6.5.9 as follows: > > > > > > > > 6.5.9 IPv6 Allocations > > > > > > > > 6.5.9.1 ARIN shall allocate IPv6 address blocks in exactly and > > > > only the following denominations: /56, /48, /40, /32, /24 > > > > > > > > 6.5.9.2 No utilization-based eligibility requirements shall > > > > apply to > > > > IPv6 allocations. > > > > > > > > 6.5.9.3 ARIN shall accept registration of no more than one > > > > address block of each size for any single organization. > > > > > > > > 6.5.9.4 ARIN shall allocate IPv6 addresses from pools such that > > > > the identity of the allocation pool serves to classify the > > > > expected size of allocations within. ISPs may use that > > > > classification to filter or otherwise manage their routing tables. > > > > > > > > 6.5.9.5 For each allocation size, ARIN shall further manage the > > > > allocation pools such that the pool identity serves to classify > > > > whether or not the registrant is Multihomed. > > > > > > > > 6.5.9.6 ARIN shall offer addresses from pools classified as > > > > multihomed only to organizations which ARIN has verified are > > > > multihomed on the public Internet per NRPM 2.7. > > > > > > > > 6.5.9.7 Where an organization ceases to be Multihomed it shall > > > > surrender all address allocations from within pools classified > > > > as multihomed within 3 months. > > > > > > > > > > > > Rationale: > > > > > > > > See the implementation notes section below for what should > > > > replace utilization-based eligibility. > > > > > > > > The existing IPv6 allocation policy under section 6.5 makes a > > > > number of unproven assumptions about how IPv6 allocations will work. > > > > > > > > Unproven: we can make a reasonable guess about how many IPv6 > > > > subnets an organization will need at the outset when they first > > > > request IP addresses. When in all of human history has this ever > > > > proven true of any resource? > > > > > > > > Unproven: with sparse allocation, we can allow organizations to > > > > expand by just changing their subnet mask so that they don't > > > > have to announce additional routes into the DFZ. This claim is > questionable. > > > > With sparse allocation, we either consume much larger blocks > > > > that what we assign (so why not just assign the larger block?) > > > > or else we don't consume them in which case the org either has > > > > to renumber to expand or he has to announce a second route. > > > > Worse, because routes of various sizes are all scattered inside > > > > the same address space, its impractical to filter out the traffic engineering routes. > > > > > > > > Unproven: we can force organizations not to disaggregate for > > > > traffic engineering purposes. Neither any of our experience with > > > > IPv4 nor any of the research in the IRTF Routing Research Group > > > > suggests that this is even remotely practical so long as BGP or > > > > any similar system rules the roost. > > > > > > > > Unproven: all non-ISPs can be reasonably expected to get their > > > > address space from ISPs instead of from ARIN. We can certainly > > > > operate that way, but it could prove deadly to the routing table. > > > > Any organization multihomed between two ISPs will need to > > > > announce that route via BGP, regardless of where they get the > > > > address space from. We have knobs and dials in the routers that > > > > let us easily filter disaggregates from distant announcements, > > > > but we don't dare do so if there is a possibility that one of > > > > those disaggregates is a multihomed customer rather than traffic engineering. > > > > > > > > Benefits of this proposal: > > > > > > > > A. Efficient allocation of IP addresses. Orgs get what they need > > > > when they need it without a great deal of guesswork. > > > > > > > > B. Efficient utilization of BGP routing slots. No multihomed > > > > orgs will announce more than five unfilterable routes, and that > > > > only if they're so large that they can afford the price tag for > > > > the biggest address blocks. That's a good thing since IPv6 > > > > routes that propagate worldwide may impose an annual systemic > > > > overhead cost on ISPs of as much as US $16,000 each. > > > > > > > > C. Traffic engineering routes are trivially filterable. Any > > > > route longer than the published allocation size can be presumed > > > > to be traffic engineering, not a downstream multihomed customer, > > > > thus you can filter distant small routes with confidence and ease. > > > > > > > > D. Fair. No need to define the difference between ISP and not ISP. > > > > Everybody plays by the same rules. > > > > > > > > E. No complicated analysis for allocation. You pay for what you > > > > want and get what you pay for. You're either multihomed or > > > > you're > not. > > > > > > > > F. Gets ARIN out of the business of being the gatekeeper for > > > > Internet routing policy. By classifying allocations instead of > > > > making eligibility decisions, ARIN empowers the ISPs to set > > > > appropriate routing eligibility policies instead. > > > > > > > > FAQ > > > > Q. Isn't this classfull addressing all over again? > > > > A. Yes. > > > > Classful addressing had a lot of virtues with respect to route > > > > filtering and management. We had to abandon it because there > > > > weren't enough B's for everyone who needed more than one C and > > > > there weren't enough A's period. With IPv6, we don't have that > > > > problem. Not yet and maybe not ever. Perhaps we can have our > > > > cake > and > eat it too. > > > > > > > > Q. What if I don't want to accept /56 routes for single-homed users? > > > > > > > > A. This policy proposal intentionally and fully places backbone > > > > routing policy in the hands of the ISPs who operate the > > > > Internet's "Default-Free Zone (DFZ)," colloquially known as the > > > > Internet backbone. The author expects that some of the > > > > allocations, especially some of the single-homed allocations, > > > > *will not* be routable on the public Internet. When we hold a > > > > general expectation that all of ARIN's allocations will be > > > > routable, we effectively mean that ARIN decides what the > > > > Internet routing policy will be. That's precisely the role this > > > > proposal removes from ARIN's hands and > > restores > > to the ISPs. > > > > > > > > Q. Spell it out for me. How exactly will pools and size > > > > classifications enable route filtering? > > > > > > > > A. Suppose ARIN holds 4000::/12. ARIN might split it up as follows: > > > > > > > > 4000::/13 -- reserved > > > > 4008::/15 -- multihomed /24 allocations > > > > 400a::/15 -- non-multihomed /24 allocations > > > > 400c::/16 -- multihomed /32 allocations > > > > 400d::/16 -- non-multihomed /32 allocations > > > > 400e:0000::/18 -- multihomed /40 allocations > > > > 400e:4000::/18 -- non-multihomed /40 allocations > > > > 400e:8000::/24 -- multihomed /48 allocations > > > > 400e:8100::/24 -- non-multihomed /48 allocations > > > > 400e:8200::/24 -- multihomed /56 allocations > > > > 400e:8300::/24 -- non-multihomed /56 allocations > > > > 400e:8400::/22 -- reserved > > > > 400e:8800::/21 -- reserved > > > > 400e:9000::/20 -- reserved > > > > 400e:a000::/19 -- reserved > > > > 400e:c000::/18 -- reserved > > > > 400f::/16 -- reserved > > > > > > > > Now, you're an ISP. Here's a sample routing policy you might choose: > > > > > > > > Accept any routes to /32 because anyone paying $10k per year for > > > > addresses is big enough to ride. > > > > For /24 allow 2 bits of traffic engineering too. > > > > Single-homers who won't spend $10k/year on their addresses > > > > (smaller than /32) must use addresses from their ISP. Tough luck. > > > > Accept multihomers down to /48. > > > > The folks paying only $10/year for /56's aren't serious. > > > > > > > > Your route filter looks like this: > > > > > > > > accept 400e:8000::/24 equal 48 > > > > accept 400e:0000::/18 equal 40 > > > > accept 400c::/15 equal 32 > > > > accept 4008::/14 le 26 > > > > reject 4000::/12 le 128 > > > > > > > > Note how 400e:8000::/24 contains only /48 allocations and you're > > > > allowing only /48 announcements. Since there aren't any /47 or > > > > /46 allocations there, nobody in the pool can slip TE routes past you. > > > > On the other hand, you'll get some benefit of traffic > > > > engineering from the super-massive /24 registrants up in > > > > 4008::/14 because you're allowing them to disaggregate down to /26. > > > > > > > > Q. If its so expensive to announce routes into the DFZ, why not > > > > use something better than BGP? > > > > > > > > A. In 2008 the IRTF Routing Research Group compiled an > > > > exhaustive study attempting to identify the possible ways to > > > > improve the routing system. A draft of the results is at > > > > http://tools.ietf.org/html/draft-irtf-rrg-recommendation-02 . > > > > While there are many promising ideas for how to replace BGP with > > > > something that scales better, we're at least a decade away and > > > > probably more from any significant deployment of a BGP replacement. > > > > > > > > Q. Is it really true that multihoming requires announcing a > > > > route via BGP? > > > > > > > > A. The short answer is yes. The long answer is more complicated. > > > > > > > > Folks have tried very hard to devise multi-vendor multihomed > > > > systems which don't rely on BGP. The only approach that has ever > > > > come near success is dynamically changing DNS records to favor > > > > the currently working Internet connection. "Near" is a relative > > > > term here. Such network architectures are enormously complex and > > > > they don't work especially well. The DNS protocol itself > > > > supports quick changes but the applications which use it often > > > > don't. It takes hours to achieve two-nines recovery from an > > > > address change in the DNS and it takes months to achieve > > > > five-nines recovery. Web browsers, for example, don't > > > > immediately recover. Search google for > "DNS Pinning." > > > > > > > > Q. So the Internet's resulting route policy will be to allow all > > > > the sizes that no major ISP decides to filter and restrict the rest? > > > > > > > > A. That's one possible outcome. On the other hand, research in > > > > the routing field suggests that with a sufficiently rich > > > > classification scheme, it may be possible to implement lower > > > > priority systems with provider-independent addresses yet without > > > > a global route. Hints for how such a thing might work can be > > > > found in http://www.cs.cornell.edu/people/francis/va-wp.pdf and > > > > http://bill.herrin.us/network/trrp.html. Such schemes need a > > > > rich classification process at the address allocation level that > > > > makes it possible for ISPs to make reasonable and simple > > > > decisions about which routes should be distributed to every DFZ > > > > router and which > > should > > not. > > > > > > > > Wouldn't that be something: IPv6 provider independent addresses > > > > for everybody without materially increasing the cost of the > > > > routing system. > > > > > > > > Q. Why allocate the /48's from a pool only for /48's, /32's from > > > > a > > > > /32 pool, etc.? Why not allocate from just one pool? > > > > > > > > A. If all assignments in a particular pool are /32 then any > > > > route in the /32 pool which is longer than /32 is a traffic > > > > engineering > > > > (TE) route. As a router operator you can filter and discard TE > > > > routes if you find they give you insufficient benefit. The > > > > routes you filter don't cost you any money; only the routes you > > > > keep carry > a > price tag. > > > > > > > > You can only filter if you're sure they're TE routes... If > > > > they're distinct downstream customer routes and you filter them, > > > > there goes the Internet. Or at least there goes your part of it. > > > > See > customers. > > > > See customers run... straight to your competitor. Setting up the > > > > distinct pools makes it practical to know with certainty whether > > > > the routes you're filtering are only for TE. > > > > > > > > Q. Why allow only one allocation of each particular size? > > > > > > > > A. Without the address scarcity issue which drives IPv4 policy, > > > > the primary criteria for IPv6 addressing policy is suppressing > > > > the disaggregation that drives route count in the IPv4 DFZ (NRPM 6.3.8). > > > > Such a criteria is not well served if an organization holds > > > > dozens of discontiguous address spaces as a result of > > > > acquisitions, mergers and and growing a little bit at a time. > > > > This proposal says, in effect, once you've consumed your smaller > > > > allocation it's time for you to get a *much* bigger allocation. > > > > The rest of us don't want to pay the routing table price for you > > > > coming back again and again and > > again. > > > > > > > > The proposal could require some renumbering as a result of > > > > mergers and acquisitions. However, with only modest planning on > > > > the registrant's part, the policy its flexible enough to allow > > > > that renumbering to occur over a long period of time so that > > > > both cost and disruption are minimized. In many cases, customer > > > > churn can be expected to take care of much of the renumbering > > > > activity all by > > itself. > > > > > > > > Q. What about the IETF recommendations? > > > > > > > > A. RFC 3177 recommends that ISPs receive a /32 while downstream > > > > customers receive a /48 assignment by default with so-called > > > > "sparse allocation" to allow those assignments to expand by > > > > changing the netmask. While this proposal supports organizations > > > > who wish to follow those recommendations, it is not this > > > > proposal's intention that ARIN follow RFC 3177. > > > > > > > > RFC 3177 is not the gospel truth. It was written back in 2001 > > > > when there was little IPv6 outside of academia and, indeed, > > > > little IPv6 at all. It's an engineers' SWAG about what > > > > operations folk should do that's now 8-years-stale. > > > > > > > > This proposal attempts to slow-start IPv6 allocations instead, > > > > while still maintaining the principle of suppressing the routing > table > size. > > > > As an ISP, consider implementing a slow start for your > > > > downstream customers as well: Give them a /60 initially, add a > > > > /56 when they need it and add a /52 when they run out of the > > > > /56. A /60 is 16 > > > > /64 subnets. That's an internal LAN, a DMZ and 14 more subnets. > > > > Just how many subnets do you think your normal downstream > > > > customer will actually use? > > > > > > > > Q. What happens when organizations merge or split? > > > > > > > > A. Entities which merge may renumber out of and return > > > > conflicting allocations, or they may maintain the existence of > > > > the acquired organization in order to keep it's addresses. > > > > Either way it should be a minor hardship. > > > > > > > > Entities which split have a bigger problem since the practical > > > > effect of route filtering may be that only one of them can keep > > > > the addresses. To a large extent, that problem already exists > > > > and is a pain in the rump for IPv4 operations today. This policy > > > > doesn't solve it but it doesn't make it a whole lot worse either. > > > > Because disaggregates are likely to be filtered, this IPv6 > > > > policy does gives us a slightly better guarantee that the rest > > > > of us won't get stuck with the check (in the form of routing > > > > slot > > > > consumption) when an ISP goes bankrupt and gets split up. > > > > > > > > Q. What about IPv6 addresses for uses which will not be > > > > connected to the Internet at all? > > > > > > > > A. Folks are welcome to get non-multihomed addresses for any > > > > purpose whatsoever. If they do eventually decide to connect to > > > > the Internet, the routes will follow whatever rules the ISPs > > > > have imposed for routes within the single-homed pools. > > > > > > > > Q. What about reporting requirements for downstream assignments? > > > > > > > > A. Reporting requirements were instituted for the purpose of > > > > verifying eligibility for additional allocations. They have > > > > proven useful for other purposes and the author encourages ARIN > > > > to maintain the SWIP system. Nevertheless, this proposal renders > > > > the use of SWIP for IPv6 optional since it is no longer needed > > > > to verify eligibility for allocations. > > > > > > > > Q. What if I need more than a /24? > > > > > > > > A. This proposal's author asserts as obvious: anyone who defines > > > > a need for more than a trillion subnets should make their case > > > > publicly on PPML, seeking a follow-on proposal that establishes > > > > address pools at the /16 level. > > > > > > > > Q. What are the struck sections of the current IPv6 policy and > > > > why should they be struck? > > > > > > > > A. 6.2.3 - 6.2.9 define terms that have no meaning or use in the > > > > policy as revised by this proposal. > > > > > > > > The 6.4.3 notion of a minimum allocation is obsoleted by the > > > > allocation pools of specific size in this proposal. > > > > > > > > 6.4.4 is moot as this proposal does not expect registrants to > > > > justify their IPv6 allocation size. > > > > > > > > 6.5.1 - 6.5.4 and 6.5.8 are replaced entirely by 6.5.9. > > > > > > > > 6.5.5 is largely moot since it's no longer necessary to confirm > > > > downstream assignments in order to determine eligibility for > > > > additional addresses. > > > > > > > > 6.7 is moot as it is unnecessary to compute utilization to > > > > justify addresses under this proposal. > > > > > > > > 6.9 paragraph 2 is moot since utilization is not a factor in > > > > IPv6 policy under this proposal. > > > > > > > > 6.10 is redundant since micro-allocations are trivially > > > > accomplished under 6.5.9. > > > > > > > > > > > > Implementation notes: > > > > > > > > To prevent wasteful consumption of IPv6 address space without a > > > > complicated eligibility regime, the author recommends an initial > > > > and annual fee regime for IPv6 address allocations similar to: > > > > > > > > /56 -- $10 USD > > > > /48 -- $100 USD > > > > /40 -- $1000 USD > > > > /32 -- $10,000 USD > > > > /24 -- $100,000 USD > > > > Legacy -- the lesser of the cost of the next larger size or the > > > > cost of the next smaller size times the number encompassed by > > > > the registration. > > > > > > > > The above notwithstanding, it may be advisable to discount /40s > > > > and /32s to a much lower price during IPv6's general deployment > > > > process in order to encourage adoption. Folks who already hold > > > > /31's should probably also get a big break on the $20k fee for a > > > > good long while, perhaps until the first time they request an > > > > additional block without offering a plan to return the legacy > addresses. > > > > > > > > For verification of multihoming, the current way ARIN verifies > > > > multihoming for other parts of it's policy appears satisfactory. > > > > Should that change, the author suggests requiring that the AS# > > > > contacts for at least two AS#'s submit a template indicating > > > > that they intend to originate or propagate IPv6 BGP routes from > > > > the registrant's ORG. > > > > > > > > Timetable for implementation: immediate > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > PPML > > > > You are receiving this message because you are subscribed to the > > > > ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > > > Unsubscribe or manage your mailing list subscription at: > > > > http://lists.arin.net/mailman/listinfo/arin-ppml > > > > Please contact info at arin.net if you experience any issues. > > > > > > _______________________________________________ > > > PPML > > > You are receiving this message because you are subscribed to the > > > ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > > Unsubscribe or manage your mailing list subscription at: > > > http://lists.arin.net/mailman/listinfo/arin-ppml > > > Please contact info at arin.net if you experience any issues. > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to the > > ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to the > > ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From bill at herrin.us Mon Nov 16 16:51:33 2009 From: bill at herrin.us (William Herrin) Date: Mon, 16 Nov 2009 16:51:33 -0500 Subject: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process In-Reply-To: References: <4AF86E15.2060307@arin.net> Message-ID: <3c3e3fca0911161351s111fe22ep9e213df6c32d122a@mail.gmail.com> On Mon, Nov 16, 2009 at 1:30 PM, George, Wes E [NTK] wrote: > I'm opposed to this proposal. Hi Wes, Thanks for the feedback. I hope I can address some of your concerns and convince you to reconsider some of the others. > I simply don't think that it's really practical to filter > traffic-engineering deaggregations without providing > networks an alternate method to manage their traffic > - there's a real quagmire in determining what is "distant" > and therefore ok to filter vs what is not, especially when > you're trying to do it with standardized route-policies. I don't know how -exactly- how the traffic engineering process would change under this proposal, if at all. As you rightly point out, it's a complex dance. This proposal doesn't preclude using disaggregation for TE, but it does alter the dynamics of the dance. In the current routing system, TE by disaggregation is a fact of life. You'll carry it (and pay for it) whether it helps you better communicate with the remote system or not because you can't efficiently get rid of it. Under this proposal, you have the right *and* the ability to reject disaggregate TE that doesn't do you any good. That doesn't mean you'll reject all TE. Where your network performs better as a result of someone else's TE, you're as likely to use it as you are to use BGP communities today. On the other hand, when Bell South comes along and offers 4300 routes, you'll probably say: nope. You're cut. I'll take your aggregate and your top few disaggregates, and that's it. And you'll have that power. > of the claimed benefits, so this would at the very least > need to be a global policy. Pushing this as a global coordinated policy has two major risks associated with it. The first is that it takes much longer to negotiate a global policy, so IPv6 policy will still be in flux much closer to the IPv4 run-out. That's not a good thing. The second is: what if we're wrong? You're right to observe that this proposal is a radical departure from existing allocation policy. If by chance it makes things worse rather than better, it would be good if that only impacted one region and harmed the multinationals not at all. I respectfully disagree that we won't see any of the benefits without a global policy. Operators in the RIPE and APNIC regions are just as capable of filtering announcements from the ARIN region on classification boundaries as anyone else is. Whatever benefit there is to be had, we should see 10%-20% of it in a single-region policy. If the benefit proves enough, I think it likely that the other regions will move to adopt similar policies without needing coordination or, frankly, much of a push. > In my opinion, an IETF draft that updates RFC3177 > would be even more helpful, since that would help > to discuss the implications to the routing system > within the body most equipped to evaluate it. My experience has been that groups like NANOG and, to the extent that it impacts addressing, PPML are better equipped to address operations issues than the IETF. That's why many if not most of the successful RFC's get written as BCPs after the fact. That's also after I spent the past several years participating in the IETF's routing WG's. Brilliant folks in the IETF, without exception, but folks with an operations bent are sparse on the ground. > I have a major problem with the fact that this proposal > as written doesn't seem to give any guidance as to how > ARIN staff would determine who gets what size allocation, The guidance is very simple: the registrant gets whatever size he A) requests and B) pays for. That's it. Look at it this way: who am I to tell you how many IP addresses you need to do your job? I'm nobody. You are uniquely well qualified to strike the best balance between cost and size in your particular organization. If it isn't absolutely necessary for me to second guess your judgment in such matters, why should I? > Until people have really gotten away from the scarcity > mentality that accompanies IPv4 addressing, barring > any sort of justification requirement, most entities that > can afford it will ask for a /24 simply because they can. If you can afford to put $100k *per year* into IPv6 addresses, well first, thank you for the investment in IPv6. I appreciate your efforts. And second off, I want you to have a /24. Really. I do. With that financial pressure behind your endeavors, I want you to have every possible advantage. However... unless you're already in ARIN's X-Large class, I doubt you're going to be willing to cough up $100k for IPv6 addresses. For the sake of the argument, let's assume that all the X-Large's will be willing to do so. How many orgs is that? Less than 1000 worldwide? > you are actually creating a disincentive to building > big networks under one block - instead of getting > a /24 because I need a bit more than a /32, I might > get a /32 and a /40, thereby adding an entry in the > routing table to save money. That's a risk. BUT, the /40 has less than half a percent of the space in the /32. You'd have to need only a hairs breadth more space than the /32 with no expectation of growing. You might add the /40 anyway for the sake of getting a little bit of TE ability. But that's a feature, not a bug: a well regulated safety release valve for the folks who really do need a little alternate routing but aren't big enough to afford the top end allocations where some disaggregation is likely to be allowed. > your suggested fees likely don't even cover ARINs costs of administration at the low end. Absent a need to evaluate the application's legitimacy, you can run it like the DNS. DNS runs fine under $10 per registration-year. > Also, I think this moves towards a system where there >really is no concept of/use for PD space anymore. What >incentive is there to get PD space and be forced to >renumber if you change ISPs when you can so easily >(and under your suggested fee structure, cheaply!) >qualify for PI space? I would expect ISPs to exclude routes within the smaller single-homed ARIN blocks for precisely that reason. Wouldn't you? If an org has to choose between paying $1k/year for addresses and using their ISP's addresses, most will choose to use their ISP's addresses and deal with the renumbering. If they have to choose between that and $10k, well, these are single-homed folks. For many, adding an extra $10k would mean paying three times as much per year for Internet service than they already do. Where the extra $10k is not an obstruction, aren't those the same folks you would expect to qualify for addresses based on utilization anyway? > I have no way to aggregate it, and no choice but to carry it. You do have a choice. I respect that you're not used to making a choice; you've been able to rely on ARIN to make it for you. To be frank, the whole point of the $10 /56 level is to put you into a position as an ISP where you have to make a choice about filtering because you can't rationally carry those routes on your big iron. I *DO NOT* seriously expect you to carry single-homed /56's in the DFZ. I would also offer the following point: if you really would prefer that ARIN be the gatekeeper for Internet routing policy in North America then we ought to stop playing the "ARIN isn't responsible for routing" game. Trying to have it both ways helps nobody. > You also need to address how existing allocations that > don't fall on those rigid boundaries would be handled. My > organization, for example, has a /29. That means ARIN > needs to be able to give me the extra bits in order to > magically make that into a /24. If ARIN didn't allocate > sparsely enough to make that work and I have to > renumber, how long do I have? My intention in the proposal was that you keep the /29 for as long as you want (don't renumber unless you want to!) and it counts under the new policy as your choice of a /32 or a /24, making you eligible to add either a /24 or a /32 but not both. My intention was also that the /29 *would not* be expandable to a /24, even if ARIN reserved enough space to do so. That's the IPv6 swamp and we're stuck with it but let's not make it any worse than it already is. > Another question I do think is largely unanswered is some > manner of estimate of how much address space (in terms > of number of networks) going back to something like classful > address allocation would cost us [...] compared with other > options like sparse allocation. Well, sparse is easy. 200 /56 allocations inside your /29 costs 8 bits leaving you with /37 as your largest possible remaining allocation. But, each of the /56's is, at that point, also capable of expanding to /37 via a netmask change. With the method described in this proposal, there's no need and indeed no reason to leave space between allocations, so the same 200 /56's consume part of one /48, leaving the largest remaining allocation in your /29 at /30. However, any of the /56's who need more addresses will add a /48 instead of being able to expand their /56. >From an address conservation perspective, this proposal's allocation method should come out way ahead of sparse. Sparse is incredibly wasteful of address space. >From a route table conservation perspective, it's a tougher call. Your 99th percentile organization won't afford a /24 and the /56 won't be routable so that means you can push four routes unless other ISPs decide to allow more. That's less than half of where we're at in the IPv4 table today. On the other hand, your /29 disaggregates to 8 /32's and when ARIN expands it to a /28, that gives you 16 /32's. And you're big enough that you'll probably announce them as /32's for the sake of TE. Worse will happen in the /48 pool where /40's won't be uncommon. And there will be a /48 pool that you'll have to carry because /48 cutouts of your /32 won't be routable and multihomed downstreams do still have to work... My gut says that the disaggregability of the current /48 pool combined with it's need to be routable in the current structure and combined with the desirability of traffic engineering means we're going to have an IPv4-like bloat while this proposal tends to put a harder limit on what will end up being allowed in the routing table. > but I am one of those who is worried about us not learning > from history. As am I. What do you make of the following history lesson: When the prior version of the Internet Protocol was replaced with IPv4, each organization which had a single address in the old scheme was assigned a class A, four tenths of a percent of the new protocol's total address space. The lesson I take is this: the allocation process for the prior protocol offers a poor guide for the new one. Try to treat the new protocol conservatively, not in relation to how the old protocol functioned, but in relation to how the new protocol functions. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Mon Nov 16 17:01:30 2009 From: bill at herrin.us (William Herrin) Date: Mon, 16 Nov 2009 17:01:30 -0500 Subject: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process In-Reply-To: <339F6302D15646D9A29EE3CFF0CF3310@johnsonvhjjf8v> References: <4AF86E15.2060307@arin.net> <4AFE3008.3000904@ibctech.ca> <0267B5481DCC474D8088BF4A25C7F1DF55127B074A@XCH-NW-05V.nw.nos.boeing.com> <7F1CF82C4623478B8F18B392B94CE37E@johnsonvhjjf8v> <0267B5481DCC474D8088BF4A25C7F1DF55127B074B@XCH-NW-05V.nw.nos.boeing.com> <339F6302D15646D9A29EE3CFF0CF3310@johnsonvhjjf8v> Message-ID: <3c3e3fca0911161401h2343ebe5wee756bc934f029c8@mail.gmail.com> On Mon, Nov 16, 2009 at 3:54 PM, Warren Johnson wrote: > Instead of spending the next two decades trying to get people migrated over > maybe we should just scrap v6 and create "v7" and make it backwards > compatible with v4. ?I guess we're not at that point yet because we just > don't know what's going to happen post-runout. http://bill.herrin.us/network/ipxl.html :P -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Mon Nov 16 17:27:58 2009 From: bill at herrin.us (William Herrin) Date: Mon, 16 Nov 2009 17:27:58 -0500 Subject: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process In-Reply-To: <4AF86E15.2060307@arin.net> References: <4AF86E15.2060307@arin.net> Message-ID: <3c3e3fca0911161427n4bc329c9i15dd013b752c1b00@mail.gmail.com> On Mon, Nov 9, 2009 at 2:31 PM, Member Services wrote: > Policy Proposal 103: Change IPv6 Allocation Process Hi folks, I received a question in a private email which strikes me as a thorny one. I'd like to open it for discussion. The question was: > a single organization can have multiple > OrgIDs at ARIN as long as each one can independently justify its resources. > Would this policy allow an organization to have multiple OrgIDs, with each > one obtaining as many prefixes as they can under this policy? Having no restrictions on OrgIDs would defeat 6.5.9.3. So how would we restrict it without either going overboard or creating excessive work for ARIN? My knee-jerk reaction is something like this: 6.2.10 Organization An organization under section 6 is either: one or more legal entities under common control or ownership, or one such legal entity which operates a strictly separate network from the others. Thoughts? Alternatives? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mcr at sandelman.ca Mon Nov 16 18:30:41 2009 From: mcr at sandelman.ca (Michael Richardson) Date: Mon, 16 Nov 2009 18:30:41 -0500 Subject: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process In-Reply-To: <0267B5481DCC474D8088BF4A25C7F1DF55127B074B@XCH-NW-05V.nw.nos.boeing.com> References: <4AF86E15.2060307@arin.net> <4AFE3008.3000904@ibctech.ca><0267B5481DCC474D8088BF4A25C7F1DF55127B074A@XCH-NW-05V.nw.nos.boeing.com> <7F1CF82C4623478B8F18B392B94CE37E@johnsonvhjjf8v> <0267B5481DCC474D8088BF4A25C7F1DF55127B074B@XCH-NW-05V.nw.nos.boeing.com> Message-ID: <4814.1258414241@marajade.sandelman.ca> >>>>> "Terry" == Terry L Davis writes: Terry> Warren Terry> My answer would be "we didn't have enough software types in Terry> the room during the discussions on creating v6" to point out Terry> the implications of that fact. Terry> Although a long term v6 advocate, I did not fully realize Terry> what we had done to ourselves till I did a Master's project Terry> paper on v6 migration a few years ago. After doing that, I v6 is completely upward compatible with v4. Watch this: marajade-[~] mcr 10001 %telnet -6 ::ffff:209.87.252.178 Trying ::ffff:209.87.252.178... Connected to ::ffff:209.87.252.178. Escape character is '^]'. tcp6 0 0 209.87.252.196:43185 209.87.252.178:23 ESTABLISHED It works fine. It uses v4 at the network layer, but the application thinks it has v6. What we did not do was make IPv4 compatible with v6, or any other new protocol. No v7, or any other thing would have accomplished that. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From scottleibrand at gmail.com Mon Nov 16 19:40:14 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 16 Nov 2009 18:40:14 -0600 Subject: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process In-Reply-To: <3c3e3fca0911161427n4bc329c9i15dd013b752c1b00@mail.gmail.com> References: <4AF86E15.2060307@arin.net> <3c3e3fca0911161427n4bc329c9i15dd013b752c1b00@mail.gmail.com> Message-ID: Another consideration is Multiple Discrete Networks. Scott On Nov 16, 2009, at 4:27 PM, William Herrin wrote: > On Mon, Nov 9, 2009 at 2:31 PM, Member Services wrote: >> Policy Proposal 103: Change IPv6 Allocation Process > > Hi folks, > > I received a question in a private email which strikes me as a thorny > one. I'd like to open it for discussion. The question was: > >> a single organization can have multiple >> OrgIDs at ARIN as long as each one can independently justify its >> resources. >> Would this policy allow an organization to have multiple OrgIDs, >> with each >> one obtaining as many prefixes as they can under this policy? > > Having no restrictions on OrgIDs would defeat 6.5.9.3. So how would we > restrict it without either going overboard or creating excessive work > for ARIN? > > My knee-jerk reaction is something like this: > > > 6.2.10 Organization > > An organization under section 6 is either: > > one or more legal entities under common control or ownership, or > > one such legal entity which operates a strictly separate network from > the others. > > > Thoughts? Alternatives? > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From michael.dillon at bt.com Tue Nov 17 06:22:16 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 17 Nov 2009 11:22:16 -0000 Subject: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process In-Reply-To: <3c3e3fca0911161401h2343ebe5wee756bc934f029c8@mail.gmail.com> Message-ID: <28E139F46D45AF49A31950F88C497458041A758D@E03MVZ2-UKDY.domain1.systemhost.net> > http://bill.herrin.us/network/ipxl.html That is a web page. Protocols are not found on web pages, but in functioning routers. Where is your functioning IPxl router? Also, what does this achieve that could not be achieved with the IPv6 address ::192.168.100.1? That is a valid IPv6 address but unfortunately it does not contain sufficient magic to allow IPv4 and IPv6 interfaces to communicate with each other. --Michael Dillon From Wesley.E.George at sprint.com Tue Nov 17 14:27:52 2009 From: Wesley.E.George at sprint.com (George, Wes E [NTK]) Date: Tue, 17 Nov 2009 13:27:52 -0600 Subject: [arin-ppml] FW: Policy Proposal 103: Change IPv6 Allocation Process Message-ID: -----Original Message----- From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf Of William Herrin Sent: Monday, November 16, 2009 4:52 PM To: George, Wes E [NTK] Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process On Mon, Nov 16, 2009 at 1:30 PM, George, Wes E [NTK] wrote: > I'm opposed to this proposal. > I simply don't think that it's really practical to filter > traffic-engineering deaggregations without providing > networks an alternate method to manage their traffic > - there's a real quagmire in determining what is "distant" > and therefore ok to filter vs what is not, especially when > you're trying to do it with standardized route-policies. I don't know how -exactly- how the traffic engineering process would change under this proposal, if at all. As you rightly point out, it's a complex dance. This proposal doesn't preclude using disaggregation for TE, but it does alter the dynamics of the dance. In the current routing system, TE by disaggregation is a fact of life. You'll carry it (and pay for it) whether it helps you better communicate with the remote system or not because you can't efficiently get rid of it. Under this proposal, you have the right *and* the ability to reject disaggregate TE that doesn't do you any good. That doesn't mean you'll reject all TE. Where your network performs better as a result of someone else's TE, you're as likely to use it as you are to use BGP communities today. On the other hand, when Bell South comes along and offers 4300 routes, you'll probably say: nope. You're cut. I'll take your aggregate and your top few disaggregates, and that's it. And you'll have that power. [weg] I'd argue that I have the right and the ability to reject disaggregate TE blocks today if they aren't helping my network. However, you're right in that it takes some fairly complex automation to digest the current allocations to determine what is filterable and what is not. Your policy does make that easier. However, I'm not sure that benefit in and of itself is enough to change my opinion that this isn't a good idea. > of the claimed benefits, so this would at the very least > need to be a global policy. Pushing this as a global coordinated policy has two major risks associated with it. The first is that it takes much longer to negotiate a global policy, so IPv6 policy will still be in flux much closer to the IPv4 run-out. That's not a good thing. [weg] agreed, but I don't think that it will have so much of an impact that an extra 6 months or a year (or more) would make enough difference that it doesn't make sense as a coordinated policy. The second is: what if we're wrong? You're right to observe that this proposal is a radical departure from existing allocation policy. If by chance it makes things worse rather than better, it would be good if that only impacted one region and harmed the multinationals not at all. [weg] that's fair. However, to quote Homer Simpson..."can't someone else do it?" I'd rather not play guinea pig in our region. I respectfully disagree that we won't see any of the benefits without a global policy. Operators in the RIPE and APNIC regions are just as capable of filtering announcements from the ARIN region on classification boundaries as anyone else is. Whatever benefit there is to be had, we should see 10%-20% of it in a single-region policy. If the benefit proves enough, I think it likely that the other regions will move to adopt similar policies without needing coordination or, frankly, much of a push. [weg] I think this hits on my concern - Your opinion and my opinion as to whether this is a good idea are still just opinions without some more analysis. We don't *know* that this will be any better. I'd rather you show your work - do some analysis of the current routing table to draw some conclusions about how much of an improvement we might actually see from something like this, both if just one region does it and if all regions do it BEFORE we implement it. Even if it's fairly simplistic and uses the IPv4 table + classful allocation (allocate the entirety of IPv4 space as many times as necessary), I'm not keen on recommending such a radical change without more analysis to back it up. > In my opinion, an IETF draft that updates RFC3177 > would be even more helpful, since that would help > to discuss the implications to the routing system > within the body most equipped to evaluate it. Brilliant folks in the IETF, without exception, but folks with an operations bent are sparse on the ground. [weg] no argument on lack of operator expertise and representation. Consider this a PSA to get more people on this list involved at IETF and vice versa. ;-) However, that aside, as I said above, this is a recommendation that needs more analysis as to its efficacy and impacts, not necessarily more operators to provide opinions. IETF (and IRTF) is good at analysis. > I have a major problem with the fact that this proposal > as written doesn't seem to give any guidance as to how > ARIN staff would determine who gets what size allocation, The guidance is very simple: the registrant gets whatever size he A) requests and B) pays for. That's it. Look at it this way: who am I to tell you how many IP addresses you need to do your job? I'm nobody. You are uniquely well qualified to strike the best balance between cost and size in your particular organization. If it isn't absolutely necessary for me to second guess your judgment in such matters, why should I? [weg] fair enough, but why are you trying to discourage me from asking for a /24 by making it prohibitively expensive then? If we're really trying to reduce the amount of overhead and justification because IPv6 is so vast and non-scarce, then make it easier to justify, don't remove the justification altogether and replace it with some pseudo-scarcity pricing model.. > Until people have really gotten away from the scarcity > mentality that accompanies IPv4 addressing, barring > any sort of justification requirement, most entities that > can afford it will ask for a /24 simply because they can. If you can afford to put $100k *per year* into IPv6 addresses, well first, thank you for the investment in IPv6. I appreciate your efforts. And second off, I want you to have a /24. Really. I do. With that financial pressure behind your endeavors, I want you to have every possible advantage. However... unless you're already in ARIN's X-Large class, I doubt you're going to be willing to cough up $100k for IPv6 addresses. For the sake of the argument, let's assume that all the X-Large's will be willing to do so. How many orgs is that? Less than 1000 worldwide? [weg] that's exactly my point. I'm in X-Large today, but there's a W I D E gap between the current fee and your proposed, even if I look at multiple org-IDs to add up the total money I'm paying to ARIN. I can afford 100K/year as an "investment in IPv6" but I would rather invest that in, you know, capital to actually make IPv6 work on my network, rather than a throwaway expense. I see no reason I should have to pay that much for a resource that is, by virtue of your advocating no use-based justification, *not* scarce. You have no way to discourage people for asking for /24s that they don't need without punishing those who actually do need one if you try to control it with pricing alone. > you are actually creating a disincentive to building > big networks under one block - instead of getting > a /24 because I need a bit more than a /32, I might > get a /32 and a /40, thereby adding an entry in the > routing table to save money. That's a risk. BUT, the /40 has less than half a percent of the space in the /32. You'd have to need only a hairs breadth more space than the /32 with no expectation of growing. [weg] ok, that was a bad example, but the mention of multiple discrete networks jogged my memory on the example I should have given, which is that today, many companies have multiple ORG-IDs, all of which are justifying their own IP space and paying their own fees. What's to stop me from using that as a means to get 3 /32s instead of the 1 /24 I really should have gotten? Your proposed text (your second message) does cover that by prohibiting it, but I'm sure there will be another loophole. I was a good boy and got all of my IPv6 space with the intention of breaking it up across all of my business areas instead of getting several smaller blocks, one for each org. If I have 3 orgs, I'm still saving myself $70K/year by getting each their own /32, which if you look at it selfishly, is more important than the additional routing slots I'm taking up in the DFZ, especially if my hypothetical company is one that doesn't have to carry the DFZ routing table. > Also, I think this moves towards a system where there >really is no concept of/use for PD space anymore. What >incentive is there to get PD space and be forced to >renumber if you change ISPs when you can so easily >(and under your suggested fee structure, cheaply!) >qualify for PI space? I would expect ISPs to exclude routes within the smaller single-homed ARIN blocks for precisely that reason. Wouldn't you? [weg] no, I wouldn't. See below. If an org has to choose between paying $1k/year for addresses and using their ISP's addresses, most will choose to use their ISP's addresses and deal with the renumbering. If they have to choose between that and $10k, well, these are single-homed folks. For many, adding an extra $10k would mean paying three times as much per year for Internet service than they already do. Where the extra $10k is not an obstruction, aren't those the same folks you would expect to qualify for addresses based on utilization anyway? [weg] I don't know, but every time we try to say "renumbering is easy" or "renumbering isn't a barrier to changing ISPs" we get shouted down by a bunch of folks who as far as I know are actual, real-live small ISPs who beg to differ. So I'll pose the question to the group - Is $1K/year a reasonable investment to ensure that you get PI space? What about $10K? What about $10? Could you live on a /56? > I have no way to aggregate it, and no choice but to carry it. You do have a choice. I respect that you're not used to making a choice; you've been able to rely on ARIN to make it for you. To be frank, the whole point of the $10 /56 level is to put you into a position as an ISP where you have to make a choice about filtering because you can't rationally carry those routes on your big iron. I *DO NOT* seriously expect you to carry single-homed /56's in the DFZ. [weg] I think you have a fundamental flaw in this assumption, and it basically breaks routing for any single-homed customer who chooses to use PI space. Let's say I'm opening "Wes's IPv6-only ISP" out of my garage. I get my $10 /56, and buy service from a single upstream. I'm doing static routing - I have a default, my upstream has a static route to me, which they are redistributing into BGP. It's PI space. How exactly would any ISP beyond the one I'm currently connected to (you know, the rest of the DFZ) be able to reach my lil' ol' /56 if my ISP isn't announcing it to the rest of the DFZ internet, or the rest of the DFZ internet isn't accepting my upstream's announcement? It's not like anyone is announcing a larger aggregate block, because the person who got the next /56 in that block may well be on a completely different ISP. Do you expect ISPs to just turn on auto-summary and hope that they get lucky enough to find some blocks that aggregate? Therefore that /56 is useless unless my ISP is so well-connected that I don't need to talk to anyone else, or I don't actually need routable space. So the "Sophie's choice" that you leave big ISPs with is either, carry a significant increase in routing state, or partition the internet. Yay, sign me up! Thanks for the "choice", ARIN! While I used /56 in this example because it's cheap, I think the same argument applies for /48s. The RIRs have already sort of forced this issue by allocating direct PI /48s, so I don't see why /56s would be any different. I would also offer the following point: if you really would prefer that ARIN be the gatekeeper for Internet routing policy in North America then we ought to stop playing the "ARIN isn't responsible for routing" game. Trying to have it both ways helps nobody. [weg] I never said I'd prefer ARIN to do it. I said that your policy, and things like direct /48 PI allocations is forcing ARIN to do so, as I detailed above. > You also need to address how existing allocations that > don't fall on those rigid boundaries would be handled. My > organization, for example, has a /29. That means ARIN > needs to be able to give me the extra bits in order to > magically make that into a /24. If ARIN didn't allocate > sparsely enough to make that work and I have to > renumber, how long do I have? My intention in the proposal was that you keep the /29 for as long as you want (don't renumber unless you want to!) and it counts under the new policy as your choice of a /32 or a /24, making you eligible to add either a /24 or a /32 but not both. My intention was also that the /29 *would not* be expandable to a /24, even if ARIN reserved enough space to do so. That's the IPv6 swamp and we're stuck with it but let's not make it any worse than it already is. [weg] if that's your intention, I didn't read that from the policy or implementation notes. You should probably make that clearer. Also, I'm unclear as to how being able to bring blocks to standard sizes through changes in bitmask would make the "IPv6 swamp" worse. > Another question I do think is largely unanswered is some > manner of estimate of how much address space (in terms > of number of networks) going back to something like classful > address allocation would cost us [...] compared with other > options like sparse allocation. Well, sparse is easy. 200 /56 allocations inside your /29 costs 8 bits leaving you with /37 as your largest possible remaining allocation. But, each of the /56's is, at that point, also capable of expanding to /37 via a netmask change. With the method described in this proposal, there's no need and indeed no reason to leave space between allocations, so the same 200 /56's consume part of one /48, leaving the largest remaining allocation in your /29 at /30. However, any of the /56's who need more addresses will add a /48 instead of being able to expand their /56. >From an address conservation perspective, this proposal's allocation method should come out way ahead of sparse. Sparse is incredibly wasteful of address space. [weg] Thanks for that, but I think you missed a fundamental distinction - allocated space (that is, ARIN actually gave it to an end network) is for all intents and purposes completely in use. Reserved space (that is, ARIN blocked it off as a means to expand an existing network's allocation via bitmask change in the future) is not. Therefore when space waste/availability becomes a concern, we can reclaim the reserved space. It's much harder to get back allocated space. See also IPv4 legacy holders for evidence of such. > but I am one of those who is worried about us not learning > from history. As am I. What do you make of the following history lesson: When the prior version of the Internet Protocol was replaced with IPv4, each organization which had a single address in the old scheme was assigned a class A, four tenths of a percent of the new protocol's total address space. The lesson I take is this: the allocation process for the prior protocol offers a poor guide for the new one. Try to treat the new protocol conservatively, not in relation to how the old protocol functioned, but in relation to how the new protocol functions. [weg] I take a different lesson - no one could conceive of exhausting the available address space given the demands of the current network and what they could imagine for future demands, so they allocated easy, large blocks on the assumption that the original networks would grow into them sooner than those not present on it yet, since they'd been using the network the longest. Further, efficiency of address use wasn't important because there was so much of it available. If anything I'll concede that some of the decisions made in earlier implementations of the protocol were driven by the hardware limitations at state-of-the-art, and so optimal was replaced by doable. In that, I think your proposal might have merit, provided you can show some analysis that it actually helps get us around the (hopefully) short-term limits of the routing system in a way that justifies the sub-optimal use of the space. Thanks, Wes George This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. From marquis at roble.com Tue Nov 17 14:52:45 2009 From: marquis at roble.com (Roger Marquis) Date: Tue, 17 Nov 2009 11:52:45 -0800 (PST) Subject: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process In-Reply-To: References: Message-ID: <20091117195245.97FD42B2110@mx5.roble.com> Michael Dillon wrote: > > Content-Type: text/plain; charset="us-ascii" > >> http://bill.herrin.us/network/ipxl.html > > That is a web page. Protocols are not found on > web pages, but in functioning routers. Where is > your functioning IPxl router? This is just being pedantic. Bill's design isn't an RFC so doesn't need a working model. It has obvious merit, however, and would not be difficult to implement. Should also note that IPv6 was at exactly the same stage at one point. One thing Bill's design has over IPv6 is immunity to "design by committee", and particular immunity to IPv6 designers whose sponsors have a financial interest in creating an artificial address shortage. IMO, Roger Marquis From schnizlein at isoc.org Tue Nov 17 14:58:39 2009 From: schnizlein at isoc.org (John Schnizlein) Date: Tue, 17 Nov 2009 14:58:39 -0500 Subject: [arin-ppml] Securing Routing Information Message-ID: <3D953C37-7E9B-4369-8B97-91B0565FAD92@isoc.org> FYI, here's a report from a group of operators who got together and discussed the issues. http://www.isoc.org/educpillar/resources/docs/routingroundtable_200909.pdf John -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Tue Nov 17 17:46:30 2009 From: bill at herrin.us (William Herrin) Date: Tue, 17 Nov 2009 17:46:30 -0500 Subject: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process In-Reply-To: References: <4AF86E15.2060307@arin.net> <3c3e3fca0911161351s111fe22ep9e213df6c32d122a@mail.gmail.com> Message-ID: <3c3e3fca0911171446h243cf8fcuc75510c7013c9ff6@mail.gmail.com> On Tue, Nov 17, 2009 at 1:09 PM, George, Wes E [NTK] wrote: > From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf Of William Herrin >>I respectfully disagree that we won't see any of the benefits without >>a global policy. Operators in the RIPE and APNIC regions are just as >>capable of filtering announcements from the ARIN region on >>classification boundaries as anyone else is. Whatever benefit there is >>to be had, we should see 10%-20% of it in a single-region policy. If >>the benefit proves enough, I think it likely that the other regions >>will move to adopt similar policies without needing coordination or, >>frankly, much of a push. > > [weg] I think this hits on my concern - Your opinion and my > opinion as to whether this is a good idea are still just opinions > without some more analysis. We don't *know* that this will be > any better. I'd rather you show your work - do some analysis > of the current routing table to draw some conclusions about > how much of an improvement we might actually see from something > like this, both if just one region does it and if all regions do it > BEFORE we implement it. Even if it's fairly simplistic and > uses the IPv4 table + classful allocation (allocate the entirety > of IPv4 space as many times as necessary), I'm not keen on > recommending such a radical change without more analysis > to back it up. Hi Wes, I think you make a fair point here. And we have lots of time before the next meeting. What kind of analysis would you like to see? Assuming ARIN is willing to provide the data, how about a simulation based on the IPv4 allocation history, repeating it as if under both the current and proposed IPv6 methods using a couple of different assumption sets and then looking to see where it comes out in terms of resulting allocations, free space fragmentation, disaggregability estimates and so on? >>Look at it this way: who am I to tell you how many IP addresses you >>need to do your job? I'm nobody. ?You are uniquely well qualified to >>strike the best balance between cost and size in your particular >>organization. If it isn't absolutely necessary for me to second guess >>your judgment in such matters, why should I? > > [weg] fair enough, but why are you trying to discourage me from > asking for a /24 by making it prohibitively expensive then? If > we're really trying to reduce the amount of overhead and > justification because IPv6 is so vast and non-scarce, then > make it easier to justify, don't remove the justification > altogether and replace it with some pseudo-scarcity pricing model.. The nice thing about cash is that balancing what you want with what you're willing to pay for is a tried and true method for achieving respectable efficiency. If you want a /24 badly enough to pay $100k for it, and more to the point if you think that's an investment you'll recover well on, then you should have it. If not, what *is* in your budget? In the name of leaving no stone unturned, I'd like to discuss alternatives. If not cash paid to ARIN directly, would you see annual Internet services budget as a more reasonable measurement vector? HD-ratio is truly bizarre but is there another non-cash vector you'd like to discuss? Perhaps a combination method where the smaller allocations are simple cash while the larger ones require modest justification but come with a lower price tag? I'd also like to hear from anyone who would argue that simple cash *is* the better choice. >> To be frank, the whole point of the $10 /56 level is to put you into a >> position as an ISP where you have to make a choice about filtering >> because you can't rationally carry those routes on your big iron. I >> *DO NOT* seriously expect you to carry single-homed /56's in the DFZ. > > [weg] I think you have a fundamental flaw in this assumption, and it >basically breaks routing for any single-homed customer who >chooses to use PI space. Upside down. Can't break what never worked. Instead, it sets the barrier to entry: ISPs don't carry the single-homed /56 block any more than they carry /26's in the DFZ today. So, just as you have to step up to a /24 to play in the DFZ for IPv4, you have to step up to some larger size to be single-homed in IPv6 with PI addresses. Which costs more. So, you have to make a judgment call about whether not having to renumber is worth the extra cash outlay. >> My intention in the proposal was that you keep the /29 for as long as >> you want (don't renumber unless you want to!) and it counts under the >> new policy as your choice of a /32 or a /24, making you eligible to >> add either a /24 or a /32 but not both. >> >> My intention was also that the /29 *would not* be expandable to a /24, >> even if ARIN reserved enough space to do so. That's the IPv6 swamp and >> we're stuck with it but let's not make it any worse than it already >> is. > [weg] if that's your intention, I didn't read that from the policy or > implementation notes. You should probably make that clearer. I'll try to clarify that in the next draft. > Also, I'm unclear as to how being able to bring blocks to > standard sizes through changes in bitmask would make the > "IPv6 swamp" worse. For each bit that you increase the mask of your allocation in the swamp, you double the potential disaggregation you can force on everybody else. Hence "worse." Also, there's a fairness question. Grandfathering an existing resource assignment is generally perceived as fair, but new registrants wouldn't have access to expanding netmask allocations. >> Another question I do think is largely unanswered is some >> manner of estimate of how much address space (in terms >> of number of networks) going back to something like classful >> address allocation would cost us [...] compared with other >> options like sparse allocation. > > Well, sparse is easy. 200 /56 allocations inside your /29 costs 8 bits > leaving you with /37 as your largest possible remaining allocation. > But, each of the /56's is, at that point, also capable of expanding to > /37 via a netmask change. > > With the method described in this proposal, there's no need and indeed > no reason to leave space between allocations, so the same 200 /56's > consume part of one /48, leaving the largest remaining allocation in > your /29 at /30. However, any of the /56's who need more addresses > will add a /48 instead of being able to expand their /56. > > From an address conservation perspective, this proposal's allocation > method should come out way ahead of sparse. Sparse is incredibly > wasteful of address space. > > [weg] Thanks for that, but I think you missed a fundamental > distinction - allocated space [is] completely in > use. Reserved space is not. Heavily fragmented reserved space creates waste and other problems. In the sparse example above you needed to assign a /32 to someone, you'd have to go back for more address space or allocate 32 disaggregate /37's. With this proposal's method, that /32 is readily doable, as is a /30. Free space fragmentation is not *as bad* as allocated space fragmentation, but it's still bad. On Mon, Nov 16, 2009 at 7:40 PM, Scott Leibrand wrote: > On Nov 16, 2009, at 4:27 PM, William Herrin wrote: >> 6.2.10 Organization >> >> An organization under section 6 is either: >> >> one or more legal entities under common control or ownership, or >> >> one such legal entity which operates a strictly separate network from >> the others. >> >> >> Thoughts? Alternatives? > Another consideration is Multiple Discrete Networks. Hi Scott, If I can duck the issue for now, I'd like to see that addressed in a later policy. I don't see Multiple Discrete Networks in current IPv6 policy. I only see it under NRPM 4.5. The proposal helps a little by allowing orgs to get several distinct blocks. In theory that will at least allow folks with a small number of discrete networks to get started. But more work will probably be needed to assess what's fair and whether it should be treated as a third measurement vector so that ISPs can filter differently. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From scottleibrand at gmail.com Tue Nov 17 18:10:24 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 17 Nov 2009 18:10:24 -0500 Subject: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process In-Reply-To: <3c3e3fca0911171446h243cf8fcuc75510c7013c9ff6@mail.gmail.com> References: <4AF86E15.2060307@arin.net> <3c3e3fca0911161351s111fe22ep9e213df6c32d122a@mail.gmail.com> <3c3e3fca0911171446h243cf8fcuc75510c7013c9ff6@mail.gmail.com> Message-ID: <4B032D60.5010906@gmail.com> William Herrin wrote: > >> Another consideration is Multiple Discrete Networks. >> > > Hi Scott, > > If I can duck the issue for now, I'd like to see that addressed in a > later policy. I don't see Multiple Discrete Networks in current IPv6 > policy. I only see it under NRPM 4.5. > You've got a couple months, I think, but we won't be able to ignore the issue at the spring meeting. At Dearborn there was near unanimous support in the room for the MDN draft policy 2009-5, so the AC voted to move it to last call, which completed last week. It will be on the agenda at our AC call this week, when I expect we'll recommend it to the Board for adoption. Then the Board will need to ratify it, and ARIN staff will need to implement it. > The proposal helps a little by allowing orgs to get several distinct > blocks. In theory that will at least allow folks with a small number > of discrete networks to get started. But more work will probably be > needed to assess what's fair and whether it should be treated as a > third measurement vector so that ISPs can filter differently. Taking off my AC hat and putting on the hat of first-hand experience as a user of the MDN policy: The routing model of proposal 103 seems to be optimized for a single organization with a single contiguous network (AS). If an organization runs multiple discrete networks (with multiple different ASNs), then the policy either needs to treat each network as a separate entity for purposes of allocating routable blocks, or we need to explicitly decide that we would prefer an org with MDNs to get a single allocation and split it up amongst the MDNs. That, of course, means that any filtering assumptions we make must take that into account, and we can't rely as reliably on easy filtering policies. We already have that problem in IPv6 today with /32s being universally accepted, but more-specific deaggregates currently being filtered (along with PI /48s) by some networks. -Scott From bill at herrin.us Tue Nov 17 18:44:17 2009 From: bill at herrin.us (William Herrin) Date: Tue, 17 Nov 2009 18:44:17 -0500 Subject: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process In-Reply-To: <4B032D60.5010906@gmail.com> References: <4AF86E15.2060307@arin.net> <3c3e3fca0911161351s111fe22ep9e213df6c32d122a@mail.gmail.com> <3c3e3fca0911171446h243cf8fcuc75510c7013c9ff6@mail.gmail.com> <4B032D60.5010906@gmail.com> Message-ID: <3c3e3fca0911171544y5b6d6225m69b4804cd64215ac@mail.gmail.com> On Tue, Nov 17, 2009 at 6:10 PM, Scott Leibrand wrote: > You've got a couple months, I think, but we won't be able to ignore the > issue at the spring meeting. ?At Dearborn there was near unanimous support > in the room for the MDN draft policy 2009-5, so the AC voted to move it to > last call, which completed last week. ?It will be on the agenda at our AC > call this week, when I expect we'll recommend it to the Board for adoption. > ?Then the Board will need to ratify it, and ARIN staff will need to > implement it. Hi Scott, Nuts. Well, if I have to, I have to. How about this as a starting point for discussion? 6.5.9.3 Excepting Multiple Discrete Network registrations, ARIN shall register no more than one address block of each prefix-length for any single organization. 6.5.9.8 ARIN shall allocate IPv6 address blocks to an organization's second and subsequent discrete networks (section 6.11) in exactly and only the following prefix lengths: /40, /32. ARIN shall manage the allocation pools such that the pool identity serves to classify whether or not the allocation is for a second or subsequent discrete network. I dropped the lower end of the range because I think for now we should discourage folks from running lots of tiny networks. I dropped /24 because I expect /24 to be modestly disaggregable and want to see if it turns out that way before including it for MDN's. So, the single/multi homed classification vector gains a third stop: MDN. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From Wesley.E.George at sprint.com Wed Nov 18 13:07:10 2009 From: Wesley.E.George at sprint.com (George, Wes E [NTK]) Date: Wed, 18 Nov 2009 12:07:10 -0600 Subject: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process In-Reply-To: <3c3e3fca0911171446h243cf8fcuc75510c7013c9ff6@mail.gmail.com> References: <4AF86E15.2060307@arin.net> <3c3e3fca0911161351s111fe22ep9e213df6c32d122a@mail.gmail.com> <3c3e3fca0911171446h243cf8fcuc75510c7013c9ff6@mail.gmail.com> Message-ID: -----Original Message----- From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf Of William Herrin Sent: Tuesday, November 17, 2009 5:47 PM To: arin-ppml at arin.net Cc: George, Wes E [NTK] Subject: Re: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process On Tue, Nov 17, 2009 at 1:09 PM, George, Wes E [NTK] wrote: > > [weg] I think this hits on my concern - Your opinion and my > opinion as to whether this is a good idea are still just opinions > without some more analysis. We don't *know* that this will be > any better. I'd rather you show your work - do some analysis > of the current routing table to draw some conclusions about > how much of an improvement we might actually see from something > like this, both if just one region does it and if all regions do it > BEFORE we implement it. Even if it's fairly simplistic and > uses the IPv4 table + classful allocation (allocate the entirety > of IPv4 space as many times as necessary), I'm not keen on > recommending such a radical change without more analysis > to back it up. Hi Wes, I think you make a fair point here. And we have lots of time before the next meeting. What kind of analysis would you like to see? Assuming ARIN is willing to provide the data, how about a simulation based on the IPv4 allocation history, repeating it as if under both the current and proposed IPv6 methods using a couple of different assumption sets and then looking to see where it comes out in terms of resulting allocations, free space fragmentation, disaggregability estimates and so on? [weg] yeah I think that gets to the right ballpark. You probably need to assume some percentages as to how much deaggregation will still be done as well as how much of it will be filtered by ISPs in the DFZ. I think you do need to try to capture some scenarios that assume some percentage of PI /48s displacing what would otherwise be aggregated PD /48s. >>Look at it this way: who am I to tell you how many IP addresses you >>need to do your job? I'm nobody. You are uniquely well qualified to >>strike the best balance between cost and size in your particular >>organization. If it isn't absolutely necessary for me to second guess >>your judgment in such matters, why should I? > > [weg] fair enough, but why are you trying to discourage me from > asking for a /24 by making it prohibitively expensive then? If > we're really trying to reduce the amount of overhead and > justification because IPv6 is so vast and non-scarce, then > make it easier to justify, don't remove the justification > altogether and replace it with some pseudo-scarcity pricing model.. The nice thing about cash is that balancing what you want with what you're willing to pay for is a tried and true method for achieving respectable efficiency. If you want a /24 badly enough to pay $100k for it, and more to the point if you think that's an investment you'll recover well on, then you should have it. If not, what *is* in your budget? [weg] it's sort of moot what is in my budget. I was simply saying that this seems to be quite a lot outside of the current fee structure, and fairly arbitrary - a simple order of magnitude increase as we go up the scale, and I can't exactly see why, other than an assumption that those large enough that they could have justified a /24 in the current system must have deep pockets, so they won't notice, and it'll keep "the riffraff" out. I think this precludes the new entries, the innovators on the assumption that $100K isn't a lot in the grand scheme of things. Maybe it would be for some... In the name of leaving no stone unturned, I'd like to discuss alternatives. If not cash paid to ARIN directly, would you see annual Internet services budget as a more reasonable measurement vector? HD-ratio is truly bizarre but is there another non-cash vector you'd like to discuss? Perhaps a combination method where the smaller allocations are simple cash while the larger ones require modest justification but come with a lower price tag? I'd also like to hear from anyone who would argue that simple cash *is* the better choice. [weg] like I said, I think the best balance would be to still have SOME amount of usage-based justification, probably much less stringent, and make the fee more reasonable, but waive the requirement for justification if someone wants it bad enough to pay an exorbitant fee. That said, I'm still not convinced that pricing is the way to enforce efficiency. If your goal is to make the routing table better, then you can implement rigid allocation models without messing with the justification to get one of said allocations. If your goal is to also make it easier to get IPv6 space in order to spur implementation, you can do that by reducing the current justification requirements. I'm not in favor of eliminating them altogether. >> To be frank, the whole point of the $10 /56 level is to put you into a >> position as an ISP where you have to make a choice about filtering >> because you can't rationally carry those routes on your big iron. I >> *DO NOT* seriously expect you to carry single-homed /56's in the DFZ. > > [weg] I think you have a fundamental flaw in this assumption, and it >basically breaks routing for any single-homed customer who >chooses to use PI space. Upside down. Can't break what never worked. Instead, it sets the barrier to entry: ISPs don't carry the single-homed /56 block any more than they carry /26's in the DFZ today. So, just as you have to step up to a /24 to play in the DFZ for IPv4, you have to step up to some larger size to be single-homed in IPv6 with PI addresses. Which costs more. So, you have to make a judgment call about whether not having to renumber is worth the extra cash outlay. [weg] Then what's the point in having /56 as an allocation at all, and especially at that price point? It has limited value, primarily for folks that have networks with a requirement for globally unique addresses but no requirement for them to be Internet routable. What I see is far more likely is people raising a ground swell of support for "I have a /56 from ARIN, and you have to route it, because I can't afford to pay you AND pay $1K/year for a /48, you big ISPs are always taking advantage of the little guy..." We didn't always accept /24s in IPv4 either... Even if I concede that /56 isn't breaking anything not broken today, and maybe it won't end up being routed, I'd argue that even at /48, it presents enough of an incentive that you will increase the number of single-homed PI holders and therefore significantly increase the routing table. At least under the other proposals being discussed, you have to be multihomed to play, so you can make the argument that you're not actively adding something to the routing table that wasn't already there (a multihomed network using PD space is always deaggregated so that you don't have prefix-length matching problems). $1K/year is (usually) still cheaper than a connection to a second provider. > Also, I'm unclear as to how being able to bring blocks to > standard sizes through changes in bitmask would make the > "IPv6 swamp" worse. For each bit that you increase the mask of your allocation in the swamp, you double the potential disaggregation you can force on everybody else. Hence "worse." Also, there's a fairness question. Grandfathering an existing resource assignment is generally perceived as fair, but new registrants wouldn't have access to expanding netmask allocations. [weg] I don't view expanding an existing network to match the standardized (and only available) netmasks as in any way unfair to new entrants. Plus, I don't see why you couldn't do filtering just the same as you do for the "non-swamp" space to nuke the disaggregation. The more of the swamp space you can get into standardized prefixes, the more you simplify any filtering you attempt to do. Even if there's not discrete blocks allocated for the different sizes, you still can put some assumptions in place about the amount of disaggregation on any of those normalized allocation sizes. Thanks again, Wes George This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. From bill at herrin.us Wed Nov 18 19:11:53 2009 From: bill at herrin.us (William Herrin) Date: Wed, 18 Nov 2009 19:11:53 -0500 Subject: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process In-Reply-To: References: <4AF86E15.2060307@arin.net> <3c3e3fca0911161351s111fe22ep9e213df6c32d122a@mail.gmail.com> <3c3e3fca0911171446h243cf8fcuc75510c7013c9ff6@mail.gmail.com> Message-ID: <3c3e3fca0911181611h21cab93as3dd285c46d957176@mail.gmail.com> On Wed, Nov 18, 2009 at 1:07 PM, George, Wes E [NTK] wrote: > [weg] yeah I think that gets to the right ballpark. You > probably need to assume some percentages as to how > much deaggregation will still be done as well as how > much of it will be filtered by ISPs in the DFZ. > I think you do need to try to capture some scenarios that > assume some percentage of PI /48s displacing what > would otherwise be aggregated PD /48s. Hi Wes, Let's see what can be done. [QUESTION FOR THE AC] I vaguely recall that ARIN offers its registration data set to researchers trying to do academic analysis about change in the Internet over time. Do I remember right? Can you point me in the right direction for what it would take to get a hold of an archive of IPv4 registration data for the purpose of simulating the action of proposal 103 versus the existing IPv6 policy? > [weg] it's sort of moot what is in my budget. I was > simply saying that this seems to be quite a lot > outside of the current fee structure, and fairly > arbitrary - a simple order of magnitude increase > as we go up the scale, and I can't exactly see why, Well, to be frank it *is* fairly arbitrary. It's also just a suggestion. ARIN has a body whose job is to take all the issues that impact fees into consideration and then set the fee structure. It's name escapes me right now, but the point is: those are the folks who will set the actual fee structure. My implementation notes are only intended to illustrate the general kind of demand that the policy places on the fee structure in order for the policy to work sensibly, since 103's needs are very different from the needs created by the prior policy. > [weg] Then what's the point in having /56 as > an allocation at all, and especially at that > price point? There are two subtle yet very important things that the /56 allocation does: 1. It creates an allocation that's effectively PI for all. ISPs *will* decide not to carry it. As long as ISPs try to stretch to carry every prefix ARIN allocates, they'll remain caught in the cost spiral from the constant tug-of-war between folks who want ARIN to do cheap PI and vendors who expect them to ante up for bigger TCAMs. I don't want that. I want to see them get together at NANOG and impanel a committee to study the classifications and issue a recommendation as to which classes should be carried in members' DFZ routers. That committee isn't politically possible while the ISPs are still trying to stretch to carry every ARIN allocation. 2. It creates a void where there's demand, no supply but plenty of opportunity. We have technologies on the drawing board like LISP and TRRP ( http://bill.herrin.us/network/trrp.html ) that could, in theory, create a secondary routing level that acts scalabily without consuming DFZ slots. But there's no demand to drive the development and deployment of those technologies because they're only one piece of the puzzle and the other pieces are also missing. > [weg] I don't view expanding an existing > network to match the standardized (and > only available) netmasks as in any way > unfair to new entrants. Oh! You mean expand the legacy prefix lengths to the closest thing to a uniform length possible rather than let them just sit there, but restrain the fees until the registrant next asks for more addresses. That way the two legacy pools may become filterable too and the reserved address space isn't lost. That's a right good idea. Would you object to seeing it as a follow-on or parallel proposal rather than part of the initial proposal? There may be complications lying in the details of how ARIN has allocated addresses in the legacy pool. I'd rather those complications not bog down 103. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From michael.dillon at bt.com Thu Nov 19 05:03:46 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 19 Nov 2009 10:03:46 -0000 Subject: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process In-Reply-To: <3c3e3fca0911181611h21cab93as3dd285c46d957176@mail.gmail.com> Message-ID: <28E139F46D45AF49A31950F88C49745804226C54@E03MVZ2-UKDY.domain1.systemhost.net> > Can you point me > in the right direction for what it would take to get a hold > of an archive of IPv4 registration data for the purpose of > simulating the action of proposal > 103 versus the existing IPv6 policy? How is a simulation of IPv4 registrations going to illuminate a change to the IPv6 policy. This proposal is just a bad idea in so many ways. It is too complex to understand all the implications. It is too radical. It would disrupt IPv6 deployment while people scramble to figure out what it all means. It is not needed. It is out of sync with the rest of the world. It is wasting our time just discussing this non-starter. Please take this off the AC's agenda so that they can focus on more important issues like IPv4 runout. --Michael Dillon From bill at herrin.us Thu Nov 19 09:16:54 2009 From: bill at herrin.us (William Herrin) Date: Thu, 19 Nov 2009 09:16:54 -0500 Subject: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process In-Reply-To: <28E139F46D45AF49A31950F88C49745804226C54@E03MVZ2-UKDY.domain1.systemhost.net> References: <3c3e3fca0911181611h21cab93as3dd285c46d957176@mail.gmail.com> <28E139F46D45AF49A31950F88C49745804226C54@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <3c3e3fca0911190616p205c20e8s1f561209d3fe8edd@mail.gmail.com> On Thu, Nov 19, 2009 at 5:03 AM, wrote: >> Can you point me >> in the right direction for what it would take to get a hold >> of an archive of IPv4 registration data for the purpose of >> simulating the action of proposal >> 103 versus the existing IPv6 policy? > > How is a simulation of IPv4 registrations going to illuminate > a change to the IPv6 policy. Hi Michael, My intention is to simulate the action over time of both the current IPv6 allocation policy and in the policy I've proposed by mapping the actual IPv4 allocations into what that chain of allocations might have looked like had they occurred under these policies. I wish to start with the IPv4 data because that's likely to yield results closer to correct than if I try to generate some sort of randomized data set. The simulation will require making certain assumptions about the mapping from IPv4 to IPv6, so I intend to make several reasonable sets of assumptions for each in order to see how that changes the results. While the results won't be perfect, it should be possible to identify patterns in the results which validate or refute this proposal's claims about address waste and routing table consumption. > This proposal is just a bad idea in so many ways. I'm sorry you feel that way. While I respect that the radical nature of the proposed change would reasonably make anyone suggest that we _proceed with care_, I hope that the AC elects to move the proposal forward so that the implications can be analyzed, discussed and should they ultimately prove persuasive, adopted by ARIN. By my count it's now 5 enthusiastic, 1 opposed until he sees some data that justifies the proposal's claims, and you. I would respectfully suggest that the count merits bringing the proposal forward for formal discussion and presentation, regardless of whether its current form is likely to be adopted. We owe it to ourselves to start thinking about the issues this proposal raises while the IPv6 allocation count is still small. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From Wesley.E.George at sprint.com Thu Nov 19 10:15:28 2009 From: Wesley.E.George at sprint.com (George, Wes E [NTK]) Date: Thu, 19 Nov 2009 09:15:28 -0600 Subject: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process In-Reply-To: <3c3e3fca0911181611h21cab93as3dd285c46d957176@mail.gmail.com> References: <4AF86E15.2060307@arin.net> <3c3e3fca0911161351s111fe22ep9e213df6c32d122a@mail.gmail.com> <3c3e3fca0911171446h243cf8fcuc75510c7013c9ff6@mail.gmail.com> <3c3e3fca0911181611h21cab93as3dd285c46d957176@mail.gmail.com> Message-ID: -----Original Message----- From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf Of William Herrin Sent: Wednesday, November 18, 2009 7:12 PM To: George, Wes E [NTK] Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process > [weg] I don't view expanding an existing > network to match the standardized (and > only available) netmasks as in any way > unfair to new entrants. Oh! You mean expand the legacy prefix lengths to the closest thing to a uniform length possible rather than let them just sit there, but restrain the fees until the registrant next asks for more addresses. That way the two legacy pools may become filterable too and the reserved address space isn't lost. That's a right good idea. Would you object to seeing it as a follow-on or parallel proposal rather than part of the initial proposal? There may be complications lying in the details of how ARIN has allocated addresses in the legacy pool. I'd rather those complications not bog down 103. [weg] Yes, exactly. I'm not necessarily making any comment on fees one way or the other, just thinking in terms of standardizing some of what would now be odd allocation sizes where it's possible to do so. However, I don't think this should be a separate proposal. What I would recommend is language in this proposal that talks to it but that doesn't make it a hard and fast requirement. In other words, give the recommendation that this would be the way to maximize the benefits of this proposal on existing allocations, without writing detailed specs on how it would be handled for all possible cases. Ultimately, that part would be up to ARIN staff to figure out, the proposal simply needs to sketch out the expectation. If it's not possible because of the way certain things are allocated, we're not necessarily any worse off, and you're not advocating renumbering to fix it, so I don't see how it would bog down this proposal. Thanks Wes George This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. From sethm at rollernet.us Thu Nov 19 12:37:26 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 19 Nov 2009 09:37:26 -0800 Subject: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process In-Reply-To: <28E139F46D45AF49A31950F88C49745804226C54@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C49745804226C54@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <4B058256.6030808@rollernet.us> michael.dillon at bt.com wrote: >> Can you point me >> in the right direction for what it would take to get a hold >> of an archive of IPv4 registration data for the purpose of >> simulating the action of proposal >> 103 versus the existing IPv6 policy? > > How is a simulation of IPv4 registrations going to illuminate > a change to the IPv6 policy. > > This proposal is just a bad idea in so many ways. > It is too complex to understand all the implications. > It is too radical. > It would disrupt IPv6 deployment while people scramble > to figure out what it all means. > It is not needed. > It is out of sync with the rest of the world. > It is wasting our time just discussing this non-starter. > Please take this off the AC's agenda so that they can focus > on more important issues like IPv4 runout. > Applying IPv4 style utilization to IPv6 is also a bad idea, but yet it's policy. ~Seth From info at arin.net Fri Nov 20 12:38:31 2009 From: info at arin.net (Member Services) Date: Fri, 20 Nov 2009 12:38:31 -0500 Subject: [arin-ppml] Policy Proposal 104: Multiple Discrete Networks for proposal 103 Message-ID: <4B06D417.9000208@arin.net> ARIN received the following policy proposal and is posting it to the Public Policy Mailing List (PPML) in accordance with Policy Development Process. This proposal is in the first stage of the Policy Development Process. ARIN staff will perform the Clarity and Understanding step. Staff does not evaluate the proposal at this time, their goal is to make sure that they understand the proposal and believe the community will as well. Staff will report their results to the ARIN Advisory Council (AC) within 10 days. The AC will review the proposal at their next regularly scheduled meeting (if the period before the next regularly scheduled meeting is less than 10 days, then the period may be extended to the subsequent regularly scheduled meeting). The AC will decide how to utilize the proposal and announce the decision to the PPML. In the meantime, the AC invites everyone to comment on the proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Mailing list subscription information can be found at: https://www.arin.net/mailing_lists/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 104: Multiple Discrete Networks for proposal 103 Proposal Originator: William Herrin Proposal Version: 1.0 Date: 20 November 2009 Proposal type: new Policy term: permanent. Policy statement: Add NRPM section 6.5.10 as follows: 6.5.10 Allocations for Multiple Discrete Networks 6.5.10.1 Notwithstanding section 6.5.9, ARIN shall allocate IPv6 address blocks to an organization's second and subsequent networks where justified by section 6.11 (Multiple Discrete Networks). 6.5.10.2 ARIN shall allocate IPv6 address blocks to an organization's second and subsequent discrete networks in exactly and only the following prefix lengths: /40, /32. 6.5.10.3 ARIN shall manage the allocation pools such that the pool identity serves to classify whether or not an allocation is for a second or subsequent discrete network regardless of whether it is single or multihomed. Rationale: This updates proposal 103 to support Multiple Discrete Networks as pending in proposal 2009-5. Offered in parallel so we can debate exactly how to integrate MDN's without tying up 103 itself. Timetable for implementation: concurrent with proposal 103. From info at arin.net Fri Nov 20 12:38:47 2009 From: info at arin.net (Member Services) Date: Fri, 20 Nov 2009 12:38:47 -0500 Subject: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process - revised Message-ID: <4B06D427.1080905@arin.net> The proposal originator submitted a revised version of the proposal. The AC will review this proposal at their next regularly scheduled meeting and decide how to utilize the proposal. Their decision will be announced to the PPML. Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 103: Change IPv6 Allocation Process Proposal Originator: William Herrin Proposal Version: 1.1 Date: 20 November 2009 Proposal type: new Policy term: permanent. Policy statement: Strike NRPM sections: 6.2.3, 6.2.4, 6.2.6-6.2.9, 6.4.3, 6.4.4, 6.5.1-6.5.5, 6.5.8, 6.7, 6.10 Strike NRPM 6.3.5 sentence 2. Strike "/NIR" from NRPM section 6.5.6. In section 6.9 strike NRPM "/LIR" at the end of paragraph 1 and all of paragraph 2. Replace 6.2.5 as follows: 6.2.5 Allocate and Assign For the purposes of NRPM section 6, allocate and assign are synonymous. Both terms describe any or all use identified in section 2.5. Replace 6.3.4 paragraph 4 with: Further, RIRs should apply allocation practices that minimize route disaggregation. Replace 6.5.7 with: 6.5.7. Existing IPv6 address space holders Organizations that received IPv6 allocations under the previous IPv6 address policy are entitled to either retain those allocations as is or trade them in for an allocation under 6.5.9. Where the prefix length of such registrations differs from the standard lengths in 6.5.9.1, it shall count as a registration of the next longer length. The above notwithstanding, ARIN is authorized to standardize the prefix lengths within these previously-allocated address pools in a manner approaching 6.5.9.4 by increasing the prefix length of all registrants within a particular pool to some specific minimum prefix length for the pool. Add NRPM section 6.2.10 as follows: 6.2.10 Organization An organization under section 6 is either: one or more legal entities under common control or ownership, or one such legal entity which operates strictly separate networks from the others. Add NRPM section 6.5.9 as follows: 6.5.9 Regular IPv6 Allocations 6.5.9.1 ARIN shall allocate IPv6 address blocks in exactly and only the following prefix lengths: /56, /48, /40, /32, /24 6.5.9.2 No usage-based eligibility requirements shall apply to IPv6 allocations. 6.5.9.3 ARIN shall register no more than one address block of each prefix-length for any single organization. These blocks may be registered simultaneously. Renumbering of existing blocks is not required to receive additional blocks. 6.5.9.4 ARIN shall allocate IPv6 addresses from pools such that the identity of the allocation pool serves to classify the expected prefix length of allocations within. ISPs may use that classification to filter or otherwise manage their routing tables. 6.5.9.5 For each allocation size, ARIN shall further manage the allocation pools such that the pool identity serves to classify whether or not the registrant is Multihomed. 6.5.9.6 ARIN shall offer addresses from pools classified as multihomed only to organizations which ARIN has verified are multihomed on the public Internet per NRPM 2.7. 6.5.9.7 Where an organization ceases to be Multihomed it shall surrender all address allocations from within pools classified as multihomed within 3 months. Rationale: See the implementation notes section below for what should replace utilization-based eligibility. The existing IPv6 allocation policy under section 6.5 makes a number of unproven assumptions about how IPv6 allocations will work. Unproven: we can make a reasonable guess about how many IPv6 subnets an organization will need at the outset when they first request IP addresses. When in all of human history has this ever proven true of any resource? Unproven: with sparse allocation, we can allow organizations to expand by just changing their subnet mask so that they don't have to announce additional routes into the DFZ. This claim is questionable. With sparse allocation, we either consume much larger blocks that what we assign (so why not just assign the larger block?) or else we don't consume them in which case the org either has to renumber to expand or he has to announce a second route. Worse, because routes of various sizes are all scattered inside the same address space, its impractical to filter out the traffic engineering routes. Unproven: we can force organizations not to disaggregate for traffic engineering purposes. Neither any of our experience with IPv4 nor any of the research in the IRTF Routing Research Group suggests that this is even remotely practical so long as BGP or any similar system rules the roost. Unproven: all non-ISPs can be reasonably expected to get their address space from ISPs instead of from ARIN. We can certainly operate that way, but it could prove deadly to the routing table. Any organization multihomed between two ISPs will need to announce that route via BGP, regardless of where they get the address space from. We have knobs and dials in the routers that let us easily filter disaggregates from distant announcements, but we don't dare do so if there is a possibility that one of those disaggregates is a multihomed customer rather than traffic engineering. Benefits of this proposal: A. Efficient allocation of IP addresses. Orgs get what they need when they need it without a great deal of guesswork. B. Efficient utilization of BGP routing slots. No multihomed orgs will announce more than five unfilterable routes, and that only if they're so large that they can afford the price tag for the biggest address blocks. That's a good thing since IPv6 routes that propagate worldwide may impose an annual systemic overhead cost on ISPs of as much as US $16,000 each. C. Traffic engineering routes are trivially filterable. Any route longer than the published allocation size can be presumed to be traffic engineering, not a downstream multihomed customer, thus you can filter distant small routes with confidence and ease. D. Fair. No need to define the difference between ISP and not ISP. Everybody plays by the same rules. E. No complicated analysis for allocation. You pay for what you want and get what you pay for. You're either multihomed or you're not. F. Gets ARIN out of the business of being the gatekeeper for Internet routing policy. By classifying allocations instead of making eligibility decisions, ARIN empowers the ISPs to set appropriate routing eligibility policies instead. FAQ Q. Isn't this classfull addressing all over again? A. Yes. Classful addressing had a lot of virtues with respect to route filtering and management. We had to abandon it because there weren't enough B's for everyone who needed more than one C and there weren't enough A's period. With IPv6, we don't have that problem. Not yet and maybe not ever. Perhaps we can have our cake and eat it too. Q. What if I don't want to accept /56 routes for single-homed users? A. This policy proposal intentionally and fully places backbone routing policy in the hands of the ISPs who operate the Internet's "Default-Free Zone (DFZ)," colloquially known as the Internet backbone. The author expects that some of the allocations, especially some of the single-homed allocations, *will not* be routable on the public Internet. When we hold a general expectation that all of ARIN's allocations will be routable, we effectively mean that ARIN decides what the Internet routing policy will be. That's precisely the role this proposal removes from ARIN's hands and restores to the ISPs. Q. Spell it out for me. How exactly will pools and size classifications enable route filtering? A. Suppose ARIN holds 4000::/12. ARIN might split it up as follows: 4000::/13 -- reserved 4008::/15 -- multihomed /24 allocations 400a::/15 -- non-multihomed /24 allocations 400c::/16 -- multihomed /32 allocations 400d::/16 -- non-multihomed /32 allocations 400e:0000::/18 -- multihomed /40 allocations 400e:4000::/18 -- non-multihomed /40 allocations 400e:8000::/24 -- multihomed /48 allocations 400e:8100::/24 -- non-multihomed /48 allocations 400e:8200::/24 -- multihomed /56 allocations 400e:8300::/24 -- non-multihomed /56 allocations 400e:8400::/22 -- reserved 400e:8800::/21 -- reserved 400e:9000::/20 -- reserved 400e:a000::/19 -- reserved 400e:c000::/18 -- reserved 400f::/16 -- reserved Now, you're an ISP. Here's a sample routing policy you might choose: Accept any routes to /32 because anyone paying $10k per year for addresses is big enough to ride. For /24 allow 2 bits of traffic engineering too. Single-homers who won't spend $10k/year on their addresses (smaller than /32) must use addresses from their ISP. Tough luck. Accept multihomers down to /48. The folks paying only $10/year for /56's aren't serious. Your route filter looks like this: accept 400e:8000::/24 equal 48 accept 400e:0000::/18 equal 40 accept 400c::/15 equal 32 accept 4008::/14 le 26 reject 4000::/12 le 128 Note how 400e:8000::/24 contains only /48 allocations and you're allowing only /48 announcements. Since there aren't any /47 or /46 allocations there, nobody in the pool can slip TE routes past you. On the other hand, you'll get some benefit of traffic engineering from the super-massive /24 registrants up in 4008::/14 because you're allowing them to disaggregate down to /26. Q. If its so expensive to announce routes into the DFZ, why not use something better than BGP? A. In 2008 the IRTF Routing Research Group compiled an exhaustive study attempting to identify the possible ways to improve the routing system. A draft of the results is at http://tools.ietf.org/html/draft-irtf-rrg-recommendation-02 . While there are many promising ideas for how to replace BGP with something that scales better, we're at least a decade away and probably more from any significant deployment of a BGP replacement. Q. Is it really true that multihoming requires announcing a route via BGP? A. The short answer is yes. The long answer is more complicated. Folks have tried very hard to devise multi-vendor multihomed systems which don't rely on BGP. The only approach that has ever come near success is dynamically changing DNS records to favor the currently working Internet connection. "Near" is a relative term here. Such network architectures are enormously complex and they don't work especially well. The DNS protocol itself supports quick changes but the applications which use it often don't. It takes hours to achieve two-nines recovery from an address change in the DNS and it takes months to achieve five-nines recovery. Web browsers, for example, don't immediately recover. Search google for "DNS Pinning." Q. So the Internet's resulting route policy will be to allow all the sizes that no major ISP decides to filter and restrict the rest? A. That's one possible outcome. On the other hand, research in the routing field suggests that with a sufficiently rich classification scheme, it may be possible to implement lower priority systems with provider-independent addresses yet without a global route. Hints for how such a thing might work can be found in http://www.cs.cornell.edu/people/francis/va-wp.pdf and http://bill.herrin.us/network/trrp.html. Such schemes need a rich classification process at the address allocation level that makes it possible for ISPs to make reasonable and simple decisions about which routes should be distributed to every DFZ router and which should not. Wouldn't that be something: IPv6 provider independent addresses for everybody without materially increasing the cost of the routing system. Q. Why allocate the /48's from a pool only for /48's, /32's from a /32 pool, etc.? Why not allocate from just one pool? A. If all assignments in a particular pool are /32 then any route in the /32 pool which is longer than /32 is a traffic engineering (TE) route. As a router operator you can filter and discard TE routes if you find they give you insufficient benefit. The routes you filter don't cost you any money; only the routes you keep carry a price tag. You can only filter if you're sure they're TE routes... If they're distinct downstream customer routes and you filter them, there goes the Internet. Or at least there goes your part of it. See customers. See customers run... straight to your competitor. Setting up the distinct pools makes it practical to know with certainty whether the routes you're filtering are only for TE. Q. Why allow only one allocation of each particular size? A. Without the address scarcity issue which drives IPv4 policy, the primary criteria for IPv6 addressing policy is suppressing the disaggregation that drives route count in the IPv4 DFZ (NRPM 6.3.8). Such a criteria is not well served if an organization holds dozens of discontiguous address spaces as a result of acquisitions, mergers and and growing a little bit at a time. This proposal says, in effect, once you've consumed your smaller allocation it's time for you to get a *much* bigger allocation. The rest of us don't want to pay the routing table price for you coming back again and again and again. The proposal could require some renumbering as a result of mergers and acquisitions. However, with only modest planning on the registrant's part, the policy its flexible enough to allow that renumbering to occur over a long period of time so that both cost and disruption are minimized. In many cases, customer churn can be expected to take care of much of the renumbering activity all by itself. Q. What about the IETF recommendations? A. RFC 3177 recommends that ISPs receive a /32 while downstream customers receive a /48 assignment by default with so-called "sparse allocation" to allow those assignments to expand by changing the netmask. While this proposal supports organizations who wish to follow those recommendations, it is not this proposal's intention that ARIN follow RFC 3177. RFC 3177 is not the gospel truth. It was written back in 2001 when there was little IPv6 outside of academia and, indeed, little IPv6 at all. It's an engineers' SWAG about what operations folk should do that's now 8-years-stale. This proposal attempts to slow-start IPv6 allocations instead, while still maintaining the principle of suppressing the routing table size. As an ISP, consider implementing a slow start for your downstream customers as well: Give them a /60 initially, add a /56 when they need it and add a /52 when they run out of the /56. A /60 is 16 /64 subnets. That's an internal LAN, a DMZ and 14 more subnets. Just how many subnets do you think your normal downstream customer will actually use? Q. What happens when organizations merge or split? A. Entities which merge may renumber out of and return conflicting allocations, or they may maintain the existence of the acquired organization in order to keep it's addresses. Either way it should be a minor hardship. Entities which split have a bigger problem since the practical effect of route filtering may be that only one of them can keep the addresses. To a large extent, that problem already exists and is a pain in the rump for IPv4 operations today. This policy doesn't solve it but it doesn't make it a whole lot worse either. Because disaggregates are likely to be filtered, this IPv6 policy does gives us a slightly better guarantee that the rest of us won't get stuck with the check (in the form of routing slot consumption) when an ISP goes bankrupt and gets split up. Q. What happens to the existing (legacy) IPv6 allocations and assignments? A. An organization will be entitled to retain their existing allocations indefinitely if they so desire. If the prefix length does not match one of the standard prefix lengths then it will be treated as the next smaller prefix length for the purposes of determining eligibility for further IPv6 allocations. To discourage unnecessary disaggregation, the prefix length of this "legacy" allocation will not be expanded even if there is room in the pool to do so. Q. What about IPv6 addresses for uses which will not be connected to the Internet at all? A. Folks are welcome to get non-multihomed addresses for any purpose whatsoever. If they do eventually decide to connect to the Internet, the routes will follow whatever rules the ISPs have imposed for routes within the single-homed pools. Q. What about reporting requirements for downstream assignments? A. Reporting requirements were instituted for the purpose of verifying eligibility for additional allocations. They have proven useful for other purposes and the author encourages ARIN to maintain the SWIP system. Nevertheless, this proposal renders the use of SWIP for IPv6 optional since it is no longer needed to verify eligibility for allocations. Q. What if I need more than a /24? A. This proposal's author asserts as obvious: anyone who defines a need for more than a trillion subnets should make their case publicly on PPML, seeking a follow-on proposal that establishes address pools at the /16 level. Q. What does standardize prefix lengths within the legacy pools in 6.5.7 mean? A. Wes George pointed out that depending on the rules ARIN has followed with respect to leaving space between allocations, it may be possible to standardize the existing pools on some prefix length as well. If it is possible, folks should become able to better filter disaggregation in those pools too. So, for example, if ARIN allocated a /32, a /31 and a /30 from the old /32 pool and reserved a /28 for each allocation to expand, ARIN could peremptorily increase all three allocations to either /28 and then publish that the exact prefix length in that pool is /28. Another example, if ARIN allocated a bunch of /32's and a /26, reserving /28 for each allocated /32, ARIN could increase the /32's to /28 and publish that the minimum allocation size for the pool is /28. Instead of the /26 registrant being able to disaggregate into 64 /32's, he might then be constrained to only disaggregate into 4 /28's. While this proposal does not require ARIN to take that action, it authorizes it. Q. What are the struck sections of the current IPv6 policy and why should they be struck? A. 6.2.3 - 6.2.9 define terms that have no meaning or use in the policy as revised by this proposal. 6.3.4 paragraph 4 gives instructions on accomplishing address aggregation which are, if this proposal's rationale is correct, counterproductive to encouraging route aggregation. Address aggregation only matters to the extent that it helps bring about route aggregation. 6.3.5 sentence 2 speaks to documentation issues that are incompatible with this proposal. If this proposal's rationale is correct then fees alone are sufficient to prevent unnecessary waste. The 6.4.3 notion of a minimum allocation is obsoleted by the allocation pools of specific size in this proposal. 6.4.4 is moot as this proposal does not expect registrants to justify their IPv6 allocation size. 6.5.1 - 6.5.4 and 6.5.8 are replaced entirely by 6.5.9. 6.5.5 is largely moot since it's no longer necessary to confirm downstream assignments in order to determine eligibility for additional addresses. 6.7 is moot as it is unnecessary to compute utilization to justify addresses under this proposal. 6.9 paragraph 2 is moot since utilization is not a factor in IPv6 policy under this proposal. 6.10 is redundant since micro-allocations are trivially accomplished under 6.5.9. Implementation notes: To prevent wasteful consumption of IPv6 address space without a complicated eligibility regime, the author recommends an initial and annual fee regime for IPv6 address allocations similar to: /56 -- $10 USD /48 -- $100 USD /40 -- $1000 USD /32 -- $10,000 USD /24 -- $100,000 USD Legacy -- the lesser of the cost of the next larger size or the cost of the next smaller size times the number encompassed by the registration. The above notwithstanding, it may be advisable to discount /40s and /32s to a much lower price during IPv6's general deployment process in order to encourage adoption. Folks who already hold /31's should probably also get a big break on the $20k fee for a good long while, perhaps until the first time they request an additional block without offering a plan to return the legacy addresses. For verification of multihoming, the current way ARIN verifies multihoming for other parts of it's policy appears satisfactory. Should that change, the author suggests requiring that the AS# contacts for at least two AS#'s submit a template indicating that they intend to originate or propagate IPv6 BGP routes from the registrant's ORG. Timetable for implementation: following an update of ARIN's IPv6 fee structure. From bill at herrin.us Fri Nov 20 12:44:48 2009 From: bill at herrin.us (William Herrin) Date: Fri, 20 Nov 2009 12:44:48 -0500 Subject: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process - revised In-Reply-To: <4B06D427.1080905@arin.net> References: <4B06D427.1080905@arin.net> Message-ID: <3c3e3fca0911200944v5c245105lc1edaab72443054a@mail.gmail.com> Here's the diff: @@ -6,7 +6,7 @@ 2. email: bill at herrin.us 3. telephone: 703-534-2652 4. organization: Self -3. Proposal Version: 1.0 +3. Proposal Version: 1.1 4. Date: 11/2009 5. Proposal type: new 6. Policy term: permanent. @@ -15,7 +15,12 @@ Strike NRPM sections: 6.2.3, 6.2.4, 6.2.6-6.2.9, 6.4.3, 6.4.4, 6.5.1-6.5.5, 6.5.8, 6.7, 6.10 -Strike NRPM section 6.9 paragraph 2. +Strike NRPM 6.3.5 sentence 2. + +Strike "/NIR" from NRPM section 6.5.6. + +In section 6.9 strike NRPM "/LIR" at the end of paragraph 1 and all of +paragraph 2. Replace 6.2.5 as follows: @@ -25,31 +30,57 @@ synonymous. Both terms describe any or all use identified in section 2.5. +Replace 6.3.4 paragraph 4 with: + +Further, RIRs should apply allocation practices that minimize route +disaggregation. + Replace 6.5.7 with: 6.5.7. Existing IPv6 address space holders Organizations that received IPv6 allocations under the previous IPv6 address policy are entitled to either retain those allocations as is -or trade them in for an allocation under 6.5.9. +or trade them in for an allocation under 6.5.9. Where the prefix +length of such registrations differs from the standard lengths in +6.5.9.1, it shall count as a registration of the next longer length. + +The above notwithstanding, ARIN is authorized to standardize the +prefix lengths within these previously-allocated address pools in a +manner approaching 6.5.9.4 by increasing the prefix length of all +registrants within a particular pool to some specific minimum prefix +length for the pool. + +Add NRPM section 6.2.10 as follows: + +6.2.10 Organization + +An organization under section 6 is either: + +one or more legal entities under common control or ownership, or + +one such legal entity which operates strictly separate networks from +the others. Add NRPM section 6.5.9 as follows: -6.5.9 IPv6 Allocations +6.5.9 Regular IPv6 Allocations 6.5.9.1 ARIN shall allocate IPv6 address blocks in exactly and only -the following denominations: /56, /48, /40, /32, /24 +the following prefix lengths: /56, /48, /40, /32, /24 -6.5.9.2 No utilization-based eligibility requirements shall apply to -IPv6 allocations. +6.5.9.2 No usage-based eligibility requirements shall apply to IPv6 +allocations. -6.5.9.3 ARIN shall accept registration of no more than one address -block of each size for any single organization. +6.5.9.3 ARIN shall register no more than one address block of each +prefix-length for any single organization. These blocks may be +registered simultaneously. Renumbering of existing blocks is not +required to receive additional blocks. 6.5.9.4 ARIN shall allocate IPv6 addresses from pools such that the -identity of the allocation pool serves to classify the expected size -of allocations within. ISPs may use that classification to filter or -otherwise manage their routing tables. +identity of the allocation pool serves to classify the expected prefix +length of allocations within. ISPs may use that classification to +filter or otherwise manage their routing tables. 6.5.9.5 For each allocation size, ARIN shall further manage the allocation pools such that the pool identity serves to classify @@ -106,7 +137,7 @@ Benefits of this proposal: A. Efficient allocation of IP addresses. Orgs get what they need when -they need it without a great deal of guesswork about actual need. +they need it without a great deal of guesswork. B. Efficient utilization of BGP routing slots. No multihomed orgs will announce more than five unfilterable routes, and that only if they're @@ -318,8 +354,20 @@ with the check (in the form of routing slot consumption) when an ISP goes bankrupt and gets split up. +Q. What happens to the existing (legacy) IPv6 allocations and +assignments? + +A. An organization will be entitled to retain their existing +allocations indefinitely if they so desire. If the prefix length does +not match one of the standard prefix lengths then it will be treated +as the next smaller prefix length for the purposes of determining +eligibility for further IPv6 allocations. To discourage unnecessary +disaggregation, the prefix length of this "legacy" allocation will not +be expanded even if there is room in the pool to do so. + Q. What about IPv6 addresses for uses which will not be connected to the Internet at all? + A. Folks are welcome to get non-multihomed addresses for any purpose whatsoever. If they do eventually decide to connect to the Internet, the routes will follow whatever rules the ISPs have imposed for routes @@ -341,12 +389,45 @@ on PPML, seeking a follow-on proposal that establishes address pools at the /16 level. +Q. What does standardize prefix lengths within the legacy pools in +6.5.7 mean? + +A. Wes George pointed out that depending on the rules ARIN has +followed with respect to leaving space between allocations, it may be +possible to standardize the existing pools on some prefix length as +well. If it is possible, folks should become able to better filter +disaggregation in those pools too. + +So, for example, if ARIN allocated a /32, a /31 and a /30 from the old +/32 pool and reserved a /28 for each allocation to expand, ARIN could +peremptorily increase all three allocations to either /28 and then +publish that the exact prefix length in that pool is /28. + +Another example, if ARIN allocated a bunch of /32's and a /26, +reserving /28 for each allocated /32, ARIN could increase the /32's to +/28 and publish that the minimum allocation size for the pool is /28. +Instead of the /26 registrant being able to disaggregate into 64 +/32's, he might then be constrained to only disaggregate into 4 /28's. + +While this proposal does not require ARIN to take that action, it +authorizes it. + Q. What are the struck sections of the current IPv6 policy and why should they be struck? A. 6.2.3 - 6.2.9 define terms that have no meaning or use in the policy as revised by this proposal. +6.3.4 paragraph 4 gives instructions on accomplishing address +aggregation which are, if this proposal's rationale is correct, +counterproductive to encouraging route aggregation. Address +aggregation only matters to the extent that it helps bring about route +aggregation. + +6.3.5 sentence 2 speaks to documentation issues that are incompatible +with this proposal. If this proposal's rationale is correct then fees +alone are sufficient to prevent unnecessary waste. + The 6.4.3 notion of a minimum allocation is obsoleted by the allocation pools of specific size in this proposal. @@ -398,7 +479,8 @@ intend to originate or propagate IPv6 BGP routes from the registrant's ORG. -9. Timetable for implementation: immediate +9. Timetable for implementation: following an update of ARIN's IPv6 +fee structure. END OF TEMPLATE -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mcr at sandelman.ca Fri Nov 20 13:36:02 2009 From: mcr at sandelman.ca (Michael Richardson) Date: Fri, 20 Nov 2009 13:36:02 -0500 Subject: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process - revised In-Reply-To: <4B06D427.1080905@arin.net> References: <4B06D427.1080905@arin.net> Message-ID: <13553.1258742162@marajade.sandelman.ca> 103> Q. What if I don't want to accept /56 routes for 103> single-homed users? 103> A. This policy proposal intentionally and fully places 103> backbone routing policy in the hands of the ISPs who operate 103> the Internet's "Default-Free Zone (DFZ)," colloquially known 103> as the Internet backbone. The author expects that some of 103> the allocations, especially some of the single-homed 103> allocations, *will not* be routable on the public 103> Internet. When we hold a general expectation that all of 103> ARIN's allocations will be routable, we effectively mean 103> that ARIN decides what the Internet routing policy will 103> be. That's precisely the role this proposal removes from 103> ARIN's hands and restores to the ISPs. HERE! HERE! IPv6 explicitely supports and encourages multiple prefixes per interface, so it's entirely reasonable that some "multihomers" will be happy to do so using several PA from each of their ISPs. The problem has been --- what address space to use internally, and this policy finally frees lets even smaller enterprises play. (All big enterprises were small enterprises at some point..) 103> Q. What about IPv6 addresses for uses which will not be 103> connected to the Internet at all? 103> A. Folks are welcome to get non-multihomed addresses for any 103> purpose whatsoever. If they do eventually decide to connect 103> to the Internet, the routes will follow whatever rules the 103> ISPs have imposed for routes within the single-homed pools. thank you. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From mpetach at netflight.com Sun Nov 22 03:21:39 2009 From: mpetach at netflight.com (Matthew Petach) Date: Sun, 22 Nov 2009 00:21:39 -0800 Subject: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process - revised In-Reply-To: <4B06D427.1080905@arin.net> References: <4B06D427.1080905@arin.net> Message-ID: <63ac96a50911220021r5ff482eev99a4756d44595e4b@mail.gmail.com> > > 6.5.9.3 ARIN shall register no more than one address block of each > prefix-length for any single organization. These blocks may be > registered simultaneously. Renumbering of existing blocks is not > required to receive additional blocks. So...I'm a company with a /40 allocation. I buy up 3 companies with /48 allocations. According to this, ARIN is supposed to drop the registrations for 2 of the 3 companies, since I can only have one /40 allocation and one /48 allocation, right? What is the timeframe allocated for renumbering the acquired companies, and what should ARIN do to the registrations for the blocks in the meantime? If my /40 was already full, and doesn't have room for the 2 new /48s I have to renumber, do I get a /32 allocation as well, so I can renumber the 2 /48s into the new /32 (thus coming back into alignment with the requirement to have only one allocation from each pool size). If that ends my buying spree, doesn't it seem a bit wasteful to force a company to get a /32 allocation to accomodate 2 /48s? Or does the proposal allow me to simply announce the 3 /48s in additional to the /40 (following more closely the current IPv4 model for handling acquisitions), even if they're from the same origin ASN? > 6.5.9.5 For each allocation size, ARIN shall further manage the > allocation pools such that the pool identity serves to classify > whether or not the registrant is Multihomed. > > 6.5.9.6 ARIN shall offer addresses from pools classified as multihomed > only to organizations which ARIN has verified are multihomed on the > public Internet per NRPM 2.7. > > 6.5.9.7 Where an organization ceases to be Multihomed it shall > surrender all address allocations from within pools classified as > multihomed within 3 months. I assume this should be re-written to state that the addresses shall only be required to be surrendered if the organization *remains* single-homed for the full three month period. Otherwise, the moment my second upstream provider suffers a serious fiber cut and my link is down for any real duration (24 hour fiber cut, on the order of what happened in Silicon Valley last year), I cease to be "Multihomed", and I get a "you have 3 months to renumber" letter from ARIN telling me to move off my multihomed space onto the single-homed pool. 24 hours after that, I get the "oops, sorry, you don't have to renumber after all" letter from them, when my second upstream link is restored. Also note that NRPM 2.7 was designed primarily for ascertaining the intent to multihome, and does not detail any provisions for ongoing testing and validation of multihoming (which is a horrible can of worms to open up! After all, what if one of my 2 upstreams is Cogent, and ARIN is getting its connectivity from he.net, and only sees one upstream for me, through HE.net; is it my fault ARIN can't see my other upstream because HE.net and Cogent are fighting that year?) > > Q. Why allow only one allocation of each particular size? > > A. Without the address scarcity issue which drives IPv4 policy, the > primary criteria for IPv6 addressing policy is suppressing the > disaggregation that drives route count in the IPv4 DFZ (NRPM 6.3.8). > Such a criteria is not well served if an organization holds dozens of > discontiguous address spaces as a result of acquisitions, mergers and > and growing a little bit at a time. This proposal says, in effect, > once you've consumed your smaller allocation it's time for you to get > a *much* bigger allocation. The rest of us don't want to pay the > routing table price for you coming back again and again and again. > > The proposal could require some renumbering as a result of mergers and > acquisitions. However, with only modest planning on the registrant's > part, the policy its flexible enough to allow that renumbering to > occur over a long period of time so that both cost and disruption are > minimized. In many cases, customer churn can be expected to take care > of much of the renumbering activity all by itself. I don't see any mention of timeframes in this document; you say that to minimize cost and disruption, renumbering from multiple smaller pools obtained due to acquisitions can occur "over a long period of time." Would a five year renumbering cycle be considered reasonable? What about a ten year renumbering cycle? Twenty years? At what point does the claim "I'm renumbering...just very slowly" become specious and indistinguishable from "I'm just going to announce multiple small blocks...deal with it." > Q. What happens when organizations merge or split? > > A. Entities which merge may renumber out of and return ?conflicting > allocations, or they may maintain the existence of the acquired > organization in order to keep it's addresses. Either way it should be > a minor hardship. What about keeping the address blocks within the combined entity? Is that verboten in this plan? Would this then simply lead to a proliferation of ORG-IDs, with every block allocated potentially keeping its own ORG-ID, just so that during mergers and acquisitions no renumbering would be required? Is there any penalty for an organization holding dozens of ORG-IDs under one umbrella? > Entities which split have a bigger problem since the practical effect > of route filtering may be that only one of them can keep the > addresses. To a large extent, that problem already exists and is a > pain in the rump for IPv4 operations today. This policy doesn't solve > it but it doesn't make it a whole lot worse either. Because > disaggregates are likely to be filtered, this IPv6 policy does gives > us a slightly better guarantee that the rest of us won't get stuck > with the check (in the form of routing slot consumption) when an ISP > goes bankrupt and gets split up. It seems to indicate that if I currently have a /40 allocation, and I split up, as long as the split off portion needs more than a /48, it can acquire its own /40, right? > Q. What about reporting requirements for downstream assignments? > > A. Reporting requirements were instituted for the purpose of verifying > eligibility for additional allocations. They have proven useful for > other purposes and the author encourages ARIN to maintain the SWIP > system. Nevertheless, this proposal renders the use of SWIP for IPv6 > optional since it is no longer needed to verify eligibility for > allocations. Ugh. I think that being able to identify sources of malware and spam is eminently useful, as is being able to notify registrants of compromised systems, etc. Not requiring any tracking of downstream number resources makes it very, very hard to identify who the right points of contact are for addressing issues with traffic originating from those number resources. I think reporting requirements for downstream assignments should still be maintained. > Implementation notes: > > To prevent wasteful consumption of IPv6 address space without a > complicated eligibility regime, the author recommends an initial and > annual fee regime for IPv6 address allocations similar to: > > /56 -- $10 USD > /48 -- $100 USD > /40 -- $1000 USD > /32 -- $10,000 USD > /24 -- $100,000 USD Without some controls in place to justify consumption, at those prices it would take less than half a billion dollars to consume all of ARIN's current IPv6 number resources. It might be worth considering *some* level of control to prevent large entities from simply choosing to buy up all available address resources. > For verification of multihoming, the current way ARIN verifies > multihoming for other parts of it's policy appears satisfactory. > Should that change, the author suggests requiring that the AS# > contacts for at least two AS#'s submit a template indicating that they > intend to originate or propagate IPv6 BGP routes from the registrant's > ORG. That's fine for the initial allocation of space in the multihoming pool; but you talk about reclaiming space 3 months after a site ceases to be multihomed; how is that going to be handled? Or will the upstream ISPs need to send re-affirming letters each month to establish their ongoing intent to provide transit services? I see so many issues with this proposal, I don't think I can support it as it currently stands. Can more work be done to address the concerns around mergers, acquisitions, divestitures, and how multihoming determinations are to be handled? Thanks! Matt From bill at herrin.us Sun Nov 22 11:15:21 2009 From: bill at herrin.us (William Herrin) Date: Sun, 22 Nov 2009 11:15:21 -0500 Subject: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process - revised In-Reply-To: <63ac96a50911220021r5ff482eev99a4756d44595e4b@mail.gmail.com> References: <4B06D427.1080905@arin.net> <63ac96a50911220021r5ff482eev99a4756d44595e4b@mail.gmail.com> Message-ID: <3c3e3fca0911220815y6f4fb6f8v40db1f784dadc9a6@mail.gmail.com> On Sun, Nov 22, 2009 at 3:21 AM, Matthew Petach wrote: > I see so many issues with this proposal, I don't think I can support > it as it currently stands. Can more work be done to address the > concerns around mergers, acquisitions, divestitures, and how > multihoming determinations are to be handled? Hi Matthew, We can do lots more work. What would you like to see done differently for the mergers/acquisitions/divestitures process? How would you recommend doing it instead? > So...I'm a company with a /40 allocation. ?I buy up 3 companies > with /48 allocations. ?According to this, ARIN is supposed to drop > the registrations for 2 of the 3 companies, since I can only have > one /40 allocation and one /48 allocation, right? ?What is the > timeframe allocated for renumbering the acquired companies, > and what should ARIN do to the registrations for the blocks in > the meantime? The idea here is that as you integrate these acquired customers into your overall network infrastructure, you will renumber them. There is no prohibition on continuing to operate the acquired ISP as a separate legal entity with a separate network for however long as you find it needful. On the other hand, the PITA aspects of maintaining a separate entity are intended to encourage you to renumber quickly. > If my /40 was already full, and doesn't have room > for the 2 new /48s I have to renumber, do I get a /32 allocation > as well, so I can renumber the 2 /48s into the new /32 (thus > coming back into alignment with the requirement to have only > one allocation from each pool size). ?If that ends my buying > spree, doesn't it seem a bit wasteful to force a company to > get a /32 allocation to accomodate 2 /48s? Bear in mind that a /40 has more than two orders of magnitude more addresses than a /48. If your /40 was 99% full when you started then yes, you'll have to add a /32. If it was only 98% full then it has space left to accommodate the three new /48's. A /40 has the same relationship to a /48 that an IPv4 /16 has to a /24. There are lots of /24's in the /16. >> 6.5.9.7 Where an organization ceases to be Multihomed it shall >> surrender all address allocations from within pools classified as >> multihomed within 3 months. > > I assume this should be re-written to state that the addresses shall > only be required to be surrendered if the organization *remains* > single-homed for the full three month period. If you've resumed multihoming within the three months then you're multihomed. Why would you need to surrender the addresses? This is a policy document; everything in it gets passed through a "common sense" filter during application. In other words, if I intended that you loose the addresses even if you resumed multihoming, I'd have to spell that out. Since the phrasing bothers you, I'll welcome some wordsmithing to set it right. > Also note that NRPM 2.7 was designed primarily for ascertaining the > intent to multihome, and does not detail any provisions for ongoing > testing and validation of multihoming (which is a horrible can of worms > to open up! ?After all, what if one of my 2 upstreams is Cogent, and ARIN > is getting its connectivity from he.net, and only sees one upstream for me, > through HE.net; is it my fault ARIN can't see my other upstream because > HE.net and Cogent are fighting that year?) ARIN currently verifies multihoming by asking you to submit two signed ISP contracts. That's a little more than just intent. It could be open to abuse but there's currently no record of it being routinely abused. If that changes then naturally we'll want ARIN to tighten it's procedures for multihoming verification. Why create extra process if the problem it's intended to resolve doesn't exist yet and might not come to exist at all? >> For verification of multihoming, the current way ARIN verifies >> multihoming for other parts of it's policy appears satisfactory. >> Should that change, the author suggests requiring that the AS# >> contacts for at least two AS#'s submit a template indicating that they >> intend to originate or propagate IPv6 BGP routes from the registrant's >> ORG. > > That's fine for the initial allocation of space in the multihoming pool; > but you talk about reclaiming space 3 months after a site ceases > to be multihomed; how is that going to be handled? Or will the > upstream ISPs need to send re-affirming letters each month to > establish their ongoing intent to provide transit services? If you stop multihoming and don't surrender the addresses, that's a breach of the RSA. Just as if you lie in some other way. When someone reports you, ARIN will audit. ARIN allows multihomed end users to get a /22 of IPv4 addresses but requires single-homed users to wait until they can justify a /20. There hasn't been evidence of any significant abuse. > I don't see any mention of timeframes in this document; you say that to > minimize cost and disruption, renumbering from multiple smaller pools > obtained due to acquisitions can occur "over a long period of time." ? Would > a five year renumbering cycle be considered reasonable? ? What about a > ten year renumbering cycle? ?Twenty years? ?At what point does the claim > "I'm renumbering...just very slowly" become specious and indistinguishable > from "I'm just going to announce multiple small blocks...deal with it." The idea is that you can independently operate the acquired network as long as you like (even 20 years!) but renumber as you fold individual customers into your main network. > What about keeping the address blocks within the combined entity? > Is that verboten in this plan? ?Would this then simply lead to a > proliferation of ORG-IDs, with every block allocated potentially > keeping its own ORG-ID, just so that during mergers and acquisitions > no renumbering would be required? ?Is there any penalty for an > organization holding dozens of ORG-IDs under one umbrella? I addressed this in the added section 6.2.10: 6.2.10 Organization An organization under section 6 is either: one or more legal entities under common control or ownership, or one such legal entity which operates strictly separate networks from the others. >> Entities which split have a bigger problem since the practical effect >> of route filtering may be that only one of them can keep the >> addresses. To a large extent, that problem already exists and is a >> pain in the rump for IPv4 operations today. This policy doesn't solve >> it but it doesn't make it a whole lot worse either. Because >> disaggregates are likely to be filtered, this IPv6 policy does gives >> us a slightly better guarantee that the rest of us won't get stuck >> with the check (in the form of routing slot consumption) when an ISP >> goes bankrupt and gets split up. > > It seems to indicate that if I currently have a /40 allocation, and I > split up, as long as the split off portion needs more than a /48, it > can acquire its own /40, right? If you "split off" the portion into a separate network and legal entity that you sell to someone else then it can acquire a /40 merely because it wants it, regardless of need. What it can't acquire from ARIN is the components of the original /40. You can delegate them and if the Internet's routing policy makes it possible you can conceivably announce them. But at the ARIN level, the original /40 allocation is indivisible. > Ugh. ?I think that being able to identify sources of malware and spam > is eminently useful, as is being able to notify registrants of compromised > systems, etc. I think it's useful too, and I think ARIN should maintain the SWIP system. Public records remains particularly useful to ISPs who want to claim under DMCA safe harbor that the downstream is the service provider so don't bother us. Nevertheless, ARIN's need for that information is tied to evaluating qualification for addresses. Without needing to evaluate qualification, the justification for demanding the information goes away. >> /56 -- $10 USD >> /48 -- $100 USD >> /40 -- $1000 USD >> /32 -- $10,000 USD >> /24 -- $100,000 USD > > Without some controls in place to justify consumption, at those prices > it would take less than half a billion dollars to consume all of ARIN's > current IPv6 number resources. > > It might be worth considering *some* level of control to prevent > large entities from simply choosing to buy up all available address > resources. Half a billion dollars is a lot of disincentive to spend money on resources you don't actually need. When you consider that RIPE has already handed out /19's for considerably less money than $100k per year, I'm not worried about folks abusing this particular "flaw." In the unlikely event that Bill Gates or Warren Buffet decides to spoof the system, we can change the policy for ARIN's next /12. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From michael.dillon at bt.com Sun Nov 22 15:09:27 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Sun, 22 Nov 2009 20:09:27 -0000 Subject: [arin-ppml] Policy Proposal 104: Multiple Discrete Networks forproposal 103 In-Reply-To: <4B06D417.9000208@arin.net> Message-ID: <28E139F46D45AF49A31950F88C497458042DDE65@E03MVZ2-UKDY.domain1.systemhost.net> 100% opposed to this type of policy proposal and I believe that we should not even entertain a discussion of the merits of the text of such a proposal. In fact, I would like to see the AC make a statement to make it clear that such policy proposals are not acceptable and will not be put forward for discussion in future. The purpose of the PPML is to discuss proposed changes to policy. This proposal wants us to discuss proposed changes to a proposal which is not yet policy. This is highly confusing, because now it is unclear whether any comments regarding proposal 103 include, or exclude the proposed changes in proposal 104. I would rather see a complete new proposal that competes with proposal 103, as we have done in the past although that is not really optimal. The fact is that during the discussion of any policy proposal, changes and additions are suggested without creating additional formal proposals. Then, the authors generally incorporate some form of the changes and additions and propose a new changed text for the original proposal. At all times, there is only the one proposal under discussion. Even though I prefer succint proposals, I would rather see a proposal with additional clauses which can be neatly cut off if they do not have support, than to muddy the waters the way that this one does. --Michael Dillon From bill at herrin.us Sun Nov 22 16:32:11 2009 From: bill at herrin.us (William Herrin) Date: Sun, 22 Nov 2009 16:32:11 -0500 Subject: [arin-ppml] Policy Proposal 104: Multiple Discrete Networks forproposal 103 In-Reply-To: <28E139F46D45AF49A31950F88C497458042DDE65@E03MVZ2-UKDY.domain1.systemhost.net> References: <4B06D417.9000208@arin.net> <28E139F46D45AF49A31950F88C497458042DDE65@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <3c3e3fca0911221332y4bc6a8f9o3b03c45114dd7cda@mail.gmail.com> On Sun, Nov 22, 2009 at 3:09 PM, wrote: > Even though I prefer succint proposals, I would rather see a proposal > with additional clauses which can be neatly cut off if they do not have > support, than to muddy the waters the way that this one does. Hi Michael, Thanks for the feedback. I split them into separate proposals because I believe that Multiple Discrete Networks raises functionally different issues from proposal 103. Should someone propose an elegant way to unify the two, I'll read it with interest. I have no opinion on the merits of incorporating the final version of 104 into the final version of 103 and will follow the AC's guidance on the matter. > This proposal wants us to discuss proposed changes to a proposal which > is not yet policy. My understanding is that IPv6 Multiple Discrete Networks (proposal 2009-5) is very likely to become policy. Proposal 104 is offered in anticipation of that outcome. If for some reason 2009-5 does not become policy, 104 will obviously be moot in its entirety. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From scottleibrand at gmail.com Sun Nov 22 17:35:53 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Sun, 22 Nov 2009 14:35:53 -0800 Subject: [arin-ppml] Policy Proposal 104: Multiple Discrete Networks forproposal 103 In-Reply-To: <3c3e3fca0911221332y4bc6a8f9o3b03c45114dd7cda@mail.gmail.com> References: <4B06D417.9000208@arin.net> <28E139F46D45AF49A31950F88C497458042DDE65@E03MVZ2-UKDY.domain1.systemhost.net> <3c3e3fca0911221332y4bc6a8f9o3b03c45114dd7cda@mail.gmail.com> Message-ID: <4B09BCC9.4020208@gmail.com> William Herrin wrote: > On Sun, Nov 22, 2009 at 3:09 PM, wrote: > >> Even though I prefer succint proposals, I would rather see a proposal >> with additional clauses which can be neatly cut off if they do not have >> support, than to muddy the waters the way that this one does. >> > > Hi Michael, > > Thanks for the feedback. I split them into separate proposals because > I believe that Multiple Discrete Networks raises functionally > different issues from proposal 103. Should someone propose an elegant > way to unify the two, I'll read it with interest. > I'm not sure how elegant it'll be, but I suspect that if we move proposal 103 forward, the AC will indeed merge 104 into it before either of them become draft policy. > I have no opinion on the merits of incorporating the final version of > 104 into the final version of 103 and will follow the AC's guidance on > the matter. > My own personal opinion is that 103+104 is better than 103 alone, to the same degree that current policy + MDN is better than current policy alone. >> This proposal wants us to discuss proposed changes to a proposal which >> is not yet policy. >> > > My understanding is that IPv6 Multiple Discrete Networks (proposal > 2009-5) is very likely to become policy. Proposal 104 is offered in > anticipation of that outcome. If for some reason 2009-5 does not > become policy, 104 will obviously be moot in its entirety. I'm not the one who makes official announcements, but in the interests of informing the discussion, it's worth noting that at Thursday's meeting, the AC approved a motion that "The ARIN Advisory Council, based on comments from stakeholders expressed either at the ARIN XXIV Public Policy Meeting, or on the ARIN Public Policy Mailing List, having reviewed the comments collected during the Last Call period, and noting that the Policy Development Process has been followed, supports Draft Policy 2009-5: IPv6 Multiple Discrete Networks and recommends the ARIN Board of Trustees adopt it." -Scott From owen at delong.com Sun Nov 22 23:10:23 2009 From: owen at delong.com (Owen DeLong) Date: Sun, 22 Nov 2009 20:10:23 -0800 Subject: [arin-ppml] Policy Proposal 104: Multiple Discrete Networks forproposal 103 In-Reply-To: <28E139F46D45AF49A31950F88C497458042DDE65@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458042DDE65@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <7A203F7E-38E2-4682-A4C8-41B3ABB54B7C@delong.com> I think it is likely that if the AC accepts either proposal 103 or 104 onto the docket, we would accept both and merge them. I am not speaking for the AC in this regard, but, that seems the logical step forward if the proposals are accepted onto the docket. Owen On Nov 22, 2009, at 12:09 PM, wrote: > > 100% opposed to this type of policy proposal and I believe that we > should not even entertain a discussion of the merits of the text of > such > a proposal. In fact, I would like to see the AC make a statement to > make > it clear that such policy proposals are not acceptable and will not be > put forward for discussion in future. > > The purpose of the PPML is to discuss proposed changes to policy. > > This proposal wants us to discuss proposed changes to a proposal which > is not yet policy. > > This is highly confusing, because now it is unclear whether any > comments > regarding proposal 103 include, or exclude the proposed changes in > proposal 104. > > I would rather see a complete new proposal that competes with proposal > 103, as we have done in the past although that is not really optimal. > > The fact is that during the discussion of any policy proposal, changes > and additions are suggested without creating additional formal > proposals. Then, the authors generally incorporate some form of the > changes and additions and propose a new changed text for the original > proposal. At all times, there is only the one proposal under > discussion. > Even though I prefer succint proposals, I would rather see a proposal > with additional clauses which can be neatly cut off if they do not > have > support, than to muddy the waters the way that this one does. > > --Michael Dillon > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From michael.dillon at bt.com Mon Nov 23 04:22:28 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 23 Nov 2009 09:22:28 -0000 Subject: [arin-ppml] Policy Proposal 104: Multiple Discrete Networks forproposal 103 In-Reply-To: <3c3e3fca0911221332y4bc6a8f9o3b03c45114dd7cda@mail.gmail.com> Message-ID: <28E139F46D45AF49A31950F88C497458042DDFDE@E03MVZ2-UKDY.domain1.systemhost.net> > Thanks for the feedback. I split them into separate proposals > because I believe that Multiple Discrete Networks raises > functionally different issues from proposal 103. Then why did you entitle as follows? Policy Proposal 104: Multiple Discrete Networks for proposal 103 --Michael Dillon From info at arin.net Tue Nov 24 11:18:03 2009 From: info at arin.net (Member Services) Date: Tue, 24 Nov 2009 11:18:03 -0500 Subject: [arin-ppml] Advisory Council Meeting Results - November 2009 Message-ID: <4B0C073B.6090604@arin.net> In accordance with the ARIN Policy Development Process the ARIN Advisory Council (AC) held a meeting on 19 November 2009 and made decisions about several draft policies and proposals. The AC recommended the following four draft policies to the ARIN Board of Trustees for adoption: 2009-3 (Global Proposal): Allocation of IPv4 Blocks to Regional Internet Registries (with an updated rationale) 2009-5: IPv6 Multiple Discrete Networks 2009-6 (Global Proposal): Internet Assigned Numbers Authority (IANA) Policy for Allocation of ASN Blocks (ASNs) to Regional Internet Registries 2009-7: Open Access To IPv6 The AC moved the following draft policy to last call as revised. It will be posted separately to last call. 2009-8: Equitable IPv4 Run-Out The AC abandoned the following proposal: 98. Last Minute Assistance for Small ISPs The AC stated, "The ARIN Advisory Council determined to abandon Policy Proposal #98: Last Minute Assistance for Small ISPs. This action reflects the interaction on the Public Policy Mailing List and the feelings of the primary AC shepherd that the proposal is overly complicated. Seemingly the essence of the proposal is to lower the minimum allocation level. As such, we have informed the author of this action and encouraged him to resubmit a simplified version that reflects the community's input." The AC is continuing to work on the following proposals: 99. /24 End User Minimum Allocation Unit 97. Waiting List for Unmet IPv4 Requests 95. Customer Confidentiality The AC chose to extend their review of the following new proposals to their regularly scheduled meeting in December: 103. Change IPv6 Allocation Process 102. Reduce and Simplify IPv4 Initial Allocations 101. Multihomed initial allocation criteria The AC made two decisions that can be petitioned. If someone is dissatisfied with the abandonment of Policy Proposal 98, it can be petitioned. 2009-8 may also be petitioned if someone is dissatisfied with the AC?s decision to send revised text to last call. The deadline to begin a petition is 3 December 2009. For more information on starting and participating in petitions, see PDP Petitions at: https://www.arin.net/policy/pdp_petitions.html Draft Policy and Proposal texts are available at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Regards, Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Tue Nov 24 11:18:21 2009 From: info at arin.net (Member Services) Date: Tue, 24 Nov 2009 11:18:21 -0500 Subject: [arin-ppml] Draft Policy 2009-8: Equitable IPv4 Run-Out - Last Call Message-ID: <4B0C074D.9020608@arin.net> The ARIN Advisory Council (AC) met on 19 November and decided to send a revised version of the following draft policy to last call: Draft Policy 2009-8: Equitable IPv4 Run-Out Feedback is encouraged during this last call period. All comments should be provided to the Public Policy Mailing List. This last call will expire on 10 December 2009. After last call the AC will conduct their last call review. The draft policy text is below and available at: https://www.arin.net/policy/proposals/ The ARIN Policy Development Process is available at: https://www.arin.net/policy/pdp.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy 2009-8 Equitable IPv4 Run-Out Version/Date: 24 November 2009 Policy statement: Rename NRPM 4.2.4.3; 4.2.4.3 Subscriber Members Less Than One Year Replace NRPM 4.2.4.4 with; 4.2.4.4 Subscriber Members After One Year After an organization has been a subscriber member of ARIN for one year, they may choose to request up to a 12 month supply of IP addresses. When ARIN receives its last /8, by IANA implementing section 10.4.2.2, the length of supply that an organization may request will be reduced. An organization may choose to request up to a 3 month supply of IP addresses. This reduction does not apply to resources received via section 8.3. An organization receiving a transfer under section 8.3 may continue to request up to a 12 month supply of IP addresses. Rationale: This policy is intended to ensure an equitable distribution of IPv4 resources as run-out of the ARIN free pool occurs. This is achieved by changing section 4.2.4.4 of the NRPM to reduce the length of supply of IPv4 resources that may be requested when the IANA free pool runs-out. Equity is accomplished by reducing the window that an advantage or disadvantage can exist between competitors, that will be created when one competitor receives a final allocation just before run-out and another competitor does not. Further this policy ensures equity between incumbent resource holders and new entrants by providing the same length of supply for each as the ARIN free pool runs out. This eliminates a potential bias toward incumbent resource holders that is created as a result of ARIN free pool run-out interacting with resource allocation slow start for new entrants in current policy. This policy is similar to ideas in RIPE policy proposal 2009-03 (http://www.ripe.net/ripe/policies/proposals/2009-03.html), and has been adapted by discussion and for use within the ARIN region. This policy is intended to be independent of other policies or proposals to reserve address space for IPv6 transition or other purposes. It is not intended to limit Transfers to Specified Recipients per section 8.3 of the NRPM. This draft contains the elements that there seems to have been the largest consensus for on the floor of ARIN XXIV Public Policy Meeting in Dearborn, Michigan. Further, there was a strong preference that no changes be triggered until IANA free pool run-out. Timetable for implementation: Immediate From cmettin at gqbc-online.com Sat Nov 28 08:27:25 2009 From: cmettin at gqbc-online.com (Christopher Mettin) Date: Sat, 28 Nov 2009 14:27:25 +0100 Subject: [arin-ppml] Policy Change Request: IP Address Assignment to Educational and Non-Commercial Organizations In-Reply-To: References: Message-ID: To the American Regional IP Network Community, Don't you think that current ARIN fees exceeds the true value of IP addresses? Actually, they are just numbers, and ARIN is in charge by IANA to assign these IP's to people in all North America. For commercial companies with revenues of several Million Dollars a year these IP address blocks ARIN assigns are affordable. But smaller non-commercial organizations and even schools cannot pay for them. Especially for high schools, colleges, and smaller universities such prices can mean a harm to their classroom project, thus they mean a harm to education. ARIN should change their policies to waive the fees for educational institutions and non-commercial organizations. Thank you. Sincerely yours, Christopher Mettin Gymnasium Querfurt High School From joelja at bogus.com Sat Nov 28 15:01:33 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Sat, 28 Nov 2009 12:01:33 -0800 Subject: [arin-ppml] Policy Change Request: IP Address Assignment to Educational and Non-Commercial Organizations In-Reply-To: References: Message-ID: <4B11819D.6090702@bogus.com> Submit a policy proposal... The question I would pose is there is administrative overhead associated with the management of assignments, what justifies the cost of the overhead being borne by one entity an not another? Are there batter ways to achieve your aim then simply creating new corner cases? Christopher Mettin wrote: > To the American Regional IP Network Community, > > Don't you think that current ARIN fees exceeds the true value of IP > addresses? Actually, they are just numbers, and ARIN is in charge by IANA to > assign these IP's to people in all North America. For commercial companies > with revenues of several Million Dollars a year these IP address blocks ARIN > assigns are affordable. But smaller non-commercial organizations and even > schools cannot pay for them. > > Especially for high schools, colleges, and smaller universities such prices > can mean a harm to their classroom project, thus they mean a harm to > education. > > ARIN should change their policies to waive the fees for educational > institutions and non-commercial organizations. > > Thank you. > > Sincerely yours, > Christopher Mettin > Gymnasium Querfurt High School > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From sethm at rollernet.us Sat Nov 28 15:04:07 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Sat, 28 Nov 2009 12:04:07 -0800 Subject: [arin-ppml] Policy Change Request: IP Address Assignment to Educational and Non-Commercial Organizations In-Reply-To: References: Message-ID: <4B118237.7070402@rollernet.us> Christopher Mettin wrote: > To the American Regional IP Network Community, > > Don't you think that current ARIN fees exceeds the true value of IP > addresses? Actually, they are just numbers, and ARIN is in charge by IANA to > assign these IP's to people in all North America. For commercial companies > with revenues of several Million Dollars a year these IP address blocks ARIN > assigns are affordable. But smaller non-commercial organizations and even > schools cannot pay for them. > > Especially for high schools, colleges, and smaller universities such prices > can mean a harm to their classroom project, thus they mean a harm to > education. > > ARIN should change their policies to waive the fees for educational > institutions and non-commercial organizations. > What exactly makes you think you need to pay ARIN to get on the internet? ~Seth From scottleibrand at gmail.com Sat Nov 28 15:27:13 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Sat, 28 Nov 2009 12:27:13 -0800 Subject: [arin-ppml] Policy Change Request: IP Address Assignment to Educational and Non-Commercial Organizations In-Reply-To: References: Message-ID: <4B1187A1.8050009@gmail.com> Christopher, Generally, smaller education institutions, non-profit organizations, and small business get their IP addresses from their upstream ISP. It is generally only necessary to get IPs directly from ARIN (and pay ARIN fees) if you intend to multihome with BGP and your own ASN. Can you provide some specifics regarding what kind of connectivity these high schools, colleges, and smaller universities are using that requires provider independent space from ARIN, rather than provider allocated space from their ISP? Thanks, Scott Christopher Mettin wrote: > To the American Regional IP Network Community, > > Don't you think that current ARIN fees exceeds the true value of IP > addresses? Actually, they are just numbers, and ARIN is in charge by IANA to > assign these IP's to people in all North America. For commercial companies > with revenues of several Million Dollars a year these IP address blocks ARIN > assigns are affordable. But smaller non-commercial organizations and even > schools cannot pay for them. > > Especially for high schools, colleges, and smaller universities such prices > can mean a harm to their classroom project, thus they mean a harm to > education. > > ARIN should change their policies to waive the fees for educational > institutions and non-commercial organizations. > > Thank you. > > Sincerely yours, > Christopher Mettin > Gymnasium Querfurt High School > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From farmer at umn.edu Sat Nov 28 17:29:27 2009 From: farmer at umn.edu (David Farmer) Date: Sat, 28 Nov 2009 16:29:27 -0600 Subject: [arin-ppml] Policy Change Request: IP Address Assignment to Educational and Non-Commercial Organizations In-Reply-To: <4B1187A1.8050009@gmail.com> References: , , <4B1187A1.8050009@gmail.com> Message-ID: <4B114FE7.16162.EC33F3E@farmer.umn.edu> Hello Christopher, Thank you for your interest and participation. But first, I'm interested in knowing why a student network administrator from a high school in Germany is interested in ARIN's fee structure for non-profit organizations? I believe you would get your IP addresses and other number resources from RIPE NCC. http://www.ripe.net/ Please do not think I am implying you are not welcome to participate, everyone is welcome to participate in policy discussions on PPML. However, it is rather unusual, and I'm interested if there is a specific reason you are interested in ARIN's policies even thought they probablly wouldn't apply to you? So now to the actual discussion; The fee structure that ARIN charges is set by the ARIN Board of Trustees to recover the costs of ARIN's operations. The fee structure itself is not normally considered a policy matter for discussion on the PPML mailing list. However, it is sometimes difficult for people to separate the fee structure from the resource management policies that are intended to be discussed on PPML, so the subject does frequently come up in discussions on this list. As Scott says the intent is for smaller organizations, commercial or non- profit, to get their IP addresses from upstream service providers. Having smaller end-users get their addresses from service providers promotes aggregation and helps to maintain the Internet Routing table at a manageable size. Some may argue it is way beyond a manageable size already, but if every small organization had its own address assignment from ARIN or the other RIRs, it would be many times if not an order of magnitude larger than it is today. As someone who is from a large non-profit end-user of IP addresses (the University fo Minnesota), I believe the current fee structure provides cost effective access to necessary resources for both commercial and non-profit end-users that are large enough to receive resources directly from ARIN. End-users that are large enough, pay a one-time fee based on the amount of resources received and a $100 annual maintenance fee associated with each end-user organization, regardless of the total amount of resources they use. Whereas, service providers pay a one-time fee based on the amount of resources received and an annual maintenance fee to base on the total amount of resource they use. Medium to large end-users typically receive a comparable amount of resources to smaller services providers, sometime even more. An equitable balance needs to be maintained between these medium to large end-users and the smaller service providers. I believe ARIN's current fee structure properly balances these issues. Thank you. On 28 Nov 2009 Scott Leibrand wrote: > Christopher, > > Generally, smaller education institutions, non-profit organizations, and > small business get their IP addresses from their upstream ISP. It is > generally only necessary to get IPs directly from ARIN (and pay ARIN > fees) if you intend to multihome with BGP and your own ASN. Can you > provide some specifics regarding what kind of connectivity these high > schools, colleges, and smaller universities are using that requires > provider independent space from ARIN, rather than provider allocated > space from their ISP? > > Thanks, > Scott > > Christopher Mettin wrote: > > To the American Regional IP Network Community, > > > > Don't you think that current ARIN fees exceeds the true value of IP > > addresses? Actually, they are just numbers, and ARIN is in charge by IANA to > > assign these IP's to people in all North America. For commercial companies > > with revenues of several Million Dollars a year these IP address blocks ARIN > > assigns are affordable. But smaller non-commercial organizations and even > > schools cannot pay for them. > > > > Especially for high schools, colleges, and smaller universities such prices > > can mean a harm to their classroom project, thus they mean a harm to > > education. > > > > ARIN should change their policies to waive the fees for educational > > institutions and non-commercial organizations. > > > > Thank you. > > > > Sincerely yours, > > Christopher Mettin > > Gymnasium Querfurt High School =============================================== David Farmer Email:farmer at umn.edu Office of Information Technology Networking & Telecomunication Services University of Minnesota Phone: 612-626-0815 2218 University Ave SE Cell: 612-812-9952 Minneapolis, MN 55414-3029 FAX: 612-626-1818 =============================================== From cmettin at gqbc-online.com Sat Nov 28 19:00:06 2009 From: cmettin at gqbc-online.com (Christopher Mettin) Date: Sun, 29 Nov 2009 01:00:06 +0100 Subject: [arin-ppml] Continuation: Policy Change Request: IP Address Assignment to Educational and Non-Commercial Organizations In-Reply-To: References: Message-ID: We just need maybe 2 or 3 blocks containing up to 255 hosts (of IP v4 addresses). We have partner schools in several US states. We plan to create a program allowing us to share classroom resources and to communicate directly. Unfortunately, our ISPs assign us dynamic IP addresses only and thus they change every 24 hours. Static IP addresses allow us to allow a connection establishment without allowing people other than our students to join. But having dynamic IP addresses only, we are forced to allow access by the entire ISP subnet which could mean a potential harm to our network. Can anyone provide us with a bunch of addresses? We would be very grateful. But such a chance should available to anyone else of the named parties as well. Thank you. Sincerely yours, Christopher Mettin Gymnasium Querfurt High School -----Original Message----- From: Christopher Mettin [mailto:cmettin at gqbc-online.com] Sent: Saturday, November 28, 2009 2:27 PM To: arin-ppml at arin.net Subject: [arin-ppml] Policy Change Request: IP Address Assignment to Educational and Non-Commercial Organizations To the American Regional IP Network Community, Don't you think that current ARIN fees exceeds the true value of IP addresses? Actually, they are just numbers, and ARIN is in charge by IANA to assign these IP's to people in all North America. For commercial companies with revenues of several Million Dollars a year these IP address blocks ARIN assigns are affordable. But smaller non-commercial organizations and even schools cannot pay for them. Especially for high schools, colleges, and smaller universities such prices can mean a harm to their classroom project, thus they mean a harm to education. ARIN should change their policies to waive the fees for educational institutions and non-commercial organizations. Thank you. Sincerely yours, Christopher Mettin Gymnasium Querfurt High School From sethm at rollernet.us Sat Nov 28 19:20:13 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Sat, 28 Nov 2009 16:20:13 -0800 Subject: [arin-ppml] Continuation: Policy Change Request: IP Address Assignment to Educational and Non-Commercial Organizations In-Reply-To: References: Message-ID: <4B11BE3D.10605@rollernet.us> Christopher Mettin wrote: > We just need maybe 2 or 3 blocks containing up to 255 hosts (of IP v4 > addresses). > > We have partner schools in several US states. We plan to create a program > allowing us to share classroom resources and to communicate directly. > Unfortunately, our ISPs assign us dynamic IP addresses only and thus they > change every 24 hours. Static IP addresses allow us to allow a connection > establishment without allowing people other than our students to join. But > having dynamic IP addresses only, we are forced to allow access by the > entire ISP subnet which could mean a potential harm to our network. > Ask the US ISP for static subnets. You don't need to engage ARIN for that. ~Seth From jradel at vantage.com Sat Nov 28 19:49:58 2009 From: jradel at vantage.com (Jon Radel) Date: Sat, 28 Nov 2009 19:49:58 -0500 Subject: [arin-ppml] Continuation: Policy Change Request: IP Address Assignment to Educational and Non-Commercial Organizations In-Reply-To: References: Message-ID: <4B11C536.3060303@vantage.com> Christopher Mettin wrote: > We just need maybe 2 or 3 blocks containing up to 255 hosts (of IP v4 > addresses). > > We have partner schools in several US states. We plan to create a program > allowing us to share classroom resources and to communicate directly. > Unfortunately, our ISPs assign us dynamic IP addresses only and thus they > change every 24 hours. Static IP addresses allow us to allow a connection > establishment without allowing people other than our students to join. But > having dynamic IP addresses only, we are forced to allow access by the > entire ISP subnet which could mean a potential harm to our network. > > Can anyone provide us with a bunch of addresses? > We would be very grateful. But such a chance should available to anyone else > of the named parties as well. > > Thank you. > > Sincerely yours, > Christopher Mettin > Gymnasium Querfurt High School > > As somebody has already touched on, I'd be surprised if all the ISPs involved allowed you to bring /24s to the table, particularly ones "donated" by somebody else that has no relationship to any of the involved schools, yet didn't have static addresses available upon request. What do your ISPs have to say about all this? Second, might I suggest that you look into VPNs as a partial solution to your security issues, although admittedly they're easier to setup if you have static IP addresses at your disposal. Third, you appear to be going down a path of using fixed IP addresses to separate insiders from outsiders who use the same ISP, with insiders trusted and the other ISP customers not trusted. That strikes me as a rather simplistic threat model to be working with. Frankly, without any further information, I'd say the odds are that the curious and malicious that are already on the school networks are much more likely to mess around with the other school's equipment than random ISP customers are. Not that it's a bad thing to restrict the outsiders, but..... I admit the above may be selling your analysis of the situation short, but nothing I've seen about the problem you're trying to solve even begins to address why ARIN should change its fee structure or completely change the requirements for PI space assignment (if my guess that you're all single-homed school networks and in no danger of justifying a /20 is correct). My suggestion would be that you hit up your respective ISPs to give you static addresses at no extra charge for the good will and possible tax benefits. Even if they're only willing to give you /29s, you can harmonize your RFC1918 address space use and use VPNs that properly reflect your security policies. --Jon Radel jon at radel.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3303 bytes Desc: S/MIME Cryptographic Signature URL: From cmettin at gqbc-online.com Sat Nov 28 20:16:31 2009 From: cmettin at gqbc-online.com (Christopher Mettin) Date: Sun, 29 Nov 2009 02:16:31 +0100 Subject: [arin-ppml] IP Address Fee Structure Policy and the Right of Education Message-ID: ARIN Community, This message is on my proposed resolution to the current ARIN policy and fee structure. Seth Mattinen wrote: >What exactly makes you think you need to pay ARIN to get on the internet? The fact that one can't access the Internet without an IP address and that ARIN sells them. Seth Mattinen wrote: >As somebody has already touched on, I'd be surprised if all the ISPs >involved allowed you to bring /24s to the table, particularly ones >"donated" by somebody else that has no relationship to any of the >involved schools, yet didn't have static addresses available upon >request. What do your ISPs have to say about all this? > >Second, might I suggest that you look into VPNs as a partial solution to >your security issues, although admittedly they're easier to setup if you >have static IP addresses at your disposal. > >Third, you appear to be going down a path of using fixed IP addresses to >separate insiders from outsiders who use the same ISP, with insiders >trusted and the other ISP customers not trusted. That strikes me as a >rather simplistic threat model to be working with. Frankly, without any >further information, I'd say the odds are that the curious and malicious >that are already on the school networks are much more likely to mess >around with the other school's equipment than random ISP customers >are. Not that it's a bad thing to restrict the outsiders, but..... > >I admit the above may be selling your analysis of the situation short, >but nothing I've seen about the problem you're trying to solve even >begins to address why ARIN should change its fee structure or completely >change the requirements for PI space assignment (if my guess that you're >all single-homed school networks and in no danger of justifying a /20 is >correct). >My suggestion would be that you hit up your respective ISPs to give you >static addresses at no extra charge for the good will and possible tax >benefits. Even if they're only willing to give you /29s, you can >harmonize your RFC1918 address space use and use VPNs that properly >reflect your security policies. Yep, VPS, you cannot set them up so easily if you don't have a commonly known (static) IP address of the end-point. Where should we send the VPS connection request if our IP always changes? Maybe try out every host on the entire ISP subnet? Our Internet connection is paid by the state. And under the current contract we actually even not allowed to publish a simple website from our network. So why should they give us a static IP to make it easier for us to do so? So the reason why ARIN should change its policies is that we want ARIN to allocate us some IP addresses which are the only way for us to solve our little problem. Thannk you. Sincerely yours, Christopher Mettin From sethm at rollernet.us Sat Nov 28 20:32:34 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Sat, 28 Nov 2009 17:32:34 -0800 Subject: [arin-ppml] IP Address Fee Structure Policy and the Right of Education In-Reply-To: References: Message-ID: <4B11CF32.3080202@rollernet.us> Christopher Mettin wrote: > ARIN Community, > > This message is on my proposed resolution to the current ARIN policy and fee > structure. > > Seth Mattinen wrote: >> What exactly makes you think you need to pay ARIN to get on the internet? > > The fact that one can't access the Internet without an IP address and that > ARIN sells them. > That's false. ARIN does not "sell" addresses and you do not need to engage ARIN directly to access the internet. > > Our Internet connection is paid by the state. And under the current contract > we actually even not allowed to publish a simple website from our network. > So why should they give us a static IP to make it easier for us to do so? > Then they are extremely unlikely to let you break away and ARIN PI space even if you were to get it. It sounds like you are limited by your ISP contracts, not ARIN policy. ~Seth From baptista at publicroot.org Sat Nov 28 20:40:21 2009 From: baptista at publicroot.org (Joe Baptista) Date: Sat, 28 Nov 2009 20:40:21 -0500 Subject: [arin-ppml] FRAUD ALERT Re: Continuation: Policy Change Request: IP Address Assignment to Educational and Non-Commercial Organizations Message-ID: <874c02a20911281740t56247ebfy590b06cf2f00d91b@mail.gmail.com> OK - before someone end up donating addresses and gets involved in a fraud - I think it's time for a little backgrounder on Christopher Mettin. http://bit.ly/87Yjir What Chris needs are a few blocks of /24 to setup a root system based on what I know of him. Thats what I think he is going on about - that they need fixed IP. About the only protocol widely used still requiring fixed IP for the root cache. Be careful I have been unable to confirm what he is doing is even authorized by the school. If you feel so inclined to provide /24 blocks to them - make sure a responsible adult from the school signs on the dotted line, takes responsibility and absolves you of any legal liability. I do however support his initial point. These are only numbers and ARIN RIPE APNIC et. al. are making a killing for just providing a database function - the rest as far as I can see is mainly hype and make work projects. I think thats been mentioned before. cheers joe baptista On Sat, Nov 28, 2009 at 7:00 PM, Christopher Mettin wrote: > We just need maybe 2 or 3 blocks containing up to 255 hosts (of IP v4 > addresses). > > We have partner schools in several US states. We plan to create a program > allowing us to share classroom resources and to communicate directly. > Unfortunately, our ISPs assign us dynamic IP addresses only and thus they > change every 24 hours. Static IP addresses allow us to allow a connection > establishment without allowing people other than our students to join. But > having dynamic IP addresses only, we are forced to allow access by the > entire ISP subnet which could mean a potential harm to our network. > > Can anyone provide us with a bunch of addresses? > We would be very grateful. But such a chance should available to anyone > else > of the named parties as well. > > Thank you. > > Sincerely yours, > Christopher Mettin > Gymnasium Querfurt High School > > -----Original Message----- > From: Christopher Mettin [mailto:cmettin at gqbc-online.com] > Sent: Saturday, November 28, 2009 2:27 PM > To: arin-ppml at arin.net > Subject: [arin-ppml] Policy Change Request: IP Address Assignment to > Educational and Non-Commercial Organizations > > To the American Regional IP Network Community, > > Don't you think that current ARIN fees exceeds the true value of IP > addresses? Actually, they are just numbers, and ARIN is in charge by IANA > to > assign these IP's to people in all North America. For commercial companies > with revenues of several Million Dollars a year these IP address blocks > ARIN > assigns are affordable. But smaller non-commercial organizations and even > schools cannot pay for them. > > Especially for high schools, colleges, and smaller universities such prices > can mean a harm to their classroom project, thus they mean a harm to > education. > > ARIN should change their policies to waive the fees for educational > institutions and non-commercial organizations. > > Thank you. > > Sincerely yours, > Christopher Mettin > Gymnasium Querfurt High School > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- Joe Baptista www.publicroot.org PublicRoot Consortium ---------------------------------------------------------------- The future of the Internet is Open, Transparent, Inclusive, Representative & Accountable to the Internet community @large. ---------------------------------------------------------------- Office: +1 (360) 526-6077 (extension 052) Fax: +1 (509) 479-0084 Personal: http://baptista.cynikal.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmettin at gqbc-online.com Sat Nov 28 20:55:38 2009 From: cmettin at gqbc-online.com (Christopher Mettin) Date: Sun, 29 Nov 2009 02:55:38 +0100 Subject: [arin-ppml] Joe Baptista is an Internet Terrorist known for attacking several Internet companies and even my school Message-ID: ARIN Community, The following message was sent recently to the ARIN mailing list by an Internet terrorist known as Joe Baptista. >OK - before someone end up donating addresses and gets involved in a fraud - I think it's time for a little >backgrounder on Christopher Mettin. > >http://bit.ly/87Yjir > >What Chris needs are a few blocks of /24 to setup a root system based on what I know of him. Thats what I think >he is going on about - that they need fixed IP. About the only protocol widely used still requiring fixed IP >for the root cache. > >Be careful I have been unable to confirm what he is doing is even authorized by the school. If you feel so >inclined to provide /24 blocks to them - make sure a responsible adult from the school signs on the dotted >line, takes responsibility and absolves you of any legal liability. > >I do however support his initial point. These are only numbers and ARIN RIPE APNIC et. al. are making a killing >for just providing a database function - the rest as far as I can see is mainly hype and make work projects. I >think thats been mentioned before. A few months ago my school has been attacked by this guy. He did already make an entire company shut down. His best weapons are lies. All that started when he was fired by the Public Root in 2005. We have been assigned a domain by a company affiliated with the Public Root Ltd. and so we became a major target to him. He sends his emails from a domain publishing a website of a "PublicRoot Consortium" which does not exist. The contact address of this consortium is a private home in an Ontarian suburb. Sending emails using this domain he tries to make people believe he is an official employee of the Public Root. The IP addresses shall be in no way used with any root system. For further reference on Joe Baptista, see http://inaic.com/index.php?p=news-25-08-2008. Sincerely yours, Christopher Mettin Gymnasium Querfurt High School From sethm at rollernet.us Sat Nov 28 21:13:36 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Sat, 28 Nov 2009 18:13:36 -0800 Subject: [arin-ppml] Joe Baptista is an Internet Terrorist known for attacking several Internet companies and even my school In-Reply-To: References: Message-ID: <4B11D8D0.5040008@rollernet.us> Christopher Mettin wrote: > ARIN Community, > > The following message was sent recently to the ARIN mailing list by an > Internet terrorist known as Joe Baptista. > Really, don't perpetuate that crap on this list. Thanks. ~Seth From mysidia at gmail.com Sat Nov 28 21:22:37 2009 From: mysidia at gmail.com (James Hess) Date: Sat, 28 Nov 2009 20:22:37 -0600 Subject: [arin-ppml] Continuation: Policy Change Request: IP Address Assignment to Educational and Non-Commercial Organizations In-Reply-To: References: Message-ID: <6eb799ab0911281822m69ca9b07x7b67ec3273c914c7@mail.gmail.com> On Sat, Nov 28, 2009 at 6:00 PM, Christopher Mettin wrote: > We just need maybe 2 or 3 blocks containing up to 255 hosts (of IP v4 > addresses). If you need blocks of global IP addresses, ask your upstream ISP for the blocks to be assigned to the networks first. ISPs receive blocks of IP addresses for the sole purpose of delegating to customer networks. Provided the customer network has a documented justifiable need for the amount of IPs. ARIN does not sell IP addresses. IP addresses are not for sale, although, there are fees involved in obtaining IPs from ARIN, the main criteria, is you first must have a justifiable need for the minimum sized block, that is You only go to ARIN if you need an allocation of least a /20 (4096 ips), or are multi-homed with 2 or more ISPs and need at least a /22 (1024 ips), and can get the documentation to show that you will meet the utilization criteria. This is all described in the Number Resources Policy Manual: https://www.arin.net/policy/nrpm.html If your ISP won't assign needed IPs to you, it might be time to switch ISPs or get a renegotiation of the contract with your ISP, including provisioning of IP addresses that you have documented need for. If the ISP is not willing to work with you to get the IPs you need... then what good is it to get IPs delegated from ARIN or from someone else? Only for your ISP to then tell you they aren't willing to announce the IP addresses for you, or to grant you a BGP feed for announcing the space. Unless an ISP of yours does extra work to provide the connectivity, you'll have no means to actually use those newly acquired IPs: it's not possible to simply assign one to your router and be done with it. Your ISP has to designate a static IP that your router can use. Your newly acquired IP block needs to get announced by some ISP connect to your sites, who is willing to forward traffic addressed to those IPs to your sites. > change every 24 hours. Static IP addresses allow us to allow a connection > establishment without allowing people other than our students to join. But > having dynamic IP addresses only, we are forced to allow access by the > entire ISP subnet which could mean a potential harm to our network. For such an application I would suggest utilizing PRIVATE IPs and a VPN application, for example you could subscribe to a service such as Hamachi (for example) to create connections between locations. Only allow users to "share" resources when connected to the VPN service. Or get your ISPs to provide each location at least 1 static IP for a VPN router: in that case, with a large number of schools, there is a good chance some would be already utilizing PRIVATE IPs, and some could be utilizing overlapping ranges. One might look into applying for IP addresses for that non-connected network, then, to avoid conflicts with 10/8 172.16/12 and 192.168/16 addresses already in use. -- -J From cmettin at gqbc-online.com Sat Nov 28 21:44:34 2009 From: cmettin at gqbc-online.com (Christopher Mettin) Date: Sun, 29 Nov 2009 03:44:34 +0100 Subject: [arin-ppml] Continuation: Policy Change Request: IP Address Assignment to Educational and Non-Commercial Organizations In-Reply-To: <6eb799ab0911281822m69ca9b07x7b67ec3273c914c7@mail.gmail.com> References: <6eb799ab0911281822m69ca9b07x7b67ec3273c914c7@mail.gmail.com> Message-ID: ARIN Community, The ISP just doesn't corporate and we can't change it since the state pays the contract and it has been renewed for 2 years some months ago. Hamachi doesn't work for us, I've tried it. And isn't charging a fee for a service the same as selling a good? Both involve a thing and money traded. Sincerely yours, Christopher Mettin Gymnasium Querfurt High School -----Original Message----- From: James Hess [mailto:mysidia at gmail.com] Sent: Sunday, November 29, 2009 3:23 AM To: Christopher Mettin Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Continuation: Policy Change Request: IP Address Assignment to Educational and Non-Commercial Organizations On Sat, Nov 28, 2009 at 6:00 PM, Christopher Mettin wrote: > We just need maybe 2 or 3 blocks containing up to 255 hosts (of IP v4 > addresses). If you need blocks of global IP addresses, ask your upstream ISP for the blocks to be assigned to the networks first. ISPs receive blocks of IP addresses for the sole purpose of delegating to customer networks. Provided the customer network has a documented justifiable need for the amount of IPs. ARIN does not sell IP addresses. IP addresses are not for sale, although, there are fees involved in obtaining IPs from ARIN, the main criteria, is you first must have a justifiable need for the minimum sized block, that is You only go to ARIN if you need an allocation of least a /20 (4096 ips), or are multi-homed with 2 or more ISPs and need at least a /22 (1024 ips), and can get the documentation to show that you will meet the utilization criteria. This is all described in the Number Resources Policy Manual: https://www.arin.net/policy/nrpm.html If your ISP won't assign needed IPs to you, it might be time to switch ISPs or get a renegotiation of the contract with your ISP, including provisioning of IP addresses that you have documented need for. If the ISP is not willing to work with you to get the IPs you need... then what good is it to get IPs delegated from ARIN or from someone else? Only for your ISP to then tell you they aren't willing to announce the IP addresses for you, or to grant you a BGP feed for announcing the space. Unless an ISP of yours does extra work to provide the connectivity, you'll have no means to actually use those newly acquired IPs: it's not possible to simply assign one to your router and be done with it. Your ISP has to designate a static IP that your router can use. Your newly acquired IP block needs to get announced by some ISP connect to your sites, who is willing to forward traffic addressed to those IPs to your sites. > change every 24 hours. Static IP addresses allow us to allow a connection > establishment without allowing people other than our students to join. But > having dynamic IP addresses only, we are forced to allow access by the > entire ISP subnet which could mean a potential harm to our network. For such an application I would suggest utilizing PRIVATE IPs and a VPN application, for example you could subscribe to a service such as Hamachi (for example) to create connections between locations. Only allow users to "share" resources when connected to the VPN service. Or get your ISPs to provide each location at least 1 static IP for a VPN router: in that case, with a large number of schools, there is a good chance some would be already utilizing PRIVATE IPs, and some could be utilizing overlapping ranges. One might look into applying for IP addresses for that non-connected network, then, to avoid conflicts with 10/8 172.16/12 and 192.168/16 addresses already in use. -- -J From jay at impulse.net Sat Nov 28 21:39:27 2009 From: jay at impulse.net (Jay Hennigan) Date: Sat, 28 Nov 2009 18:39:27 -0800 Subject: [arin-ppml] Joe Baptista... In-Reply-To: References: Message-ID: <4B11DEDF.9080706@impulse.net> +-------------------+ | PLEASE DO NOT | | FEED THE TROLL | | | | Thank you, | | Management | +-------------------+ | | @@@ | | @@@ @x@@x@ | | |/ \||||/ | | \| \||/ | | | /\/\/\/\/\/\/\/\//\/\\/\/\/\/\/\/\/\ ==================================== -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From cmettin at gqbc-online.com Sat Nov 28 22:06:42 2009 From: cmettin at gqbc-online.com (Christopher Mettin) Date: Sun, 29 Nov 2009 04:06:42 +0100 Subject: [arin-ppml] Continuation: Policy Change Request: IP Address Assignment to Educational and Non-Commercial Organizations In-Reply-To: <81E5BCD2-9D5A-4622-85B8-2C8EB81A9AF9@gmail.com> References: <6eb799ab0911281822m69ca9b07x7b67ec3273c914c7@mail.gmail.com> <81E5BCD2-9D5A-4622-85B8-2C8EB81A9AF9@gmail.com> Message-ID: Thanks. We thought about using a tunnel, yeah. But it is easier to manage the network if we continue to use IPv4 addresses rather than changing to IPv6. Our ISP said they won't give us a static IP but I am not sure about BGP. We would check this and if they won't, we would try the tunnel way. It would be awesome if we had a few IP's already, so we could test all this. Thank you. Sincerely yours, Christopher Mettin -----Original Message----- From: Scott Leibrand [mailto:scottleibrand at gmail.com] Sent: Sunday, November 29, 2009 4:02 AM To: Christopher Mettin Subject: Re: [arin-ppml] Continuation: Policy Change Request: IP Address Assignment to Educational and Non-Commercial Organizations Will your ISP run BGP with you? If not, you can't route a netblock you get from ARIN or anyone else. If you can get a static IP from them, you could conceivably run a tunnel to someone else who'd run BGP with you. In fact, you can do that much easier with IPv6 than IPv4, as folks like HE.net will be happy to run a tunnel and route you a /48. Scott On Nov 28, 2009, at 6:44 PM, "Christopher Mettin" wrote: > ARIN Community, > > The ISP just doesn't corporate and we can't change it since the > state pays > the contract and it has been renewed for 2 years some months ago. > > Hamachi doesn't work for us, I've tried it. > > And isn't charging a fee for a service the same as selling a good? > Both > involve a thing and money traded. > > Sincerely yours, > Christopher Mettin > Gymnasium Querfurt High School > > -----Original Message----- > From: James Hess [mailto:mysidia at gmail.com] > Sent: Sunday, November 29, 2009 3:23 AM > To: Christopher Mettin > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Continuation: Policy Change Request: IP > Address > Assignment to Educational and Non-Commercial Organizations > > On Sat, Nov 28, 2009 at 6:00 PM, Christopher Mettin > wrote: >> We just need maybe 2 or 3 blocks containing up to 255 hosts (of IP v4 >> addresses). > > If you need blocks of global IP addresses, ask your upstream ISP for > the blocks to be assigned to the networks first. ISPs receive blocks > of IP addresses for the sole purpose of delegating to customer > networks. Provided the customer network has a documented justifiable > need for the amount of IPs. > > ARIN does not sell IP addresses. IP addresses are not for sale, > although, there are fees involved in obtaining IPs from ARIN, the > main criteria, is you first must have a justifiable need for the > minimum sized block, that is > > You only go to ARIN if you need an allocation of least a /20 (4096 > ips), or are multi-homed with 2 or more ISPs and need at least a /22 > (1024 ips), and can get the documentation to show that you will meet > the utilization criteria. > This is all described in the Number Resources Policy Manual: > https://www.arin.net/policy/nrpm.html > > > If your ISP won't assign needed IPs to you, it might be time to switch > ISPs or get a renegotiation of the contract with your ISP, including > provisioning of IP addresses that you have documented need for. > > If the ISP is not willing to work with you to get the IPs you need... > then what good is it to get IPs delegated from ARIN or from someone > else? > > Only for your ISP to then tell you they aren't willing to announce the > IP addresses for you, or to grant you a BGP feed for announcing > the space. > > Unless an ISP of yours does extra work to provide the connectivity, > you'll have no means to actually use those newly acquired IPs: it's > not possible to simply assign one to your router and be done with it. > > Your ISP has to designate a static IP that your router can use. > Your newly acquired IP block needs to get announced by some ISP > connect to your sites, who is willing to forward traffic addressed > to those IPs to your sites. > >> change every 24 hours. Static IP addresses allow us to allow a >> connection >> establishment without allowing people other than our students to >> join. But >> having dynamic IP addresses only, we are forced to allow access by >> the >> entire ISP subnet which could mean a potential harm to our network. > > For such an application I would suggest utilizing PRIVATE IPs and a > VPN application, for example you could subscribe to a service such as > Hamachi (for example) to create connections between locations. > > Only allow users to "share" resources when connected to the VPN > service. > > Or get your ISPs to provide each location at least 1 static IP for a > VPN router: > in that case, with a large number of schools, there is a good chance > some would be already utilizing PRIVATE IPs, and some could be > utilizing overlapping ranges. > > One might look into applying for IP addresses for that > non-connected network, then, to avoid conflicts with 10/8 > 172.16/12 and 192.168/16 addresses already in use. > > -- > -J > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From jcurran at arin.net Sun Nov 29 06:15:32 2009 From: jcurran at arin.net (John Curran) Date: Sun, 29 Nov 2009 06:15:32 -0500 Subject: [arin-ppml] ARIN AUP for the Public Policy Mailing List (PPML) Message-ID: <6E1E9B0B-0012-414D-B665-747CC8725600@arin.net> Folks - Please conduct discussions on PPML in accordance with the ARIN mailing list AUP . If you have not read the AUP recently, now it would be appropriate to take this opportunity to review it. Thank you, and Happy Holidays! /John John Curran President and CEO ARIN From cmettin at gqbc-online.com Sun Nov 29 07:53:26 2009 From: cmettin at gqbc-online.com (Christopher Mettin) Date: Sun, 29 Nov 2009 13:53:26 +0100 Subject: [arin-ppml] IP Address Fee Structure Policy and the Right of Education In-Reply-To: <4B120115.8080307@eml.cc> References: <4B120115.8080307@eml.cc> Message-ID: ARIN Community, Why does ARIN manage the IP addresses allocated to North America? Did they win a competition in cost-effeteness and reliability? And does ARIN show a proof that the fees cover at least 90% of their operating costs? If IANA would replace ARIN with GQHS today, I could offer everyone a /20 block for just $10 annually and no cent more. GQHS will also have less operation costs and that will save our environment a lot. I will propose this idea to IANA soon. Maybe "Virginian non-profit" actually means they just don't have any stocks but I bet they make a million revenue each year. At all, they are not the right organization to manage IP addresses it seems. Has anyone a problem with IP addresses given away for as cheap as a .com domain? Sincerely yours, Christopher -----Original Message----- From: Per Heldal [mailto:heldal at eml.cc] Sent: Sunday, November 29, 2009 6:05 AM To: Christopher Mettin Subject: Re: [arin-ppml] IP Address Fee Structure Policy and the Right of Education On 11/29/2009 02:16 AM, Christopher Mettin wrote: > The fact that one can't access the Internet without an IP address and that > ARIN sells them. RIR's don't sell IP-addresses. Addresses are assigned for a documented purpose. The RIRs are not-for-profit organisations. The fee is not for the IP-addresses themselves, but rather to cover the administrative costs of running the RIR-operations organization. >> My suggestion would be that you hit up your respective ISPs to give you >> static addresses at no extra charge for the good will and possible tax >> benefits. Even if they're only willing to give you /29s, you can >> harmonize your RFC1918 address space use and use VPNs that properly >> reflect your security policies. > > Yep, VPS, you cannot set them up so easily if you don't have a commonly > known (static) IP address of the end-point. Where should we send the VPS > connection request if our IP always changes? Maybe try out every host on the > entire ISP subnet? > > Our Internet connection is paid by the state. And under the current contract > we actually even not allowed to publish a simple website from our network. > So why should they give us a static IP to make it easier for us to do so? > You can not blame the internet-community for your organisation's failure to negotiate a contract that meets your needs. I doubt you'll find a serious SP anywhere that doesn't offer contracts that include static addressing. So far there's been no mention of a need for multi-homing which normally is the key requirement to justify direct assignments. What difference does the fee make if you don't qualify for an allocation in the first place. > So the reason why ARIN should change its policies is that we want ARIN to > allocate us some IP addresses which are the only way for us to solve our > little problem. You should resolve this with the people who are responsible for a service-contract that doesn't meet your functional requirements. //per From bmanning at vacation.karoshi.com Sun Nov 29 08:10:06 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sun, 29 Nov 2009 13:10:06 +0000 Subject: [arin-ppml] IP Address Fee Structure Policy and the Right of Education In-Reply-To: References: <4B120115.8080307@eml.cc> Message-ID: <20091129131006.GA7604@vacation.karoshi.com.> ARIN manages the IP space for its region based on the consent of its members and the governments in that region. ARINs finances are a matter of public record - you can find them on the ARIN web site. As for your proposal to replace ARIN with GQHS, I for one, would like to see the dialog between you/GQHS and the IANA as a matter of public record. If you would like to change the ARIN proceedures for address allocation and stewardship - the process is open and available to all. You just have to convince others to agree with you on your well thought out, viable alternative. Please ensure that you either cover all the things ARIN does or find other parties to take on those roles. Luck --bill On Sun, Nov 29, 2009 at 01:53:26PM +0100, Christopher Mettin wrote: > ARIN Community, > > Why does ARIN manage the IP addresses allocated to North America? Did they > win a competition in cost-effeteness and reliability? > > And does ARIN show a proof that the fees cover at least 90% of their > operating costs? > > If IANA would replace ARIN with GQHS today, I could offer everyone a /20 > block for just $10 annually and no cent more. GQHS will also have less > operation costs and that will save our environment a lot. > > I will propose this idea to IANA soon. Maybe "Virginian non-profit" actually > means they just don't have any stocks but I bet they make a million revenue > each year. At all, they are not the right organization to manage IP > addresses it seems. > > Has anyone a problem with IP addresses given away for as cheap as a .com > domain? > > Sincerely yours, > Christopher > > -----Original Message----- > From: Per Heldal [mailto:heldal at eml.cc] > Sent: Sunday, November 29, 2009 6:05 AM > To: Christopher Mettin > Subject: Re: [arin-ppml] IP Address Fee Structure Policy and the Right of > Education > > On 11/29/2009 02:16 AM, Christopher Mettin wrote: > > The fact that one can't access the Internet without an IP address and that > > ARIN sells them. > > RIR's don't sell IP-addresses. Addresses are assigned for a documented > purpose. The RIRs are not-for-profit organisations. The fee is not for > the IP-addresses themselves, but rather to cover the administrative > costs of running the RIR-operations organization. > > >> My suggestion would be that you hit up your respective ISPs to give you > >> static addresses at no extra charge for the good will and possible tax > >> benefits. Even if they're only willing to give you /29s, you can > >> harmonize your RFC1918 address space use and use VPNs that properly > >> reflect your security policies. > > > > Yep, VPS, you cannot set them up so easily if you don't have a commonly > > known (static) IP address of the end-point. Where should we send the VPS > > connection request if our IP always changes? Maybe try out every host on > the > > entire ISP subnet? > > > > Our Internet connection is paid by the state. And under the current > contract > > we actually even not allowed to publish a simple website from our network. > > So why should they give us a static IP to make it easier for us to do so? > > > > You can not blame the internet-community for your organisation's failure > to negotiate a contract that meets your needs. I doubt you'll find a > serious SP anywhere that doesn't offer contracts that include static > addressing. So far there's been no mention of a need for multi-homing > which normally is the key requirement to justify direct assignments. > What difference does the fee make if you don't qualify for an allocation > in the first place. > > > > So the reason why ARIN should change its policies is that we want ARIN to > > allocate us some IP addresses which are the only way for us to solve our > > little problem. > > You should resolve this with the people who are responsible for a > service-contract that doesn't meet your functional requirements. > > > //per > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From cmettin at gqbc-online.com Sun Nov 29 09:42:39 2009 From: cmettin at gqbc-online.com (Christopher Mettin) Date: Sun, 29 Nov 2009 15:42:39 +0100 Subject: [arin-ppml] IP Address Fee Structure Policy and the Right of Education References: <4B120115.8080307@eml.cc> <20091129131006.GA7604@vacation.karoshi.com.> Message-ID: ARIN Community, Why doesn't ARIN allocate GQHS a bunch of /20 addresses for the purpose of a quasi-ISP service and we assign /24 addresses to verified educational institutions for a much smaller fee? That would be a possible solution. It doesn't cause ARIN any costs and all fees would be directly and entirely submitted to ARIN. Also, In the end ARIN could maybe receive more from fees of several smaller sub allocations than from one larger allocation. Another preference is that there would be no address space fragmentation on the RIR level, GQHS would figure as a LIR except for the fact that ARIN fees would be sub delegated to charged by GQHS. I am looking forward to receive comments on this idea. Thank you. Sincerely yours, Christopher Mettin Gymnaium Querfurt High School -----Original Message----- From: bmanning at vacation.karoshi.com [mailto:bmanning at vacation.karoshi.com] Sent: Sunday, November 29, 2009 2:10 PM To: Christopher Mettin Cc: arin-ppml at arin.net; 'Per Heldal' Subject: Re: [arin-ppml] IP Address Fee Structure Policy and the Right of Education ARIN manages the IP space for its region based on the consent of its members and the governments in that region. ARINs finances are a matter of public record - you can find them on the ARIN web site. As for your proposal to replace ARIN with GQHS, I for one, would like to see the dialog between you/GQHS and the IANA as a matter of public record. If you would like to change the ARIN proceedures for address allocation and stewardship - the process is open and available to all. You just have to convince others to agree with you on your well thought out, viable alternative. Please ensure that you either cover all the things ARIN does or find other parties to take on those roles. Luck --bill On Sun, Nov 29, 2009 at 01:53:26PM +0100, Christopher Mettin wrote: > ARIN Community, > > Why does ARIN manage the IP addresses allocated to North America? Did they > win a competition in cost-effeteness and reliability? > > And does ARIN show a proof that the fees cover at least 90% of their > operating costs? > > If IANA would replace ARIN with GQHS today, I could offer everyone a /20 > block for just $10 annually and no cent more. GQHS will also have less > operation costs and that will save our environment a lot. > > I will propose this idea to IANA soon. Maybe "Virginian non-profit" actually > means they just don't have any stocks but I bet they make a million revenue > each year. At all, they are not the right organization to manage IP > addresses it seems. > > Has anyone a problem with IP addresses given away for as cheap as a .com > domain? > > Sincerely yours, > Christopher > > -----Original Message----- > From: Per Heldal [mailto:heldal at eml.cc] > Sent: Sunday, November 29, 2009 6:05 AM > To: Christopher Mettin > Subject: Re: [arin-ppml] IP Address Fee Structure Policy and the Right of > Education > > On 11/29/2009 02:16 AM, Christopher Mettin wrote: > > The fact that one can't access the Internet without an IP address and that > > ARIN sells them. > > RIR's don't sell IP-addresses. Addresses are assigned for a documented > purpose. The RIRs are not-for-profit organisations. The fee is not for > the IP-addresses themselves, but rather to cover the administrative > costs of running the RIR-operations organization. > > >> My suggestion would be that you hit up your respective ISPs to give you > >> static addresses at no extra charge for the good will and possible tax > >> benefits. Even if they're only willing to give you /29s, you can > >> harmonize your RFC1918 address space use and use VPNs that properly > >> reflect your security policies. > > > > Yep, VPS, you cannot set them up so easily if you don't have a commonly > > known (static) IP address of the end-point. Where should we send the VPS > > connection request if our IP always changes? Maybe try out every host on > the > > entire ISP subnet? > > > > Our Internet connection is paid by the state. And under the current > contract > > we actually even not allowed to publish a simple website from our network. > > So why should they give us a static IP to make it easier for us to do so? > > > > You can not blame the internet-community for your organisation's failure > to negotiate a contract that meets your needs. I doubt you'll find a > serious SP anywhere that doesn't offer contracts that include static > addressing. So far there's been no mention of a need for multi-homing > which normally is the key requirement to justify direct assignments. > What difference does the fee make if you don't qualify for an allocation > in the first place. > > > > So the reason why ARIN should change its policies is that we want ARIN to > > allocate us some IP addresses which are the only way for us to solve our > > little problem. > > You should resolve this with the people who are responsible for a > service-contract that doesn't meet your functional requirements. > > > //per > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From cmettin at gqbc-online.com Sun Nov 29 10:20:25 2009 From: cmettin at gqbc-online.com (Christopher Mettin) Date: Sun, 29 Nov 2009 16:20:25 +0100 Subject: [arin-ppml] IP Address Fee Structure Policy and the Right of Education References: <4B120115.8080307@eml.cc> <20091129131006.GA7604@vacation.karoshi.com.> <20091129150015.GB8343@vacation.karoshi.com.> Message-ID: ARIN Community, We haven't made a request yet. I was only registering a POC and an ORG ID yet. I still wait for the approval of the Org Id in order to request an address block. I will check the classes of assignment asap. Maybe I can find something useful. But I never heard or read about special treatments before. According to IANA there should be LIRs under each RIR. Originally I wanted to request addresses directly from IANA but they referred me to ARIN and gave me a link to a chart showing how IP allocation is managed. This chart showed a LIR on the lowest level assigning IP addresses to end users. But would there generally be a problem with my model of assigning IP addresses to educational institutions through GQHS as LIR? Thank you. Sincerely yours, Christopher Mettin Gymnasium Querfurt High School -----Original Message----- From: bmanning at vacation.karoshi.com [mailto:bmanning at vacation.karoshi.com] Sent: Sunday, November 29, 2009 4:00 PM To: Christopher Mettin Cc: bmanning at vacation.karoshi.com Subject: Re: [arin-ppml] IP Address Fee Structure Policy and the Right of Education has GQHS made application to ARIN for a (bunch) of /20 addresses, been able to justify the request and had the request denied? as to fee structures, there is a current proposal to treat some classes of assignments differently wrt fee structures. you might do a bit of homework on that proposal and see if it meets your needs. and last I checked, there was no concept of LIR in the ARIN region. YMMV of course. --bill On Sun, Nov 29, 2009 at 03:20:58PM +0100, Christopher Mettin wrote: > ARIN Community, > > Why doesn't ARIN allocate GQHS a bunch of /20 addresses for the purpose of a > quasi-ISP service and we assign /24 addresses to verified educational > institutions for a much smaller fee? > > That would be a possible solution. It doesn't cause ARIN any costs and all > fees would be directly and entirely submitted to ARIN. Also, In the end ARIN > could maybe receive more from fees of several smaller sub allocations than > from one larger allocation. > > Another preference is that there would be no address space fragmentation on > the RIR level, GQHS would figure as a LIR except for the fact that ARIN fees > would be sub delegated to charged by GQHS. > > I am looking forward to receive comments on this idea. > > Thank you. > > Sincerely yours, > Christopher Mettin > Gymnaium Querfurt High School > > -----Original Message----- > From: bmanning at vacation.karoshi.com [mailto:bmanning at vacation.karoshi.com] > Sent: Sunday, November 29, 2009 2:10 PM > To: Christopher Mettin > Cc: arin-ppml at arin.net; 'Per Heldal' > Subject: Re: [arin-ppml] IP Address Fee Structure Policy and the Right of > Education > > > ARIN manages the IP space for its region based on the consent of its > members and the governments in that region. > > ARINs finances are a matter of public record - you can find them on the > ARIN web site. > > As for your proposal to replace ARIN with GQHS, I for one, would like to > see the dialog between you/GQHS and the IANA as a matter of public record. > > If you would like to change the ARIN proceedures for address allocation and > stewardship - the process is open and available to all. You just have to > convince others to agree with you on your well thought out, viable > alternative. > > Please ensure that you either cover all the things ARIN does or find other > parties to take on those roles. > > > Luck > > > --bill > > > > On Sun, Nov 29, 2009 at 01:53:26PM +0100, Christopher Mettin wrote: > > ARIN Community, > > > > Why does ARIN manage the IP addresses allocated to North America? Did they > > win a competition in cost-effeteness and reliability? > > > > And does ARIN show a proof that the fees cover at least 90% of their > > operating costs? > > > > If IANA would replace ARIN with GQHS today, I could offer everyone a /20 > > block for just $10 annually and no cent more. GQHS will also have less > > operation costs and that will save our environment a lot. > > > > I will propose this idea to IANA soon. Maybe "Virginian non-profit" > actually > > means they just don't have any stocks but I bet they make a million > revenue > > each year. At all, they are not the right organization to manage IP > > addresses it seems. > > > > Has anyone a problem with IP addresses given away for as cheap as a .com > > domain? > > > > Sincerely yours, > > Christopher > > > > -----Original Message----- > > From: Per Heldal [mailto:heldal at eml.cc] > > Sent: Sunday, November 29, 2009 6:05 AM > > To: Christopher Mettin > > Subject: Re: [arin-ppml] IP Address Fee Structure Policy and the Right of > > Education > > > > On 11/29/2009 02:16 AM, Christopher Mettin wrote: > > > The fact that one can't access the Internet without an IP address and > that > > > ARIN sells them. > > > > RIR's don't sell IP-addresses. Addresses are assigned for a documented > > purpose. The RIRs are not-for-profit organisations. The fee is not for > > the IP-addresses themselves, but rather to cover the administrative > > costs of running the RIR-operations organization. > > > > >> My suggestion would be that you hit up your respective ISPs to give you > > >> static addresses at no extra charge for the good will and possible tax > > >> benefits. Even if they're only willing to give you /29s, you can > > >> harmonize your RFC1918 address space use and use VPNs that properly > > >> reflect your security policies. > > > > > > Yep, VPS, you cannot set them up so easily if you don't have a commonly > > > known (static) IP address of the end-point. Where should we send the VPS > > > connection request if our IP always changes? Maybe try out every host on > > the > > > entire ISP subnet? > > > > > > Our Internet connection is paid by the state. And under the current > > contract > > > we actually even not allowed to publish a simple website from our > network. > > > So why should they give us a static IP to make it easier for us to do > so? > > > > > > > You can not blame the internet-community for your organisation's failure > > to negotiate a contract that meets your needs. I doubt you'll find a > > serious SP anywhere that doesn't offer contracts that include static > > addressing. So far there's been no mention of a need for multi-homing > > which normally is the key requirement to justify direct assignments. > > What difference does the fee make if you don't qualify for an allocation > > in the first place. > > > > > > > So the reason why ARIN should change its policies is that we want ARIN > to > > > allocate us some IP addresses which are the only way for us to solve our > > > little problem. > > > > You should resolve this with the people who are responsible for a > > service-contract that doesn't meet your functional requirements. > > > > > > //per > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. From bill at herrin.us Sun Nov 29 12:19:59 2009 From: bill at herrin.us (William Herrin) Date: Sun, 29 Nov 2009 12:19:59 -0500 Subject: [arin-ppml] IP Address Fee Structure Policy and the Right of Education In-Reply-To: References: <4B120115.8080307@eml.cc> <20091129131006.GA7604@vacation.karoshi.com.> <20091129150015.GB8343@vacation.karoshi.com.> Message-ID: <3c3e3fca0911290919m67f38bbakcf74e85ed9e6d345@mail.gmail.com> On Sun, Nov 29, 2009 at 10:20 AM, Christopher Mettin wrote: > But would there generally be a problem with my model of assigning IP > addresses to educational institutions through GQHS as LIR? Chris, If your ARIN-region ISP won't give you static addresses now, they won't route the addresses you bring them either. There's a division of responsibility there that I'm not convinced you clearly understand. I respectfully suggest you work on getting accounts from those ISPs which support the use of static CIDR blocks and BGP before you continue your pursuit of IP addresses at ARIN. While there is nothing intrinsically wrong with GQHS operating as a LIR, in the ARIN region that more or less means ISP and much of the policy is written with the tacit understanding that LIR=ISP. I don't get the impression that GQHS is planning to build an international packet data network any time soon so you're probably not prepared to meet the networking and efficiency requirements that are built in to the allocation process. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From tvest at eyeconomics.com Sun Nov 29 12:49:49 2009 From: tvest at eyeconomics.com (tvest at eyeconomics.com) Date: Sun, 29 Nov 2009 12:49:49 -0500 Subject: [arin-ppml] IP Address Fee Structure Policy and the Right of Education In-Reply-To: References: <4B120115.8080307@eml.cc> <20091129131006.GA7604@vacation.karoshi.com.> Message-ID: Hi Christopher, Thanks for your very interesting questions. If GQHS provides a real (as opposed to a "quasi") ISP service within the ARIN region, then ARIN's normal IPv4 allocation process should be able to accommodate you just fine without any modification. Of course, GQHS's real ISP would still need to satisfy the same eligibility criteria for securing IPv4 addresses that all other current IPv4 seekers have to satisfy when they seek an allocation from ARIN. There are many reasons why ARIN doesn't give out IP number resources to anyone/everyone who simply asserts a problem, and asserts that only a free, no-strings-attached IPv4 distribution would solve that problem. Those reasons include, but are not limited to: -- the conservation of finite IP number resource pools, to extend their "useful lifetimes" (note that that's a two-dimensional challenge), because integrating a new addressing pool can be, um, both tricky and expensive; -- the preservation of private incentives to be conservative in imposing unilateral demands on finite and shared routing system carrying capacity, for the same reasons; -- the maintenance over time of a comprehensive database of identifying information about individual IP number resources, the contents of which both grows and changes over time. This is necessary to preserve the uniqueness of resources, which once again is a predicate for the usefulness of IP number resources over time. There are also many reasons why your assertion that ARIN could "allocate GQHS a bunch of /20 addresses for the purpose of a quasi-ISP service to assign /24 addresses to verified educational institutions," and that that wouldn't impose "any costs at all on ARIN" is quite mistaken: -- If GQHS does not provide a real ISP service, then GQHS has no *demonstrable* private incentive to redistribute IP addresses in a way that efficiently leverages the unique technical functionality which makes IP addresses useful. Given that, every IP address that ARIN (or any other xIR) provides to GQHS would ultimately deprive some real ISP of an IP address which, given the *demonstrated* investment in the inputs for delivering Internet services that a real ISP makes, would be more likely to be used to contribute to the real expansion of the real Internet. -- If GQHS does not provide a real ISP service, then it is a near certainty that whatever quantity of IP addresses that GQHS receives will ultimately impose the maximum possible burden on the Internet's shared routing infrastructure -- i.e., it will be de-aggregated to the maximum degree permitted by real routing services providers. Contrast this with the case of a real ISP, which practically speaking also has broad discretion to de-aggregate -- perhaps even to the max. possible level -- but which (unlike GQHS) demonstrably has some capex at risk if the routing system becomes unsustainable, and whose obligatory participation in the database of identifying information makes them subject to peer pressure (or perhaps to more muscular private/ bilateral responses, e.g., price hikes, depeering) if the demands that they impose on the shared routing infrastructure grow to excessive levels. -- If GQHS cannot assure the same level of participation in the comprehensive database of identifying information, then the allocation of any quantity of IP addresses to GQHS by ARIN or any other xIR would impose an equally large cost on all of the other users of the Internet, in perpetuity, in the form of diminished confidence that future accidental and/or intentional problems originating from or exacerbated by GQHS's address ranges could be resolved without recourse to lawsuits or worse (assuming that such remedies are even possible). To answer an earlier question of yours, the inetnum registration databases are very different from the .com/DNS registry -- in fact, it's fair to say that the current flexibility of DNS registrations is possible *only* because of the relative inflexibility (and hence, higher levels of accuracy/consistency) of the xIR registries. Over the years, many different address distribution ideas like yours, i.e., based on non-operational institutional hierarchies or other affinity relations, have been suggested. So far, none has offered a better mix of features for balancing the goals of industry openness, innovation, and growth with the goal to avoiding the premature obsolescence of current Internet technologies and investments. Perhaps you will be the one to do it -- and I hope that you will keep trying -- but you're not there yet. Regards, Tom Vest On Nov 29, 2009, at 9:42 AM, Christopher Mettin wrote: > ARIN Community, > > Why doesn't ARIN allocate GQHS a bunch of /20 addresses for the > purpose of a > quasi-ISP service and we assign /24 addresses to verified educational > institutions for a much smaller fee? > > That would be a possible solution. It doesn't cause ARIN any costs > and all > fees would be directly and entirely submitted to ARIN. Also, In the > end ARIN > could maybe receive more from fees of several smaller sub > allocations than > from one larger allocation. > > Another preference is that there would be no address space > fragmentation on > the RIR level, GQHS would figure as a LIR except for the fact that > ARIN fees > would be sub delegated to charged by GQHS. > > I am looking forward to receive comments on this idea. > > Thank you. > > Sincerely yours, > Christopher Mettin > Gymnaium Querfurt High School > > -----Original Message----- > From: bmanning at vacation.karoshi.com [mailto:bmanning at vacation.karoshi.com > ] > Sent: Sunday, November 29, 2009 2:10 PM > To: Christopher Mettin > Cc: arin-ppml at arin.net; 'Per Heldal' > Subject: Re: [arin-ppml] IP Address Fee Structure Policy and the > Right of > Education > > > ARIN manages the IP space for its region based on the consent of its > members and the governments in that region. > > ARINs finances are a matter of public record - you can find them on > the > ARIN web site. > > As for your proposal to replace ARIN with GQHS, I for one, would > like to > see the dialog between you/GQHS and the IANA as a matter of public > record. > > If you would like to change the ARIN proceedures for address > allocation and > stewardship - the process is open and available to all. You just > have to > convince others to agree with you on your well thought out, viable > alternative. > > Please ensure that you either cover all the things ARIN does or find > other > parties to take on those roles. > > > Luck > > > --bill > > > > On Sun, Nov 29, 2009 at 01:53:26PM +0100, Christopher Mettin wrote: >> ARIN Community, >> >> Why does ARIN manage the IP addresses allocated to North America? >> Did they >> win a competition in cost-effeteness and reliability? >> >> And does ARIN show a proof that the fees cover at least 90% of their >> operating costs? >> >> If IANA would replace ARIN with GQHS today, I could offer everyone >> a /20 >> block for just $10 annually and no cent more. GQHS will also have >> less >> operation costs and that will save our environment a lot. >> >> I will propose this idea to IANA soon. Maybe "Virginian non-profit" > actually >> means they just don't have any stocks but I bet they make a million > revenue >> each year. At all, they are not the right organization to manage IP >> addresses it seems. >> >> Has anyone a problem with IP addresses given away for as cheap as >> a .com >> domain? >> >> Sincerely yours, >> Christopher >> >> -----Original Message----- >> From: Per Heldal [mailto:heldal at eml.cc] >> Sent: Sunday, November 29, 2009 6:05 AM >> To: Christopher Mettin >> Subject: Re: [arin-ppml] IP Address Fee Structure Policy and the >> Right of >> Education >> >> On 11/29/2009 02:16 AM, Christopher Mettin wrote: >>> The fact that one can't access the Internet without an IP address >>> and > that >>> ARIN sells them. >> >> RIR's don't sell IP-addresses. Addresses are assigned for a >> documented >> purpose. The RIRs are not-for-profit organisations. The fee is not >> for >> the IP-addresses themselves, but rather to cover the administrative >> costs of running the RIR-operations organization. >> >>>> My suggestion would be that you hit up your respective ISPs to >>>> give you >>>> static addresses at no extra charge for the good will and >>>> possible tax >>>> benefits. Even if they're only willing to give you /29s, you can >>>> harmonize your RFC1918 address space use and use VPNs that properly >>>> reflect your security policies. >>> >>> Yep, VPS, you cannot set them up so easily if you don't have a >>> commonly >>> known (static) IP address of the end-point. Where should we send >>> the VPS >>> connection request if our IP always changes? Maybe try out every >>> host on >> the >>> entire ISP subnet? >>> >>> Our Internet connection is paid by the state. And under the current >> contract >>> we actually even not allowed to publish a simple website from our > network. >>> So why should they give us a static IP to make it easier for us to >>> do > so? >>> >> >> You can not blame the internet-community for your organisation's >> failure >> to negotiate a contract that meets your needs. I doubt you'll find a >> serious SP anywhere that doesn't offer contracts that include static >> addressing. So far there's been no mention of a need for multi-homing >> which normally is the key requirement to justify direct assignments. >> What difference does the fee make if you don't qualify for an >> allocation >> in the first place. >> >> >>> So the reason why ARIN should change its policies is that we want >>> ARIN > to >>> allocate us some IP addresses which are the only way for us to >>> solve our >>> little problem. >> >> You should resolve this with the people who are responsible for a >> service-contract that doesn't meet your functional requirements. >> >> >> //per >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From mueller at syr.edu Sun Nov 29 20:05:57 2009 From: mueller at syr.edu (Milton L Mueller) Date: Sun, 29 Nov 2009 20:05:57 -0500 Subject: [arin-ppml] IP Address Fee Structure Policy and the Right of Education In-Reply-To: References: <4B120115.8080307@eml.cc> Message-ID: <75822E125BCB994F8446858C4B19F0D793F44599@SUEX07-MBX-04.ad.syr.edu> > -----Original Message----- > > Why does ARIN manage the IP addresses allocated to North America? Did they > win a competition in cost-effeteness and reliability? ARIN is the product of a privatization of a U.S. government contractor by the National Science Foundation in 1997. http://128.150.4.107/news/news_summ.jsp?cntn_id=102819 > And does ARIN show a proof that the fees cover at least 90% of their > operating costs? ARIN's fees for address blocks reflect neither the economic value of the resources nor its actual costs in administering addresses. Instead, ARIN is run as a membership association for ASNs. However, when offered a cup of the "we don't charge for addresses" kool-aid, you really don't have to drink it. ARIN uses the size of address blocks as a rough proxy for the size of the member in order to tier the fees. It also uses address fees (crudely) as a policy instrument in other ways. The RIR fee policies are, let us put it charitably, in transition and a bit confused. > If IANA would replace ARIN with GQHS today, I could offer everyone a /20 > block for just $10 annually and no cent more. GQHS will also have less > operation costs and that will save our environment a lot. IANA - that is, ICANN - has no ability to "replace" ARIN. In theory, ICANN could allocate address blocks to someone else, or even assign them to users directly. That would constitute a rather revolutionary change in current Internet governance arrangements, however, so don't count on it happening any time soon. You're dealing with highly institutionalized relationships among a fairly settled group of actors. Whether there could be a competitive tendering of RIR functions is an idea worth considering (at least for us mischievous souls who enjoy both probing the intellectual limits of ARIN apologists and watching them labor to manufacture plausible rationalizations for the status quo). Truth be told, however, I doubt seriously if your organization could replace ARIN's functions at the scale and level of reliability required. In terms of "reliability" there are no obvious reasons to complain about any of the three main RIRs. > Has anyone a problem with IP addresses given away for as cheap as a .com > domain? I do, if you're talking IPv4 addresses. The scarcity value of an IPv4 address block vastly exceeds the market price of most available .com registrations. Keep in mind that some .com names have sold for millions of dollars based on their value and that an ordinary (good) .com name in the secondary market routinely goes for a few thousand dollars. --MM From dudepron at gmail.com Sun Nov 29 22:36:07 2009 From: dudepron at gmail.com (Aaron) Date: Sun, 29 Nov 2009 22:36:07 -0500 Subject: [arin-ppml] IP Address Fee Structure Policy and the Right of Education In-Reply-To: References: <4B120115.8080307@eml.cc> <20091129131006.GA7604@vacation.karoshi.com.> Message-ID: <480dad640911291936u401f406au1b14eeb082da1880@mail.gmail.com> Christopher, I may have missed this but I'm not sure why are you are coming to ARIN as GQHS is not located in an ARIN region but in RIPEs. Aaron On Sun, Nov 29, 2009 at 09:42, Christopher Mettin wrote: > ARIN Community, > > Why doesn't ARIN allocate GQHS a bunch of /20 addresses for the purpose of > a > quasi-ISP service and we assign /24 addresses to verified educational > institutions for a much smaller fee? > > That would be a possible solution. It doesn't cause ARIN any costs and all > fees would be directly and entirely submitted to ARIN. Also, In the end > ARIN > could maybe receive more from fees of several smaller sub allocations than > from one larger allocation. > > Another preference is that there would be no address space fragmentation on > the RIR level, GQHS would figure as a LIR except for the fact that ARIN > fees > would be sub delegated to charged by GQHS. > > I am looking forward to receive comments on this idea. > > Thank you. > > Sincerely yours, > Christopher Mettin > Gymnaium Querfurt High School > > -----Original Message----- > From: bmanning at vacation.karoshi.com [mailto:bmanning at vacation.karoshi.com] > Sent: Sunday, November 29, 2009 2:10 PM > To: Christopher Mettin > Cc: arin-ppml at arin.net; 'Per Heldal' > Subject: Re: [arin-ppml] IP Address Fee Structure Policy and the Right of > Education > > > ARIN manages the IP space for its region based on the consent of its > members and the governments in that region. > > ARINs finances are a matter of public record - you can find them on the > ARIN web site. > > As for your proposal to replace ARIN with GQHS, I for one, would like to > see the dialog between you/GQHS and the IANA as a matter of public record. > > If you would like to change the ARIN proceedures for address allocation and > stewardship - the process is open and available to all. You just have to > convince others to agree with you on your well thought out, viable > alternative. > > Please ensure that you either cover all the things ARIN does or find other > parties to take on those roles. > > > Luck > > > --bill > > > > On Sun, Nov 29, 2009 at 01:53:26PM +0100, Christopher Mettin wrote: > > ARIN Community, > > > > Why does ARIN manage the IP addresses allocated to North America? Did > they > > win a competition in cost-effeteness and reliability? > > > > And does ARIN show a proof that the fees cover at least 90% of their > > operating costs? > > > > If IANA would replace ARIN with GQHS today, I could offer everyone a /20 > > block for just $10 annually and no cent more. GQHS will also have less > > operation costs and that will save our environment a lot. > > > > I will propose this idea to IANA soon. Maybe "Virginian non-profit" > actually > > means they just don't have any stocks but I bet they make a million > revenue > > each year. At all, they are not the right organization to manage IP > > addresses it seems. > > > > Has anyone a problem with IP addresses given away for as cheap as a .com > > domain? > > > > Sincerely yours, > > Christopher > > > > -----Original Message----- > > From: Per Heldal [mailto:heldal at eml.cc] > > Sent: Sunday, November 29, 2009 6:05 AM > > To: Christopher Mettin > > Subject: Re: [arin-ppml] IP Address Fee Structure Policy and the Right of > > Education > > > > On 11/29/2009 02:16 AM, Christopher Mettin wrote: > > > The fact that one can't access the Internet without an IP address and > that > > > ARIN sells them. > > > > RIR's don't sell IP-addresses. Addresses are assigned for a documented > > purpose. The RIRs are not-for-profit organisations. The fee is not for > > the IP-addresses themselves, but rather to cover the administrative > > costs of running the RIR-operations organization. > > > > >> My suggestion would be that you hit up your respective ISPs to give > you > > >> static addresses at no extra charge for the good will and possible tax > > >> benefits. Even if they're only willing to give you /29s, you can > > >> harmonize your RFC1918 address space use and use VPNs that properly > > >> reflect your security policies. > > > > > > Yep, VPS, you cannot set them up so easily if you don't have a commonly > > > known (static) IP address of the end-point. Where should we send the > VPS > > > connection request if our IP always changes? Maybe try out every host > on > > the > > > entire ISP subnet? > > > > > > Our Internet connection is paid by the state. And under the current > > contract > > > we actually even not allowed to publish a simple website from our > network. > > > So why should they give us a static IP to make it easier for us to do > so? > > > > > > > You can not blame the internet-community for your organisation's failure > > to negotiate a contract that meets your needs. I doubt you'll find a > > serious SP anywhere that doesn't offer contracts that include static > > addressing. So far there's been no mention of a need for multi-homing > > which normally is the key requirement to justify direct assignments. > > What difference does the fee make if you don't qualify for an allocation > > in the first place. > > > > > > > So the reason why ARIN should change its policies is that we want ARIN > to > > > allocate us some IP addresses which are the only way for us to solve > our > > > little problem. > > > > You should resolve this with the people who are responsible for a > > service-contract that doesn't meet your functional requirements. > > > > > > //per > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.dillon at bt.com Mon Nov 30 05:02:50 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 30 Nov 2009 10:02:50 -0000 Subject: [arin-ppml] Policy Change Request: IP Address Assignment toEducational and Non-Commercial Organizations In-Reply-To: Message-ID: <28E139F46D45AF49A31950F88C497458044886B9@E03MVZ2-UKDY.domain1.systemhost.net> > To the American Regional IP Network Community, > > Don't you think that current ARIN fees exceeds the true value > of IP addresses? Sorry, but the fees that ARIN sets for its members are not public business, but are the business of ARIN and the members. There is a discussion list where members can discuss fees if they want to, but please note that members do vote on financial matters at the twice annual ARIN members meetings. > Christopher Mettin > Gymnasium Querfurt High School Your school is located in Sachsen-Anhalt, Germany, so it is unlikely that ARIN practices would have any effect on you. For the European equivalent of ARIN, see http://www.ripe.net --Michael Dillon From michael.dillon at bt.com Mon Nov 30 05:09:09 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 30 Nov 2009 10:09:09 -0000 Subject: [arin-ppml] Continuation: Policy Change Request: IP AddressAssignment to Educational and Non-Commercial Organizations In-Reply-To: Message-ID: <28E139F46D45AF49A31950F88C497458044886EB@E03MVZ2-UKDY.domain1.systemhost.net> > We have partner schools in several US states. We plan to > create a program allowing us to share classroom resources and > to communicate directly. > Unfortunately, our ISPs assign us dynamic IP addresses only > and thus they change every 24 hours. Solution 1. Go and explain to your ISP about the project and ask them to assign you a static IP address. Solution 2. Either rent a virtual server (VPS) with a static address or find one of the U.S. schools who have a static address. Then, on the network with dynamic addresses, configure a VPN tunnel to the site with a static address. Use this to maintain connectivity to only the machines which need to communicate with U.S. schools. Solution 3. Use DNS names for all communications. Find a dynamic DNS hosting service where you can register any changes in IP address so that the domain name will always point to your single server. If a firewall needs to be configured with IP addresses, then a script can poll the dynamic DNS server to detect when the IP address changes, and reconfigure the firewall. --Michael Dillon From michael.dillon at bt.com Mon Nov 30 05:20:49 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 30 Nov 2009 10:20:49 -0000 Subject: [arin-ppml] IP Address Fee Structure Policy and the Right ofEducation In-Reply-To: Message-ID: <28E139F46D45AF49A31950F88C4974580448874D@E03MVZ2-UKDY.domain1.systemhost.net> > If IANA would replace ARIN with GQHS today, I could offer > everyone a /20 block for just $10 annually and no cent more. > GQHS will also have less operation costs and that will save > our environment a lot. > > I will propose this idea to IANA soon. You should write your letter to ICANN soon if you want to be able to discuss it at the ICANN meeting in Brussels in June 2010. has more info. --Michael Dillon From cmettin at gqbc-online.com Mon Nov 30 09:03:15 2009 From: cmettin at gqbc-online.com (Christopher Mettin) Date: Mon, 30 Nov 2009 15:03:15 +0100 Subject: [arin-ppml] IP Address Fee Structure Policy and the Right of Education In-Reply-To: <480dad640911291936u401f406au1b14eeb082da1880@mail.gmail.com> References: <4B120115.8080307@eml.cc> <20091129131006.GA7604@vacation.karoshi.com.> <480dad640911291936u401f406au1b14eeb082da1880@mail.gmail.com> Message-ID: Dear Aaron, Well, I said that already. Two reasons: we are an American school and we decline to work with a Nazi organization like RIPE. We can't even get an IP from our ISP, because they always just say something like, "That's not part of our contract and this and that policy don't require us to give you one. And in Germany this is not the usual way, but what we do is spying your personal information and sell them to other companies or to the government if they think you void the censorship act." God bless America! We are so thankful here at GQHS that there is some place on the world with democracy and liberty besides all these dumb Germans around us. We are just right now about to define our request better with all your help before we are going to present it to ARIN. Thank you. Sincerely yours, Christopher From: Aaron [mailto:dudepron at gmail.com] Sent: Monday, November 30, 2009 4:36 AM To: Christopher Mettin Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] IP Address Fee Structure Policy and the Right of Education Christopher, I may have missed this but I'm not sure why are you are coming to ARIN as GQHS is not located in an ARIN region but in RIPEs. Aaron On Sun, Nov 29, 2009 at 09:42, Christopher Mettin wrote: ARIN Community, Why doesn't ARIN allocate GQHS a bunch of /20 addresses for the purpose of a quasi-ISP service and we assign /24 addresses to verified educational institutions for a much smaller fee? That would be a possible solution. It doesn't cause ARIN any costs and all fees would be directly and entirely submitted to ARIN. Also, In the end ARIN could maybe receive more from fees of several smaller sub allocations than from one larger allocation. Another preference is that there would be no address space fragmentation on the RIR level, GQHS would figure as a LIR except for the fact that ARIN fees would be sub delegated to charged by GQHS. I am looking forward to receive comments on this idea. Thank you. Sincerely yours, Christopher Mettin Gymnaium Querfurt High School -----Original Message----- From: bmanning at vacation.karoshi.com [mailto:bmanning at vacation.karoshi.com] Sent: Sunday, November 29, 2009 2:10 PM To: Christopher Mettin Cc: arin-ppml at arin.net; 'Per Heldal' Subject: Re: [arin-ppml] IP Address Fee Structure Policy and the Right of Education ARIN manages the IP space for its region based on the consent of its members and the governments in that region. ARINs finances are a matter of public record - you can find them on the ARIN web site. As for your proposal to replace ARIN with GQHS, I for one, would like to see the dialog between you/GQHS and the IANA as a matter of public record. If you would like to change the ARIN proceedures for address allocation and stewardship - the process is open and available to all. You just have to convince others to agree with you on your well thought out, viable alternative. Please ensure that you either cover all the things ARIN does or find other parties to take on those roles. Luck --bill On Sun, Nov 29, 2009 at 01:53:26PM +0100, Christopher Mettin wrote: > ARIN Community, > > Why does ARIN manage the IP addresses allocated to North America? Did they > win a competition in cost-effeteness and reliability? > > And does ARIN show a proof that the fees cover at least 90% of their > operating costs? > > If IANA would replace ARIN with GQHS today, I could offer everyone a /20 > block for just $10 annually and no cent more. GQHS will also have less > operation costs and that will save our environment a lot. > > I will propose this idea to IANA soon. Maybe "Virginian non-profit" actually > means they just don't have any stocks but I bet they make a million revenue > each year. At all, they are not the right organization to manage IP > addresses it seems. > > Has anyone a problem with IP addresses given away for as cheap as a .com > domain? > > Sincerely yours, > Christopher > > -----Original Message----- > From: Per Heldal [mailto:heldal at eml.cc] > Sent: Sunday, November 29, 2009 6:05 AM > To: Christopher Mettin > Subject: Re: [arin-ppml] IP Address Fee Structure Policy and the Right of > Education > > On 11/29/2009 02:16 AM, Christopher Mettin wrote: > > The fact that one can't access the Internet without an IP address and that > > ARIN sells them. > > RIR's don't sell IP-addresses. Addresses are assigned for a documented > purpose. The RIRs are not-for-profit organisations. The fee is not for > the IP-addresses themselves, but rather to cover the administrative > costs of running the RIR-operations organization. > > >> My suggestion would be that you hit up your respective ISPs to give you > >> static addresses at no extra charge for the good will and possible tax > >> benefits. Even if they're only willing to give you /29s, you can > >> harmonize your RFC1918 address space use and use VPNs that properly > >> reflect your security policies. > > > > Yep, VPS, you cannot set them up so easily if you don't have a commonly > > known (static) IP address of the end-point. Where should we send the VPS > > connection request if our IP always changes? Maybe try out every host on > the > > entire ISP subnet? > > > > Our Internet connection is paid by the state. And under the current > contract > > we actually even not allowed to publish a simple website from our network. > > So why should they give us a static IP to make it easier for us to do so? > > > > You can not blame the internet-community for your organisation's failure > to negotiate a contract that meets your needs. I doubt you'll find a > serious SP anywhere that doesn't offer contracts that include static > addressing. So far there's been no mention of a need for multi-homing > which normally is the key requirement to justify direct assignments. > What difference does the fee make if you don't qualify for an allocation > in the first place. > > > > So the reason why ARIN should change its policies is that we want ARIN to > > allocate us some IP addresses which are the only way for us to solve our > > little problem. > > You should resolve this with the people who are responsible for a > service-contract that doesn't meet your functional requirements. > > > //per > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rudi.daniel at gmail.com Mon Nov 30 09:29:41 2009 From: rudi.daniel at gmail.com (RudOlph Daniel) Date: Mon, 30 Nov 2009 09:29:41 -0500 Subject: [arin-ppml] ARIN-PPML Digest, Vol 53, Issue 43 In-Reply-To: References: Message-ID: <8aeeaff60911300629n3335acf3k878eba127763efb0@mail.gmail.com> Christopher That's a strong statement about RIPE, surely you would have guidance from their maillist? RD Well, I said that already. Two reasons: we are an American school and we > decline to work with a Nazi organization like RIPE. > > We can't even get an IP from our ISP, because they always just say > something > like, "That's not part of our contract and this and that policy don't > require us to give you one. And in Germany this is not the usual way, but > what we do is spying your personal information and sell them to other > companies or to the government if they think you void the censorship act." > > > > God bless America! We are so thankful here at GQHS that there is some place > on the world with democracy and liberty besides all these dumb Germans > around us. > > > > We are just right now about to define our request better with all your help > before we are going to present it to ARIN. > > > > Thank you. > > > > Sincerely yours, > > Christopher > > > > From: Aaron [mailto:dudepron at gmail.com] > Sent: Monday, November 30, 2009 4:36 AM > To: Christopher Mettin > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] IP Address Fee Structure Policy and the Right of > Education > > > > Christopher, > > I may have missed this but I'm not sure why are you are coming to ARIN as > GQHS is not located in an ARIN region but in RIPEs. > > Aaron > > > > On Sun, Nov 29, 2009 at 09:42, Christopher Mettin > > wrote: > > ARIN Community, > > Why doesn't ARIN allocate GQHS a bunch of /20 addresses for the purpose of > a > quasi-ISP service and we assign /24 addresses to verified educational > institutions for a much smaller fee? > > That would be a possible solution. It doesn't cause ARIN any costs and all > fees would be directly and entirely submitted to ARIN. Also, In the end > ARIN > could maybe receive more from fees of several smaller sub allocations than > from one larger allocation. > > Another preference is that there would be no address space fragmentation on > the RIR level, GQHS would figure as a LIR except for the fact that ARIN > fees > would be sub delegated to charged by GQHS. > > I am looking forward to receive comments on this idea. > > Thank you. > > Sincerely yours, > Christopher Mettin > Gymnaium Querfurt High School > > -----Original Message----- > From: bmanning at vacation.karoshi.com [mailto:bmanning at vacation.karoshi.com] > Sent: Sunday, November 29, 2009 2:10 PM > To: Christopher Mettin > Cc: arin-ppml at arin.net; 'Per Heldal' > Subject: Re: [arin-ppml] IP Address Fee Structure Policy and the Right of > Education > > > ARIN manages the IP space for its region based on the consent of its > members and the governments in that region. > > ARINs finances are a matter of public record - you can find them on the > ARIN web site. > > As for your proposal to replace ARIN with GQHS, I for one, would like to > see the dialog between you/GQHS and the IANA as a matter of public record. > > If you would like to change the ARIN proceedures for address allocation and > stewardship - the process is open and available to all. You just have to > convince others to agree with you on your well thought out, viable > alternative. > > Please ensure that you either cover all the things ARIN does or find other > parties to take on those roles. > > > Luck > > > --bill > > > > On Sun, Nov 29, 2009 at 01:53:26PM +0100, Christopher Mettin wrote: > > ARIN Community, > > > > Why does ARIN manage the IP addresses allocated to North America? Did > they > > win a competition in cost-effeteness and reliability? > > > > And does ARIN show a proof that the fees cover at least 90% of their > > operating costs? > > > > If IANA would replace ARIN with GQHS today, I could offer everyone a /20 > > block for just $10 annually and no cent more. GQHS will also have less > > operation costs and that will save our environment a lot. > > > > I will propose this idea to IANA soon. Maybe "Virginian non-profit" > actually > > means they just don't have any stocks but I bet they make a million > revenue > > each year. At all, they are not the right organization to manage IP > > addresses it seems. > > > > Has anyone a problem with IP addresses given away for as cheap as a .com > > domain? > > > > Sincerely yours, > > Christopher > > > > -----Original Message----- > > From: Per Heldal [mailto:heldal at eml.cc] > > Sent: Sunday, November 29, 2009 6:05 AM > > To: Christopher Mettin > > Subject: Re: [arin-ppml] IP Address Fee Structure Policy and the Right of > > Education > > > > On 11/29/2009 02:16 AM, Christopher Mettin wrote: > > > The fact that one can't access the Internet without an IP address and > that > > > ARIN sells them. > > > > RIR's don't sell IP-addresses. Addresses are assigned for a documented > > purpose. The RIRs are not-for-profit organisations. The fee is not for > > the IP-addresses themselves, but rather to cover the administrative > > costs of running the RIR-operations organization. > > > > >> My suggestion would be that you hit up your respective ISPs to give > you > > >> static addresses at no extra charge for the good will and possible tax > > >> benefits. Even if they're only willing to give you /29s, you can > > >> harmonize your RFC1918 address space use and use VPNs that properly > > >> reflect your security policies. > > > > > > Yep, VPS, you cannot set them up so easily if you don't have a commonly > > > known (static) IP address of the end-point. Where should we send the > VPS > > > connection request if our IP always changes? Maybe try out every host > on > > the > > > entire ISP subnet? > > > > > > Our Internet connection is paid by the state. And under the current > > contract > > > we actually even not allowed to publish a simple website from our > network. > > > So why should they give us a static IP to make it easier for us to do > so? > > > > > > > You can not blame the internet-community for your organisation's failure > > to negotiate a contract that meets your needs. I doubt you'll find a > > serious SP anywhere that doesn't offer contracts that include static > > addressing. So far there's been no mention of a need for multi-homing > > which normally is the key requirement to justify direct assignments. > > What difference does the fee make if you don't qualify for an allocation > > in the first place. > > > > > > > So the reason why ARIN should change its policies is that we want ARIN > to > > > allocate us some IP addresses which are the only way for us to solve > our > > > little problem. > > > > You should resolve this with the people who are responsible for a > > service-contract that doesn't meet your functional requirements. > > > > > > //per > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.arin.net/pipermail/arin-ppml/attachments/20091130/2ddcb812/attachment.html > > > > ------------------------------ > > _______________________________________________ > ARIN-PPML mailing list > ARIN-PPML at arin.net > http://lists.arin.net/mailman/listinfo/arin-ppml > > End of ARIN-PPML Digest, Vol 53, Issue 43 > ***************************************** > -- Rudi Daniel Independent Consultants http://www.svgpso.org http://danielcharles.weebly.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mysidia at gmail.com Mon Nov 30 09:45:55 2009 From: mysidia at gmail.com (James Hess) Date: Mon, 30 Nov 2009 08:45:55 -0600 Subject: [arin-ppml] IP Address Fee Structure Policy and the Right of Education In-Reply-To: <480dad640911291936u401f406au1b14eeb082da1880@mail.gmail.com> References: <4B120115.8080307@eml.cc> <20091129131006.GA7604@vacation.karoshi.com.> <480dad640911291936u401f406au1b14eeb082da1880@mail.gmail.com> Message-ID: <6eb799ab0911300645v10942b8bm8c71b398f2647e6a@mail.gmail.com> On Sun, Nov 29, 2009 at 9:36 PM, Aaron wrote: > Christopher, I may have missed this but I'm not sure why are you are coming to ARIN as > GQHS is not located in an ARIN region but in RIPEs. > Aaron ARIN number policy is not the place for grievances against RIPE. ARIN's fee-structure is not determined by IP address policy, anyways: policy policy proposals cannot change the fees, so this line of discussion is a waste of bits. You can plainly see here the proper list, for such matters: https://www.arin.net/participate/mailing_lists/index.html arin-discuss at arin.net "Provides a forum for the member community to discuss ARIN-specific issues such as fee structures and internal policies." If you want to discuss ARIN's fee structure, read up on the rationale behind the current fee structure, including public disclosures and archived discussions, and take it up on arin-discuss at . -- -J From bmanning at vacation.karoshi.com Mon Nov 30 09:52:10 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 30 Nov 2009 14:52:10 +0000 Subject: [arin-ppml] IP Address Fee Structure Policy and the Right of Education In-Reply-To: <6eb799ab0911300645v10942b8bm8c71b398f2647e6a@mail.gmail.com> References: <4B120115.8080307@eml.cc> <20091129131006.GA7604@vacation.karoshi.com.> <480dad640911291936u401f406au1b14eeb082da1880@mail.gmail.com> <6eb799ab0911300645v10942b8bm8c71b398f2647e6a@mail.gmail.com> Message-ID: <20091130145210.GA18946@vacation.karoshi.com.> On Mon, Nov 30, 2009 at 08:45:55AM -0600, James Hess wrote: > On Sun, Nov 29, 2009 at 9:36 PM, Aaron wrote: > > Christopher, I may have missed this but I'm not sure why are you are coming to ARIN as > > GQHS is not located in an ARIN region but in RIPEs. > Aaron > > ARIN number policy is not the place for grievances against RIPE. > > ARIN's fee-structure is not determined by IP address policy, > anyways: policy policy proposals cannot change the fees, so this > line of discussion is a waste of bits. > You can plainly see here the proper list, for such matters: > https://www.arin.net/participate/mailing_lists/index.html > > arin-discuss at arin.net > "Provides a forum for the member community to discuss ARIN-specific > issues such as fee structures and internal policies." > > If you want to discuss ARIN's fee structure, read up on the > rationale behind the current fee structure, including public > disclosures and archived discussions, and take it up on > arin-discuss at . > > -- > -J > _______________________________________________ I believe that Christopher is seeking a number of things including at least one policy change related to organizational identity. --bill From cmettin at gqbc-online.com Mon Nov 30 09:54:47 2009 From: cmettin at gqbc-online.com (Christopher Mettin) Date: Mon, 30 Nov 2009 15:54:47 +0100 Subject: [arin-ppml] IP Address Fee Structure Policy and the Right of Education In-Reply-To: <20091130145210.GA18946@vacation.karoshi.com.> References: <4B120115.8080307@eml.cc> <20091129131006.GA7604@vacation.karoshi.com.> <480dad640911291936u401f406au1b14eeb082da1880@mail.gmail.com> <6eb799ab0911300645v10942b8bm8c71b398f2647e6a@mail.gmail.com> <20091130145210.GA18946@vacation.karoshi.com.> Message-ID: Exactly, that is the point. Thank you, Bill. IANA told me this is the right list for the goal we aim on, getting an IP address from ARIN. If this mailing list would approve a policy change so that educational institutions are eligible for free IP address assignments, than there were no discussion on fees necessary anymore (except for surcharges, etc.). The policy change would have to define the term education institution/organization and then this should full-fill all the address assignment requirements for such a project GQHS is planning. Sincerely yours, Christopher Mettin Gymnasium Querfurt High School -----Original Message----- From: bmanning at vacation.karoshi.com [mailto:bmanning at vacation.karoshi.com] Sent: Monday, November 30, 2009 3:52 PM To: James Hess Cc: Aaron; Christopher Mettin; arin-ppml at arin.net Subject: Re: [arin-ppml] IP Address Fee Structure Policy and the Right of Education On Mon, Nov 30, 2009 at 08:45:55AM -0600, James Hess wrote: > On Sun, Nov 29, 2009 at 9:36 PM, Aaron wrote: > > Christopher, I may have missed this but I'm not sure why are you are coming to ARIN as > > GQHS is not located in an ARIN region but in RIPEs. > Aaron > > ARIN number policy is not the place for grievances against RIPE. > > ARIN's fee-structure is not determined by IP address policy, > anyways: policy policy proposals cannot change the fees, so this > line of discussion is a waste of bits. > You can plainly see here the proper list, for such matters: > https://www.arin.net/participate/mailing_lists/index.html > > arin-discuss at arin.net > "Provides a forum for the member community to discuss ARIN-specific > issues such as fee structures and internal policies." > > If you want to discuss ARIN's fee structure, read up on the > rationale behind the current fee structure, including public > disclosures and archived discussions, and take it up on > arin-discuss at . > > -- > -J > _______________________________________________ I believe that Christopher is seeking a number of things including at least one policy change related to organizational identity. --bill From cmettin at gqbc-online.com Mon Nov 30 10:35:47 2009 From: cmettin at gqbc-online.com (Christopher Mettin) Date: Mon, 30 Nov 2009 16:35:47 +0100 Subject: [arin-ppml] IP Address Fee Structure Policy and the Right of Education In-Reply-To: <20091130152243.GA19057@vacation.karoshi.com.> References: <4B120115.8080307@eml.cc> <20091129131006.GA7604@vacation.karoshi.com.> <75822E125BCB994F8446858C4B19F0D793F44598@SUEX07-MBX-04.ad.syr.edu> <20091130011749.GA11856@vacation.karoshi.com.> <20091130152243.GA19057@vacation.karoshi.com.> Message-ID: Our postal address is as follows: Gymnasium Querfurt High School An der Geispromenade 29 Querfurt, ST 06268 And an IP for example is 217.234.79.76, which is dynamically assigned by a German Service Provider. As far as I could figure it out, we get assignments in the range from 217.334.0.1 to 217.334.255.254. Why do you need that? Ah yeah, I am sorry if I have never told it in that way, legally the school is actually on American ground, we even have a Union flag with 51 stars in front of the school building. Any other questions? Sincerely yours, Christopher Mettin Gymnasium Querfurt High School -----Original Message----- From: bmanning at vacation.karoshi.com [mailto:bmanning at vacation.karoshi.com] Sent: Monday, November 30, 2009 4:23 PM To: Christopher Mettin Cc: bmanning at vacation.karoshi.com Subject: Re: [arin-ppml] IP Address Fee Structure Policy and the Right of Education the national science foundation is not under the department of defense. and actually, they did - due to agreement within the then Federal Networking Council - transfering responsiblity to the NSF from DoD. for further edification, may I ask a few questions? ) can you provide a postal address for Gymnasium Querfurt High School? ) what prefix(es) are you currently using? dynamic assignements from your ISP are fine. --bill On Mon, Nov 30, 2009 at 03:58:36PM +0100, Christopher Mettin wrote: > Is the NSF an agency under the Department of Defense? If not they had no > right to delegate ARIN control over IP address registrations. > And unfortunately I know what it means if a government organization approves > a plan of a commercial company -> lobbying. Not that lobbying would be > something bad, but sometimes it looks like not everyone was asked. > > Sincerely yours, > Christopher Mettin > Gymnasium Querfurt High School > > -----Original Message----- > From: bmanning at vacation.karoshi.com [mailto:bmanning at vacation.karoshi.com] > Sent: Monday, November 30, 2009 2:18 AM > To: Milton L Mueller > Cc: bmanning at vacation.karoshi.com; Christopher Mettin > Subject: Re: [arin-ppml] IP Address Fee Structure Policy and the Right of > Education > > > well - here is one... > > http://128.150.4.107/news/news_summ.jsp?cntn_id=102819 > > -----Original Message----- > From: bmanning at vacation.karoshi.com [mailto:bmanning at vacation.karoshi.com] > Sent: Monday, November 30, 2009 1:38 AM > To: Christopher Mettin > Cc: bmanning at vacation.karoshi.com > Subject: Re: [arin-ppml] IP Address Fee Structure Policy and the Right of > Education > > On Sun, Nov 29, 2009 at 04:09:25PM +0100, Christopher Mettin wrote: > > > > But would there generally be a problem with my model of assigning IP > > addresses to educational institutions through GQHS as LIR? > > > > Thank you. > > > > Sincerely yours, > > Christopher Mettin > > Gymnasium Querfurt High School > > > > don't really know. you'd have to ask ARIN. > and since this is the public policy list, not sure > that asking here is the same as asking ARIN. > > --bill > > On Sun, Nov 29, 2009 at 07:14:11PM -0500, Milton L Mueller wrote: > > Bill > > Would like to see any documents memorializing the "consent of the > governments of the region." > > > > > -----Original Message----- > > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > > > Behalf Of bmanning at vacation.karoshi.com > > > Sent: Sunday, November 29, 2009 8:10 AM > > > To: Christopher Mettin > > > Cc: arin-ppml at arin.net > > > Subject: Re: [arin-ppml] IP Address Fee Structure Policy and the Right > of > > > Education > > > > > > > > > ARIN manages the IP space for its region based on the consent of its > > > members and the governments in that region. > > > > > > ARINs finances are a matter of public record - you can find them on the > > > ARIN web site. > > > > > > As for your proposal to replace ARIN with GQHS, I for one, would like to > > > see the dialog between you/GQHS and the IANA as a matter of public > record. > > > > > > If you would like to change the ARIN proceedures for address allocation > > > and > > > stewardship - the process is open and available to all. You just have > to > > > convince others to agree with you on your well thought out, viable > > > alternative. > > > > > > Please ensure that you either cover all the things ARIN does or find > other > > > parties to take on those roles. > > > > > > > > > Luck > > > > > > > > > --bill > > > > > > > > > > > > On Sun, Nov 29, 2009 at 01:53:26PM +0100, Christopher Mettin wrote: > > > > ARIN Community, > > > > > > > > Why does ARIN manage the IP addresses allocated to North America? Did > > > they > > > > win a competition in cost-effeteness and reliability? > > > > > > > > And does ARIN show a proof that the fees cover at least 90% of their > > > > operating costs? > > > > > > > > If IANA would replace ARIN with GQHS today, I could offer everyone a > /20 > > > > block for just $10 annually and no cent more. GQHS will also have less > > > > operation costs and that will save our environment a lot. > > > > > > > > I will propose this idea to IANA soon. Maybe "Virginian non-profit" > > > actually > > > > means they just don't have any stocks but I bet they make a million > > > revenue > > > > each year. At all, they are not the right organization to manage IP > > > > addresses it seems. > > > > > > > > Has anyone a problem with IP addresses given away for as cheap as a > .com > > > > domain? > > > > > > > > Sincerely yours, > > > > Christopher > > > > > > > > -----Original Message----- > > > > From: Per Heldal [mailto:heldal at eml.cc] > > > > Sent: Sunday, November 29, 2009 6:05 AM > > > > To: Christopher Mettin > > > > Subject: Re: [arin-ppml] IP Address Fee Structure Policy and the Right > > > of > > > > Education > > > > > > > > On 11/29/2009 02:16 AM, Christopher Mettin wrote: > > > > > The fact that one can't access the Internet without an IP address > and > > > that > > > > > ARIN sells them. > > > > > > > > RIR's don't sell IP-addresses. Addresses are assigned for a documented > > > > purpose. The RIRs are not-for-profit organisations. The fee is not for > > > > the IP-addresses themselves, but rather to cover the administrative > > > > costs of running the RIR-operations organization. > > > > > > > > >> My suggestion would be that you hit up your respective ISPs to give > > > you > > > > >> static addresses at no extra charge for the good will and possible > > > tax > > > > >> benefits. Even if they're only willing to give you /29s, you can > > > > >> harmonize your RFC1918 address space use and use VPNs that properly > > > > >> reflect your security policies. > > > > > > > > > > Yep, VPS, you cannot set them up so easily if you don't have a > > > commonly > > > > > known (static) IP address of the end-point. Where should we send the > > > VPS > > > > > connection request if our IP always changes? Maybe try out every > host > > > on > > > > the > > > > > entire ISP subnet? > > > > > > > > > > Our Internet connection is paid by the state. And under the current > > > > contract > > > > > we actually even not allowed to publish a simple website from our > > > network. > > > > > So why should they give us a static IP to make it easier for us to > do > > > so? > > > > > > > > > > > > > You can not blame the internet-community for your organisation's > failure > > > > to negotiate a contract that meets your needs. I doubt you'll find a > > > > serious SP anywhere that doesn't offer contracts that include static > > > > addressing. So far there's been no mention of a need for multi-homing > > > > which normally is the key requirement to justify direct assignments. > > > > What difference does the fee make if you don't qualify for an > allocation > > > > in the first place. > > > > > > > > > > > > > So the reason why ARIN should change its policies is that we want > ARIN > > > to > > > > > allocate us some IP addresses which are the only way for us to solve > > > our > > > > > little problem. > > > > > > > > You should resolve this with the people who are responsible for a > > > > service-contract that doesn't meet your functional requirements. > > > > > > > > > > > > //per > > > > > > > > _______________________________________________ > > > > PPML > > > > You are receiving this message because you are subscribed to > > > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > > > Unsubscribe or manage your mailing list subscription at: > > > > http://lists.arin.net/mailman/listinfo/arin-ppml > > > > Please contact info at arin.net if you experience any issues. > > > _______________________________________________ > > > PPML > > > You are receiving this message because you are subscribed to > > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > > Unsubscribe or manage your mailing list subscription at: > > > http://lists.arin.net/mailman/listinfo/arin-ppml > > > Please contact info at arin.net if you experience any issues. From jay at impulse.net Mon Nov 30 10:43:13 2009 From: jay at impulse.net (Jay Hennigan) Date: Mon, 30 Nov 2009 07:43:13 -0800 Subject: [arin-ppml] IP Address Fee Structure Policy and the Right of Education In-Reply-To: References: <4B120115.8080307@eml.cc> <20091129131006.GA7604@vacation.karoshi.com.> <480dad640911291936u401f406au1b14eeb082da1880@mail.gmail.com> Message-ID: <4B13E811.2010003@impulse.net> Christopher Mettin wrote: > Well, I said that already. Two reasons: we are an American school and we > decline to work with a Nazi organization like RIPE. Well, _THAT_ took a little less time than I expected. Paging Mike Godwin, white courtesy phone please. Christopher, you didn't learn about Godwin's Law? No History of Usenet course in your high school? -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From bmanning at vacation.karoshi.com Mon Nov 30 10:43:50 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 30 Nov 2009 15:43:50 +0000 Subject: [arin-ppml] IP Address Fee Structure Policy and the Right of Education In-Reply-To: References: <4B120115.8080307@eml.cc> <20091129131006.GA7604@vacation.karoshi.com.> <75822E125BCB994F8446858C4B19F0D793F44598@SUEX07-MBX-04.ad.syr.edu> <20091130011749.GA11856@vacation.karoshi.com.> <20091130152243.GA19057@vacation.karoshi.com.> Message-ID: <20091130154350.GA19444@vacation.karoshi.com.> thanks. this clarifies (for me) a little more of your situation. --bill On Mon, Nov 30, 2009 at 04:35:47PM +0100, Christopher Mettin wrote: > Our postal address is as follows: > > Gymnasium Querfurt High School > An der Geispromenade 29 > Querfurt, ST 06268 > > And an IP for example is 217.234.79.76, which is dynamically assigned by a > German Service Provider. > > As far as I could figure it out, we get assignments in the range from > 217.334.0.1 to 217.334.255.254. > > Why do you need that? > > Ah yeah, I am sorry if I have never told it in that way, legally the school > is actually on American ground, we even have a Union flag with 51 stars in > front of the school building. > > Any other questions? > > Sincerely yours, > Christopher Mettin > Gymnasium Querfurt High School > > > -----Original Message----- > From: bmanning at vacation.karoshi.com [mailto:bmanning at vacation.karoshi.com] > Sent: Monday, November 30, 2009 4:23 PM > To: Christopher Mettin > Cc: bmanning at vacation.karoshi.com > Subject: Re: [arin-ppml] IP Address Fee Structure Policy and the Right of > Education > > the national science foundation is not under the department of defense. > and actually, they did - due to agreement within the then Federal > Networking > Council - transfering responsiblity to the NSF from DoD. > > for further edification, may I ask a few questions? > > ) can you provide a postal address for Gymnasium Querfurt High School? > ) what prefix(es) are you currently using? dynamic assignements from your > ISP are fine. > > --bill > > > On Mon, Nov 30, 2009 at 03:58:36PM +0100, Christopher Mettin wrote: > > Is the NSF an agency under the Department of Defense? If not they had no > > right to delegate ARIN control over IP address registrations. > > And unfortunately I know what it means if a government organization > approves > > a plan of a commercial company -> lobbying. Not that lobbying would be > > something bad, but sometimes it looks like not everyone was asked. > > > > Sincerely yours, > > Christopher Mettin > > Gymnasium Querfurt High School > > > > -----Original Message----- > > From: bmanning at vacation.karoshi.com [mailto:bmanning at vacation.karoshi.com] > > > Sent: Monday, November 30, 2009 2:18 AM > > To: Milton L Mueller > > Cc: bmanning at vacation.karoshi.com; Christopher Mettin > > Subject: Re: [arin-ppml] IP Address Fee Structure Policy and the Right of > > Education > > > > > > well - here is one... > > > > http://128.150.4.107/news/news_summ.jsp?cntn_id=102819 > > > > -----Original Message----- > > From: bmanning at vacation.karoshi.com [mailto:bmanning at vacation.karoshi.com] > > > Sent: Monday, November 30, 2009 1:38 AM > > To: Christopher Mettin > > Cc: bmanning at vacation.karoshi.com > > Subject: Re: [arin-ppml] IP Address Fee Structure Policy and the Right of > > Education > > > > On Sun, Nov 29, 2009 at 04:09:25PM +0100, Christopher Mettin wrote: > > > > > > But would there generally be a problem with my model of assigning IP > > > addresses to educational institutions through GQHS as LIR? > > > > > > Thank you. > > > > > > Sincerely yours, > > > Christopher Mettin > > > Gymnasium Querfurt High School > > > > > > > don't really know. you'd have to ask ARIN. > > and since this is the public policy list, not sure > > that asking here is the same as asking ARIN. > > > > --bill > > > > On Sun, Nov 29, 2009 at 07:14:11PM -0500, Milton L Mueller wrote: > > > Bill > > > Would like to see any documents memorializing the "consent of the > > governments of the region." > > > > > > > -----Original Message----- > > > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] > On > > > > Behalf Of bmanning at vacation.karoshi.com > > > > Sent: Sunday, November 29, 2009 8:10 AM > > > > To: Christopher Mettin > > > > Cc: arin-ppml at arin.net > > > > Subject: Re: [arin-ppml] IP Address Fee Structure Policy and the Right > > of > > > > Education > > > > > > > > > > > > ARIN manages the IP space for its region based on the consent of its > > > > members and the governments in that region. > > > > > > > > ARINs finances are a matter of public record - you can find them on > the > > > > ARIN web site. > > > > > > > > As for your proposal to replace ARIN with GQHS, I for one, would like > to > > > > see the dialog between you/GQHS and the IANA as a matter of public > > record. > > > > > > > > If you would like to change the ARIN proceedures for address > allocation > > > > and > > > > stewardship - the process is open and available to all. You just have > > to > > > > convince others to agree with you on your well thought out, viable > > > > alternative. > > > > > > > > Please ensure that you either cover all the things ARIN does or find > > other > > > > parties to take on those roles. > > > > > > > > > > > > Luck > > > > > > > > > > > > --bill > > > > > > > > > > > > > > > > On Sun, Nov 29, 2009 at 01:53:26PM +0100, Christopher Mettin wrote: > > > > > ARIN Community, > > > > > > > > > > Why does ARIN manage the IP addresses allocated to North America? > Did > > > > they > > > > > win a competition in cost-effeteness and reliability? > > > > > > > > > > And does ARIN show a proof that the fees cover at least 90% of their > > > > > operating costs? > > > > > > > > > > If IANA would replace ARIN with GQHS today, I could offer everyone a > > /20 > > > > > block for just $10 annually and no cent more. GQHS will also have > less > > > > > operation costs and that will save our environment a lot. > > > > > > > > > > I will propose this idea to IANA soon. Maybe "Virginian non-profit" > > > > actually > > > > > means they just don't have any stocks but I bet they make a million > > > > revenue > > > > > each year. At all, they are not the right organization to manage IP > > > > > addresses it seems. > > > > > > > > > > Has anyone a problem with IP addresses given away for as cheap as a > > .com > > > > > domain? > > > > > > > > > > Sincerely yours, > > > > > Christopher > > > > > > > > > > -----Original Message----- > > > > > From: Per Heldal [mailto:heldal at eml.cc] > > > > > Sent: Sunday, November 29, 2009 6:05 AM > > > > > To: Christopher Mettin > > > > > Subject: Re: [arin-ppml] IP Address Fee Structure Policy and the > Right > > > > of > > > > > Education > > > > > > > > > > On 11/29/2009 02:16 AM, Christopher Mettin wrote: > > > > > > The fact that one can't access the Internet without an IP address > > and > > > > that > > > > > > ARIN sells them. > > > > > > > > > > RIR's don't sell IP-addresses. Addresses are assigned for a > documented > > > > > purpose. The RIRs are not-for-profit organisations. The fee is not > for > > > > > the IP-addresses themselves, but rather to cover the administrative > > > > > costs of running the RIR-operations organization. > > > > > > > > > > >> My suggestion would be that you hit up your respective ISPs to > give > > > > you > > > > > >> static addresses at no extra charge for the good will and > possible > > > > tax > > > > > >> benefits. Even if they're only willing to give you /29s, you can > > > > > >> harmonize your RFC1918 address space use and use VPNs that > properly > > > > > >> reflect your security policies. > > > > > > > > > > > > Yep, VPS, you cannot set them up so easily if you don't have a > > > > commonly > > > > > > known (static) IP address of the end-point. Where should we send > the > > > > VPS > > > > > > connection request if our IP always changes? Maybe try out every > > host > > > > on > > > > > the > > > > > > entire ISP subnet? > > > > > > > > > > > > Our Internet connection is paid by the state. And under the > current > > > > > contract > > > > > > we actually even not allowed to publish a simple website from our > > > > network. > > > > > > So why should they give us a static IP to make it easier for us to > > do > > > > so? > > > > > > > > > > > > > > > > You can not blame the internet-community for your organisation's > > failure > > > > > to negotiate a contract that meets your needs. I doubt you'll find a > > > > > serious SP anywhere that doesn't offer contracts that include static > > > > > addressing. So far there's been no mention of a need for > multi-homing > > > > > which normally is the key requirement to justify direct assignments. > > > > > What difference does the fee make if you don't qualify for an > > allocation > > > > > in the first place. > > > > > > > > > > > > > > > > So the reason why ARIN should change its policies is that we want > > ARIN > > > > to > > > > > > allocate us some IP addresses which are the only way for us to > solve > > > > our > > > > > > little problem. > > > > > > > > > > You should resolve this with the people who are responsible for a > > > > > service-contract that doesn't meet your functional requirements. > > > > > > > > > > > > > > > //per > > > > > > > > > > _______________________________________________ > > > > > PPML > > > > > You are receiving this message because you are subscribed to > > > > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > > > > Unsubscribe or manage your mailing list subscription at: > > > > > http://lists.arin.net/mailman/listinfo/arin-ppml > > > > > Please contact info at arin.net if you experience any issues. > > > > _______________________________________________ > > > > PPML > > > > You are receiving this message because you are subscribed to > > > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > > > Unsubscribe or manage your mailing list subscription at: > > > > http://lists.arin.net/mailman/listinfo/arin-ppml > > > > Please contact info at arin.net if you experience any issues. From baptista at publicroot.org Mon Nov 30 10:49:02 2009 From: baptista at publicroot.org (Joe Baptista) Date: Mon, 30 Nov 2009 10:49:02 -0500 Subject: [arin-ppml] IP Address Fee Structure Policy and the Right of Education In-Reply-To: References: <4B120115.8080307@eml.cc> <20091129131006.GA7604@vacation.karoshi.com.> <75822E125BCB994F8446858C4B19F0D793F44598@SUEX07-MBX-04.ad.syr.edu> <20091130011749.GA11856@vacation.karoshi.com.> <20091130152243.GA19057@vacation.karoshi.com.> Message-ID: <874c02a20911300749x5ce5a37fk532a84ac024de69@mail.gmail.com> On Mon, Nov 30, 2009 at 10:35 AM, Christopher Mettin < cmettin at gqbc-online.com> wrote: > And an IP for example is 217.234.79.76, which is dynamically assigned by a > German Service Provider. > hmmm ... I don't see any school at that site. It looks more like a games board for kids. cheers joe baptista -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.dillon at bt.com Mon Nov 30 10:49:11 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 30 Nov 2009 15:49:11 -0000 Subject: [arin-ppml] IP Address Fee Structure Policy and the Right ofEducation In-Reply-To: Message-ID: <28E139F46D45AF49A31950F88C497458044FDDA4@E03MVZ2-UKDY.domain1.systemhost.net> > IANA told me this is the right list for the goal we aim on, > getting an IP address from ARIN. > If this mailing list would approve a policy change so that > educational institutions are eligible for free IP address > assignments, than there were no discussion on fees necessary > anymore (except for surcharges, etc.). The policy change > would have to define the term education > institution/organization and then this should full-fill all > the address assignment requirements for such a project GQHS > is planning. OK, let's start with this draft text for a policy change: ----- Change the NRPM section 6.5.1.1. Initial allocation criteria by adding a paragraph e as follows: e. or be a worthy educational institution as defined in section 6.4.5. And then let's add 6.4.5 as follows: 6.4.5 Worthy Educational Institions ARIN will provide IPv6 PI allocations at no charge to any educational institution at the secondary or post-secondary level, where the instition is located in the ARIN region or carrying out network projects with partners located in the ARIN region. Rationale: IP networking has been around long enough that it has worked its way into the educational system, and down the chain into secondary and primary institutions. Given that around age 14, humans are intellectualy capable of understanding the complexities of IP networking, the policy proposal suggests that we restrict this to not include primary schools. Some may worry that this will cause a huge influx of PI allocations into the default free zone, however I believe that the burdens of technical competence and technical understanding required to make use of a PI allocation, will limit uptake. Similarly, if a school does not have a project that could benefit from a PI allocation, it would be easier and cheaper to simply get a /48 from their upstream ISP. -------- OK, so that's some draft text that is not yet a formal proposal. I can already see some issues with it, like the and/or logic of paragraph e. and the fact that maybe it should go into the PI section of the policy. But it's a start. --Michael Dillon From jcurran at arin.net Mon Nov 30 10:51:29 2009 From: jcurran at arin.net (John Curran) Date: Mon, 30 Nov 2009 10:51:29 -0500 Subject: [arin-ppml] IP Address Fee Structure Policy and the Right of Education In-Reply-To: References: <4B120115.8080307@eml.cc> <20091129131006.GA7604@vacation.karoshi.com> <75822E125BCB994F8446858C4B19F0D793F44598@SUEX07-MBX-04.ad.syr.edu> <20091130011749.GA11856@vacation.karoshi.com> <20091130152243.GA19057@vacation.karoshi.com> Message-ID: On Nov 30, 2009, at 10:35 AM, Christopher Mettin wrote: > Our postal address is as follows: > > Gymnasium Querfurt High School > An der Geispromenade 29 > Querfurt, ST 06268 Chris - Anyone, regardless of location or membership is welcome to discuss policy changes on this mailing list in accordance with the mailing list AUP. It's a global Internet, and well-recognized that these policies have implications for everyone. I will note, however, that ARIN's role is the management of numbering resources within this region, and as such, no ARIN policy for number allocation will be applicable to GQHS. /John John Curran President and CEO ARIN From aaron at wholesaleinternet.net Mon Nov 30 11:03:42 2009 From: aaron at wholesaleinternet.net (aaron at wholesaleinternet.net) Date: Mon, 30 Nov 2009 16:03:42 +0000 Subject: [arin-ppml] IP Address Fee Structure Policy and the Right ofEducation In-Reply-To: References: <4B120115.8080307@eml.cc><20091129131006.GA7604@vacation.karoshi.com.><75822E125BCB994F8446858C4B19F0D793F44598@SUEX07-MBX-04.ad.syr.edu><20091130011749.GA11856@vacation.karoshi.com.><20091130152243.GA19057@vacation.karoshi.com.> Message-ID: <469008208-1259596522-cardhu_decombobulator_blackberry.rim.net-740346393-@bda560.bisx.prod.on.blackberry> Now I'm curious as to why that flag has 51 stars. Sent from my Verizon Wireless BlackBerry -----Original Message----- From: "Christopher Mettin" Date: Mon, 30 Nov 2009 16:35:47 To: ; Subject: Re: [arin-ppml] IP Address Fee Structure Policy and the Right of Education Our postal address is as follows: Gymnasium Querfurt High School An der Geispromenade 29 Querfurt, ST 06268 And an IP for example is 217.234.79.76, which is dynamically assigned by a German Service Provider. As far as I could figure it out, we get assignments in the range from 217.334.0.1 to 217.334.255.254. Why do you need that? Ah yeah, I am sorry if I have never told it in that way, legally the school is actually on American ground, we even have a Union flag with 51 stars in front of the school building. Any other questions? Sincerely yours, Christopher Mettin Gymnasium Querfurt High School -----Original Message----- From: bmanning at vacation.karoshi.com [mailto:bmanning at vacation.karoshi.com] Sent: Monday, November 30, 2009 4:23 PM To: Christopher Mettin Cc: bmanning at vacation.karoshi.com Subject: Re: [arin-ppml] IP Address Fee Structure Policy and the Right of Education the national science foundation is not under the department of defense. and actually, they did - due to agreement within the then Federal Networking Council - transfering responsiblity to the NSF from DoD. for further edification, may I ask a few questions? ) can you provide a postal address for Gymnasium Querfurt High School? ) what prefix(es) are you currently using? dynamic assignements from your ISP are fine. --bill On Mon, Nov 30, 2009 at 03:58:36PM +0100, Christopher Mettin wrote: > Is the NSF an agency under the Department of Defense? If not they had no > right to delegate ARIN control over IP address registrations. > And unfortunately I know what it means if a government organization approves > a plan of a commercial company -> lobbying. Not that lobbying would be > something bad, but sometimes it looks like not everyone was asked. > > Sincerely yours, > Christopher Mettin > Gymnasium Querfurt High School > > -----Original Message----- > From: bmanning at vacation.karoshi.com [mailto:bmanning at vacation.karoshi.com] > Sent: Monday, November 30, 2009 2:18 AM > To: Milton L Mueller > Cc: bmanning at vacation.karoshi.com; Christopher Mettin > Subject: Re: [arin-ppml] IP Address Fee Structure Policy and the Right of > Education > > > well - here is one... > > http://128.150.4.107/news/news_summ.jsp?cntn_id=102819 > > -----Original Message----- > From: bmanning at vacation.karoshi.com [mailto:bmanning at vacation.karoshi.com] > Sent: Monday, November 30, 2009 1:38 AM > To: Christopher Mettin > Cc: bmanning at vacation.karoshi.com > Subject: Re: [arin-ppml] IP Address Fee Structure Policy and the Right of > Education > > On Sun, Nov 29, 2009 at 04:09:25PM +0100, Christopher Mettin wrote: > > > > But would there generally be a problem with my model of assigning IP > > addresses to educational institutions through GQHS as LIR? > > > > Thank you. > > > > Sincerely yours, > > Christopher Mettin > > Gymnasium Querfurt High School > > > > don't really know. you'd have to ask ARIN. > and since this is the public policy list, not sure > that asking here is the same as asking ARIN. > > --bill > > On Sun, Nov 29, 2009 at 07:14:11PM -0500, Milton L Mueller wrote: > > Bill > > Would like to see any documents memorializing the "consent of the > governments of the region." > > > > > -----Original Message----- > > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > > > Behalf Of bmanning at vacation.karoshi.com > > > Sent: Sunday, November 29, 2009 8:10 AM > > > To: Christopher Mettin > > > Cc: arin-ppml at arin.net > > > Subject: Re: [arin-ppml] IP Address Fee Structure Policy and the Right > of > > > Education > > > > > > > > > ARIN manages the IP space for its region based on the consent of its > > > members and the governments in that region. > > > > > > ARINs finances are a matter of public record - you can find them on the > > > ARIN web site. > > > > > > As for your proposal to replace ARIN with GQHS, I for one, would like to > > > see the dialog between you/GQHS and the IANA as a matter of public > record. > > > > > > If you would like to change the ARIN proceedures for address allocation > > > and > > > stewardship - the process is open and available to all. You just have > to > > > convince others to agree with you on your well thought out, viable > > > alternative. > > > > > > Please ensure that you either cover all the things ARIN does or find > other > > > parties to take on those roles. > > > > > > > > > Luck > > > > > > > > > --bill > > > > > > > > > > > > On Sun, Nov 29, 2009 at 01:53:26PM +0100, Christopher Mettin wrote: > > > > ARIN Community, > > > > > > > > Why does ARIN manage the IP addresses allocated to North America? Did > > > they > > > > win a competition in cost-effeteness and reliability? > > > > > > > > And does ARIN show a proof that the fees cover at least 90% of their > > > > operating costs? > > > > > > > > If IANA would replace ARIN with GQHS today, I could offer everyone a > /20 > > > > block for just $10 annually and no cent more. GQHS will also have less > > > > operation costs and that will save our environment a lot. > > > > > > > > I will propose this idea to IANA soon. Maybe "Virginian non-profit" > > > actually > > > > means they just don't have any stocks but I bet they make a million > > > revenue > > > > each year. At all, they are not the right organization to manage IP > > > > addresses it seems. > > > > > > > > Has anyone a problem with IP addresses given away for as cheap as a > .com > > > > domain? > > > > > > > > Sincerely yours, > > > > Christopher > > > > > > > > -----Original Message----- > > > > From: Per Heldal [mailto:heldal at eml.cc] > > > > Sent: Sunday, November 29, 2009 6:05 AM > > > > To: Christopher Mettin > > > > Subject: Re: [arin-ppml] IP Address Fee Structure Policy and the Right > > > of > > > > Education > > > > > > > > On 11/29/2009 02:16 AM, Christopher Mettin wrote: > > > > > The fact that one can't access the Internet without an IP address > and > > > that > > > > > ARIN sells them. > > > > > > > > RIR's don't sell IP-addresses. Addresses are assigned for a documented > > > > purpose. The RIRs are not-for-profit organisations. The fee is not for > > > > the IP-addresses themselves, but rather to cover the administrative > > > > costs of running the RIR-operations organization. > > > > > > > > >> My suggestion would be that you hit up your respective ISPs to give > > > you > > > > >> static addresses at no extra charge for the good will and possible > > > tax > > > > >> benefits. Even if they're only willing to give you /29s, you can > > > > >> harmonize your RFC1918 address space use and use VPNs that properly > > > > >> reflect your security policies. > > > > > > > > > > Yep, VPS, you cannot set them up so easily if you don't have a > > > commonly > > > > > known (static) IP address of the end-point. Where should we send the > > > VPS > > > > > connection request if our IP always changes? Maybe try out every > host > > > on > > > > the > > > > > entire ISP subnet? > > > > > > > > > > Our Internet connection is paid by the state. And under the current > > > > contract > > > > > we actually even not allowed to publish a simple website from our > > > network. > > > > > So why should they give us a static IP to make it easier for us to > do > > > so? > > > > > > > > > > > > > You can not blame the internet-community for your organisation's > failure > > > > to negotiate a contract that meets your needs. I doubt you'll find a > > > > serious SP anywhere that doesn't offer contracts that include static > > > > addressing. So far there's been no mention of a need for multi-homing > > > > which normally is the key requirement to justify direct assignments. > > > > What difference does the fee make if you don't qualify for an > allocation > > > > in the first place. > > > > > > > > > > > > > So the reason why ARIN should change its policies is that we want > ARIN > > > to > > > > > allocate us some IP addresses which are the only way for us to solve > > > our > > > > > little problem. > > > > > > > > You should resolve this with the people who are responsible for a > > > > service-contract that doesn't meet your functional requirements. > > > > > > > > > > > > //per > > > > > > > > _______________________________________________ > > > > PPML > > > > You are receiving this message because you are subscribed to > > > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > > > Unsubscribe or manage your mailing list subscription at: > > > > http://lists.arin.net/mailman/listinfo/arin-ppml > > > > Please contact info at arin.net if you experience any issues. > > > _______________________________________________ > > > PPML > > > You are receiving this message because you are subscribed to > > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > > Unsubscribe or manage your mailing list subscription at: > > > http://lists.arin.net/mailman/listinfo/arin-ppml > > > Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From michael.dillon at bt.com Mon Nov 30 10:56:26 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 30 Nov 2009 15:56:26 -0000 Subject: [arin-ppml] IP Address Fee Structure Policy and the Right ofEducation In-Reply-To: Message-ID: <28E139F46D45AF49A31950F88C497458044FDDCC@E03MVZ2-UKDY.domain1.systemhost.net> > Our postal address is as follows: > > Gymnasium Querfurt High School > An der Geispromenade 29 > Querfurt, ST 06268 Wrong. You forgot the bottom line which should say either GERMANY or DEUTSCHLAND or DE There is not state code ST in the USA and the zip code 06268 goes to Storrs, Connecticut, not Querfurt. > Ah yeah, I am sorry if I have never told it in that way, > legally the school is actually on American ground, we even > have a Union flag with 51 stars in front of the school building. Clearly the Union that you refer to is not the United States of America which has 50 stars on its flag http://en.wikipedia.org/wiki/Flag_of_the_United_States --Michael Dillon From cmettin at gqbc-online.com Mon Nov 30 10:56:35 2009 From: cmettin at gqbc-online.com (Christopher Mettin) Date: Mon, 30 Nov 2009 16:56:35 +0100 Subject: [arin-ppml] IP Address Fee Structure Policy and the Right ofEducation In-Reply-To: <469008208-1259596522-cardhu_decombobulator_blackberry.rim.net-740346393-@bda560.bisx.prod.on.blackberry> References: <4B120115.8080307@eml.cc><20091129131006.GA7604@vacation.karoshi.com.><75822E125BCB994F8446858C4B19F0D793F44598@SUEX07-MBX-04.ad.syr.edu><20091130011749.GA11856@vacation.karoshi.com.><20091130152243.GA19057@vacation.karoshi.com.> <469008208-1259596522-cardhu_decombobulator_blackberry.rim.net-740346393-@bda560.bisx.prod.on.blackberry> Message-ID: The flag has 51 stars since the 50 stars as of 1959 plus the state of Sachsen-Anhalt make up 51 stars on the US flag. The design was adopted as proposed by the Department of Defense. Sincerely yours, Christopher Mettin Gymnasium Querfurt High School -----Original Message----- From: aaron at wholesaleinternet.net [mailto:aaron at wholesaleinternet.net] Sent: Monday, November 30, 2009 5:04 PM To: Christopher Mettin; arin-ppml at arin.net Subject: Re: [arin-ppml] IP Address Fee Structure Policy and the Right ofEducation Now I'm curious as to why that flag has 51 stars. Sent from my Verizon Wireless BlackBerry -----Original Message----- From: "Christopher Mettin" Date: Mon, 30 Nov 2009 16:35:47 To: ; Subject: Re: [arin-ppml] IP Address Fee Structure Policy and the Right of Education Our postal address is as follows: Gymnasium Querfurt High School An der Geispromenade 29 Querfurt, ST 06268 And an IP for example is 217.234.79.76, which is dynamically assigned by a German Service Provider. As far as I could figure it out, we get assignments in the range from 217.334.0.1 to 217.334.255.254. Why do you need that? Ah yeah, I am sorry if I have never told it in that way, legally the school is actually on American ground, we even have a Union flag with 51 stars in front of the school building. Any other questions? Sincerely yours, Christopher Mettin Gymnasium Querfurt High School -----Original Message----- From: bmanning at vacation.karoshi.com [mailto:bmanning at vacation.karoshi.com] Sent: Monday, November 30, 2009 4:23 PM To: Christopher Mettin Cc: bmanning at vacation.karoshi.com Subject: Re: [arin-ppml] IP Address Fee Structure Policy and the Right of Education the national science foundation is not under the department of defense. and actually, they did - due to agreement within the then Federal Networking Council - transfering responsiblity to the NSF from DoD. for further edification, may I ask a few questions? ) can you provide a postal address for Gymnasium Querfurt High School? ) what prefix(es) are you currently using? dynamic assignements from your ISP are fine. --bill On Mon, Nov 30, 2009 at 03:58:36PM +0100, Christopher Mettin wrote: > Is the NSF an agency under the Department of Defense? If not they had no > right to delegate ARIN control over IP address registrations. > And unfortunately I know what it means if a government organization approves > a plan of a commercial company -> lobbying. Not that lobbying would be > something bad, but sometimes it looks like not everyone was asked. > > Sincerely yours, > Christopher Mettin > Gymnasium Querfurt High School > > -----Original Message----- > From: bmanning at vacation.karoshi.com [mailto:bmanning at vacation.karoshi.com] > Sent: Monday, November 30, 2009 2:18 AM > To: Milton L Mueller > Cc: bmanning at vacation.karoshi.com; Christopher Mettin > Subject: Re: [arin-ppml] IP Address Fee Structure Policy and the Right of > Education > > > well - here is one... > > http://128.150.4.107/news/news_summ.jsp?cntn_id=102819 > > -----Original Message----- > From: bmanning at vacation.karoshi.com [mailto:bmanning at vacation.karoshi.com] > Sent: Monday, November 30, 2009 1:38 AM > To: Christopher Mettin > Cc: bmanning at vacation.karoshi.com > Subject: Re: [arin-ppml] IP Address Fee Structure Policy and the Right of > Education > > On Sun, Nov 29, 2009 at 04:09:25PM +0100, Christopher Mettin wrote: > > > > But would there generally be a problem with my model of assigning IP > > addresses to educational institutions through GQHS as LIR? > > > > Thank you. > > > > Sincerely yours, > > Christopher Mettin > > Gymnasium Querfurt High School > > > > don't really know. you'd have to ask ARIN. > and since this is the public policy list, not sure > that asking here is the same as asking ARIN. > > --bill > > On Sun, Nov 29, 2009 at 07:14:11PM -0500, Milton L Mueller wrote: > > Bill > > Would like to see any documents memorializing the "consent of the > governments of the region." > > > > > -----Original Message----- > > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > > > Behalf Of bmanning at vacation.karoshi.com > > > Sent: Sunday, November 29, 2009 8:10 AM > > > To: Christopher Mettin > > > Cc: arin-ppml at arin.net > > > Subject: Re: [arin-ppml] IP Address Fee Structure Policy and the Right > of > > > Education > > > > > > > > > ARIN manages the IP space for its region based on the consent of its > > > members and the governments in that region. > > > > > > ARINs finances are a matter of public record - you can find them on the > > > ARIN web site. > > > > > > As for your proposal to replace ARIN with GQHS, I for one, would like to > > > see the dialog between you/GQHS and the IANA as a matter of public > record. > > > > > > If you would like to change the ARIN proceedures for address allocation > > > and > > > stewardship - the process is open and available to all. You just have > to > > > convince others to agree with you on your well thought out, viable > > > alternative. > > > > > > Please ensure that you either cover all the things ARIN does or find > other > > > parties to take on those roles. > > > > > > > > > Luck > > > > > > > > > --bill > > > > > > > > > > > > On Sun, Nov 29, 2009 at 01:53:26PM +0100, Christopher Mettin wrote: > > > > ARIN Community, > > > > > > > > Why does ARIN manage the IP addresses allocated to North America? Did > > > they > > > > win a competition in cost-effeteness and reliability? > > > > > > > > And does ARIN show a proof that the fees cover at least 90% of their > > > > operating costs? > > > > > > > > If IANA would replace ARIN with GQHS today, I could offer everyone a > /20 > > > > block for just $10 annually and no cent more. GQHS will also have less > > > > operation costs and that will save our environment a lot. > > > > > > > > I will propose this idea to IANA soon. Maybe "Virginian non-profit" > > > actually > > > > means they just don't have any stocks but I bet they make a million > > > revenue > > > > each year. At all, they are not the right organization to manage IP > > > > addresses it seems. > > > > > > > > Has anyone a problem with IP addresses given away for as cheap as a > .com > > > > domain? > > > > > > > > Sincerely yours, > > > > Christopher > > > > > > > > -----Original Message----- > > > > From: Per Heldal [mailto:heldal at eml.cc] > > > > Sent: Sunday, November 29, 2009 6:05 AM > > > > To: Christopher Mettin > > > > Subject: Re: [arin-ppml] IP Address Fee Structure Policy and the Right > > > of > > > > Education > > > > > > > > On 11/29/2009 02:16 AM, Christopher Mettin wrote: > > > > > The fact that one can't access the Internet without an IP address > and > > > that > > > > > ARIN sells them. > > > > > > > > RIR's don't sell IP-addresses. Addresses are assigned for a documented > > > > purpose. The RIRs are not-for-profit organisations. The fee is not for > > > > the IP-addresses themselves, but rather to cover the administrative > > > > costs of running the RIR-operations organization. > > > > > > > > >> My suggestion would be that you hit up your respective ISPs to give > > > you > > > > >> static addresses at no extra charge for the good will and possible > > > tax > > > > >> benefits. Even if they're only willing to give you /29s, you can > > > > >> harmonize your RFC1918 address space use and use VPNs that properly > > > > >> reflect your security policies. > > > > > > > > > > Yep, VPS, you cannot set them up so easily if you don't have a > > > commonly > > > > > known (static) IP address of the end-point. Where should we send the > > > VPS > > > > > connection request if our IP always changes? Maybe try out every > host > > > on > > > > the > > > > > entire ISP subnet? > > > > > > > > > > Our Internet connection is paid by the state. And under the current > > > > contract > > > > > we actually even not allowed to publish a simple website from our > > > network. > > > > > So why should they give us a static IP to make it easier for us to > do > > > so? > > > > > > > > > > > > > You can not blame the internet-community for your organisation's > failure > > > > to negotiate a contract that meets your needs. I doubt you'll find a > > > > serious SP anywhere that doesn't offer contracts that include static > > > > addressing. So far there's been no mention of a need for multi-homing > > > > which normally is the key requirement to justify direct assignments. > > > > What difference does the fee make if you don't qualify for an > allocation > > > > in the first place. > > > > > > > > > > > > > So the reason why ARIN should change its policies is that we want > ARIN > > > to > > > > > allocate us some IP addresses which are the only way for us to solve > > > our > > > > > little problem. > > > > > > > > You should resolve this with the people who are responsible for a > > > > service-contract that doesn't meet your functional requirements. > > > > > > > > > > > > //per > > > > > > > > _______________________________________________ > > > > PPML > > > > You are receiving this message because you are subscribed to > > > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > > > Unsubscribe or manage your mailing list subscription at: > > > > http://lists.arin.net/mailman/listinfo/arin-ppml > > > > Please contact info at arin.net if you experience any issues. > > > _______________________________________________ > > > PPML > > > You are receiving this message because you are subscribed to > > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > > Unsubscribe or manage your mailing list subscription at: > > > http://lists.arin.net/mailman/listinfo/arin-ppml > > > Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From kkargel at polartel.com Mon Nov 30 11:01:24 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Mon, 30 Nov 2009 10:01:24 -0600 Subject: [arin-ppml] IP Address Fee Structure Policy and the Right of Education In-Reply-To: References: Message-ID: <8695009A81378E48879980039EEDAD2869DCBF17@MAIL1.polartel.local> Christopher, As a US ISP who has provided internet service for many schools I will agree with others who have advised you here that your best venue will be to get the schools involved to request IP addresses from their internet service provider. If they can justify this with a need (and a classroom project would satisfy that need) I am sure the ISP's will work with the schools. This is especially true if the project at this time is a proof of concept and may or may not be a permanent installation. If the project evaporates it will be much easier to re-assimilate the IP addresses if they were allocated by the ISP. When your project is mature and proven then will be the appropriate time to approach the community with a request for a permanent assignment. Even then the schools will need to coordinate with the ISP to make sure it is possible to advertise the allocation properly. Best regards, Kevin Kargel Polar Communications,110 4th Street East,Park River, ND 58270 Tel: (701)284-7221 x330 (800)284-7222 Fax: (701)284-2758 kkargel at polartel.com or sysadmin at polarcomm.com > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Christopher Mettin > Sent: Saturday, November 28, 2009 7:17 PM > To: jradel at vantage.com; arin-ppml at arin.net; 'Scott Leibrand'; > sethm at rollernet.us; 'David Farmer'; joelja at bogus.com; > mcr at marajade.sandelman.ca > Subject: [arin-ppml] IP Address Fee Structure Policy and the Right of > Education > > ARIN Community, > > This message is on my proposed resolution to the current ARIN policy and > fee > structure. > > Seth Mattinen wrote: > >What exactly makes you think you need to pay ARIN to get on the internet? > > The fact that one can't access the Internet without an IP address and that > ARIN sells them. > > Seth Mattinen wrote: > >As somebody has already touched on, I'd be surprised if all the ISPs > >involved allowed you to bring /24s to the table, particularly ones > >"donated" by somebody else that has no relationship to any of the > >involved schools, yet didn't have static addresses available upon > >request. What do your ISPs have to say about all this? > > > >Second, might I suggest that you look into VPNs as a partial solution to > >your security issues, although admittedly they're easier to setup if you > >have static IP addresses at your disposal. > > > >Third, you appear to be going down a path of using fixed IP addresses to > >separate insiders from outsiders who use the same ISP, with insiders > >trusted and the other ISP customers not trusted. That strikes me as a > >rather simplistic threat model to be working with. Frankly, without any > >further information, I'd say the odds are that the curious and malicious > >that are already on the school networks are much more likely to mess > >around with the other school's equipment than random ISP customers > >are. Not that it's a bad thing to restrict the outsiders, but..... > > > >I admit the above may be selling your analysis of the situation short, > >but nothing I've seen about the problem you're trying to solve even > >begins to address why ARIN should change its fee structure or completely > >change the requirements for PI space assignment (if my guess that you're > >all single-homed school networks and in no danger of justifying a /20 is > >correct). > > >My suggestion would be that you hit up your respective ISPs to give you > >static addresses at no extra charge for the good will and possible tax > >benefits. Even if they're only willing to give you /29s, you can > >harmonize your RFC1918 address space use and use VPNs that properly > >reflect your security policies. > > Yep, VPS, you cannot set them up so easily if you don't have a commonly > known (static) IP address of the end-point. Where should we send the VPS > connection request if our IP always changes? Maybe try out every host on > the > entire ISP subnet? > > Our Internet connection is paid by the state. And under the current > contract > we actually even not allowed to publish a simple website from our network. > So why should they give us a static IP to make it easier for us to do so? > > So the reason why ARIN should change its policies is that we want ARIN to > allocate us some IP addresses which are the only way for us to solve our > little problem. > > Thannk you. > > Sincerely yours, > Christopher Mettin > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From michael.dillon at bt.com Mon Nov 30 11:02:14 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 30 Nov 2009 16:02:14 -0000 Subject: [arin-ppml] IP Address Fee Structure Policy and the Right ofEducation In-Reply-To: <20091130154350.GA19444@vacation.karoshi.com.> Message-ID: <28E139F46D45AF49A31950F88C497458044FDDEE@E03MVZ2-UKDY.domain1.systemhost.net> > thanks. this clarifies (for me) a little more of your situation. > > And an IP for example is 217.234.79.76, which is Yes indeed, this clarifies things. http://217.234.79.76 leads me to http://217.234.79.76/web/index.php?forum-showposts-1 which says that you plan on rebroadcasting US TV channels. I imagine that you have found a high-school in the USA that is willing to host a Slingbox, or something similar, and you need a static IP address as a destination for your streams. No doubt this will be a lucrative business until you get arrested by the police. I feel a screenplay coming on... --Michael Dillon From tme at multicasttech.com Mon Nov 30 11:03:54 2009 From: tme at multicasttech.com (Marshall Eubanks) Date: Mon, 30 Nov 2009 11:03:54 -0500 Subject: [arin-ppml] IP Address Fee Structure Policy and the Right of Education In-Reply-To: References: <4B120115.8080307@eml.cc> <20091129131006.GA7604@vacation.karoshi.com.> <75822E125BCB994F8446858C4B19F0D793F44598@SUEX07-MBX-04.ad.syr.edu> <20091130011749.GA11856@vacation.karoshi.com.> <20091130152243.GA19057@vacation.karoshi.com.> Message-ID: On Nov 30, 2009, at 10:35 AM, Christopher Mettin wrote: > Our postal address is as follows: > > Gymnasium Querfurt High School > An der Geispromenade 29 > Querfurt, ST 06268 > > And an IP for example is 217.234.79.76, which is dynamically > assigned by a > German Service Provider. > > As far as I could figure it out, we get assignments in the range from > 217.334.0.1 to 217.334.255.254. > > Why do you need that? > > Ah yeah, I am sorry if I have never told it in that way, legally the > school > is actually on American ground, we even have a Union flag with 51 > stars in > front of the school building. > This is off-topic, but you might want to count those stars again . More on topic is that you forgot to mention that you are operating a TLD registry http://tld.gqbc-online.com/ Regards Marshall > Any other questions? > > Sincerely yours, > Christopher Mettin > Gymnasium Querfurt High School > > > -----Original Message----- > From: bmanning at vacation.karoshi.com [mailto:bmanning at vacation.karoshi.com > ] > Sent: Monday, November 30, 2009 4:23 PM > To: Christopher Mettin > Cc: bmanning at vacation.karoshi.com > Subject: Re: [arin-ppml] IP Address Fee Structure Policy and the > Right of > Education > > the national science foundation is not under the department of > defense. > and actually, they did - due to agreement within the then Federal > Networking > Council - transfering responsiblity to the NSF from DoD. > > for further edification, may I ask a few questions? > > ) can you provide a postal address for Gymnasium Querfurt High School? > ) what prefix(es) are you currently using? dynamic assignements from > your > ISP are fine. > > --bill > > > On Mon, Nov 30, 2009 at 03:58:36PM +0100, Christopher Mettin wrote: >> Is the NSF an agency under the Department of Defense? If not they >> had no >> right to delegate ARIN control over IP address registrations. >> And unfortunately I know what it means if a government organization > approves >> a plan of a commercial company -> lobbying. Not that lobbying would >> be >> something bad, but sometimes it looks like not everyone was asked. >> >> Sincerely yours, >> Christopher Mettin >> Gymnasium Querfurt High School >> >> -----Original Message----- >> From: bmanning at vacation.karoshi.com [mailto:bmanning at vacation.karoshi.com >> ] > >> Sent: Monday, November 30, 2009 2:18 AM >> To: Milton L Mueller >> Cc: bmanning at vacation.karoshi.com; Christopher Mettin >> Subject: Re: [arin-ppml] IP Address Fee Structure Policy and the >> Right of >> Education >> >> >> well - here is one... >> >> http://128.150.4.107/news/news_summ.jsp?cntn_id=102819 >> >> -----Original Message----- >> From: bmanning at vacation.karoshi.com [mailto:bmanning at vacation.karoshi.com >> ] > >> Sent: Monday, November 30, 2009 1:38 AM >> To: Christopher Mettin >> Cc: bmanning at vacation.karoshi.com >> Subject: Re: [arin-ppml] IP Address Fee Structure Policy and the >> Right of >> Education >> >> On Sun, Nov 29, 2009 at 04:09:25PM +0100, Christopher Mettin wrote: >>> >>> But would there generally be a problem with my model of assigning IP >>> addresses to educational institutions through GQHS as LIR? >>> >>> Thank you. >>> >>> Sincerely yours, >>> Christopher Mettin >>> Gymnasium Querfurt High School >>> >> >> don't really know. you'd have to ask ARIN. >> and since this is the public policy list, not sure >> that asking here is the same as asking ARIN. >> >> --bill >> >> On Sun, Nov 29, 2009 at 07:14:11PM -0500, Milton L Mueller wrote: >>> Bill >>> Would like to see any documents memorializing the "consent of the >> governments of the region." >>> >>>> -----Original Message----- >>>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml- >>>> bounces at arin.net] > On >>>> Behalf Of bmanning at vacation.karoshi.com >>>> Sent: Sunday, November 29, 2009 8:10 AM >>>> To: Christopher Mettin >>>> Cc: arin-ppml at arin.net >>>> Subject: Re: [arin-ppml] IP Address Fee Structure Policy and the >>>> Right >> of >>>> Education >>>> >>>> >>>> ARIN manages the IP space for its region based on the consent of >>>> its >>>> members and the governments in that region. >>>> >>>> ARINs finances are a matter of public record - you can find them on > the >>>> ARIN web site. >>>> >>>> As for your proposal to replace ARIN with GQHS, I for one, would >>>> like > to >>>> see the dialog between you/GQHS and the IANA as a matter of public >> record. >>>> >>>> If you would like to change the ARIN proceedures for address > allocation >>>> and >>>> stewardship - the process is open and available to all. You just >>>> have >> to >>>> convince others to agree with you on your well thought out, viable >>>> alternative. >>>> >>>> Please ensure that you either cover all the things ARIN does or >>>> find >> other >>>> parties to take on those roles. >>>> >>>> >>>> Luck >>>> >>>> >>>> --bill >>>> >>>> >>>> >>>> On Sun, Nov 29, 2009 at 01:53:26PM +0100, Christopher Mettin wrote: >>>>> ARIN Community, >>>>> >>>>> Why does ARIN manage the IP addresses allocated to North America? > Did >>>> they >>>>> win a competition in cost-effeteness and reliability? >>>>> >>>>> And does ARIN show a proof that the fees cover at least 90% of >>>>> their >>>>> operating costs? >>>>> >>>>> If IANA would replace ARIN with GQHS today, I could offer >>>>> everyone a >> /20 >>>>> block for just $10 annually and no cent more. GQHS will also have > less >>>>> operation costs and that will save our environment a lot. >>>>> >>>>> I will propose this idea to IANA soon. Maybe "Virginian non- >>>>> profit" >>>> actually >>>>> means they just don't have any stocks but I bet they make a >>>>> million >>>> revenue >>>>> each year. At all, they are not the right organization to manage >>>>> IP >>>>> addresses it seems. >>>>> >>>>> Has anyone a problem with IP addresses given away for as cheap >>>>> as a >> .com >>>>> domain? >>>>> >>>>> Sincerely yours, >>>>> Christopher >>>>> >>>>> -----Original Message----- >>>>> From: Per Heldal [mailto:heldal at eml.cc] >>>>> Sent: Sunday, November 29, 2009 6:05 AM >>>>> To: Christopher Mettin >>>>> Subject: Re: [arin-ppml] IP Address Fee Structure Policy and the > Right >>>> of >>>>> Education >>>>> >>>>> On 11/29/2009 02:16 AM, Christopher Mettin wrote: >>>>>> The fact that one can't access the Internet without an IP address >> and >>>> that >>>>>> ARIN sells them. >>>>> >>>>> RIR's don't sell IP-addresses. Addresses are assigned for a > documented >>>>> purpose. The RIRs are not-for-profit organisations. The fee is not > for >>>>> the IP-addresses themselves, but rather to cover the >>>>> administrative >>>>> costs of running the RIR-operations organization. >>>>> >>>>>>> My suggestion would be that you hit up your respective ISPs to > give >>>> you >>>>>>> static addresses at no extra charge for the good will and > possible >>>> tax >>>>>>> benefits. Even if they're only willing to give you /29s, you >>>>>>> can >>>>>>> harmonize your RFC1918 address space use and use VPNs that > properly >>>>>>> reflect your security policies. >>>>>> >>>>>> Yep, VPS, you cannot set them up so easily if you don't have a >>>> commonly >>>>>> known (static) IP address of the end-point. Where should we send > the >>>> VPS >>>>>> connection request if our IP always changes? Maybe try out every >> host >>>> on >>>>> the >>>>>> entire ISP subnet? >>>>>> >>>>>> Our Internet connection is paid by the state. And under the > current >>>>> contract >>>>>> we actually even not allowed to publish a simple website from our >>>> network. >>>>>> So why should they give us a static IP to make it easier for us >>>>>> to >> do >>>> so? >>>>>> >>>>> >>>>> You can not blame the internet-community for your organisation's >> failure >>>>> to negotiate a contract that meets your needs. I doubt you'll >>>>> find a >>>>> serious SP anywhere that doesn't offer contracts that include >>>>> static >>>>> addressing. So far there's been no mention of a need for > multi-homing >>>>> which normally is the key requirement to justify direct >>>>> assignments. >>>>> What difference does the fee make if you don't qualify for an >> allocation >>>>> in the first place. >>>>> >>>>> >>>>>> So the reason why ARIN should change its policies is that we want >> ARIN >>>> to >>>>>> allocate us some IP addresses which are the only way for us to > solve >>>> our >>>>>> little problem. >>>>> >>>>> You should resolve this with the people who are responsible for a >>>>> service-contract that doesn't meet your functional requirements. >>>>> >>>>> >>>>> //per >>>>> >>>>> _______________________________________________ >>>>> PPML >>>>> You are receiving this message because you are subscribed to >>>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>>>> Unsubscribe or manage your mailing list subscription at: >>>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>>> Please contact info at arin.net if you experience any issues. >>>> _______________________________________________ >>>> PPML >>>> You are receiving this message because you are subscribed to >>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>>> Unsubscribe or manage your mailing list subscription at: >>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>> Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From michael.dillon at bt.com Mon Nov 30 11:11:20 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 30 Nov 2009 16:11:20 -0000 Subject: [arin-ppml] IP Address Fee Structure Policy and the RightofEducation In-Reply-To: <469008208-1259596522-cardhu_decombobulator_blackberry.rim.net-740346393-@bda560.bisx.prod.on.blackberry> Message-ID: <28E139F46D45AF49A31950F88C497458044FDE1B@E03MVZ2-UKDY.domain1.systemhost.net> > Now I'm curious as to why that flag has 51 stars. My guess is that he worships Herman Johannes Xennt who declared a former NATO bunker in the Netherlands to be an independent country. But since it was hard to make a case for his high-school being a similarly independent country, they settled for putting up a modified flag and claiming that they are the 51st state of the United States. But why should I guess. Let's give Google a go: Querfurt 51st state So, it seems that all of Sachsen-Anhalt is now part of the United States. I wonder how many electoral college votes they have? --Michael Dillon P.S. If Steiermark, Austria would do the same, the the current governor of California could end up being the next President of the USA, having been born in the 52nd state... From baptista at publicroot.org Mon Nov 30 11:18:18 2009 From: baptista at publicroot.org (Joe Baptista) Date: Mon, 30 Nov 2009 11:18:18 -0500 Subject: [arin-ppml] IP Address Fee Structure Policy and the Right of Education In-Reply-To: References: <4B120115.8080307@eml.cc> <20091129131006.GA7604@vacation.karoshi.com.> <75822E125BCB994F8446858C4B19F0D793F44598@SUEX07-MBX-04.ad.syr.edu> <20091130011749.GA11856@vacation.karoshi.com.> <20091130152243.GA19057@vacation.karoshi.com.> Message-ID: <874c02a20911300818k1ae6579ci9d7e5068c89a8cd@mail.gmail.com> On Mon, Nov 30, 2009 at 11:03 AM, Marshall Eubanks wrote: > More on topic is that you forgot to mention that you are operating a TLD > registry > > http://tld.gqbc-online.com/ > > ah .. but this is an INAIC approved TLD registry. However .. since INAIC does not exist http://bit.ly/61Anot it is easy for us to conclude that the TLD registry Chris operates is maybe part of a scam. Those of you who missed my write up, posted earlier, on the Gymnasium Querfurt can find it here http://bit.ly/87Yjir regards joe baptista -------------- next part -------------- An HTML attachment was scrubbed... URL: From kkargel at polartel.com Mon Nov 30 11:19:54 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Mon, 30 Nov 2009 10:19:54 -0600 Subject: [arin-ppml] IP Address Fee Structure Policy and the Right of Education In-Reply-To: <4B11CF32.3080202@rollernet.us> References: <4B11CF32.3080202@rollernet.us> Message-ID: <8695009A81378E48879980039EEDAD2869DCBF1B@MAIL1.polartel.local> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Seth Mattinen > Sent: Saturday, November 28, 2009 7:33 PM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] IP Address Fee Structure Policy and the Right of > Education > > Christopher Mettin wrote: > > ARIN Community, > > > > This message is on my proposed resolution to the current ARIN policy and > fee > > structure. > > > > Seth Mattinen wrote: > >> What exactly makes you think you need to pay ARIN to get on the > internet? > > > > The fact that one can't access the Internet without an IP address and > that > > ARIN sells them. > > > > That's false. ARIN does not "sell" addresses and you do not need to > engage ARIN directly to access the internet. I disagree, the policy changes last year establishing an IP market did in fact create the situation where IP addresses - or rather the leases for IP addresses - are sold. If the rights to them are exchanged for monetary compensation and the new 'owners' name is transferred on to the registration that pretty much is the definition of sold. > > > > > > > Our Internet connection is paid by the state. And under the current > contract > > we actually even not allowed to publish a simple website from our > network. > > So why should they give us a static IP to make it easier for us to do > so? > > > > Then they are extremely unlikely to let you break away and ARIN PI space > even if you were to get it. It sounds like you are limited by your ISP > contracts, not ARIN policy. > > ~Seth From marty at akamai.com Mon Nov 30 11:23:02 2009 From: marty at akamai.com (Martin Hannigan) Date: Mon, 30 Nov 2009 11:23:02 -0500 Subject: [arin-ppml] IP Address Fee Structure Policy and the RightofEducation In-Reply-To: References: <4B120115.8080307@eml.cc><20091129131006.GA7604@vacation.karoshi.com.><75822E125BCB994F8446858C4B19F0D793F44598@SUEX07-MBX-04.ad.syr.edu><20091130011749.GA11856@vacation.karoshi.com.><20091130152243.GA19057@vacation.karoshi.com.><469008208-1259596522-cardhu_decombobulator_blackberry.rim.net-740346393-@bda560.bisx.prod.on.blackberry> Message-ID: <8FE931AB-89FD-45C4-BD36-5A90508A73CE@akamai.com> On Nov 30, 2009, at 10:56 AM, Christopher Mettin wrote: > . The design was adopted as > proposed by the Department of Defense. > > Should be more than enough reason to drop this actor into kill files. -M< From jradel at vantage.com Mon Nov 30 11:30:41 2009 From: jradel at vantage.com (Jon Radel) Date: Mon, 30 Nov 2009 11:30:41 -0500 Subject: [arin-ppml] IP Address Fee Structure Policy and the Right ofEducation In-Reply-To: <28E139F46D45AF49A31950F88C497458044FDDEE@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458044FDDEE@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <4B13F331.9010106@vantage.com> michael.dillon at bt.com wrote: >> thanks. this clarifies (for me) a little more of your situation. >> > > >>> And an IP for example is 217.234.79.76, which is >>> > > Yes indeed, this clarifies things. http://217.234.79.76 > leads me to http://217.234.79.76/web/index.php?forum-showposts-1 > which says that you plan on rebroadcasting US TV channels. > I imagine that you have found a high-school in the USA that > is willing to host a Slingbox, or something similar, and you > need a static IP address as a destination for your streams. > Hmmmm....at least when I want to do sleazy things on the Internet I don't jump up and down on mailing lists about how everyone owes it to me to make it work. I'm beginning to suspect that all the suggestions that he negotiate something with his ISP aren't getting much traction because his ISP has gotten really, really tired of hearing about all this. Anyway, last I checked, Germany is one of those countries that takes tight control of TVs relatively seriously; there might actually be an interesting back story to that little Godwin's Law outburst. BTW, right now links to the Gymnasium Querfurt Broadcasting Channel are going to http://texas.gqbc-online.com/path/section_home/page_home in/near Dallas, Texas, which has the little note: "Due to problem with the server in our main facility, we switched to our back up server in Dallas, Texas temporarily. Please be aware that some parts of this website might not work correctly and might not be up to date. We appologize for any inconvenience." At the very least, however, I'm hoping that this discussion is proving of pedagogical value to Christopher. --Jon Radel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3303 bytes Desc: S/MIME Cryptographic Signature URL: From kkargel at polartel.com Mon Nov 30 11:32:29 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Mon, 30 Nov 2009 10:32:29 -0600 Subject: [arin-ppml] Continuation: Policy Change Request: IP Address Assignment to Educational and Non-Commercial Organizations In-Reply-To: <874c02a20911281740t56247ebfy590b06cf2f00d91b@mail.gmail.com> References: <874c02a20911281740t56247ebfy590b06cf2f00d91b@mail.gmail.com> Message-ID: <8695009A81378E48879980039EEDAD2869DCBF1F@MAIL1.polartel.local> Assuming this is not all a scam the problem they are going to have in the US is that schools are migrating to a state operated network, and are moving away from independent service providers. The state networks properly manage themselves for both security and access. What the classroom projects are going to have to do is to work with the state network administrators to ensure that their project is within the Acceptable Use Policy (AUP) the school has entered in to with the state. If that is successfully accomplished I do not see why there should be any problem getting IP addresses assigned to the project. If they cannot fit their project in to the AUP then it is something that the school network does not want them to do and we should not abet the effort to do an end run around security. I suspect we have people from "schoolnet" and/or k12 monitoring this list. Can we receive comments from them? I find it hard to believe that the state governments would not be progressive in promoting educational projects on the internet. It is simply a matter of crossing t's and dotting i's, which is as much a part of learning as the technical aspects. Kevin Kargel From ppml at rsuc.gweep.net Mon Nov 30 11:28:36 2009 From: ppml at rsuc.gweep.net (Joe Provo) Date: Mon, 30 Nov 2009 11:28:36 -0500 Subject: [arin-ppml] IP Address Fee Structure Policy and the Right of Education In-Reply-To: References: <4B120115.8080307@eml.cc> Message-ID: <20091130162836.GA85142@gweep.net> Please don't feed the trolls. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From cmettin at gqbc-online.com Mon Nov 30 12:27:14 2009 From: cmettin at gqbc-online.com (Christopher Mettin) Date: Mon, 30 Nov 2009 18:27:14 +0100 Subject: [arin-ppml] Continuation: Policy Change Request: IP Address Assignment to Educational and Non-Commercial Organizations Message-ID: That is a really good idea. Are schoolnet or k12 such state network operators? We should at least send them some email and wait for a reply, maybe they will also join the list. We don't have a state network in Sachsen-Anhalt but maybe any state network can provide us with access to theirs. Thank you, Kevin. Guess that will help. Sincerely yours, Christopher Mettin Gymnasium Querfurt High School -----Original Message----- From: Kevin Kargel [mailto:kkargel at polartel.com] Sent: Monday, November 30, 2009 5:32 PM To: 'arin-ppml at arin.net' Subject: Re: [arin-ppml] Continuation: Policy Change Request: IP Address Assignment to Educational and Non-Commercial Organizations Assuming this is not all a scam the problem they are going to have in the US is that schools are migrating to a state operated network, and are moving away from independent service providers. The state networks properly manage themselves for both security and access. What the classroom projects are going to have to do is to work with the state network administrators to ensure that their project is within the Acceptable Use Policy (AUP) the school has entered in to with the state. If that is successfully accomplished I do not see why there should be any problem getting IP addresses assigned to the project. If they cannot fit their project in to the AUP then it is something that the school network does not want them to do and we should not abet the effort to do an end run around security. I suspect we have people from "schoolnet" and/or k12 monitoring this list. Can we receive comments from them? I find it hard to believe that the state governments would not be progressive in promoting educational projects on the internet. It is simply a matter of crossing t's and dotting i's, which is as much a part of learning as the technical aspects. Kevin Kargel From tedm at ipinc.net Mon Nov 30 14:15:53 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 30 Nov 2009 11:15:53 -0800 Subject: [arin-ppml] IP Address Fee Structure Policy and the Right of Education In-Reply-To: References: <4B120115.8080307@eml.cc> <20091129131006.GA7604@vacation.karoshi.com.> <75822E125BCB994F8446858C4B19F0D793F44598@SUEX07-MBX-04.ad.syr.edu> <20091130011749.GA11856@vacation.karoshi.com.> <20091130152243.GA19057@vacation.karoshi.com.> Message-ID: <4B1419E9.5010804@ipinc.net> Christopher Mettin wrote: > Our postal address is as follows: > > Gymnasium Querfurt High School > An der Geispromenade 29 > Querfurt, ST 06268 > > And an IP for example is 217.234.79.76, which is dynamically assigned by a > German Service Provider. > > As far as I could figure it out, we get assignments in the range from > 217.334.0.1 to 217.334.255.254. > That would be extremely difficult since that's not even a legal IP address. You sure you don't mean 217.234.0.1 to 217.234.255.254 > Why do you need that? > > Ah yeah, I am sorry if I have never told it in that way, legally the school > is actually on American ground, we even have a Union flag with 51 stars in > front of the school building. > That makes no difference at all. Your postal address is located in Germany so you fall under RIPE's (R?seaux IP Europ?ens ) jurisdiction. The NIC's jurisdiction covers geographic, NOT legal, regions. RIPE's name is French anyway, so I'm not sure why you think RIPE has anything to do with Nazi's. Any "request" for IP numbering to ARIN from you will be rejected and referred to RIPE, and in any case you almost certainly don't meet the minimum utilization requirements, much less even if you got them, nobody is going to route them for you, not at least without spending a LOT more money than you are now on connectivity. If your IP addressing is in fact 217.234.0.1 to 217.234.255.254 then your ISP is Deutsche Telekom AG. And DT AG definitely DOES provide static IP addresses - just NOT to their HOME accounts. Your at a school - so if your running a home DSL line on a Speedport 303v from DTAG or something like that, your already being given the cheaper residential rates by DTAG purely out of the kindness of their hearts - in actuality your school DOESN'T deserve them. You SHOULD be paying the more expensive business rates - which come with a static IP address. There's http://www.dyndns.com/ for people like you who are running dynamic IP addresses on cheap home DSL lines and who want to setup servers. Instead of wasting your time here, I suggest you go out and buy a decent router from the http://www.dd-wrt.com list of supported routers, set your DSL modem up in Bridged mode and input the dyndns servers into your router and have at it. There's plenty of people on DTAG who have done that who have written up explanations of how to do that on the Internet, and many in Germany. You probably live within 20km of someone who has done it and can come over and help you if you can't figure it out yourself. Ted > Any other questions? > > Sincerely yours, > Christopher Mettin > Gymnasium Querfurt High School > > > -----Original Message----- > From: bmanning at vacation.karoshi.com [mailto:bmanning at vacation.karoshi.com] > Sent: Monday, November 30, 2009 4:23 PM > To: Christopher Mettin > Cc: bmanning at vacation.karoshi.com > Subject: Re: [arin-ppml] IP Address Fee Structure Policy and the Right of > Education > > the national science foundation is not under the department of defense. > and actually, they did - due to agreement within the then Federal > Networking > Council - transfering responsiblity to the NSF from DoD. > > for further edification, may I ask a few questions? > > ) can you provide a postal address for Gymnasium Querfurt High School? > ) what prefix(es) are you currently using? dynamic assignements from your > ISP are fine. > > --bill > > > On Mon, Nov 30, 2009 at 03:58:36PM +0100, Christopher Mettin wrote: >> Is the NSF an agency under the Department of Defense? If not they had no >> right to delegate ARIN control over IP address registrations. >> And unfortunately I know what it means if a government organization > approves >> a plan of a commercial company -> lobbying. Not that lobbying would be >> something bad, but sometimes it looks like not everyone was asked. >> >> Sincerely yours, >> Christopher Mettin >> Gymnasium Querfurt High School >> >> -----Original Message----- >> From: bmanning at vacation.karoshi.com [mailto:bmanning at vacation.karoshi.com] > >> Sent: Monday, November 30, 2009 2:18 AM >> To: Milton L Mueller >> Cc: bmanning at vacation.karoshi.com; Christopher Mettin >> Subject: Re: [arin-ppml] IP Address Fee Structure Policy and the Right of >> Education >> >> >> well - here is one... >> >> http://128.150.4.107/news/news_summ.jsp?cntn_id=102819 >> >> -----Original Message----- >> From: bmanning at vacation.karoshi.com [mailto:bmanning at vacation.karoshi.com] > >> Sent: Monday, November 30, 2009 1:38 AM >> To: Christopher Mettin >> Cc: bmanning at vacation.karoshi.com >> Subject: Re: [arin-ppml] IP Address Fee Structure Policy and the Right of >> Education >> >> On Sun, Nov 29, 2009 at 04:09:25PM +0100, Christopher Mettin wrote: >>> But would there generally be a problem with my model of assigning IP >>> addresses to educational institutions through GQHS as LIR? >>> >>> Thank you. >>> >>> Sincerely yours, >>> Christopher Mettin >>> Gymnasium Querfurt High School >>> >> don't really know. you'd have to ask ARIN. >> and since this is the public policy list, not sure >> that asking here is the same as asking ARIN. >> >> --bill >> >> On Sun, Nov 29, 2009 at 07:14:11PM -0500, Milton L Mueller wrote: >>> Bill >>> Would like to see any documents memorializing the "consent of the >> governments of the region." >>>> -----Original Message----- >>>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] > On >>>> Behalf Of bmanning at vacation.karoshi.com >>>> Sent: Sunday, November 29, 2009 8:10 AM >>>> To: Christopher Mettin >>>> Cc: arin-ppml at arin.net >>>> Subject: Re: [arin-ppml] IP Address Fee Structure Policy and the Right >> of >>>> Education >>>> >>>> >>>> ARIN manages the IP space for its region based on the consent of its >>>> members and the governments in that region. >>>> >>>> ARINs finances are a matter of public record - you can find them on > the >>>> ARIN web site. >>>> >>>> As for your proposal to replace ARIN with GQHS, I for one, would like > to >>>> see the dialog between you/GQHS and the IANA as a matter of public >> record. >>>> If you would like to change the ARIN proceedures for address > allocation >>>> and >>>> stewardship - the process is open and available to all. You just have >> to >>>> convince others to agree with you on your well thought out, viable >>>> alternative. >>>> >>>> Please ensure that you either cover all the things ARIN does or find >> other >>>> parties to take on those roles. >>>> >>>> >>>> Luck >>>> >>>> >>>> --bill >>>> >>>> >>>> >>>> On Sun, Nov 29, 2009 at 01:53:26PM +0100, Christopher Mettin wrote: >>>>> ARIN Community, >>>>> >>>>> Why does ARIN manage the IP addresses allocated to North America? > Did >>>> they >>>>> win a competition in cost-effeteness and reliability? >>>>> >>>>> And does ARIN show a proof that the fees cover at least 90% of their >>>>> operating costs? >>>>> >>>>> If IANA would replace ARIN with GQHS today, I could offer everyone a >> /20 >>>>> block for just $10 annually and no cent more. GQHS will also have > less >>>>> operation costs and that will save our environment a lot. >>>>> >>>>> I will propose this idea to IANA soon. Maybe "Virginian non-profit" >>>> actually >>>>> means they just don't have any stocks but I bet they make a million >>>> revenue >>>>> each year. At all, they are not the right organization to manage IP >>>>> addresses it seems. >>>>> >>>>> Has anyone a problem with IP addresses given away for as cheap as a >> .com >>>>> domain? >>>>> >>>>> Sincerely yours, >>>>> Christopher >>>>> >>>>> -----Original Message----- >>>>> From: Per Heldal [mailto:heldal at eml.cc] >>>>> Sent: Sunday, November 29, 2009 6:05 AM >>>>> To: Christopher Mettin >>>>> Subject: Re: [arin-ppml] IP Address Fee Structure Policy and the > Right >>>> of >>>>> Education >>>>> >>>>> On 11/29/2009 02:16 AM, Christopher Mettin wrote: >>>>>> The fact that one can't access the Internet without an IP address >> and >>>> that >>>>>> ARIN sells them. >>>>> RIR's don't sell IP-addresses. Addresses are assigned for a > documented >>>>> purpose. The RIRs are not-for-profit organisations. The fee is not > for >>>>> the IP-addresses themselves, but rather to cover the administrative >>>>> costs of running the RIR-operations organization. >>>>> >>>>>>> My suggestion would be that you hit up your respective ISPs to > give >>>> you >>>>>>> static addresses at no extra charge for the good will and > possible >>>> tax >>>>>>> benefits. Even if they're only willing to give you /29s, you can >>>>>>> harmonize your RFC1918 address space use and use VPNs that > properly >>>>>>> reflect your security policies. >>>>>> Yep, VPS, you cannot set them up so easily if you don't have a >>>> commonly >>>>>> known (static) IP address of the end-point. Where should we send > the >>>> VPS >>>>>> connection request if our IP always changes? Maybe try out every >> host >>>> on >>>>> the >>>>>> entire ISP subnet? >>>>>> >>>>>> Our Internet connection is paid by the state. And under the > current >>>>> contract >>>>>> we actually even not allowed to publish a simple website from our >>>> network. >>>>>> So why should they give us a static IP to make it easier for us to >> do >>>> so? >>>>> You can not blame the internet-community for your organisation's >> failure >>>>> to negotiate a contract that meets your needs. I doubt you'll find a >>>>> serious SP anywhere that doesn't offer contracts that include static >>>>> addressing. So far there's been no mention of a need for > multi-homing >>>>> which normally is the key requirement to justify direct assignments. >>>>> What difference does the fee make if you don't qualify for an >> allocation >>>>> in the first place. >>>>> >>>>> >>>>>> So the reason why ARIN should change its policies is that we want >> ARIN >>>> to >>>>>> allocate us some IP addresses which are the only way for us to > solve >>>> our >>>>>> little problem. >>>>> You should resolve this with the people who are responsible for a >>>>> service-contract that doesn't meet your functional requirements. >>>>> >>>>> >>>>> //per >>>>> >>>>> _______________________________________________ >>>>> PPML >>>>> You are receiving this message because you are subscribed to >>>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>>>> Unsubscribe or manage your mailing list subscription at: >>>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>>> Please contact info at arin.net if you experience any issues. >>>> _______________________________________________ >>>> PPML >>>> You are receiving this message because you are subscribed to >>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>>> Unsubscribe or manage your mailing list subscription at: >>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>> Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From craig.finseth at state.mn.us Mon Nov 30 14:32:06 2009 From: craig.finseth at state.mn.us (Craig Finseth) Date: Mon, 30 Nov 2009 13:32:06 -0600 Subject: [arin-ppml] Continuation: Policy Change Request: IP Address Assignment to Educational and Non-Commercial Organizations In-Reply-To: <8695009A81378E48879980039EEDAD2869DCBF1F@MAIL1.polartel.local> (message from Kevin Kargel on Mon, 30 Nov 2009 10:32:29 -0600) References: <874c02a20911281740t56247ebfy590b06cf2f00d91b@mail.gmail.com> <8695009A81378E48879980039EEDAD2869DCBF1F@MAIL1.polartel.local> Message-ID: <200911301932.nAUJW63x031613@inana.itg.state.mn.us> Assuming this is not all a scam the problem they are going to have in the US is that schools are migrating to a state operated network, and are moving away from independent service providers. The state networks properly manage themselves for both security and access. ... I suspect we have people from "schoolnet" and/or k12 monitoring this list. Can we receive comments from them? I find it hard to believe that the state governments would not be progressive in promoting educational projects on the internet. It is simply a matter of crossing t's and dotting i's, which is as much a part of learning as the technical aspects. Yes and no. The Minnesota state-based network provides connectivity to about 1/3 of the school districts in the state. Other large ISPs handle the rest. I am not aware of any K12 that operates in the DFZ, although one might. In our case, we handle the DFZ routing for the K12s (and our other customers). Since these other customers include those such as essentially all law enforcement, first responders, 911-type services, and other critical infrastructure, we would not let K12s (or, for that matter, any other customer) have direct access to DFZ routing. Note that we already provide fully-redundant physical and logical DFZ connections. If a K12 came to us about this, we would put them in touch with one of the higher education campuses in the state and facilitate their interaction, possibly by setting up their own MPLS VPN(s). We could also provide globally routable addresses if needed, although I would expect that it be done on RFC 1918 addresses. So, they could get the experience that they want without the risk of affecting service to them or to any other customers. In other words, we would support them but in a way that does not pose a risk to anyone else. Craig From danny at tcb.net Mon Nov 30 17:21:48 2009 From: danny at tcb.net (Danny McPherson) Date: Mon, 30 Nov 2009 15:21:48 -0700 Subject: [arin-ppml] SWIPs & IPv6 Message-ID: <5AB64AFF-C7E9-4699-A45B-F0561EB4B192@tcb.net> An HTML attachment was scrubbed... URL: From danny at tcb.net Mon Nov 30 17:22:25 2009 From: danny at tcb.net (Danny McPherson) Date: Mon, 30 Nov 2009 15:22:25 -0700 Subject: [arin-ppml] SWIPs & IPv6 Message-ID: <2D960BC0-4B97-4595-8C59-1192F78E2EE3@tcb.net> I'd like to know what folks here are thinking regarding IPv6 and SWIPs. In particular, a primary driver for SWIPs today is to enable justification of additional addresses (when the time comes). SWIP data is clearly invaluable to network operations and security folks, as well as law enforcement, when investigating or dealing with various incidents (not to mention many other uses, as many of you well know). I suspect that with such large IPv6 allocations, the need to keep SWIP/(rwhois) data up to date will diminish, severely hindering folks that use SWIP data on a regular basis. Furthermore, while development of an RPKI is underway, it really only deals with certification of routed number spaces (as currently specified). While I _think we don't want all subsequent assignment/allocation data in the RPKI, I'm worried we won't have it anywhere with IPv6 -- or in many different places and formats. I suspect at least a BCP (some form, some where) and some community guidance is in order along these lines (i.e., SWIP-esque data is a must to some reasonable level of granularity), I'd like to see what folks here are thinking along these lines.. If I've missed this discussion here (or in other forums) references welcome, a cursory search yields nothing expressly related to this topic. Thanks in advance, -danny From mcr at sandelman.ca Mon Nov 30 21:44:26 2009 From: mcr at sandelman.ca (Michael Richardson) Date: Mon, 30 Nov 2009 21:44:26 -0500 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <5AB64AFF-C7E9-4699-A45B-F0561EB4B192@tcb.net> References: <5AB64AFF-C7E9-4699-A45B-F0561EB4B192@tcb.net> Message-ID: <29173.1259635466@marajade.sandelman.ca> >>>>> "Danny" == Danny McPherson writes: Danny> I'd like to know what folks here are thinking regarding Danny> IPv6 and SWIPs. In particular, a primary driver for SWIPs Danny> today is to enable justification of additional addresses Danny> (when the time comes). SWIP data is clearly invaluable to Danny> network operations and security folks, as well as law Danny> enforcement, when investigating or dealing with various Danny> incidents (not to mention many other uses, as many of you Danny> well know). Uhm, I guess I really disagree. Maybe to operators that do not take support calls (in particular support calls from other ISPs), then the "primary driver for SWIPs today is to enable justification of additional addresses". But, to the rest of us, SWIP data is not just "clearly invaluable", it's critical to all manner of internal and external support, both for enterprises (me), and ISPs (sometimes me). But, certainly if it's the case that updating SWIP data is just a chore necessary to get more address space, that certainly explains why some ISPs (near me) have little interest in keeping it update, or in doing proper reverse DNS. Danny> basis. Furthermore, while development of an RPKI is Danny> underway, it really only deals with certification of routed Danny> number spaces (as currently specified). While I _think we Danny> don't want all subsequent assignment/allocation data in the Danny> RPKI, I'm worried we won't have it anywhere with IPv6 -- or Danny> in many different places and formats. I suspect at least a Danny> BCP (some form, some where) and some community guidance is in Danny> order along these lines (i.e., SWIP-esque data is a must to Danny> some reasonable level of granularity), I'd like to see what Danny> folks here are thinking along these lines.. If I've missed Danny> this discussion here (or in other forums) references welcome, Danny> a cursory search yields nothing expressly related to this Danny> topic. 1) So, I think you are saying that in IPv6 land, there will be little reason to update delegated SWIP data: Most delegations won't have routing different than their aggregate, and therefore won't an RPKI entry either. 2) You are also saying that all address space that everyone sees will, if you can see, it, be routable. WRT (1): I think you are probably right. I wish I could point to a BCP that told ISPs what they are expected to do. For instance, how many support RFC2317 for delegation of reverse DNS? For me, this is one reason to support Bill Herrin's policy proposal 103 to allocate address space in well known sizes, from well known pools. At least when the SWIP data is missing, one will have some idea what was *supposed* to happen for this block. WRT (2): This concerns me more. I think it is really only true for operators. IPv6 got too much input, I think, from clueful operators and backbone equipment vendors :-) For enterprises, the lack of local address other than ULA ones is a problem, in my opinion. One of the reasons why I dislike RFC4193 (ULA-local) addresses is because there is no SWIP information. If I see a ULA somewhere that it does not belong, it's very hard for me to determine who it is supposed to belong to. (It's certainly the same thing with RFC1918 addresses... and it's also one of the reasons why we got rid of IPv6 site-local addresses...) I have seriously been into multiple organizations where the site to site connectivity was not a VPN, but was outsourced to an "ISP" to "manage". Historically, it was supposed to be run on dedicated equipment, but more often than not, it was "virtual" (with real invoices for equipment not bought). Today, at least nobody pretends that the equipment isn't virtual. Why was I there? To help determine the origin of rogue packets that seemed to be originating from the inside. ULAs, RFC1918s and anything not properly SWIP'ed makes this really hard. Unique addresses are good. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From owen at delong.com Mon Nov 30 22:13:19 2009 From: owen at delong.com (Owen DeLong) Date: Mon, 30 Nov 2009 19:13:19 -0800 Subject: [arin-ppml] SWIPs & IPv6 In-Reply-To: <2D960BC0-4B97-4595-8C59-1192F78E2EE3@tcb.net> References: <2D960BC0-4B97-4595-8C59-1192F78E2EE3@tcb.net> Message-ID: <040DE541-C865-4898-9696-BEB2BAAC9B90@delong.com> I believe that the resource review policy would preserve the need for ISPs to keep SWIPs up to date or risk having their resources audited. Owen On Nov 30, 2009, at 2:22 PM, Danny McPherson wrote: > > I'd like to know what folks here are thinking regarding > IPv6 and SWIPs. In particular, a primary driver for SWIPs > today is to enable justification of additional addresses > (when the time comes). SWIP data is clearly invaluable to > network operations and security folks, as well as law > enforcement, when investigating or dealing with various > incidents (not to mention many other uses, as many of you > well know). > > I suspect that with such large IPv6 allocations, the need > to keep SWIP/(rwhois) data up to date will diminish, severely > hindering folks that use SWIP data on a regular basis. > > Furthermore, while development of an RPKI is underway, it > really only deals with certification of routed number spaces > (as currently specified). While I _think we don't want all > subsequent assignment/allocation data in the RPKI, I'm worried > we won't have it anywhere with IPv6 -- or in many different > places and formats. > > I suspect at least a BCP (some form, some where) and some > community guidance is in order along these lines (i.e., > SWIP-esque data is a must to some reasonable level of > granularity), I'd like to see what folks here are thinking > along these lines.. > > If I've missed this discussion here (or in other forums) > references welcome, a cursory search yields nothing expressly > related to this topic. > > Thanks in advance, > > -danny > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues.