From matt.pounsett at cira.ca Sun May 1 13:32:43 2005 From: matt.pounsett at cira.ca (Matt Pounsett) Date: Sun, 1 May 2005 13:32:43 -0400 Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: <2147483647.1114432682@delong-dhcp8.delong.sj.ca.us> References: <20050425164516.GA38607@ussenterprise.ufp.org> <2147483647.1114429693@delong-dhcp8.delong.sj.ca.us> <2147483647.1114432682@delong-dhcp8.delong.sj.ca.us> Message-ID: <0976c9d319028c882407217df312f047@cira.ca> On Apr 25, 2005, at 15:38, Owen DeLong wrote: > Well... I feel that the /48, /64, etc. discussion has wandered far > afield > from the topic of the 2005-1 policy proposal (whether or not to issue > PI > space to end users of V6 that can justify it). I just don't see how a > debate > of minimum prefix sizes overall for V6 is part of this discussion. 2005-1 also indirectly addresses the question of what gets assigned, and in that context a discussion on prefix sizes is perfectly relevant. Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From terry.l.davis at boeing.com Mon May 2 00:06:40 2005 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Sun, 1 May 2005 21:06:40 -0700 Subject: [ppml] 2005-1:Multi-national Business Enablement Message-ID: <6E5042539D21AF4E9C457B4DDCC3D6E108301302@xch-nw-21.nw.nos.boeing.com> Owen I think Fred is describing reality for those of us that have global networks. Maybe you have a point on the /64's; that could be an option. But sorry, no global corporation is going to accept a single ISP solution as currently dictated; not one of us would survive trying to explain this to our Boards. That is reality whether the routing works or not!! And it is the crux of whether v6 can advance or not. Take care Terry -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Saturday, April 23, 2005 12:29 AM To: Jeroen Massar; Wettling, Fred Cc: ppml at arin.net Subject: Re: [ppml] 2005-1:Multi-national Business Enablement > Let's make a nice normal typical example of a 'multi-national business': > > Thus there is a company lets name it Example Corp. > This company has offices (read: sites) all around the world (New York, > Amsterdam, Paris, London, Tokyo, Canberra, Seoul, Lima, etc). Every site > has their own admins so they want a /48 per site, just like every > enduser with a dsl line, cellphone, or whatever connectivity method gets > a /48. As this company is large it also has a lot of employees, and > these like to dial in to the company network using VPN's. Thus everytime > a employee connects, this employees network wants to get connected to > the company network and thus the VPN gets a /48 routed over it too. > Um... generally, the company should be giving /64s to the employees, VPNs, etc., not /48s. Every end user with a DSL line, generally, should also be getting a /64 unless they have need of multiple networks, in which case, a /48 would be justified. > Effectively this company will thus need a /32 or similar large sized > block, just like Google and Microsoft amongst others already have. > Not necessarily, however, this example is _NOT_ the example that 2005-1 is targeted for. This example could be an LIR. Now, if the company wants to treat each site as a separate ORG, then, those sites might, individually be eligible for /48s under 2005-1. > Now a fun part. The site in Lima doesn't have that much connectivity, it > has only a 2mbit SAT uplink. The site in Paris is also not very well > connected, only a 10mbit leased line. > > The webservers need a 1Gbit connection, because a lot of French people > are connecting to it etc. Those webservers are located in New York. > > Now where are you going to do your BGP announcements? > > Do remind that the company gets a single /32 and are not supposed to be > announcing multiple /48's out of that, as that will break the whole idea > of aggregation. Also keep in mind that if you only announce it in New > York that traffic from the employees summer house in Nice will flow over > New York to Paris, introducing a nice 160ms latency for his SSH > connection. If you announce it in Paris, without limiting it to the > peers, because then you introduce the latency again, then a lot of > french people and surrounding areas will go over that teeny 10mbit > leased line, while they all might want to download that super cool new > product advertisement movie, which does fit over the 1Gbit pipe at the > webservers but does not fit over the 10mbit leased line... > If you're going to be an LIR, it comes with the responsibility for building a backbone sufficient to meet your Intradomain connectivity needs. If your dealing with multiple organizations that are diversly connected, then, topologically they are many small organizations, not one large one. Owen -- If it wasn't crypto-signed, it probably didn't come from me. From terry.l.davis at boeing.com Mon May 2 00:23:38 2005 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Sun, 1 May 2005 21:23:38 -0700 Subject: [ppml] 2005-1:Business Need for PI Assignments Message-ID: <6E5042539D21AF4E9C457B4DDCC3D6E108301303@xch-nw-21.nw.nos.boeing.com> About four years back I made these points in presentation to the UTC: - Your home is going to be a member of multiple IP-v6 networks. These include: Energy providers (gas and electric) Water City/county/state/federal Communications - Your energy system is likely to consume somewhere between 500 and 1000 addresses by itself. (count every electrical device in your home, including wall sockets!) - Video services - Communications services (phone etc) - Government is considering a v6 address for your property to use for everything from emergency services to tax collection. - Electronic equipment service requirement reporting Take care Terry -----Original Message----- From: Edward Lewis [mailto:Ed.Lewis at neustar.biz] Sent: Monday, April 25, 2005 8:56 AM To: Michael.Dillon at radianz.com Cc: ppml at arin.net Subject: Re: [ppml] 2005-1:Business Need for PI Assignments At 16:31 +0100 4/25/05, Michael.Dillon at radianz.com wrote: >> If you put a /48 in my house, with each device getting a /64 to >> assign a /128 to it's interfaces, I still have a hard time imagining >> that this would be an efficient use of space. > >Now you are thinking like a Bedouin in the Sahara. When water is scarce Analogies don't help me understand the problem any better. Yeah, scarcity is relative. Today I have 3 IP addresses DHCP assigned to me, and even that seems plenty - I've never used more than 2 at a time, 99.99% of the time I use just one. What will I be addressing that will need more addresses? >You are at liberty to run your home network the way that you want to I don't run my home network. As much as networking is my career, I leave it at the office. In my house I have a few client machines, no servers, probably even less sophisticated than what my parents have. I leave the network management to the ISP I buy service from. What I mean is - I have yet to be convinced that there is a concrete reason to assign gobs of addresses to my house. Why not dole out IPv6 a few addresses at a time until it's clear I need a /48 or /52 or /60. My lack of addresses (when I am home) isn't what's holding back innovation. Wouldn't my squandering addresses be a bigger risk to future innovation? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From dr at cluenet.de Mon May 2 00:38:51 2005 From: dr at cluenet.de (Daniel Roesen) Date: Mon, 2 May 2005 06:38:51 +0200 Subject: [ppml] Re: 2005-1:Multi-national Business Enablement In-Reply-To: <000401c54cc3$b2553730$6501a8c0@ssprunk> References: <3400197AD5EC0540BC920AB9A1FD24330190E8E1@fres0094.amers.ibechtel.com> <1114195383.5691.66.camel@firenze.zurich.ibm.com> <20050423114615.GB19642@srv01.cluenet.de> <025801c548d9$260aeb00$6601a8c0@stephen> <20050425222956.GA20348@srv01.cluenet.de> <000401c54cc3$b2553730$6501a8c0@ssprunk> Message-ID: <20050502043851.GA15219@srv01.cluenet.de> On Thu, Apr 28, 2005 at 06:56:04AM -0500, Stephen Sprunk wrote: > Thus spake "Daniel Roesen" > > On Sun, Apr 24, 2005 at 09:13:48AM -0500, Stephen Sprunk wrote: > > > > Nope. They should get a /48 unless they can convincingly show that > > > > they'll never need more than a single subnet. > > > > > > It is ridiculous to think that ISPs are going to completely discard > their > > > current IPv4 topology to deploy IPv6. > > > > Why must they discard any topology? > > IPv6 mandates a particular topology and disallows others which happen > to be in widespread use by IPv4 ISPs. I have problems imagining both. Can you give me an example? > > > Most "residential" ISPs I'm aware of use a single subnet for N > > > customers, > > > > Hm? I guess you are referring to cable modem stuff? > > It's common for cable, DSL, wireless, and other technologies. For > instance, my landlord provides a straight ethernet connection into > my residence (which is connected to a T1); with DHCP, I consume only > one IP per PC. For them to offer me an IPv6 /48 or even /64, they'd > need to change their IPv4 addressing to a /30 or shorter for each > customer, wasting four addresses for a customer with one PC. But that's considered perfectly fine use of those addresses, not "waste". Sure, the result are unused addresses, but the way of usage if sound. I do generally consider a shared L3 subnet a mistake by itself, especially for security reasons (I know there are methods to battle those). > > Over here (DE), almost all residential users use dial-up, be it real > > (analog, ISDN) or virtual (DSL, via PPPoE). So they are connected via > > virtual interfaces, and get their IP address usually via dynamic pools > > or static via RADIUS. No problem adapting this to assign /48s > > (especially via RADIUS). > > If that's the topology, then that makes sense. However, it's not the > dominant topology in the US today. And global IPv6 policies should adapt to US legacy? Or what are you asking for? [my presumption is that we want to reach global policies, not regional ones for that] > > The mantra is "/48, no questions asked, and by default". > > When you consider how that affects the IPv4 topology, that doesn't make > sense in many cases. If we're going to share subnets across customers in > IPv4, we need to do the same for IPv6. Not necessarily. You might take it as a starting point to migrate your legacy setup to a possibly better one. :-) But well, I don't care if US ISPs are giving only /64s to their customers. I do enjoy living in EU where I hope that /48s will be the default (a man needs to dream once in a while). *g* Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From Ed.Lewis at neustar.biz Mon May 2 05:58:25 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Mon, 2 May 2005 11:58:25 +0200 Subject: [ppml] 2005-1:Business Need for PI Assignments In-Reply-To: <6E5042539D21AF4E9C457B4DDCC3D6E108301303@xch-nw-21.nw.nos.boeing.com> References: <6E5042539D21AF4E9C457B4DDCC3D6E108301303@xch-nw-21.nw.nos.boeing.com> Message-ID: At 21:23 -0700 5/1/05, Davis, Terry L wrote: >About four years back I made these points in presentation to the UTC: (Stupid question - what is the UTC?) >- Your home is going to be a member of multiple IP-v6 networks. These >include: ... >- Government is considering a v6 address for your property to use for >everything from emergency services to tax collection. ... Is the presentation publicly available? I have some quibbles with the above "in the small" so it would be better to see the context first. E.g., a v6 address for property - that's certainly tying network topology to geography. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From L.Howard at stanleyassociates.com Mon May 2 14:07:44 2005 From: L.Howard at stanleyassociates.com (Howard, W. Lee) Date: Mon, 2 May 2005 14:07:44 -0400 Subject: [ppml] Re: 2005-1:Multi-national Business Enablement Message-ID: > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Daniel Roesen > Sent: Monday, May 02, 2005 12:39 AM > To: ppml at arin.net > Subject: [ppml] Re: 2005-1:Multi-national Business Enablement > > > > > Over here (DE), almost all residential users use dial-up, > be it real > > > (analog, ISDN) or virtual (DSL, via PPPoE). So they are connected > > > via virtual interfaces, and get their IP address usually > via dynamic > > > pools or static via RADIUS. No problem adapting this to > assign /48s > > > (especially via RADIUS). > > > > If that's the topology, then that makes sense. However, > it's not the > > dominant topology in the US today. > > And global IPv6 policies should adapt to US legacy? Or what > are you asking for? > > [my presumption is that we want to reach global policies, not > regional ones for that] When posting to the ARIN Public Policy Mailing List, on the topic of Policy Proposal 2005-1, it is reasonable to assume the context is regional policy. There are good reasons why we have regional policy forums, facilitated by the Regional Internet Registries. Lee > Best regards, > Daniel > > -- > CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 > From randy at psg.com Mon May 2 14:32:14 2005 From: randy at psg.com (Randy Bush) Date: Mon, 2 May 2005 08:32:14 -1000 Subject: [ppml] Re: 2005-1:Multi-national Business Enablement References: Message-ID: <17014.29230.191127.972140@roam.psg.com> > When posting to the ARIN Public Policy Mailing List, on the topic of Policy > Proposal 2005-1, it is reasonable to assume the context is regional policy. > There are good reasons why we have regional policy forums, facilitated by > the Regional Internet Registries. indeed! after all, my routers only see regional paths and prefixes. randy From Michael.Dillon at radianz.com Tue May 3 06:28:08 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Tue, 3 May 2005 11:28:08 +0100 Subject: Fw: [ppml] 2005-1:Business Need for PI Assignments Message-ID: > For a concrete example, say each state is given a geographical registry Aligning addressing to state boundaries is *NOT* geographical addressing, it is geopolitical addressing. That is what the ITU has proposed and I believe that it is the wrong way to go. >A provider in Detroit may reasonably choose to get its connectivity solely > from Chicago and Cleveland. Either (a) the provider uses Illinois or Ohio > addresses, meaning their customers can only multihome (or change providers) > to other providers also serving Illinois and Ohio, or (b) the provider uses > Michigan addresses and must announce more-specifics into the global (or at > least US) routing tables for each customer block. Both scenarios are worse > than what we have today. First, geographical addressing in IPv6 should be implemented as an alternative choice. That way, there will be a competitive marketplace of sorts, in which providers and companies can choose whether or not to use geographical addressing. If the geographical boundaries were as you described, then you are simply describing a scenario in which a provider, of their own free will, makes a dum choice. Market forces will sort it out. However, if Chicago is considered to be a regional center for the purposes of geographic addressing, it is highly likely that Detroit would be considered to be part of the Chicago region. Geographical addressing ignores national and state boundaries and looks at the cities which are centers of commerce and transportation and communications. It is the relationships between these cities(nodes) that will determine the regional and sub regional boundaries. In the USA, the work done on LATAs will be useful to guide this. However, anyone looking for a system that carves up the world into sharply delineated regions will be disappointed. Since geographical addressing deals with the regions created by human commerce and communications links, the majority of "boundaries" will be as fuzzy as those links. > The only way to make this work is to force providers (by law) to peer with > or purchase transit from all other providers in a given location to be > allowed to offer service there. I can't cure insanity and I can't understand why people think that technical problems need a top-down decree from the "powers that be". If and when IPv6 geographical addressing comes into being it will be based on sound research and the consensus of domain experts including the IP networking community and the economics community and the anthropology community and the geographic community. > Unfortunately, many others proposing the same addressing model are planning > to use it to replace, not augment, the current model. It makes no difference to me what other people are "planning" to do. Many people in the world plan impossible things and most of them fade into the sunset. > > Topology does follow geography. > > No, it does not. The vast, vast majority of networks I personally have > worked on have little if any correlation to geography at the IP level. You are just viewing the network in the wrong way. You are looking at the topology of ASes. I am looking at the topology of traffic flows and it makes little difference to me whether the flows between Boston and New York are inside an AS or between ASes. Current IPv6 addressing mimics IPv4 addressing and aggregates addresses by AS, more or less. I want to cut the pie in a different way so that addresses can be aggregated by geography. And just like Pizza Hut's square slice pizzas, I want to give people a choice. Some people will choose the square slice and some will go for the traditional wedge. Today, in IPv6 addressing this choice does not exist. > Geographic addressing makes things simpler for sites that are connected only > to other sites in the same area, and that may be nice for consumers and some > businesses, but it makes things worse for operators of more complicated > networks. No, it makes things *BETTER* for the operators of complicated networks because they will not need to deal with the large number of routes that are hidden behind the geographical aggregates. Geographical addressing is an *OPTION* which providers can use if it makes sense for them. If a provider does not use geographic addresses in their network and they cover all of the USA, then they can simply accept a single global aggregate route from their peers. If the provider's network spans continents, then it makes more sense to accept a half dozen continental aggregates from peers in the relevant continents. That is all that changes for a network that does not use geographical addresses internally. --Michael Dillon From stephen at sprunk.org Tue May 3 14:38:45 2005 From: stephen at sprunk.org (Stephen Sprunk) Date: Tue, 3 May 2005 13:38:45 -0500 Subject: [ppml] Re: 2005-1:Multi-national Business Enablement References: <3400197AD5EC0540BC920AB9A1FD24330190E8E1@fres0094.amers.ibechtel.com> <1114195383.5691.66.camel@firenze.zurich.ibm.com> <20050423114615.GB19642@srv01.cluenet.de> <025801c548d9$260aeb00$6601a8c0@stephen> <20050425222956.GA20348@srv01.cluenet.de> <000401c54cc3$b2553730$6501a8c0@ssprunk> <20050502043851.GA15219@srv01.cluenet.de> Message-ID: <009001c55010$3eae8250$6601a8c0@stephen> Thus spake "Daniel Roesen" > On Thu, Apr 28, 2005 at 06:56:04AM -0500, Stephen Sprunk wrote: > > IPv6 mandates a particular topology and disallows others > > which happen to be in widespread use by IPv4 ISPs. > > I have problems imagining both. Can you give me an example? IPv6 mandates that users must be given a subnet of their own; it is common practice with IPv4 to issue individual addresses on a shared subnet to reduce waste. These methods are incompatible. > > It's common for cable, DSL, wireless, and other technologies. > > For instance, my landlord provides a straight ethernet connection > > into my residence (which is connected to a T1); with DHCP, I > > consume only one IP per PC. For them to offer me an IPv6 /48 > > or even /64, they'd need to change their IPv4 addressing to a > > /30 or shorter for each customer, wasting four addresses for a > > customer with one PC. > > But that's considered perfectly fine use of those addresses, not > "waste". Sure, the result are unused addresses, but the way of usage > if sound. I sincerely hope that ARIN would not approve any request for IPv4 space that was based on 80% addressing overhead. I'm pretty sure that's a policy violation; if not, it should be. We're short enough on IPv4 addresses as it is; pissing 80% of them away for aesthetics is irresponsible. > I do generally consider a shared L3 subnet a mistake by itself, > especially for security reasons (I know there are methods to battle > those). You may consider it a mistake, but the practice is widespread and works perfectly fine, not to mention it is the most efficient use of address space. > > If that's the topology, then that makes sense. However, it's not the > > dominant topology in the US today. > > And global IPv6 policies should adapt to US legacy? Or what are you > asking for? I'm asking that IPv6 policies allow ISPs to roll out IPv6 without having to completely reengineer existing IPv4 networks as well as quintuple IPv4 address requirements. > [my presumption is that we want to reach global policies, not regional > ones for that] I thought one of the reasons we have RIRs is that different regions may need different policies. If the RIRs are going to consider themselves hostage to decisions made a decade ago by the IETF, there's not much point in having RIRs at all; let's give worldwide address allocation back to the goons at NSI. > > > The mantra is "/48, no questions asked, and by default". > > > > When you consider how that affects the IPv4 topology, that > > doesn't make sense in many cases. If we're going to share > > subnets across customers in IPv4, we need to do the same > > for IPv6. > > Not necessarily. You might take it as a starting point to migrate > your legacy setup to a possibly better one. :-) This is not legacy -- it's current practice for IPv4 and arguably better than the alternative for several reasons. For that matter, I'm willing to bet you'd find the same topology in other countries if you looked. > But well, I don't care if US ISPs are giving only /64s to their > customers. I do enjoy living in EU where I hope that /48s will be the > default (a man needs to dream once in a while). *g* I also hope that /64s and /48s will be available in the US to those who want them, but I'd be much happier getting a few /128s (one per host, via autoconfig). And I say that as a "power user". Without sensible policies, I won't be getting IPv6 at home (or at work, if 2005-1 doesn't pass) at all. It's not routing or transit in the core that we're waiting on now -- it's address policies at the edge. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From jeroen at unfix.org Tue May 3 16:05:20 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 03 May 2005 22:05:20 +0200 Subject: [ppml] Re: 2005-1:Multi-national Business Enablement In-Reply-To: <009001c55010$3eae8250$6601a8c0@stephen> References: <3400197AD5EC0540BC920AB9A1FD24330190E8E1@fres0094.amers.ibechtel.com> <1114195383.5691.66.camel@firenze.zurich.ibm.com> <20050423114615.GB19642@srv01.cluenet.de> <025801c548d9$260aeb00$6601a8c0@stephen> <20050425222956.GA20348@srv01.cluenet.de> <000401c54cc3$b2553730$6501a8c0@ssprunk> <20050502043851.GA15219@srv01.cluenet.de> <009001c55010$3eae8250$6601a8c0@stephen> Message-ID: <1115150720.1788.24.camel@firenze.zurich.ibm.com> On Tue, 2005-05-03 at 13:38 -0500, Stephen Sprunk wrote: > Thus spake "Daniel Roesen" > > On Thu, Apr 28, 2005 at 06:56:04AM -0500, Stephen Sprunk wrote: > > > IPv6 mandates a particular topology and disallows others > > > which happen to be in widespread use by IPv4 ISPs. > > > > I have problems imagining both. Can you give me an example? > > IPv6 mandates that users must be given a subnet of their own; it is common > practice with IPv4 to issue individual addresses on a shared subnet to > reduce waste. These methods are incompatible. First thing you should remember: IPv6 is not IPv4, IPv4 is not IPv6. They look the same they taste the same but they are not the same. As to your problem: the medium (cable or ethernet) is a shared space, on which the user in IPv4 land gets an address, statically, or DHCP. In IPv6 you do the same, assign a /64 to that L2, every user gets an IP using DHCPv6 or RA's. Nothing changed here. Upto here you simply expect the endsite to have 1 endpoint. Now because you are routing to endusers, you must actually expect them to have more than one device, thus to every endpoint you also route a separate /48. Now what is the problem with this again? > > > It's common for cable, DSL, wireless, and other technologies. > > > For instance, my landlord provides a straight ethernet connection > > > into my residence (which is connected to a T1); with DHCP, I > > > consume only one IP per PC. For them to offer me an IPv6 /48 > > > or even /64, they'd need to change their IPv4 addressing to a > > > /30 or shorter for each customer, wasting four addresses for a > > > customer with one PC. > > > > But that's considered perfectly fine use of those addresses, not > > "waste". Sure, the result are unused addresses, but the way of usage > > if sound. > > I sincerely hope that ARIN would not approve any request for IPv4 space that > was based on 80% addressing overhead. I'm pretty sure that's a policy > violation; if not, it should be. We're short enough on IPv4 addresses as it > is; pissing 80% of them away for aesthetics is irresponsible. IPv6 is not IPv4. IPv4 is not IPv6. Or do you consider 48-bit mac addresses also a waste because they will never all pop up on the same L2 segment? Think about that analogy. > > > If that's the topology, then that makes sense. However, it's not the > > > dominant topology in the US today. > > > > And global IPv6 policies should adapt to US legacy? Or what are you > > asking for? > > I'm asking that IPv6 policies allow ISPs to roll out IPv6 without having to > completely reengineer existing IPv4 networks as well as quintuple IPv4 > address requirements. If you need to reengineer your network because of that, I suggest you go to some IPv6 class and learn how to do it there, not that you learn much, because you already know how to solve this problem, you just don't see it at the moment. The real problem you seem to be having is that you do not want to give address space to endusers. Because then you can't have a 'business case' and letting them pay for more addresses. Think about this for a second: charge them based on traffic usage, just like your transits do. They do not charge you based on the number of IP's you are routing either now are they. > > [my presumption is that we want to reach global policies, not regional > > ones for that] > > I thought one of the reasons we have RIRs is that different regions may need > different policies. If the RIRs are going to consider themselves hostage to > decisions made a decade ago by the IETF, there's not much point in having > RIRs at all; let's give worldwide address allocation back to the goons at > NSI. RIRs exist in those regions to be able to help out their local members better. Never realized that it is easier for Japanese/Korean/Chinese organizations to be able to talk in their own tongue to their RIR, or do you want everything to be 'owned & regulated by the US', if you want that, please sign up with the ITU, they want that too. > > > > The mantra is "/48, no questions asked, and by default". > > > > > > When you consider how that affects the IPv4 topology, that > > > doesn't make sense in many cases. If we're going to share > > > subnets across customers in IPv4, we need to do the same > > > for IPv6. > > > > Not necessarily. You might take it as a starting point to migrate > > your legacy setup to a possibly better one. :-) > > This is not legacy -- it's current practice for IPv4 and arguably better > than the alternative for several reasons. For that matter, I'm willing to > bet you'd find the same topology in other countries if you looked. > > > But well, I don't care if US ISPs are giving only /64s to their > > customers. I do enjoy living in EU where I hope that /48s will be the > > default (a man needs to dream once in a while). *g* > > I also hope that /64s and /48s will be available in the US to those who want > them, but I'd be much happier getting a few /128s (one per host, via > autoconfig). And I say that as a "power user". And then you change provider and you have to renumber your house, host per host, fridge by fridge, toy by toy. What kind of poweruser are you? I am not going to renumber every device individually, I just change my RA setup on the routers, fix up the firewall rules, fixup DNS and done in my case. Oh and I changed IPv4 providers twice already and IPv6 blocks three times. 3ffe:8114:2000:240::/60 (tunnel) -> 2001:7b8:300::/48 (tunnel) -> 2001:7b8:20d::/48 (native IPv6 over DSL :) But because the latter two are both the same size, I did not have to redo any network numbering, and I could very easily reconfig my routers to, at first, announce the new prefix, and a week or so later I removed that prefix, and everything moved on seamlessly ;) Now if I had /128's, of which I then would have needed 50 separate ones, really handy for maintaining, I would need to fix up every single toy, change a lot of firewall rules, not the easy sed script, and other annoyances. Also the upstream ISP would have a lot of fun sticking all the reverse delegations into their nameservers. Not even thinking about RPF and other such tools. > Without sensible policies, I won't be getting IPv6 at home (or at work, if > 2005-1 doesn't pass) at all. It's not routing or transit in the core that > we're waiting on now -- it's address policies at the edge. 2005-1 is not for the home. 2005-1 is for organizations (read: businesses) that have a need for multihoming, that means multiple separate physical upstreams and a vast userbase and LIR membership. Or are you going to polute BGP with /128's ? Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 240 bytes Desc: This is a digitally signed message part URL: From dr at cluenet.de Tue May 3 17:01:37 2005 From: dr at cluenet.de (Daniel Roesen) Date: Tue, 3 May 2005 23:01:37 +0200 Subject: [ppml] Re: Re: 2005-1:Multi-national Business Enablement In-Reply-To: <1115150720.1788.24.camel@firenze.zurich.ibm.com> References: <3400197AD5EC0540BC920AB9A1FD24330190E8E1@fres0094.amers.ibechtel.com> <1114195383.5691.66.camel@firenze.zurich.ibm.com> <20050423114615.GB19642@srv01.cluenet.de> <025801c548d9$260aeb00$6601a8c0@stephen> <20050425222956.GA20348@srv01.cluenet.de> <000401c54cc3$b2553730$6501a8c0@ssprunk> <20050502043851.GA15219@srv01.cluenet.de> <009001c55010$3eae8250$6601a8c0@stephen> <1115150720.1788.24.camel@firenze.zurich.ibm.com> Message-ID: <20050503210137.GB3204@srv01.cluenet.de> On Tue, May 03, 2005 at 10:05:20PM +0200, Jeroen Massar wrote: > > Without sensible policies, I won't be getting IPv6 at home (or at work, if > > 2005-1 doesn't pass) at all. It's not routing or transit in the core that > > we're waiting on now -- it's address policies at the edge. > > 2005-1 is not for the home. 2005-1 is for organizations (read: > businesses) that have a need for multihoming, that means multiple > separate physical upstreams and a vast userbase and LIR membership. > Or are you going to polute BGP with /128's ? Did you actully read 2005-1? 2005-1 refers to "end-site organizations", not businesses. I don't think that Owen meant "businesses" when he wrote "organizations". This "only big business shalt be independent" thinking is a disease. Further, there is no requirement for either "separate physical upstreams", "vast userbase" or "LIR membership" in there. Not even implicitly derrived from ASN assignment policy, as you need none of those to qualify for an ASN. For recollection, here is the proposed policy text of 2005-1 again: 6.11 Assignments to End-sites with Autonomous System Numbers Any end-site which meets the current criteria for assignment of an autonomous system number (ASN) shall also qualify for one IPv6 prefix assignment of the minimum size justified under the ARIN guidelines for assignment by an LIR. If the organization grows to require more space, it will not be entitled to an additional block, but rather may obtain a new, replacement block of sufficient size to meet its needs in exchange for making the commitment to return its existing block within 24 months, so that it may be reassigned. Regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From L.Howard at stanleyassociates.com Tue May 3 18:06:30 2005 From: L.Howard at stanleyassociates.com (Howard, W. Lee) Date: Tue, 3 May 2005 18:06:30 -0400 Subject: [ppml] Re: 2005-1:Multi-national Business Enablement Message-ID: > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Jeroen Massar > Sent: Tuesday, May 03, 2005 4:05 PM > To: Stephen Sprunk > Cc: ppml at arin.net > Subject: Re: [ppml] Re: 2005-1:Multi-national Business Enablement > > > The real problem you seem to be having is that you do not > want to give address space to endusers. Because then you > can't have a 'business case' and letting them pay for more addresses. Why do you assume this motive? > RIRs exist in those regions to be able to help out their > local members better. Never realized that it is easier for > Japanese/Korean/Chinese organizations to be able to talk in > their own tongue to their RIR, or do you want everything to > be 'owned & regulated by the US', if you want that, please > sign up with the ITU, they want that too. I think Dr. Zhao would disagree with you. http://www.itu.int/ITU-T/tsb-director/itut-wsis/files/zhao-netgov01.doc I believe the NIRs in Japan, Korea and China operate in the local languages. > Greets, > Jeroen Lee From lea.roberts at stanford.edu Tue May 3 18:43:03 2005 From: lea.roberts at stanford.edu (Lea Roberts) Date: Tue, 3 May 2005 15:43:03 -0700 (PDT) Subject: [ppml] Re: Re: 2005-1:Multi-national Business Enablement In-Reply-To: <20050503210137.GB3204@srv01.cluenet.de> Message-ID: Daniel (et al) - the original 2005-1 did not receive overwhelming support from the community, so it will be revised in keeping with the feedback given in Orlando. there will probaboy need to be a much higher bar to get through the process at this time.... sorry, /Lea On Tue, 3 May 2005, Daniel Roesen wrote: > On Tue, May 03, 2005 at 10:05:20PM +0200, Jeroen Massar wrote: > > > Without sensible policies, I won't be getting IPv6 at home (or at work, if > > > 2005-1 doesn't pass) at all. It's not routing or transit in the core that > > > we're waiting on now -- it's address policies at the edge. > > > > 2005-1 is not for the home. 2005-1 is for organizations (read: > > businesses) that have a need for multihoming, that means multiple > > separate physical upstreams and a vast userbase and LIR membership. > > Or are you going to polute BGP with /128's ? > > Did you actully read 2005-1? > > 2005-1 refers to "end-site organizations", not businesses. I don't think > that Owen meant "businesses" when he wrote "organizations". This "only > big business shalt be independent" thinking is a disease. > > Further, there is no requirement for either "separate physical > upstreams", "vast userbase" or "LIR membership" in there. Not even > implicitly derrived from ASN assignment policy, as you need none of > those to qualify for an ASN. > > For recollection, here is the proposed policy text of 2005-1 again: > > > 6.11 Assignments to End-sites with Autonomous System Numbers > > Any end-site which meets the current criteria for assignment of an > autonomous system number (ASN) shall also qualify for one IPv6 prefix > assignment of the minimum size justified under the ARIN guidelines for > assignment by an LIR. If the organization grows to require more space, > it will not be entitled to an additional block, but rather may obtain a > new, replacement block of sufficient size to meet its needs in exchange > for making the commitment to return its existing block within 24 months, > so that it may be reassigned. > > > > Regards, > Daniel > > -- > CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 > From jeroen at unfix.org Wed May 4 04:39:14 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 04 May 2005 10:39:14 +0200 Subject: [ppml] Re: 2005-1:Multi-national Business Enablement In-Reply-To: References: Message-ID: <1115195954.3981.16.camel@firenze.zurich.ibm.com> On Tue, 2005-05-03 at 18:06 -0400, Howard, W. Lee wrote: > > Behalf Of Jeroen Massar > > The real problem you seem to be having is that you do not > > want to give address space to endusers. Because then you > > can't have a 'business case' and letting them pay for more addresses. > > Why do you assume this motive? Because that is the current business case of many ISP's ? And they earn money with this? There are only few customers ISP's who actually give out multiple IP's to end users. 1 IP address for 'home users', multiple for 'business accounts', for the latter you pay a lot more. Thus if you want to have multiple PC's online with IPv4 addresses you end up doing either NAT, going to a friendly ISP or getting yourself a very expensive business type account. Funny that ISP's claim they can't assign more IP addresses to endusers because "there is a shortage", while they can simply request them from their local RIR. Note the above is for IPv4 and I sincerely hope that ISP's don't do this for IPv6 and nicely give endusers a /48 routed towards the endpoint of that enduser, including reverse dns delegation if that user asks for it of course. If ISP's don't do this, then we can stick to IPv4 and NAT just as well and not even bother with IPv6. (I am btw glad to know a friendly ISP ;) > > RIRs exist in those regions to be able to help out their > > local members better. Never realized that it is easier for > > Japanese/Korean/Chinese organizations to be able to talk in > > their own tongue to their RIR, or do you want everything to > > be 'owned & regulated by the US', if you want that, please > > sign up with the ITU, they want that too. > > I think Dr. Zhao would disagree with you. > http://www.itu.int/ITU-T/tsb-director/itut-wsis/files/zhao-netgov01.doc > I believe the NIRs in Japan, Korea and China operate in the local > languages. That is exactly what I meant with the above. I should have added a colon/newline behind the "to their RIR" part to separate the sentence apparently. As for the ITU part, read between the lines of the following presentations: http://www.itu.int/ITU-T/worksem/ngn/200505/program.html IETF = open free end-2-end connectivity, ITU = regulate+charge for every single application, and it seems they want to bring this weird idea to the internet unfortunately... Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 240 bytes Desc: This is a digitally signed message part URL: From L.Howard at stanleyassociates.com Wed May 4 13:03:31 2005 From: L.Howard at stanleyassociates.com (Howard, W. Lee) Date: Wed, 4 May 2005 13:03:31 -0400 Subject: [ppml] Re: 2005-1:Multi-national Business Enablement Message-ID: > -----Original Message----- > From: Jeroen Massar [mailto:jeroen at unfix.org] > Sent: Wednesday, May 04, 2005 4:39 AM > To: Howard, W. Lee > Cc: ppml at arin.net > Subject: RE: [ppml] Re: 2005-1:Multi-national Business Enablement > > > On Tue, 2005-05-03 at 18:06 -0400, Howard, W. Lee wrote: > > > Behalf Of Jeroen Massar > > > > The real problem you seem to be having is that you do not > > > want to give address space to endusers. Because then you > > > can't have a 'business case' and letting them pay for > more addresses. > > > > Why do you assume this motive? > > Because that is the current business case of many ISP's ? > And they earn money with this? There are only few customers > ISP's who actually give out multiple IP's to end users. > > 1 IP address for 'home users', multiple for 'business > accounts', for the latter you pay a lot more. Thus if you > want to have multiple PC's online with IPv4 addresses you end > up doing either NAT, going to a friendly ISP or getting > yourself a very expensive business type account. Ah. Some residential providers do charge for additional IPs. Others force you into business service. But they do this not because IPs are scarce, but because users with multiple machines use more bandwidth, which changes their capacity model. However, this is not the only reason one might think certain sizes of assignments are too large for home users. For instance, I thik /48 for each residential user is too much, but I don't work for an ISP. When I did work for an ISP, we did not charge for addresses. I believe that we should be very careful how quickly we hand out addresses, because if we're wrong, it's harder to make policies more restrictive than more liberal. > > > RIRs exist in those regions to be able to help out their > > > local members better. Never realized that it is easier for > > > Japanese/Korean/Chinese organizations to be able to talk in > > > their own tongue to their RIR, or do you want everything to > > > be 'owned & regulated by the US', if you want that, please > > > sign up with the ITU, they want that too. > > > > I think Dr. Zhao would disagree with you. > > > http://www.itu.int/ITU-T/tsb-director/itut-> wsis/files/zhao-netgov01.do > > c > > I believe the NIRs in Japan, Korea and China operate in the local > > languages. > > That is exactly what I meant with the above. I should have > added a colon/newline behind the "to their RIR" part to > separate the sentence apparently. As for the ITU part, read > between the lines of the following > presentations: > http://www.itu.int/ITU-> T/worksem/ngn/200505/program.html > IETF > = open free end-2-end > connectivity, ITU = regulate+charge for every single > application, and it seems they want to bring this weird idea > to the internet unfortunately... I don't understand you. How does "ITU = regulate+charge" equate to "'owned & regulated by the US'"? Also, how would you describe the ITU's position on multilingualism versus the RIRs' and ICANN's? Lee > Greets, > Jeroen From John.Sweeting at teleglobe.com Wed May 4 13:19:37 2005 From: John.Sweeting at teleglobe.com (Sweeting, John) Date: Wed, 4 May 2005 13:19:37 -0400 Subject: [ppml] Re: 2005-1:Multi-national Business Enablement Message-ID: <1797AB680DD0D2118987009027178032183D90A5@camtmms01.Teleglobe.CA> *-----Original Message----- *From: Jeroen Massar [mailto:jeroen at unfix.org] *Sent: 4 mai 2005 04:39 *To: Howard, W. Lee *Cc: ppml at arin.net *Subject: RE: [ppml] Re: 2005-1:Multi-national Business Enablement * * *On Tue, 2005-05-03 at 18:06 -0400, Howard, W. Lee wrote: *> > Behalf Of Jeroen Massar * *> > The real problem you seem to be having is that you do not *> > want to give address space to endusers. Because then you *> > can't have a 'business case' and letting them pay for more *addresses. *> *> Why do you assume this motive? * *Because that is the current business case of many ISP's ? *And they earn money with this? There are only few customers ISP's who *actually give out multiple IP's to end users. * *1 IP address for 'home users', multiple for 'business *accounts', for the *latter you pay a lot more. Thus if you want to have multiple *PC's online *with IPv4 addresses you end up doing either NAT, going to a *friendly ISP *or getting yourself a very expensive business type account. There are many differences between a "business account" and a "home user" account; number of IP addresses is just one. Normally "home users" can obtain additional IP addresses for a small administrative fee but if they want additional services normally reserved for a "business account" then they sign up for a "business account". * *Funny that ISP's claim they can't assign more IP addresses to endusers *because "there is a shortage", while they can simply request them from *their local RIR. I have never heard that reason but do not doubt that it is used; it is just not valid though. * *Note the above is for IPv4 and I sincerely hope that ISP's *don't do this *for IPv6 and nicely give endusers a /48 routed towards the endpoint of *that enduser, including reverse dns delegation if that user asks for it *of course. * *If ISP's don't do this, then we can stick to IPv4 and NAT just as well *and not even bother with IPv6. There are other benefits to IPv6 than just more address space. * *(I am btw glad to know a friendly ISP ;) * *> > RIRs exist in those regions to be able to help out their *> > local members better. Never realized that it is easier for *> > Japanese/Korean/Chinese organizations to be able to talk in *> > their own tongue to their RIR, or do you want everything to *> > be 'owned & regulated by the US', if you want that, please *> > sign up with the ITU, they want that too. *> *> I think Dr. Zhao would disagree with you. *> *http://www.itu.int/ITU-T/tsb-director/itut-*wsis/files/zhao-netgov01.doc *> I believe the NIRs in Japan, Korea and China operate in the local *> languages. * *That is exactly what I meant with the above. I should have added a *colon/newline behind the "to their RIR" part to separate the sentence *apparently. As for the ITU part, read between the lines of the *following *presentations: http://www.itu.int/ITU-T/worksem/ngn/200505/program.html *IETF = open free end-2-end connectivity, ITU = regulate+charge *for every *single application, and it seems they want to bring this weird idea to *the internet unfortunately... * *Greets, * Jeroen * * From david.conrad at nominum.com Wed May 4 14:15:42 2005 From: david.conrad at nominum.com (David Conrad) Date: Wed, 4 May 2005 11:15:42 -0700 Subject: Pragmatism (was Re: [ppml] Re: 2005-1:Multi-national Business Enablement) In-Reply-To: <1115195954.3981.16.camel@firenze.zurich.ibm.com> References: <1115195954.3981.16.camel@firenze.zurich.ibm.com> Message-ID: Hi, Speaking only for myself and definitely not representing anyone: On May 4, 2005, at 1:39 AM, Jeroen Massar wrote: > And they earn money with this? There are only few customers ISP's who > actually give out multiple IP's to end users. In my limited experience I have worked for two ISPs which did not charge for addresses and have been a customer of four ISPs, only one of which charged for addresses ($6.95 per month per IP address!?!? They weren't my ISP for very long). Obviously your mileage may vary. > Funny that ISP's claim they can't assign more IP addresses to endusers > because "there is a shortage", while they can simply request them from > their local RIR. To be fair, there is a cost associated with obtaining and managing IP addresses and the documentation associated with requesting those addresses. For example, I suspect many of the people who attend RIR meetings are hired specifically to deal with the IP address allocations and I suspect they'd sort of like to be paid by their employer. In my opinion, it is perfectly appropriate to pass those costs on to customers either hidden in the connectivity fee or as an explicit charge. > If ISP's don't do this, then we can stick to IPv4 and NAT just as well > and not even bother with IPv6. Rightly or wrongly, this is a common suggestion and, if one ignores religion, it has its good points and its bad points. I personally believe that until IPv6 offers something more that IPv4-with-bigger-addresses-and-stateless-autoconfiguration, the IPv4+NAT approach will win. Particularly if end users need to be involved at any technical level when service providers change. > As for the ITU part, read between the lines of the following > presentations: http://www.itu.int/ITU-T/worksem/ngn/200505/program.html > IETF = open free end-2-end connectivity, As anyone who has worked at an ISP will likely tell you, connectivity is never free, rarely open, and perhaps ideally end-2-end, but in reality, most likely mediated by proxies, caches, or NATs. Pretending otherwise is self-defeating. > ITU = regulate+charge for every > single application, and it seems they want to bring this weird idea to > the internet unfortunately... Actually, I believe the ITU position (if it can be said to have a position) is that telecommunications (which includes the Internet) is a national sovereignty issue and nations have the right and responsibility to regulate and/or charge for whatever they feel appropriate to suit their national interests. While people in "the West" may feel this is simply wrong, I suspect you'd get strenuous arguments from people in countries where telecommunication settlements account for significant portions of their country's GNP. With respect to IPv6 and addressing issues, the director of the ITU telecoms standardization has proposed what he has characterized as competition in address allocations for IPv6. His approach is to allocate chunks of addresses on geo-political boundaries instead of the traditional network topological boundaries to attempt to insure a more "equitable" distribution of IPv6 addresses than IPv4 addresses. Depending on where you live, Zhao's approach could either be much more closely aligned with your apparent desire for everyone who requests to have a /48 no questions asked or it could be the exact opposite of allocation on demand and much, much worse than any ISP's or RIR's allocation policies. My larger worry, however, is that the institution of non-network-topological addressing will lead to a traditional telecoms-like settlement regime for the Internet as geo-* addressing requires (at least in all the proposals I've heard) ISPs provide transit for non-customers/non-peers. I'm not smart enough to think up a way to do this without some sort of settlement mechanism, but perhaps others are. Further, while I might think inflicting settlements on the Internet would be an astoundingly bad idea, it is perhaps instructive to note that the PSTN has functioned (more or less) and been economically stable for more than a century. I believe even a perception profligate waste of address space such that it can be seen as even possible that we'll run out of address space greatly strengthens the hand of folks who believe the IPv6 address space should be chunked up and assigned to countries. As such, I personally tend to be a bit conservative when reviewing IPv6 address allocation policies, specifically trying to avoid mistakes (such as fixed network mask lengths) that have been made in the past. However, I do not make policy at ARIN. I, like the other board members, merely try to insure the open policy processes are followed and encourage people to participate and make their own decisions. Rgds, -drc From gih at apnic.net Thu May 5 01:29:59 2005 From: gih at apnic.net (Geoff Huston) Date: Thu, 05 May 2005 15:29:59 +1000 Subject: Pragmatism (was Re: [ppml] Re: 2005-1:Multi-national Business Enablement) In-Reply-To: References: <1115195954.3981.16.camel@firenze.zurich.ibm.com> Message-ID: <6.0.1.1.2.20050505151207.02549620@localhost> David Conrad worried that: >My larger worry, however, is that the institution of >non-network-topological addressing will lead to a traditional >telecoms-like settlement regime for the Internet as geo-* addressing >requires (at least in all the proposals I've heard) ISPs provide transit >for non-customers/non-peers. I'm not smart enough to think up a way to do >this without some sort of settlement mechanism, but perhaps others >are. Further, while I might think inflicting settlements on the Internet >would be an astoundingly bad idea, it is perhaps instructive to note that >the PSTN has functioned (more or less) and been economically stable for >more than a century. Yes, and the attributes that allowed the PSTN to function in this fashion have no counterpart in the Internet. Think "no third party transit", think "call accounting", think "call termination charges", think "Quantum Distortion Units", think "single service network platforms", think of an inter-provider charging regime that became a global industry in its own right that totally perverted the charges for international telephony to such an extent that it had no visible relationship to underlying costs, think market distortions, think structural inefficiencies that when faced with a radically different communications paradigm (such as packet switching) that the industry as a whole was incapable of understanding, let alone reacting, think of massive disruptive forces in one of the more massive, valuable and valued areas of economic activity for the globe. And then, maybe, worry just a little more.. But that won't stop folk from attempting to shoehorn this square plug of Internet technology into a round receptacle of the circuit switched single service PSTN architecture. After all, all you really need to do is just knock off those annoying little corners off the packets! :-) >I believe even a perception profligate waste of address space such that it >can be seen as even possible that we'll run out of address space greatly >strengthens the hand of folks who believe the IPv6 address space should be >chunked up and assigned to countries. As such, I personally tend to be a >bit conservative when reviewing IPv6 address allocation policies, >specifically trying to avoid mistakes (such as fixed network mask lengths) >that have been made in the past. As as we move into a realm where the Internet is a public utility, and national interests have legitimacy for consideration in devising address distribution structure as well as industry and technology interests, then some cautious conservatism is often a better yardstick to use. We need to offer stances that reflect a longer term interest in stewardship of this resource, and balance ease of exploitation against considerations of maintenance of longer term value through careful conservation, and also ensure that this includes careful consideration of externalities such as routeability and service industry business structures. Its the balancing of these diverse set of interests that would be of value to achieve here, which leads me to a very similar conclusion to that of David. regards, Geoff Huston From tvest at pch.net Thu May 5 04:38:24 2005 From: tvest at pch.net (Tom Vest) Date: Thu, 5 May 2005 09:38:24 +0100 Subject: Pragmatism (was Re: [ppml] Re: 2005-1:Multi-national Business Enablement) In-Reply-To: References: <1115195954.3981.16.camel@firenze.zurich.ibm.com> Message-ID: <1666cbc9b46d7546fc3142342855f15a@pch.net> On May 4, 2005, at 7:15 PM, David Conrad wrote: > My larger worry, however, is that the institution of > non-network-topological addressing will lead to a traditional > telecoms-like settlement regime for the Internet as geo-* addressing > requires (at least in all the proposals I've heard) ISPs provide > transit for non-customers/non-peers. I'm not smart enough to think up > a way to do this without some sort of settlement mechanism, but > perhaps others are. Further, while I might think inflicting > settlements on the Internet would be an astoundingly bad idea, it is > perhaps instructive to note that the PSTN has functioned (more or > less) and been economically stable for more than a century. A big correction is in order here. The international telephony settlement system was significantly destabilized in 1996-1997, when the US FCC took steps to address an escalating problem with the ITU accounting system. To the best of my knowledge, many developed countries no longer participate, or participate fully, in this system. Apparently this event is still not widely known or well understood; I am writing a CircleID article related to this, but will provide a quick overview now. The ITU mediated international telephony settlement system specifies that countries (or providers, in competitive markets) set their own retail prices for international telephony services, but compensate each other for net outbound traffic, at a fixed "accounting rate" per net minute (MITT) that is terminated in a particular foreign market. Retail-facing prices are expected to follow the normal "subjective economics" rule that price is set at whatever the market will bear, while the accounting rate is set by multilateral agreement, at a rate that is partially based on the old "objective economics" rule that value is based on input costs. The international accounting rate was not set at "actual" cost of service delivery, but at a cost+ basis, with the premium intended to increase the revenue transfer from wealthy, large call volume-producing countries to LDCs. The explicit goal of this arrangement was to accelerate the rollout of universal telecom service in developing countries. The system was always subject to abuse, as it could create a perverse incentive to suppress demand for outbound calls in order to maximize inbound settlement revenues. This temptation was/is particularly acute for countries with controlled currencies, as telecom settlement payments are made in hard currency. In addition, some statistical research in the mid-1990s cast some doubt on whether these premium payouts had made any difference to the explicit goal of accelerating universal service rollout over the preceding decades. No question that many LDCs could really use more hard currency anywhere that they can get it -- for health, education etc. -- but note that many of the same countries that reserve the right to divert these telecom revenues to other vital social services are the same countries that complain bitterly about the digital divide. Very difficult to have it both ways. Anyway, this latent risk ultimately came to a head in the mid-1990s because of a combination of new technology and asymmetrical market liberalization. Technology brought the advent of callback boxes (I assume everyone here is familiar with these). Asymmetrical market opening made it possible, for example, for entrepreneurial companies to put a callback box in a liberalized, low retail cost market, which would enable a high-cost economy caller to dial the liberalized country, thereby (a) taking advantage of that country's lower retail price for international service, while at the same time (b) increasing that open, low-cost economy's net outbound payment to the high cost economy. International telephony being a very price elastic service, the former greatly increased demand for international calling, which only increased the punishment inflicted on the low cost operators in liberalized markets. Classic telecom arbitrage game. Imagine a scenario where the callback box is actually owned by high cost foreign PSTN; they could simply "voice spam" the low cost economy and create a perpetual money machine. Not a sustainable arrangement. The FCC responded to this development in 1996-1997 with the "Benchmarks" initiative, which sought to put international accounting rates back on an "objective economics" footing, i.e., closer to estimated cost of service delivery. The idea was to reduce the perverse incentives built into the old system without hobbling foreign operators. In theory, subsidies that had been previously hidden in the accounting rate would be replaced by explicit aid that would be more directly tied to telecom infrastructure development. Since that time (I believe) international telephony settlements have diversified quite a lot, with some now based on various bilateral flat-rate arrangements, and some based on the old multilateral net payout system. First moral of the story: the international settlement system was broken well before international data traffic was a big deal. Bonus observation -- Note 1996-1997 timeline exactly corresponds to the institutionalization of the peering hierarchy and the "Great Depeering." From 1997-2004, peering requirements between large operators explicitly followed the kind of "objective economics" cost-of-service-delivery criteria endorsed by out by the FCC for voice telephony. Perhaps no coincidence, since many of the early US international telephony providers are the same IXCs that we know and love as the Tier Ones. Bonus observation 2 -- The International Charging Arrangements (ICAIS) controversy that began almost immediately thereafter is based, if somewhat problematically, on the same "objective economics" cost-of-service-delivery argument. Second moral of the story: Always be care what you tug on; you never know what it's connected to... TV From tvest at pch.net Thu May 5 05:32:18 2005 From: tvest at pch.net (Tom Vest) Date: Thu, 5 May 2005 10:32:18 +0100 Subject: Pragmatism (was Re: [ppml] Re: 2005-1:Multi-national Business Enablement) In-Reply-To: References: <1115195954.3981.16.camel@firenze.zurich.ibm.com> Message-ID: On May 4, 2005, at 7:15 PM, David Conrad wrote: > My larger worry, however, is that the institution of > non-network-topological addressing will lead to a traditional > telecoms-like settlement regime for the Internet as geo-* addressing > requires (at least in all the proposals I've heard) ISPs provide > transit for non-customers/non-peers. I'm not smart enough to think up > a way to do this without some sort of settlement mechanism, but > perhaps others are. Further, while I might think inflicting > settlements on the Internet would be an astoundingly bad idea, it is > perhaps instructive to note that the PSTN has functioned (more or > less) and been economically stable for more than a century. A big correction is in order here. The international telephony settlement system was significantly destabilized in 1996-1997, when the US FCC took steps to address an escalating problem with the ITU accounting system. To the best of my knowledge, many developed countries no longer participate, or participate fully, in this system. Apparently this event is still not widely known or well understood; I am writing a CircleID article related to this, but will provide a quick overview now. The ITU mediated international telephony settlement system specifies that countries (or providers, in competitive markets) set their own retail prices for international telephony services, but compensate each other for net outbound traffic, at a fixed "accounting rate" per net minute (MITT) that is terminated in a particular foreign market. Retail-facing prices are expected to follow the normal "subjective economics" rule that price is set at whatever the market will bear, while the accounting rate is set by multilateral agreement, at a rate that is partially based on the old "objective economics" rule that value is based on input costs. The international accounting rate was not set at "actual" cost of service delivery, but at a cost+ basis, with the premium intended to increase the revenue transfer from wealthy, large call volume-producing countries to LDCs. The explicit goal of this arrangement was to accelerate the rollout of universal telecom service in developing countries. The system was always subject to abuse, as it could create a perverse incentive to suppress demand for outbound calls in order to maximize inbound settlement revenues. This temptation was/is particularly acute for countries with controlled currencies, as telecom settlement payments are made in hard currency. In addition, some statistical research in the mid-1990s cast some doubt on whether these premium payouts had made any difference to the explicit goal of accelerating universal service rollout over the preceding decades. No question that many LDCs could really use more hard currency anywhere that they can get it -- for health, education etc. -- but note that many of the same countries that reserve the right to divert these telecom revenues to other vital social services are the same countries that complain bitterly about the digital divide. Very difficult to have it both ways. Anyway, this latent risk ultimately came to a head in the mid-1990s because of a combination of new technology and asymmetrical market liberalization. Technology brought the advent of callback boxes (I assume everyone here is familiar with these). Asymmetrical market opening made it possible, for example, for entrepreneurial companies to put a callback box in a liberalized, low retail cost market, which would enable a high-cost economy caller to dial the liberalized country, thereby (a) taking advantage of that country's lower retail price for international service, while at the same time (b) increasing that open, low-cost economy's net outbound payment to the high cost economy. International telephony being a very price elastic service, the former greatly increased demand for international calling, which only increased the punishment inflicted on the low cost operators in liberalized markets. Classic telecom arbitrage game. Imagine a scenario where the callback box is actually owned by high cost foreign PSTN; they could simply "voice spam" the low cost economy and create a perpetual money machine. Not a sustainable arrangement. The FCC responded to this development in 1996-1997 with the "Benchmarks" initiative, which sought to put international accounting rates back on an "objective economics" footing, i.e., closer to estimated cost of service delivery. The idea was to reduce the perverse incentives built into the old system without hobbling foreign operators. In theory, subsidies that had been previously hidden in the accounting rate would be replaced by explicit aid that would be more directly tied to telecom infrastructure development. Since that time (I believe) international telephony settlements have diversified quite a lot, with some now based on various bilateral flat-rate arrangements, and some based on the old multilateral net payout system. First moral of the story: the international settlement system was broken well before international data traffic was a big deal. Bonus observation -- Note 1996-1997 timeline exactly corresponds to the institutionalization of the peering hierarchy and the "Great Depeering." From 1997-2004, peering requirements between large operators explicitly followed the kind of "objective economics" cost-of-service-delivery criteria endorsed by out by the FCC for voice telephony. Perhaps no coincidence, since many of the early US international telephony providers are the same IXCs that we know and love as the Tier Ones. Bonus observation 2 -- The International Charging Arrangements (ICAIS) controversy that began almost immediately thereafter is based, if somewhat problematically, on the same "objective economics" cost-of-service-delivery argument. Second moral of the story: Always be care what you tug on; you never know what it's all connected to... TV From tvest at pch.net Thu May 5 08:26:04 2005 From: tvest at pch.net (Tom Vest) Date: Thu, 5 May 2005 13:26:04 +0100 Subject: Pragmatism (was Re: [ppml] Re: 2005-1:Multi-national Business Enablement) In-Reply-To: References: <1115195954.3981.16.camel@firenze.zurich.ibm.com> Message-ID: <7c8581420fe3ead6919a10430ba8fe2a@pch.net> On May 5, 2005, at 10:32 AM, Tom Vest wrote: > On May 4, 2005, at 7:15 PM, David Conrad wrote: > >> My larger worry, however, is that the institution of >> non-network-topological addressing will lead to a traditional >> telecoms-like settlement regime for the Internet as geo-* addressing >> requires (at least in all the proposals I've heard) ISPs provide >> transit for non-customers/non-peers. I'm not smart enough to think >> up a way to do this without some sort of settlement mechanism, but >> perhaps others are. Further, while I might think inflicting >> settlements on the Internet would be an astoundingly bad idea, it is >> perhaps instructive to note that the PSTN has functioned (more or >> less) and been economically stable for more than a century. > > A big correction is in order here. The international telephony > settlement system was significantly destabilized in 1996-1997, when > the US FCC took steps to address an escalating problem with the ITU > accounting system. To the best of my knowledge, many developed > countries no longer participate, or participate fully, in this system. > Apparently this event is still not widely known or well understood; I > am writing a CircleID article related to this, but will provide a > quick overview now... A third implication comes to mind. International telephony settlements probably "reified" and stabilized PSTNs as the chief moving parts in the global circuit switched communications industry, just as the current peering/transit arrangements reinforce the role of autonomous systems in the packet-based traffic business. No country is especially well-served by another country's PSTN, and perhaps no customer is particularly well-served by another's (unrelated) network provider. But overall, which set of arrangements is better equipped to deliver the varied, rapidly evolving and diversifying content, services, and technologies that packet switching makes possible? Which will best preserve the openness that permits current "customers" to step up and become providers themselves (and when circumstances warrant, vice versa)? Of the developing network economies today, which are better served (all things considered), those with substantial provider diversity at layer 3, or those where the rule remains one phone company, one network? TV From randy at psg.com Thu May 5 14:15:32 2005 From: randy at psg.com (Randy Bush) Date: Thu, 5 May 2005 08:15:32 -1000 Subject: Pragmatism (was Re: [ppml] Re: 2005-1:Multi-national Business Enablement) References: <1115195954.3981.16.camel@firenze.zurich.ibm.com> Message-ID: <17018.25284.318407.836502@roam.psg.com> > Actually, I believe the ITU position (if it can be said to have a > position) is that telecommunications (which includes the Internet) is a > national sovereignty issue and nations have the right and > responsibility to regulate and/or charge for whatever they feel > appropriate to suit their national interests. While people in "the > West" may feel this is simply wrong, I suspect you'd get strenuous > arguments from people in countries where telecommunication settlements > account for significant portions of their country's GNP. you are likely correct here, if by people in the west you mean the general populace, and by people in ... you mean the monopoly ptts there but the actual division is between the telcos, who make the money, and the populace, which, if they see anything, tend to see social benefit to open and less financially burdened communication. and guess who the itu represents. randy From owen at delong.com Sat May 7 02:37:02 2005 From: owen at delong.com (Owen DeLong) Date: Fri, 06 May 2005 23:37:02 -0700 Subject: [ppml] 2005-1:Multi-national Business Enablement In-Reply-To: <6E5042539D21AF4E9C457B4DDCC3D6E108301302@xch-nw-21.nw.nos.boeing.com> References: <6E5042539D21AF4E9C457B4DDCC3D6E108301302@xch-nw-21.nw.nos.boein g.com> Message-ID: <2147483647.1115422618@[192.168.1.32]> Terry, One of us is not understanding the other. A global corporation, in my opinion, usually _IS_ an ISP for it's various departments, VPN users, etc. Regardless of the number of external ISPs that they peer with (paid or otherwise), they _ARE_ an ISP themselves. Now, for the ones that aren't, they are multiple islands of connectivity linked by VPNs. In this case, each island is either going to be using one or more PA blocks, or, will be multihomed. In the case of a multihomed island, they would be an ORG qualifying under my intent for 2005-1. In the case of a single-homed island, I believe existing PA solutions are as adequate as current V4 solutions. I'd like to better understand where the disconnect between what I have said in the past and your expression in the quoted message. Currently, from my viewpoint, your comment does not make sense to me as a response to my statements. Owen --On Sunday, May 1, 2005 21:06 -0700 "Davis, Terry L" wrote: > Owen > > I think Fred is describing reality for those of us that have global > networks. Maybe you have a point on the /64's; that could be an option. > > But sorry, no global corporation is going to accept a single ISP > solution as currently dictated; not one of us would survive trying to > explain this to our Boards. That is reality whether the routing works > or not!! And it is the crux of whether v6 can advance or not. > > Take care > Terry > > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Saturday, April 23, 2005 12:29 AM > To: Jeroen Massar; Wettling, Fred > Cc: ppml at arin.net > Subject: Re: [ppml] 2005-1:Multi-national Business Enablement > >> Let's make a nice normal typical example of a 'multi-national > business': >> >> Thus there is a company lets name it Example Corp. >> This company has offices (read: sites) all around the world (New York, >> Amsterdam, Paris, London, Tokyo, Canberra, Seoul, Lima, etc). Every > site >> has their own admins so they want a /48 per site, just like every >> enduser with a dsl line, cellphone, or whatever connectivity method > gets >> a /48. As this company is large it also has a lot of employees, and >> these like to dial in to the company network using VPN's. Thus > everytime >> a employee connects, this employees network wants to get connected to >> the company network and thus the VPN gets a /48 routed over it too. >> > Um... generally, the company should be giving /64s to the employees, > VPNs, > etc., not /48s. Every end user with a DSL line, generally, should also > be > getting a /64 unless they have need of multiple networks, in which case, > a /48 would be justified. > >> Effectively this company will thus need a /32 or similar large sized >> block, just like Google and Microsoft amongst others already have. >> > Not necessarily, however, this example is _NOT_ the example that 2005-1 > is targeted for. This example could be an LIR. Now, if the company > wants > to treat each site as a separate ORG, then, those sites might, > individually > be eligible for /48s under 2005-1. > >> Now a fun part. The site in Lima doesn't have that much connectivity, > it >> has only a 2mbit SAT uplink. The site in Paris is also not very well >> connected, only a 10mbit leased line. >> >> The webservers need a 1Gbit connection, because a lot of French people >> are connecting to it etc. Those webservers are located in New York. >> >> Now where are you going to do your BGP announcements? >> >> Do remind that the company gets a single /32 and are not supposed to > be >> announcing multiple /48's out of that, as that will break the whole > idea >> of aggregation. Also keep in mind that if you only announce it in New >> York that traffic from the employees summer house in Nice will flow > over >> New York to Paris, introducing a nice 160ms latency for his SSH >> connection. If you announce it in Paris, without limiting it to the >> peers, because then you introduce the latency again, then a lot of >> french people and surrounding areas will go over that teeny 10mbit >> leased line, while they all might want to download that super cool new >> product advertisement movie, which does fit over the 1Gbit pipe at the >> webservers but does not fit over the 10mbit leased line... >> > If you're going to be an LIR, it comes with the responsibility for > building a backbone sufficient to meet your Intradomain connectivity > needs. If your dealing with multiple organizations that are diversly > connected, then, topologically they are many small organizations, > not one large one. > > Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From owen at delong.com Sat May 7 02:57:31 2005 From: owen at delong.com (Owen DeLong) Date: Fri, 06 May 2005 23:57:31 -0700 Subject: [ppml] Re: Re: 2005-1:Multi-national Business Enablement In-Reply-To: <20050503210137.GB3204@srv01.cluenet.de> References: <3400197AD5EC0540BC920AB9A1FD24330190E8E1@fres0094.amers.ibechtel .com> <1114195383.5691.66.camel@firenze.zurich.ibm.com> <20050423114615.GB19642@srv01.cluenet.de> <025801c548d9$260aeb00$6601a8c0@stephen> <20050425222956.GA20348@srv01.cluenet.de> <000401c54cc3$b2553730$6501a8c0@ssprunk> <20050502043851.GA15219@srv01.cluenet.de> <009001c55010$3eae8250$6601a8c0@stephen> <1115150720.1788.24.camel@firenze.zurich.ibm.com> <20050503210137.GB3204@srv01.cluenet.de> Message-ID: <2147483647.1115423851@[192.168.1.32]> You are absolutely correct, Daniel. Thanks. Owen --On Tuesday, May 3, 2005 23:01 +0200 Daniel Roesen wrote: > On Tue, May 03, 2005 at 10:05:20PM +0200, Jeroen Massar wrote: >> > Without sensible policies, I won't be getting IPv6 at home (or at >> > work, if 2005-1 doesn't pass) at all. It's not routing or transit in >> > the core that we're waiting on now -- it's address policies at the >> > edge. >> >> 2005-1 is not for the home. 2005-1 is for organizations (read: >> businesses) that have a need for multihoming, that means multiple >> separate physical upstreams and a vast userbase and LIR membership. >> Or are you going to polute BGP with /128's ? > > Did you actully read 2005-1? > > 2005-1 refers to "end-site organizations", not businesses. I don't think > that Owen meant "businesses" when he wrote "organizations". This "only > big business shalt be independent" thinking is a disease. > > Further, there is no requirement for either "separate physical > upstreams", "vast userbase" or "LIR membership" in there. Not even > implicitly derrived from ASN assignment policy, as you need none of > those to qualify for an ASN. > > For recollection, here is the proposed policy text of 2005-1 again: > > > 6.11 Assignments to End-sites with Autonomous System Numbers > > Any end-site which meets the current criteria for assignment of an > autonomous system number (ASN) shall also qualify for one IPv6 prefix > assignment of the minimum size justified under the ARIN guidelines for > assignment by an LIR. If the organization grows to require more space, > it will not be entitled to an additional block, but rather may obtain a > new, replacement block of sufficient size to meet its needs in exchange > for making the commitment to return its existing block within 24 months, > so that it may be reassigned. > > > > Regards, > Daniel -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From paul at vix.com Sat May 7 12:48:47 2005 From: paul at vix.com (Paul Vixie) Date: Sat, 07 May 2005 16:48:47 +0000 Subject: [ppml] 2005-1:Multi-national Business Enablement In-Reply-To: Your message of "Fri, 06 May 2005 23:37:02 MST." <2147483647.1115422618@[192.168.1.32]> References: <6E5042539D21AF4E9C457B4DDCC3D6E108301302@xch-nw-21.nw.nos.boein g.com> <2147483647.1115422618@[192.168.1.32]> Message-ID: <20050507164847.62E5A13971@sa.vix.com> i've been watching this debate, both on the current thread and in years past, and while i watch, i've tried to see if there's a grand unifying principle. multihoming is the right technical basis for needing one's own address space, and i do think that a technical basis is better than any other kind of basis. but what kind of multihoming? buying two DS3's from two transit providers is technically "multihoming" but it's not sufficient cause to allocate a slot in the global routing table-- no matter what size the address block might be. i think i'm ready to make a proposal. let's make it be all about peering, and leave the only-buys-diverse-transit folks to the mercy of their ISP's. we can argue about how many peers you have to have, in how many exchange points, and whether buying transit reduces or increases the number of peers you have to have. we can argue about how often you have to re-show proof that you're still peering, and how long is your grace period if you fall out of compliance. i feel VERY sure that bechtel, ford, daimler-chrysler, and the other large companies with large networks, are all capable of renting rack space at PAIX or Equinix or whatever, buying some routers, renting some BGP engineers, and meeting this requirement. especially if they know they'll get a /32 out of it. occasionally you'll run into smaller companies who can also do this, but i think it's unlikely to cause a "gold rush" toward the peering centers. From owen at delong.com Sun May 8 13:30:13 2005 From: owen at delong.com (Owen DeLong) Date: Sun, 08 May 2005 10:30:13 -0700 Subject: [ppml] Re: 2005-1:Multi-national Business Enablement In-Reply-To: <1797AB680DD0D2118987009027178032183D90A5@camtmms01.Teleglobe.CA> References: <1797AB680DD0D2118987009027178032183D90A5@camtmms01.Teleglobe.CA > Message-ID: <76DBC4FF4CB29FFC1C74B8B0@imac-en0.delong.sj.ca.us> > > There are other benefits to IPv6 than just more address space. People keep making this claim, but, I have not seen anyone back this up in any concrete way with the current IPv6 implementations. Would you care to explain what some of these are? I can show you several new limitations in IPv6 that are problematic vs. IPv4: 1. Lack of a rational microassignment policy or any method for delivery of PI addresses to end sites. 2. In many ways, renumbering is more difficult than in IPv4. (Don't get me wrong, I am not a fan of NAT, and, will be somewhat glad to see it gone, but, NAT did facilitate easy external renumbering). 3. Insanely complex multihoming theories and no actual practice as yet unless you are an ISP. 4. Multiple levels of additional complexity and little or no clarity on correct methods for choosing a source address for a given datagram. I'm sure there are other disadvantages, but, these are the most prominent ones that come to mind immediately. Don't get me wrong, I'm not opposed to IPv6, I'm just not sold on it yet either. I think it's still a work in progress, but, I also think it still needs quite a bit of work before it's ready for prime-time. Also, I just haven't seen enough benefit to it yet to justify the extra baggage that comes with it, or, the limitations it imposes. Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From owen at delong.com Sun May 8 15:24:03 2005 From: owen at delong.com (Owen DeLong) Date: Sun, 08 May 2005 12:24:03 -0700 Subject: Pragmatism (was Re: [ppml] Re: 2005-1:Multi-national Business Enablement) In-Reply-To: <17018.25284.318407.836502@roam.psg.com> References: <1115195954.3981.16.camel@firenze.zurich.ibm.com> <17018.25284.318407.836502@roam.psg.com> Message-ID: <6FE685ABCF9502F9ECA3ECCD@imac-en0.delong.sj.ca.us> > you are likely correct here, if by > people in the west you mean the general populace, and by > people in ... you mean the monopoly ptts there > but the actual division is between the telcos, who make the > money, and the populace, which, if they see anything, tend > to see social benefit to open and less financially burdened > communication. and guess who the itu represents. The ITU represents neither of the groups you describe. The ITU represents the governments of the various nations. Unfortunately, the governments tend, quite often, to represent the monopoly PTTs better than the general populace. However, governments often have their own additional agenda as well, further complicating the ITU scenario. In any case, the least represented in almost every case are the general populace. Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From bicknell at ufp.org Mon May 9 11:12:18 2005 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 9 May 2005 11:12:18 -0400 Subject: [ppml] IPv6>>32 Message-ID: <20050509151218.GA61248@ussenterprise.ufp.org> IPv6>>32 There has been a lot of talk about IPv6 addressing, and how well it will scale. Geoff Houston (David Conrad) presented a very well researched paper at the Orlando meeting which documented the use of address space. You can read a copy of it here: http://www.arin.net/meetings/minutes/ARIN_XV/PDF/wed/Round_Table.pdf The net result is that we're poised to burn through a /1 to a /4 of the IPv6 address space in the next 60 years based on our best current guesses. This makes me extremely nervous. If anything the past shows that we are generally poor predictors of the future, and also that more often than not we predict too low. I also believe that we should be able to do much better than 60 years. IPv4 is conservatively going to last at least 30 years before it is replaced, and likely more like 40+ years. To expect that with those 30-40 years experience that we can only double the life of the next protocol is a poor target. Fortunately, there is no fundamental design flaw. The protocol is not broken, the addressing design is not broken. Indeed, the basic IPv6 architecture documents call for a "variable length subnet mask" basic implementation. If we look at RFC 3513, we see that in section 2.5 standard behavior is a variable length subnet mask sort of behavior, but later in section 2.5.4 we see where 64 bits are dedicated to the host function. See: http://www.faqs.org/rfcs/rfc3513.html What the IETF has done is separate a "host portion" and a "routing portion" on a /64 boundary. Having a fixed host portion is convenient for many reasons. It allows for autoconfiguration (a la RFC 2462). It also allows the mapping of a globally unique identifier into the address. In the IPv6 case they chose the IEEE's EUI-64 ID (see http://standards.ieee.org/regauth/oui/tutorials/EUI64.html). However, now that the host is guaranteed globally unique, it raises new privacy concerns. Indeed, these have already been recognized by the IETF, and are addressed in RFC 3041 (see http://www.faqs.org/rfcs/rfc3041.html). Without trivializing the work in the paper, the solution is basically to use randomized addresses. As there is a 64 bit space to work with the probability of collision is low, and IPv6 already requires Duplicate Address Detection (DAD) to prevent duplicates from occurring. One item not addressed in any IETF documents is that most sites will probably continue to use DHCP to assign addresses. While IPv6 allows a host to obtain an IPv6 address and determine its default gateway, it does not pass any of the other information administrators have come to rely on being in DHCP. These features include, but are not limited to DNS information, services information including boot servers, WINS servers and the like, and time servers. DHCP servers also generally update dynamic DNS, allowing the host to have a stable DNS entry. All of these point to administrators still using DHCP even where autoconfiguration is available. With that background out of the way, a picture is formed where there is 64 bits of routing information, and 64 bits of host information. Geoff's paper and proposals for HD ratio address only the 64 bits of routing information, and how we can recover bits on that side of the equation. That's good, and gains us some headroom, but leaves half of the problem unaddressed. To address the host portion, we need to look at the good parts of what the IETF has done: - Autconfiguration is a nice feature, and may be useful for some devices. - Fixed size host portions facilitate renumbering and easy administration. - Byte boundaries are good. However, we also have to look at the bad parts: - EUI-64 addresses are Globally Unique, which is not necessary for the host portion. - EUI-64 in the address raises privacy concerns. - EUI-64 depends on the continued maintenance and management of the IEEE. There is also the unknown: - It has been stated that there may be future applications developed around the fact that the host portion is globally unique. - It has been stated that it is useful to have the routing portion and the host portion be the same bit size, so that one can be embedded in the other. To preserve the good, and eliminate the bad, I propose a simple change. Shift all of the current policies to the right by 32 bits. That is, the host portion becomes a 32 bit quantity. EUI-64's would no longer be used, all hosts would simply randomly generate addresses for autoconfiguration. This is already the direction the privacy work is going. 32 bits is more than enough to allow random address selection on extremely large lans (10-50,000 addresses) with minimal collisions. The host portion would still be fixed, allowing for easy renumbering, autoconfiguration, and similar features. All other boundaries move down as well: - A /64 subnet becomes a /96 subnet. - A /48 assignment becomes a /80 assignment. - A /32 ISP allocation becomes a /64 ISP allocation. Coming back to Geoff's numbers. If he's right about a /1, the entire routing system will now fit in a /33 in 60 years, without changing the HD Ratio. Less space than we use for a single ISP today is enough to number the entire world based on our current understanding. Note also that the byte boundaries are preserved allowing for easy DNS administration and other features. More importantly, if Geoff is off by an order of magnitude (which is about 3.2 bits), under the current system we'd be short about 2 bits to number everything. With this change, we would simply consume a /29. The largest down side I can find is the unknowns listed above. It appears some people are thinking of applications that require the host portion to be globally unique, and/or applications that depend on being able to imbed a prefix in the host portion, or a host portion in the prefix portion. I have been unable to find any hard documentation on either of these applications, and I would be extremely interested in any defined uses of these behaviors. To me, a change such as this provides several safety nets: - If we're off by an order of magnitude or more, we don't run out of space. - If we've gotten this 100% wrong, we will have used around a /32 in 60 years allowing us to adjust the addressing plan without having to deploy an entirely new protocol to do it. - It allows a large amount of growth room for the unknown. - IPv6 should be able to last significantly longer than 60 years. Obviously, there are a few down sides: - The specification and code to do autoconfiguration will have to be changed. - This leaves enough free bits on the top end to further subdivide the address space (one proposal would be to assign a /24 for "country specific" prefixes, with the next 8 bits being a country identifier [there are currently 191 UN members], allowing each country to have a /32, which is now enough space to address the entire world). - ISP's that have already received a /32 (or larger) have made a successful land grab if those addresses are not reclaimed. Finally, I'd like to close with a discussion of why I'm posting this to PPML. I've spoken with a number of people about the IETF process, and what has been made abundantly clear to me is that the IETF is not even remotely interested in opening this issue for discussion. They feel the current proposal out there is the best proposal, they have fought their war to decide on it and will now fight to leave the issue sealed. I also think it's clear the community has some serious concerns with the current proposal. Geoff's paper is an illustration, and I commend him for his work on the routing portion. I think the community should also take a hard look at the host portion before it's too late. Right now IPv6 deployment is limited, and so it's not too late to make a change. Another few years may get us to a point where it is too late though, with too much inertia behind the 64 bit boundary. This is why PPML is involved. I think the community needs to think about this issue and if it is worth discussing. I'm not sure my proposal is "the best" or even good, but without a straw man to dissect the discussion will not be complete. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From paul at vix.com Mon May 9 11:30:21 2005 From: paul at vix.com (Paul Vixie) Date: Mon, 09 May 2005 15:30:21 +0000 Subject: [ppml] IPv6>>32 In-Reply-To: Your message of "Mon, 09 May 2005 11:12:18 -0400." <20050509151218.GA61248@ussenterprise.ufp.org> References: <20050509151218.GA61248@ussenterprise.ufp.org> Message-ID: <20050509153021.483D613971@sa.vix.com> > ... > To preserve the good, and eliminate the bad, I propose a simple > change. Shift all of the current policies to the right by 32 bits. > That is, the host portion becomes a 32 bit quantity. EUI-64's > would no longer be used, all hosts would simply randomly generate > addresses for autoconfiguration. This is already the direction the > privacy work is going. 32 bits is more than enough to allow random > address selection on extremely large lans (10-50,000 addresses) > with minimal collisions. i like this. > The host portion would still be fixed, > allowing for easy renumbering, autoconfiguration, and similar features. but not this. i already have some /124 subnets here. noone outside a subnet should ever make any assumptions of where the boundaries are between my isp (if any), my site/campus, my subnet, and my host. > All other boundaries move down as well: > > - A /64 subnet becomes a /96 subnet. > - A /48 assignment becomes a /80 assignment. > - A /32 ISP allocation becomes a /64 ISP allocation. as recommended boundaries, these are good. as vendor defaults, these are good. but as protocol invariants, they would be very, very bad. > The largest down side I can find is the unknowns listed above. It > appears some people are thinking of applications that require the > host portion to be globally unique, and/or applications that depend > on being able to imbed a prefix in the host portion, or a host > portion in the prefix portion. I have been unable to find any hard > documentation on either of these applications, and I would be > extremely interested in any defined uses of these behaviors. so would i. if we're going to go back to 8+8 then we should also go back to TLA's and pTLA's. there's no need for all the complexity we've built into the allocation system if the bottom 64 bits are going to be universal. > Obviously, there are a few down sides: > > - The specification and code to do autoconfiguration will have to be > changed. EUI-64 is on its way to "dead" in any case. not because of address space shortage but because autoconfiguration doesn't provide enough auditing of host come/go events. > - ISP's that have already received a /32 (or larger) have made a > successful land grab if those addresses are not reclaimed. i don't see a way to get address space back, but since we know we can't hand a /32 to every multihomer and still fit the routing table into available hardware (or fit the route churn into the available network), most existing /32's are already destined to be considered "land grabs" by future generations. > This is why PPML is involved. I think the community needs to think > about this issue and if it is worth discussing. I'm not sure my > proposal is "the best" or even good, but without a straw man to > dissect the discussion will not be complete. i agree that this is an RIR issue rather than an IETF one. the IETF is where proposals like 8+8 and TLA/pTLA come from. "how to carve it up" is not a decision that most protocol designers are qualified for or interested in. and i think this is a good proposal, with the exceptions noted above. From jordi.palet at consulintel.es Mon May 9 11:56:10 2005 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Mon, 09 May 2005 17:56:10 +0200 Subject: [ppml] IPv6>>32 In-Reply-To: <20050509151218.GA61248@ussenterprise.ufp.org> Message-ID: Hi Leo, Apart for technical issues, I will say that is too late, years late, to change the host length. There has been a strong effort in coding and deployment. May be not so much in US, but definitively in AP and Europe, which can't be changed so easily. On the other side, you're probably missing the picture of the hardware issues, I mean silicon implementations of IPv6, which mean a huge investment and years to be replaced in the market. I don't really think that's possible, and probably all those are the reasons why the people that you could have asked in IETF have in mind to avoid going into this direction. Instead, I feel much more realistic to reconsider the HD-ratio for IPv6. Final consideration, do you really believe in 50-100 years we will still be using IP at all ?. Regards, Jordi > De: Leo Bicknell > Organizaci?n: United Federation of Planets > Responder a: > Fecha: Mon, 9 May 2005 11:12:18 -0400 > Para: > Asunto: [ppml] IPv6>>32 > > > > IPv6>>32 > > There has been a lot of talk about IPv6 addressing, and how well > it will scale. Geoff Houston (David Conrad) presented a very well > researched paper at the Orlando meeting which documented the use > of address space. You can read a copy of it here: > http://www.arin.net/meetings/minutes/ARIN_XV/PDF/wed/Round_Table.pdf > > The net result is that we're poised to burn through a /1 to a /4 > of the IPv6 address space in the next 60 years based on our best > current guesses. This makes me extremely nervous. If anything the > past shows that we are generally poor predictors of the future, and > also that more often than not we predict too low. I also believe > that we should be able to do much better than 60 years. IPv4 is > conservatively going to last at least 30 years before it is replaced, > and likely more like 40+ years. To expect that with those 30-40 > years experience that we can only double the life of the next > protocol is a poor target. > > Fortunately, there is no fundamental design flaw. The protocol is > not broken, the addressing design is not broken. Indeed, the basic > IPv6 architecture documents call for a "variable length subnet mask" > basic implementation. If we look at RFC 3513, we see that in section > 2.5 standard behavior is a variable length subnet mask sort of > behavior, but later in section 2.5.4 we see where 64 bits are > dedicated to the host function. See: http://www.faqs.org/rfcs/rfc3513.html > > What the IETF has done is separate a "host portion" and a "routing > portion" on a /64 boundary. Having a fixed host portion is convenient > for many reasons. It allows for autoconfiguration (a la RFC 2462). > It also allows the mapping of a globally unique identifier into the > address. In the IPv6 case they chose the IEEE's EUI-64 ID (see > http://standards.ieee.org/regauth/oui/tutorials/EUI64.html). > > However, now that the host is guaranteed globally unique, it raises > new privacy concerns. Indeed, these have already been recognized > by the IETF, and are addressed in RFC 3041 (see > http://www.faqs.org/rfcs/rfc3041.html). Without trivializing the > work in the paper, the solution is basically to use randomized > addresses. As there is a 64 bit space to work with the probability > of collision is low, and IPv6 already requires Duplicate Address > Detection (DAD) to prevent duplicates from occurring. > > One item not addressed in any IETF documents is that most sites > will probably continue to use DHCP to assign addresses. While IPv6 > allows a host to obtain an IPv6 address and determine its default > gateway, it does not pass any of the other information administrators > have come to rely on being in DHCP. These features include, but > are not limited to DNS information, services information including > boot servers, WINS servers and the like, and time servers. DHCP > servers also generally update dynamic DNS, allowing the host to > have a stable DNS entry. All of these point to administrators still > using DHCP even where autoconfiguration is available. > > With that background out of the way, a picture is formed where there > is 64 bits of routing information, and 64 bits of host information. > Geoff's paper and proposals for HD ratio address only the 64 bits > of routing information, and how we can recover bits on that side > of the equation. That's good, and gains us some headroom, but > leaves half of the problem unaddressed. To address the host portion, > we need to look at the good parts of what the IETF has done: > > - Autconfiguration is a nice feature, and may be useful for some > devices. > - Fixed size host portions facilitate renumbering and easy > administration. > - Byte boundaries are good. > > However, we also have to look at the bad parts: > > - EUI-64 addresses are Globally Unique, which is not necessary for > the host portion. > - EUI-64 in the address raises privacy concerns. - EUI-64 depends > on the continued maintenance and management of the > IEEE. > > There is also the unknown: > > - It has been stated that there may be future applications developed > around the fact that the host portion is globally unique. > - It has been stated that it is useful to have the routing portion and > the host portion be the same bit size, so that one can be embedded in > the other. > > To preserve the good, and eliminate the bad, I propose a simple > change. Shift all of the current policies to the right by 32 bits. > That is, the host portion becomes a 32 bit quantity. EUI-64's > would no longer be used, all hosts would simply randomly generate > addresses for autoconfiguration. This is already the direction the > privacy work is going. 32 bits is more than enough to allow random > address selection on extremely large lans (10-50,000 addresses) > with minimal collisions. The host portion would still be fixed, > allowing for easy renumbering, autoconfiguration, and similar > features. > > All other boundaries move down as well: > > - A /64 subnet becomes a /96 subnet. > - A /48 assignment becomes a /80 assignment. > - A /32 ISP allocation becomes a /64 ISP allocation. > > Coming back to Geoff's numbers. If he's right about a /1, the > entire routing system will now fit in a /33 in 60 years, without > changing the HD Ratio. Less space than we use for a single ISP > today is enough to number the entire world based on our current > understanding. Note also that the byte boundaries are preserved > allowing for easy DNS administration and other features. > > More importantly, if Geoff is off by an order of magnitude (which > is about 3.2 bits), under the current system we'd be short about 2 > bits to number everything. With this change, we would simply consume > a /29. > > The largest down side I can find is the unknowns listed above. It > appears some people are thinking of applications that require the > host portion to be globally unique, and/or applications that depend > on being able to imbed a prefix in the host portion, or a host > portion in the prefix portion. I have been unable to find any hard > documentation on either of these applications, and I would be > extremely interested in any defined uses of these behaviors. > > To me, a change such as this provides several safety nets: > > - If we're off by an order of magnitude or more, we don't run out > of space. > - If we've gotten this 100% wrong, we will have used around a /32 in > 60 years allowing us to adjust the addressing plan without having to > deploy an entirely new protocol to do it. > - It allows a large amount of growth room for the unknown. > - IPv6 should be able to last significantly longer than 60 years. > > Obviously, there are a few down sides: > > - The specification and code to do autoconfiguration will have to be > changed. > - This leaves enough free bits on the top end to further subdivide the > address space (one proposal would be to assign a /24 for "country > specific" prefixes, with the next 8 bits being a country identifier > [there are currently 191 UN members], allowing each country to have a > /32, which is now enough space to address the entire world). > - ISP's that have already received a /32 (or larger) have made a > successful land grab if those addresses are not reclaimed. > > Finally, I'd like to close with a discussion of why I'm posting > this to PPML. I've spoken with a number of people about the IETF > process, and what has been made abundantly clear to me is that the > IETF is not even remotely interested in opening this issue for > discussion. They feel the current proposal out there is the best > proposal, they have fought their war to decide on it and will now > fight to leave the issue sealed. > > I also think it's clear the community has some serious concerns > with the current proposal. Geoff's paper is an illustration, and > I commend him for his work on the routing portion. I think the > community should also take a hard look at the host portion before > it's too late. Right now IPv6 deployment is limited, and so it's > not too late to make a change. Another few years may get us to a > point where it is too late though, with too much inertia behind > the 64 bit boundary. > > This is why PPML is involved. I think the community needs to think > about this issue and if it is worth discussing. I'm not sure my > proposal is "the best" or even good, but without a straw man to > dissect the discussion will not be complete. > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org ************************************ Barcelona 2005 Global IPv6 Summit Registration open. Information available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From memsvcs at arin.net Mon May 9 12:27:35 2005 From: memsvcs at arin.net (Member Services) Date: Mon, 09 May 2005 12:27:35 -0400 Subject: [ppml] Proposed Policy: IPv6 HD ratio Message-ID: <427F8F77.8070501@arin.net> ARIN received the following proposed policy. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List and being placed on ARIN's website. The ARIN Advisory Council will review the proposal and within ten working days may decide to: 1) support the proposal as is, 2) work with the author to clarify, divide or combine one or more policy proposals, or 3) not support the policy proposal. If the AC supports the proposal or reaches an agreement to work with the author, then the proposal will be posted as a formal policy proposal to the Public Policy Mailing List and it will be presented at the Public Policy Meeting. If the AC does not support the proposal, then the author may elect to use the petition process to advance the proposal. If the author elects not to petition or the petition fails, then the proposed policy will be considered closed. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/ipep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal Name: IPv6 HD ratio Author: Andrew Dul Policy term: permanent Policy statement: Change HD ratio used for IPv6 allocations to 0.94 This would modify sections 6.5.2.2 & 6.7 (including the HD-ratio to percentage table) of the NRPM. Rationale: Recent research has shown that based upon certain growth models the current IPv6 allocation policy using the HD ratio of 0.8 will allocate between a /1 and /4 of Ipv6 address space over the period of about 60 years. http://www.ietf.org/internet-drafts/draft-huston-ipv6-hd-metric-00.txt By changing the HD ratio to 0.94, this would require LIRs to have a higher utilization of the /48s that are assigned to end sites before being able to obtain additional allocations. This policy would change the threshold for an LIR holding a /32 from approximately 11% to 51%. An LIR with a /20 would have a utilized percentage of approximately 31% vs. the current 2%. This policy may also prevent the hoarding of IPv6 addresses by current organizations with large customer bases, but no substantial current IPv6 network. Timetable for implementation: Within 30 days of ratification by the BoT. From memsvcs at arin.net Mon May 9 12:27:14 2005 From: memsvcs at arin.net (Member Services) Date: Mon, 09 May 2005 12:27:14 -0400 Subject: [ppml] Proposed Policy: AfriNIC Recognition Policy Message-ID: <427F8F62.3090204@arin.net> ARIN received the following proposed policy. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List and being placed on ARIN's website. The ARIN Advisory Council will review the proposal and within ten working days may decide to: 1) support the proposal as is, 2) work with the author to clarify, divide or combine one or more policy proposals, or 3) not support the policy proposal. If the AC supports the proposal or reaches an agreement to work with the author, then the proposal will be posted as a formal policy proposal to the Public Policy Mailing List and it will be presented at the Public Policy Meeting. If the AC does not support the proposal, then the author may elect to use the petition process to advance the proposal. If the author elects not to petition or the petition fails, then the proposed policy will be considered closed. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/ipep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal Name: AfriNIC Recognition Policy Author: Andrew Dul Policy term: permanent Policy statement: Remove section 4.8 entitled "Policy for the African Portion of the ARIN Region" of the NRPM. Rationale: The ARIN BoT recently suspended section 4.8 of the NRPM upon recognition of AfriNIC as an RIR by ICANN. Section 4.8 of the NRPM applied only to areas of the ARIN region that are now covered by AfriNIC. Timetable for implementation: Within 30 days of ratification by the BoT. From Michael.Dillon at radianz.com Mon May 9 12:39:07 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Mon, 9 May 2005 17:39:07 +0100 Subject: [ppml] IPv6>>32 In-Reply-To: <20050509151218.GA61248@ussenterprise.ufp.org> Message-ID: > The net result is that we're poised to burn through a /1 to a /4 > of the IPv6 address space in the next 60 years based on our best > current guesses. This makes me extremely nervous. I'm sorry but I cannot understand this sentiment at all. IPv4 has not even been deployed for 60 years yet and nevertheless we still have spare addresses and we have created and deployed an IPv4 replacement. I strongly suspect that the engineers of the next generation, 30-40 years from now, can do the same thing if it proves necessary. And with the benefit of hindsight that we cannot have (i.e. a view of the next 30-40 years) they will do a better job of this than we can. ARIN should completely avoid this type of policymaking. It is not the job of ARIN or any RIR to drive today's policy based upon the hypothetical needs of people 60 years from now. In any case, nobody will be here in 60 years to use any network protocols. In case you hadn't noticed, an asteroid will pass close to the earth in 2029 and if that does not destroy modern civilization, then it's return some few years later will likely do so. If people today insist on preparing the groundwork for the people 60 years in the future, they would do better to set up classes in stone age technology, identifying metallic ores and primitive smelting technology. It will be of more concrete use to the future than attempting to build the present on a fantasy that is 60 years too early. > What the IETF has done is separate a "host portion" and a "routing > portion" on a /64 boundary. And our job is not to change IETF designs. > One item not addressed in any IETF documents is that most sites > will probably continue to use DHCP to assign addresses. Sorry, but I am not going to run a DHCP server on my mobile phone, on my fridge, on my TV or my stereo or my home lighting system. I won't be running a DHCP server on my home environment monitors, on my furnace or on any of my automobile networks either. I won't be running a DHCP server on my shower control system or my bathtub or my heated toilet with robotic sanitary arm. (Don't laugh, this toilet is already on the market in Japan). In short, I think that you are starting from wrong premises in your use of the word "host" and "site". IPv6 is not the same as IPv4. This is not your father's IP protocol. > To preserve the good, and eliminate the bad, I propose a simple > change. Shift all of the current policies to the right by 32 bits. > That is, the host portion becomes a 32 bit quantity. EUI-64's > would no longer be used, all hosts would simply randomly generate > addresses for autoconfiguration. As I said, our job is not to change IETF designs. You are on the wrong list. You also fail to see why I do *NOT* want privacy on all my IPv6 attachment points. When my stove wants to use my Internet connection to send a message back to the factory with usage statistics and performance parameters, I am happy to let it use the IPv6 EUI-64 that the factory encoded in the device. Of course, I am concerned with privacy so I will route all this traffic through my time-lapse proxy. This proxy runs on my mobile phone. When a device in my home sends traffic through the proxy, the phone network stores it on my 128 gigabyte SD card (I carry around Russian TV series to watch on the train). When I am away from home, perhaps on the train or walking down a street somewhere, I tell my phone network to route the time-lapse proxy traffic out of a nearby Wi-Fi (802.11z3) network rather than through my mobile provider. If you can't get your head around the concepts that I have just described, then perhaps you should not be planning for situations which will not arise for the next 60 years. By the way, the phone network that I described does not look like a modern cellphone. Only the handset is similar to a cellphone but it is lighter because is is just a handset. The guts of the phone network is in my jacket. I have the main server/transmitter in the phone pocket (you know, most jackets have a special pocket to hold your server/tran) and the antenna is built into the jacket itself. For handsfree, when I don't mind looking stupid in public, I use the built-in collar mike and flip up one of the collar earphones. When my jacket is hanging in the office, the short range BlueZeeTooth transceiver in the handset takes care of network connectivity. And I have a pocket computer that is usually plugged into the computer pocket of the jacket when I'm not using it. Yes, it also has BlueZeeTooth but that doesn't work so good when I'm downloading TV shows to watch later. I have a terabyte compact flash card in the pocket computer. Yes, things will not be the same in 60 years from now. > - If we're off by an order of magnitude or more, we don't run out > of space. I think it would be a good thing to run out of IPv6 space in 60 years. It would provide engineers of the future with a great object lesson in humility. They will know firsthand that an engineer cannot always predict the future with confidence and that some problems just cannot be solved today but must wait for tomorrow. > Finally, I'd like to close with a discussion of why I'm posting > this to PPML. I've spoken with a number of people about the IETF > process, and what has been made abundantly clear to me is that the > IETF is not even remotely interested in opening this issue for > discussion. Have you ever heard of something called "working code". There are hundreds of people making rather smaller changes to IP (v4 and v6) than you have described and they are actually coding these changes into running code, either in network simulators or on real boxes that they experiment with in the lab. Why should the IETF listen to an idea that has no running code to back it up? > This is why PPML is involved. I think the community needs to think > about this issue and if it is worth discussing. I'm not sure my > proposal is "the best" or even good, but without a straw man to > dissect the discussion will not be complete. Well, you can see my opinions. I don't think this is worth discussing in PPML and I think this particular straw man is actually made out of synthetic straw with the same chemical composition as the membrane covering the zeppelin airships of the 30's. This same material was used in the United States as the fuel for early ballistic missiles and spaceship engines. --Michael Dillon From Ed.Lewis at neustar.biz Mon May 9 12:42:04 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Mon, 9 May 2005 12:42:04 -0400 Subject: Pragmatism (was Re: [ppml] Re: 2005-1:Multi-national Business Enablement) In-Reply-To: References: <1115195954.3981.16.camel@firenze.zurich.ibm.com> Message-ID: At 11:15 -0700 5/4/05, David Conrad wrote: >Actually, I believe the ITU position (if it can be said to have a position) >is that telecommunications (which includes the Internet) is a national >sovereignty issue and nations have the right and responsibility to regulate >and/or charge for whatever they feel appropriate to suit their national >interests. While people in "the West" may feel this is simply wrong, I >suspect you'd get strenuous arguments from people in countries where >telecommunication settlements account for significant portions of their >country's GNP. What follows is a question that reads like a statement - with the question being whether or not my attempt to rewrite the above is "hotter" or "colder" from the truth. The ITU is a body formulated along national sovereignty lines to manage one critical resource of governance, namely telecommunications. Aligning issues to national boundaries fits with the regulatory model of the world held by the body, as this fits with legal, judicial, financial, etc., alignments. If the Internet has yet to scale one more order of magnitude (from about the estimated 1 billion users to the estimated population of the earth at 7 billion), the resources that are already regulated along national sovereignty boundaries will have to be tapped - and these will have to be tapped in accordance with "their" rules. IOW, considering all of the resources used to build the Internet today - imagine needing to consume the same 9 times over. Where do these resources come from? >I believe even a perception profligate waste of address space such that it can >be seen as even possible that we'll run out of address space greatly >strengthens the hand of folks who believe the IPv6 address space should be >chunked up and assigned to countries. As such, I personally tend to be a bit >conservative when reviewing IPv6 address allocation policies, specifically >trying to avoid mistakes (such as fixed network mask lengths) that have been >made in the past. Especially because the ITU's managed address space has not run out. IPv4's is allegedly (prompting IPv6), so if we deplete v6 also the ITU can claim "we've never exhausted an address pool but they have - twice!" -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From Ed.Lewis at neustar.biz Mon May 9 12:54:55 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Mon, 9 May 2005 12:54:55 -0400 Subject: [ppml] IPv6>>32 In-Reply-To: <20050509151218.GA61248@ussenterprise.ufp.org> References: <20050509151218.GA61248@ussenterprise.ufp.org> Message-ID: At 11:12 -0400 5/9/05, Leo Bicknell wrote: > IPv6>>32 > >There has been a lot of talk about IPv6 addressing, and how well >it will scale. Geoff Houston (David Conrad) presented a very well >researched paper at the Orlando meeting which documented the use >of address space. You can read a copy of it here: >http://www.arin.net/meetings/minutes/ARIN_XV/PDF/wed/Round_Table.pdf At RIPE last week Geoff gave a follow-up presentation that was spawned by the round table at ARIN. In the presentation he presented other ways of perhaps squeezing a few more bits of "reserve." The report is available here: http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary-wed-ipv6-roundtable-report.pdf -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From bicknell at ufp.org Mon May 9 13:09:45 2005 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 9 May 2005 13:09:45 -0400 Subject: [ppml] IPv6>>32 In-Reply-To: References: <20050509151218.GA61248@ussenterprise.ufp.org> Message-ID: <20050509170945.GA67090@ussenterprise.ufp.org> In a message written on Mon, May 09, 2005 at 05:56:10PM +0200, JORDI PALET MARTINEZ wrote: > Apart for technical issues, I will say that is too late, years late, to > change the host length. > > There has been a strong effort in coding and deployment. May be not so much > in US, but definitively in AP and Europe, which can't be changed so easily. > > On the other side, you're probably missing the picture of the hardware > issues, I mean silicon implementations of IPv6, which mean a huge investment > and years to be replaced in the market. While I can't argue the deployment aspect, as there is an intertia there, the software and hardware aspect I can address. Already per RFC 3177, software and hardware limits on prefix lengths are verboten. I quote from section 4: - We are highly confident in the validity of this analysis, based on experience with IPv4 and several other address spaces, and on extremely ambitious scaling goals for the Internet amounting to an 80 bit address space *per person*. Even so, being acutely aware of the history of under-estimating demand, the IETF has reserved more than 85% of the address space (i.e., the bulk of the space not under the 001 Global Unicast Address prefix). Therefore, if the analysis does one day turn out to be wrong, our successors will still have the option of imposing much more restrictive allocation policies on the remaining 85%. However, we must stress that vendors should not encode any of the boundaries discussed here either in software nor hardware. Under that assumption, should we ever have to use the remaining 85% of the address space, such a migration may not be devoid of pain, but it should be far less disruptive than deployment of a new version of IP. Note that they stress vendors should not encode any of the boundaries in software or hardware. Those writing software, or spinning silicon with built in limitations are already violating the RFC's, even if no changes are made at this time. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From paul at vix.com Mon May 9 13:10:16 2005 From: paul at vix.com (Paul Vixie) Date: Mon, 09 May 2005 17:10:16 +0000 Subject: [ppml] IPv6>>32 In-Reply-To: Your message of "Mon, 09 May 2005 17:56:10 +0200." References: Message-ID: <20050509171016.07E6B13971@sa.vix.com> jordi wrote, in response to leo: > Apart for technical issues, I will say that is too late, years late, > to change the host length. > > There has been a strong effort in coding and deployment. May be not so > much in US, but definitively in AP and Europe, which can't be changed > so easily. with respect, i don't see this as directly relevant. i am aware of sites that use static addressing or dhcp6 because of various perceived problems with EUI64 autoconfiguration. i am therefore certain that EUI64 can be gone without in at least some situations. therefore an RIR policy of the form "if you can live without EUI64, you can have PI space" would likely have significant uptake. > On the other side, you're probably missing the picture of the hardware > issues, I mean silicon implementations of IPv6, which mean a huge > investment and years to be replaced in the market. i'm still waiting for someone to identify a router that either works better or goes faster or costs less or can handle more subnets if you use /64's per LAN rather than /96's. my own testing with M20's and 7206VXR's says that it makes no difference, but i know there are more modern routers and i'm waiting for someone to identify one that cares about your prefix size. ("one" might not be enough to sway my opinion, but it'd be a beginning.) > I don't really think that's possible, and probably all those are the > reasons why the people that you could have asked in IETF have in mind > to avoid going into this direction. the people actively involved in designing protocols via the IETF just don't care about economics, as a rule. "what it would look like it deployed" was not a consideration with classful IPv4 ("how are we going to *route* 16 million class c's?"), or DNSSEC ("if a zone can't be secured until its parent is secured, and if the parent has no incentive, *then* what?") or in IPv6 ("we've got 128 bits, let's burn half of them on something nobody cares about that has unforeseen privacy effects"), or A6/DNAME ("let's put *even* *more* pressure on the size of the global routing table, shall we?"). > Instead, I feel much more realistic to reconsider the HD-ratio for > IPv6. i think that this should (and will) also be done. > Final consideration, do you really believe in 50-100 years we will > still be using IP at all ?. my final consideration is, since the size of the ipv6 installed base is very much smaller and very much more fluid/serviceable than the size of the ipv4 installed base, why are we assuming we can forklift-upgrade the latter but not the former? paul From randy at psg.com Mon May 9 13:21:20 2005 From: randy at psg.com (Randy Bush) Date: Mon, 9 May 2005 07:21:20 -1000 Subject: [ppml] IPv6>>32 References: <20050509151218.GA61248@ussenterprise.ufp.org> Message-ID: <17023.39952.836316.636731@roam.psg.com> > There has been a strong effort in coding and deployment. May be not so > much in US, but definitively in AP and Europe, which can't be changed so > easily. jordi, the vendors were specificially told not to hard code ANY boundaries. this should not be a problem. randy From jordi.palet at consulintel.es Mon May 9 14:08:13 2005 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Mon, 09 May 2005 20:08:13 +0200 Subject: [ppml] IPv6>>32 In-Reply-To: <20050509170945.GA67090@ussenterprise.ufp.org> Message-ID: We have lots of examples of people don't following RFCs, and I don't mean I agree with that, but is real life. Keeping 128 bits in the lookup tables of core routers has been seen by some chip set vendors as not useful, very expensive and time consuming, while they only handle actually 64 bits routes in that part of the network. Those routers don't expect to see the 64 bits of the host field to be required for the routing, because they look into the aggregated route towards the PoP, access network, or whatever is next. I think this 64 bits usage is not in conflict with RFC3177, but actually it sound to me that this part of the text in the RFC3177 could require a clarification. The point is that if those routers are forced to route, in the core, per 128 bits, then the trouble is a different one, of a much bigger magnitude. Regards, Jordi > De: Leo Bicknell > Organizaci?n: United Federation of Planets > Responder a: > Fecha: Mon, 9 May 2005 13:09:45 -0400 > Para: > Asunto: Re: [ppml] IPv6>>32 > > In a message written on Mon, May 09, 2005 at 05:56:10PM +0200, JORDI PALET > MARTINEZ wrote: >> Apart for technical issues, I will say that is too late, years late, to >> change the host length. >> >> There has been a strong effort in coding and deployment. May be not so much >> in US, but definitively in AP and Europe, which can't be changed so easily. >> >> On the other side, you're probably missing the picture of the hardware >> issues, I mean silicon implementations of IPv6, which mean a huge investment >> and years to be replaced in the market. > > While I can't argue the deployment aspect, as there is an intertia > there, the software and hardware aspect I can address. Already per > RFC 3177, software and hardware limits on prefix lengths are verboten. > I quote from section 4: > > - We are highly confident in the validity of this analysis, based > on experience with IPv4 and several other address spaces, and > on extremely ambitious scaling goals for the Internet amounting > to an 80 bit address space *per person*. Even so, being > acutely aware of the history of under-estimating demand, the > IETF has reserved more than 85% of the address space (i.e., the > bulk of the space not under the 001 Global Unicast Address > prefix). Therefore, if the analysis does one day turn out to > be wrong, our successors will still have the option of imposing > much more restrictive allocation policies on the remaining 85%. > However, we must stress that vendors should not encode any of > the boundaries discussed here either in software nor hardware. > Under that assumption, should we ever have to use the remaining > 85% of the address space, such a migration may not be devoid of > pain, but it should be far less disruptive than deployment of a > new version of IP. > > Note that they stress vendors should not encode any of the boundaries > in software or hardware. Those writing software, or spinning silicon > with built in limitations are already violating the RFC's, even if > no changes are made at this time. > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org ************************************ Barcelona 2005 Global IPv6 Summit Registration open. Information available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From tvest at pch.net Mon May 9 14:07:48 2005 From: tvest at pch.net (Tom Vest) Date: Mon, 9 May 2005 14:07:48 -0400 Subject: Pragmatism (was Re: [ppml] Re: 2005-1:Multi-national Business Enablement) In-Reply-To: References: <1115195954.3981.16.camel@firenze.zurich.ibm.com> Message-ID: On May 9, 2005, at 12:42 PM, Edward Lewis wrote: > > If the Internet has yet to scale one more order of magnitude (from > about the estimated 1 billion users to the estimated population of the > earth at 7 billion), the resources that are already regulated along > national sovereignty boundaries will have to be tapped - and these > will have to be tapped in accordance with "their" rules. IOW, > considering all of the resources used to build the Internet today - > imagine needing to consume the same 9 times over. Where do these > resources come from? > Especially because the ITU's managed address space has not run out. > IPv4's is allegedly (prompting IPv6), so if we deplete v6 also the ITU > can claim "we've never exhausted an address pool but they have - > twice!" > -- Hi Ed, Trying to parse your question; hoping for further assistance... First, the only slightly tongue-in-cheek response: do you think the ITU would be (or be perceived to be) doing as well with their number management if 8-9 new sovereign states were added to the international system every day? That's the situation that the RIRs face, because -- at least in some places -- the barriers to becoming a network operator are relatively low. In perhaps half of the world -- precisely the half where all resources are *not* strictly aligned with national boundaries -- once "mere subjects" (read: customers) have broad latitude to secede whenever they perceive that they can (1) make money, (2) save money, or (3) fulfill any purpose important enough to justify *to themselves* the necessary investment. We see an average of nine or so such "secessions" in the routing table every day -- and *they* are the primary source and vehicle of Internet expansion, statistically. New networks are the primary source of new Internet growth -- users, uses, usage, etc. How many new sovereign national entities do you see being created every day -- every century? No so many, because existing political entities prefer a status quo that guarantees them power over their existing resource base, to a system where those resources may get eroded through progressive devolution/decentralization. There have always been arguments that in many cases/places a kind of sovereign-level devolution/reorganizing could lead to a better, "more efficient" international system -- but almost no one's buying. I'll spare you the academic citations, but the point is that "national resource alignment" is essentially a conservative strategy, not a strategy for growth. Strict national resource alignment is not an efficient way of organizing a system that grows in response to transnational supply and demand -- like the conventional economy, like the Internet. It is, however, a good strategy for perpetuating national power. Shameless plug: http://www.pch.net/resources/papers/the-wealth-of-networks/Vest- WoN at SIMS-DLS-050316.pdf TV From paul at vix.com Mon May 9 14:16:53 2005 From: paul at vix.com (Paul Vixie) Date: Mon, 09 May 2005 18:16:53 +0000 Subject: [ppml] IPv6>>32 In-Reply-To: Your message of "Mon, 09 May 2005 20:08:13 +0200." References: Message-ID: <20050509181653.EA80313971@sa.vix.com> jordi wrote, again in response to leo, as follows: > We have lots of examples of people don't following RFCs, and I don't > mean I agree with that, but is real life. > > Keeping 128 bits in the lookup tables of core routers has been seen by > some chip set vendors as not useful, very expensive and time > consuming, while they only handle actually 64 bits routes in that part > of the network. no doubt. > Those routers don't expect to see the 64 bits of the host field to be > required for the routing, because they look into the aggregated route > towards the PoP, access network, or whatever is next. what routers? you lost me on that last part. which router/routers, exactly? paul From david.conrad at nominum.com Mon May 9 14:37:43 2005 From: david.conrad at nominum.com (David Conrad) Date: Mon, 9 May 2005 11:37:43 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: References: Message-ID: <9F7279D9-0B98-4726-A666-94C917C09DAE@nominum.com> Michael, On May 9, 2005, at 9:39 AM, Michael.Dillon at radianz.com wrote: >> The net result is that we're poised to burn through a /1 to a /4 >> of the IPv6 address space in the next 60 years based on our best >> current guesses. This makes me extremely nervous. > I'm sorry but I cannot understand this sentiment at all. For me, the sentiment derives from the discomfort of knowingly deploying something that is (arguably) broken. I suspect if you went back in time and asked Vint or Bob Kahn or any of the other original net geeks if they thought IPv4 would ever really be at risk of running out, they'd laugh at you. > ARIN should completely avoid this type of policymaking. It is > not the job of ARIN or any RIR to drive today's policy based upon > the hypothetical needs of people 60 years from now. Hmm. I would've thought this would be pretty close to the actual definition of "stewardship". > And our job is not to change IETF designs. No, market and operational realities change IETF designs as they also change RIR policies. > Sorry, but I am not going to run a DHCP server on my mobile > phone, on my fridge, on my TV or my stereo or my home lighting > system. Well, you might on your phone if it is the gateway for your personal area network, connecting all the biosensors and other gadgets attached to you. You probably wouldn't run a _server_ on end devices like your TV, however I suspect you might on your residential gateway (s). > Have you ever heard of something called "working code". ... > Why should the IETF listen to an idea that has no running code to > back it up? While I might argue the IETF long ago gave up on running code, I think the issue here is one of perception. Some might argue that due to the fact there is very little actual operational experience with IPv6 and, in particular, essentially no operational experience with scaling IPv6 anywhere near what it is expected to be able to do, that the "working code" of address allocation for IPv6 has not yet been defined. What I might suggest we have is an evolving working group draft that we're just now getting to actually implementing (and have already found some warts)... Rgds, -drc From jordi.palet at consulintel.es Mon May 9 14:40:25 2005 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Mon, 09 May 2005 20:40:25 +0200 Subject: [ppml] IPv6>>32 In-Reply-To: <20050509181653.EA80313971@sa.vix.com> Message-ID: I mean core routers, not access routers, not CPEs. Regards, Jordi > De: Paul Vixie > Responder a: > Fecha: Mon, 09 May 2005 18:16:53 +0000 > Para: > Asunto: Re: [ppml] IPv6>>32 > > jordi wrote, again in response to leo, as follows: > >> We have lots of examples of people don't following RFCs, and I don't >> mean I agree with that, but is real life. >> >> Keeping 128 bits in the lookup tables of core routers has been seen by >> some chip set vendors as not useful, very expensive and time >> consuming, while they only handle actually 64 bits routes in that part >> of the network. > > no doubt. > >> Those routers don't expect to see the 64 bits of the host field to be >> required for the routing, because they look into the aggregated route >> towards the PoP, access network, or whatever is next. > > what routers? you lost me on that last part. which router/routers, exactly? > > paul ************************************ Barcelona 2005 Global IPv6 Summit Registration open. Information available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owen at delong.com Mon May 9 15:41:14 2005 From: owen at delong.com (Owen DeLong) Date: Mon, 09 May 2005 12:41:14 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: References: Message-ID: > Final consideration, do you really believe in 50-100 years we will still > be using IP at all ?. Yes, but, the more I learn about the current state of IPv6, the more I think it will either be IPv4 or whatever replaces IPv6. Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From gih at apnic.net Mon May 9 15:53:04 2005 From: gih at apnic.net (Geoff Huston) Date: Tue, 10 May 2005 05:53:04 +1000 Subject: [ppml] IPv6>>32 In-Reply-To: References: <20050509151218.GA61248@ussenterprise.ufp.org> Message-ID: <6.0.1.1.2.20050510054214.032f0020@kahuna.telstra.net> >Final consideration, do you really believe in 50-100 years we will still be >using IP at all ?. This is a central question to the entire topic of IPv6. My best answer is "I really don't know" which, logically, admits the possibility of "yes". Some technologies are "sticky" simply because they work and the cost of universal adoption of alternatives are just too high. So over a century later we still use the internal consumption engine, decades later we still use amplitude modulated radio signalling, and so on. It may well be the case that packet switching is one of these sticky technologies, in which case the address architecture is indeed a critical issue. I'm not sure that we should be in the business of built in obsolescence, and certainly not if we can buy the additional time without undue pain. The presentation at ARIN XV looked at the HD ratio and the subnet boundary as potential points of variation in the address plan that could admit more efficient utilization without alteration to the overall IPv6 architecture and without undue need to alter existing equipment, software or deployments such as they are. Its certainly the case that alteration of the length of the global identifier could admit vastly greater address utilization but of course the question here is, simply, whether the gain is worth the pain. Geoff From owen at delong.com Mon May 9 16:02:38 2005 From: owen at delong.com (Owen DeLong) Date: Mon, 09 May 2005 13:02:38 -0700 Subject: Pragmatism (was Re: [ppml] Re: 2005-1:Multi-national Business Enablement) In-Reply-To: References: <1115195954.3981.16.camel@firenze.zurich.ibm.com> Message-ID: > Especially because the ITU's managed address space has not run out. Only because ITU's managed address space is not fixed in length. It's easy not to run out of places to the right of the decimal. What's hard is doing it in a way that can be globally routed on a packet switched network. The ITU has never managed a packet switched network or resources in support of a packet switched network, so, this is not an apples-to-apples comparison. The ITU, to my knowledge, regulates two principle forms of addresses, and, actually, the ITU only regulates the PREFIX portion in both cases: Radio Call Signs Telephone Numbers In the case of Radio Call signs, for example, the ITU has assigned to the US all callsigns starting with the letters A, K, N, and W. I think there are some holes in the US "K" allocation for some of the Pacific Islands, but, I don't have my ARRL map handy at the moment. Anyway, the key here is that the US can put whatever it wants after the A, K, N, or W to make a callsign. If the US runs out of callsigns that look like W6X, the US creates callsigns that look like W6ZX, WA6ZX, WB6RFZ, etc. If they run out of those, then, they can create callsigns that look like KGRDE3912834EAEFKK3KJ3141JHJ if they so choose, so, the only way for the ITU to run out of callsigns is to allocate all the prefixes. However, the way the ITU has prevented this is that as they started to get short on letters to hand out, they stopped handing out letters, and, started handing out prefixes like VK4, VE, etc. Again, since they can make the prefix as long as they choose any time they choose, it's easy to not run out. In the case of telephone numbers, the ITU only allocates country codes. Country codes can also be expanded to any length the ITU chooses as needed. For example, the US+Canada is country code 1. Russia is 7. Other countries have 2 digit (and, if memory serves, some even have 3 digit codes). > IPv4's is allegedly (prompting IPv6), so if we deplete v6 also the ITU > can claim "we've never exhausted an address pool but they have - twice!" They could, but, they'd be making a very specious claim about completely unrelated issues. Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From alh-ietf at tndh.net Mon May 9 16:01:34 2005 From: alh-ietf at tndh.net (Tony Hain) Date: Mon, 9 May 2005 13:01:34 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: <9F7279D9-0B98-4726-A666-94C917C09DAE@nominum.com> Message-ID: <20050509200142.4062D145441@smtp2.arin.net> David Conrad wrote: > Michael, > > On May 9, 2005, at 9:39 AM, Michael.Dillon at radianz.com wrote: > >> The net result is that we're poised to burn through a /1 to a /4 > >> of the IPv6 address space in the next 60 years based on our best > >> current guesses. This makes me extremely nervous. > > I'm sorry but I cannot understand this sentiment at all. > > For me, the sentiment derives from the discomfort of knowingly > deploying something that is (arguably) broken. I suspect if you went > back in time and asked Vint or Bob Kahn or any of the other original > net geeks if they thought IPv4 would ever really be at risk of > running out, they'd laugh at you. Burning through a /4 in 50 years is consistent with original assumptions, as is the point that we have 3/4 of the space set aside for different allocation approaches if the first proved wrong. It is not that people didn't learn anything from the first time around, it is just that some want to be more conservative than others. > > > ARIN should completely avoid this type of policymaking. It is > > not the job of ARIN or any RIR to drive today's policy based upon > > the hypothetical needs of people 60 years from now. > > Hmm. I would've thought this would be pretty close to the actual > definition of "stewardship". Yes stewardship is about resource management so that it is available in the future, but is also about allowing current use of the resource in ways that don't artificially constrain innovation to past practice. We have to get past the brain-dead concept that an ISP will micro-manage every connected appliance on the customer network. > > > And our job is not to change IETF designs. > > No, market and operational realities change IETF designs as they also > change RIR policies. There is a place for RIR policy to feed back into the design process, and that has already happened with the removal of TLD/NLD designations. That said, there does not appear to be a consistent mechanism for design goals to be propagated across the RIRs. The IETF ends up putting a stake in the ground and the RIRs complain about moving the stake without appreciation for why a specific set of trade-offs was agreed on. > > > Sorry, but I am not going to run a DHCP server on my mobile > > phone, on my fridge, on my TV or my stereo or my home lighting > > system. > > Well, you might on your phone if it is the gateway for your personal > area network, connecting all the biosensors and other gadgets > attached to you. You probably wouldn't run a _server_ on end devices > like your TV, however I suspect you might on your residential gateway > (s). It will undoubtedly take most of a generation to change the mindset, but DHCP is not a requirement for operating a network. Many ISP and enterprise operators have come to rely on that tool as part of their access control infrastructure, but that does not turn it into a required protocol. The only thing that is required is that a node have an address in the range of the local subnet and that there is a router which can get bits between that subnet and others. > > > Have you ever heard of something called "working code". > ... > > Why should the IETF listen to an idea that has no running code to > > back it up? > > While I might argue the IETF long ago gave up on running code, I Well some would argue that past IESG's chose to ignore the running code and the practice of letting the market decide in favor of dictating how networks should be run, but I digress... > think the issue here is one of perception. Some might argue that due > to the fact there is very little actual operational experience with > IPv6 and, in particular, essentially no operational experience with > scaling IPv6 anywhere near what it is expected to be able to do, that > the "working code" of address allocation for IPv6 has not yet been > defined. What I might suggest we have is an evolving working group > draft that we're just now getting to actually implementing (and have > already found some warts)... I don't hear anyone arguing that we need to keep the current H-D ratio assumptions. In particular it is RIR policy to use that measure, so it could be RIR policy to use another value or approach. The argument that it only gets back 3 bits ignores the impact where your 60 year projection would become 480 years. I am not opposed to values other than /48 for customer connects: http://www.ietf.org/internet-drafts/draft-hain-prefix-consider-00.txt (comments?) but I am opposed to claiming there is a threat to running out if we don't revert to the IPv4 practice of minimal/per-host allocations. People need a way to switch providers without concern that they will have to change their subnet plan. Some consistent policy buckets will allow them to move to like service and avoid the pain of a redesign. Aligning those buckets with ptr zone files will allow each customer's ddns to manage the local appliances and attach itself to the global tree as a single trusted agent aggregating the morass behind it. In any case it is wrong for an ISP to assume that the device at the end of a particular link is an endpoint handset. The upstream radio link is just that, a link with interesting characteristics, and the device at the end is just as likely to be a router as an endpoint. It is likewise wrong to assume that a single subnet is sufficient for a customer since we know multi-media bridging is fundamentally broken and media types are evolving all the time. These are issues that need to be addressed by any allocation policy, but the FUD simply states that we are wasting space because we are allocating more than we have in the past. At the point of evaluation 64 bits was sufficient to meet the design goals of the IPv4 replacement, but at the front of the bubble there were concerns about sufficient hierarchy, so the whole 64 bits was given to routing. Now we find that the greedy routing side is jealous that the host side gets just as much space and is looking for any reason to grab more. There is no need to revisit the 64 split at this point. Even if we are wrong 3/4 of the space is still there for other approaches and with 60 years to burn through a /4 we would still have a few decades to argue over a different approach before the current /3 is consumed. If the H-D ratio policies were changed to require more efficiency from larger organizations we would have a few centuries to argue, so we should make that change quickly and buy ourselves some time to get a century or two of running code before we get too hung up on micro-managing the customer end of the allocation. Tony > > Rgds, > -drc From billd at cait.wustl.edu Mon May 9 16:05:07 2005 From: billd at cait.wustl.edu (Bill Darte) Date: Mon, 9 May 2005 15:05:07 -0500 Subject: [ppml] Proposed Policy: AfriNIC Recognition Policy Message-ID: Just a note in case anyone is wondering: The historical context and record of this policy element will be entered into the NRPM Change Log (http://www.arin.net/policy/nrpm_changelog.html) upon adoption. Bill Darte ARIN AC > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Member Services > Sent: Monday, May 09, 2005 11:27 AM > To: ppml at arin.net > Subject: [ppml] Proposed Policy: AfriNIC Recognition Policy > > > ARIN received the following proposed policy. In accordance > with the ARIN Internet Resource Policy Evaluation Process, > the proposal is being posted to the ARIN Public Policy > Mailing List and being placed on ARIN's website. > > The ARIN Advisory Council will review the proposal and within > ten working days may decide to: > 1) support the proposal as is, > 2) work with the author to clarify, divide or combine one or > more policy proposals, or > 3) not support the policy proposal. > > If the AC supports the proposal or reaches an agreement to > work with the author, then the proposal will be posted as a > formal policy proposal to the Public Policy Mailing List and > it will be presented at the Public Policy Meeting. If the AC > does not support the proposal, then the author may elect to > use the petition process to advance the proposal. If the > author elects not to petition or the petition fails, then the > proposed policy will be considered closed. > > The ARIN Internet Resource Policy Evaluation Process can be > found at: http://www.arin.net/policy/ipep.html > > Mailing list subscription information can be found at: > http://www.arin.net/mailing_lists/index.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ### * ### > > > Policy Proposal Name: AfriNIC Recognition Policy > > Author: Andrew Dul > > Policy term: permanent > > Policy statement: Remove section 4.8 entitled "Policy for the > African Portion of the ARIN Region" of the NRPM. > > Rationale: The ARIN BoT recently suspended section 4.8 of the > NRPM upon recognition of AfriNIC as an RIR by ICANN. Section > 4.8 of the NRPM applied only to areas of the ARIN region that > are now covered by AfriNIC. > > Timetable for implementation: Within 30 days of ratification > by the BoT. > > From bicknell at ufp.org Mon May 9 16:07:42 2005 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 9 May 2005 16:07:42 -0400 Subject: [ppml] Directory Services - Take 2 Message-ID: <20050509200742.GA75281@ussenterprise.ufp.org> Below is my directory services proposal, take two. Based on feedback from the last meeting, I have removed the option of displaying SWIP information, and also updated several minor terms which were confusing from feedback on the mailing list. I'd like to get some discussion going so this can be ready for the next ARIN meeting. Also, at the end of this message I included a context diff to call out the changes. $Author: bicknell $ - $Date: 2005/05/09 20:06:30 $ - $Revision: 1.4 $ Replace all of section three with the following rewrite. 3 Directory Services 3.1 ARIN Directory Services Databases The ARIN Public Information Database (APID) is a collection of information created and collected by ARIN during the due course of business which the ARIN membership has deemed public information and decided to publish. The ARIN Confidential Information Database (ACID) is a collection of information created and collected by ARIN during the due course of business which the ARIN membership has deemed is confidential information that should be kept under a strict privacy policy. 3.2 Directory Information Made Public ARIN shall publish verified contact information and the resource(s) allocated (including identification for that allocation, like date of allocation or other information identified by ARIN) in the APID for all resources delegated by ARIN. In addition, all reassignment information as defined by section 4.2.3.7 will be included in the APID. ARIN shall insure all contact information in the APID is verified from time to time and is correct to the best of ARIN's ability. ARIN staff shall maintain verification criteria and post it on the ARIN web site. 3.2.1 Non-Responsive Contacts If ARIN is unable to verify contact information via the normal verification procedure ARIN shall attempt to notify the parent of the resource to have the information updated. If there is no parent, or if the data is not corrected in a reasonable amount of time the resource shall be SUSPENDED. Once the resource is suspended ARIN shall make one more request of all contacts listed with the resource and the parent resource (if available), and if no response is received in a reasonable amount of time the resource shall be reclaimed (APID records removed, DNS delegations removed, the space returned to the free pool). Third parties may report the inability to make contact with a party via information in the APID. In this case ARIN shall attempt the contact verification procedure for that contact immediately. If a response is received, ARIN should document that a problem occurred, and the response from the resource holder. Resource holders who fail to respond to third parties more than 4 times per month for three months may have their resources reclaimed at the discretion of ARIN staff. If a third party submits reports of the inability to make contact that are subsequently disproven, ARIN may choose to ignore reports from specific companies, people, e-mail addresses, or any other classification means as appropriate. The ARIN staff shall publish the time thresholds and procedural details to implement this policy on the ARIN web site. If a resource is reclaimed under no circumstances shall the holder of that resource be entitled to a refund of any fees. 3.3 Data Distribution 3.3.1 Methods of Access ARIN shall publish the APID in the following methods using industry standard practices: - Via the WHOIS protocol. - Via a query form accessible via the HTTP protocol. - Via FTP to users who complete the bulk data form. - Via CDROM to users who complete the bulk data form. - Via the RWHOIS protocol. All users of the APID must agree to the ARIN AUP. ARIN staff may make the APID available via other methods as conveniant. 3.3.1.1 Outside Sources ARIN may refer a query to a outside source (for instance via RWHOIS or HTTP redirect). Outside sources must: 1 Have an AUP deemed compatible with the ARIN AUP by ARIN staff. 2 Support the applications in section 3.3.1. 3 Prohibit the applications in section 3.3.2. 4 Meet the requirements in section 3.3.3. 3.3.2 Acceptable Usage Policy All data provided shall be subject to an AUP. The AUP shall be written by ARIN staff and legal and posted on the ARIN website. ARIN may require a signed copy of the AUP before providing bulk data. 3.3.3 Requirements for Internet Accessible Services For any method of access which is provided in real time via the Internet the following requirements must be met: * The distributed information service must be operational 24 hours a day, 7 days a week to both the general public and ARIN staff. The service is allowed reasonable downtime for server maintenance according to generally accepted community standards. * The distributed information service must allow public access to reassignment information. The service may restrict the number of queries allowed per time interval from a host or subnet to defend against DDOS attacks, remote mirroring attempts, and other nefarious acts. * The distributed information service must return current information. 3.4 Distribution of the ARIN Public Information Database 3.4.1 Supported Uses ARIN shall make the APID available for the following uses (supported uses): 1 ARIN's use in implementing ARIN policies and other business. 2 Community verification, allowing members of the community to confirm the proper users of the various resources ARIN controls. 3 Statistic gathering by ARIN and third parties on resource utilization. 4 As a contact database to facilitate communication with the person or entity responsible for a particular resource. 3.4.2 Prohibited Uses ARIN prohibits the use of the APID for the following uses: 1 Sending any unsolicited commercial correspondence advertising a product or service to any address (physical or electronic) listed in the APID. 2 Using data in the APID to facilitate violating any state, federal, or local law. 3.4.3 Other Uses ARIN shall allow all non-prohibited uses of the APID, however unless those uses are listed as a supported use the data set may be changed in such a way as to render them ineffective, or they may be blocked outright as deemed necessary by ARIN staff. Users of applications not listed who are concerned that they are supported should introduce a proposal to add their application to the supported list. 3.5 Distribution of the ARIN Confidential Information Database ARIN Staff shall use industry standard procedures to prevent the distribution of any data in the ARIN Confidential Information Database. 3.6 Implementation Details ARIN Staff shall document all implementation specific details for directory services in a single document available on the web site. The document must contain, but is not limited to: - Database field definitions. - Update procedures. - Templates. - Points of contact. - Copies of the AUP. - Verification procedures. 3.7 [Routing Registry] Copy Verbatim from the existing 3.4. Section 4.2.3.7.4: Replace with: All reassignment information for current blocks shall be submitted to ARIN prior to submitting a request for a new allocation. -------------------Context diff below---------------------------------- 2c2 < $Author: bicknell $ - $Date: 2005/02/03 15:27:41 $ - $Revision: 1.2 $ --- > $Author: bicknell $ - $Date: 2005/05/09 20:06:30 $ - $Revision: 1.4 $ 25,30c25,27 < identified by ARIN) in the APID in the following cases: < < - All resources delegated by ARIN. < - If allowed by the parent delegation, and requested by < the contact listed with the parent, a subdelegation of a < resource. --- > identified by ARIN) in the APID for all resources delegated > by ARIN. In addition, all reassignment information as defined > by section 4.2.3.7 will be included in the APID. 45,48c42,47 < Once the resource is suspended ARIN shall make one more request < of all contacts listed with the resource and the parent resource < (if available), and if no response is received in a reasonable < amount of time the resource shall be reclaimed. --- > Once the resource is suspended ARIN shall make one more > request of all contacts listed with the resource and the > parent resource (if available), and if no response is received > in a reasonable amount of time the resource shall be reclaimed > (APID records removed, DNS delegations removed, the space > returned to the free pool). 50,51c49,50 < Third parties may report the inability to make contact with a < party via information in the APID. In this case ARIN shall --- > Third parties may report the inability to make contact with > a party via information in the APID. In this case ARIN shall 55,57c54,56 < holder. Offenders who fail to respond to third parties more < than 4 times per month for three months may have their resources < reclaimed at the discretion of ARIN staff. --- > holder. Resource holders who fail to respond to third parties > more than 4 times per month for three months may have their > resources reclaimed at the discretion of ARIN staff. 82a82,84 > All users of the APID must agree to the ARIN AUP. ARIN staff > may make the APID available via other methods as conveniant. > 89,91c91,93 < 2 Meet the requirements in section 3.3.3. < 3 Support the applications in section 3.3.1. < 4 Prohibit the applications in section 3.3.2. --- > 2 Support the applications in section 3.3.1. > 3 Prohibit the applications in section 3.3.2. > 4 Meet the requirements in section 3.3.3. 182,183d183 < < Section 4.2.3.7.6: Strike. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From Ed.Lewis at neustar.biz Mon May 9 16:10:21 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Mon, 9 May 2005 16:10:21 -0400 Subject: Pragmatism (was Re: [ppml] Re: 2005-1:Multi-national Business Enablement) In-Reply-To: References: <1115195954.3981.16.camel@firenze.zurich.ibm.com> Message-ID: At 14:07 -0400 5/9/05, Tom Vest wrote: >First, the only slightly tongue-in-cheek response: do you think the ITU would >be (or be perceived to be) doing as well with their number management if 8-9 >new sovereign states were added to the international system every day? That's >the situation that the RIRs face, because -- at least in some places -- the >barriers to becoming a network operator are relatively low. In perhaps half of Well, my question was more about what drove the desires, but you've brought up something that does differentiate between the RIR approach and the ITU approach. What's interesting is that the difference here relates to barriers of entry, but is much the same as the difference between fundamental technical differences between telephony's time (or wave) division multiplexing and computer network on-demand (ALOHA-like) methods of sharing a medium. Hmmm. I was thinking that one difference was the fixed size of address (in IP) versus variable (tel nos.). Because phone numbers aren't fixed length, assigning country codes is plausible. With fixed lengths, it isn't so much. But having to deal with players coming and going - and all the associated security, economic, and business state being established and dismantled - that the environment is much harder to deal with. (If you can count the game's participants, it's much easier to predict the outcome.) >How many new sovereign national entities do you see being created every day > -- every century? One could make a snide remark about "regime change" directives. ;) >system -- but almost no one's buying. I'll spare you the academic citations, >but the point is that "national resource alignment" is essentially a >conservative strategy, not a strategy for growth. Strict national resource >alignment is not an efficient way of organizing a system that grows in >response to transnational supply and demand -- like the conventional economy, >like the Internet. It is, however, a good strategy for perpetuating national >power. I don't need the citations, I wholeheartedly agree with this. At one time I was convinced the following was a paraphrased quote of Samuel Morse (telegraph dude), but have yet to find a citation - and I have tried - "Innovation is stymied because there comes a time when to deploy it fully you need the capitalization owned by the proponents of the status quo. Not until the status quo proponents have figured out how to use the innovation to their own benefit will the capital appear." The quoted words were much better... IOW - Nations (or the people in power) will want to see the Interent administered (I'm avoiding "governed") in a way that perpetuates their power. I think that's only natural. The (rhetorical) question is how does the Internet grow with or inspite of this, without killing the benefit (real or perceived, past or future) of the innovation? I suppose you could boil down my question to - it's not that the ITU is "backwards" for being so nationalistic, it's that the Internet Community (TM) needs to figure out how to continue to be innovative with the nationalistic reality. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From Ed.Lewis at neustar.biz Mon May 9 16:15:59 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Mon, 9 May 2005 16:15:59 -0400 Subject: Pragmatism (was Re: [ppml] Re: 2005-1:Multi-national Business Enablement) In-Reply-To: References: <1115195954.3981.16.camel@firenze.zurich.ibm.com> Message-ID: At 13:02 -0700 5/9/05, Owen DeLong wrote: >Ed> Especially because the ITU's managed address space has not run out. > >Only because ITU's managed address space is not fixed in length. It's Yeah, exactly. Well, that's one reason. >Ed> IPv4's is allegedly (prompting IPv6), so if we deplete v6 also the ITU >Ed> can claim "we've never exhausted an address pool but they have - twice!" > >They could, but, they'd be making a very specious claim about completely >unrelated issues. Like specious claims never hurt anyone. When I wrote this I was thinking of the lack of Major League Baseball in Washington DC from 1972 until 2004. DC is the only city to have lost two franchises, taking 33 years to "earn" another. Variable length addresses and the low barrier to entry for obtaining space are two real differences between the ITU and RIRs. There are probably more. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From randy at psg.com Mon May 9 16:17:08 2005 From: randy at psg.com (Randy Bush) Date: Mon, 9 May 2005 10:17:08 -1000 Subject: [ppml] IPv6>>32 References: <9F7279D9-0B98-4726-A666-94C917C09DAE@nominum.com> <20050509200142.4062D145441@smtp2.arin.net> Message-ID: <17023.50500.24829.982688@roam.psg.com> > Yes stewardship is about resource management so that it is available > in the future, but is also about allowing current use of the resource > in ways that don't artificially constrain innovation to past practice. this deserves one concrete example where it is doing so. otherwise it's all outer space where we have no idea what we could or should be doing other than the current v6 marketing smoke, build it and they will come. randy From matt.pounsett at cira.ca Mon May 9 16:53:26 2005 From: matt.pounsett at cira.ca (Matt Pounsett) Date: Mon, 9 May 2005 16:53:26 -0400 Subject: [ppml] IPv6>>32 In-Reply-To: References: Message-ID: >> The net result is that we're poised to burn through a /1 to a /4 >> of the IPv6 address space in the next 60 years based on our best >> current guesses. This makes me extremely nervous. >> > > I'm sorry but I cannot understand this sentiment at all. IPv4 has > not even been deployed for 60 years yet and nevertheless we still > have spare addresses and we have created and deployed an IPv4 > replacement. [...] > Sorry, but I am not going to run a DHCP server on my mobile > phone, on my fridge, on my TV or my stereo or my home lighting > system. I won't be running a DHCP server on my home environment > monitors, on my furnace or on any of my automobile networks > either. I won't be running a DHCP server on my shower control > system or my bathtub or my heated toilet with robotic sanitary > arm. (Don't laugh, this toilet is already on the market in Japan). > In short, I think that you are starting from wrong premises in > your use of the word "host" and "site". I'm sorry, but I'm a bit confused by this apparent contradiction. Are you approaching IPv6 from the perspective that it is going to allow us to deploy IP stacks on hundreds of new devices per home, and per person, or are you approaching it from the perspective that IPv6 is just meant to give us breathing room in our deployment of current applications of IPv4? If the former, then I don't understand how you can question that the potential exists for us to use up a significant chunk of the v6 space in the next 60 years. Matt Pounsett -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From gih at apnic.net Mon May 9 16:56:16 2005 From: gih at apnic.net (Geoff Huston) Date: Tue, 10 May 2005 06:56:16 +1000 Subject: [ppml] IPv6>>32 In-Reply-To: <20050509200142.4062D145441@smtp2.arin.net> References: <9F7279D9-0B98-4726-A666-94C917C09DAE@nominum.com> <20050509200142.4062D145441@smtp2.arin.net> Message-ID: <6.0.1.1.2.20050510063111.0380bd70@kahuna.telstra.net> At 06:01 AM 10/05/2005, Tony Hain wrote: >David Conrad wrote: > > Michael, > > > > On May 9, 2005, at 9:39 AM, Michael.Dillon at radianz.com wrote: > > >> The net result is that we're poised to burn through a /1 to a /4 > > >> of the IPv6 address space in the next 60 years based on our best > > >> current guesses. This makes me extremely nervous. > > > I'm sorry but I cannot understand this sentiment at all. > > > > For me, the sentiment derives from the discomfort of knowingly > > deploying something that is (arguably) broken. I suspect if you went > > back in time and asked Vint or Bob Kahn or any of the other original > > net geeks if they thought IPv4 would ever really be at risk of > > running out, they'd laugh at you. > >Burning through a /4 in 50 years is consistent with original assumptions, as >is the point that we have 3/4 of the space set aside for different >allocation approaches if the first proved wrong. It is not that people >didn't learn anything from the first time around, it is just that some want >to be more conservative than others. The IPv6 roundtable presentation at ARIN XV explicitly placed quite a high level of uncertainly on that number of cumulative consumption Tony, and the presentation explicitly noted that the outcome was somewhere between a /1 and a /4. Not, that's not a /4, that's somewhere between a /1 and a /4. Also, just to be mathematically on the right track here a /4 is 1/16 of the number space, while a /2 is one quarter of the address space. So, to rephrase your comment, if the cumulative consumption is a /4 then there is 15/16ths of the space that could, in theory, be used for different allocation approaches. However, its sensible to also note that if we think that "installed base" is an argument today in terms of the pain associated with changing the 64 bit length for the device identifier, just wait until the installed base of end sites gets to the 30 billion mark that is commensurate with a /4 consumption under current policies. Now 30 billion end sites is _really_ an installed base, and its inertial impetus would say to me that at that stage your wriggle room for the remaining space is pretty much a lost opportunity. So if we are having trouble now in looking at the global identifier on the basis of the inertial mass of already deployed systems and services, then you cannot also put forward the proposition that we can change things once we've deployed 30 billion end site instances of the same. So I'm afraid that "we've still got future wriggle room in the future so don't worry about it now" is not an approach that I can accept easily - if at all. At that point the late comers will be complaining that they are exposed to tougher and more constrained policies that are deployed at a higher cost than that of the early adopters - and if all this sounds hauntingly familiar in reference to the current debates about national interests and highly populous economies and various address policy frameworks, then it should. I'm afraid that there's an increasing cynicism out there about the refrain of "don't worry we'll fix it once its visibly broken" with respect to address policies. We should at this point be striving to instill some broad confidence in the proposition that we can provide a stable and enduring platform for the world's communications needs. regards, Geoff From alh-ietf at tndh.net Mon May 9 17:08:33 2005 From: alh-ietf at tndh.net (Tony Hain) Date: Mon, 9 May 2005 14:08:33 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: <17023.50500.24829.982688@roam.psg.com> Message-ID: <20050509210834.CEC631451A2@smtp2.arin.net> Randy Bush wrote: > > Yes stewardship is about resource management so that it is available > > in the future, but is also about allowing current use of the resource > > in ways that don't artificially constrain innovation to past practice. > > this deserves one concrete example where it is doing so. otherwise it's > all outer space where we have no idea what we could or should be doing > other than the current v6 marketing smoke, build it and they will come. > > randy One could argue that the smoke coming from the 'conservation is paramount' crowd deserves at least one concrete example of why a well managed set of 45 bits is insufficient ... 1) RFC 3306 - there are not enough bits to use this approach with Leo's proposal. I don't know what they are using for server address allocations but http://www.ipv6style.jp/en/action/20040902/index.shtml shows that IPv6 multicast is already in commercial deployment. 2) http://www.ietf.cnri.reston.va.us/proceedings/02jul/slides/send-2/tsld003.ht m shows some thoughts about how security might be improved, and while current proposals might not work out the overall approach suggests that aggressive conservation will stifle innovation in this space. The point is that IPv4/nat has constrained innovation; that IPv6 as defined opens the potential again; and anyone that claims to know what we will or will not need in 50 years is just wrong. Yes egregious waste of the address resource should be avoided, but so should miserly conservation that increases the market value of nat approaches. The /48-/64 units effectively reduce the market value of nat to $0. Artificially constraining the space available to network users will only negate that effect. Change the H-D ratio policy and gain back 3 bits (well over 300 years worth), then we can talk about the impact/value of changing the customer side allocation boundary. There are non-technical reasons that this whole debate is moot so rather than wasting more time on it we should get past the conservation FUD and get on with allocations. Tony From tvest at pch.net Mon May 9 17:16:09 2005 From: tvest at pch.net (Tom Vest) Date: Mon, 9 May 2005 17:16:09 -0400 Subject: Pragmatism (was Re: [ppml] Re: 2005-1:Multi-national Business Enablement) In-Reply-To: References: <1115195954.3981.16.camel@firenze.zurich.ibm.com> Message-ID: On May 9, 2005, at 4:10 PM, Edward Lewis wrote: > At 14:07 -0400 5/9/05, Tom Vest wrote: > >> First, the only slightly tongue-in-cheek response: do you think the >> ITU would >> be (or be perceived to be) doing as well with their number management >> if 8-9 >> new sovereign states were added to the international system every >> day? That's >> the situation that the RIRs face, because -- at least in some places >> -- the >> barriers to becoming a network operator are relatively low. In >> perhaps half of > > Well, my question was more about what drove the desires, but you've > brought up something that does differentiate between the RIR approach > and the ITU approach. > > What's interesting is that the difference here relates to barriers of > entry, but is much the same as the difference between fundamental > technical differences between telephony's time (or wave) division > multiplexing and computer network on-demand (ALOHA-like) methods of > sharing a medium. Hmmm. you could almost call something like this "logical multiplexing" ;) (apropos previous shameless self-promotion) > I was thinking that one difference was the fixed size of address (in > IP) versus variable (tel nos.). Because phone numbers aren't fixed > length, assigning country codes is plausible. With fixed lengths, it > isn't so much. > > But having to deal with players coming and going - and all the > associated security, economic, and business state being established > and dismantled - that the environment is much harder to deal with. (If > you can count the game's participants, it's much easier to predict the > outcome.) > >> How many new sovereign national entities do you see being created >> every day >> -- every century? > > One could make a snide remark about "regime change" directives. ;) That might count as "change of management," much less frequently M&A, but almost never devolution resulting in a larger number of basic entities afterward. We get nine new networks a day, and rising. >> system -- but almost no one's buying. I'll spare you the academic >> citations, >> but the point is that "national resource alignment" is essentially a >> conservative strategy, not a strategy for growth. Strict national >> resource >> alignment is not an efficient way of organizing a system that grows in >> response to transnational supply and demand -- like the conventional >> economy, >> like the Internet. It is, however, a good strategy for perpetuating >> national >> power. > > I don't need the citations, I wholeheartedly agree with this. > > At one time I was convinced the following was a paraphrased quote of > Samuel Morse (telegraph dude), but have yet to find a citation - and I > have tried - > > "Innovation is stymied because there comes a time when to deploy it > fully you need the capitalization owned by the proponents of the > status quo. Not until the status quo proponents have figured out how > to use the innovation to their own benefit will the capital appear." > The quoted words were much better... > > IOW - Nations (or the people in power) will want to see the Interent > administered (I'm avoiding "governed") in a way that perpetuates their > power. I think that's only natural. The (rhetorical) question is how > does the Internet grow with or inspite of this, without killing the > benefit (real or perceived, past or future) of the innovation? > > I suppose you could boil down my question to - it's not that the ITU > is "backwards" for being so nationalistic, it's that the Internet > Community (TM) needs to figure out how to continue to be innovative > with the nationalistic reality. I wholeheartedly agree back. Neither government(s) nor the ITU are stupid or evil; both have done lots of good in their time/place, also lots of harm at other times. Change is upon us, and it is incumbent upon everyone to think about what to do about it. I will do something even more unexpected and paraphrase Hans Klein and Milton Mueller, about the appropriate prerequisites for greater government involvement in Internet policy: "...one cannot expect a government to apply competition law evenhandedly to a monopoly enterprise created by the government or a state-owned enterprise in which the government has a substantial economic stake. If governments want to (have greater authority over Internet policy) they have to get out of its day to day workings."* In other words, governments should be expected to choose between Internet roles -- player or referee, but not both. To demand both engenders a conflict of interest that is inconsistent with good governance in any sector. TV *This is generalized from a statement about ICANN reform in "What to Do About ICANN: A Proposal for Structural Reform," online at: http://dcc.syr.edu/miscarticles/IGP-ICANNReform.pdf > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > =-=-=- > Edward Lewis > +1-571-434-5468 > NeuStar > > If you knew what I was thinking, you'd understand what I was saying. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 5119 bytes Desc: not available URL: From paul at vix.com Mon May 9 17:17:14 2005 From: paul at vix.com (Paul Vixie) Date: Mon, 09 May 2005 21:17:14 +0000 Subject: [ppml] IPv6>>32 In-Reply-To: Your message of "Mon, 09 May 2005 20:40:25 +0200." References: Message-ID: <20050509211714.7B62F13971@sa.vix.com> > I mean core routers, not access routers, not CPEs. all core routers? or only some of them? which ones, made by whom, when? re: > > De: Paul Vixie > > Responder a: > > Fecha: Mon, 09 May 2005 18:16:53 +0000 > > Para: > > Asunto: Re: [ppml] IPv6>>32 > > > > jordi wrote, again in response to leo, as follows: > > > >> We have lots of examples of people don't following RFCs, and I > >> don't mean I agree with that, but is real life. > >> > >> Keeping 128 bits in the lookup tables of core routers has been seen > >> by some chip set vendors as not useful, very expensive and time > >> consuming, while they only handle actually 64 bits routes in that > >> part of the network. > > > > no doubt. > > > >> Those routers don't expect to see the 64 bits of the host field to > >> be required for the routing, because they look into the aggregated > >> route towards the PoP, access network, or whatever is next. > > > > what routers? you lost me on that last part. which router/routers, > > exactly? > > > > paul From randy at psg.com Mon May 9 17:23:44 2005 From: randy at psg.com (Randy Bush) Date: Mon, 9 May 2005 11:23:44 -1000 Subject: [ppml] IPv6>>32 References: <17023.50500.24829.982688@roam.psg.com> Message-ID: <17023.54496.965412.366345@roam.psg.com> >>> Yes stewardship is about resource management so that it is available >>> in the future, but is also about allowing current use of the resource >>> in ways that don't artificially constrain innovation to past practice. >> this deserves one concrete example where it is doing so. otherwise it's >> all outer space where we have no idea what we could or should be doing >> other than the current v6 marketing smoke, build it and they will come. > One could argue that the smoke coming from the 'conservation is paramount' > crowd deserves at least one concrete example of why a well managed set of > 45 bits is insufficient ... one answer is in four characters "IPv4." which is one big reason why ipv6 deployment is essentially negligible. randy From alh-ietf at tndh.net Mon May 9 17:26:09 2005 From: alh-ietf at tndh.net (Tony Hain) Date: Mon, 9 May 2005 14:26:09 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: <6.0.1.1.2.20050510063111.0380bd70@kahuna.telstra.net> Message-ID: <20050509212615.6C8F2145425@smtp2.arin.net> Geoff Huston wrote: > >Burning through a /4 in 50 years is consistent with original assumptions, > as > >is the point that we have 3/4 of the space set aside for different > >allocation approaches if the first proved wrong. It is not that people > >didn't learn anything from the first time around, it is just that some > want > >to be more conservative than others. > > The IPv6 roundtable presentation at ARIN XV explicitly placed quite a high > level of uncertainly on that number of cumulative consumption Tony, and > the > presentation explicitly noted that the outcome was somewhere between a /1 > and a /4. Not, that's not a /4, that's somewhere between a /1 and a /4. > Yes there is uncertainty, as there has been all along. That was part of the point of starting with 1/8th and allowing for different approaches if time proved the first attempt to be wrong. The current discussions seem to be more focused on 'we have to get this right the first time to last for 100 years' than they are on the reality that we don't and can't know what it will take to deal with the network of 100 years from now. > Also, just to be mathematically on the right track here a /4 is 1/16 of > the > number space, while a /2 is one quarter of the address space. So, to > rephrase your comment, if the cumulative consumption is a /4 then there is > 15/16ths of the space that could, in theory, be used for different > allocation approaches. I was not trying to nail down every last block because we have already defined parts of 0/4, and f/4 so in the big picture there is essentially only 6/8's worth of space without any issues. > > However, its sensible to also note that if we think that "installed base" > is an argument today in terms of the pain associated with changing the 64 > bit length for the device identifier, just wait until the installed base > of > end sites gets to the 30 billion mark that is commensurate with a /4 > consumption under current policies. Now 30 billion end sites is _really_ > an installed base, and its inertial impetus would say to me that at that > stage your wriggle room for the remaining space is pretty much a lost > opportunity. So if we are having trouble now in looking at the global > identifier on the basis of the inertial mass of already deployed systems > and services, then you cannot also put forward the proposition that we can > change things once we've deployed 30 billion end site instances of the > same. I am not suggesting we change 2000::/3 ever. On the other hand we would not have to change protocol versions to adjust the allocation policies for other /3 prefixes. > > So I'm afraid that "we've still got future wriggle room in the future so > don't worry about it now" is not an approach that I can accept easily - if > at all. At that point the late comers will be complaining that they are > exposed to tougher and more constrained policies that are deployed at a > higher cost than that of the early adopters - and if all this sounds > hauntingly familiar in reference to the current debates about national > interests and highly populous economies and various address policy > frameworks, then it should. I'm afraid that there's an increasing cynicism > out there about the refrain of "don't worry we'll fix it once its visibly > broken" with respect to address policies. We should at this point be > striving to instill some broad confidence in the proposition that we can > provide a stable and enduring platform for the world's communications > needs. By your own numbers changing the H-D policy would get us to centuries in the current /3, then folding in the non-technical business desires to differentiate based on prefix length we are talking about multiple millennia still using the 64/64 split. At what point do you think people will want a new protocol for non-address consumption reasons? IPv6 is a good protocol but it will not be in use in 1000 years because there will be plenty of reasons to change it (including that engineers just can't resist their need to tinker). Manage the space, but conservation that stifles innovation is both unnecessary and fundamentally wrong. Tony From alh-ietf at tndh.net Mon May 9 17:44:26 2005 From: alh-ietf at tndh.net (Tony Hain) Date: Mon, 9 May 2005 14:44:26 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: <17023.54496.965412.366345@roam.psg.com> Message-ID: <20050509214427.464901449F2@smtp2.arin.net> Randy Bush wrote: > >>> Yes stewardship is about resource management so that it is available > >>> in the future, but is also about allowing current use of the resource > >>> in ways that don't artificially constrain innovation to past practice. > >> this deserves one concrete example where it is doing so. otherwise > it's > >> all outer space where we have no idea what we could or should be doing > >> other than the current v6 marketing smoke, build it and they will come. > > One could argue that the smoke coming from the 'conservation is > paramount' > > crowd deserves at least one concrete example of why a well managed set > of > > 45 bits is insufficient ... > > one answer is in four characters "IPv4." which is one big reason why ipv6 > deployment is essentially negligible. IPv6 deployment is gated by lack of applications and/or a crisis. The crisis is looming despite Geoff's extended projection (which will only make the panic more acute). His simple exponential on the 10 year data is biased by the 98-00 lull in allocations from IANA as well as the more stringent attitudes of the late 90's (the impact of the recent plan to relax further and allow public IPv4 for private use will not show up for some time to come). A second order polynomial fit on the most recent 5 years of the IANA run rate is both more accurate and more indicative of how hard we are going to hit the wall. The crisis that will drive rapid deployment of IPv6 is coming, as are applications that will take advantage of it. The allocation policy that allows very large organizations to be inefficient in their management of space needs to be fixed before that happens, so quickly change the H-D ratio for them to one that makes sense. Tony From randy at psg.com Mon May 9 17:52:46 2005 From: randy at psg.com (Randy Bush) Date: Mon, 9 May 2005 11:52:46 -1000 Subject: [ppml] IPv6>>32 References: <17023.54496.965412.366345@roam.psg.com> Message-ID: <17023.56238.899376.896218@roam.psg.com> > IPv6 deployment is gated by lack of applications and/or a > crisis. The crisis is looming shall we have a game to see who can list the crises which were about to explode v6 deployment which have loomed in the last decade? don't get me wrongly. i will not be at all unhappy if ipv6 moves from k00la1d to reality. but, for a decade, i have had this problem of seeing the emperor's attire, and i don't see it today. perhaps it's my aging eyes. randy From gih at apnic.net Mon May 9 18:17:19 2005 From: gih at apnic.net (Geoff Huston) Date: Tue, 10 May 2005 08:17:19 +1000 Subject: [ppml] IPv6>>32 In-Reply-To: <200505092126.j49LQCsf013264@apnic.net> References: <6.0.1.1.2.20050510063111.0380bd70@kahuna.telstra.net> <200505092126.j49LQCsf013264@apnic.net> Message-ID: <6.0.1.1.2.20050510080227.038124e0@kahuna.telstra.net> > > > We should at this point be > > striving to instill some broad confidence in the proposition that we can > > provide a stable and enduring platform for the world's communications > > needs. > >By your own numbers changing the H-D policy would get us to centuries in the >current /3, then folding in the non-technical business desires to >differentiate based on prefix length we are talking about multiple millennia >still using the 64/64 split. Again referring to the presentation at the ARIN VX IPv6 roundtable what was presented was the theme that a change in the HD ratio and an additional setting in the subnet space of 56 bits would appear to gain us all some 10 bits (or thereabouts) of address space - which would certainly be an adequate margin to dispel many lingering levels of discomfort with the total capacity of the address architecture without imposing undue levels of imposition or cost on the current and potential user population - these are after all relatively minor adjustments on the supply side rather than changes to the address architecture itself. The 64/64 split is not quite in the same category here, and there is an impact on the current address architecture. Its true that the original motivations for this particular aspect of the address architecture have largely gone away, or at least have been unable to be realized, and the residual reasons for its adoption are based more in legacy conformance than in true utility. But here its not quite so clear to me that change is necessary. As Thomas Narten has said, maybe it would be more practical to go after the low hanging fruit here, when referring to a preference to look at the HD Ratio and the subnet size points over looking at the 64 bit split point between local identification and routing identifiers. regards, Geoff From alh-ietf at tndh.net Mon May 9 18:56:31 2005 From: alh-ietf at tndh.net (Tony Hain) Date: Mon, 9 May 2005 15:56:31 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: <17023.56238.899376.896218@roam.psg.com> Message-ID: <20050509225636.588D3145468@smtp2.arin.net> Randy Bush wrote: > > IPv6 deployment is gated by lack of applications and/or a > > crisis. The crisis is looming > > shall we have a game to see who can list the crises which were > about to explode v6 deployment which have loomed in the last > decade? > > don't get me wrongly. i will not be at all unhappy if ipv6 moves > from k00la1d to reality. but, for a decade, i have had this > problem of seeing the emperor's attire, and i don't see it today. > perhaps it's my aging eyes. Those would be the same ones that claim to see that 8k times the number of bits that got us 30 years (while arguably loosely managed and including hosts) will be insufficient to get us past 100 years (by only indicating the customer demarc). 45 bits is a very large space. You can drop the bubble-hype of 'it didn't happen in 6 months so it isn't real'. We knew going in that it would take a decade to make a massive change to the infrastructure, and all hype aside we are not getting it done any quicker by wasting time fighting nay-sayers. If you choose to slam into the wall when the address pool runs out that is your choice. Some of us want to enable others to avoid the problems that will create. Tony From alh-ietf at tndh.net Mon May 9 19:11:50 2005 From: alh-ietf at tndh.net (Tony Hain) Date: Mon, 9 May 2005 16:11:50 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: <6.0.1.1.2.20050510080227.038124e0@kahuna.telstra.net> Message-ID: <20050509231158.E07CE144E37@smtp2.arin.net> Geoff Huston wrote: > > > We should at this point be > > > striving to instill some broad confidence in the proposition that we > can > > > provide a stable and enduring platform for the world's communications > > > needs. > > > >By your own numbers changing the H-D policy would get us to centuries in > the > >current /3, then folding in the non-technical business desires to > >differentiate based on prefix length we are talking about multiple > millennia > >still using the 64/64 split. > > > Again referring to the presentation at the ARIN VX IPv6 roundtable what > was > presented was the theme that a change in the HD ratio and an additional > setting in the subnet space of 56 bits would appear to gain us all some 10 > bits (or thereabouts) of address space - which would certainly be an > adequate margin to dispel many lingering levels of discomfort with the > total capacity of the address architecture I seriously doubt it. Given that people can't do simple math and realize that 32 bits got is 30 years while including hosts and that there are 2^13 32 bit chunks in the first /3 that will only have to identify customer demarc's, there is no amount of change that will dispel lingering doubt in those that simply don't want to believe. > without imposing undue levels of > imposition or cost on the current and potential user population - these > are > after all relatively minor adjustments on the supply side rather than > changes to the address architecture itself. There are business reasons to consider other than /48, so we should talk about the appropriate values. Casting a change as 'needed for address lifetime' is simply going to reopen battles that were fought long ago. > > The 64/64 split is not quite in the same category here, and there is an > impact on the current address architecture. Its true that the original > motivations for this particular aspect of the address architecture have > largely gone away, or at least have been unable to be realized, and the > residual reasons for its adoption are based more in legacy conformance > than > in true utility. This statement stems from a 'routing' perspective of utility. There are other forms of utility that have not been given the opportunity to flourish due to the continuous FUD about the need to micro-manage the space. > But here its not quite so clear to me that change is > necessary. As Thomas Narten has said, maybe it would be more practical to > go after the low hanging fruit here, when referring to a preference to > look > at the HD Ratio and the subnet size points over looking at the 64 bit > split > point between local identification and routing identifiers. The H-D ratio policy is clearly in RIR space and therefore is the lowest hanging fruit. Some productive discussion about the perceived need for business differentiators in the customer prefix length would deal with the hard feelings about a fixed value, but there is nothing that will convince those who simply want to constrain their customers to the 'old world' model of IPv4 address management. As such I am not sure it is really an RIR policy so much as a BCP that provides clue about the negative impact of picking random values. Tony > > regards, > > Geoff From bicknell at ufp.org Mon May 9 20:57:20 2005 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 9 May 2005 20:57:20 -0400 Subject: [ppml] IPv6>>32 In-Reply-To: <20050509210834.CEC631451A2@smtp2.arin.net> References: <17023.50500.24829.982688@roam.psg.com> <20050509210834.CEC631451A2@smtp2.arin.net> Message-ID: <20050510005720.GA88259@ussenterprise.ufp.org> In a message written on Mon, May 09, 2005 at 02:08:33PM -0700, Tony Hain wrote: > The point is that IPv4/nat has constrained innovation; that IPv6 as defined > opens the potential again; and anyone that claims to know what we will or > will not need in 50 years is just wrong. Yes egregious waste of the address > resource should be avoided, but so should miserly conservation that > increases the market value of nat approaches. The /48-/64 units effectively > reduce the market value of nat to $0. Artificially constraining the space > available to network users will only negate that effect. You did not say this directly, so I will ask directly. Am I correct in assuming that you believe 32 bits of host space (4 billion hosts per subnet) is a constraint that qualifies as "miserly", and that will lead to the adoption of IPv6 NAT? -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From bicknell at ufp.org Mon May 9 21:08:00 2005 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 9 May 2005 21:08:00 -0400 Subject: [ppml] IPv6>>32 In-Reply-To: <20050509212615.6C8F2145425@smtp2.arin.net> References: <6.0.1.1.2.20050510063111.0380bd70@kahuna.telstra.net> <20050509212615.6C8F2145425@smtp2.arin.net> Message-ID: <20050510010800.GB88259@ussenterprise.ufp.org> In a message written on Mon, May 09, 2005 at 02:26:09PM -0700, Tony Hain wrote: > I am not suggesting we change 2000::/3 ever. On the other hand we would not > have to change protocol versions to adjust the allocation policies for other > /3 prefixes. The problem with changing things later to be tighter is that it creates a first mover advantage, where as changing it to be loser later creates a level playing field. I will provide a concrete example, picking on BBN since they are no longer around. During some of the "bust" hard times BBN would sell you a T1 with a "free" /24 thrown in. No justification required. They had 4/8, it would be a long time until they had to pay the piper. Many late comers, without a /8 to toss around were going back to ARIN every 6 months. Sales, and the customer wanted to know why when BBN was giving away a /24, they had to make the customer fill out a justification form, and then the customer only got a /28. If in the future we have to tighten IPv6 allocation policies for future /3's we stand a chance of doing the exact same thing again. We reward a company for being around at the beginning, and we create an artificial advantage for that type of business. On the other hand, if we start with a more restrictive policy, and it turns out that later we have more room than we thought we than then make an intelligent decision to either open up the field equally to all participants at that time, or to continue with the more restrictive policy in an effort to extend the life in the protocol. In short, with the IETF's proposal we have the potential upside of "something no one has thought of yet" (innovation), and the potential downside of artificially biasing the business landscape and running out of address space before we have some other need to replace the protocol. With a more conservative approach we have the potential upside of having a choice later between "roomy" allocations and extending the life of the protocol and a level business playing field, and the potential down side of holding back innovation. We know what the IETF is comfortable with, what is the comfort level of everyone else involved? -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From kloch at hotnic.net Mon May 9 22:14:43 2005 From: kloch at hotnic.net (Kevin Loch) Date: Mon, 09 May 2005 22:14:43 -0400 Subject: [ppml] IPv6>>32 In-Reply-To: References: Message-ID: <42801913.40003@hotnic.net> JORDI PALET MARTINEZ wrote: > There has been a strong effort in coding and deployment. May be not so much > in US, but definitively in AP and Europe, which can't be changed so easily. I have yet to see any evidence of widespread deployment to end users even in places with lots of /32's. Put up a website that gets traffic from those reigons and see how much comes via IPv6. My small data set indicates about 0.2%. Maybe Google can provide some good data when they light up AAAA records. Now would be a good time to consider addressing policy changes before actual widespread deployment occurrs. o Increasing the H-D ratio is a no brainer. I have advocated this several times before. Esitmated benefit: 3 bits. o Changing the default assignment for end sites to /56 (or even /60) is a good idea. Even if the threshold for upgrading to /48 was just asking, the typical non technical end site would not. This would probably save 6-7 (10-11) bits on average, a huge benefit. So we could have 9-14 extra bits with just those proposals. At that point I would rather recover payload space through some ugly hack than recover address space from 64-128. There is also the issue of the gigantic windfall for early adopters that would result from moving /32 to /64 I thought we weren't supposed to do that again? - Kevin From Michael.Dillon at radianz.com Tue May 10 06:02:33 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Tue, 10 May 2005 11:02:33 +0100 Subject: [ppml] IPv6>>32 In-Reply-To: <9F7279D9-0B98-4726-A666-94C917C09DAE@nominum.com> Message-ID: > For me, the sentiment derives from the discomfort of knowingly > deploying something that is (arguably) broken. I can understand this. It is common among technical people and artists. You seek perfection. However, in management one MUST become comfortable with deploying things that are broken on a regular basis. You know the 80-20 rule? You can gain 80% of the benefits at 20% of the costs. A manager is often faced with multiple projects competing for a limited pool of resources. Add to this, the knowledge that the pool of resources could be bigger in the future and, in fact, current actions can lead to a bigger pool of resources. In such a scenario, if you can get something deployed that will break in 60 years and it costs 20% of your resource pool, then that is a bargain. The remaining resource pool can be used for other important things, and during the 60 years there will be multiple opportunities and additional resources available to solve the problem, if, indeed, there is a problem. I'm reminded of London's Routemaster buses. These red double-decker buses with the rear entrance were introduced in 1954 and expected to last 25 years. 50 years later there were still hundreds of them running in regular service throughout the city. A prediction of breakage in 60 years does not mean that there will be breakage in 60 years. It easy to make predictions but it is not easy to foresee the real future. > > ARIN should completely avoid this type of policymaking. It is > > not the job of ARIN or any RIR to drive today's policy based upon > > the hypothetical needs of people 60 years from now. > > Hmm. I would've thought this would be pretty close to the actual > definition of "stewardship". No, I think it is closer to the definition of insanity. Stewardship is not the same as conservation. Stewardship refers to wise use of the resource. In my opinion, getting 60 years of use out of a network protocol is pretty darn good. As far as I know there is no network protocol (or telecoms protocol) that has survived that long other than Morse code. --Michael Dillon From Michael.Dillon at radianz.com Tue May 10 06:08:55 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Tue, 10 May 2005 11:08:55 +0100 Subject: [ppml] IPv6>>32 In-Reply-To: Message-ID: > > Final consideration, do you really believe in 50-100 years we will still > > be using IP at all ?. > > Yes, but, the more I learn about the current state of IPv6, the more I think > it will either be IPv4 or whatever replaces IPv6. This kind of thinking leads to surprises out of left field. If all current IPv4 network operators think this way, that does not mean that IPv6 will disappear. It means that IPv6 will be used by people outside the IP network mainstream and then suddenly one day we discover that every hospital in the world is filled with devices communicating over IPv6 and they want to cut costs of network connectivity by getting rid of their V6-V4 gateways. Or we discover that all cellphones use IPv6 on their internal networks and manufacturers are beginning to release componentized phones where you can mix and match transcievers, cameras, audio devices, amplifiers, radio tuners, etc. Suddenly IPv6 becomes the protocol of choice for home entertainment systems to interface with the componentized phones. And so on. What we have here is a failure of imagination. --Michael Dillon From Michael.Dillon at radianz.com Tue May 10 06:17:41 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Tue, 10 May 2005 11:17:41 +0100 Subject: [ppml] IPv6>>32 In-Reply-To: <6.0.1.1.2.20050510054214.032f0020@kahuna.telstra.net> Message-ID: > I'm not sure that we should be in the business of built in obsolescence, We are not talking about built-in obsolescence. Rather we are talking about TRUST. Do we trust the IP engineers and RIR members of the future to recognize when and if IPv6 addressing needs to be revised? Do we trust them to do the right thing? If we do, then the best course of action is to leave well-enough alone. We have shown that it is likely to work just find for many decades. In particular, Geoff Huston has shown that if there is a future need for a revised IPv6 addressing plan, there are lots of spare addresses to use for this great renumbering. It is premature to be changing the addressing scheme when we have so little experience with IPv6. In that repsect we simply are not qualified to make these decisions. We should leave this decision to the experts. And who are those experts? The engineers of the future who will have 10-20 years of IPv6 operational experience are the experts I am referring to. --Michael Dillon From owen at delong.com Tue May 10 06:23:09 2005 From: owen at delong.com (Owen DeLong) Date: Tue, 10 May 2005 03:23:09 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: References: Message-ID: <2147483647.1115695388@[172.17.1.152]> --On Tuesday, May 10, 2005 11:08 +0100 Michael.Dillon at radianz.com wrote: >> > Final consideration, do you really believe in 50-100 years we will > still >> > be using IP at all ?. >> >> Yes, but, the more I learn about the current state of IPv6, the more I > think >> it will either be IPv4 or whatever replaces IPv6. > > This kind of thinking leads to surprises out of left field. > If all current IPv4 network operators think this way, that does > not mean that IPv6 will disappear. It means that IPv6 will be > used by people outside the IP network mainstream and then suddenly > one day we discover that every hospital in the world is filled > with devices communicating over IPv6 and they want to cut > costs of network connectivity by getting rid of their V6-V4 > gateways. Or we discover that all cellphones use IPv6 on their > internal networks and manufacturers are beginning to release > componentized phones where you can mix and match transcievers, > cameras, audio devices, amplifiers, radio tuners, etc. Suddenly > IPv6 becomes the protocol of choice for home entertainment > systems to interface with the componentized phones. And so on. > > What we have here is a failure of imagination. What we have here is multiple failures: + The failure to accept TUBA as a bandaid and move forward recognizing that something better would take too long to develop given the anticipated constraints of the time. + The failure to meet the design goals of IPv6 and the consistent stripping down of those design goals until we found ourselves left essentially with TUBA plus stateless autoconfiguration. + The failure to deliver on the promise and requirement of easy renumbering. + The failure to recognize that IPv6 had to deliver at least the same capabilities as IPv4 both from a technology and an operational perspective before it would gain substantial acceptance. + The failure of the operational community to participate significantly in the development of IPv6 or to preserve the importance of several operational design goals that got lost along the way. + Failure to recognize that a GRT will not scale to IPv4 address exhaustion, let alone IPv6. + Failure to identify the need to separate the end system identifier role of an IP address from it's topological location identifier role. (full address is currently used as end system identifier, while prefix is used as topological identification identifier) + Failure to recognize that number portability is a real and meaningful need and that while CIDR and NAT were well accepted and well tolerated, they are hacks that come with a serious tradeoff and we need to find ways to restore a world where they are not needed. I can imagine lots of things, and, I can even imagine some ways in which we might be able to solve the above failures. However, I am not convinced from what I see that this will happen in IPv6. I am convinced that if at least some of these issues don't get addressed in IPv6, IPv6 will not become the default protocol on the internet because of it's substantial deficiencies compared to IPv4. You may disagree with my assessment of the situation, but, my imagination has not failed. It simply starts from a different world vision. Owen -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From Michael.Dillon at radianz.com Tue May 10 06:32:08 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Tue, 10 May 2005 11:32:08 +0100 Subject: [ppml] IPv6>>32 In-Reply-To: Message-ID: > People > need a way to switch providers without concern that they will have to change > their subnet plan. Some people will switch providers on a daily basis. Maybe even more than once per day. Consider a Vehicle Area Network installed in a refrigerated van filled with crates of vegetables. Each vegetable crate has it's own subnet. The refrigeration systems have several subnets for motors, motor control, coolant monitoring, circulation control. Then there are the various normal systems found in any vehicle, the driver's own Personal Area Network and his links into the corporate VPN. This will be a complex subnet plan more complex than found in most small businesses today. This VAN needs to be able to roam from one provider to another without resubnetting and in the evening when it is parked in the company facility, again, it needs to fit in as a node in the vast corporate network. > In any case it is wrong for an ISP to assume that the device at the end of a > particular link is an endpoint handset. I think this is the fundamental challenge of networking in this century. The current IPv4 network is rather small and can often be visualized as a hierarchy from Tier1 to provider core to pop to end site. Today this is a workable simplification in many instances. But the small IPv4 networks common today will be dwarfed by the scale and complexity of networks 50 years from now. In 50 years, it will be difficult to identify end-sites because many traditional end-sites will become gateways to other networks at least part of the time. > FUD simply states that we are wasting space because we are allocating more > than we have in the past. I think we are allocating less than in the past. In IPv4 we give a new ISP 20 bits of address space. In IPv6 we give him 32 bits in his prefix. Therefore the IPv6 ISP is getting a much smaller fraction of the total address space than the IPv4 ISP. These people who talk about waste simply do not understand IPv6 fundamentals. Either that, or their definition of "waste" doesn't match what I read in the dictionary. --Michael Dillon From terry.l.davis at boeing.com Tue May 10 11:31:36 2005 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Tue, 10 May 2005 08:31:36 -0700 Subject: [ppml] IPv6>>32 Message-ID: <6E5042539D21AF4E9C457B4DDCC3D6E108301DB3@xch-nw-21.nw.nos.boeing.com> Michael Good example. Imagine the problems we have today with aircraft that have an entire public /24 assigned to them and they move through several airports, that all have different ISP's, everyday docking and undocking. V4 never considered the idea that entire networks would "undock" from the Internet and then "move between continents" and attempt to "dock" with the Internet again. Take care Terry -----Original Message----- From: Michael.Dillon at radianz.com [mailto:Michael.Dillon at radianz.com] Sent: Tuesday, May 10, 2005 3:32 AM To: ppml at arin.net Subject: RE: [ppml] IPv6>>32 > People > need a way to switch providers without concern that they will have to change > their subnet plan. Some people will switch providers on a daily basis. Maybe even more than once per day. Consider a Vehicle Area Network installed in a refrigerated van filled with crates of vegetables. Each vegetable crate has it's own subnet. The refrigeration systems have several subnets for motors, motor control, coolant monitoring, circulation control. Then there are the various normal systems found in any vehicle, the driver's own Personal Area Network and his links into the corporate VPN. This will be a complex subnet plan more complex than found in most small businesses today. This VAN needs to be able to roam from one provider to another without resubnetting and in the evening when it is parked in the company facility, again, it needs to fit in as a node in the vast corporate network. > In any case it is wrong for an ISP to assume that the device at the end of a > particular link is an endpoint handset. I think this is the fundamental challenge of networking in this century. The current IPv4 network is rather small and can often be visualized as a hierarchy from Tier1 to provider core to pop to end site. Today this is a workable simplification in many instances. But the small IPv4 networks common today will be dwarfed by the scale and complexity of networks 50 years from now. In 50 years, it will be difficult to identify end-sites because many traditional end-sites will become gateways to other networks at least part of the time. > FUD simply states that we are wasting space because we are allocating more > than we have in the past. I think we are allocating less than in the past. In IPv4 we give a new ISP 20 bits of address space. In IPv6 we give him 32 bits in his prefix. Therefore the IPv6 ISP is getting a much smaller fraction of the total address space than the IPv4 ISP. These people who talk about waste simply do not understand IPv6 fundamentals. Either that, or their definition of "waste" doesn't match what I read in the dictionary. --Michael Dillon From david.conrad at nominum.com Tue May 10 12:18:53 2005 From: david.conrad at nominum.com (David Conrad) Date: Tue, 10 May 2005 09:18:53 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: <6E5042539D21AF4E9C457B4DDCC3D6E108301DB3@xch-nw-21.nw.nos.boeing.com> References: <6E5042539D21AF4E9C457B4DDCC3D6E108301DB3@xch-nw-21.nw.nos.boeing.com> Message-ID: <1E62FFDE-2D50-4CAB-A995-757F67EB2496@nominum.com> Terry, On May 10, 2005, at 8:31 AM, Davis, Terry L wrote: > V4 never considered the idea that entire networks would "undock" from > the Internet and then "move between continents" and attempt to "dock" > with the Internet again. While this might be true, it can be argued that given v6 uses the same routing technology as v4, v6 also doesn't consider the idea that networks can dock and undock. The same solution that is (at least theoretically) usable for IPv4 is what is being proposed for IPv6 -- provider independent addresses. Rgds, -drc From billd at cait.wustl.edu Tue May 10 12:33:57 2005 From: billd at cait.wustl.edu (Bill Darte) Date: Tue, 10 May 2005 11:33:57 -0500 Subject: [ppml] Proposed Policy: AfriNIC Recognition Policy Message-ID: This seems a straighforward conclusion to the anticipated withdrawal of this policy element. Given that the policy is no longer in force given the ARIN BoT suspension after the successful emergence and recognition of AfriNIC by ICANN, I support this proposal. And congratulations to AfriNIC http://www.afrinic.net/ once again... Bill Darte CAIT - Washington University in St. Louis > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Member Services > Sent: Monday, May 09, 2005 11:27 AM > To: ppml at arin.net > Subject: [ppml] Proposed Policy: AfriNIC Recognition Policy > > > ARIN received the following proposed policy. In accordance > with the ARIN Internet Resource Policy Evaluation Process, > the proposal is being posted to the ARIN Public Policy > Mailing List and being placed on ARIN's website. > > The ARIN Advisory Council will review the proposal and within > ten working days may decide to: > 1) support the proposal as is, > 2) work with the author to clarify, divide or combine one or > more policy proposals, or > 3) not support the policy proposal. > > If the AC supports the proposal or reaches an agreement to > work with the author, then the proposal will be posted as a > formal policy proposal to the Public Policy Mailing List and > it will be presented at the Public Policy Meeting. If the AC > does not support the proposal, then the author may elect to > use the petition process to advance the proposal. If the > author elects not to petition or the petition fails, then the > proposed policy will be considered closed. > > The ARIN Internet Resource Policy Evaluation Process can be > found at: http://www.arin.net/policy/ipep.html > > Mailing list subscription information can be found at: > http://www.arin.net/mailing_lists/index.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ### * ### > > > Policy Proposal Name: AfriNIC Recognition Policy > > Author: Andrew Dul > > Policy term: permanent > > Policy statement: Remove section 4.8 entitled "Policy for the > African Portion of the ARIN Region" of the NRPM. > > Rationale: The ARIN BoT recently suspended section 4.8 of the > NRPM upon recognition of AfriNIC as an RIR by ICANN. Section > 4.8 of the NRPM applied only to areas of the ARIN region that > are now covered by AfriNIC. > > Timetable for implementation: Within 30 days of ratification > by the BoT. > > From billd at cait.wustl.edu Tue May 10 12:42:39 2005 From: billd at cait.wustl.edu (Bill Darte) Date: Tue, 10 May 2005 11:42:39 -0500 Subject: [ppml] Proposed Policy: IPv6 HD ratio Message-ID: There has been great discussion on this list about aspects of IPv6 conservation beyond what the current policy specifies. One of the major components of that conservation discussion has been changing the HD Ratio for subsequent allocations. The change to .94 from .8 in the proposed policy change arises from work by Geoff Huston and his presentation at the ARIN XV meeting IPv6 Roundtable along with others. It seems to me following the various threads that there is little resistance to the HD Ratio change. Bill Darte CAIT - Washington University in St. Louis > > > > Policy Proposal Name: IPv6 HD ratio > > Author: Andrew Dul > > Policy term: permanent > > Policy statement: Change HD ratio used for IPv6 allocations to 0.94 > > This would modify sections 6.5.2.2 & 6.7 (including the > HD-ratio to percentage table) of the NRPM. > > Rationale: Recent research has shown that based upon certain > growth models the current IPv6 allocation policy using the HD > ratio of 0.8 will allocate between a /1 and /4 of Ipv6 > address space over the period of about 60 years. > > http://www.ietf.org/internet-drafts/draft-huston-ipv6-hd-metric-00.txt > > By changing the HD ratio to 0.94, this would require LIRs to > have a higher utilization of the /48s that are assigned to > end sites before being able to obtain additional allocations. > This policy would change the threshold for an LIR holding a > /32 from approximately 11% to 51%. An LIR with a /20 would > have a utilized percentage of approximately 31% vs. the current 2%. > > This policy may also prevent the hoarding of IPv6 addresses > by current organizations with large customer bases, but no > substantial current IPv6 network. > > Timetable for implementation: Within 30 days of ratification > by the BoT. > > > From L.Howard at stanleyassociates.com Tue May 10 12:45:49 2005 From: L.Howard at stanleyassociates.com (Howard, W. Lee) Date: Tue, 10 May 2005 12:45:49 -0400 Subject: [ppml] IPv6>>32 Message-ID: > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Michael.Dillon at radianz.com > Sent: Tuesday, May 10, 2005 6:32 AM > To: ppml at arin.net > Subject: RE: [ppml] IPv6>>32 > > > > People > > need a way to switch providers without concern that they > will have to > change > > their subnet plan. > > Some people will switch providers on a daily basis. Maybe > even more than once per day. Consider a Vehicle Area Network > installed in a refrigerated van filled with crates of > vegetables. Each vegetable crate has it's own > subnet. The refrigeration systems have several subnets for > motors, motor control, coolant monitoring, circulation > control. Then there are the > various > normal systems found in any vehicle, the driver's own Personal Area > Network > and his links into the corporate VPN. This will be a complex > subnet plan more complex than found in most small businesses > today. This VAN needs to be able to roam from one provider to > another without resubnetting and in the evening when it is > parked in the company facility, again, it needs to fit in as > a node in the vast corporate network. What size assignment do you advocate for a produce crate? Please extrapolate the lifetime of IPv6 if consumables get subnets. > > In any case it is wrong for an ISP to assume that the device at the > > end > of a > > particular link is an endpoint handset. > > I think this is the fundamental challenge of networking in > this century. The current IPv4 network is rather small and > can often be visualized as a hierarchy from Tier1 to provider > core to pop to end site. Today this is a workable > simplification in many instances. But the small IPv4 > networks > common today will be dwarfed by the scale and complexity of > networks 50 years from now. In 50 years, it will be difficult > to identify end-sites because many traditional end-sites will > become gateways to other networks > at least part of the time. What kind of addressing policy and routing system would you propose to scale to that kind of network? > > > FUD simply states that we are wasting space because we are > allocating > more > > than we have in the past. > > I think we are allocating less than in the past. In IPv4 we give > a new ISP 20 bits of address space. In IPv6 we give him 32 > bits in his prefix. Therefore the IPv6 ISP is getting a much > smaller fraction of the total address space than the IPv4 > ISP. These people who talk about waste simply do not > understand IPv6 fundamentals. Either that, or their > definition of "waste" doesn't match what I read in the dictionary. A smaller fraction for ISPs, but as you point out, there are many different kinds of entities that could get assignments. It seems to me that most arguments assume a higher rate of growth than the current curve. Lee > > --Michael Dillon > From L.Howard at stanleyassociates.com Tue May 10 12:51:10 2005 From: L.Howard at stanleyassociates.com (Howard, W. Lee) Date: Tue, 10 May 2005 12:51:10 -0400 Subject: [ppml] IPv6>>32 Message-ID: > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Tony Hain > Sent: Monday, May 09, 2005 5:09 PM > To: 'Randy Bush' > Cc: ppml at arin.net > Subject: RE: [ppml] IPv6>>32 > > Yes egregious waste of the address resource should be avoided, but so should > miserly conservation Looks to me like the debate is about the values of "egregious" and "miserly." Personally, I tend toward conservatism, on the basis that it's easier to loosen the sphincter than tighten it. Lee > Tony From terry.l.davis at boeing.com Tue May 10 12:52:28 2005 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Tue, 10 May 2005 09:52:28 -0700 Subject: [ppml] IPv6>>32 Message-ID: <6E5042539D21AF4E9C457B4DDCC3D6E108301E06@xch-nw-21.nw.nos.boeing.com> David True enough but someday still I hope to see something come out of research that isn't a tunnel back or a brute force BGP solution. And probably within the next couple years we will see how well provider independent addressing works. Take care Terry -----Original Message----- From: David Conrad [mailto:david.conrad at nominum.com] Sent: Tuesday, May 10, 2005 9:19 AM To: Davis, Terry L Cc: Michael.Dillon at radianz.com; ppml at arin.net Subject: Re: [ppml] IPv6>>32 Terry, On May 10, 2005, at 8:31 AM, Davis, Terry L wrote: > V4 never considered the idea that entire networks would "undock" from > the Internet and then "move between continents" and attempt to "dock" > with the Internet again. While this might be true, it can be argued that given v6 uses the same routing technology as v4, v6 also doesn't consider the idea that networks can dock and undock. The same solution that is (at least theoretically) usable for IPv4 is what is being proposed for IPv6 -- provider independent addresses. Rgds, -drc From randy at psg.com Tue May 10 12:55:31 2005 From: randy at psg.com (Randy Bush) Date: Tue, 10 May 2005 06:55:31 -1000 Subject: [ppml] Proposed Policy: IPv6 HD ratio References: Message-ID: <17024.59267.469594.794471@roam.psg.com> > One of the major components of that conservation discussion has been > changing the HD Ratio for subsequent allocations. The change to .94 from .8 > in the proposed policy change arises from work by Geoff Huston and his > presentation at the ARIN XV meeting IPv6 Roundtable along with others. > > It seems to me following the various threads that there is little resistance > to the HD Ratio change. i suspect that some folk may not understand all of the implications. heck, i probably don't. but one would seem to be that it makes it even harder for the smaller folk and not too much harder for the larger. randy From billd at cait.wustl.edu Tue May 10 12:59:25 2005 From: billd at cait.wustl.edu (Bill Darte) Date: Tue, 10 May 2005 11:59:25 -0500 Subject: [ppml] Proposed Policy: IPv6 HD ratio Message-ID: > > It seems to me following the various threads that there is little > > resistance to the HD Ratio change. > > i suspect that some folk may not understand all of the > implications. heck, i probably don't. but one would seem to > be that it makes it even harder for the smaller folk and not > too much harder for the larger. > > randy > Do you suggest a split level of HD Ratio requirement...one ratio for large and another for small? If so, where would the demarc be? Bill Darte From randy at psg.com Tue May 10 13:12:10 2005 From: randy at psg.com (Randy Bush) Date: Tue, 10 May 2005 07:12:10 -1000 Subject: [ppml] IPv6>>32 References: <6E5042539D21AF4E9C457B4DDCC3D6E108301E06@xch-nw-21.nw.nos.boeing.com> Message-ID: <17024.60266.817961.55106@roam.psg.com> > True enough but someday still I hope to see something come out of > research that isn't a tunnel back or a brute force BGP solution. >> V4 never considered the idea that entire networks would "undock" from >> the Internet and then "move between continents" and attempt to "dock" >> with the Internet again. > While this might be true, it can be argued that given v6 uses the > same routing technology as v4, v6 also doesn't consider the idea that > networks can dock and undock. well, some old dogs, and even some new dogs, are not to excited about basing decisions with long-term impact on things which have yet to pan out but we still hope some day might. to be mildly less polite, few if any of the the v6 133t's grand visions and promises seem to have panned out yet, routing is still the same, and we're trying to deal socially with a massive case of second system syndrome. yet we ops are struggling to do our best to deploy this half-designed but little different wobbly structure for which there are yet sufficient users to pay 10% of the costs we're incurring just in case we hit an address space problem. and we decry v4 nats while nats are slowly becoming more a part of what we are told to expect in v6 (every time we push hard enough on the routing table size question). so please hold back on the "we need to do X just in case Y, which has been promised all our lives, pans out some year." it's not that ops don't plan for the future; we just don't enjoy having to keep explaining to the the board why 4/5 of the future never seems to arrive on the income side of the income statement. randy --- Q: Because it reverses the logical flow of conversation. A: Why is top posting frowned upon? From randy at psg.com Tue May 10 13:16:56 2005 From: randy at psg.com (Randy Bush) Date: Tue, 10 May 2005 07:16:56 -1000 Subject: [ppml] Proposed Policy: IPv6 HD ratio References: Message-ID: <17024.60552.999155.847173@roam.psg.com> >>> It seems to me following the various threads that there is little >>> resistance to the HD Ratio change. >> i suspect that some folk may not understand all of the >> implications. heck, i probably don't. but one would seem to >> be that it makes it even harder for the smaller folk and not >> too much harder for the larger. > Do you suggest a split level of HD Ratio requirement...one ratio > for large and another for small? If so, where would the demarc > be? well, the rich get richer and the poor stay poor thing is a basic effect of the hd ratio. log functions are not linear, doh. and making it a step log would be ugly. how about 1 - log(n) ? while i do not mean that seriously, thinking about it might give the rich a small inkling of how the poor feel. randy From bicknell at ufp.org Tue May 10 13:21:39 2005 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 10 May 2005 13:21:39 -0400 Subject: [ppml] Proposed Policy: IPv6 HD ratio In-Reply-To: <17024.59267.469594.794471@roam.psg.com> References: <17024.59267.469594.794471@roam.psg.com> Message-ID: <20050510172139.GA25563@ussenterprise.ufp.org> In a message written on Tue, May 10, 2005 at 06:55:31AM -1000, Randy Bush wrote: > i suspect that some folk may not understand all of the implications. > heck, i probably don't. but one would seem to be that it makes it > even harder for the smaller folk and not too much harder for the larger. I have wondered why we don't use a flat measurement as we already do, simply relaxed to fit the additional v6 "free use of IP addresses". I have yet to see a good argument that large ISP's have significantly more waste. Most of them are based on IPv4 notions, where if you allocate a /20 to a POP to aggregate you have to justify all of the /20. In IPv6 you allocate it a /48 and that's that. Remembering that we're talking about allocated, and not in use, and from that perspective it seems IPv6 should be more efficient than IPv4, based on the current guidelines. I don't know what the number should be, but I'm thinking 50-65%. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From billd at cait.wustl.edu Tue May 10 13:05:06 2005 From: billd at cait.wustl.edu (Bill Darte) Date: Tue, 10 May 2005 12:05:06 -0500 Subject: [ppml] IPv6>>32 Message-ID: > > > Yes egregious waste of the address resource should be > avoided, but so > should > > miserly conservation > > Looks to me like the debate is about the values of > "egregious" and "miserly." Personally, I tend toward > conservatism, on the basis that it's easier to loosen the > sphincter than tighten it. > > Lee > > > Tony > But is 'misery' conservation the appropriate contrasting element. Is it that anything less than 65K subnets of 64 bits is 'miserly' or is the argument that that anything less may cause 'bureaucracy of address administration' when sites run out of addresses and have to come back? Bill Darte From narten at us.ibm.com Tue May 10 14:00:48 2005 From: narten at us.ibm.com (Thomas Narten) Date: Tue, 10 May 2005 14:00:48 -0400 Subject: [ppml] Proposed Policy: IPv6 HD ratio In-Reply-To: Message from randy@psg.com of "Tue, 10 May 2005 06:55:31 -1000." <17024.59267.469594.794471@roam.psg.com> Message-ID: <200505101800.j4AI0mQi030279@rotala.raleigh.ibm.com> Hi Randy. > > One of the major components of that conservation discussion has been > > changing the HD Ratio for subsequent allocations. The change to .94 from .8 > > in the proposed policy change arises from work by Geoff Huston and his > > presentation at the ARIN XV meeting IPv6 Roundtable along with others. > > > > It seems to me following the various threads that there is little resistance > > to the HD Ratio change. > i suspect that some folk may not understand all of the implications. > heck, i probably don't. but one would seem to be that it makes it > even harder for the smaller folk and not too much harder for the larger. I don't understand this. One of the observations made in Geoff's presentations is that something like 80% of all assignments are for the default /32 size. Changing the HD ratio threshhold will not impact those "smaller" sites at all. The impact will be on the larger sites, those that can justify more than the default /32. Under the proposed HD ratio value of .94, they will be able to obtain less space than under the current .8 threshold, but quite a lot more than under the IPv4 "80% utilization" threshhold. Thomas From alh-ietf at tndh.net Tue May 10 14:05:19 2005 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 10 May 2005 11:05:19 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: <20050510005720.GA88259@ussenterprise.ufp.org> Message-ID: <20050510180523.CEA2D143BBC@smtp2.arin.net> Leo Bicknell wrote: > ... > You did not say this directly, so I will ask directly. > > Am I correct in assuming that you believe 32 bits of host space (4 > billion hosts per subnet) is a constraint that qualifies as "miserly", > and that will lead to the adoption of IPv6 NAT? You appear to be focused on absolute utilization efficiency. CGA approaches like: http://www.ietf.cnri.reston.va.us/proceedings/02jul/slides/send-2/tsld003.ht m trade space efficiency for authenticity. Approaches like using RFC3041 addresses for everything trade utilization efficiency for immunity to scanning attacks. Maximizing allocation efficiency is simply one dimension in a multi-dimensional problem space. Tony From alh-ietf at tndh.net Tue May 10 14:06:02 2005 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 10 May 2005 11:06:02 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: Message-ID: <20050510180604.8368A143C1B@smtp2.arin.net> Bill Darte wrote: > > But is 'misery' conservation the appropriate contrasting element. Is it > that anything less than 65K subnets of 64 bits is 'miserly' or is the > argument that that anything less may cause 'bureaucracy of address > administration' when sites run out of addresses and have to come back? Stating that the allocation system will run out of addresses unless we provide for more than 10^14 customer demarcation points is being miserly. Yes there is loss in the system, but minimizing the pain in allocations is being directly traded against the pain in provider flexibility for the local network manager, and/or pain at the developer/innovator level in terms of available options. Until someone shows that they can actually efficiently consume 10^14 prefixes there is no reason to even consider changing the /48 issue. So far all we have is a presentation from Geoff & David that shows we know how to waste that much space through the currently generous HD ratio. Change that to a more appropriate value. To be clear I am not fixated on /48 because there are business interests overlaying this space that will want other values. What we need are a small number of clear bucket sizes that allow people to move between providers without having to rebuild there subnet structure. The only comment I have received on my draft so far is that we probably need to add /44 for very large organizations. I am opposed to the nonsense of 'IPv6 will never be real' because it doesn't fit an individual's perspective of perfection. IPv4 will run out of space before most people are ready to move, if for no other reason than they are being lulled into a state of unconsciousness by those who refuse to accept that change is inevitable. Tony From alh-ietf at tndh.net Tue May 10 14:05:56 2005 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 10 May 2005 11:05:56 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: Message-ID: <20050510180558.DB4EE143C03@smtp2.arin.net> Howard, W. Lee wrote: > Looks to me like the debate is about the values of "egregious" and > "miserly." > Personally, I tend toward conservatism, on the basis that it's easier to > loosen the sphincter than tighten it. In general the RIR community has become so accustomed to conservatism that they can't see any reason to even consider that they might be killing off innovation in the process. We are working in a multi-dimensional problem space. Consider it like a balloon where squeezing hard on one side to minimize the perceived local problem space causes problems in another area to expand. Yes the IETF has taken a position that causes the RIR side of the balloon to expand, but that was intentional to create some perspective of balance over the entire set. The amount of expansion is not that great, it just appears so for those who can't shift their focus off of squeezing the last drop out of the rapidly shrinking IPv4 pool. Tony From narten at us.ibm.com Tue May 10 14:08:02 2005 From: narten at us.ibm.com (Thomas Narten) Date: Tue, 10 May 2005 14:08:02 -0400 Subject: [ppml] Proposed Policy: IPv6 HD ratio In-Reply-To: Message from bicknell@ufp.org of "Tue, 10 May 2005 13:21:39 EDT." <20050510172139.GA25563@ussenterprise.ufp.org> Message-ID: <200505101808.j4AI829e030301@rotala.raleigh.ibm.com> Hi Leo. > I have wondered why we don't use a flat measurement as we already > do, simply relaxed to fit the additional v6 "free use of IP > addresses". One theory is that larger sites have multiple levels of hierarchy. At the lower levels of the hierarchy, one can presumably flat route, in which case high densities are achievable. But if you have a hierarchy (with aggregation), each level in the heirarchy will have a level of inherent inefficiency, and the total inefficiency is multiplicative. E.g., 80% utilization at level one combined with 80% utilization at the next level up is only 64% utilization when multiplied together. One of the arguments being made for moving the HD ratio threshhold upward is that a ratio of .8 is more in line with something like 12 levels of heirarchy in the network, a level that doesn't seem in line with reality. Thomas From bicknell at ufp.org Tue May 10 14:20:41 2005 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 10 May 2005 14:20:41 -0400 Subject: [ppml] IPv6>>32 In-Reply-To: <200505101805.j4AI5LP4027736@ussenterprise.ufp.org> <20050510005720.GA88259@ussenterprise.ufp.org> <20050509210834.CEC631451A2@smtp2.arin.net> References: <20050510005720.GA88259@ussenterprise.ufp.org> <200505101805.j4AI5LP4027736@ussenterprise.ufp.org> <17023.50500.24829.982688@roam.psg.com> <20050509210834.CEC631451A2@smtp2.arin.net> <20050510005720.GA88259@ussenterprise.ufp.org> <17023.50500.24829.982688@roam.psg.com> <20050509210834.CEC631451A2@smtp2.arin.net> Message-ID: <20050510182041.GA28204@ussenterprise.ufp.org> In a message written on Mon, May 09, 2005 at 02:08:33PM -0700, Tony Hain wrote: > will not need in 50 years is just wrong. Yes egregious waste of the address > resource should be avoided, but so should miserly conservation that > increases the market value of nat approaches. The /48-/64 units effectively > reduce the market value of nat to $0. Artificially constraining the space In a message written on Mon, May 09, 2005 at 08:57:20PM -0400, Leo Bicknell wrote: > You did not say this directly, so I will ask directly. > > Am I correct in assuming that you believe 32 bits of host space (4 > billion hosts per subnet) is a constraint that qualifies as "miserly", > and that will lead to the adoption of IPv6 NAT? In a message written on Tue, May 10, 2005 at 11:05:19AM -0700, Tony Hain wrote: > You appear to be focused on absolute utilization efficiency. CGA approaches > like: > http://www.ietf.cnri.reston.va.us/proceedings/02jul/slides/send-2/tsld003.ht > m > trade space efficiency for authenticity. Approaches like using RFC3041 > addresses for everything trade utilization efficiency for immunity to > scanning attacks. > > Maximizing allocation efficiency is simply one dimension in a > multi-dimensional problem space. You appear to be avoiding my question. In your original statement you said miserly conservation increases the market value of nat. I specifically asked if you considered 32 bits of host space miserly with respect to the adoption of IPv6 NAT. You then changed the subject to other things that more bits enable. I realize it is a multi-dimentional problem, but I asked a question about one specific dimension. I will be happy to address the merits of things like CGA after you answer my question. Is 32 bits of host space miserly such that it would lead to IPv6 NAT? -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From marla_azinger at eli.net Tue May 10 14:25:18 2005 From: marla_azinger at eli.net (Azinger, Marla) Date: Tue, 10 May 2005 11:25:18 -0700 Subject: [ppml] Proposed Policy: IPv6 HD ratio Message-ID: <10ECB7F03C568F48B9213EF9E7F790D201512210@wava00s2ke2k01.corp.pvt> I see the same thing from all the postings. However...keeping the scope of the proposal on track at the next conference is what will be a challenge. MA -----Original Message----- From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of Bill Darte Sent: Tuesday, May 10, 2005 9:43 AM To: ppml at arin.net Subject: RE: [ppml] Proposed Policy: IPv6 HD ratio There has been great discussion on this list about aspects of IPv6 conservation beyond what the current policy specifies. One of the major components of that conservation discussion has been changing the HD Ratio for subsequent allocations. The change to .94 from .8 in the proposed policy change arises from work by Geoff Huston and his presentation at the ARIN XV meeting IPv6 Roundtable along with others. It seems to me following the various threads that there is little resistance to the HD Ratio change. Bill Darte CAIT - Washington University in St. Louis > > > > Policy Proposal Name: IPv6 HD ratio > > Author: Andrew Dul > > Policy term: permanent > > Policy statement: Change HD ratio used for IPv6 allocations to 0.94 > > This would modify sections 6.5.2.2 & 6.7 (including the > HD-ratio to percentage table) of the NRPM. > > Rationale: Recent research has shown that based upon certain > growth models the current IPv6 allocation policy using the HD > ratio of 0.8 will allocate between a /1 and /4 of Ipv6 > address space over the period of about 60 years. > > http://www.ietf.org/internet-drafts/draft-huston-ipv6-hd-metric-00.txt > > By changing the HD ratio to 0.94, this would require LIRs to > have a higher utilization of the /48s that are assigned to > end sites before being able to obtain additional allocations. > This policy would change the threshold for an LIR holding a > /32 from approximately 11% to 51%. An LIR with a /20 would > have a utilized percentage of approximately 31% vs. the current 2%. > > This policy may also prevent the hoarding of IPv6 addresses > by current organizations with large customer bases, but no > substantial current IPv6 network. > > Timetable for implementation: Within 30 days of ratification > by the BoT. > > > From david.conrad at nominum.com Tue May 10 14:27:15 2005 From: david.conrad at nominum.com (David Conrad) Date: Tue, 10 May 2005 11:27:15 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: References: Message-ID: Michael, On May 10, 2005, at 3:32 AM, Michael.Dillon at radianz.com wrote: > Some people will switch providers on a daily basis. I am somewhat skeptical that people will switch providers as you suggest when it takes end-user intervention to implement that switch. Renumbering remains a non-trivial exercise. Connections break. Firewall rules change. Network management objects have to be updated. Etc. Until renumbering is addressed (no pun intended), I suspect the scenarios of *ANs switching providers rapidly will remain a fantasy. > I think we are allocating less than in the past. In IPv4 we give > a new ISP 20 bits of address space. In IPv6 we give him 32 bits > in his prefix. Therefore the IPv6 ISP is getting a much smaller > fraction of the total address space than the IPv4 ISP. Lies, damn lies, and fractions of address space. While what you say might be true, it is irrelevant. As far as I'm aware, no ISP (or anyone else, with the possible exception of the ITU) views the amount of address space they manage in terms of the fraction of total address space nor do I suspect they care. What they care about is having sufficient addresses to satisfy their customer requests and internal infrastructure demands. The fraction of address space they've been allocated is not a useful metric to judge sufficiency (IMHO). Rgds, -drc From bicknell at ufp.org Tue May 10 14:39:26 2005 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 10 May 2005 14:39:26 -0400 Subject: [ppml] Proposed Policy: IPv6 HD ratio In-Reply-To: References: Message-ID: <20050510183926.GA28933@ussenterprise.ufp.org> In a message written on Tue, May 10, 2005 at 11:42:39AM -0500, Bill Darte wrote: > It seems to me following the various threads that there is little resistance > to the HD Ratio change. Of the people who have voiced an opinion, I agree there is clearly agreement on the HD Ratio Change. However, I'm concerned that so far it is a relatively select group making comments. Almost all the comments for or against are from people who are either involved in the IETF process, or members of various RIR groups. I'm sure this is in part due to the fact that "Joe Random" ISP in the ARIN region probably isn't making IPv6 assignments at this time, and thus the addressing people who might otherwise speak up aren't saying anything. As much as I enjoy a good debate, as an AC member I think it's critical we dig into what the ARIN membership, and public in general want. In particular on this issue, I'd like to hear from people who are working for ISP's giving out IPv6 space at this time. While there are a few, there are some, and they are the only real world experience we have to draw on at this time. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From L.Howard at stanleyassociates.com Tue May 10 14:51:42 2005 From: L.Howard at stanleyassociates.com (Howard, W. Lee) Date: Tue, 10 May 2005 14:51:42 -0400 Subject: [ppml] IPv6>>32 Message-ID: > -----Original Message----- > From: Tony Hain [mailto:alh-ietf at tndh.net] > Sent: Tuesday, May 10, 2005 2:06 PM > To: 'Howard, W. Lee' > Cc: ppml at arin.net > Subject: RE: [ppml] IPv6>>32 > > > Howard, W. Lee wrote: > > Looks to me like the debate is about the values of "egregious" and > > "miserly." Personally, I tend toward conservatism, on the > basis that > > it's easier to loosen the sphincter than tighten it. > > In general the RIR community has become so accustomed to > conservatism that they can't see any reason to even consider > that they might be killing off innovation in the process. You attribute a motive where I don't believe there is enough evidence to do so. Is it possible that we're thoughtfully concerned, rather than reacting out of habit? It may be that active members of PPML have a breadth of imagination that allows for the possibility of address space exhaustion. Lee > Tony > > From L.Howard at stanleyassociates.com Tue May 10 15:12:58 2005 From: L.Howard at stanleyassociates.com (Howard, W. Lee) Date: Tue, 10 May 2005 15:12:58 -0400 Subject: [ppml] Proposed Policy: IPv6 HD ratio Message-ID: I tried to do some numbers on this recently, using large telco-ISPs, cable providers, and dial providers. If you assign /48 to end users (whether dial, cable, or T1/T3/x), and you have, say, 500 end users on a router, that's a /39 per router. Say you have several routers (or whatever L3 aggregation device) in a POP; let's reserve space for 8, you have /36 per POP. I don't know how many POPs you have in a metro area, but let's reserve 16, which I make to be /32 per metro area. If you carve your metro areas into regions (say, Northeast, Southwest, etc., in the US, or maybe national borders in other regions, within an AS) you might need another layer of hierarhcy, up to 16, so now within a rough continent, one large ISP needs a /28 in one part of the world. Because of the additional layers of hierarchy, a large ISP is assumed to have fewer customer assignments within its allocation than a smaller one. The ISP above may only have a couple of customers, but address space is reserved at each level of the hierarchy. Under some definition, that's less efficient. That's the argument, anyway. If you want, you can continue the thought exercise further and assume some level of competition (8-16 ISPs per region, 4 bits), maybe more customers on a single router (2000? 11 bits), and factor in the 6 continents (3 bits) and find yourself with a /10 used before we even start. Lee > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Leo Bicknell > Sent: Tuesday, May 10, 2005 1:22 PM > To: ppml at arin.net > Subject: Re: [ppml] Proposed Policy: IPv6 HD ratio > > > In a message written on Tue, May 10, 2005 at 06:55:31AM > -1000, Randy Bush wrote: > > i suspect that some folk may not understand all of the > implications. > > heck, i probably don't. but one would seem to be that it makes it > > even harder for the smaller folk and not too much harder for the > > larger. > > I have wondered why we don't use a flat measurement as we > already do, simply relaxed to fit the additional v6 "free use > of IP addresses". I have yet to see a good argument that > large ISP's have significantly more waste. Most of them are > based on IPv4 notions, where if you allocate a /20 to a POP > to aggregate you have to justify all of the /20. In IPv6 you > allocate it a /48 and that's that. Remembering that we're > talking about allocated, and not in use, and from that > perspective it seems IPv6 should be more efficient than IPv4, > based on the current guidelines. > > I don't know what the number should be, but I'm thinking 50-65%. > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org > From Ed.Lewis at neustar.biz Tue May 10 15:10:11 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Tue, 10 May 2005 15:10:11 -0400 Subject: [ppml] Proposed Policy: IPv6 HD ratio In-Reply-To: <20050510183926.GA28933@ussenterprise.ufp.org> References: <20050510183926.GA28933@ussenterprise.ufp.org> Message-ID: At 14:39 -0400 5/10/05, Leo Bicknell wrote: >However, I'm concerned that so far it is a relatively select group >making comments. Good observation... >As much as I enjoy a good debate, as an AC member I think it's >critical we dig into what the ARIN membership, and public in general >want. In particular on this issue, I'd like to hear from people >who are working for ISP's giving out IPv6 space at this time. While >there are a few, there are some, and they are the only real world >experience we have to draw on at this time. I don't work for an ISP, but have an interest in what's going on (and some time to devote to it). I have some questions about HD rations. At the last APNIC meeting there was a discussion about applying HD ration to IPv4 - in looking through APNIC's website I found this presentation (from a previous RIPE meeting): http://www.apnic.net/community/presentations/docs/ripe/ripe-48-pres-pwilson-hdratio.pdf Yes, this is about IPv4, but the background slides were enlightening to me. One of the critical factors in efficiency is the depth of the network hierarchy. For a cable system provider, the depth may be shallow, making it easy to fill up a stretch of addresses. For someone that is a wide area backbone provider, filling up the same stretch of addresses with hosts is harder. Question 1 - does the HD ratio inherently account for this? Regardless of the HD value that is. It's a log ratio...so maybe yes. If so, maybe it's just a question of what setting to use. Question 2 - should the hierarchy of the network design be something that the RIR ought to have to consider when judging which (if there is more than one) utilization metric to use? There's obviously the problem of an ISP having to expose internals to the RIR - who would want that - and there's the problem of the RIR then having to consider a flood of information. But, would this be worth it to get to squeeze out a few more bits? I suppose that it wouldn't be manageable to categorize an ISP into a "kind" - like home consumer market, business market, WAN services - and use that to determine what ration to use. Or would it? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From billd at cait.wustl.edu Tue May 10 15:11:52 2005 From: billd at cait.wustl.edu (Bill Darte) Date: Tue, 10 May 2005 14:11:52 -0500 Subject: [ppml] IPv6>>32 Message-ID: > > > Howard, W. Lee wrote: > > > Looks to me like the debate is about the values of "egregious" and > > > "miserly." Personally, I tend toward conservatism, on the > > basis that > > > it's easier to loosen the sphincter than tighten it. > > > > In general the RIR community has become so accustomed to > > conservatism that they can't see any reason to even consider > > that they might be killing off innovation in the process. > > You attribute a motive where I don't believe there is enough > evidence to do so. > > Is it possible that we're thoughtfully concerned, rather than > reacting out of habit? It may be that active members of PPML > have a breadth of imagination that allows for the possibility > of address space exhaustion. > > Lee > > > > Tony > > > > > If it were easy to abandon a pervasive standard, we would be further along the demand curve for v6. Fact is, anyone with enough v4 addresses and a functioning environment delivering sufficient value is not interested in change....net value of v6 today is more addresses. That's with a billion addresses announced. When its many trillions of v6 addresses announced and several more global layers of integration and economic foundation in the mix, the chance of migration to something new is gonna be near impossible. So I think the notion of looking at v6 with a sunset horizon of 60 or 100 years is not prudent. Plan for the long, long, long haul. Then if something new begins to emerge....that next promise of networking nirvana, where we'll never run out of ... and the IS and new way of changing....SO CHANGE.... But, in the absence of experience that says we can just 'change' when things get difficult, prudence says conservation of the limiting benefit of v6 seems reasonable to me. If we are going to apply innovation, then apply it to ways to achieve the renumbering promise, to make a routing environment that scales so that end-site v6 allocations won't break things.... Bill Darte From kloch at hotnic.net Tue May 10 15:24:25 2005 From: kloch at hotnic.net (Kevin Loch) Date: Tue, 10 May 2005 15:24:25 -0400 Subject: [ppml] Proposed Policy: IPv6 HD ratio In-Reply-To: <17024.59267.469594.794471@roam.psg.com> References: <17024.59267.469594.794471@roam.psg.com> Message-ID: <42810A69.8090504@hotnic.net> Randy Bush wrote: > i suspect that some folk may not understand all of the implications. > heck, i probably don't. but one would seem to be that it makes it > even harder for the smaller folk and not too much harder for the larger. You have it backwards: (utilization threshold %) HD=0.8 HD=0.94 /32 10.9% 51.4% /20 2.1% 31.2% The utilization threshold for a /20 is 15 times higher for /20 but only 5 times higher for a /32. There are some good reasons to consider a flat threshold, but as long as we are using HD it should at least be sane. Does anyone really think a 50% utilization rate is opressive? - Kevin From marla_azinger at eli.net Tue May 10 15:34:50 2005 From: marla_azinger at eli.net (Azinger, Marla) Date: Tue, 10 May 2005 12:34:50 -0700 Subject: [ppml] IPv6>>32 Message-ID: <10ECB7F03C568F48B9213EF9E7F790D209B13B@wava00s2ke2k01.corp.pvt> "Some people will switch providers on a daily basis. Maybe even more than once per day. Consider a Vehicle Area Network installed in a refrigerated van filled with crates of vegetables. Each vegetable crate has it's own subnet. The refrigeration systems have several subnets for motors, motor control, coolant monitoring, circulation control. Then there are the various normal systems found in any vehicle, the driver's own Personal Area Network and his links into the corporate VPN. This will be a complex subnet plan more complex than found in most small businesses today. This VAN needs to be able to roam from one provider to another without resubnetting and in the evening when it is parked in the company facility, again, it needs to fit in as a node in the vast corporate network." Lack of imagination is not a problem here...but lack of conservation and us of "Private IP Addresses" might be...not to mention this example above entertwines several distinct issues into one ball. Specifically, porting of IP Address space and lack of conservation. For this response...I am only addressing the later..."lack of conservation". I understand the whole concept of thinking into the future and what we might use "Public IP Addresses" for...but I have noticed a trend that when these "possibilities" are brought up...it seems to lack someone asking whether its "really a need" or just a "because I can" use of IP addresses. It would be beneficial for everyone to consider the difference between "what we can do and whether we need or should do". And if we are determined to do it...why not factor in conservation and use of "Private IP Addresses"? Maybe its just how I interpret things...but it just seems that when we "look to the future"...sometimes it appears "conservation" is replaced with "because I can". Marla Azinger Electric Lightwave -----Original Message----- From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of Michael.Dillon at radianz.com Sent: Tuesday, May 10, 2005 3:32 AM To: ppml at arin.net Subject: RE: [ppml] IPv6>>32 > People > need a way to switch providers without concern that they will have to change > their subnet plan. Some people will switch providers on a daily basis. Maybe even more than once per day. Consider a Vehicle Area Network installed in a refrigerated van filled with crates of vegetables. Each vegetable crate has it's own subnet. The refrigeration systems have several subnets for motors, motor control, coolant monitoring, circulation control. Then there are the various normal systems found in any vehicle, the driver's own Personal Area Network and his links into the corporate VPN. This will be a complex subnet plan more complex than found in most small businesses today. This VAN needs to be able to roam from one provider to another without resubnetting and in the evening when it is parked in the company facility, again, it needs to fit in as a node in the vast corporate network. > In any case it is wrong for an ISP to assume that the device at the end of a > particular link is an endpoint handset. I think this is the fundamental challenge of networking in this century. The current IPv4 network is rather small and can often be visualized as a hierarchy from Tier1 to provider core to pop to end site. Today this is a workable simplification in many instances. But the small IPv4 networks common today will be dwarfed by the scale and complexity of networks 50 years from now. In 50 years, it will be difficult to identify end-sites because many traditional end-sites will become gateways to other networks at least part of the time. > FUD simply states that we are wasting space because we are allocating more > than we have in the past. I think we are allocating less than in the past. In IPv4 we give a new ISP 20 bits of address space. In IPv6 we give him 32 bits in his prefix. Therefore the IPv6 ISP is getting a much smaller fraction of the total address space than the IPv4 ISP. These people who talk about waste simply do not understand IPv6 fundamentals. Either that, or their definition of "waste" doesn't match what I read in the dictionary. --Michael Dillon From gih at apnic.net Tue May 10 15:49:54 2005 From: gih at apnic.net (Geoff Huston) Date: Wed, 11 May 2005 05:49:54 +1000 Subject: [ppml] IPv6>>32 In-Reply-To: References: <6.0.1.1.2.20050510054214.032f0020@kahuna.telstra.net> Message-ID: <6.0.1.1.2.20050511053502.033835f0@kahuna.telstra.net> >If we do, then the best course of action is to leave >well-enough alone. We have shown that it is likely >to work just find for many decades. In particular, >Geoff Huston has shown that if there is a future need >for a revised IPv6 addressing plan, there are lots >of spare addresses to use for this great renumbering. > >It is premature to be changing the addressing scheme >when we have so little experience with IPv6. In that >repsect we simply are not qualified to make these decisions. >We should leave this decision to the experts. And who >are those experts? The engineers of the future who >will have 10-20 years of IPv6 operational experience >are the experts I am referring to. At which point the installed base will either be so large that the problem of inertial mass and potential inequities in distribution structures will effectively imply that any changes will be extremely tough (yes, we're visiting this space already in IPv4!), or the installed base will be insignificant, in which case the entire topic would be irrelevant. When to consider this is very much a public policy topic. While there is a temptation to leave well alone, from a public policy perspective we stand the risk of yet again visibly creating an early adopter reward and a corresponding late adopter set of barriers. I suspect that we have already exhausted any tolerance we may have enjoyed in the past on this type of behaviour and there is a strong impetus on the part of many developing populous economies not to see such a precise rerun of what they would call previous mistakes. This is not an abstract concept but one where we are already seeing proposals from the ITU-T to establish an alternative address distribution system that is based around this particular concern. In other words you may well believe that this is premature, but others, for valid reasons, see it as merely timely, while others see this as an urgent priority. regards, Geoff From gih at apnic.net Tue May 10 16:05:26 2005 From: gih at apnic.net (Geoff Huston) Date: Wed, 11 May 2005 06:05:26 +1000 Subject: [ppml] Proposed Policy: IPv6 HD ratio In-Reply-To: <17024.59267.469594.794471@roam.psg.com> References: <17024.59267.469594.794471@roam.psg.com> Message-ID: <6.0.1.1.2.20050511055408.03380ae0@kahuna.telstra.net> Randy Bush wrote: > > One of the major components of that conservation discussion has been > > changing the HD Ratio for subsequent allocations. The change to .94 > from .8 > > in the proposed policy change arises from work by Geoff Huston and his > > presentation at the ARIN XV meeting IPv6 Roundtable along with others. > > > > It seems to me following the various threads that there is little > resistance > > to the HD Ratio change. > >i suspect that some folk may not understand all of the implications. >heck, i probably don't. but one would seem to be that it makes it >even harder for the smaller folk and not too much harder for the larger. Interestingly I would actually say that if anything the effect of the change in the HD Ratio would be in the other direction. If the level of address allocation activity over the past 5 years in IPv4 is any indication (and in that period we've seen boom, bust and recovery) then some 80% of the registry transactions to ISP and LIRs would be a /32 or /31 irrespective of the HD Ratio choice, while some 2% of allocations would be larger than a /27. Unfortunately the dynamic nature of the ARIN XV agenda meant that a more detailed consideration of this topic was not able to happen at that meeting. The presentation I'd prepared on this topic is at http://www.potaroo.net/presentations/2005-04-11-IPv6-HD.pdf Slide 20 provides some observations arising from this study. One could offer the observation that changing the HD ratio makes effectively no difference to the smaller folk, but does provide some encouragement for the larger folk to consider their addressing plan with a little more care. regards, Geoff From gih at apnic.net Tue May 10 16:18:45 2005 From: gih at apnic.net (Geoff Huston) Date: Wed, 11 May 2005 06:18:45 +1000 Subject: [ppml] Proposed Policy: IPv6 HD ratio In-Reply-To: <20050510172139.GA25563@ussenterprise.ufp.org> References: <17024.59267.469594.794471@roam.psg.com> <20050510172139.GA25563@ussenterprise.ufp.org> Message-ID: <6.0.1.1.2.20050511061747.03b59eb0@kahuna.telstra.net> At 03:21 AM 11/05/2005, Leo Bicknell wrote: >In a message written on Tue, May 10, 2005 at 06:55:31AM -1000, Randy Bush >wrote: > > i suspect that some folk may not understand all of the implications. > > heck, i probably don't. but one would seem to be that it makes it > > even harder for the smaller folk and not too much harder for the larger. > >I have wondered why we don't use a flat measurement as we already >do, simply relaxed to fit the additional v6 "free use of IP addresses". >I have yet to see a good argument that large ISP's have significantly >more waste. Most of them are based on IPv4 notions, where if you >allocate a /20 to a POP to aggregate you have to justify all of the >/20. In IPv6 you allocate it a /48 and that's that. Remembering >that we're talking about allocated, and not in use, and from that >perspective it seems IPv6 should be more efficient than IPv4, based >on the current guidelines. > >I don't know what the number should be, but I'm thinking 50-65%. I would encourage you to have a look through the presentation http://www.potaroo.net/presentations/2005-04-11-IPv6-HD.pdf for a background to this area of consideration. regards, Geoff From randy at psg.com Tue May 10 16:31:06 2005 From: randy at psg.com (Randy Bush) Date: Tue, 10 May 2005 10:31:06 -1000 Subject: [ppml] IPv6>>32 References: Message-ID: <17025.6666.77658.917833@roam.psg.com> > Is it possible that we're thoughtfully concerned, rather than > reacting out of habit? It may be that active members of PPML > have a breadth of imagination that allows for the possibility > of address space exhaustion. as folk such as tony are repeating "the end of ipv4 space is neigh" on a daily basis, imagination is not required, only induction. randy From gih at apnic.net Tue May 10 16:29:26 2005 From: gih at apnic.net (Geoff Huston) Date: Wed, 11 May 2005 06:29:26 +1000 Subject: [ppml] Proposed Policy: IPv6 HD ratio In-Reply-To: References: <20050510183926.GA28933@ussenterprise.ufp.org> Message-ID: <6.0.1.1.2.20050511062341.03b5dc80@kahuna.telstra.net> >One of the critical factors in efficiency is the depth of the network >hierarchy. For a cable system provider, the depth may be shallow, making >it easy to fill up a stretch of addresses. For someone that is a wide >area backbone provider, filling up the same stretch of addresses with >hosts is harder. > >Question 1 - does the HD ratio inherently account for this? Regardless of >the HD value that is. It's a log ratio...so maybe yes. If so, maybe it's >just a question of what setting to use. You can map a particular HD ratio setting to the concept of a network that achieves a fixed efficiency setting at each level of internal hierarchy, and adds an additional level of hierarchy each time the network by a factor of n (for some value of n) An HD ratio of 0.94 corresponds to a 75% efficiency at each internal level of hierarchy, with a new level of hierarchy added when the network expands by a factor of 32 An HD ratio of 0.8 corresponds to a 70% efficiency at each level with a new level of hierarchy added each time the networks grows by a factor of 8. Geoff From randy at psg.com Tue May 10 16:39:51 2005 From: randy at psg.com (Randy Bush) Date: Tue, 10 May 2005 10:39:51 -1000 Subject: [ppml] Proposed Policy: IPv6 HD ratio References: <17024.59267.469594.794471@roam.psg.com> <6.0.1.1.2.20050511055408.03380ae0@kahuna.telstra.net> Message-ID: <17025.7191.909887.668458@roam.psg.com> >>> It seems to me following the various threads that there is little >>> resistance to the HD Ratio change. >> i suspect that some folk may not understand all of the implications. >> heck, i probably don't. but one would seem to be that it makes it >> even harder for the smaller folk and not too much harder for the larger. > Interestingly I would actually say that if anything the effect of the > change in the HD Ratio would be in the other direction. as thomas and a few other folk have pointed out privately, i should not type so much without coffee. randy From billd at cait.wustl.edu Tue May 10 16:41:02 2005 From: billd at cait.wustl.edu (Bill Darte) Date: Tue, 10 May 2005 15:41:02 -0500 Subject: [ppml] IPv6>>32 Message-ID: > > > Is it possible that we're thoughtfully concerned, rather > than reacting > > out of habit? It may be that active members of PPML have a > breadth of > > imagination that allows for the possibility of address space > > exhaustion. > > as folk such as tony are repeating "the end of ipv4 space is > neigh" on a daily basis, imagination is not required, only induction. > > randy > If by neigh you mean 3-5 years, then I suggest that ARIN strike up the band...wave the flag...and release the lawyers to go recover v4 space. I do not see v6 overcoming its vexing problems and satisfying a (yet inobvious) substantial demand for it maturing in the interim. Bill Darte From owen at delong.com Tue May 10 16:51:51 2005 From: owen at delong.com (Owen DeLong) Date: Tue, 10 May 2005 13:51:51 -0700 Subject: [ppml] Proposed Policy: IPv6 HD ratio In-Reply-To: <42810A69.8090504@hotnic.net> References: <17024.59267.469594.794471@roam.psg.com> <42810A69.8090504@hotnic.net> Message-ID: <017E5A6EF18DCCC48D932CFA@imac-en0.delong.sj.ca.us> > You have it backwards: > > (utilization threshold %) > HD=0.8 HD=0.94 > > /32 10.9% 51.4% > /20 2.1% 31.2% > > The utilization threshold for a /20 is 15 times higher for /20 > but only 5 times higher for a /32. > While that is technically true... I think that it is hard to say that 51.4% is not significantly harder than 31.2. The guy with the /32 would still have almost twice the burden of the guy with the /20. > There are some good reasons to consider a flat threshold, but as long > as we are using HD it should at least be sane. Does anyone really think > a 50% utilization rate is opressive? > No, but, I really think a 31% rate is liberal. I think that the HD ratio isn't necessarily the correct approach. The inherent assumption that hierarchical complexity is geometrically proportional to total address space does not fit with my experience. As such, I think we're trying to use one approximation as an input into a forumula to determine another approximation and then taking the inverse log of the rounding error. Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From bicknell at ufp.org Tue May 10 16:57:41 2005 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 10 May 2005 16:57:41 -0400 Subject: [ppml] Proposed Policy: IPv6 HD ratio In-Reply-To: <6.0.1.1.2.20050511061747.03b59eb0@kahuna.telstra.net> References: <17024.59267.469594.794471@roam.psg.com> <20050510172139.GA25563@ussenterprise.ufp.org> <6.0.1.1.2.20050511061747.03b59eb0@kahuna.telstra.net> Message-ID: <20050510205741.GA33690@ussenterprise.ufp.org> In a message written on Wed, May 11, 2005 at 06:18:45AM +1000, Geoff Huston wrote: > I would encourage you to have a look through the presentation > http://www.potaroo.net/presentations/2005-04-11-IPv6-HD.pdf > for a background to this area of consideration. I find myself twisted up thinking about this, so let's see if I can explain myself clearly. I believe the current HD Ratio implies a linear relationship between network size and levels of hierarchy. Specifically, every 3 bits (factor of 8) you get one more level of hierarchy. Changing the HD ratio changes the number of bits to get one more level, but does not change the linear relationship. If we start with a /32 having a base of "N" layers of hierarchy, we have potentially 10 layers more for someone with a /2. We don't know what N is for any particular provider (and indeed, it will vary from provider to provider), but I suspect N for most providers today is somewhere on the order of 1-6 layers. This gives us a total range of 1-16 layers. The problem is, 16 layers seems like a bit much. Even being generous with a progression like World -> Continent -> Country -> Region -> State -> County -> City -> MSA -> MSO -> Customer we're at only 10 layers, and most people aren't going to divide the address space at all of those boundaries. Also, as the number of layers increase, the lack of efficiency in the smallest ones make less difference. A provider with a /20 will have no issues with an MSO not having a single customer in it. I think the growth of hierarchy is what grows logarithmically. The more layers you add, the slower you add layers. Going from a /32 to a /30 you might add one layer, but the next layer will take you to a /26, and the next layer to a /18. I'm not sure how you turn a logarithmic growth in hierarchy into a formula that makes sense though. At the same time, I wonder if it's overly complex. If we're going to require the biggest people to have ~50% efficiency, why not just require that of everyone? Why are we holding the smaller people to a tighter standard that they will simply be able to relax with size? Philosophically it doesn't make a lot of sense to me. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From paul at vix.com Tue May 10 17:03:40 2005 From: paul at vix.com (Paul Vixie) Date: Tue, 10 May 2005 21:03:40 +0000 Subject: [ppml] IPv6>>32 In-Reply-To: Your message of "Mon, 09 May 2005 21:17:14 GMT." Message-ID: <20050510210340.1B54E13CDF@sa.vix.com> jordi, i'm asking again, and still in public, because i want to either firmly establish these facts, or forever put an end to these urban legends, and only you seem to be able to help decide which it will be. > > I mean core routers, not access routers, not CPEs. > > all core routers? or only some of them? which ones, made by whom, when? paul From L.Howard at stanleyassociates.com Tue May 10 18:02:51 2005 From: L.Howard at stanleyassociates.com (Howard, W. Lee) Date: Tue, 10 May 2005 18:02:51 -0400 Subject: [ppml] IPv6>>32 Message-ID: > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Tony Hain > Sent: Monday, May 09, 2005 6:57 PM > To: 'Randy Bush' > Cc: ppml at arin.net > Subject: RE: [ppml] IPv6>>32 > > > Randy Bush wrote: > > > IPv6 deployment is gated by lack of applications and/or a crisis. > > > The crisis is looming > > > > shall we have a game to see who can list the crises which > were about > > to explode v6 deployment which have loomed in the last decade? > > > > don't get me wrongly. i will not be at all unhappy if ipv6 > moves from > > k00la1d to reality. but, for a decade, i have had this problem of > > seeing the emperor's attire, and i don't see it today. > perhaps it's my > > aging eyes. > > Those would be the same ones that claim to see that 8k times > the number of bits that got us 30 years (while arguably > loosely managed and including > hosts) will be insufficient to get us past 100 years (by only > indicating the customer demarc). 45 bits is a very large space. I think that argument is a little misleading. Extrapolating (32 bits / 30 years) = (64 bits / 60 years) assumes that past performance is a predictor of future allocation [1]. The problem, as I like to frame it, is that if we take the attitude that IPv6 is infinite, then addresses or subnets will be assigned to consumables, consumed, and never reused. I see lots of engineers-cum-science-fiction-writers who talk about potential uses for IPv6, all of which seem to me to argue against themselves; they seem to say there will be such demand that we can't afford to be careful now. Especially since produce-truck drivers, nanobots, and complex molecules, are not ISPs as currently defined by policy. If these clusters are going to be sliding gracefully from network to network with their /48s, then the /32 aggregation goal is blown. The magic of a /64 is that it's a single routable entity. If I assume that layer 3 networks connect layer 2 networks, I still haven't seen any argument here about what a layer 2 network of 2^64 devices would look like. It's not only inconceivable, it's inconceivable to (2^32) power or more, and then we say that we have to assign this enormous set of numbers in groups of 2^16. The /48 rule applied equally to every possible definition of end user is arbitrary and reckless. I will concede that in IPv6 terms, a /48 is reasonable for the enterprise network, but I just can't understand how it's more responsible to assign this much to every node on the theory that in someone's wildest dreams, any node could someday be a router. If a node does someday become a router, is renumbering one device (possibly to a /48) insurmountable? Even if it is, is there any barrier to the household (or cellular, or vehicular) router routing (or switching) /96 subnets within the /64? Presumably, my blinds will never have a host address (EUI-64, MAC, or whatever) that conflicts with my vacuum cleaner. Oh, for the record, Geoff Huston's model said we'd consume a /1 to a /4 in 60 years; at the rate of one /1 every 60 years, we run out of IPv6 space in 120 years. Lee [1] OK, technically it assumes an exponential progression, but a predictable exponent. And I don't think most people see that. > > You can drop the bubble-hype of 'it didn't happen in 6 months > so it isn't real'. We knew going in that it would take a > decade to make a massive change to the infrastructure, and > all hype aside we are not getting it done any quicker by > wasting time fighting nay-sayers. If you choose to slam into > the wall when the address pool runs out that is your choice. > Some of us want to enable others to avoid the problems that > will create. > > Tony > > From david.conrad at nominum.com Tue May 10 18:16:58 2005 From: david.conrad at nominum.com (David Conrad) Date: Tue, 10 May 2005 15:16:58 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: <20050510180604.8368A143C1B@smtp2.arin.net> References: <20050510180604.8368A143C1B@smtp2.arin.net> Message-ID: On May 10, 2005, at 11:06 AM, Tony Hain wrote: > To be clear I am not fixated on /48 because there are business > interests > overlaying this space that will want other values. What we need are > a small > number of clear bucket sizes that allow people to move between > providers > without having to rebuild there subnet structure. Perhaps we should have 3 buckets. The first would be a /56, the second a /48, and the third, a /40. Just for fun, let's call them class C, B, and A respectively... (ironic half :-)) > IPv4 will run out of space > before most people are ready to move, if for no other reason than > they are > being lulled into a state of unconsciousness by those who refuse to > accept > that change is inevitable. I doubt IPv4 will ever run out. As the unallocated pool of IPv4 becomes smaller and, as a result, RIRs policies and procedures become even more unfair and draconian, people will either (a) migrate to IPv6, (b) NAT themselves so they only use a couple IP addresses, or (c) obtain the addresses they need from the black/gray market. Assuming the market will be allowed to exist (and I'd argue it will whether or not the RIRs accept the fact), I suspect a combination of (b) and (c) will satisfy the needs of most folks unable/unwilling/ unmotivated to do (a). Speaking only for myself of course, but the way things are going, in the end I'm afraid Paul Francis's NUTSS (Nats, Uris, Tunnels, Sip, and Stun) "architecture" will win out. I personally would prefer a world in which there was a clear and obvious reason to migrate to end- to-end IPv6, e.g., deployable multi-homing and/or trivial renumbering, instead of FUD with questionable basis. However, to date, I haven't see that reason. Rgds, -drc From david.conrad at nominum.com Tue May 10 18:33:23 2005 From: david.conrad at nominum.com (David Conrad) Date: Tue, 10 May 2005 15:33:23 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: References: Message-ID: <79D0B492-AB99-4A98-BF2C-4A53D0BDC37A@nominum.com> Michael, On May 10, 2005, at 3:02 AM, Michael.Dillon at radianz.com wrote: >> For me, the sentiment derives from the discomfort of knowingly >> deploying something that is (arguably) broken. > I can understand this. It is common among technical people > and artists. You seek perfection. Err, no. I'm in the software business, I gave up on perfection long ago. :-) I think it more accurate to say I prefer to make new mistakes instead of repeating old ones. > Stewardship is not the same as conservation. Stewardship refers > to wise use of the resource. I agree. I guess my feeling is that "wise use" precludes profligate waste on the off chance that someone will, at some point in the lifetime of IPv6, come up with a cool application that absolutely requires 2^80 "endpoint identifiers". Rgds, -drc From gih at apnic.net Tue May 10 18:39:19 2005 From: gih at apnic.net (Geoff Huston) Date: Wed, 11 May 2005 08:39:19 +1000 Subject: [ppml] Proposed Policy: IPv6 HD ratio In-Reply-To: <017E5A6EF18DCCC48D932CFA@imac-en0.delong.sj.ca.us> References: <17024.59267.469594.794471@roam.psg.com> <42810A69.8090504@hotnic.net> <017E5A6EF18DCCC48D932CFA@imac-en0.delong.sj.ca.us> Message-ID: <6.0.1.1.2.20050511083626.032ba870@kahuna.telstra.net> >No, but, I really think a 31% rate is liberal. I think that the HD ratio >isn't necessarily the correct approach. The inherent assumption that >hierarchical complexity is geometrically proportional to total address >space does not fit with my experience. As such, I think we're trying to >use one approximation as an input into a forumula to determine another >approximation and then taking the inverse log of the rounding error. Better actual data would help here, without doubt. APNIC is conducting a survey of its members at the moment to gain more information about network structure and address plans (results to be presented at APNIC 20 in September), but of course more information and data here is always helpful to the overall process. Geoff From randy at psg.com Tue May 10 21:12:32 2005 From: randy at psg.com (Randy Bush) Date: Tue, 10 May 2005 15:12:32 -1000 Subject: [ppml] IPv6>>32 References: <20050510180604.8368A143C1B@smtp2.arin.net> Message-ID: <17025.23552.128824.453879@roam.psg.com> > I doubt IPv4 will ever run out. As the unallocated pool of IPv4 > becomes smaller and, as a result, RIRs policies and procedures become > even more unfair and draconian perhaps, as a board member of an rir, you could explain why you conscience unfair and draconian policies? randy From david.conrad at nominum.com Tue May 10 21:18:15 2005 From: david.conrad at nominum.com (David Conrad) Date: Tue, 10 May 2005 18:18:15 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: <17025.23552.128824.453879@roam.psg.com> References: <20050510180604.8368A143C1B@smtp2.arin.net> <17025.23552.128824.453879@roam.psg.com> Message-ID: Forgive me. A vain attempt at being ironic. I left off the smiley. I, of course, do not consider RIR polices to be unfair or draconian. In fact, I feel the current mechanisms by which policies are defined are better than they have ever been. Also, to be clear, I am not speaking as a board member on this list. Hope that clears up any possible confusion. Rgds, -drc Not speaking for anyone but myself. On May 10, 2005, at 6:12 PM, Randy Bush wrote: >> I doubt IPv4 will ever run out. As the unallocated pool of IPv4 >> becomes smaller and, as a result, RIRs policies and procedures become >> even more unfair and draconian >> > > perhaps, as a board member of an rir, you could explain why you > conscience unfair and draconian policies? > > randy > > From owen at delong.com Wed May 11 02:39:04 2005 From: owen at delong.com (Owen DeLong) Date: Tue, 10 May 2005 23:39:04 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: References: Message-ID: <2147483647.1115768343@[172.17.1.152]> > > I think that argument is a little misleading. Extrapolating > (32 bits / 30 years) = (64 bits / 60 years) assumes that past > performance is a predictor of future allocation [1]. > It's also mathematically incorrect. (32 bits/30 years) generally should approximate (33 bits/60 years). Even allowing for growth rate, I don't see us using 2^32 times as much space in twice the time (which is the ratio between 32 bits and 64 bits). (this expands on Lee's [1] below). > The magic of a /64 is that it's a single routable entity. If I > assume that layer 3 networks connect layer 2 networks, I still > haven't seen any argument here about what a layer 2 network of > 2^64 devices would look like. It's not only inconceivable, it's > inconceivable to (2^32) power or more, and then we say that we > have to assign this enormous set of numbers in groups of 2^16. > Agreed. > [1] OK, technically it assumes an exponential progression, but a > predictable exponent. And I don't think most people see that. > Yeah... That one. :-) Owen -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From Michael.Dillon at radianz.com Wed May 11 05:23:42 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Wed, 11 May 2005 10:23:42 +0100 Subject: [ppml] IPv6>>32 In-Reply-To: <1E62FFDE-2D50-4CAB-A995-757F67EB2496@nominum.com> Message-ID: > While this might be true, it can be argued that given v6 uses the > same routing technology as v4, v6 also doesn't consider the idea that > networks can dock and undock. Docking and undocking are the same thing as switching providers. IPv6 *DOES* consider this idea. That is why every end-site is given a fixed size /48 block of addresses. That way their subnet plan stays intact when they switch providers, whether or not they do it several times a day or once every few years. --Michael Dillon From Michael.Dillon at radianz.com Wed May 11 05:40:38 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Wed, 11 May 2005 10:40:38 +0100 Subject: [ppml] IPv6>>32 In-Reply-To: Message-ID: > What size assignment do you advocate for a produce crate? Please > extrapolate the lifetime of IPv6 if consumables get subnets. I would use a /64 per crate. Each crate will have a network of somewhere between 6 and 12 sensors monitoring air temperature, humidity, condensation/juice on the crate floor, concentration of ethylene gas, and a 3-axis accelerometer. There will likely also be an LCD panel as well to identify the contents and physical destination. > What kind of addressing policy and routing system would you propose > to scale to that kind of network? Much the same as the existing IPv6 policy except that I think we could have a cap on the HD ratio to limit the size of a single allocation. If people actually do outgrow an allocation then they can come back later and get more at a time when we have more data and experience. As for routing, I think you know about my support for a geographical addressing hierarchy outside of 2000::/3. This would be based on a detailed plan for address deployment covering the entire globe in a way that could be fully agregated along existing fiber pathways. That means it ignores national borders and sees the world as a collection of cities/towns connected by greater/lesser quantities of fiber. And this plan would also only use a fraction of the IPv6 space no larger than twice the size of 2000::/3. The intention is that the current addressing plan and the geographic plan should compete in the marketplace and in a decade or so, when we know more about what really works and how things are developping, we could revise or replace both plans. In the interim, the geographical addressing plan minimizes consumption of slots in the global routing table. The most important aspects of this are that there are two distinctly different variations of addressing plan that compete and the IPv6 space has enough reserve to completely replace both plans and still have space left in reserve. This is the only plan that can scale. People who have direct experience with scaling either networks or businesses or chemical plants know that unforeseen factors cause you to change your assumptions and change your plans. We need to expect the unexpected and plan to be surprised and plan enough reserves to adapt to those surprises. > > I think we are allocating less than in the past. In IPv4 we give > > a new ISP 20 bits of address space. In IPv6 we give him 32 > > bits in his prefix. Therefore the IPv6 ISP is getting a much > > smaller fraction of the total address space than the IPv4 > > ISP. These people who talk about waste simply do not > > understand IPv6 fundamentals. Either that, or their > > definition of "waste" doesn't match what I read in the dictionary. > > A smaller fraction for ISPs, but as you point out, there are many > different kinds of entities that could get assignments. It seems to > me that most arguments assume a higher rate of growth than the > current curve. Nevertheless, today in IPv4 we give a /32 to a single interface on a single device, sometimes mistakenly referred to as a "host". In IPv6 we give that same /32 to an organization running a large network with at least two levels of hierarchy, namely the organization's own network and the networks of the end-sites. In many cases, these end-sites also have 2 levels of hierarchy, but not in all cases. This is already very much more scalable than IPv4. --Michael Dillon From Michael.Dillon at radianz.com Wed May 11 05:57:34 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Wed, 11 May 2005 10:57:34 +0100 Subject: [ppml] IPv6>>32 In-Reply-To: <20050510180604.8368A143C1B@smtp2.arin.net> Message-ID: > The only comment I have > received on my draft so far is that we probably need to add /44 for very > large organizations. Very large organizations are not very static places. They split off bits of themselves into other organizations and aggregate other organizations into themselves on a regular basis. I don't think there is any case for allowing for more than a /48 to large organizations. Most large organizations are more likely to approach providers for several /48's with each /48 used to service some subset of the whole organization. I just can't see a scenario in which all traffic in a large organization will want to use a single gateway. However, I'm not opposed to defining a second smaller subnet size at the /56 boundary. Then ISPs can give organizations a choice between SMALL or LARGE end-site allocations. Residential customer and Vehicle Area Networks would fall into the SMALL category. The LARGE category would include organizations who operate many VANs or multiple sites. Then, when a VAN leaves the mother ship and needs to connect to a wireless hotspot, the ISP is already geared up to support /56 end-sites. However, if we do allow for /56 subsets we need to have some clear guidance where they should be used, and where they should not be used, otherwise people who are making subnet plans for a /48 end-site will incorrectly use the /56 boundary inside their networks where they should use smaller blocks. Consider a warehouse with 40 loading docks and a fleet of 100 trucks based there. The trucks should each get a /56 but the warehouse itself really only needs a /64 or maybe a /62. Any alternatives to /48 need to be clearly explained with many examples. --Michael Dillon From Michael.Dillon at radianz.com Wed May 11 06:07:12 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Wed, 11 May 2005 11:07:12 +0100 Subject: [ppml] IPv6>>32 In-Reply-To: Message-ID: > > Some people will switch providers on a daily basis. > > I am somewhat skeptical that people will switch providers as you > suggest when it takes end-user intervention to implement that > switch. Renumbering remains a non-trivial exercise. Connections > break. Firewall rules change. Network management objects have to be > updated. Etc. Until renumbering is addressed (no pun intended), I > suspect the scenarios of *ANs switching providers rapidly will remain > a fantasy. All those problems will be solved when people realise that they need to be solved to run IP networks in airplanes, buses, trains, cars, freight trucks, delivery vans, etc. The expansion of Wi-Fi Internet access combined with on-board IP networks will drive the innovation. Look at IPv4. When renumbering became a problem, some people created a new protcol, DHCP and created the software needed to make automatic renumbering work. I myself use it to change providers twice every day when my laptop moves from my home to my office and back again. I am confident that the IPv6 world will solve this problem too. > > I think we are allocating less than in the past. In IPv4 we give > > a new ISP 20 bits of address space. In IPv6 we give him 32 bits > > in his prefix. Therefore the IPv6 ISP is getting a much smaller > > fraction of the total address space than the IPv4 ISP. > > Lies, damn lies, and fractions of address space. While what you say > might be true, it is irrelevant. As far as I'm aware, no ISP (or > anyone else, with the possible exception of the ITU) views the amount > of address space they manage in terms of the fraction of total > address space You are wrong there. If by ITU you are referring to phone numbers, that number space is unlimited because they can add digits. So they cannot concern themselves with fractions of total space. But if you read some of Geoff Huston's work you will see that there are people who do concern themselves with fractions of IPv4 and IPv6 space. The entire IPv6 addressing plan, e.g. choice of 2000://3 and /48 boundaries, was made after considering fractions of the IPv6 space. --Michael Dillon From Michael.Dillon at radianz.com Wed May 11 06:14:45 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Wed, 11 May 2005 11:14:45 +0100 Subject: [ppml] Proposed Policy: IPv6 HD ratio In-Reply-To: <20050510183926.GA28933@ussenterprise.ufp.org> Message-ID: > As much as I enjoy a good debate, as an AC member I think it's > critical we dig into what the ARIN membership, and public in general > want. And now we get to the crux of the issue. The decay of ARIN as a membership organization. Why does ARIN not operate a mailing list for members to discuss policy, etc.? There is no way for members to communicate. A few members are on this public policy mailing list. A few members attend meetings. The vast majority just pay their fees and get their addresses. But policy is determined, not by ARIN members but by the industry elite who sit on the ARIN advisory council and the board of trustees. I really think this is a bad thing because we all become out of touch with what is happening in the network provider industry. Not all sectors of the industry operate in the same way or have the same problems or view the world in the same way. Diversity leads to strength and the policy discussions are not as diverse as they should be. --Michael Dillon From Michael.Dillon at radianz.com Wed May 11 06:34:57 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Wed, 11 May 2005 11:34:57 +0100 Subject: [ppml] IPv6>>32 In-Reply-To: <6.0.1.1.2.20050511053502.033835f0@kahuna.telstra.net> Message-ID: > >We should leave this decision to the experts. And who > >are those experts? The engineers of the future who > >will have 10-20 years of IPv6 operational experience > >are the experts I am referring to. > > At which point the installed base will either be so large that > the problem of inertial mass and potential inequities in distribution > structures will effectively imply that any changes will be extremely > tough Good! I respect the skills of the people who will be on the front lines in 20 years. I am happy that they have a tough challenge and real problems to solve. I would hate to create a future in which people don't need to think and solve problems. At the same time, I know that another massive entrenched network is being transitioned as we speak and the engineers of the future will have the benefit of that experience. In the UK we are beginning to transition the entire PSTN voice network onto an IP/MPLS core network. This will be 50% complete in 2008 and 100% in 2010. I expect that other large PSTN networks will make similar transitions over the next 20 years. > While there is a temptation to leave well alone, from > a public policy perspective we stand the risk of yet again visibly > creating an early adopter reward and a corresponding late adopter > set of barriers. This is a much more important concern than conservation or trying to reach perfection. I agree that the early adopter reward should be minimized and that is why I support adjusting the HD ratio and even capping the size of a single allocation to force the very large networks to return to the RIRs after the early adopter stage and after we have more experience. > I suspect that we have already exhausted any > tolerance we may have enjoyed in the past on this type > of behaviour and there is a strong impetus on the part of many > developing populous economies not to see such a precise rerun > of what they would call previous mistakes. This is not an abstract > concept but one where we are already seeing proposals from > the ITU-T to establish an alternative address distribution system > that is based around this particular concern. I believe that these types of concerns from developing economies can be alleviated by introducing geographic addressing that takes the RIR continentally aggregated addresses of IPv4 to another level or two of detail. In addition because that, in effect, creates a competitive market between the two addressing systems, I think we can alleviate the concerns that address policy is being created in an ivory tower. --Michael Dillon From bicknell at ufp.org Wed May 11 08:23:59 2005 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 11 May 2005 08:23:59 -0400 Subject: [ppml] Proposed Policy: IPv6 HD ratio In-Reply-To: References: <20050510183926.GA28933@ussenterprise.ufp.org> Message-ID: <20050511122359.GB65324@ussenterprise.ufp.org> In a message written on Wed, May 11, 2005 at 11:14:45AM +0100, Michael.Dillon at radianz.com wrote: > And now we get to the crux of the issue. The decay of ARIN > as a membership organization. Why does ARIN not operate a mailing > list for members to discuss policy, etc.? There is no way for > members to communicate. A few members are on this public policy > mailing list. A few members attend meetings. The vast majority > just pay their fees and get their addresses. > > But policy is determined, not by ARIN members but by the > industry elite who sit on the ARIN advisory council and > the board of trustees. Whoa. I find this personally offensive. The AC does not make policy. The AC's role is clearly laid out in http://www.arin.net/policy/irpep.html. The part you don't see is that after every public policy meeting we meet and discuss what policies had consensus. It's not about what AC members want, it's about what was voiced in the meetings, on the mailing list, and in the halls. We talk about if the community supports the action or not. Although some of the AC members (such as myself) are quite vocal and passionate on various issues, when it comes to deciding what the community wants I believe you'll find us very humble, and looking to what the community decided. Which is exactly why I composed my original message. In order to do my job at the next meeting, I need to know what the community is thinking. I do that by reading the mailing list, listening to speakers at the meetings, and talking to various people in the hallways at the meetings. I also consider the source. The AC and BoT carry less weight in the evaluation of "community consensus", at least with me because of their positions. Finally, this is the list for members to communicate. ARIN has a /Public/ policy process. You don't need to be an ARIN member to introduce a policy, or attend a meeting. There is no elite here, there is a completely open and transparent process with no exclusions. ARIN members who are interested in policy, can and do speak up on this list. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From william at elan.net Wed May 11 08:54:49 2005 From: william at elan.net (william(at)elan.net) Date: Wed, 11 May 2005 05:54:49 -0700 (PDT) Subject: [ppml] IPv6>>32 In-Reply-To: References: Message-ID: On Wed, 11 May 2005 Michael.Dillon at radianz.com wrote: >> While this might be true, it can be argued that given v6 uses the >> same routing technology as v4, v6 also doesn't consider the idea that >> networks can dock and undock. > > Docking and undocking are the same thing as switching providers. > IPv6 *DOES* consider this idea. That is why every end-site is > given a fixed size /48 block of addresses. That way their > subnet plan stays intact when they switch providers, whether > or not they do it several times a day or once every few years. And lets not forget this very important point and not argue for having system where providers can assign blocks of different size. /48 is VERY good number and will accommodate almost ever end-site and uniformity in assignments will greatly help MIP (Mobil IP) and non-bgp based multihoming. So I don't think we should change /48 and I dont think we should be so worried about running out of ip6 addresses, we really do have enough of them. That does not however mean that its bad idea to change HD ratio as it does appear to waste too much space for large companies whose userbase may not be growing as much as HD ratio would allow for. -- William Leibzon Elan Networks william at elan.net From Michael.Dillon at radianz.com Wed May 11 08:55:49 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Wed, 11 May 2005 13:55:49 +0100 Subject: [ppml] Proposed Policy: IPv6 HD ratio In-Reply-To: <20050511122359.GB65324@ussenterprise.ufp.org> Message-ID: > > But policy is determined, not by ARIN members but by the > > industry elite who sit on the ARIN advisory council and > > the board of trustees. > > Whoa. I find this personally offensive. The AC does not make > policy. The AC's role is clearly laid out in > http://www.arin.net/policy/irpep.html. *sigh* I know what the documents say. But I am not talking about documents. I am referring to the real world operational nitty gritty of how ARIN's policies have been made in the past 2 years. You are an AC member and therefore you are a member of the industry elite whether you like it or not. However, I was one of the founding members of the ARIN AC so as a former AC member, that also makes me a member of this elite. How many people who are not current or trustees or AC members, actually participate in ARIN policy discussions and what percentage of the membership does that represent? In my opinion it is miniscule and that is a bad thing. > It's not about > what AC members want, it's about what was voiced in the meetings, > on the mailing list, and in the halls. We talk about if the community > supports the action or not. This community is primarily composed of the industry elite. In England that community of consensus used to be called "the nobility". Later it was referred to as the "landed gentry". Elites can form communities, but ARIN has a duty to its members and to the larger community of Internet users, to draw in participation from a wider circle. I don't see that happening and in fact, over the past 2 years, I see the circle diminishing in size somewhat. For instance, I reccognize the name of every person who is currently on the AC and I believe I have personally met all but two of them even though I don't get to very many industry conferences (e.g. NANOG, ARIN, RIPE). Average of one a year. To me that indicates too much concentration of old-timers and members of a small closed group. In a body with 15 members serving an industry as big as the North American Internet, I believe that there should be more people who I have never heard of. It is not necessary for people to be ARIN groupies or industry old-timers in order to make a solid contribution on the AC. There needs to be more diversity of views and more diversity of backgrounds in the mix. > Finally, this is the list for members to communicate. Does this list have at least one participant from each ARIN member? I think not. This is the PUBLIC policy mailing list; a free for all where anyone who wants to can discuss policy. But it is definitely not a vehicle for ARIN members to communicate with each other and voice concerns to other parts of the ARIN organization. > You don't need to be an ARIN member to > introduce a policy, or attend a meeting. I have no argument with being open to public input. However I believe that such input is more useful when it fills an oversight role, commenting on the actions and planned actions of ARIN. I believe that this oversight role is SEVERELY impaired because there is no ARIN members forum. If there was such a forum, you would see it proposing things from the IP network operators' point of view, and then the public comment on this list would temper those proposals with the public's point of view. > there is a completely open and transparent process with no exclusions. > ARIN members who are interested in policy, can and do speak up on > this list. The Communist Party of the Soviet Union was similarly open to comment with no exclusions. However, in practice, it was rare for such comments to be made. The end result is that the organization ossified, made lots of stupid decisions, and was eventually destroyed when people discovered that they didn't have to put up with it any more. It is not enough for an organization to be open on paper. It needs to be seen to be open in actual practice. And I don't think this is happening with ARIN. I think ARIN is beginning to ossify because it lacks a supply of new blood with new ideas. --Michael Dillon From billd at cait.wustl.edu Wed May 11 09:05:47 2005 From: billd at cait.wustl.edu (Bill Darte) Date: Wed, 11 May 2005 08:05:47 -0500 Subject: [ppml] Proposed Policy: IPv6 HD ratio Message-ID: Michael, > And now we get to the crux of the issue. The decay of ARIN > as a membership organization. Why does ARIN not operate a > mailing list for members to discuss policy, etc.? There is no > way for members to communicate. A few members are on this > public policy mailing list. A few members attend meetings. > The vast majority just pay their fees and get their addresses. > > But policy is determined, not by ARIN members but by the > industry elite who sit on the ARIN advisory council and the > board of trustees. > > I really think this is a bad thing because we all become > out of touch with what is happening in the network provider > industry. Not all sectors of the industry operate in the same > way or have the same problems or view the world in the same > way. Diversity leads to strength and the policy > discussions are not as diverse as they should be. > > --Michael Dillon > You often make enlightened and insightful statements. This email was not such an example. The Advisory Council makes NO policy. Policy is proffered by those that have an interest. The AC evaluates policy statements for clarity and/or applicability. It judges consensus by those that participate. I suspect your response to that statement, is to itemize "applicability" as the AC's unfair throttling by we 'industry elite'. Fat chance that I should be 'accused' of being an industry elite...though I'm willing to own up to it if you'll write my boss to tell her that, as such, I should be elevated in rank or salary. I'm classic democracy! I'm a nobody who takes all this seriously and wants to ensure that ALL sides get heard. You were in favor....sponsored....using HD Ratios for v4. That proposal received a fair hearing by those that participated. That proposal did not receive a consensus endorsement. That proposal resurfaced and was NOT forwarded because of the recent consensus failure. The policy proposal safeguard of your rights to circumvent the AC was followed by you. It received another airing...the proposal was introduced needing only 'minimal industry support', but failed to achieve such endorsement. The AC did not defeat this proposal. Lack of support for this proposal by those that participate defeated it. You could neither activate participation nor support for the proposal. Who's fault is that? As for participation. Explain to me how a 'members list' would entice any more participation than the 'ppml list' and access to email addresses of all AC and BoT members? Would your HD Ratio proposal have garnered more support on yet another list? How would YOU suggest that ARIN generate greater participation? ARIN wants and invites participation. It IS an open and transparent organization. My feeling is that ARIN gets less participation than you or I or all of ARIN would like, because people do not perceive themselves to be negatively affected. If they do, they feel that that is their ISPs fault. I wish ALL ISPs would advise their customers about ARIN and encourage them to become familiar with and participate in the process of determining their Internet numbers policy future. I wish all ISPs did! I do believe that ARIN itself could outreach to more entities if you and others think that that is an appropriate expenditure of your $$$. Though so many people felt strongly about the last national elections...where there was tremendous exposure and money spend by both parties, party-supporting action committees, endorsements by celebrities, media exposure....and everyone KNOWS that the outcomes WILL affect them personally and financially........ turnout for the election was still poor. Who's fault is that? Bill Darte ARIN AC CAIT - Washington University in St. Louis From billd at cait.wustl.edu Wed May 11 09:17:14 2005 From: billd at cait.wustl.edu (Bill Darte) Date: Wed, 11 May 2005 08:17:14 -0500 Subject: [ppml] Proposed Policy: IPv6 HD ratio Message-ID: Michael, > > > Finally, this is the list for members to communicate. > > Does this list have at least one participant from > each ARIN member? I think not. This is the PUBLIC > policy mailing list; a free for all where anyone who > wants to can discuss policy. But it is definitely not > a vehicle for ARIN members to communicate with each other > and voice concerns to other parts of the ARIN organization. Who stops them? Are they encouraged to participate? ARIN-Announce enjoins them. They KNOW ARIN exists. They choose NOT to participate... I can only assume because they do NOT feel violated or..... > > > The Communist Party of the Soviet Union was similarly open > to comment with no exclusions. However, in practice, it was > rare for such comments to be made. The end result is that the > organization ossified, made lots of stupid decisions, and was > eventually destroyed when people discovered that they didn't > have to put up with it any more. It is not enough for an > organization to be open on paper. It needs to be seen to be > open in actual practice. And I don't think this is happening > with ARIN. I think ARIN is beginning to ossify because it lacks a > supply of new blood with new ideas. > > --Michael Dillon > That ARIN is a 'landed gentry' with NO land...or another 'communist party' ossifying and needing their attention. FUD! It's so common place today to scare and coerse those that have superficial understanding and are subject to emotional manipulation by those with a real axe to grind....industry elite or not. Bill Darte CAIT - Washington University in St. Louis From Michael.Dillon at radianz.com Wed May 11 09:38:23 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Wed, 11 May 2005 14:38:23 +0100 Subject: [ppml] Proposed Policy: IPv6 HD ratio In-Reply-To: Message-ID: > You often make enlightened and insightful statements. This email was not > such an example. The Advisory Council makes NO policy. But the AC is part of the process. In any case, I am not attacking the AC. I am attacking the small group of insiders who currently form policy. I happen to be part of that group so I'm attacking me as well, but not the AC per se. If I had wanted to attack the AC itself then I would have focused on their omnibus rewrite of the entire ARIN policy set. > Fat > chance that I should be 'accused' of being an industry elite...though I'm > willing to own up to it if you'll write my boss to tell her that, as such, I > should be elevated in rank or salary. Maybe I should say "industry insider" then. > You could neither activate participation nor > support for the proposal. Who's fault is that? That is the fault of ARIN in toto for preventing the ARIN membership from easily communicating with each other, and by not trying to broaden participation in the ARIN policy making process. Whether the HD ratio idea for IPv4 is good or bad, it just didn't get much discussion at all. There just aren't very many people out there looking at policy proposals and commenting on them. > As for participation. Explain to me how a 'members list' would entice any > more participation than the 'ppml list' and access to email addresses of all > AC and BoT members? Well, it would allow a member to communicate directly with the agreggate membership rather than to the public, the AC or the BoT. > Would your HD Ratio proposal have garnered more support > on yet another list? First of all, it is not *MY* proposal. The HD ratio for IPv4 is something that originated in the APNIC region and I believe it was Paul Wilson who started it all. Policies do not belong to individuals. And secondly, I am not writing about the HD ratio policy in particular. It is just one of many policies that did not get a very good airing in terms of diverse viewpoints. This lack of diversity impacts successful proposals as much as unsuccessful ones. > How would YOU suggest that ARIN generate greater > participation? 1. Make a member-only list and add at least one contact person for each member. Offer every member the possibility to have other people from their organization added to the list. In the interests of transparency, archive it in a publicly accessible form so that all can read but only members can post. No doubt, if the public wishes to comment, they will take the discussion to the PPML. 2. Assign a staff member to actively solicit participation on the PPML from non-member organizations who could or should have an interest in IP addressing. Actively embrace organizations like the NANPA council and the ITU who, have different perspectives and experience. I wonder how many of you have read the NANPA address allocation policies and examined their reporting spreadsheets. I know that IP addresses are not phone numbers, but understanding how other groups do their work provides perspective. > My feeling is that ARIN gets less participation than you or I or all of ARIN > would like, because people do not perceive themselves to be negatively > affected. I agree. But it is a bad trend for ARIN as an organization especially now that the authority of ARIN and all RIRs is being openly questioned in the ITU and the United Nations. It is not wise to wait for angry people who are negatively affected to demand ARIN action. We need to be more proactive so that ARIN is seen to be *MANAGING* IP addressing rather than merely reacting. > I do believe that ARIN itself > could outreach to more entities if you and others think that that is an > appropriate expenditure of your $$$. As I understand it, that is a decision for the BoT. I am hoping that by raising the issue here we can have some public discussion and convince the BoT that it is worth examining the issue and possibly, expending some resources in this direction. > turnout for the election was still poor. > Who's fault is that? The fault of all the people who make elections into an emotional argument devoid of facts and a popularity contest for a Stalinesque father figure. So far, ARIN has been rather more sober and ARIN policymaking has been rather more focused on facts and public examination of alternative courses of action. Not perfect by any means, but better than the TV driven drama of last autumn. --Michael Dillon From L.Howard at stanleyassociates.com Wed May 11 10:50:33 2005 From: L.Howard at stanleyassociates.com (Howard, W. Lee) Date: Wed, 11 May 2005 10:50:33 -0400 Subject: [ppml] Proposed Policy: IPv6 HD ratio Message-ID: > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Michael.Dillon at radianz.com > Sent: Wednesday, May 11, 2005 8:56 AM > To: ppml at arin.net > Subject: Re: [ppml] Proposed Policy: IPv6 HD ratio > How many people who are not current or trustees or AC > members, actually participate in ARIN policy discussions and > what percentage of the membership does that represent? In my > opinion it is miniscule and that is a bad thing. It looks to me like people become AC and BoT members because they participate. So, when members of the public participate, they're asked to run for election; when elected, they become "31337" and should no longer particpate? > This community is primarily composed of the industry elite. Only by virtue of being composed of the people who post. > In England that community of consensus used to be called > "the nobility". Later it was referred to as the "landed > gentry". Elites can form communities, but ARIN has a duty to > its members and to the larger community of Internet users, to draw in > participation from a wider circle. I don't see that happening > and in fact, over the past 2 years, I see the circle > diminishing in size somewhat. Economic downturn, corporate downsizing, more work per person. . . people don't have as much time to read and post to mailing lists. > For instance, I reccognize the name of every person who is > currently on the AC and I believe I have personally met > all but two of them even though I don't get to very many > industry conferences (e.g. NANOG, ARIN, RIPE). Average of one > a year. To me that indicates too much concentration of > old-timers and members of a small closed group. Part of the problem is that we have people who have too much experience? > In a body > with 15 members serving an industry as big as the North > American Internet, I believe that there should be more people > who I have never heard of. It is not necessary for people to > be ARIN groupies or industry old-timers in > order to make a solid contribution on the AC. There needs > to be more diversity of views and more diversity of > backgrounds in the mix. There's something concrete you can do about this: http://www.arin.net/elections/nominate.html Now open! > planned actions of ARIN. I believe that this oversight > role is SEVERELY impaired because there is no ARIN > members forum. If there was such a forum, you would see > it proposing things from the IP network operators' > point of view, and then the public comment on this list > would temper those proposals with the public's point > of view. arin-discuss at arin.net "Provides a forum for the member community to discuss ARIN-specific issues such as fee structures and internal policies." http://www.arin.net/mailing_lists/index.html Huh, what do you know, the most recent post was from Michael Dillon, Oct 24, 2003. > > there is a completely open and transparent process with no > exclusions. > > ARIN members who are interested in policy, can and do speak > up on this > > list. > > The Communist Party of the Soviet Union was similarly open > to comment with no exclusions. However, in practice, it was > rare for such comments to be made. The end result is that the > organization ossified, made lots of stupid decisions, and was > eventually destroyed when people discovered that they didn't > have to put up with it any more. It is not enough for an > organization to be open on paper. It needs to be seen to be > open in actual practice. And I don't think this is happening > with ARIN. I think ARIN is beginning to ossify because it lacks a > supply of new blood with new ideas. I think we're pretty well open to new contributions. Frequently, when someone posts for the first time, they get a couple of private messages saying, "Thanks for posting! Keep it up!" Same with comments at the mike at the public policy meetings. We love new people. So, all you lurkers, say something! Lee > --Michael Dillon > From terry.l.davis at boeing.com Wed May 11 11:15:19 2005 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Wed, 11 May 2005 08:15:19 -0700 Subject: [ppml] IPv6>>32 Message-ID: <6E5042539D21AF4E9C457B4DDCC3D6E108301FEA@xch-nw-21.nw.nos.boeing.com> Michael >> > Some people will switch providers on a daily basis. >> >> I am somewhat skeptical that people will switch providers as you >> suggest when it takes end-user intervention to implement that >> switch. Renumbering remains a non-trivial exercise. Connections >> break. Firewall rules change. Network management objects have to be >> updated. Etc. Until renumbering is addressed (no pun intended), I >> suspect the scenarios of *ANs switching providers rapidly will remain >> a fantasy. > >All those problems will be solved when people realise that they >need to be solved to run IP networks in airplanes, buses, trains, >cars, freight trucks, delivery vans, etc. The expansion of Wi-Fi >Internet access combined with on-board IP networks will drive the >innovation. Look at IPv4. When renumbering became a problem, some >people created a new protcol, DHCP and created the software needed >to make automatic renumbering work. I myself use it to change providers >twice every day when my laptop moves from my home to my office and >back again. I am confident that the IPv6 world will solve this >problem too. > I absolutely agree. And it does not necessarily even have to occur with a new network protocol. The new generation of "network aware" applications is re-defining the old definition of "connected" to deal with a world where "network connectivity" is forever changing (i.e. like mobile platforms) and sometimes only available for a few minutes at a time with ever changing ISP's. Take care Terry PS: First instance of a DHCP prototype was originally developed for a business need by a corporation then shown to the Internet community. From marla_azinger at eli.net Wed May 11 12:31:46 2005 From: marla_azinger at eli.net (Azinger, Marla) Date: Wed, 11 May 2005 09:31:46 -0700 Subject: [ppml] Proposed Policy: IPv6 HD ratio/ Really public involvment Message-ID: <10ECB7F03C568F48B9213EF9E7F790D209B13C@wava00s2ke2k01.corp.pvt> >From my experience I have found there are a large number of people within the Internet Community that read about 75% of these postings. They also form an opinion. However, they refrain from commenting. Why? I have been told by many..."because you already said what I was thinking" or "because I dont like speaking or commenting in public forum so I just wait until someone else says what I'm thinking." Now granted, this leaves those of us that do publicly participate thinking there is only a small number of us who pay attention and voice our concerns...when really...people use those of us that are comfortable with "public forum" to do their talking. I'm sure if someone felt their "views" were not being stated by someone else already...they would speak up. That is how I ended up at the mic for the first time several conferences ago. This is also what brought several government offices to the last conference and up to the Mic. Maybe we should adjust our view. Right now there are some who view a low number of "public speakers" as a bad thing. Maybe, it is actually a sign of success? Maybe those that do speak up publically already have a wide variety of opinions therefore leaving the rest of the internet community satisified that their concerns are already being voiced? Just a thought. Marla Azinger Electric Lightwave -----Original Message----- From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of Howard, W. Lee Sent: Wednesday, May 11, 2005 7:51 AM To: 'Michael.Dillon at radianz.com'; ppml at arin.net Subject: RE: [ppml] Proposed Policy: IPv6 HD ratio > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Michael.Dillon at radianz.com > Sent: Wednesday, May 11, 2005 8:56 AM > To: ppml at arin.net > Subject: Re: [ppml] Proposed Policy: IPv6 HD ratio > How many people who are not current or trustees or AC > members, actually participate in ARIN policy discussions and > what percentage of the membership does that represent? In my > opinion it is miniscule and that is a bad thing. It looks to me like people become AC and BoT members because they participate. So, when members of the public participate, they're asked to run for election; when elected, they become "31337" and should no longer particpate? > This community is primarily composed of the industry elite. Only by virtue of being composed of the people who post. > In England that community of consensus used to be called > "the nobility". Later it was referred to as the "landed > gentry". Elites can form communities, but ARIN has a duty to > its members and to the larger community of Internet users, to draw in > participation from a wider circle. I don't see that happening > and in fact, over the past 2 years, I see the circle > diminishing in size somewhat. Economic downturn, corporate downsizing, more work per person. . . people don't have as much time to read and post to mailing lists. > For instance, I reccognize the name of every person who is > currently on the AC and I believe I have personally met > all but two of them even though I don't get to very many > industry conferences (e.g. NANOG, ARIN, RIPE). Average of one > a year. To me that indicates too much concentration of > old-timers and members of a small closed group. Part of the problem is that we have people who have too much experience? > In a body > with 15 members serving an industry as big as the North > American Internet, I believe that there should be more people > who I have never heard of. It is not necessary for people to > be ARIN groupies or industry old-timers in > order to make a solid contribution on the AC. There needs > to be more diversity of views and more diversity of > backgrounds in the mix. There's something concrete you can do about this: http://www.arin.net/elections/nominate.html Now open! > planned actions of ARIN. I believe that this oversight > role is SEVERELY impaired because there is no ARIN > members forum. If there was such a forum, you would see > it proposing things from the IP network operators' > point of view, and then the public comment on this list > would temper those proposals with the public's point > of view. arin-discuss at arin.net "Provides a forum for the member community to discuss ARIN-specific issues such as fee structures and internal policies." http://www.arin.net/mailing_lists/index.html Huh, what do you know, the most recent post was from Michael Dillon, Oct 24, 2003. > > there is a completely open and transparent process with no > exclusions. > > ARIN members who are interested in policy, can and do speak > up on this > > list. > > The Communist Party of the Soviet Union was similarly open > to comment with no exclusions. However, in practice, it was > rare for such comments to be made. The end result is that the > organization ossified, made lots of stupid decisions, and was > eventually destroyed when people discovered that they didn't > have to put up with it any more. It is not enough for an > organization to be open on paper. It needs to be seen to be > open in actual practice. And I don't think this is happening > with ARIN. I think ARIN is beginning to ossify because it lacks a > supply of new blood with new ideas. I think we're pretty well open to new contributions. Frequently, when someone posts for the first time, they get a couple of private messages saying, "Thanks for posting! Keep it up!" Same with comments at the mike at the public policy meetings. We love new people. So, all you lurkers, say something! Lee > --Michael Dillon > From Scott.Shackelford at cox.com Wed May 11 13:22:02 2005 From: Scott.Shackelford at cox.com (Scott.Shackelford at cox.com) Date: Wed, 11 May 2005 13:22:02 -0400 Subject: [ppml] Proposed Policy: IPv6 HD ratio/ Really public involvment Message-ID: Agreed. See....you said what I was thinking. ;-) It's what I've referred to in the past (and which has many applications) as the 80/20 rule in that 80% of the discussion and activity is generated by 20% of the population or attendees. There is no way around the fact that there tend to be cliques among and within the ARIN community, but that's not to say that it's any one person or committees fault. Naturally, birds of a feather.......well, you know the rest. In the few times that I've been to the microphone or have perhaps tried to engage in an offline conversation, I've always found openness and interest from other members, AC folk and the like. It appears to me that the nature of this community has been that the same people are rehashed in their roles and capacities mainly because they're interested in making a difference....which is the point to begin with, right? To Michaels end, I agree that it may not be a bad idea to come up with an idea to try and introduce other members to participate, but I seem to recall that outreaching efforts such as this have often times fallen short of the desired expectations. At which point you have to ask if it's worth the time and/or energy to reach out beyond the standard methods that are in place or do you just continue with what you have? Regards, Scott Shackelford IP Engineer/IP Administrator Cox Communications Office: 404-269-7312 IM: cypscott -----Original Message----- From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On Behalf Of Azinger, Marla Sent: Wednesday, May 11, 2005 12:32 PM To: Howard, W. Lee; Michael.Dillon at radianz.com; ppml at arin.net Subject: RE: [ppml] Proposed Policy: IPv6 HD ratio/ Really public involvment >From my experience I have found there are a large number of people within the Internet Community that read about 75% of these postings. They also form an opinion. However, they refrain from commenting. Why? I have been told by many..."because you already said what I was thinking" or "because I dont like speaking or commenting in public forum so I just wait until someone else says what I'm thinking." Now granted, this leaves those of us that do publicly participate thinking there is only a small number of us who pay attention and voice our concerns...when really...people use those of us that are comfortable with "public forum" to do their talking. I'm sure if someone felt their "views" were not being stated by someone else already...they would speak up. That is how I ended up at the mic for the first time several conferences ago. This is also what brought several government offices to the last conference and up to the Mic. Maybe we should adjust our view. Right now there are some who view a low number of "public speakers" as a bad thing. Maybe, it is actually a sign of success? Maybe those that do speak up publically already have a wide variety of opinions therefore leaving the rest of the internet community satisified that their concerns are already being voiced? Just a thought. Marla Azinger Electric Lightwave -----Original Message----- From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of Howard, W. Lee Sent: Wednesday, May 11, 2005 7:51 AM To: 'Michael.Dillon at radianz.com'; ppml at arin.net Subject: RE: [ppml] Proposed Policy: IPv6 HD ratio > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Michael.Dillon at radianz.com > Sent: Wednesday, May 11, 2005 8:56 AM > To: ppml at arin.net > Subject: Re: [ppml] Proposed Policy: IPv6 HD ratio > How many people who are not current or trustees or AC > members, actually participate in ARIN policy discussions and > what percentage of the membership does that represent? In my > opinion it is miniscule and that is a bad thing. It looks to me like people become AC and BoT members because they participate. So, when members of the public participate, they're asked to run for election; when elected, they become "31337" and should no longer particpate? > This community is primarily composed of the industry elite. Only by virtue of being composed of the people who post. > In England that community of consensus used to be called > "the nobility". Later it was referred to as the "landed > gentry". Elites can form communities, but ARIN has a duty to > its members and to the larger community of Internet users, to draw in > participation from a wider circle. I don't see that happening > and in fact, over the past 2 years, I see the circle > diminishing in size somewhat. Economic downturn, corporate downsizing, more work per person. . . people don't have as much time to read and post to mailing lists. > For instance, I reccognize the name of every person who is > currently on the AC and I believe I have personally met > all but two of them even though I don't get to very many > industry conferences (e.g. NANOG, ARIN, RIPE). Average of one > a year. To me that indicates too much concentration of > old-timers and members of a small closed group. Part of the problem is that we have people who have too much experience? > In a body > with 15 members serving an industry as big as the North > American Internet, I believe that there should be more people > who I have never heard of. It is not necessary for people to > be ARIN groupies or industry old-timers in > order to make a solid contribution on the AC. There needs > to be more diversity of views and more diversity of > backgrounds in the mix. There's something concrete you can do about this: http://www.arin.net/elections/nominate.html Now open! > planned actions of ARIN. I believe that this oversight > role is SEVERELY impaired because there is no ARIN > members forum. If there was such a forum, you would see > it proposing things from the IP network operators' > point of view, and then the public comment on this list > would temper those proposals with the public's point > of view. arin-discuss at arin.net "Provides a forum for the member community to discuss ARIN-specific issues such as fee structures and internal policies." http://www.arin.net/mailing_lists/index.html Huh, what do you know, the most recent post was from Michael Dillon, Oct 24, 2003. > > there is a completely open and transparent process with no > exclusions. > > ARIN members who are interested in policy, can and do speak > up on this > > list. > > The Communist Party of the Soviet Union was similarly open > to comment with no exclusions. However, in practice, it was > rare for such comments to be made. The end result is that the > organization ossified, made lots of stupid decisions, and was > eventually destroyed when people discovered that they didn't > have to put up with it any more. It is not enough for an > organization to be open on paper. It needs to be seen to be > open in actual practice. And I don't think this is happening > with ARIN. I think ARIN is beginning to ossify because it lacks a > supply of new blood with new ideas. I think we're pretty well open to new contributions. Frequently, when someone posts for the first time, they get a couple of private messages saying, "Thanks for posting! Keep it up!" Same with comments at the mike at the public policy meetings. We love new people. So, all you lurkers, say something! Lee > --Michael Dillon > From matt.pounsett at cira.ca Wed May 11 13:23:31 2005 From: matt.pounsett at cira.ca (Matt Pounsett) Date: Wed, 11 May 2005 13:23:31 -0400 Subject: [ppml] ARIN participation (was: Proposed Policy: IPv6 HD ratio) In-Reply-To: References: Message-ID: <29A23720-89DC-4E9A-9709-24C3CCBC10EB@cira.ca> It's an annoying but common feature of human nature to not bother with things that are perceived to be working just fine, or perceived to have a high bar of entry (either in required experience or skill). Also, people are lazy. We have a similar problem with participation here at CIRA, where domain holders act in many ways like shareholders in the company.. running for and voting for our board, voting on annual financial statements, etc. The members have a huge say in how the organization is run, yet with over half a million domains out there we have a hard time making quorum for our annual general meeting. As Bill Darte noted, just look at the American and Canadian electoral processes.. even with millions of dollars going into advertising specifically designed to get people to vote, a significant number of people just don't bother. The subject of participation at meetings came up in Reston.. in the Policy Proposal BoF, I believe. One major thread of the conversation revolved around the perception by newcomers that there is a great deal of history (both technical and political) in most discussions, as well as a need for a significant amount of operational experience in order to understand all the nuances and potential side-effects of any one suggestion or decision. The two combine to make it difficult to feel comfortable adding one's voice. Personally, as someone who operates a small network on the edge, I just don't have operational experience on the same scale of many of those who participate in meetings or on PPML. Also, as a relative newcomer to the ARIN scene, I'm unaware of discussions that may have already taken place eliminating particular solutions or avenues. That makes it difficult to feel comfortable commenting, or making suggestions... it's just too easy to commit some sort of gaffe. As a result, I tend to limit my comments to subjects where I do have significant operational expertise, such as with the DNS or with whois. ... and I'm not even the proverbial geek introvert. I gathered from the discussion at Reston that there are many others with similar reasons for lurking. I'm not sure there's an easy solution. Creating a new mailing list certainly isn't going to do it... if the members were going to participate in a mailing list just because it exists, they'd participate here or on arin-discuss. If I'm reading between the lines correctly, it seems the suggestion is based on the notion of mandatory subscription, which I don't think will fly... and not just because people will revolt if you tell them they /have/ to accept e-mail from you. In my experience, people don't participate on mailing lists because there just isn't time. I can spend a couple hours a day just keeping up with ARIN and NANOG, and the only reason my boss allows that to continue is because I've convinced him it's in our best interests as a part of the infrastructure to know what's going on. Of course we want more people to participate, but I think it's incorrect to suggest there's something wrong with having experienced people (not only operationally experienced, but more importantly experienced with the community that is ARIN) on the AC or the BoT. As has already been noted in this thread, and as is noted at every meeting, these people do not make or break policy -- they oversee process, and rubber stamp the decisions of the community. I think it's important that a significant number of the people doing those jobs be very familiar with ARIN, its processes, and the nuances of its community. I haven't proposed any solutions here, but hopefully I've provided some insight into why a participation problem exists. I don't have any good suggestions, since marketing just isn't my forte, but I will note that all cases where I've seen the public respond to requests to participate, it has been at the expense of a significant amount of cash. Matt Pounsett -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From billd at cait.wustl.edu Wed May 11 13:31:08 2005 From: billd at cait.wustl.edu (Bill Darte) Date: Wed, 11 May 2005 12:31:08 -0500 Subject: [ppml] ARIN participation (was: Proposed Policy: IPv6 HD rati o) Message-ID: Matt, Channeling Lee Howard....thanks for your contribution to this discussion and your involvement. Those on the edge who may feel like newcomers should still voice there opinions and perspectives as ARIN is as much their organization as that of any other participant. bd > > > It's an annoying but common feature of human nature to not bother > with things that are perceived to be working just fine, or perceived > to have a high bar of entry (either in required experience or > skill). Also, people are lazy. > > We have a similar problem with participation here at CIRA, where > domain holders act in many ways like shareholders in the company.. > running for and voting for our board, voting on annual financial > statements, etc. The members have a huge say in how the > organization > is run, yet with over half a million domains out there we > have a hard > time making quorum for our annual general meeting. As Bill Darte > noted, just look at the American and Canadian electoral processes.. > even with millions of dollars going into advertising specifically > designed to get people to vote, a significant number of people just > don't bother. > > The subject of participation at meetings came up in Reston.. in the > Policy Proposal BoF, I believe. One major thread of the > conversation > revolved around the perception by newcomers that there is a great > deal of history (both technical and political) in most discussions, > as well as a need for a significant amount of operational experience > in order to understand all the nuances and potential side-effects of > any one suggestion or decision. The two combine to make it > difficult > to feel comfortable adding one's voice. > > Personally, as someone who operates a small network on the edge, I > just don't have operational experience on the same scale of many of > those who participate in meetings or on PPML. Also, as a relative > newcomer to the ARIN scene, I'm unaware of discussions that may have > already taken place eliminating particular solutions or avenues. > That makes it difficult to feel comfortable commenting, or making > suggestions... it's just too easy to commit some sort of > gaffe. As a > result, I tend to limit my comments to subjects where I do have > significant operational expertise, such as with the DNS or with > whois. ... and I'm not even the proverbial geek introvert. I > gathered from the discussion at Reston that there are many others > with similar reasons for lurking. > > I'm not sure there's an easy solution. > > Creating a new mailing list certainly isn't going to do it... if the > members were going to participate in a mailing list just because it > exists, they'd participate here or on arin-discuss. If I'm reading > between the lines correctly, it seems the suggestion is based on the > notion of mandatory subscription, which I don't think will > fly... and > not just because people will revolt if you tell them they /have/ to > accept e-mail from you. In my experience, people don't participate > on mailing lists because there just isn't time. I can spend > a couple > hours a day just keeping up with ARIN and NANOG, and the only reason > my boss allows that to continue is because I've convinced him > it's in > our best interests as a part of the infrastructure to know what's > going on. > > Of course we want more people to participate, but I think it's > incorrect to suggest there's something wrong with having experienced > people (not only operationally experienced, but more importantly > experienced with the community that is ARIN) on the AC or the BoT. > As has already been noted in this thread, and as is noted at every > meeting, these people do not make or break policy -- they oversee > process, and rubber stamp the decisions of the community. I think > it's important that a significant number of the people doing those > jobs be very familiar with ARIN, its processes, and the nuances of > its community. > > I haven't proposed any solutions here, but hopefully I've provided > some insight into why a participation problem exists. I don't have > any good suggestions, since marketing just isn't my forte, > but I will > note that all cases where I've seen the public respond to > requests to > participate, it has been at the expense of a significant > amount of cash. > > Matt Pounsett > From hannigan at verisign.com Wed May 11 14:15:36 2005 From: hannigan at verisign.com (Hannigan, Martin) Date: Wed, 11 May 2005 14:15:36 -0400 Subject: [ppml] Proposed Policy: IPv6 HD ratio Message-ID: > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of > Michael.Dillon at radianz.com > Sent: Wednesday, May 11, 2005 9:38 AM > To: ppml at arin.net > Subject: RE: [ppml] Proposed Policy: IPv6 HD ratio > > > > You often make enlightened and insightful statements. This > email was > not > > such an example. The Advisory Council makes NO policy. > > But the AC is part of the process. In any case, I am > not attacking the AC. I am attacking the small group of > insiders who currently form policy. I happen to be part > of that group so I'm attacking me as well, but not the > AC per se. If I had wanted to attack the AC itself then > I would have focused on their omnibus rewrite of the > entire ARIN policy set. I think youre referring to 'status quo'. Status quo is intimidating to new and old people alike and is generally a bad thing, as you say. [ SNIP ] > 1. Make a member-only list and add at least one > contact person for each member. Offer every member > the possibility to have other people from their > organization added to the list. In the interests > of transparency, archive it in a publicly accessible > form so that all can read but only members can post. > No doubt, if the public wishes to comment, they will > take the discussion to the PPML. Mm. That seems additionally divisive and elitist to me and contrary to the air of open-ness that the Internet tends to operate in for at least as long as I've been around - which results in lack of participation because a "lesser" class is created. Member only meeting/voting is good enough seperation for me. > > 2. Assign a staff member to actively solicit participation > on the PPML from non-member organizations who could or > should have an interest in IP addressing. Actively embrace > organizations like the NANPA council and the ITU who, > have different perspectives and experience. I wonder how > many of you have read the NANPA address allocation policies > and examined their reporting spreadsheets. I know that > IP addresses are not phone numbers, but understanding how > other groups do their work provides perspective. I'm quite familiar with NANPA. I think it's more productive for the majority to focus. A few of us familiarized with NANPA, et. al. should suffice as a good reference point, IMO. That certainly doesn't stop anyone from doing it, but consider this a touch of dissuasion. > > My feeling is that ARIN gets less participation than you or > I or all of > ARIN > > would like, because people do not perceive themselves to be > negatively > > affected. > > I agree. But it is a bad trend for ARIN as an organization > especially now that the authority of ARIN and all RIRs is > being openly questioned in the ITU and the United Nations. > It is not wise to wait for angry people who are negatively > affected to demand ARIN action. We need to be more proactive > so that ARIN is seen to be *MANAGING* IP addressing rather > than merely reacting. A little Occams Razor here. More participation and open-ness should address this. The question then comes back around to simply 'how to get more people participating'. -M< From alh-ietf at tndh.net Wed May 11 18:12:14 2005 From: alh-ietf at tndh.net (Tony Hain) Date: Wed, 11 May 2005 15:12:14 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: Message-ID: <20050511221221.3C26C1444D9@smtp2.arin.net> David Conrad wrote: > Michael, > > On May 10, 2005, at 3:32 AM, Michael.Dillon at radianz.com wrote: > > Some people will switch providers on a daily basis. > > I am somewhat skeptical that people will switch providers as you > suggest when it takes end-user intervention to implement that > switch. Renumbering remains a non-trivial exercise. Connections > break. Firewall rules change. Network management objects have to be > updated. Etc. Until renumbering is addressed (no pun intended), I > suspect the scenarios of *ANs switching providers rapidly will remain > a fantasy. You appear to be thinking in terms of existing fixed networks and the cumbersome tools that vendors provide for managing those. It is not hard to imagine a personal area and/or vehicle network where the handset/router changes providers between available short range and long range radios over fairly short time periods. Renumbering is not a complex task. The tools that allow it to happen are currently cumbersome, but that does not mean they can't be automated. In fact it is not all that hard to imagine a fully automated set top that switches service between power line, cable, dsl, fiber, metro-wireless, or satellite based on which service had the lowest rates today. > > > I think we are allocating less than in the past. In IPv4 we give > > a new ISP 20 bits of address space. In IPv6 we give him 32 bits > > in his prefix. Therefore the IPv6 ISP is getting a much smaller > > fraction of the total address space than the IPv4 ISP. > > Lies, damn lies, and fractions of address space. While what you say > might be true, it is irrelevant. As far as I'm aware, no ISP (or > anyone else, with the possible exception of the ITU) views the amount > of address space they manage in terms of the fraction of total > address space nor do I suspect they care. What they care about is > having sufficient addresses to satisfy their customer requests and > internal infrastructure demands. The fraction of address space > they've been allocated is not a useful metric to judge sufficiency > (IMHO). It is not a useful metric to judge sufficiency, but like it or not it is the metric used to judge fairness. Comparing IPv6 allocation practice to IPv4 practice is not overly useful because one is allocating the demarc for a network while the other is allocating for a specific number of devices. Tony From alh-ietf at tndh.net Wed May 11 18:12:14 2005 From: alh-ietf at tndh.net (Tony Hain) Date: Wed, 11 May 2005 15:12:14 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: <20050510182041.GA28204@ussenterprise.ufp.org> Message-ID: <20050511221221.3C1151444D7@smtp2.arin.net> Leo Bicknell wrote: > ... > You appear to be avoiding my question. > > In your original statement you said miserly conservation increases > the market value of nat. I specifically asked if you considered > 32 bits of host space miserly with respect to the adoption of IPv6 > NAT. You then changed the subject to other things that more bits > enable. I realize it is a multi-dimentional problem, but I asked > a question about one specific dimension. > > I will be happy to address the merits of things like CGA after you > answer my question. > > Is 32 bits of host space miserly such that it would lead to IPv6 > NAT? Any approach that needs more than 32 bits to work would be precluded by an allocation policy that limited subnets to that size. NAT is a work around to limitations imposed by a service provider, and may or may not be a reasonable approach to work around the limited vision of the ISP. If nat by its nature breaks the function that the larger IID was attempting to fix, then no, the 32 bit IID would not drive nat. Restricting a customer to a single subnet of any size would be a stronger motivator than limiting the number of IID values. That said, equating number of IID values to number of physical devices is already broken and will only become more so as integration results in more logical functions being packaged into a single device (cable modems already include multiple logical devices, virtual machines mean a single computer appears to be a set, ...). What you appear to be asking is what the maximum number of devices will be on a subnet 100 years from now. If so, that is not even worth the time to blow off the question since we can't possibly know what technologies will exist or be dropped along the way as 'not worth the effort', no matter what size is chosen. I am not interested in playing a 'throw darts at comments or proposals' game. If this is going to be a serious discussion about what is reasonable then it needs to include a recognition that routing doesn't 'need' more than 45 bits if it is managed to the degree that we already understand. We already know that the HD ratio as defined is not a good match for real IP network deployments. Fix that, then we can talk about why 600 years is insufficient and the potential need to change the default customer prefix length. Starting out by saying that 'that value for the other guy is too rich' when the existing value for the routing side is equally rich is nothing more than greed. Tony From alh-ietf at tndh.net Wed May 11 18:12:14 2005 From: alh-ietf at tndh.net (Tony Hain) Date: Wed, 11 May 2005 15:12:14 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: Message-ID: <20050511221221.3C33A1444DB@smtp2.arin.net> Bill Darte wrote: > > If it were easy to abandon a pervasive standard, we would be further along > the demand curve for v6. Fact is, anyone with enough v4 addresses and a > functioning environment delivering sufficient value is not interested in > change....net value of v6 today is more addresses. That's with a billion > addresses announced. > > When its many trillions of v6 addresses announced and several more global > layers of integration and economic foundation in the mix, the chance of > migration to something new is gonna be near impossible. So I think the > notion of looking at v6 with a sunset horizon of 60 or 100 years is not > prudent. Plan for the long, long, long haul. Then if something new > begins > to emerge....that next promise of networking nirvana, where we'll never > run > out of ... and the IS and new way of changing....SO > CHANGE.... But, in the absence of experience that says we can just > 'change' > when things get difficult, prudence says conservation of the limiting > benefit of v6 seems reasonable to me. If we are going to apply innovation, > then apply it to ways to achieve the renumbering promise, to make a > routing > environment that scales so that end-site v6 allocations won't break > things.... Even the 100+ year phone system is a dying approach. Ignore the technology evolutions that have and are still occurring under the covers, the whole concept of a string of nonsensical digits as an identifier is being replaced with alpha strings that people already associate with the target. The idea that any modern technology will persist unaltered for more than a few generations is something worth considering but at the same time poses baseless hubris on those that attempt it. Tony From alh-ietf at tndh.net Wed May 11 18:22:43 2005 From: alh-ietf at tndh.net (Tony Hain) Date: Wed, 11 May 2005 15:22:43 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: <10ECB7F03C568F48B9213EF9E7F790D209B13B@wava00s2ke2k01.corp.pvt> Message-ID: <20050511222419.12B901443BE@smtp2.arin.net> Azinger, Marla wrote: > ... > Lack of imagination is not a problem here...but lack of conservation and > us of "Private IP Addresses" might be...not to mention this example above > entertwines several distinct issues into one ball. Specifically, porting > of IP Address space and lack of conservation. > > For this response...I am only addressing the later..."lack of > conservation". > > I understand the whole concept of thinking into the future and what we > might use "Public IP Addresses" for...but I have noticed a trend that when > these "possibilities" are brought up...it seems to lack someone asking > whether its "really a need" or just a "because I can" use of IP addresses. > It would be beneficial for everyone to consider the difference between > "what we can do and whether we need or should do". And if we are > determined to do it...why not factor in conservation and use of "Private > IP Addresses"? > > Maybe its just how I interpret things...but it just seems that when we > "look to the future"...sometimes it appears "conservation" is replaced > with "because I can". >From another perspective, 'aggressive conservation' == 'because I can'. There needs to be a balance here and the current balance point is set to meet the original goals for the protocol. We can always change the goals after the fact, but that will cause confusion, and confusion always results in delay. I can already hear the screams about lack of need being the delay, so save the bits. It is unfortunate but we are likely to reach a crisis before people wake up, and then the move will be painful. In any case reasonable stewardship allows for innovation as well as managing resources for the long term. If the 'we will run out' perspective of those who want to micro-manage end side allocations were applied to oil we would have strict rationing, because as we all know oil is a finite resource and we have to make sure it is available 1200 years from now... As far as private addresses go, yes we should be using them for private purposes. IPv6 implementations specifically expect to have multiple addresses simultaneously so they can use private addresses for local functions while public addresses are available for public functions. These addresses are not necessarily for address conservation, but would have that effect for those organizations that have a large number of devices that will never be publicly routed (like the management functions on DOCSIS 3 equipment). They also allow vehicles to move between docking points without disrupting internal communications. Yes they exist and should be used, but they are not going to make a significant difference in address consumption. Tony From alh-ietf at tndh.net Wed May 11 18:22:43 2005 From: alh-ietf at tndh.net (Tony Hain) Date: Wed, 11 May 2005 15:22:43 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: Message-ID: <20050511222415.EC3DA1443BA@smtp2.arin.net> Howard, W. Lee wrote: > ... > I think that argument is a little misleading. Extrapolating > (32 bits / 30 years) = (64 bits / 60 years) assumes that past > performance is a predictor of future allocation [1]. > > The problem, as I like to frame it, is that if we take the > attitude that IPv6 is infinite, then addresses or subnets will > be assigned to consumables, consumed, and never reused. I see > lots of engineers-cum-science-fiction-writers who talk about > potential uses for IPv6, all of which seem to me to argue against > themselves; they seem to say there will be such demand that we > can't afford to be careful now. Especially since produce-truck > drivers, nanobots, and complex molecules, are not ISPs as > currently defined by policy. If these clusters are going to be > sliding gracefully from network to network with their /48s, then > the /32 aggregation goal is blown. No it is not. They are not moving the upper 48 bits, they are fitting gracefully into the new provider's existing /32 aggregate. This is not about consumption without reuse, it is about creating a mechanism that prevents artificial lock-in due to the pain of rebuilding the entire network. Readdressing IPv6 hosts is trivial by design. Renumbering network components requires much more work in places that currently require manual intervention. At the end of the day though as long as the subnet topology stays the same we are talking about a string replace on configuration files from the old provider's /48 to the new one. > > The magic of a /64 is that it's a single routable entity. If I > assume that layer 3 networks connect layer 2 networks, I still > haven't seen any argument here about what a layer 2 network of > 2^64 devices would look like. It's not only inconceivable, it's > inconceivable to (2^32) power or more, and then we say that we > have to assign this enormous set of numbers in groups of 2^16. The point is consistency for the end site. > > The /48 rule applied equally to every possible definition of > end user is arbitrary and reckless. I will concede that in > IPv6 terms, a /48 is reasonable for the enterprise network, > but I just can't understand how it's more responsible to assign > this much to every node on the theory that in someone's wildest > dreams, any node could someday be a router. If a node does > someday become a router, is renumbering one device (possibly to > a /48) insurmountable? Even if it is, is there any barrier to > the household (or cellular, or vehicular) router routing (or > switching) /96 subnets within the /64? Presumably, my blinds > will never have a host address (EUI-64, MAC, or whatever) that > conflicts with my vacuum cleaner. > > Oh, for the record, Geoff Huston's model said we'd consume a /1 > to a /4 in 60 years; at the rate of one /1 every 60 years, we > run out of IPv6 space in 120 years. And also by his model if we simply change the HD from .8 to .94 that becomes 1200 years. By all means the right thing to do is have a reasonable HD metric. > > > Lee > > [1] OK, technically it assumes an exponential progression, but a > predictable exponent. And I don't think most people see that. > What most people seem to miss is that if 2^32 == 30, then with no other changes 2^45 == 245,760 years. Other than Geoff & David's presentation on why the HD metric is wrong, I have yet to see a valid argument on why 45 bits is not enough for the foreseeable lifetime of any protocol. Tony From alh-ietf at tndh.net Wed May 11 18:22:43 2005 From: alh-ietf at tndh.net (Tony Hain) Date: Wed, 11 May 2005 15:22:43 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: Message-ID: <20050511222417.0A9741443BA@smtp2.arin.net> Bill Darte wrote: > ... > If by neigh you mean 3-5 years, then I suggest that ARIN strike up the > band...wave the flag...and release the lawyers to go recover v4 space. I > do > not see v6 overcoming its vexing problems and satisfying a (yet inobvious) > substantial demand for it maturing in the interim. Yes we are talking about an approximate 5 year timeframe, but you would be wasting your time to go down the reclamation path. Even if you do recover a few /8's, it will take years of fighting (likely an expensive effort in the courts) and at the end of the day you get back a month or two of run rate. The IANA run rate has been accelerating over the last 5 years and we are already burning close to 1 /8 per month. If the 5 year rate of growth holds (and given the ability to get public space for private use it will only go up) we will be at 1.5 per month in 3 years. So if you get back 3 /8's after the reclamation fights you will consume them faster than the current users of the space can renumber. A more prudent use of the time will be helping people with their IPv6 rollout. Tony From alh-ietf at tndh.net Wed May 11 18:24:07 2005 From: alh-ietf at tndh.net (Tony Hain) Date: Wed, 11 May 2005 15:24:07 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: Message-ID: <20050511222539.D771514441E@smtp2.arin.net> David Conrad wrote: > ... > Perhaps we should have 3 buckets. The first would be a /56, the > second a /48, and the third, a /40. Just for fun, let's call them > class C, B, and A respectively... (ironic half :-)) That analogy has invalid hidden assumptions. The IPv4 Class A,B,C addresses were PI space randomly assigned. What we are talking about here is a consistent bucket size such that subscribers can move between existing provider aggregates without having to rebuild their network from scratch. > > > IPv4 will run out of space > > before most people are ready to move, if for no other reason than > > they are > > being lulled into a state of unconsciousness by those who refuse to > > accept > > that change is inevitable. > > I doubt IPv4 will ever run out. As the unallocated pool of IPv4 > becomes smaller and, as a result, RIRs policies and procedures become > even more unfair and draconian, people will either (a) migrate to > IPv6, (b) NAT themselves so they only use a couple IP addresses, or > (c) obtain the addresses they need from the black/gray market. > Assuming the market will be allowed to exist (and I'd argue it will > whether or not the RIRs accept the fact), I suspect a combination of > (b) and (c) will satisfy the needs of most folks unable/unwilling/ > unmotivated to do (a). The perceived 'unfair' distribution of the IPv4 space is the reason that governments will not allow the market in address space trading to develop. > > Speaking only for myself of course, but the way things are going, in > the end I'm afraid Paul Francis's NUTSS (Nats, Uris, Tunnels, Sip, > and Stun) "architecture" will win out. I personally would prefer a > world in which there was a clear and obvious reason to migrate to end- > to-end IPv6, e.g., deployable multi-homing and/or trivial > renumbering, instead of FUD with questionable basis. However, to > date, I haven't see that reason. Complex work around approaches have their value, but when it is cheaper to operate an IPv6 application than the comparable nat hack version there will be no contest as cheaper will win out. Getting to the point of cheaper requires several things; awareness of the costs of operating the nat hack, or the costs of mangling the application to work through the traversal technologies; widespread availability of developer tools and libraries that support IPv6 and remove the need for the app developer to think about topology issues; key infrastructure components (like the dns root) available via IPv6 networks; the perception that the IPv6 network reaches places that are interesting to the app developer; network elements that support handling IPv6 packets; trained staff to manage those elements; and availability of addresses. The first of those is happening now as service providers have already told me that application support costs through nat traversal (particularly a 3rd party nat) are untenable and will bankrupt the business. Libraries and tools are available though not as widespread as they need to be. Infrastructure and elements are moving along and I expect them to be ready before the apps are. Staff training is going to be painful, and after application development this is the major point of inertia in the system. This leaves address availability and management. We have a plan in place that with appropriate RIR policy about the HD metric will arguably last for several hundred years. There are organizations that have business reasons to differentiate prefix lengths, so our task is to make sure they don't break the ability to reasonably manage the ptr zones, and that they provide some consistency across providers so that people can move between provider aggregates without having to rebuild everything. In the end I would expect IPv6 to be replaced by some other approach long before we run out of addresses. Tony From L.Howard at stanleyassociates.com Wed May 11 19:02:56 2005 From: L.Howard at stanleyassociates.com (Howard, W. Lee) Date: Wed, 11 May 2005 19:02:56 -0400 Subject: [ppml] IPv6>>32 Message-ID: > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Tony Hain > Sent: Wednesday, May 11, 2005 6:23 PM > To: 'Howard, W. Lee' > Cc: ppml at arin.net > Subject: RE: [ppml] IPv6>>32 > > > Howard, W. Lee wrote: > > If > > these clusters are going to be sliding gracefully from network to > > network with their /48s, then the /32 aggregation goal is blown. > > No it is not. They are not moving the upper 48 bits, they are > fitting gracefully into the new provider's existing /32 > aggregate. This is not about consumption without reuse, it is > about creating a mechanism that prevents artificial lock-in > due to the pain of rebuilding the entire network. > Readdressing IPv6 hosts is trivial by design. Renumbering > network components requires much more work in places that > currently require manual intervention. At the end of the day > though as long as the subnet topology stays the same we are > talking about a string replace on configuration files from > the old provider's /48 to the new one. Oh, I see. You aren't asserting that people need to move their /48s around, only that they need to preserve the hierarchy, and renumbering a /48 network will be trivial. If I stipulate trivial renumbering, I will concede the usefulness of a fixed assignment size for networks. I'm not ready to concede that everything needs an assignment as if it were a router; how about it we assign a /64 to "things," and some fixed size for "routers?" i.e., a single subnet or host gets a /64, and when a router pops into existence, we assign a /56. Elsewhere in this thread you said: > If this is going to be a serious discussion about what is > reasonable then it needs to include a recognition that routing > doesn't 'need' more than 45 bits if it is managed to the degree > that we already understand. I don't think there's consensus on this point. Neither is there consensus that routing can handle anywhere near that number of bits. You also said, in response to Leo: > > infrastructure demands. The fraction of address space they've been > > allocated is not a useful metric to judge sufficiency (IMHO). > > It is not a useful metric to judge sufficiency, but like it or not > it is the metric used to judge fairness. Comparing IPv6 allocation > practice to IPv4 practice is not overly useful because one is > allocating the demarc for a network while the other is allocating for > a specific number of devices. The metric used by whom? Is it an accurate metric? Fraction of total space assigned is only useful if you can measure fraction of total Internet consumed; then one might judge fairness. It seems to me that IPv6 has a network part and a host part, and the assertion is that hosts (interfaces) must be assigned large network numbers in case they someday evolve into something they currently are not. > > The magic of a /64 is that it's a single routable entity. > If I assume > > that layer 3 networks connect layer 2 networks, I still > haven't seen > > any argument here about what a layer 2 network of 2^64 > devices would > > look like. It's not only inconceivable, it's inconceivable > to (2^32) > > power or more, and then we say that we have to assign this enormous > > set of numbers in groups of 2^16. > > The point is consistency for the end site. OK, if I stipulate and concede, can we debate the value of the constant? > > Oh, for the record, Geoff Huston's model said we'd consume > a /1 to a > > /4 in 60 years; at the rate of one /1 every 60 years, we run out of > > IPv6 space in 120 years. > > And also by his model if we simply change the HD from .8 to > .94 that becomes 1200 years. By all means the right thing to > do is have a reasonable HD metric. I'm in favor of increasing the HD ratio required for additional allocations. > > [1] OK, technically it assumes an exponential progression, but a > > predictable exponent. And I don't think most people see that. > > What most people seem to miss is that if 2^32 == 30, then > with no other changes 2^45 == 245,760 years. Other than Geoff > & David's presentation on why the HD metric is wrong, I have > yet to see a valid argument on why 45 bits is not enough for > the foreseeable lifetime of any protocol. Well, people keep arguing that we can't predict the future, and that smart people will come of with all kinds of incredible uses for these numbers. We're not going to burn 4 billion every 30 years, we're going to burn at ever increasing rates. And based on the science fiction I read on IPv6 debates, the rate will increase, and the rate of increase will increase. But I can't predict those rates, so I'm just trying to find the right balance between easy, fair, and durable, and I don't agree with you on where that balance is. For those not trying to follow the math, (2^(45-32))*30 is how you get 245,760. You chose 45 bits because you assume /48 assignments, but only from the 2001/3 we're currently using? > Tony Lee From owen at delong.com Wed May 11 19:33:36 2005 From: owen at delong.com (Owen DeLong) Date: Wed, 11 May 2005 16:33:36 -0700 Subject: [ppml] ARIN participation (was: Proposed Policy: IPv6 HD rati o) In-Reply-To: References: Message-ID: At the risk of being declared industry elite, I'll second what Bill says below. Don't worry about speaking up not knowing the history. Someone will explain it to you. I remember in the latter half of 2003 when some folks from AfriNIC proposed policy 2003-15. It provided for specific microassignments for Africa without relief for North America. I took great offense, and, a long debate ensued. I think I was public enemy number one for many of the African ISPs on the list for some time. Later, I came to realize that they were unaware of proposal 2002-3 and the history of efforts for microassignment policy in ARIN. At that point, we were able to come to mutual understanding and agreement. Both 2002-3 and 2003-15 achieved consensus with broad support in North America and Africa. Now, 2003-15 is about to be retired because of the success in getting AfriNIC up and running, largely due to the efforts of these bold individuals. Speak up. It may not be comfortable, it may not be easy, but, in the end, speaking tends to work better than silence. I suspect neither 2002-3 or 2003-15 would have achieved success without the understanding we achieved through that debate. Owen --On Wednesday, May 11, 2005 12:31 PM -0500 Bill Darte wrote: > Matt, > > Channeling Lee Howard....thanks for your contribution to this discussion > and your involvement. > Those on the edge who may feel like newcomers should still voice there > opinions and perspectives as ARIN is as much their organization as that of > any other participant. > > bd > >> >> >> It's an annoying but common feature of human nature to not bother >> with things that are perceived to be working just fine, or perceived >> to have a high bar of entry (either in required experience or >> skill). Also, people are lazy. >> >> We have a similar problem with participation here at CIRA, where >> domain holders act in many ways like shareholders in the company.. >> running for and voting for our board, voting on annual financial >> statements, etc. The members have a huge say in how the >> organization >> is run, yet with over half a million domains out there we >> have a hard >> time making quorum for our annual general meeting. As Bill Darte >> noted, just look at the American and Canadian electoral processes.. >> even with millions of dollars going into advertising specifically >> designed to get people to vote, a significant number of people just >> don't bother. >> >> The subject of participation at meetings came up in Reston.. in the >> Policy Proposal BoF, I believe. One major thread of the >> conversation >> revolved around the perception by newcomers that there is a great >> deal of history (both technical and political) in most discussions, >> as well as a need for a significant amount of operational experience >> in order to understand all the nuances and potential side-effects of >> any one suggestion or decision. The two combine to make it >> difficult >> to feel comfortable adding one's voice. >> >> Personally, as someone who operates a small network on the edge, I >> just don't have operational experience on the same scale of many of >> those who participate in meetings or on PPML. Also, as a relative >> newcomer to the ARIN scene, I'm unaware of discussions that may have >> already taken place eliminating particular solutions or avenues. >> That makes it difficult to feel comfortable commenting, or making >> suggestions... it's just too easy to commit some sort of >> gaffe. As a >> result, I tend to limit my comments to subjects where I do have >> significant operational expertise, such as with the DNS or with >> whois. ... and I'm not even the proverbial geek introvert. I >> gathered from the discussion at Reston that there are many others >> with similar reasons for lurking. >> >> I'm not sure there's an easy solution. >> >> Creating a new mailing list certainly isn't going to do it... if the >> members were going to participate in a mailing list just because it >> exists, they'd participate here or on arin-discuss. If I'm reading >> between the lines correctly, it seems the suggestion is based on the >> notion of mandatory subscription, which I don't think will >> fly... and >> not just because people will revolt if you tell them they /have/ to >> accept e-mail from you. In my experience, people don't participate >> on mailing lists because there just isn't time. I can spend >> a couple >> hours a day just keeping up with ARIN and NANOG, and the only reason >> my boss allows that to continue is because I've convinced him >> it's in >> our best interests as a part of the infrastructure to know what's >> going on. >> >> Of course we want more people to participate, but I think it's >> incorrect to suggest there's something wrong with having experienced >> people (not only operationally experienced, but more importantly >> experienced with the community that is ARIN) on the AC or the BoT. >> As has already been noted in this thread, and as is noted at every >> meeting, these people do not make or break policy -- they oversee >> process, and rubber stamp the decisions of the community. I think >> it's important that a significant number of the people doing those >> jobs be very familiar with ARIN, its processes, and the nuances of >> its community. >> >> I haven't proposed any solutions here, but hopefully I've provided >> some insight into why a participation problem exists. I don't have >> any good suggestions, since marketing just isn't my forte, >> but I will >> note that all cases where I've seen the public respond to >> requests to >> participate, it has been at the expense of a significant >> amount of cash. >> >> Matt Pounsett >> -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From william at elan.net Wed May 11 19:49:18 2005 From: william at elan.net (william(at)elan.net) Date: Wed, 11 May 2005 16:49:18 -0700 (PDT) Subject: [ppml] ARIN participation (was: Proposed Policy: IPv6 HD rati o) In-Reply-To: References: Message-ID: On Wed, 11 May 2005, Owen DeLong wrote: > I remember in the latter half of 2003 when some folks from AfriNIC proposed > policy 2003-15. It provided for specific microassignments for Africa > without relief for North America. I took great offense, and, a long > debate ensued. I think I was public enemy number one for many of the > African ISPs on the list for some time. Later, I came to realize that > they were unaware of proposal 2002-3 and the history of efforts for > microassignment policy in ARIN. At that point, we were able to come to > mutual understanding and agreement. Both 2002-3 and 2003-15 achieved > consensus with broad support in North America and Africa. Now, 2003-15 > is about to be retired because of the success in getting AfriNIC up and > running, largely due to the efforts of these bold individuals. > > Speak up. It may not be comfortable, it may not be easy, but, in the end, > speaking tends to work better than silence. I suspect neither 2002-3 or > 2003-15 would have achieved success without the understanding we achieved > through that debate. I don't know about that. My personal opinion (at the risk of becoming public enemy #1, which is hardly an unusual position for me) is that it was a mistake to make 2003-15 a policy when we knew that Afrinic would become a RIR within a year and when we knew that micro-assignment policy (for the SAME size assignments) was also part of ARIN's own agenda. What I think should have been done is to let both proposals get discussed but approve 2003-15 only if there was consensus for it but not a consensus for 2002-3, i.e. AC should have blocked 2003-15 after the meeting having seen that its functions are achieved though 2002-3. Otherwise we just waisted the effort of having a special policy for a region for one year and I'm not entirely certain that its a good idea for ARIN to give a precedent like that by having a special policy for particular sub-region. But oh well, this is all history now... And BTW - congratulations to Afrinic for making it through! (even when there are enemies like me and Owen lurking around :) -- William Leibzon Elan Networks william at elan.net From bmanning at vacation.karoshi.com Wed May 11 20:03:07 2005 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 12 May 2005 00:03:07 +0000 Subject: [ppml] IPv6>>32 In-Reply-To: <20050511221221.3C26C1444D9@smtp2.arin.net> References: <20050511221221.3C26C1444D9@smtp2.arin.net> Message-ID: <20050512000307.GA31400@vacation.karoshi.com.> > > > > On May 10, 2005, at 3:32 AM, Michael.Dillon at radianz.com wrote: > > > Some people will switch providers on a daily basis. > > > > I am somewhat skeptical that people will switch providers as you > > suggest when it takes end-user intervention to implement that > > switch. Renumbering remains a non-trivial exercise. Connections > > break. Firewall rules change. Network management objects have to be > > updated. Etc. Until renumbering is addressed (no pun intended), I > > suspect the scenarios of *ANs switching providers rapidly will remain > > a fantasy. > > You appear to be thinking in terms of existing fixed networks and the > cumbersome tools that vendors provide for managing those. It is not hard to > imagine a personal area and/or vehicle network where the handset/router > changes providers between available short range and long range radios over > fairly short time periods. Renumbering is not a complex task. The tools that > allow it to happen are currently cumbersome, but that does not mean they > can't be automated. In fact it is not all that hard to imagine a fully > automated set top that switches service between power line, cable, dsl, > fiber, metro-wireless, or satellite based on which service had the lowest > rates today. moving their BGP peering links, DNS servers, SNMP traps, syslog collectors et.al... peice of cake. No real problems with any of these things.. right? any issues w/ radius or other accounting logs? didn't think so. yes, i can imagine a settop box that is able to swap out the highorder bits btwn several providers based on some metric suite. i can also imagine the grief i would go through trying to explain that the 96 low-order bits that seem to be mine attached to an invoice - for service i did not receive. (seems that some perp had changed his low-order bits to match mine and then freq-hopped btwn service providers - with MY addresses!) rapid, painless renumbering will only be effective when/if there is a clear, clean separation btwn the topology locator and the node identifier. HIP might work. the bastardized construct that is IPv6 today will -NEVER- do transparent, easy, painless renumbering. Of course, YMMV and i might have a tiny bias here. --bill (ex chair of the PIER w/g) From owen at delong.com Wed May 11 20:04:28 2005 From: owen at delong.com (Owen DeLong) Date: Wed, 11 May 2005 17:04:28 -0700 Subject: [ppml] ARIN participation (was: Proposed Policy: IPv6 HD rati o) In-Reply-To: References: Message-ID: <864282BE253D238E5553C7EC@imac-en0.delong.sj.ca.us> > I don't know about that. My personal opinion (at the risk of becoming > public enemy #1, which is hardly an unusual position for me) is that it > was a mistake to make 2003-15 a policy when we knew that Afrinic would > become a RIR within a year and when we knew that micro-assignment policy > (for the SAME size assignments) was also part of ARIN's own agenda. > While I agreed with you to a certain extent, 2003-15 represented much more than the actual policy relief it provided. It was important for a number of reasons that 2003-15 received consensus and approval. It made a big difference to the AfriNIC contingent. It showed them strong support from ARIN, and, it did provide a small amount of additional relief to them beyond what was available from 2002-3. It is a good thing that AfriNIC is up and running only a year later. There is some reason to believe, however, without 2003-15, this would not have happened as quickly. That is one of the reasons I agreed to support 2003-15. Also note, that 2003-15 was viewed as so important by the AfriNIC contingent that there was agreement to support 2002-3 only if I would support 2003-15. In the end, I don't think we are considered enemies of AfriNIC. It was a good debate, and, I think everyone won in the end as a result of a good airing of the ideas and needs. Anyway, I'm starting to drift off the original topic here. Bottom line, silence is viewed as consent, often by both sides of a debate. If you don't want to support both parties positions, voice your position. Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From david.conrad at nominum.com Wed May 11 20:06:39 2005 From: david.conrad at nominum.com (David Conrad) Date: Wed, 11 May 2005 17:06:39 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: <20050511222539.D771514441E@smtp2.arin.net> References: <20050511222539.D771514441E@smtp2.arin.net> Message-ID: <6101609E-ED75-4E7F-96B1-04C8B66D1873@nominum.com> [Speaking only as myself, not as an ARIN board member nor an employee of Nominum] Tony, On May 11, 2005, at 3:24 PM, Tony Hain wrote: >> Perhaps we should have 3 buckets. The first would be a /56, the >> second a /48, and the third, a /40. Just for fun, let's call them >> class C, B, and A respectively... (ironic half :-)) > That analogy has invalid hidden assumptions. That's part of the reason for the half :-). The serious half is that breaking out on octets might be an acceptable compromise (at least for some). Or maybe not. > The IPv4 Class A,B,C addresses > were PI space randomly assigned. What we are talking about here is a > consistent bucket size such that subscribers can move between existing > provider aggregates without having to rebuild their network from > scratch. Perhaps you have more information than I, but I am unsure how many ISPs would require new customers to renumber into a smaller IPv6 block as a condition for service. I have to admit I suspect the number would approach zero as more ISPs start offering IPv6. In any event, couldn't this be easily handled by an RIR policy that says you always get at least as much address space as you already have when you switch providers? > The perceived 'unfair' distribution of the IPv4 space is the reason > that > governments will not allow the market in address space trading to > develop. Well, I suspect a market already exists, although all I have is anecdotal evidence to date so I can't prove it. I also suspect some governments may actually want to encourage a market as it can be seen as a pragmatic way in which the perceived or actual unfairness can be remedied. However, this is just speculation, at least until the pool of unallocated IPv4 prefixes becomes smaller. (To be clear, I am not trying to suggest address markets, black, gray, or white, are good or bad. I just figure they are inevitable as the IPv4 unallocated pool decreases and the unannounced but announceable pool of addresses remains proportionally the same as it is today.) > Complex work around approaches have their value, but when it is > cheaper to > operate an IPv6 application than the comparable nat hack version > there will > be no contest as cheaper will win out. I fully agree. The question is, cheaper for whom? My personal feeling is that the vast majority of Internet users simply don't care how they get to the sites they want to go to, they just want to get there. It doesn't matter to them if they are NAT'd or if they use IPv6. Most of the costs that you mention are not typically direct costs felt by the Internet user, rather they are costs that are hidden in software, hardware, or infrastructure purchases. Until IPv6 provides a clear, unambiguous, and non-techno-geek justification to Internet users why it helps them do what they want to do, I think the amount of address space someone gets is the least of the IPv6's deployment impediments. But maybe that's just me. Rgds, -drc [Speaking only as myself, not as an ARIN board member nor an employee of Nominum] From stephen at sprunk.org Wed May 11 20:21:57 2005 From: stephen at sprunk.org (Stephen Sprunk) Date: Wed, 11 May 2005 19:21:57 -0500 Subject: [ppml] Proposed Policy: IPv6 HD ratio References: Message-ID: <035501c55688$e743fa20$6601a8c0@stephen> Thus spake > > Fat chance that I should be 'accused' of being an industry > > elite...though I'm willing to own up to it if you'll write my boss > > to tell her that, as such, I should be elevated in rank or salary. > > Maybe I should say "industry insider" then. > > > You could neither activate participation nor > > support for the proposal. Who's fault is that? > > That is the fault of ARIN in toto for preventing the ARIN > membership from easily communicating with each other, and > by not trying to broaden participation in the ARIN policy > making process. Whether the HD ratio idea for IPv4 is good > or bad, it just didn't get much discussion at all. There just > aren't very many people out there looking at policy proposals > and commenting on them. Perhaps it's because the vast majority of people (members or not) simply don't care enough to participate? There's dozens of groups I'm a member of, and I have a limited amount of time to dedicate to the few I'm really passionate about; I figure most tech workers are the same way. Or maybe I've become an "industry insider" without knowing it and thus have lost my perspective. > > As for participation. Explain to me how a 'members list' would > > entice any more participation than the 'ppml list' and access > > to email addresses of all AC and BoT members? > > Well, it would allow a member to communicate directly with > the agreggate membership rather than to the public, > the AC or the BoT. Any member is free to join PPML and discuss their concerns; what you seem to be advocating is a closed discussion group smaller than what already exists. Is there any reason we need another mailing list where anyone is allowed to read but only a subset of people are allowed to comment? IMHO, that's a step backwards. What I'd like to see is a bit different: a monthly e-newsletter sent to all members that details what's been recently decided, what's up for discussion on PPML, and why they might care. At the bottom put a reminder of how they can review the archives and contribute if desired. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From tme at multicasttech.com Wed May 11 21:03:58 2005 From: tme at multicasttech.com (Marshall Eubanks) Date: Wed, 11 May 2005 21:03:58 -0400 Subject: [ppml] ARIN participation (was: Proposed Policy: IPv6 HD rati o) In-Reply-To: <864282BE253D238E5553C7EC@imac-en0.delong.sj.ca.us> Message-ID: I thought that - the 2002-3 experince was actually very positive, at least for me. I thought that the system worked the way it was supposed to. - by the time it came to approval, 2003-15 was so entangled with it that (as it not uncommon with legislation) that it was better to approve them both than open up two cans of worms to create a combined proposal. My guess is that would have added a year to the process; it might be waiting for approval yet. Regards Marshall Eubanks On Wed, 11 May 2005 17:04:28 -0700 Owen DeLong wrote: > > I don't know about that. My personal opinion (at the risk of becoming > > public enemy #1, which is hardly an unusual position for me) is that it > > was a mistake to make 2003-15 a policy when we knew that Afrinic would > > become a RIR within a year and when we knew that micro-assignment policy > > (for the SAME size assignments) was also part of ARIN's own agenda. > > > While I agreed with you to a certain extent, 2003-15 represented much more > than the actual policy relief it provided. It was important for a number > of reasons that 2003-15 received consensus and approval. It made a big > difference to the AfriNIC contingent. It showed them strong support from > ARIN, and, it did provide a small amount of additional relief to them beyond > what was available from 2002-3. It is a good thing that AfriNIC is up and > running only a year later. There is some reason to believe, however, > without > 2003-15, this would not have happened as quickly. That is one of the > reasons > I agreed to support 2003-15. Also note, that 2003-15 was viewed as so > important by the AfriNIC contingent that there was agreement to support > 2002-3 only if I would support 2003-15. > > In the end, I don't think we are considered enemies of AfriNIC. It was a > good debate, and, I think everyone won in the end as a result of a good > airing of the ideas and needs. > > Anyway, I'm starting to drift off the original topic here. Bottom line, > silence is viewed as consent, often by both sides of a debate. If you don't > want to support both parties positions, voice your position. > > Owen > > -- > If it wasn't crypto-signed, it probably didn't come from me. From bicknell at ufp.org Wed May 11 22:16:38 2005 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 11 May 2005 22:16:38 -0400 Subject: [ppml] IPv6>>32 In-Reply-To: <20050510180523.CEA2D143BBC@smtp2.arin.net> References: <20050510005720.GA88259@ussenterprise.ufp.org> <20050510180523.CEA2D143BBC@smtp2.arin.net> Message-ID: <20050512021638.GB93400@ussenterprise.ufp.org> In a message written on Tue, May 10, 2005 at 11:05:19AM -0700, Tony Hain wrote: > You appear to be focused on absolute utilization efficiency. CGA approaches > like: > http://www.ietf.cnri.reston.va.us/proceedings/02jul/slides/send-2/tsld003.ht > m > trade space efficiency for authenticity. Approaches like using RFC3041 > addresses for everything trade utilization efficiency for immunity to > scanning attacks. > > Maximizing allocation efficiency is simply one dimension in a > multi-dimensional problem space. There are several problems I have with functions like CGA, and some of the current thoughts on host address space. In no particular order: The current IPv6 policy allows for a /128 where "one and only one" device will be connected. This is an Achilles heal for the entire class of new host based addressing schemes. First and foremost, if an application is to work in this situation, it must be capable of working from a single address. An application vendor would be foolish to write an application that only worked where multiple addresses were available, locking them out of a segment of the market. A secondary problem is that for all the various security through obscurity machinations about cryptographically picking addresses and / or being unable to scan a 64 bit address space if a host has a single address, and a single address only it's likely that it has a limited ability to change address, and also it is more likely that address will be known to at least some entities. This makes relying on any sort of "security" offered by the wide address space at best a foolish proposition. For that matter, who's to say that 64 bits of space can't be scanned? Sure, it can't be exhaustively scanned anytime in the near future, but the people don't the scanning don't need exhaustive scanning. All a virus, worm, or attacker needs is one vulnerable host. Quite frankly, the more addresses a box uses, the worse this problem becomes. A box using 100 addresses, is 100 times more likely to be hit by a partial scan. Once a single host on a subnet is compromised the rest will be found via other means. Multicast, broadcast, higher level functions from rwho to Rendezvous will be used to find other hosts. That's not to say I believe the bar isn't raised. I think the bar will be raised. However, earlier someone used a balloon analogy, and I think that's quite appropriate here. Squeeze one side of it, that is making scanning harder here, and the attacks will simply pop out another vector. That's a good thing, isn't it? Well, not really in an address. See, what's happened here is we're giving away bits that don't solve a problem, but we're incurring the direct cost of the overhead in transmission and memory to store information in routes and other devices, and the opportunity cost of using them for something else, like routing. There's also a more basic layering problem. The lower down in the protocol stack a problem exists, the harder it is to fix, and the more wide spread the impact. Embedding information other than what is necessary to get a packet to its destination in the layer who's sole responsibility is getting the packet to its destination is extremely dangerous. Embedding things like crypto in basic addressing implies some level of awareness at the deepest levels of the IP stack. Any errors in coding, performance impacts, or security flaws will have a devastating impact. The network system is built out of layers for a very good reason. Let's directly address CGA. CGA exists because IPv6 has fundamental security flaws. Rather than design a secure protocol from the start, an insecure protocol was offered up, and now people are trying to bandaid a solution, using any free bits they can find. I suppose in some twisted sense that qualifies as "innovation". Most interesting to me, is that CGA addresses the wrong problem. They talk about WiFi networks, and making sure you're talking to the correct router. The problem is, all CGA tells you is that you're talking to the person who sent you a reply. Again, the attack vector shifts, but only slightly. The simplest description is this: Go to starbucks, fire up a WiFi jammer on the frequency used by the in-house WiFi. At the same time, turn up a new network with the same name and such on a new frequency, using a cellular modem to gateway traffic to the internet. Provide service to everyone in the Starbucks. A user goes in, turns on their computer, is connected to a WiFi network with the right name, and your own rogue box can even do CGA proving it is who it says it is. The user browses the web just fine, with all the traffic going through your box. Again, raised the bar, and yet completely missed the security mark. Of course, the reality is, why would an attacker care? An attacker would be stupid to put his system in the middle of communications on a WiFi network. There's no need. Passive sniffing yields all the information, causes no performance issues, and when done properly is completely undetectable. Triple padlocks on the front door don't change the fact that the garage is wide open....but it will keep people from going in the front door. Will the bits be used? I have no doubt that if they are available someone will "innovate" and use them for something. Is that a good use of the bits? Absolutely not. Layer 3 is about the information in a packet necessary to get it to its destination. Anything else should be in a higher level. Other items put there are dangerous. They destabilize the system. Applications, and make no mistake, proposals like CGA is an application, will only grow over time. Security requires more bits. Features require more bits. They will either outgrow the bits allocated, move on, and leave them wasted or worse, they will demand more bits in the next system. So no, I'm not sold that putting anything other than an address, that is, the information needed to get a packet to its destination in the "address field" is a good idea. Indeed, I think the opposite. It's playing with fire, and particularly if exploited the wrong way early on will be yet another reason IPv6 will not be adopted. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From bicknell at ufp.org Wed May 11 22:38:45 2005 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 11 May 2005 22:38:45 -0400 Subject: [ppml] IPv6>>32 In-Reply-To: <20050509151218.GA61248@ussenterprise.ufp.org> References: <20050509151218.GA61248@ussenterprise.ufp.org> Message-ID: <20050512023845.GB95830@ussenterprise.ufp.org> This URL was just posted to Nanog, but it illustrates a business point I feel many of the engineers are ignoring. http://biz.verizon.net/pands/fios/features.asp You can get Verizon service with "dyanmic IP" for $59.95/month, or with "Static IP" (note, you get to chose 1 or 5 addresses, more addresses are even more money) for $99.95/month. So Verizon has a revenue stream of $40/month for supplying a static address. Now, I can't predict the future, but I can already see the arguments being made by sales, marketing, and the like that in an IPv6 world you should get a single address, and if you want more (1? 5?, are we really going to hope for a /64?) it will be $40/month. I've never met a sales, marking, or board member who would give up $40/month per subscriber "because the protocol designers say it's a good idea". All of which is why I'm extremely cynical that: - A scheme where the user gets to pick their address, rather than having a specific one given to them by their provider will succeed (required for CGA). - IPv6 NAT will not exist. More than a few users would find the costs to support NAT far less than $40/month. - Applications that require more than one address will flourish. After all, if my application requires me to pay an extra $40 (or more) to my provider to work, I'll look for some other application that can work on a single address. - That 64 bit address space is required, if business factors are going to limit the number of available IP's. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From jwkckid1 at ix.netcom.com Thu May 12 03:36:39 2005 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Thu, 12 May 2005 00:36:39 -0700 Subject: [ppml] ARIN participation (was: Proposed Policy: IPv6 HD rati o) References: Message-ID: <42830781.64A2BE09@ix.netcom.com> Owen and all, I know much of the history, yet I am often by some on this forum, chastized, admonished, or otherwise called names, for speaking up or presenting a different view. Of course you Owen have been very respectful and I appreciate that very much... Owen DeLong wrote: > At the risk of being declared industry elite, I'll second what Bill says > below. Don't worry about speaking up not knowing the history. Someone will > explain it to you. > > I remember in the latter half of 2003 when some folks from AfriNIC proposed > policy 2003-15. It provided for specific microassignments for Africa > without relief for North America. I took great offense, and, a long > debate ensued. I think I was public enemy number one for many of the > African ISPs on the list for some time. Later, I came to realize that > they were unaware of proposal 2002-3 and the history of efforts for > microassignment policy in ARIN. At that point, we were able to come to > mutual understanding and agreement. Both 2002-3 and 2003-15 achieved > consensus with broad support in North America and Africa. Now, 2003-15 > is about to be retired because of the success in getting AfriNIC up and > running, largely due to the efforts of these bold individuals. > > Speak up. It may not be comfortable, it may not be easy, but, in the end, > speaking tends to work better than silence. I suspect neither 2002-3 or > 2003-15 would have achieved success without the understanding we achieved > through that debate. > > Owen > > --On Wednesday, May 11, 2005 12:31 PM -0500 Bill Darte > wrote: > > > Matt, > > > > Channeling Lee Howard....thanks for your contribution to this discussion > > and your involvement. > > Those on the edge who may feel like newcomers should still voice there > > opinions and perspectives as ARIN is as much their organization as that of > > any other participant. > > > > bd > > > >> > >> > >> It's an annoying but common feature of human nature to not bother > >> with things that are perceived to be working just fine, or perceived > >> to have a high bar of entry (either in required experience or > >> skill). Also, people are lazy. > >> > >> We have a similar problem with participation here at CIRA, where > >> domain holders act in many ways like shareholders in the company.. > >> running for and voting for our board, voting on annual financial > >> statements, etc. The members have a huge say in how the > >> organization > >> is run, yet with over half a million domains out there we > >> have a hard > >> time making quorum for our annual general meeting. As Bill Darte > >> noted, just look at the American and Canadian electoral processes.. > >> even with millions of dollars going into advertising specifically > >> designed to get people to vote, a significant number of people just > >> don't bother. > >> > >> The subject of participation at meetings came up in Reston.. in the > >> Policy Proposal BoF, I believe. One major thread of the > >> conversation > >> revolved around the perception by newcomers that there is a great > >> deal of history (both technical and political) in most discussions, > >> as well as a need for a significant amount of operational experience > >> in order to understand all the nuances and potential side-effects of > >> any one suggestion or decision. The two combine to make it > >> difficult > >> to feel comfortable adding one's voice. > >> > >> Personally, as someone who operates a small network on the edge, I > >> just don't have operational experience on the same scale of many of > >> those who participate in meetings or on PPML. Also, as a relative > >> newcomer to the ARIN scene, I'm unaware of discussions that may have > >> already taken place eliminating particular solutions or avenues. > >> That makes it difficult to feel comfortable commenting, or making > >> suggestions... it's just too easy to commit some sort of > >> gaffe. As a > >> result, I tend to limit my comments to subjects where I do have > >> significant operational expertise, such as with the DNS or with > >> whois. ... and I'm not even the proverbial geek introvert. I > >> gathered from the discussion at Reston that there are many others > >> with similar reasons for lurking. > >> > >> I'm not sure there's an easy solution. > >> > >> Creating a new mailing list certainly isn't going to do it... if the > >> members were going to participate in a mailing list just because it > >> exists, they'd participate here or on arin-discuss. If I'm reading > >> between the lines correctly, it seems the suggestion is based on the > >> notion of mandatory subscription, which I don't think will > >> fly... and > >> not just because people will revolt if you tell them they /have/ to > >> accept e-mail from you. In my experience, people don't participate > >> on mailing lists because there just isn't time. I can spend > >> a couple > >> hours a day just keeping up with ARIN and NANOG, and the only reason > >> my boss allows that to continue is because I've convinced him > >> it's in > >> our best interests as a part of the infrastructure to know what's > >> going on. > >> > >> Of course we want more people to participate, but I think it's > >> incorrect to suggest there's something wrong with having experienced > >> people (not only operationally experienced, but more importantly > >> experienced with the community that is ARIN) on the AC or the BoT. > >> As has already been noted in this thread, and as is noted at every > >> meeting, these people do not make or break policy -- they oversee > >> process, and rubber stamp the decisions of the community. I think > >> it's important that a significant number of the people doing those > >> jobs be very familiar with ARIN, its processes, and the nuances of > >> its community. > >> > >> I haven't proposed any solutions here, but hopefully I've provided > >> some insight into why a participation problem exists. I don't have > >> any good suggestions, since marketing just isn't my forte, > >> but I will > >> note that all cases where I've seen the public respond to > >> requests to > >> participate, it has been at the expense of a significant > >> amount of cash. > >> > >> Matt Pounsett > >> > > -- > If it wasn't crypto-signed, it probably didn't come from me. > > ------------------------------------------------------------------------ > > Part 1.2 Type: application/pgp-signature > Encoding: 7bit Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 From owen at delong.com Thu May 12 04:19:51 2005 From: owen at delong.com (Owen DeLong) Date: Thu, 12 May 2005 01:19:51 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: <20050512023845.GB95830@ussenterprise.ufp.org> References: <20050509151218.GA61248@ussenterprise.ufp.org> <20050512023845.GB95830@ussenterprise.ufp.org> Message-ID: <2147483647.1115860790@[172.17.1.152]> > So Verizon has a revenue stream of $40/month for supplying a static > address. > Verizon gets away with this in IPv4 because there is a perceived scarcity of addresses, and, people will let them get away with it as a result. Verizon will face competition in IPv6 that will gladly give end users a /64 or /48 because they don't really have to do much to justify that they have done so and they don't have to worry about having such assignments questioned by their RIR. That will create market pressure on Verizon to stop charging $40 for a reasonable sized network. My current provider, for example, charges me $59/month and is routing PI addresses for me on DSL. Technically, I have 768 static addresses for only $14 more than Verizon is charging for a single dynamic, so, it's already economically feasible. Do you really think than in the V6 world where RIR audit becomes much less of an issue that providers will stonewall instead of undercutting Verizon by offering more address space for the same price? Once that happens, applications that require more than one address per user will begin to gain acceptance. As they gain acceptance, Verizon will face customers that ask "Why won't your network let me run blah, when it works fine for my friend on XYZ provider's network?" > Now, I can't predict the future, but I can already see the arguments > being made by sales, marketing, and the like that in an IPv6 world > you should get a single address, and if you want more (1? 5?, are > we really going to hope for a /64?) it will be $40/month. I've > never met a sales, marking, or board member who would give up > $40/month per subscriber "because the protocol designers say it's > a good idea". > I can see that argument being made. Heck, I've seen sales people invent all kinds of crazy things. However, when they're faced with competition offering something better for the same price, they're kind of stuck. This is the one good thing about capitalism. We should at least count on it working. > All of which is why I'm extremely cynical that: > Which crumbles when that one assumption falls. Owen -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From Michael.Dillon at radianz.com Thu May 12 06:00:31 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 12 May 2005 11:00:31 +0100 Subject: [ppml] IPv6>>32 In-Reply-To: <20050512021638.GB93400@ussenterprise.ufp.org> Message-ID: > All a virus, worm, or attacker needs is one vulnerable host. And what if this "vulnerable" host is a Z-80 based PIC collecting readings from 8 sensors and transmitting them through Ethernet to a central data collection station? And yes, IPv6 has been ported to Z-80 CPUs and the configuration that I describe is actually in use today. The definition of a host becomes fuzzier and fuzzier as time goes on. In making IPv6 addressing policy we must be aware that we are not making policy for the computers and networks of 1995. Things are different today and will be moreso in the coming years. --Michael Dillon From william at elan.net Thu May 12 07:15:28 2005 From: william at elan.net (william(at)elan.net) Date: Thu, 12 May 2005 04:15:28 -0700 (PDT) Subject: [ppml] IPv6>>32 In-Reply-To: <20050511222417.0A9741443BA@smtp2.arin.net> References: <20050511222417.0A9741443BA@smtp2.arin.net> Message-ID: On Wed, 11 May 2005, Tony Hain wrote: > Yes we are talking about an approximate 5 year timeframe, but you would be > wasting your time to go down the reclamation path. Even if you do recover a > few /8's, it will take years of fighting (likely an expensive effort in the > courts) and at the end of the day you get back a month or two of run rate. > The IANA run rate has been accelerating over the last 5 years and we are > already burning close to 1 /8 per month. If the 5 year rate of growth holds > (and given the ability to get public space for private use it will only go > up) we will be at 1.5 per month in 3 years. So if you get back 3 /8's after > the reclamation fights you will consume them faster than the current users > of the space can renumber. A more prudent use of the time will be helping > people with their IPv6 rollout. What I see is situation about 10 years from now when ISPs will ask those of their users who can support ip6 natively to only use ip6 and ISP would be able to provide ip6->ip4 translation for legacy service. Such change will allow to reclaim ip4 space, which will be used for users who can only support ip4. When enough users move to ip6, they begin to prefer ip6 native direct connection for everything and so content providers accommodate. This causes beginning of content providers who with only ip6 available content and that would cause desire to move to ip6 for the userbase. If this happens in the right period of time, there will not be exact date when we ran out of ip6 and rather there would be some point when need for new ip4 will finally slow down as ISPs are able to reclaim some space for users who moved to ip6. --- Note that to make this happen we need ability for users who only got IP6 address to still access entire IP4 content space. I've heard of at least one such project on linux conference year 1.5 years ago but don't remember now what it was... -- William Leibzon Elan Networks william at elan.net From billd at cait.wustl.edu Thu May 12 08:21:19 2005 From: billd at cait.wustl.edu (Bill Darte) Date: Thu, 12 May 2005 07:21:19 -0500 Subject: [ppml] IPv6>>32 Message-ID: > Bill Darte wrote: > > > > If it were easy to abandon a pervasive standard, we would > be further > > along the demand curve for v6. Fact is, anyone with enough v4 > > addresses and a functioning environment delivering > sufficient value is > > not interested in change....net value of v6 today is more > addresses. > > That's with a billion addresses announced. > > > > When its many trillions of v6 addresses announced and several more > > global layers of integration and economic foundation in the > mix, the > > chance of migration to something new is gonna be near > impossible. So I > > think the notion of looking at v6 with a sunset horizon of > 60 or 100 > > years is not prudent. Plan for the long, long, long haul. Then if > > something new begins to emerge....that next promise of networking > > nirvana, where we'll never run > > out of ... and the IS and new way of > changing....SO > > CHANGE.... But, in the absence of experience that says we can just > > 'change' > > when things get difficult, prudence says conservation of > the limiting > > benefit of v6 seems reasonable to me. If we are going to apply > innovation, > > then apply it to ways to achieve the renumbering promise, to make a > > routing environment that scales so that end-site v6 > allocations won't > > break things.... > > Even the 100+ year phone system is a dying approach. Ignore > the technology evolutions that have and are still occurring > under the covers, the whole concept of a string of > nonsensical digits as an identifier is being replaced with > alpha strings that people already associate with the target. > The idea that any modern technology will persist unaltered > for more than a few generations is something worth > considering but at the same time poses baseless hubris on > those that attempt it. > > Tony > Yeah, and that said, I'd submit that before the nonsensical digits are replaced, they will be embedded deeper by means we already know and understand (which is the easy way..and the way it goes)... DNS provides the abstraction to make those nonsense identifiers function more 'user friendly' and at the same time providing flexibility. ARP does the same. The notion that innovation will easily and in the short run (of 100+) years scrap a pervasive implementation of v6 nonsensical addresses defies the logic of systems migration....LEGACY is king! All those of you who still run production systems on Series 1 computers raise your hand.... bd From billd at cait.wustl.edu Thu May 12 08:30:33 2005 From: billd at cait.wustl.edu (Bill Darte) Date: Thu, 12 May 2005 07:30:33 -0500 Subject: [ppml] IPv6>>32 Message-ID: Tony said.... > From another perspective, 'aggressive conservation' == > 'because I can'. There needs to be a balance here and the > current balance point is set to meet the original goals for > the protocol. We can always change the goals after the fact, > but that will cause confusion, and confusion always results > in delay. I can already hear the screams about lack of need > being the delay, so save the bits. It is unfortunate but we > are likely to reach a crisis before people wake up, and then > the move will be painful. In any case reasonable stewardship > allows for innovation as well as managing resources for the > long term. If the 'we will run out' perspective of those who > want to micro-manage end side allocations were applied to oil > we would have strict rationing, because as we all know oil is > a finite resource and we have to make sure it is available > 1200 years from now... and in both systems...protocols and oil....there is massive initia because of existing investment, comfort of status quo, powerbase, fear or change, risk avoidance, etc. which means that no significant change to any large embedded system is possible without crisis....the bigger the system, the greater the initia, the longer the delay. Period. > > As far as private addresses go, yes we should be using them > for private purposes. IPv6 implementations specifically > expect to have multiple addresses simultaneously so they can > use private addresses for local functions while public > addresses are available for public functions. These addresses > are not necessarily for address conservation, but would have > that effect for those organizations that have a large number > of devices that will never be publicly routed (like the > management functions on DOCSIS 3 equipment). They also allow > vehicles to move between docking points without disrupting > internal communications. Yes they exist and should be used, > but they are not going to make a significant difference in > address consumption. > > Tony > > > From bicknell at ufp.org Thu May 12 08:43:08 2005 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 12 May 2005 08:43:08 -0400 Subject: [ppml] IPv6>>32 In-Reply-To: <2147483647.1115860790@[172.17.1.152]> References: <20050509151218.GA61248@ussenterprise.ufp.org> <20050512023845.GB95830@ussenterprise.ufp.org> <2147483647.1115860790@[172.17.1.152]> Message-ID: <20050512124308.GA13898@ussenterprise.ufp.org> In a message written on Thu, May 12, 2005 at 01:19:51AM -0700, Owen DeLong wrote: > Verizon gets away with this in IPv4 because there is a perceived > scarcity of addresses, and, people will let them get away with it > as a result. I don't think it's a perceived scarcity of addresses, as I don't think Joe Average, or even your average small business network admin has any idea. The problem is, they have a near-monopoly on a number of services. Indeed, with their fiber offering it's worse as in some places they are cutting copper as the fiber is installed, and the fiber is not subject to UNE's yet. In the end, it's the same reason you pay $8 for a beer, and $5 for a hot dog at a sporting event. Neither beer nor hot dogs are in short supply, but the owners of the venue have artificially created scarcity by limiting the food vendors and what you can bring in. I firmly expect the same behavior from providers who have basically been trying to enforce lock-in their entire history. Recent regulations are not helping matters, making it easier for iLECs and Cable Providers to insure that no competitive offerings exist to the home. I'm still optimistic. I think we'll get a /64 to the home. It's mainly based around an assumption that people will want autoconfiguration to work, so a /64 will be required. I think the hopes of a /48 on "home" service are slim to none though, as the Verizon's of the world are going to first wonder why you need more than a /64, but more importantly if they do give it to you it will be for a cost as an additional revenue stream. Those who need multiple subnets will find NAT, or subdividing the /64 much cheaper options. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From jwkckid1 at ix.netcom.com Thu May 12 11:54:49 2005 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Thu, 12 May 2005 08:54:49 -0700 Subject: [ppml] IPv6>>32 References: <20050509151218.GA61248@ussenterprise.ufp.org> <20050512023845.GB95830@ussenterprise.ufp.org> <2147483647.1115860790@[172.17.1.152]> <20050512124308.GA13898@ussenterprise.ufp.org> Message-ID: <42837C45.EADE8AEC@ix.netcom.com> Leo and all, No offense, but the average Joe knows much more than your giving him credit for... And as such an assumption is troubling with regards to participation, many average Joe's also know that this attitude is so prevalent that many of them feel as though they are being relegated to being ignorant improperly... Leo Bicknell wrote: > In a message written on Thu, May 12, 2005 at 01:19:51AM -0700, Owen DeLong wrote: > > Verizon gets away with this in IPv4 because there is a perceived > > scarcity of addresses, and, people will let them get away with it > > as a result. > > I don't think it's a perceived scarcity of addresses, as I don't > think Joe Average, or even your average small business network admin > has any idea. > > The problem is, they have a near-monopoly on a number of services. > Indeed, with their fiber offering it's worse as in some places they > are cutting copper as the fiber is installed, and the fiber is not > subject to UNE's yet. In the end, it's the same reason you pay $8 > for a beer, and $5 for a hot dog at a sporting event. Neither beer > nor hot dogs are in short supply, but the owners of the venue have > artificially created scarcity by limiting the food vendors and what > you can bring in. I firmly expect the same behavior from providers > who have basically been trying to enforce lock-in their entire > history. > > Recent regulations are not helping matters, making it easier for > iLECs and Cable Providers to insure that no competitive offerings > exist to the home. > > I'm still optimistic. I think we'll get a /64 to the home. It's > mainly based around an assumption that people will want autoconfiguration > to work, so a /64 will be required. I think the hopes of a /48 on > "home" service are slim to none though, as the Verizon's of the > world are going to first wonder why you need more than a /64, but > more importantly if they do give it to you it will be for a cost > as an additional revenue stream. Those who need multiple subnets > will find NAT, or subdividing the /64 much cheaper options. > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org > > ------------------------------------------------------------------------ > > Part 1.2 Type: application/pgp-signature Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 From steve at blighty.com Thu May 12 12:13:53 2005 From: steve at blighty.com (Steve Atkins) Date: Thu, 12 May 2005 09:13:53 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: <42837C45.EADE8AEC@ix.netcom.com> References: <20050509151218.GA61248@ussenterprise.ufp.org> <20050512023845.GB95830@ussenterprise.ufp.org> <2147483647.1115860790@[172.17.1.152]> <20050512124308.GA13898@ussenterprise.ufp.org> <42837C45.EADE8AEC@ix.netcom.com> Message-ID: <20050512161353.GC12820@gp.word-to-the-wise.com> On Thu, May 12, 2005 at 08:54:49AM -0700, Jeff Williams wrote: > Leo and all, > > No offense, but the average Joe knows much more than your > giving him credit for... And as such an assumption is troubling > with regards to participation, many average Joe's also know that > this attitude is so prevalent that many of them feel as though > they are being relegated to being ignorant improperly... Joe User may know, but Joe User doesn't really care that much. With a few exceptions Joe User simply picks from the options available. I also don't think that it's a perceived scarcity of addresses - I think Joe User sees that it's because the consumer ISPs don't want servers running on consumer accounts because they can charge more for accounts that do allow servers. Dynamically assigning addresses to always-on connections (and to a lesser extent creative port blocking) are primarily for product differentiation, and I think that's pretty well understood by Joe User. I've not even heard an ISP claim that dynamic assignments are due to scarcity of addresses since the days of pay-per-minute dialup. I suspect that if there is any choice of IPv6 service available at all the one Joe User demands will be driven more by what Linksys and Netgear support well, rather than by any of Joes beliefs about how it should be, and that may make Leo's optimistic thoughts about autoconfiguration more realistic. Then again, Linksys and friends are sneaky and may well be able to provide a very simple, happy end-user experience without having 2^64 bits to play with. And that's all Joe User really cares about. > Leo says > > I'm still optimistic. I think we'll get a /64 to the home. It's > > mainly based around an assumption that people will want autoconfiguration > > to work, so a /64 will be required. I think the hopes of a /48 on > > "home" service are slim to none though, as the Verizon's of the > > world are going to first wonder why you need more than a /64, but > > more importantly if they do give it to you it will be for a cost > > as an additional revenue stream. Those who need multiple subnets > > will find NAT, or subdividing the /64 much cheaper options. Cheers, Steve -- -- Steve Atkins aka "Joe User" From L.Howard at stanleyassociates.com Thu May 12 12:18:11 2005 From: L.Howard at stanleyassociates.com (Howard, W. Lee) Date: Thu, 12 May 2005 12:18:11 -0400 Subject: [ppml] Proposed Policy: IPv6 HD ratio Message-ID: Hurray, more posts from people who don't regularly post! > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Stephen Sprunk > Sent: Wednesday, May 11, 2005 8:22 PM > To: Michael.Dillon at radianz.com; ppml at arin.net > Subject: Re: [ppml] Proposed Policy: IPv6 HD ratio > > > Thus spake > What I'd like to see is a bit different: a monthly > e-newsletter sent to all members that details what's been > recently decided, what's up for discussion on PPML, and why > they might care. At the bottom put a reminder of how they > can review the archives and contribute if desired. It's only quarterly: http://www.arin.net/newsletter/index.html The issue prior to each public policy meeting includes the text of all of the proposals being considered at the meeting. On the last page (at least, of the copy I got in Orlando, which *of course* I've read and *of course* I have right next to me, thank you Jason) are URLs for proposal archives, meeting minutes, mailing lists, and webcast information. That issue also included summaries of other recent meetings. A recent addition to public policy discussions at the meetings is a summary of the number of posts on a particular proposal and the main points made. This is hard to do in advance of the meeting, because conversation continues up to the actual discussion (and sometimes during the discussion!). It might be something that could be iterated, though. MemSvcs? Member Services: Is email subscription possible? Lee PS: Cheers for Susan and her team! > S > > Stephen Sprunk "Those people who think they know everything > CCIE #3723 are a great annoyance to those of us who do." > K5SSS --Isaac Asimov > From tvest at pch.net Thu May 12 12:38:32 2005 From: tvest at pch.net (Tom Vest) Date: Thu, 12 May 2005 12:38:32 -0400 Subject: [ppml] IPv6>>32 In-Reply-To: <20050512161353.GC12820@gp.word-to-the-wise.com> References: <20050509151218.GA61248@ussenterprise.ufp.org> <20050512023845.GB95830@ussenterprise.ufp.org> <2147483647.1115860790@[172.17.1.152]> <20050512124308.GA13898@ussenterprise.ufp.org> <42837C45.EADE8AEC@ix.netcom.com> <20050512161353.GC12820@gp.word-to-the-wise.com> Message-ID: <4347465C-3746-46C8-832A-312D8006727D@pch.net> On May 12, 2005, at 12:13 PM, Steve Atkins wrote: > I also don't think that it's a perceived scarcity of addresses - I > think Joe User sees that it's because the consumer ISPs don't want > servers running on consumer accounts because they can charge more for > accounts that do allow servers. Dynamically assigning addresses to > always-on connections (and to a lesser extent creative port blocking) > are primarily for product differentiation, and I think that's pretty > well understood by Joe User. I've not even heard an ISP claim that > dynamic assignments are due to scarcity of addresses since the > days of pay-per-minute dialup. However, this is the argument that Joe developing country enterprise sometimes hears from his locally dominant LIR, who would prefer that Joe not multihome. This, in turn, is a significant factor contributing to the popular perception(s) that IPv4 is nearing exhaustion, and that the current nested arrangements for allocation/ assignment control are unfair. TV -------------- next part -------------- An HTML attachment was scrubbed... URL: From kloch at hotnic.net Thu May 12 16:05:45 2005 From: kloch at hotnic.net (Kevin Loch) Date: Thu, 12 May 2005 16:05:45 -0400 Subject: [ppml] IPv6>>32 In-Reply-To: <2147483647.1115860790@[172.17.1.152]> References: <20050509151218.GA61248@ussenterprise.ufp.org> <20050512023845.GB95830@ussenterprise.ufp.org> <2147483647.1115860790@[172.17.1.152]> Message-ID: <4283B719.60402@hotnic.net> Owen DeLong wrote: > Verizon gets away with this in IPv4 because there is a perceived > scarcity of addresses, and, people will let them get away with it > as a result. Verizon does this because there is an actual scarcity of addresses and they are encouraged to do it by ARIN policy. I don't know how many residential customers there are in North America, but let's take a wild guess of 10 million. If Each customer received a /28, that would consume 9.5 /8's Follow that trend in other reigons and -poof- IPv4 is gone faster than you think. The dynamic assignment of a single ip can be traced back to RFC 2050: 7. Due to constraints on the available free pool of IPv4 address space, the use of static IP address assignments (e.g., one address per customer) for dial-up users is strongly discouraged. While it is understood that the use of static addressing may ease some aspects of administration, the current rate of consumption of the remaining unassigned IPv4 address space does not permit the assignment of addresses for administrative ease. Organizations considering the use of static IP address assignment are expected to investigate and implement dynamic assignment technologies whenever possible. And the current ARIN policy states: 4.1.7. RFC 2050 - ARIN takes guidance from allocation and assignment policies and procedures set forth in RFC 2050. These guidelines were developed to meet the needs of the larger Internet community in conserving scarce IPv4 address space and allowing continued use of existing Internet routing technologies. Now there is a difference between dialup pools and "always on" residential connections but customer expectations were set by the dialup experience. This is one problem that IPv6 is supposed to, and will solve. Residential phone/cable companies will probably be the last ones to deploy IPv6. This is a good thing because the rest of us get to set the consumers expectations before they have a chance to screw it up. > Verizon will face competition in IPv6 that will gladly give end users > a /64 or /48 because they don't really have to do much to justify that > they have done so and they don't have to worry about having such > assignments > questioned by their RIR. They will have to swip or rwhois each /48, which they don't have to do right now with "address pools". Perhaps we should change policy to encourage assignment of /48's by only requiring documentation of aggregate customers instead of each /48? - Kevin From owen at delong.com Thu May 12 16:18:10 2005 From: owen at delong.com (Owen DeLong) Date: Thu, 12 May 2005 13:18:10 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: References: Message-ID: --On Thursday, May 12, 2005 11:00 AM +0100 Michael.Dillon at radianz.com wrote: >> All a virus, worm, or attacker needs is one vulnerable host. > > And what if this "vulnerable" host is a Z-80 based PIC collecting > readings from 8 sensors and transmitting them through Ethernet > to a central data collection station? And yes, IPv6 has been > ported to Z-80 CPUs and the configuration that I describe is > actually in use today. > If it's vulnerable, what difference does it make whether it's a Z-80 PIC or a Cray YMP? Once it's infected, it will spew infection to the other hosts it knows about. > The definition of a host becomes fuzzier and fuzzier as > time goes on. > So? > In making IPv6 addressing policy we must be aware that > we are not making policy for the computers and networks > of 1995. Things are different today and will be moreso > in the coming years. > And yet, in some cases, the more things change, the more they stay the same. Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From owen at delong.com Thu May 12 16:30:59 2005 From: owen at delong.com (Owen DeLong) Date: Thu, 12 May 2005 13:30:59 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: References: <20050511222417.0A9741443BA@smtp2.arin.net> Message-ID: <6ADCAADBCDADA584EA235A3E@imac-en0.delong.sj.ca.us> > What I see is situation about 10 years from now when ISPs will ask those > of their users who can support ip6 natively to only use ip6 and ISP would > be able to provide ip6->ip4 translation for legacy service. Such change > will allow to reclaim ip4 space, which will be used for users who can > only support ip4. > I don't see much cooperation with that until such time as ip6 offers at least the same capabilities of ip4. We aren't there today. > When enough users move to ip6, they begin to prefer ip6 native direct > connection for everything and so content providers accommodate. This > causes beginning of content providers who with only ip6 available > content and that would cause desire to move to ip6 for the userbase. > This assertion depends on the validity of the previous assertion. > If this happens in the right period of time, there will not be exact > date when we ran out of ip6 and rather there would be some point when > need for new ip4 will finally slow down as ISPs are able to reclaim > some space for users who moved to ip6. > And this assertion depends on both of the previous assertions being true. I think it is a house of cards, and, I think that the current state of ip6 is somewhat windy. Owen > --- > > Note that to make this happen we need ability for users who only got > IP6 address to still access entire IP4 content space. I've heard of > at least one such project on linux conference year 1.5 years ago but > don't remember now what it was... > > -- > William Leibzon > Elan Networks > william at elan.net -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From william at elan.net Thu May 12 16:34:29 2005 From: william at elan.net (william(at)elan.net) Date: Thu, 12 May 2005 13:34:29 -0700 (PDT) Subject: [ppml] IPv6>>32 In-Reply-To: <6ADCAADBCDADA584EA235A3E@imac-en0.delong.sj.ca.us> References: <20050511222417.0A9741443BA@smtp2.arin.net> <6ADCAADBCDADA584EA235A3E@imac-en0.delong.sj.ca.us> Message-ID: On Thu, 12 May 2005, Owen DeLong wrote: >> What I see is situation about 10 years from now when ISPs will ask those >> of their users who can support ip6 natively to only use ip6 and ISP would >> be able to provide ip6->ip4 translation for legacy service. Such change >> will allow to reclaim ip4 space, which will be used for users who can >> only support ip4. >> > I don't see much cooperation with that until such time as ip6 offers at > least the same capabilities of ip4. We aren't there today. That is why I said 10 years from now. I'm being optimistic, you know :) -- William Leibzon Elan Networks william at elan.net From stephen at sprunk.org Thu May 12 15:37:13 2005 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 12 May 2005 14:37:13 -0500 Subject: [ppml] IPv6>>32 References: <20050509151218.GA61248@ussenterprise.ufp.org> <20050512023845.GB95830@ussenterprise.ufp.org> <2147483647.1115860790@[172.17.1.152]> <20050512124308.GA13898@ussenterprise.ufp.org> <42837C45.EADE8AEC@ix.netcom.com> <20050512161353.GC12820@gp.word-to-the-wise.com> Message-ID: <000c01c55732$4b465910$6601a8c0@stephen> Thus spake "Steve Atkins" > On Thu, May 12, 2005 at 08:54:49AM -0700, Jeff Williams wrote: > > No offense, but the average Joe knows much more than your > > giving him credit for... And as such an assumption is troubling > > with regards to participation, many average Joe's also know that > > this attitude is so prevalent that many of them feel as though > > they are being relegated to being ignorant improperly... > > Joe User may know, but Joe User doesn't really care that much. With > a few exceptions Joe User simply picks from the options available. Right. And we need to make sure ISPs and vendors are able to provide Joe with the option(s) he wants. > I also don't think that it's a perceived scarcity of addresses - I > think Joe User sees that it's because the consumer ISPs don't > want servers running on consumer accounts because they can > charge more for accounts that do allow servers. Dynamically > assigning addresses to always-on connections (and to a lesser > extent creative port blocking) are primarily for product differentiation, > and I think that's pretty well understood by Joe User. I've not even > heard an ISP claim that dynamic assignments are due to scarcity > of addresses since the days of pay-per-minute dialup. IMHO, dynamic assignment is the default now primarily because it's the easiest model to support. Just tell the user to plug in their PC (or whatever) and it works -- no messing with complicated IP settings. The problem comes when providers lock things down so that a given user can only get one DHCP address or use one MAC at a time; mine happens not to do that (though multiple hosts are against the AUP), but I suspect there are many that do. Banning servers is handled more easily through AUP enforcement than via the addressing model. Sure, it requires a bit more work to run a server on a dynamic address, but it's still possible and still an AUP violation for most consumer accounts. Providing insufficient upstream bandwidth is the most effective method in any case. > I suspect that if there is any choice of IPv6 service available at all > the one Joe User demands will be driven more by what Linksys and > Netgear support well, rather than by any of Joes beliefs about > how it should be, and that may make Leo's optimistic thoughts about > autoconfiguration more realistic. Then again, Linksys and friends > are sneaky and may well be able to provide a very simple, happy > end-user experience without having 2^64 bits to play with. And > that's all Joe User really cares about. Then I think it's up to the IPng WG, perhaps at the RIRs' request, to come up with standards for how we expect such devices to work with IPv6. Vendors do generally try to do the right thing given the constraints of the market dynamics they face. Telling them "every home must get a /48" or even a /64 will end up just as futile as saying "don't do NAT" was. The market disagreed with the IETF, and the market always wins. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From kloch at hotnic.net Thu May 12 16:42:56 2005 From: kloch at hotnic.net (Kevin Loch) Date: Thu, 12 May 2005 16:42:56 -0400 Subject: [ppml] IPv6>>32 In-Reply-To: <20050512023845.GB95830@ussenterprise.ufp.org> References: <20050509151218.GA61248@ussenterprise.ufp.org> <20050512023845.GB95830@ussenterprise.ufp.org> Message-ID: <4283BFD0.8010400@hotnic.net> Leo Bicknell wrote: > So Verizon has a revenue stream of $40/month for supplying a static > address. This is more about static vs dynamic than it is about single ip vs subnet. They already know everyone is using NAT so it's not about the number of users supported. It's about services and applications that expect consistent endpoints. > Now, I can't predict the future, but I can already see the arguments > being made by sales, marketing, and the like that in an IPv6 world > you should get a single address, and if you want more (1? 5?, are > we really going to hope for a /64?) it will be $40/month. I've > never met a sales, marking, or board member who would give up > $40/month per subscriber "because the protocol designers say it's > a good idea". Fortunately the phone company isn't the only provider of IP services. There are and will be ISP's that allocate /48's and /64's in all of their packages. Let's not change registry policy based upon phone company, cable company or any other monopoly business model. I agree with you that 32 bits is more than sufficient for host id's. However I don't see any reason to change /64 -> /96 at this time. o Increasing the HD ratio, or a flat utilization threshold fixes any possible shortage. If that doesn't do it, /48 -> /56 would. The more I look at the numbers, the more convinced I am that /48 should be left alone and a flat threshold be used (perhaps 60%). o Autoconfiguration uses 64 bits right now. That's running code. I suggest we change that before we change registry policy on /64. o Other uses for those 64 bits have been proposed and I am more interested in seeing what creative people will do with those bits than solving the non problem of address shortage. - Kevin From bmanning at vacation.karoshi.com Thu May 12 16:46:49 2005 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 12 May 2005 20:46:49 +0000 Subject: [ppml] IPv6>>32 In-Reply-To: <4283BFD0.8010400@hotnic.net> References: <20050509151218.GA61248@ussenterprise.ufp.org> <20050512023845.GB95830@ussenterprise.ufp.org> <4283BFD0.8010400@hotnic.net> Message-ID: <20050512204649.GB3893@vacation.karoshi.com.> > This is more about static vs dynamic than it is about single ip vs > subnet. They already know everyone is using NAT so it's not about > the number of users supported. any studies to back up that assertion kevin? --bill From owen at delong.com Thu May 12 17:14:23 2005 From: owen at delong.com (Owen DeLong) Date: Thu, 12 May 2005 14:14:23 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: References: Message-ID: > Yeah, and that said, I'd submit that before the nonsensical digits are > replaced, they will be embedded deeper by means we already know and > understand (which is the easy way..and the way it goes)... > This is already the case. > DNS provides the abstraction to make those nonsense identifiers function > more 'user friendly' and at the same time providing flexibility. ARP does > the same. > SS7 is sort of like telephone DNS, but, it translates dialed/dialing numbers into billing numbers and destination identifiers. It turns out that all of these numbers have the same format and look a lot alike (in the US/Canada, anyway, it's 3 digit NPA, 3 digit NXX, 4 digit suffix). This is how LNP is achieved and how TFNs (800 numbers) are routed as well. Hence my claim it has already been done. Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From owen at delong.com Thu May 12 17:19:46 2005 From: owen at delong.com (Owen DeLong) Date: Thu, 12 May 2005 14:19:46 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: <20050512124308.GA13898@ussenterprise.ufp.org> References: <20050509151218.GA61248@ussenterprise.ufp.org> <20050512023845.GB95830@ussenterprise.ufp.org> <2147483647.1115860790@[172.17.1.152]> <20050512124308.GA13898@ussenterprise.ufp.org> Message-ID: <38F004481D117382B1EF8756@imac-en0.delong.sj.ca.us> --On Thursday, May 12, 2005 8:43 AM -0400 Leo Bicknell wrote: > In a message written on Thu, May 12, 2005 at 01:19:51AM -0700, Owen > DeLong wrote: >> Verizon gets away with this in IPv4 because there is a perceived >> scarcity of addresses, and, people will let them get away with it >> as a result. > > I don't think it's a perceived scarcity of addresses, as I don't > think Joe Average, or even your average small business network admin > has any idea. > True... It's not perception on the part of the customer. It's perception on the part of Verizon's competitors. If VZ competitors felt that they could get away with handing every customer a /24, do you really think that VZs address policy would continue? > The problem is, they have a near-monopoly on a number of services. > Indeed, with their fiber offering it's worse as in some places they > are cutting copper as the fiber is installed, and the fiber is not > subject to UNE's yet. In the end, it's the same reason you pay $8 > for a beer, and $5 for a hot dog at a sporting event. Neither beer > nor hot dogs are in short supply, but the owners of the venue have > artificially created scarcity by limiting the food vendors and what > you can bring in. I firmly expect the same behavior from providers > who have basically been trying to enforce lock-in their entire > history. > Yep... However, I suspect any such situation is temporary in nature and will be short-lived. > Recent regulations are not helping matters, making it easier for > iLECs and Cable Providers to insure that no competitive offerings > exist to the home. > Yes... The previous and current FCC chairs are definitely either ignorant or working from an agenda contrary to the public good. Possibly both. > I'm still optimistic. I think we'll get a /64 to the home. It's > mainly based around an assumption that people will want autoconfiguration > to work, so a /64 will be required. I think the hopes of a /48 on > "home" service are slim to none though, as the Verizon's of the > world are going to first wonder why you need more than a /64, but > more importantly if they do give it to you it will be for a cost > as an additional revenue stream. Those who need multiple subnets > will find NAT, or subdividing the /64 much cheaper options. > Well... I'm optimistic, too. I think I'll have no trouble getting a /48 for my home when the time comes, and, if I really wanted it, I could probably manage a /32. However, if I can subnet it, a /64 will be quite sufficient for my needs. :-) My point is that the current revenue model of charging more for static or multiple IP addresses will crumble when faced with competition that does not have to. Under IPv6, if it ever catches up to the v4 feature set enough to gain widespread acceptance, I think that will happen. Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From owen at delong.com Thu May 12 17:40:25 2005 From: owen at delong.com (Owen DeLong) Date: Thu, 12 May 2005 14:40:25 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: <20050512161353.GC12820@gp.word-to-the-wise.com> References: <20050509151218.GA61248@ussenterprise.ufp.org> <20050512023845.GB95830@ussenterprise.ufp.org> <2147483647.1115860790@[172.17.1.152]> <20050512124308.GA13898@ussenterprise.ufp.org> <42837C45.EADE8AEC@ix.netcom.com> <20050512161353.GC12820@gp.word-to-the-wise.com> Message-ID: <4D753F888F65BC2A11A5CE9C@imac-en0.delong.sj.ca.us> > Joe User may know, but Joe User doesn't really care that much. With > a few exceptions Joe User simply picks from the options available. > There is some truth in this statement, but, if other options were made available (static addressing and whole networks for similar pricing), Joe user would, indeed, probably choose them in many cases, and, competition might well force the others to abandon such surcharges. > I also don't think that it's a perceived scarcity of addresses - I > think Joe User sees that it's because the consumer ISPs don't want > servers running on consumer accounts because they can charge more for > accounts that do allow servers. Dynamically assigning addresses to > always-on connections (and to a lesser extent creative port blocking) > are primarily for product differentiation, and I think that's pretty > well understood by Joe User. I've not even heard an ISP claim that > dynamic assignments are due to scarcity of addresses since the > days of pay-per-minute dialup. > When I called it a perceived scarcity, I was talking about the perception of the competitors, not the perception of the end user. I am sorry I did not make that clear at first. However, I think that many Joe Users are aware that the "servers are different from clients" mentality is a myth. IP is a peer to peer network, and, any machine can be server and client at any time. ISPs don't claim that dynamic assignments are due to scarcity of addresses, but, the do tell end users that more than one address costs more because they pay more for more addresses (technically true on some levels, but...). This amounts to the same thing. Also, the amount of additional justification required for anything larger than a /28 places a significant cost on the ISP for issuing a larger block, and, even at the /28 level, there's more accounting required than for a single IP. With IPv6, that is no longer the case. It's one of the very few advantages IPv6 offers right now. > I suspect that if there is any choice of IPv6 service available at all > the one Joe User demands will be driven more by what Linksys and > Netgear support well, rather than by any of Joes beliefs about > how it should be, and that may make Leo's optimistic thoughts about > autoconfiguration more realistic. Then again, Linksys and friends > are sneaky and may well be able to provide a very simple, happy > end-user experience without having 2^64 bits to play with. And > that's all Joe User really cares about. > There aren't 2^64 bits to play with in the entire IPv6 address space. However, I suspect that Linksys and friends will implement NATv6 if there is a market for it, but, if ISPs are giving end users /64 or /48 assignments, they'll happily implement that. In the long run, the end user with multiple networks will become the norm and not the exception. In the short run, I'm sure all kinds of people with an interest in it will attempt to preserve the status quo, and, I'm sure the vendors will deliver solutions to meet whatever need is defined by the market whether it matches the status quo or whether it evolves. Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From stephen at sprunk.org Thu May 12 17:21:55 2005 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 12 May 2005 16:21:55 -0500 Subject: [ppml] IPv6>>32 References: Message-ID: <01aa01c5573b$bbda2590$6601a8c0@stephen> Thus spake > > The only comment I have received on my draft so far is that > > we probably need to add /44 for very large organizations. > > Very large organizations are not very static places. They split off > bits of themselves into other organizations and aggregate other > organizations into themselves on a regular basis. Right, but that's orthogonal to the size of the prefixes. Renumbering is a fact of life regardless of prefix size when organizations split or merge, and so far IPv6 doesn't make that any easier (unfortunately) or harder (thankfully). > I don't think there is any case for allowing for more than a > /48 to large organizations. Most large organizations are more > likely to approach providers for several /48's with each > /48 used to service some subset of the whole organization. > I just can't see a scenario in which all traffic in a large > organization will want to use a single gateway. They don't want to use a single gateway; they want multiple vendors at each of several geographically diverse locations all using the same prefix. This implies PI, which is why 2005-1 was proposed. If organizations are forced to use a different /48 for each upstream link, then they're going to be forced into IPv6 NAT at each gateway with ULAs on the inside. More likely they'll just keep using RFC1918 and NAT. > Any alternatives to /48 need to be clearly explained with > many examples. Agreed. Assignments shorter than /48 should be possible if the HD ratio warrants, but I don't see much need for anything between /48 and /64. I also think we need to clarify when a /64 or longer can be assigned, if that's what makes the most technical sense or if it's what the customer requests. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From kloch at hotnic.net Thu May 12 18:11:17 2005 From: kloch at hotnic.net (Kevin Loch) Date: Thu, 12 May 2005 18:11:17 -0400 Subject: [ppml] IPv6>>32 In-Reply-To: <20050512204649.GB3893@vacation.karoshi.com.> References: <20050509151218.GA61248@ussenterprise.ufp.org> <20050512023845.GB95830@ussenterprise.ufp.org> <4283BFD0.8010400@hotnic.net> <20050512204649.GB3893@vacation.karoshi.com.> Message-ID: <4283D485.8030807@hotnic.net> bmanning at vacation.karoshi.com wrote: >>This is more about static vs dynamic than it is about single ip vs >>subnet. They already know everyone is using NAT so it's not about >>the number of users supported. > > any studies to back up that assertion kevin? http://www.webactivemagazine.co.uk/news/1161694 "According to newly published research from Infonetics..." ... "In term of units shipped, the total of 73 million last year represented a staggering 74 per cent hike, according to the analyst firm's report." ... "DSL CPE was found to account for up to 48 per cent of total revenue in the fourth quarter, while cable CPE made up 17 per cent, broadband gateways 25 per cent, and voice terminal adapters and IP set-top boxes made up the remainder." So about 20 million nat boxes sold just in 2004. http://www.gigaom.com/2005/04/13/us-broadband-subscribers-57-million-in-2008/ Nat boxes are extremely common in the residential market. - Kevin From bicknell at ufp.org Thu May 12 19:14:43 2005 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 12 May 2005 19:14:43 -0400 Subject: [ppml] IPv6>>32 In-Reply-To: <4283B719.60402@hotnic.net> References: <20050509151218.GA61248@ussenterprise.ufp.org> <20050512023845.GB95830@ussenterprise.ufp.org> <2147483647.1115860790@[172.17.1.152]> <4283B719.60402@hotnic.net> Message-ID: <20050512231443.GA38468@ussenterprise.ufp.org> In a message written on Thu, May 12, 2005 at 04:05:45PM -0400, Kevin Loch wrote: > The dynamic assignment of a single ip can be traced back to > RFC 2050: > > 7. Due to constraints on the available free pool of IPv4 address > space, the use of static IP address assignments (e.g., one > address per customer) for dial-up users is strongly discouraged. A bit of history for those who didn't live it. Prior to broadband it was a not uncommon practice to give a dial up user a fixed IP address. They would dial up and use that particular address, then disconnect. The address would only be available on the internet while they were connected. For instance, Virginia Tech was doing this circa 1991-1994, and IIRC there were ~10,000 static addresses assigned, but only 2-3,000 dial up ports. This guaranteed ~7,000 addresses were not in use at any given time. Policies like this were worded to get people out of this model, and into dynamic addressing for dial up as we all know and love it today. > Now there is a difference between dialup pools and "always on" > residential connections but customer expectations were set by the dialup > experience. By "expectation" I assume you mean the dynamic assignment of addresses. And to some degree I think that you are correct. At the same time, I think that's also an overgeneralization. The counter example is services like http://www.dyndns.org/ which go to great pains to work around the dynamic addressing. These customers "expect" something similar to always on static IP'ed service, but they either can't get it at all (which is actually my situation, Adelphia here does not offer multiple IP's, or static IP's at all for any price), or have decided their provider wants too much money (eg, $40/month from verizon, when dyndns is $24/year + $30/year if you want mail forwarding). If the competitive market was delivering static IP's at a good price services like dyndns wouldn't be necessary at all. > They will have to swip or rwhois each /48, which they don't have to do > right now with "address pools". Perhaps we should change policy > to encourage assignment of /48's by only requiring documentation of > aggregate customers instead of each /48? Based on the last meeting, and my own proposal, the ARIN membership is quite clear that they want all assignments in the database. I completely forgot to add that to my list of reasons companies might choose to give out /128's rather than /48's or /64's, reduction of paperwork. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From william at elan.net Thu May 12 19:39:20 2005 From: william at elan.net (william(at)elan.net) Date: Thu, 12 May 2005 16:39:20 -0700 (PDT) Subject: [ppml] IPv6>>32 In-Reply-To: <20050512231443.GA38468@ussenterprise.ufp.org> References: <20050509151218.GA61248@ussenterprise.ufp.org> <20050512023845.GB95830@ussenterprise.ufp.org> <2147483647.1115860790@[172.17.1.152]> <4283B719.60402@hotnic.net> <20050512231443.GA38468@ussenterprise.ufp.org> Message-ID: On Thu, 12 May 2005, Leo Bicknell wrote: > Based on the last meeting, and my own proposal, the ARIN membership > is quite clear that they want all assignments in the database. > I completely forgot to add that to my list of reasons companies might > choose to give out /128's rather than /48's or /64's, reduction of > paperwork. I think you're misinterpreting the discussion at last meeting. It was primarily against your proposal to remove requirement for ISPs to keep publicly available in whois information about their sub-allocations and assignments, they already would HAVE TO REPORT to ARIN anyway. In terms of IPv4 it does not mean that ISPs report every customer with single static ip address assignment to ARIN. They only report assignments of blocks /29 or larger and anything less then that is optional. I would suspect that the same would be true for IPv6 and ISPs would report to ARIN (and thus it would be visible in public whois) assignments of /48 blocks but single host assignments of /64 would be optional. -- William Leibzon Elan Networks william at elan.net From bmanning at vacation.karoshi.com Thu May 12 20:02:08 2005 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 13 May 2005 00:02:08 +0000 Subject: [ppml] IPv6>>32 In-Reply-To: <4283D485.8030807@hotnic.net> References: <20050509151218.GA61248@ussenterprise.ufp.org> <20050512023845.GB95830@ussenterprise.ufp.org> <4283BFD0.8010400@hotnic.net> <20050512204649.GB3893@vacation.karoshi.com.> <4283D485.8030807@hotnic.net> Message-ID: <20050513000208.GA4757@vacation.karoshi.com.> On Thu, May 12, 2005 at 06:11:17PM -0400, Kevin Loch wrote: > bmanning at vacation.karoshi.com wrote: > >>This is more about static vs dynamic than it is about single ip vs > >>subnet. They already know everyone is using NAT so it's not about > >>the number of users supported. > > > > any studies to back up that assertion kevin? > > http://www.webactivemagazine.co.uk/news/1161694 > http://www.gigaom.com/2005/04/13/us-broadband-subscribers-57-million-in-2008/ > > Nat boxes are extremely common in the residential market. > > - Kevin so... you are asserting "extremely common" == "everyone"... i, for one, am unwilling to make that leap of faith. the NAT-capable boxes at my house have NAT turned off. the NAT-mandatory boxes I have purchased (and no doubt recorded as units sold) have been relegated to the e-waste bin.... so as long as I am not using NAT (agressively at this point in time) your statement that "everyone" is using NAT is demonstrably false. --bill From gih at apnic.net Thu May 12 20:15:53 2005 From: gih at apnic.net (Geoff Huston) Date: Fri, 13 May 2005 10:15:53 +1000 Subject: [ppml] IPv6>>32 In-Reply-To: References: <20050509151218.GA61248@ussenterprise.ufp.org> Message-ID: <6.0.1.1.2.20050513100937.041828a0@kahuna.telstra.net> >At RIPE last week Geoff gave a follow-up presentation that was spawned by >the round table at ARIN. In the presentation he presented other ways of >perhaps squeezing a few more bits of "reserve." > >The report is available here: > >http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary-wed-ipv6-roundtable-report.pdf The change here was the inclusion on one additional area of consideration, that I called "Public Policy - The "Fairness" Factor, that posed the question of when should one adjust allocation policies for global public resources. noting that early changes tended to create conservative outcomes, but avoided the risk of late adopter penalties, while deferring changes often created diverse outcomes, typically with early adopter rewards. I commented that these issues were parhaps of a lesser consideration some time back, but with the role of the Internet firmly fixed in the public space these days, then consideration of such issues at a global level is quite proper and appropriate. I also highlighted the option to change later from RFC 3177, but I noted, and also noted on this mailing list, that by the time we've got to the point of needing changes the massive inertial mass of the billions of installed "things" will make any form of alteration in the technology really very hard. regards, Geoff From bicknell at ufp.org Thu May 12 20:35:50 2005 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 12 May 2005 20:35:50 -0400 Subject: [ppml] IPv6>>32 In-Reply-To: References: <20050509151218.GA61248@ussenterprise.ufp.org> <20050512023845.GB95830@ussenterprise.ufp.org> <2147483647.1115860790@[172.17.1.152]> <4283B719.60402@hotnic.net> <20050512231443.GA38468@ussenterprise.ufp.org> Message-ID: <20050513003550.GA41763@ussenterprise.ufp.org> In a message written on Thu, May 12, 2005 at 04:39:20PM -0700, william(at)elan.net wrote: > I would suspect that the same would be true for IPv6 and ISPs would report > to ARIN (and thus it would be visible in public whois) assignments of /48 > blocks but single host assignments of /64 would be optional. I believe per sectin 6.5.5 of the NRPM that /64's must be registered as well, although I must admit the wording leaves something to be desired: To save you from having to open a browser, I quote: ] When an organization holding an IPv6 address allocation makes IPv6 ] address assignments, it must register assignment information in a ] database, accessible by RIRs as appropriate (information registered by ] an RIR/NIR may be replaced by a distributed database for registering ] address management information in future). Information is registered in ] units of assigned /48 networks. When more than a /48 is assigned to an ] organization, the assigning organization is responsible for ensuring ] that the address space is registered in an RIR/NIR database. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From william at elan.net Thu May 12 21:03:34 2005 From: william at elan.net (william(at)elan.net) Date: Thu, 12 May 2005 18:03:34 -0700 (PDT) Subject: [ppml] IPv6>>32 In-Reply-To: <20050513003550.GA41763@ussenterprise.ufp.org> References: <20050509151218.GA61248@ussenterprise.ufp.org> <20050512023845.GB95830@ussenterprise.ufp.org> <2147483647.1115860790@[172.17.1.152]> <4283B719.60402@hotnic.net> <20050512231443.GA38468@ussenterprise.ufp.org> <20050513003550.GA41763@ussenterprise.ufp.org> Message-ID: On Thu, 12 May 2005, Leo Bicknell wrote: > In a message written on Thu, May 12, 2005 at 04:39:20PM -0700, william(at)elan.net wrote: >> I would suspect that the same would be true for IPv6 and ISPs would report >> to ARIN (and thus it would be visible in public whois) assignments of /48 >> blocks but single host assignments of /64 would be optional. > > I believe per sectin 6.5.5 of the NRPM that /64's must be registered as > well, although I must admit the wording leaves something to be desired: > > To save you from having to open a browser, I quote: > > ] When an organization holding an IPv6 address allocation makes IPv6 > ] address assignments, it must register assignment information in a > ] database, accessible by RIRs as appropriate (information registered by > ] an RIR/NIR may be replaced by a distributed database for registering > ] address management information in future). Information is registered in > ] units of assigned /48 networks. When more than a /48 is assigned to an > ] organization, the assigning organization is responsible for ensuring > ] that the address space is registered in an RIR/NIR database. Yes, this wording is troublesome to say the least. However I interpret it different then you: | Information is registered in units of assigned /48 networks. My Interpretation: Register assignments with size of block /48 or more | When more than a /48 is assigned to an organization, the assigning | organization is responsible for ensuring that the address space is | registered in an RIR/NIR database. My Interpretation: If LIR sub-allocates space to another organization (smaller ISP) with size of sub-allocation greater then /48, then whoever the block is sub-allocated to is responsible for making further allocations and assignments to RIR whois (Note that I interpreted assign as allocate as I think for other RIRs they do not make distinction of how its done and the policy was originally one prepared as unifying one for all RIRs) Considering difficulting in reading that paragraph and interpreting it, if there is a person on this list, who originally drafted that paragraph, it would be great if he could stand up and tell us what was meant and whose interpretation is correct. And for future readers AC should think about policy change to replace that paragraph with something easier to understand... -- William Leibzon Elan Networks william at elan.net From kloch at hotnic.net Fri May 13 00:25:48 2005 From: kloch at hotnic.net (Kevin Loch) Date: Fri, 13 May 2005 00:25:48 -0400 Subject: [ppml] IPv6>>32 In-Reply-To: <20050513000208.GA4757@vacation.karoshi.com.> References: <20050509151218.GA61248@ussenterprise.ufp.org> <20050512023845.GB95830@ussenterprise.ufp.org> <4283BFD0.8010400@hotnic.net> <20050512204649.GB3893@vacation.karoshi.com.> <4283D485.8030807@hotnic.net> <20050513000208.GA4757@vacation.karoshi.com.> Message-ID: <42842C4C.30200@hotnic.net> bmanning at vacation.karoshi.com wrote: > On Thu, May 12, 2005 at 06:11:17PM -0400, Kevin Loch wrote: > >>>>This is more about static vs dynamic than it is about single ip vs >>>>subnet. They already know everyone is using NAT so it's not about >>>>the number of users supported. > > so as long as I am not using NAT (agressively at this point > in time) your statement that "everyone" is using NAT is > demonstrably false. That statement taken literally is indeed false. Let me rephrase: s/already know everyone is using/know customers could use/ Customers with multiple devices could also use tunnels or proxies but neither is as common as "NAT in a box" (unfortunately). I'm glad you asked, because before I dug up that article I had no idea that many boxes had been sold. - Kevin From owen at delong.com Fri May 13 01:10:27 2005 From: owen at delong.com (Owen DeLong) Date: Thu, 12 May 2005 22:10:27 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: <20050513000208.GA4757@vacation.karoshi.com.> References: <20050509151218.GA61248@ussenterprise.ufp.org> <20050512023845.GB95830@ussenterprise.ufp.org> <4283BFD0.8010400@hotnic.net> <20050512204649.GB3893@vacation.karoshi.com.> <4283D485.8030807@hotnic.net> <20050513000208.GA4757@vacation.karoshi.com.> Message-ID: <2147483647.1115935826@[172.17.1.152]> > the NAT-capable boxes at my house have NAT turned off. the > NAT-mandatory boxes I have purchased (and no doubt recorded > as units sold) have been relegated to the e-waste bin.... I have to second Bill on this. I have 7 devices in my house capable of doing NAT and probably counted as units sold. NONE of them are actually doing any NAT. There is NO NAT in my house. Sales of NAT capable units are a very poor way to measure NAT deployment. Owen -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From jwkckid1 at ix.netcom.com Fri May 13 03:41:48 2005 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Fri, 13 May 2005 00:41:48 -0700 Subject: [ppml] IPv6>>32 References: <20050509151218.GA61248@ussenterprise.ufp.org> <20050512023845.GB95830@ussenterprise.ufp.org> <2147483647.1115860790@[172.17.1.152]> <20050512124308.GA13898@ussenterprise.ufp.org> <42837C45.EADE8AEC@ix.netcom.com> <20050512161353.GC12820@gp.word-to-the-wise.com> Message-ID: <42845A3B.C32E3A9@ix.netcom.com> Steve and all, Respectively I disagree. However I can't accurately know if a majority of "users" know or don't know. Neither can you... Steve Atkins wrote: > On Thu, May 12, 2005 at 08:54:49AM -0700, Jeff Williams wrote: > > Leo and all, > > > > No offense, but the average Joe knows much more than your > > giving him credit for... And as such an assumption is troubling > > with regards to participation, many average Joe's also know that > > this attitude is so prevalent that many of them feel as though > > they are being relegated to being ignorant improperly... > > Joe User may know, but Joe User doesn't really care that much. With > a few exceptions Joe User simply picks from the options available. > > I also don't think that it's a perceived scarcity of addresses - I > think Joe User sees that it's because the consumer ISPs don't want > servers running on consumer accounts because they can charge more for > accounts that do allow servers. Dynamically assigning addresses to > always-on connections (and to a lesser extent creative port blocking) > are primarily for product differentiation, and I think that's pretty > well understood by Joe User. I've not even heard an ISP claim that > dynamic assignments are due to scarcity of addresses since the > days of pay-per-minute dialup. > > I suspect that if there is any choice of IPv6 service available at all > the one Joe User demands will be driven more by what Linksys and > Netgear support well, rather than by any of Joes beliefs about > how it should be, and that may make Leo's optimistic thoughts about > autoconfiguration more realistic. Then again, Linksys and friends > are sneaky and may well be able to provide a very simple, happy > end-user experience without having 2^64 bits to play with. And > that's all Joe User really cares about. > > > Leo says > > > I'm still optimistic. I think we'll get a /64 to the home. It's > > > mainly based around an assumption that people will want autoconfiguration > > > to work, so a /64 will be required. I think the hopes of a /48 on > > > "home" service are slim to none though, as the Verizon's of the > > > world are going to first wonder why you need more than a /64, but > > > more importantly if they do give it to you it will be for a cost > > > as an additional revenue stream. Those who need multiple subnets > > > will find NAT, or subdividing the /64 much cheaper options. > > Cheers, > Steve > -- > -- Steve Atkins aka "Joe User" -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 From josmon at rigozsaurus.com Fri May 13 02:29:21 2005 From: josmon at rigozsaurus.com (josmon) Date: Fri, 13 May 2005 00:29:21 -0600 Subject: [ppml] IPv6>>32 In-Reply-To: <2147483647.1115935826@[172.17.1.152]> References: <20050509151218.GA61248@ussenterprise.ufp.org> <20050512023845.GB95830@ussenterprise.ufp.org> <4283BFD0.8010400@hotnic.net> <20050512204649.GB3893@vacation.karoshi.com.> <4283D485.8030807@hotnic.net> <20050513000208.GA4757@vacation.karoshi.com.> <2147483647.1115935826@[172.17.1.152]> Message-ID: <20050513062921.GA23826@jeeves.rigozsaurus.com> On Thu, May 12, 2005 at 10:10:27PM -0700, Owen DeLong wrote: > > the NAT-capable boxes at my house have NAT turned off. the > > NAT-mandatory boxes I have purchased (and no doubt recorded > > as units sold) have been relegated to the e-waste bin.... > > I have to second Bill on this. I have 7 devices in my house capable of > doing NAT and probably counted as units sold. NONE of them are actually > doing any NAT. There is NO NAT in my house. > > Sales of NAT capable units are a very poor way to measure NAT deployment. When it comes to NAT, I'm willing to bet that the average ppml subscriber is less likely to NAT than the public at large, so any response is (at best) skewed. With that said, I have to throw in with Bill and Owen and admit to no NAT in my house. What I find interesting, is that I've been telling people that use NAT that they aren't actually on the Internet -- but rather proxied to it. In the last six months or so several folks have indicated that they actually understood that statement. Is it possible that people are finally starting to see that NAT breaks end-to-end connectivity? (Or am I just hanging out with a better/worse crowd?) From geier-lists-arin at tih.co.tz Fri May 13 02:56:36 2005 From: geier-lists-arin at tih.co.tz (Frank Habicht) Date: Fri, 13 May 2005 09:56:36 +0300 Subject: [ppml] IPv6>>32 In-Reply-To: <20050513062921.GA23826@jeeves.rigozsaurus.com> References: <20050509151218.GA61248@ussenterprise.ufp.org> <20050512023845.GB95830@ussenterprise.ufp.org> <4283BFD0.8010400@hotnic.net> <20050512204649.GB3893@vacation.karoshi.com.> <4283D485.8030807@hotnic.net> <20050513000208.GA4757@vacation.karoshi.com.> <2147483647.1115935826@[172.17.1.152]> <20050513062921.GA23826@jeeves.rigozsaurus.com> Message-ID: <42844FA4.9000206@tih.co.tz> Hi all, (first post to ppml ;-) I'd like to argue that there's more NAT than many here think. I didn't buy a NAT device, but I NAT my 192.168.0.0/24 in my house (on Pentium1) somewhere into 172.16.0.0/12 which gets NATed at the ISP. Hopefully not much longer because the ISP will start using their (new, 'own') /19. And yes, this is not in (ip4-)address-space-rich North America, but in former-arin-land Tanzania. (or was the discussion about use in arin region?) Another ISP here is said to charge $10 for a static /32. I agree that people understand more and will demand more.... Frank Habicht On 5/13/2005 9:29 AM, josmon wrote: > On Thu, May 12, 2005 at 10:10:27PM -0700, Owen DeLong wrote: > >>> the NAT-capable boxes at my house have NAT turned off. the >>> NAT-mandatory boxes I have purchased (and no doubt recorded >>> as units sold) have been relegated to the e-waste bin.... >> >>I have to second Bill on this. I have 7 devices in my house capable of >>doing NAT and probably counted as units sold. NONE of them are actually >>doing any NAT. There is NO NAT in my house. >> >>Sales of NAT capable units are a very poor way to measure NAT deployment. > > > When it comes to NAT, I'm willing to bet that the average ppml > subscriber is less likely to NAT than the public at large, so > any response is (at best) skewed. > > With that said, I have to throw in with Bill and Owen and admit to no > NAT in my house. > > What I find interesting, is that I've been telling people that use > NAT that they aren't actually on the Internet -- but rather proxied > to it. In the last six months or so several folks have indicated that > they actually understood that statement. > > Is it possible that people are finally starting to see that NAT breaks > end-to-end connectivity? (Or am I just hanging out with a better/worse crowd?) From Michael.Dillon at radianz.com Fri May 13 05:31:23 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Fri, 13 May 2005 10:31:23 +0100 Subject: [ppml] IPv6>>32 In-Reply-To: <4283BFD0.8010400@hotnic.net> Message-ID: > o Increasing the HD ratio, or a flat utilization threshold fixes > any possible shortage. If that doesn't do it, /48 -> /56 > would. The more I look at the numbers, the more convinced I > am that /48 should be left alone and a flat threshold be used > (perhaps 60%). I agree that the /48 --> /56 issue is definitely second priority. If we can solve the immediate problem by adjusting the HD ratio rules then we should limit current action to that area. I also think that a flat threshold is useful, but not in place of the HD ratio. My thinking is that whatever the HD ratio is, we should have a cap on the number of IPv6 addresses that we allocate all in one go. Here's the scenario I envisage: 1. Network Operator comes to ARIN and says, I want to start deploying IPv6. ARIN looks at plans, forecasts, diagrams, and comes up with /12 as the right size allocation. But the cap rule kicks in and they only allocate this organization a /28. 2. Network operator goes away and works on deployment. A few years later they come to ARIN and show that they deserve more addresses. At this point the HD ratio shows whether or not their /28 is densely used. If we adjust the HD ratio to .94 then this /28 will be a lot more densely used that it would have to be at a .8 ratio. Chances are this .94 ratio means that step number two happens later than it otherwise would have. But the cap makes step number two happen earlier than it would have. In any case, ARIN sees that a /12 is still justified and allocates an additional /28 because of the cap. Operator is given the choice of renumbering into a new /27 if they wish to. 3. Network Operator returns a second time, rinse and repeat. But eventually, confidence in v6 renumbering is high and the network operator renumbers one of its /28 blocks into a new /27. 4. Network Operator returns a third time and receives a /26 block. They then renumber out of their last /27 and their remaining /28. Of course, the choice of /28 was purely arbitrary on my part to use as an example. --Michael Dillon From Michael.Dillon at radianz.com Fri May 13 05:43:38 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Fri, 13 May 2005 10:43:38 +0100 Subject: [ppml] IPv6>>32 In-Reply-To: <20050513062921.GA23826@jeeves.rigozsaurus.com> Message-ID: > With that said, I have to throw in with Bill and Owen and admit to no > NAT in my house. Well, I have always had NAT in my house since the days back in 1995 when I first set up TIS firewalls tookit on a FreeBSD machine connected via an always-on v.32bis modem link. > Is it possible that people are finally starting to see that NAT breaks > end-to-end connectivity? (Or am I just hanging out with a > better/worse crowd?) I know exactly what the benefits and downsides of NAT are. But it runs all the things that I want to run at home just fine. For anything else, I have a colocated server elsewhere in a nice data centre. http://www.vix.com/personalcolo/ I think this is also the pattern followed by Joe User although his "server" is likely to be a shared server running a blog or a wiki, than my *nix box. --Michael Dillon From bicknell at ufp.org Fri May 13 10:05:59 2005 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 13 May 2005 10:05:59 -0400 Subject: [ppml] IPv6>>32 In-Reply-To: References: <20050509151218.GA61248@ussenterprise.ufp.org> <20050512023845.GB95830@ussenterprise.ufp.org> <2147483647.1115860790@[172.17.1.152]> <4283B719.60402@hotnic.net> <20050512231443.GA38468@ussenterprise.ufp.org> <20050513003550.GA41763@ussenterprise.ufp.org> Message-ID: <20050513140559.GA65832@ussenterprise.ufp.org> In a message written on Thu, May 12, 2005 at 06:03:34PM -0700, william(at)elan.net wrote: > >] When an organization holding an IPv6 address allocation makes IPv6 > >] address assignments, it must register assignment information in a > >] database, accessible by RIRs as appropriate (information registered by > >] an RIR/NIR may be replaced by a distributed database for registering > >] address management information in future). Information is registered in This is the more troubleing statement to me. The later statement, "registered in /48 units" is vague as to meaning. However this statement seems to suggest any assignment must be registered. ARIN staff can correct me, but I suspect in the ARIN region no one has come back for a second allocation so we've never tested the documentation rules. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From L.Howard at stanleyassociates.com Fri May 13 10:12:52 2005 From: L.Howard at stanleyassociates.com (Howard, W. Lee) Date: Fri, 13 May 2005 10:12:52 -0400 Subject: [ppml] IPv6>>32 Message-ID: Good example. I've heard that address assignment in Africa is different than North America, because ISPs (frequently the PTT) don't want customers multihoming--they see that as promoting the competition. What do you think will happen when they're assigning IPv6 space? Lee > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Frank Habicht > Sent: Friday, May 13, 2005 2:57 AM > To: ppml at arin.net > Subject: Re: [ppml] IPv6>>32 > > > Hi all, > > (first post to ppml ;-) > > I'd like to argue that there's more NAT than many here think. > I didn't buy a NAT device, but I NAT my 192.168.0.0/24 in my house (on > Pentium1) somewhere into 172.16.0.0/12 which gets NATed at > the ISP. Hopefully not much longer because the ISP will start > using their (new, > 'own') /19. > > And yes, this is not in (ip4-)address-space-rich North > America, but in former-arin-land Tanzania. (or was the > discussion about use in arin region?) Another ISP here is > said to charge $10 for a static /32. > > I agree that people understand more and will demand more.... > > Frank Habicht > > > On 5/13/2005 9:29 AM, josmon wrote: > > On Thu, May 12, 2005 at 10:10:27PM -0700, Owen DeLong wrote: > > > >>> the NAT-capable boxes at my house have NAT turned off. the > >>> NAT-mandatory boxes I have purchased (and no doubt recorded > >>> as units sold) have been relegated to the e-waste bin.... > >> > >>I have to second Bill on this. I have 7 devices in my > house capable > >>of doing NAT and probably counted as units sold. NONE of them are > >>actually doing any NAT. There is NO NAT in my house. > >> > >>Sales of NAT capable units are a very poor way to measure NAT > >>deployment. > > > > > > When it comes to NAT, I'm willing to bet that the average ppml > > subscriber is less likely to NAT than the public at large, so any > > response is (at best) skewed. > > > > With that said, I have to throw in with Bill and Owen and > admit to no > > NAT in my house. > > > > What I find interesting, is that I've been telling people > that use NAT > > that they aren't actually on the Internet -- but rather > proxied to it. > > In the last six months or so several folks have indicated that they > > actually understood that statement. > > > > Is it possible that people are finally starting to see that > NAT breaks > > end-to-end connectivity? (Or am I just hanging out with a > > better/worse crowd?) > From ljb at merit.edu Fri May 13 10:24:55 2005 From: ljb at merit.edu (Larry J. Blunk) Date: Fri, 13 May 2005 10:24:55 -0400 Subject: [ppml] IPv6>>32 In-Reply-To: References: Message-ID: <1115994295.17083.14.camel@ablate.merit.edu> On Fri, 2005-05-13 at 10:31 +0100, Michael.Dillon at radianz.com wrote: > > o Increasing the HD ratio, or a flat utilization threshold fixes > > any possible shortage. If that doesn't do it, /48 -> /56 > > would. The more I look at the numbers, the more convinced I > > am that /48 should be left alone and a flat threshold be used > > (perhaps 60%). > > I agree that the /48 --> /56 issue is definitely second priority. > If we can solve the immediate problem by adjusting the HD ratio > rules then we should limit current action to that area. > I think there are other reasons for considering /56's. Consider, for example, university dorms rooms. Should each of them get a /48? The University of Michigan has 5793 dorms and 1483 family housing apartments (ref -- http://www.housing.umich.edu/general/factsheet.html). You'd need a /35 at a minimum to give everyone a /48 and that wouldn't leave much headroom or flexibility in addressing hierarchy. Realistically, you probably want to assign a /32. Merit provides Internet access for 13 universities and the State of Michigan. Based on the above considerations, we asked for a /28 from ARIN (enough for a /32 for each university and the state). Our application was denied, and we only received a /32. What size prefix should allocate to the universities (ARIN suggested a /40)? What prefix size should we advise them to assign to dorm rooms? -Larry Blunk Merit From stephen at sprunk.org Fri May 13 10:52:54 2005 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 13 May 2005 09:52:54 -0500 Subject: [ppml] IPv6>>32 References: <1115994295.17083.14.camel@ablate.merit.edu> Message-ID: <011701c557cb$7f80eb20$6601a8c0@stephen> Thus spake "Larry J. Blunk" > I think there are other reasons for considering /56's. Consider, > for example, university dorms rooms. Should each of them get a > /48? The University of Michigan has 5793 dorms and 1483 family > housing apartments (ref -- http://www.housing.umich.edu/general/factsheet.html). > You'd need a /35 at a minimum to give everyone a /48 and that > wouldn't leave much headroom or flexibility in addressing hierarchy. > Realistically, you probably want to assign a /32. > > Merit provides Internet access for 13 universities and the State > of Michigan. Based on the above considerations, we asked for a /28 > from ARIN (enough for a /32 for each university and the state). Our > application was denied, and we only received a /32. What size prefix > should allocate to the universities (ARIN suggested a /40)? What > prefix size should we advise them to assign to dorm rooms? Based on a previous response to me, individual customers within a single building are apparently not considered "sites". Either way, I'd be assigning a /64 per dorm building or per floor -- not per room -- unless ARIN forced me to assign more. From there you can determine what each university needs (presumably a /48). Thanks for the info on your application being denied; it's useful to have real-world examples of policies' effects even if only anecdotal. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From cpm at well.com Fri May 13 11:42:25 2005 From: cpm at well.com (Chip Mefford) Date: Fri, 13 May 2005 11:42:25 -0400 Subject: [ppml] Proposed Policy: IPv6 HD ratio/ Really public involvment In-Reply-To: <10ECB7F03C568F48B9213EF9E7F790D209B13C@wava00s2ke2k01.corp.pvt> References: <10ECB7F03C568F48B9213EF9E7F790D209B13C@wava00s2ke2k01.corp.pvt> Message-ID: <4284CAE1.9040801@well.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Azinger, Marla wrote: |>From my experience I have found there are a large number of people within the Internet Community that read about 75% of these postings. They also form an opinion. However, they refrain from commenting. Why? I have been told by many..."because you already said what I was thinking" or "because I dont like speaking or commenting in public forum so I just wait until someone else says what I'm thinking." There are also those of us who might interject something, but since the format is a top-posted, jeaporday style thread, it's difficult to contribute without being misconstrued. Please don't top post. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFChMrh0STXFHxUucwRAgznAKCYKrTEYG3ZXynWHhxmiL3hlZABRQCfQrL+ yAmhSZS37ETPihHcE7ccznw= =jq+r -----END PGP SIGNATURE----- From iggy at merit.edu Fri May 13 11:45:52 2005 From: iggy at merit.edu (Glenn Wiltse) Date: Fri, 13 May 2005 11:45:52 -0400 (EDT) Subject: [ppml] IPv6>>32 In-Reply-To: <011701c557cb$7f80eb20$6601a8c0@stephen> References: <1115994295.17083.14.camel@ablate.merit.edu> <011701c557cb$7f80eb20$6601a8c0@stephen> Message-ID: What most of this comes down to is what is a 'end site'. And what is the appropreate size assignment for a 'end site'. Currently ARIN policy defines end 'site' this way... -=-=-= 6.2.9. End site An end site is defined as an end user (subscriber) who has a business relationship with a service provider that involves: 1. that service provider assigning address space to the end user 2. that service provider providing transit service for the end user to other sites 3. that service provider carrying the end user's traffic. 4. that service provider advertising an aggregate prefix route that contains the end user's assignment -=-=-= I have heard people desribe a end site as anything from a business to a person. Which leaves alot of room for confusion as to what is right. I beleive some people even consider that possibly a phone or other device could be considered a 'end site' and therefore deserving of a /48. The device getting a /48 seems a bit extreme to me, but I think suggesting that a University the size of UofM, MSU, WSU, etc... is only deserving of a /48 is also a bit extreme. The other deffintion of importance here is ISP/LIR... I think one could easily argue that a university such as lets say Columbia is a ISR. (Or maybe MSU, UofM, WSU, etc...) Columbia University was indeed given a /32 by ARIN. I'm not sure how they justified this this direct allocation from ARIN. However it clearly was done. Anyway, back to my point... The bottom line seems to be how you define a ISP and/or a End Site. Untill people can agree on these types of diffintions, the current ARIN policy is very nebulous at best. This type of discussion with regard to what size block should be assigne or what number to use in a HD ratio calculation going to be nearly impossible to come to consensus on. For what it's worth, the 13 Universitys that are Members of Merit, are not your typical 'customer' or even 'end site'. They are their own unique institutions, that happen to more or less own Merit. This relationship is not as simple as a customer/provider. Also, my own comments on this, should not in anyway be taken to be as speaking directly for any of Merit's member Universitys, they I'm sure have their own opions. Glenn Wiltse On Fri, 13 May 2005, Stephen Sprunk wrote: > Thus spake "Larry J. Blunk" > > I think there are other reasons for considering /56's. Consider, > > for example, university dorms rooms. Should each of them get a > > /48? The University of Michigan has 5793 dorms and 1483 family > > housing apartments (ref -- > http://www.housing.umich.edu/general/factsheet.html). > > You'd need a /35 at a minimum to give everyone a /48 and that > > wouldn't leave much headroom or flexibility in addressing hierarchy. > > Realistically, you probably want to assign a /32. > > > > Merit provides Internet access for 13 universities and the State > > of Michigan. Based on the above considerations, we asked for a /28 > > from ARIN (enough for a /32 for each university and the state). Our > > application was denied, and we only received a /32. What size prefix > > should allocate to the universities (ARIN suggested a /40)? What > > prefix size should we advise them to assign to dorm rooms? > > Based on a previous response to me, individual customers within a single > building are apparently not considered "sites". Either way, I'd be > assigning a /64 per dorm building or per floor -- not per room -- unless > ARIN forced me to assign more. From there you can determine what each > university needs (presumably a /48). > > Thanks for the info on your application being denied; it's useful to have > real-world examples of policies' effects even if only anecdotal. > > S > > Stephen Sprunk "Those people who think they know everything > CCIE #3723 are a great annoyance to those of us who do." > K5SSS --Isaac Asimov > > > !DSPAM:4284c08a21693848324722! > > From iggy at merit.edu Fri May 13 11:50:58 2005 From: iggy at merit.edu (Glenn Wiltse) Date: Fri, 13 May 2005 11:50:58 -0400 (EDT) Subject: [ppml] Proposed Policy: IPv6 HD ratio/ Really public involvment In-Reply-To: <4284CAE1.9040801@well.com> References: <10ECB7F03C568F48B9213EF9E7F790D209B13C@wava00s2ke2k01.corp.pvt> <4284CAE1.9040801@well.com> Message-ID: Oh, come on... please don't get started on a debate of top or bottom posting... or posting in between for that matter. It's trivial attacks of this nature that detur some more timid folks from posting. Glenn Wiltse On Fri, 13 May 2005, Chip Mefford wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Azinger, Marla wrote: > |>From my experience I have found there are a large number of people > within the Internet Community that read about 75% of these postings. > They also form an opinion. However, they refrain from commenting. Why? > I have been told by many..."because you already said what I was > thinking" or "because I dont like speaking or commenting in public forum > so I just wait until someone else says what I'm thinking." > > > There are also those of us who might interject something, but since the > format is a top-posted, jeaporday style thread, it's difficult > to contribute without being misconstrued. > > Please don't top post. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.0 (GNU/Linux) > > iD8DBQFChMrh0STXFHxUucwRAgznAKCYKrTEYG3ZXynWHhxmiL3hlZABRQCfQrL+ > yAmhSZS37ETPihHcE7ccznw= > =jq+r > -----END PGP SIGNATURE----- > > !DSPAM:4284cc0e2341125504042! > > Just so your clear on my posistion, I'll post on both top and bottom. Oh, come on... please don't get started on a debate of top or bottom posting... or posting in between for that matter. It's trivial attacks of this nature that detur some more timid folks from posting. Glenn Wiltse From Ed.Lewis at neustar.biz Fri May 13 12:02:51 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Fri, 13 May 2005 12:02:51 -0400 Subject: [ppml] Proposed Policy: IPv6 HD ratio/ Really public involvment In-Reply-To: <4284CAE1.9040801@well.com> References: <10ECB7F03C568F48B9213EF9E7F790D209B13C@wava00s2ke2k01.corp.pvt> <4284CAE1.9040801@well.com> Message-ID: I don't think top-posting is the problem. But I don't mean to harp on that. this message is about the "really public involvement" part of the subject. Although I am at almost every meeting and have a lot of background in some parts of the Internet, address allocation is a topic that is alien to me. As the discussion has been raging these past few weeks I have been trying to read every thing and find other materials for background. I think one reason there isn't broad input is that fringe players like me (and those even further out) have a hard time navigating through all of the threads. Besides misconstrued and mis-attributed statements, it's the track of the discussion that is hard to follow. What would be helpful is an active editor of the discussion, someone tracking what is said and laying out the discussion for those that don't live and breath this stuff. E.g., I've completely lost the meaning of the subject line "IPv6>>32" - and how does this relate to a proposed policy? To get back to why top posting isn't the problem - as I read through all of the messages, it's the top-posted threads that are the easiest to follow. The context is maintained message to message and there is no need to scroll through the already-been-read-context to find the two lines of comeback. Top posting is like putting the exec summary first and then letting the reader decide how far back to go in the message history before context is understood. As someone said recently - it's not the top-posting, it's not the other, it's the mixing of the two that make it hard to follow. If you have been reading the list, the rest is something you've already seen, attached only to give context. At 11:42 -0400 5/13/05, Chip Mefford wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Azinger, Marla wrote: >|>From my experience I have found there are a large number of people >within the Internet Community that read about 75% of these postings. >They also form an opinion. However, they refrain from commenting. Why? > I have been told by many..."because you already said what I was >thinking" or "because I dont like speaking or commenting in public forum >so I just wait until someone else says what I'm thinking." > > >There are also those of us who might interject something, but since the >format is a top-posted, jeaporday style thread, it's difficult >to contribute without being misconstrued. > >Please don't top post. >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.0 (GNU/Linux) > >iD8DBQFChMrh0STXFHxUucwRAgznAKCYKrTEYG3ZXynWHhxmiL3hlZABRQCfQrL+ >yAmhSZS37ETPihHcE7ccznw= >=jq+r >-----END PGP SIGNATURE----- -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From kloch at hotnic.net Fri May 13 12:19:03 2005 From: kloch at hotnic.net (Kevin Loch) Date: Fri, 13 May 2005 12:19:03 -0400 Subject: [ppml] IPv6>>32 In-Reply-To: <1115994295.17083.14.camel@ablate.merit.edu> References: <1115994295.17083.14.camel@ablate.merit.edu> Message-ID: <4284D377.6030106@hotnic.net> Larry J. Blunk wrote: > I think there are other reasons for considering /56's. Consider, > for example, university dorms rooms. Should each of them get a /48? > The University of Michigan has 5793 dorms and 1483 family housing > apartments (ref -- http://www.housing.umich.edu/general/factsheet.html). > You'd need a /35 at a minimum to give everyone a /48 and that wouldn't > leave much headroom or flexibility in addressing hierarchy. > Realistically, you probably want to assign a /32. > Under the current policy, if MERIT should only have to demonstrate 38,000 downstream customers (students) to qualify for a /28, not counting downstream customers of universities that have their own allocation. > Merit provides Internet access for 13 universities and the State > of Michigan. Based on the above considerations, we asked for a /28 > from ARIN (enough for a /32 for each university and the state). Our > application was denied, and we only received a /32. What size prefix > should allocate to the universities (ARIN suggested a /40)? What > prefix size should we advise them to assign to dorm rooms? Under the current policy, each university should easially qualify for their own /32. For dorm rooms, universities should be able to assign students anywhere from nothing (let them use university "assigned" space) or their own /48. - Kevin From cpm at well.com Fri May 13 13:06:18 2005 From: cpm at well.com (Chip Mefford) Date: Fri, 13 May 2005 13:06:18 -0400 Subject: [ppml] Proposed Policy: IPv6 HD ratio/ Really public involvment In-Reply-To: References: <10ECB7F03C568F48B9213EF9E7F790D209B13C@wava00s2ke2k01.corp.pvt> <4284CAE1.9040801@well.com> Message-ID: <4284DE8A.1070101@well.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Glenn Wiltse wrote: | Oh, come on... please don't get started on a debate of top or bottom | posting... or posting in between for that matter. It's trivial attacks | of this nature that detur some more timid folks from posting. | | Glenn Wiltse Glenn, It was neither an attack, nor trivial. It was a declarative statement. Such things make threads difficult to follow, and discourge interjection. It is difficult to avoid being misconstrued if context is not kept. This is a pretty intimidating list as it is. There was a statement made that implied that things might move along better if there were more input. I made my observation. It seems pretty clear to me, that /right here/ is a good enough example of me at least, wanting back into lurk mode most desperately. I know this is true for me, I can fairly intuit it is for others also. This is a high traffic list, I have a day job. I try to read as much of this list as I can, some threads might go on for a week or so before I even begin on them. I'm sure I am not alone. - -- | | On Fri, 13 May 2005, Chip Mefford wrote: | | | Azinger, Marla wrote: | |>From my experience I have found there are a large number of people | within the Internet Community that read about 75% of these postings. | They also form an opinion. However, they refrain from commenting. Why? | I have been told by many..."because you already said what I was | thinking" or "because I dont like speaking or commenting in public forum | so I just wait until someone else says what I'm thinking." | | | There are also those of us who might interject something, but since the | format is a top-posted, jeaporday style thread, it's difficult | to contribute without being misconstrued. | | Please don't top post. !DSPAM:4284cc0e2341125504042! | Just so your clear on my posistion, I'll post on both top and bottom. | Oh, come on... please don't get started on a debate of top or bottom | posting... or posting in between for that matter. It's trivial attacks | of this nature that detur some more timid folks from posting. | Glenn Wiltse -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFChN6K0STXFHxUucwRAge6AJsE0nb9oTdprWqUJjN8sDufR3YqUQCZAaeT QhhzkHBBqGs8GAAymP5zpNw= =Tj9e -----END PGP SIGNATURE----- From kloch at hotnic.net Fri May 13 13:11:35 2005 From: kloch at hotnic.net (Kevin Loch) Date: Fri, 13 May 2005 13:11:35 -0400 Subject: [ppml] IPv6>>32 In-Reply-To: <011701c557cb$7f80eb20$6601a8c0@stephen> References: <1115994295.17083.14.camel@ablate.merit.edu> <011701c557cb$7f80eb20$6601a8c0@stephen> Message-ID: <4284DFC7.1040701@hotnic.net> Stephen Sprunk wrote: > Based on a previous response to me, individual customers within a single > building are apparently not considered "sites". Is this an undocumented ARIN policy? It directly conflicts with the official policy: 6.2.9. End site An end site is defined as an end user (subscriber) who has a business relationship with a service provider that involves: 1. that service provider assigning address space to the end user 2. that service provider providing transit service for the end user to other sites 3. that service provider carrying the end user's traffic. 4. that service provider advertising an aggregate prefix route that contains the end user's assignment There is no restriction on customers in the same physical building and it applies to any customer, business or individual. I would have strong objections to a policy where building == site. multiple businesses in the same office building should not have to share a /48. > Either way, I'd be > assigning a /64 per dorm building or per floor -- not per room -- unless > ARIN forced me to assign more. From there you can determine what each > university needs (presumably a /48). You can do that. The policy does not force you to assign anything. Your business relationship with the customer (student) might not involve assigning space to the student at all (the /64 per dorm in your example). Or it might involve assigning a /48 to the student, as policy does not prevent you from having that business relationship. The End Site definition does not define the business relationship with your customer. The business relationship with your customer determines if they are an End Site. The definition of End Site is not vague as some have suggested. It is specific and esaily applied. - Kevin From marla_azinger at eli.net Fri May 13 13:22:10 2005 From: marla_azinger at eli.net (Azinger, Marla) Date: Fri, 13 May 2005 10:22:10 -0700 Subject: [ppml] Proposed Policy: IPv6 HD ratio/ Really public involvment Message-ID: <10ECB7F03C568F48B9213EF9E7F790D201512237@wava00s2ke2k01.corp.pvt> We all have our opinions/views and we all need to hear the various opinions/views. What we all need to keep in mind is ...they are just that...views and opinions...its business...not personal. I don't always agree with a view/opinion someone may have made...and I might also post a strong opposing view/opinion back to what I didn't agree with. However, I still value the opinion/view that I don't agree with. Even if I don't agree with something it still opens my mind up further to consider the possibility and re-examine what I originally formulated in my brain. Chip thank you for you comments. I look forward to reading more in the future. Even if I might oppose one. ;o) Marla Electric Lightwave -----Original Message----- From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of Chip Mefford Sent: Friday, May 13, 2005 10:06 AM To: Glenn Wiltse; ppml at arin.net Subject: Re: [ppml] Proposed Policy: IPv6 HD ratio/ Really public involvment -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Glenn Wiltse wrote: | Oh, come on... please don't get started on a debate of top or bottom | posting... or posting in between for that matter. It's trivial attacks | of this nature that detur some more timid folks from posting. | | Glenn Wiltse Glenn, It was neither an attack, nor trivial. It was a declarative statement. Such things make threads difficult to follow, and discourge interjection. It is difficult to avoid being misconstrued if context is not kept. This is a pretty intimidating list as it is. There was a statement made that implied that things might move along better if there were more input. I made my observation. It seems pretty clear to me, that /right here/ is a good enough example of me at least, wanting back into lurk mode most desperately. I know this is true for me, I can fairly intuit it is for others also. This is a high traffic list, I have a day job. I try to read as much of this list as I can, some threads might go on for a week or so before I even begin on them. I'm sure I am not alone. - -- | | On Fri, 13 May 2005, Chip Mefford wrote: | | | Azinger, Marla wrote: | |>From my experience I have found there are a large number of people | within the Internet Community that read about 75% of these postings. | They also form an opinion. However, they refrain from commenting. Why? | I have been told by many..."because you already said what I was | thinking" or "because I dont like speaking or commenting in public forum | so I just wait until someone else says what I'm thinking." | | | There are also those of us who might interject something, but since the | format is a top-posted, jeaporday style thread, it's difficult | to contribute without being misconstrued. | | Please don't top post. !DSPAM:4284cc0e2341125504042! | Just so your clear on my posistion, I'll post on both top and bottom. | Oh, come on... please don't get started on a debate of top or bottom | posting... or posting in between for that matter. It's trivial attacks | of this nature that detur some more timid folks from posting. | Glenn Wiltse -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFChN6K0STXFHxUucwRAge6AJsE0nb9oTdprWqUJjN8sDufR3YqUQCZAaeT QhhzkHBBqGs8GAAymP5zpNw= =Tj9e -----END PGP SIGNATURE----- From kloch at hotnic.net Fri May 13 13:39:34 2005 From: kloch at hotnic.net (Kevin Loch) Date: Fri, 13 May 2005 13:39:34 -0400 Subject: [ppml] IPv6>>32 In-Reply-To: References: <1115994295.17083.14.camel@ablate.merit.edu> <011701c557cb$7f80eb20$6601a8c0@stephen> Message-ID: <4284E656.1060401@hotnic.net> Glenn Wiltse wrote: > I have heard people desribe a end site as anything from a > business to a person. Which leaves alot of room for confusion > as to what is right. I beleive some people even consider that > possibly a phone or other device could be considered a 'end site' > and therefore deserving of a /48. Phones and devices are not capable of entering into business relationships (at least here in Virginia), so the entity with the business relationship with the ISP would not qualify for an additional /48 after they assigned it to the device. If the entity was an ISP they could assign a /48 to their own device(s) in each POP under current policy, but that's it. > > The other deffintion of importance here is ISP/LIR... I think > one could easily argue that a university such as lets say Columbia > is a ISR. (Or maybe MSU, UofM, WSU, etc...) Columbia University > was indeed given a /32 by ARIN. I'm not sure how they justified this > this direct allocation from ARIN. However it clearly was done. Most if not all universities could easily qualify for a /32 from ARIN under current policy. > Anyway, back to my point... The bottom line seems to be how you define a > ISP and/or a End Site. Untill people can agree on these types of > diffintions, the current ARIN policy is very nebulous at best. I think the definitions are very clear. They are also very liberal which causes confusion when people try to project limitations into them that aren't there. If we don't want universities to be able to assign a /48 to each student the policy needs to be changed to reflect that. I don't see how we can do that without singling out "university students". - Kevin From owen at delong.com Fri May 13 13:51:25 2005 From: owen at delong.com (Owen DeLong) Date: Fri, 13 May 2005 10:51:25 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: References: Message-ID: > 3. Network Operator returns a second time, rinse and repeat. ====== > But eventually, confidence in v6 renumbering is high and > the network operator renumbers one of its /28 blocks into > a new /27. ====== The complete and total lack of any evidence to support this assertion in any way whatsoever and the overwhelming historical evidence to the contrary are what make your entire proposed scenario a really bad idea. It is hard for me to imagine a scenario where an LIR could justify a /28, let alone a /12 (remember, a /28 is 16 times as many /64 subnets as there are addresses in the IPv4), but, I think that forced fragmentation is an absolutely bad idea. If we're going to spend lots of addresses optimizing anything in v6, it should be looking for ways to minimize the amount of prefix fragmentation which occurs. If we're going to put an artificial upper limit on instantaneous allocations, we should at least allow ARIN to reserve the full justified space for some time, and, second and subsequent rounds should be done in such a way as to preserve contiguity and minimize fragmentation as much as possible. At least as long as we are stuck with an IDR protocol which requires absolute global knowledge in the DFZ. Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From owen at delong.com Fri May 13 13:55:22 2005 From: owen at delong.com (Owen DeLong) Date: Fri, 13 May 2005 10:55:22 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: References: Message-ID: > I know exactly what the benefits and downsides of NAT are. > But it runs all the things that I want to run at home > just fine. For anything else, I have a colocated server > elsewhere in a nice data centre. > http://www.vix.com/personalcolo/ > > I think this is also the pattern followed by Joe User > although his "server" is likely to be a shared server > running a blog or a wiki, than my *nix box. If colo is working for you, great. I'm not using colo, and, NAT would definitely break things for me. Can you point to a single benefit from NAT (NAT, not ancillary benefits from stateful inspection) besides synthetic address conservation?(*) Owen * I call the address conservation synthetic because it is really address use optimization. There still needs to be at least one external 48 bit address/port for every flow in use at any given time. Of course, with a single /32, you usually get enough 48 bit tuples for most household applications, but, not always. -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From owen at delong.com Fri May 13 14:07:04 2005 From: owen at delong.com (Owen DeLong) Date: Fri, 13 May 2005 11:07:04 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: <1115994295.17083.14.camel@ablate.merit.edu> References: <1115994295.17083.14.camel@ablate.merit.edu> Message-ID: <95480F3F9E0865059C929E46@imac-en0.delong.sj.ca.us> --On Friday, May 13, 2005 10:24 AM -0400 "Larry J. Blunk" wrote: > On Fri, 2005-05-13 at 10:31 +0100, Michael.Dillon at radianz.com wrote: >> > o Increasing the HD ratio, or a flat utilization threshold fixes >> > any possible shortage. If that doesn't do it, /48 -> /56 >> > would. The more I look at the numbers, the more convinced I >> > am that /48 should be left alone and a flat threshold be used >> > (perhaps 60%). >> >> I agree that the /48 --> /56 issue is definitely second priority. >> If we can solve the immediate problem by adjusting the HD ratio >> rules then we should limit current action to that area. >> > > I think there are other reasons for considering /56's. Consider, > for example, university dorms rooms. Should each of them get a /48? > The University of Michigan has 5793 dorms and 1483 family housing > apartments (ref -- http://www.housing.umich.edu/general/factsheet.html). > You'd need a /35 at a minimum to give everyone a /48 and that wouldn't > leave much headroom or flexibility in addressing hierarchy. > Realistically, you probably want to assign a /32. > And the policy states that such a situation would be an LIR anyway, as they obviously have at least 200 students (external customers) subscribing to their IP service. Voila... They get a /32 anyway. > Merit provides Internet access for 13 universities and the State > of Michigan. Based on the above considerations, we asked for a /28 > from ARIN (enough for a /32 for each university and the state). Our > application was denied, and we only received a /32. What size prefix > should allocate to the universities (ARIN suggested a /40)? What > prefix size should we advise them to assign to dorm rooms? > Since each of them would qualify as an LIR most likely, I see no problem with each of them getting a /32 under existing policy and if they wanted to aggregate within your block, I can see no justification for not approving a /28 to deal with that. However, I think that the policy makes it pretty clear that they could each qualify for a /32 as an LIR direct. If they can use a /40, that's reasonable, too, depending on each other university's particular needs. Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From owen at delong.com Fri May 13 14:12:37 2005 From: owen at delong.com (Owen DeLong) Date: Fri, 13 May 2005 11:12:37 -0700 Subject: [ppml] Proposed Policy: IPv6 HD ratio/ Really public involvment In-Reply-To: <4284CAE1.9040801@well.com> References: <10ECB7F03C568F48B9213EF9E7F790D209B13C@wava00s2ke2k01.corp.pvt> <4284CAE1.9040801@well.com> Message-ID: I realize that there are people who are completely opposed to top posting. However, there are times when it is useful, and, times when it is confusing. In this case, I figure it's not particularly confusing, and, it allows those who have been following the thread to read the new material with having to scan past or through the quotation, while still providing context for those that start at this message. In other cases, you'll notice that I tend to either intersperse or bottom post when I think that the context is more important to my comments. Owen --On Friday, May 13, 2005 11:42 AM -0400 Chip Mefford wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Azinger, Marla wrote: >|> From my experience I have found there are a large number of people > within the Internet Community that read about 75% of these postings. > They also form an opinion. However, they refrain from commenting. Why? > I have been told by many..."because you already said what I was > thinking" or "because I dont like speaking or commenting in public forum > so I just wait until someone else says what I'm thinking." > > > There are also those of us who might interject something, but since the > format is a top-posted, jeaporday style thread, it's difficult > to contribute without being misconstrued. > > Please don't top post. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.0 (GNU/Linux) > > iD8DBQFChMrh0STXFHxUucwRAgznAKCYKrTEYG3ZXynWHhxmiL3hlZABRQCfQrL+ > yAmhSZS37ETPihHcE7ccznw= > =jq+r > -----END PGP SIGNATURE----- -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From david.conrad at nominum.com Fri May 13 14:29:37 2005 From: david.conrad at nominum.com (David Conrad) Date: Fri, 13 May 2005 11:29:37 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: <20050511221218.9AA7A1EE102@mx2.nominum.com> References: <20050511221218.9AA7A1EE102@mx2.nominum.com> Message-ID: <51CA4498-AF7D-4992-A01D-E9C05CED8B04@nominum.com> [Speaking only for myself] Tony, On May 11, 2005, at 3:12 PM, Tony Hain wrote: > You appear to be thinking in terms of existing fixed networks and the > cumbersome tools that vendors provide for managing those. It is not > hard to > imagine a personal area and/or vehicle network where the handset/ > router > changes providers between available short range and long range > radios over > fairly short time periods. It is also not hard to imagine world peace, the hard part is actually getting there... > Renumbering is not a complex task. If renumbering was not a complex task, then no one would need worry about provider independent space. In a note you sent to PPML on 4/27, you said (when discussing a non-provider-based routing approach): >> ] Given a >> ] choice between provider-lock/renumbering-pain vs. a little bit >> more for a >> ] diverted fiber run, I am sure businesses would favor the known >> cost of fiber >> ] over the unknown and potentially lethal costs of yielding to the >> provider. I don't think you can have it both ways. If renumbering is easy, no one would worry about the cost of renumbering and there would be no provider lock. If renumbering isn't easy, people with significant network infrastructure would be (rightly) worried about the cost of renumbering and hence be susceptible to being locked into a provider. My contention, which has at least been corroborated by a couple of people from larger enterprises, is that renumbering actually is a complex task and will remain so for the foreseeable future given the current IPv6 architecture. For this reason, if IPv6 is going to be deployed in significant amounts, we will be exactly repeating the history of IPv4 address allocations with the folks getting /19s and / 20s today being the equivalent of folks getting class As in pre- history. Assertions about the huge number of /48s or /45s are irrelevant given medium size telcos are getting /19s and /20s. As such, it would seem to be prudent to be somewhat conservative in allocations. > Comparing IPv6 allocation practice to IPv4 > practice is not overly useful because one is allocating the demarc > for a > network while the other is allocating for a specific number of > devices. Interesting observation. This would appear to argue that the entire concept of the HD ratio is spurious since host density would be irrelevant. Hmm. Rgds, -drc [Speaking only for myself. Really] From lea.roberts at stanford.edu Fri May 13 15:29:09 2005 From: lea.roberts at stanford.edu (Lea Roberts) Date: Fri, 13 May 2005 12:29:09 -0700 (PDT) Subject: [ppml] IPv6>>32 In-Reply-To: <95480F3F9E0865059C929E46@imac-en0.delong.sj.ca.us> Message-ID: I think this /48 per room stuff is just a little over the top. Is this "just because we can"?? Let's try to show a little sense and some version of reality rather than extreme future fantasy... are there really going to be 64K *subnets* in each dorm room??? which brings me another complaint about this thread... people are talking like networks should assign a /64 per host. these are subnets, people!! they might even have 10s of hosts using one prefix! more comments inline for the top-posting averse... On Fri, 13 May 2005, Owen DeLong wrote: > > --On Friday, May 13, 2005 10:24 AM -0400 "Larry J. Blunk" > wrote: > > > On Fri, 2005-05-13 at 10:31 +0100, Michael.Dillon at radianz.com wrote: > >> > >> I agree that the /48 --> /56 issue is definitely second priority. > >> If we can solve the immediate problem by adjusting the HD ratio > >> rules then we should limit current action to that area. > >> > > > > I think there are other reasons for considering /56's. Consider, > > for example, university dorms rooms. Should each of them get a /48? > > The University of Michigan has 5793 dorms and 1483 family housing > > apartments (ref -- http://www.housing.umich.edu/general/factsheet.html). > > You'd need a /35 at a minimum to give everyone a /48 and that wouldn't > > leave much headroom or flexibility in addressing hierarchy. > > Realistically, you probably want to assign a /32. > > > And the policy states that such a situation would be an LIR anyway, as they > obviously have at least 200 students (external customers) subscribing to > their IP service. Voila... They get a /32 anyway. you are building a network here... one can imagine a future topology where there might really be a router per room (the reason you would assign a /48 under current policy), then might not a /60 be a reasonable allocation through that router, to a single room?? Now we're back to the /64 per host; it never quits. BTW, I don't think the ability to switch providers argument is going to apply to dorm rooms (but I suppose that's just because I'm unimaginative and closed minded. :-) So thanks for an excellent example of how the current policy really does need some clarification. > > Merit provides Internet access for 13 universities and the State > > of Michigan. Based on the above considerations, we asked for a /28 > > from ARIN (enough for a /32 for each university and the state). Our > > application was denied, and we only received a /32. What size prefix > > should allocate to the universities (ARIN suggested a /40)? What > > prefix size should we advise them to assign to dorm rooms? > > > Since each of them would qualify as an LIR most likely, I see no problem > with > each of them getting a /32 under existing policy and if they wanted to > aggregate within your block, I can see no justification for not approving > a /28 to deal with that. However, I think that the policy makes it > pretty clear that they could each qualify for a /32 as an LIR direct. > If they can use a /40, that's reasonable, too, depending on each other > university's particular needs. Obviously, I should get in the application for Stanford's /32 before some sanity returns to IPv6 address policy... gotta run, /Lea From dogwallah at gmail.com Fri May 13 16:02:53 2005 From: dogwallah at gmail.com (McTim) Date: Fri, 13 May 2005 23:02:53 +0300 Subject: [ppml] Proposed Policy: IPv6 HD ratio/ Really public involvment In-Reply-To: References: <10ECB7F03C568F48B9213EF9E7F790D209B13C@wava00s2ke2k01.corp.pvt> <4284CAE1.9040801@well.com> Message-ID: Hi Ed, On 5/13/05, Edward Lewis wrote: > > > I think one reason there isn't broad input is that fringe players > like me (and those even further out) have a hard time navigating > through all of the threads. Besides misconstrued and mis-attributed > statements, it's the track of the discussion that is hard to follow. ACK > > What would be helpful is an active editor of the discussion, someone > tracking what is said and laying out the discussion for those that > don't live and breath this stuff. E.g., I've completely lost the > meaning of the subject line "IPv6>>32" - and how does this relate to > a proposed policy? I think this is a fine idea. It might even help in determining *consensus*. Cheers, McTim nic-hdl: TMCG If you understood what I was saying, you'd now what I was thinking, maybe...or not From stephen at sprunk.org Fri May 13 16:05:16 2005 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 13 May 2005 15:05:16 -0500 Subject: [ppml] IPv6>>32 References: <1115994295.17083.14.camel@ablate.merit.edu> <95480F3F9E0865059C929E46@imac-en0.delong.sj.ca.us> Message-ID: <026e01c557f8$39f28c30$6601a8c0@stephen> Thus spake "Owen DeLong" > And the policy states that such a situation would be an LIR anyway, > as they obviously have at least 200 students (external customers) > subscribing to their IP service. Voila... They get a /32 anyway. I agree that's what the letter of the policy states, but I can't imagine that's what was intended. Assigning a /48 to each student violates simple common sense. Yes, I know there's enough /48s for every human on the planet, but we're going to have serious problems down the road if we start allocating a /48 for each host, which is the vast majority of cases in a dorm today and for the conceivable future. Burning a /64 per host is bad enough, but I could be convinced to accept that if Merit said they liked that idea (I personally doubt they do). Not to mention what actually deploying such a setup would do to the existing IPv4 addressing plan. What are the odds ARIN would approve Merit (today, ignoring their legacy /8) requesting an IPv4 /12 so they could give every student (38,000 cited elsewhere in the thread) a /29? That's what we'd be forcing them to do if they had to provide a subnet per student. Perhaps some vendor will come out with a whiz-bang device that allows a shared IPv4 subnet while routing IPv6 natively, but I'm not aware of anything like that on the market or even proposed for development. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From terry.l.davis at boeing.com Fri May 13 16:25:48 2005 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Fri, 13 May 2005 13:25:48 -0700 Subject: [ppml] IPv6>>32 Message-ID: David/Tony A case in point: A long range aircraft (747/A-340/777/A-380) often carries approaching fifty (50) independent antennas; mixed short range, long range, and satcom. The airline typically has from 3 to 6 service providers for just "air traffic control" links around the globe. And often a half dozen or more links are generally active simultaneously and coming and going constantly. I anticipate that within about 10 years most of these will be converted to use IP (most likely IP-v6). There will probably still be about the same number of antennas, same number of global service providers (ISP's by then), and it will still have many links to different providers active at the same time and coming and going constantly. Take care Terry -----Original Message----- From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On Behalf Of David Conrad Sent: Friday, May 13, 2005 11:30 AM To: Tony Hain Cc: Michael.Dillon at radianz.com; ppml at arin.net Subject: Re: [ppml] IPv6>>32 [Speaking only for myself] Tony, On May 11, 2005, at 3:12 PM, Tony Hain wrote: > You appear to be thinking in terms of existing fixed networks and the > cumbersome tools that vendors provide for managing those. It is not > hard to > imagine a personal area and/or vehicle network where the handset/ > router > changes providers between available short range and long range > radios over > fairly short time periods. It is also not hard to imagine world peace, the hard part is actually getting there... From owen at delong.com Sat May 14 05:24:12 2005 From: owen at delong.com (Owen DeLong) Date: Sat, 14 May 2005 02:24:12 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: <51CA4498-AF7D-4992-A01D-E9C05CED8B04@nominum.com> References: <20050511221218.9AA7A1EE102@mx2.nominum.com> <51CA4498-AF7D-4992-A01D-E9C05CED8B04@nominum.com> Message-ID: > My contention, which has at least been corroborated by a couple of > people from larger enterprises, is that renumbering actually is a > complex task and will remain so for the foreseeable future given the > current IPv6 architecture. For this reason, if IPv6 is going to be > deployed in significant amounts, we will be exactly repeating the > history of IPv4 address allocations with the folks getting /19s and / 20s > today being the equivalent of folks getting class As in pre- history. > Assertions about the huge number of /48s or /45s are irrelevant given > medium size telcos are getting /19s and /20s. As such, it would seem to > be prudent to be somewhat conservative in allocations. > Your enterprise does not have to be particularly large for renumbering to be a complex task. Imagine even a small company with a couple of hundred customers who connect over VPN tunnels. Now, imagine renumbering all of the virtual addresses used on the client side and all of the tunnel end point addresses for that series of customer connections in order to switch providers. That can happen to a relatively small business and still be quite an economic issue. Especially if it occurs as a result of a vendor-viability issue with the upstream provider, thus producing potentially short notice. Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From owen at delong.com Sat May 14 05:36:12 2005 From: owen at delong.com (Owen DeLong) Date: Sat, 14 May 2005 02:36:12 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: <026e01c557f8$39f28c30$6601a8c0@stephen> References: <1115994295.17083.14.camel@ablate.merit.edu> <95480F3F9E0865059C929E46@imac-en0.delong.sj.ca.us> <026e01c557f8$39f28c30$6601a8c0@stephen> Message-ID: <8A3E9A9D47115A1D6796AB55@imac-en0.delong.sj.ca.us> --On Friday, May 13, 2005 3:05 PM -0500 Stephen Sprunk wrote: > Thus spake "Owen DeLong" >> And the policy states that such a situation would be an LIR anyway, >> as they obviously have at least 200 students (external customers) >> subscribing to their IP service. Voila... They get a /32 anyway. > > I agree that's what the letter of the policy states, but I can't imagine > that's what was intended. > > Assigning a /48 to each student violates simple common sense. Yes, I know > there's enough /48s for every human on the planet, but we're going to have > serious problems down the road if we start allocating a /48 for each host, > which is the vast majority of cases in a dorm today and for the > conceivable future. Burning a /64 per host is bad enough, but I could be > convinced to accept that if Merit said they liked that idea (I personally > doubt they do). > I think by default, each student should get a /64. If, however, the student expresses need for multiple subnets, then, I think a /48 is exactly what was intended under the policy. I'm not making any value judgments at this point as to whether the policy is good or bad, but, that is my understanding of its intent. > Not to mention what actually deploying such a setup would do to the > existing IPv4 addressing plan. What are the odds ARIN would approve > Merit (today, ignoring their legacy /8) requesting an IPv4 /12 so they > could give every student (38,000 cited elsewhere in the thread) a /29? > That's what we'd be forcing them to do if they had to provide a subnet > per student. > This is where IPv4 != IPv6 and there does start to be some reason to consider that addresses are no longer scarce. In IPv4, it is hard to imagine assigning a static address to every person on the planet. In IPv6, it is hard to imagine the population being sufficient that each person could not have a /64. > Perhaps some vendor will come out with a whiz-bang device that allows a > shared IPv4 subnet while routing IPv6 natively, but I'm not aware of > anything like that on the market or even proposed for development. > I guess I'm not understanding the situation you are describing here. There are several ways to do 6:4 gateways which would allow you to run v4 and v6 on the same segment. There is nothing which requires you to match your v4 topology to your v6 topology. Most Cisco routers can bridge any protocol which is not routed on a given interface, so, I think CRB should be possible between v4/v6 as you describe, although I have not tested it. Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From kloch at hotnic.net Sat May 14 11:03:37 2005 From: kloch at hotnic.net (Kevin Loch) Date: Sat, 14 May 2005 11:03:37 -0400 Subject: [ppml] Universities (was IPv6>>32) In-Reply-To: <8A3E9A9D47115A1D6796AB55@imac-en0.delong.sj.ca.us> References: <1115994295.17083.14.camel@ablate.merit.edu> <95480F3F9E0865059C929E46@imac-en0.delong.sj.ca.us> <026e01c557f8$39f28c30$6601a8c0@stephen> <8A3E9A9D47115A1D6796AB55@imac-en0.delong.sj.ca.us> Message-ID: <42861349.2020203@hotnic.net> Owen DeLong wrote: > I think by default, each student should get a /64. If, however, the student > expresses need for multiple subnets, then, I think a /48 is exactly what was > intended under the policy. It's not about wether a student needs 65k subnets, it's about wether they need 2. Assigning 2 /64's to a student would violate current policy where assigning a /48 would not. Interestingly, while they could assign a /48 per _student_, they could not assign a /48 per _room_. "Assignments" are made to legal entities and show up in swip/rwhois. They only get one /48 per campus for their own infrastructure, so a /64 per room could be done but a /48 could not. If a University was sure they would not be assigning /48's to anyone (faculty, on/off campus students, vendors, commercial/industrial partners) then a /48 per campus would be all they need. If they plan on assigning /48's then they should get a /32. I expect most universities will eventually ask for and receive their own /32. For that reason, reigonal networks that serve them should probably not get a large allocation (> /32) based on total downstream university customers. - Kevin From dogwallah at gmail.com Sun May 15 23:51:51 2005 From: dogwallah at gmail.com (McTim) Date: Mon, 16 May 2005 06:51:51 +0300 Subject: [ppml] Universities (was IPv6>>32) In-Reply-To: <42861349.2020203@hotnic.net> References: <1115994295.17083.14.camel@ablate.merit.edu> <95480F3F9E0865059C929E46@imac-en0.delong.sj.ca.us> <026e01c557f8$39f28c30$6601a8c0@stephen> <8A3E9A9D47115A1D6796AB55@imac-en0.delong.sj.ca.us> <42861349.2020203@hotnic.net> Message-ID: hello all, I think the global policy was worded in a sufficiently vague way to allow for a wide variety of interpretation. On 5/14/05, Kevin Loch wrote: > Owen DeLong wrote: > > I think by default, each student should get a /64. If, however, the student > > expresses need for multiple subnets, then, I think a /48 is exactly what was > > intended under the policy. > > It's not about wether a student needs 65k subnets, it's about wether > they need 2. Assigning 2 /64's to a student would violate current > policy where assigning a /48 would not. Hmm I read it as not quite that strict: If "by design" a university network planner wanted to give a /64 to each student for their mobile devices and another for their room, then this fits the policy IMO. Of course, the /64 to the room would be assigned to the housing entity and not to the students themselves. > > Interestingly, while they could assign a /48 per _student_, they could > not assign a /48 per _room_. "Assignments" are made to legal entities > and show up in swip/rwhois. not necessarily, my reading of 6.3.3 doesn't mention SWIP/WHOIS or "legal entities". If I was a planning a university network, I would assign to /48s to organisational units (Office of Campus Housing for instance), and then have those units sub-assign /64s to individual dorm rooms. However, when submitting my allocation application, I might be tempted to "plan" to assign a /48 per room/student. ;-) > > If a University was sure they would not be assigning /48's to anyone > (faculty, on/off campus students, vendors, commercial/industrial > partners) then a /48 per campus would be all they need. If they plan on > assigning /48's then they should get a /32. sounds reasonable to me, (as long as they are willing to do the things needed to get an allocation). > > I expect most universities will eventually ask for and receive their > own /32. For that reason, reigonal networks that serve them should > probably not get a large allocation (> /32) based on total downstream > university customers. > If a university wants to have a relationship with ARIN, they probably can get a /32. However, if they want to join a consortium that has the relationship with the RIR, then I see no problem with this "regional network" getting a larger block, as v6 allows for more hierarchy by design. Cheers, McTim nic-hdl: TMCG source: AFRINIC From owen at delong.com Mon May 16 01:03:51 2005 From: owen at delong.com (Owen DeLong) Date: Sun, 15 May 2005 22:03:51 -0700 Subject: [ppml] Universities (was IPv6>>32) In-Reply-To: <42861349.2020203@hotnic.net> References: <1115994295.17083.14.camel@ablate.merit.edu> <95480F3F9E0865059C929E46@imac-en0.delong.sj.ca.us> <026e01c557f8$39f28c30$6601a8c0@stephen> <8A3E9A9D47115A1D6796AB55@imac-en0.delong.sj.ca.us> <42861349.2020203@hotnic.net> Message-ID: <2147483647.1116194629@[172.17.1.152]> --On Saturday, May 14, 2005 11:03 -0400 Kevin Loch wrote: > Owen DeLong wrote: >> I think by default, each student should get a /64. If, however, the >> student expresses need for multiple subnets, then, I think a /48 is >> exactly what was intended under the policy. > > It's not about wether a student needs 65k subnets, it's about wether > they need 2. Assigning 2 /64's to a student would violate current > policy where assigning a /48 would not. > Right... However, why is that really a problem? I can see some reasons to potentially assign the student a /56, but, I think that /63s are probably not a great idea if they can be avoided. > Interestingly, while they could assign a /48 per _student_, they could > not assign a /48 per _room_. "Assignments" are made to legal entities > and show up in swip/rwhois. They only get one /48 per campus for their > own infrastructure, so a /64 per room could be done but a /48 could not. > Sure it could. Each room could be dubbed an organizational unit or department. > If a University was sure they would not be assigning /48's to anyone > (faculty, on/off campus students, vendors, commercial/industrial > partners) then a /48 per campus would be all they need. If they plan on > assigning /48's then they should get a /32. > Right. If they aren't going to be an LIR, then, they should get a /48. If they're going to function as an LIR, then, a /32 is in order. > I expect most universities will eventually ask for and receive their > own /32. For that reason, reigonal networks that serve them should > probably not get a large allocation (> /32) based on total downstream > university customers. > I'm not so sure about that. I think that universities that are not going to act as LIRs should be counted as part of their upstream LIR customer base for addressing. Universities that do intend to act as LIRs should get their own space from the RIR. I don't think that is broken under current policy. Owen -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From jwkckid1 at ix.netcom.com Mon May 16 04:30:40 2005 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Mon, 16 May 2005 01:30:40 -0700 Subject: [ppml] Proposed Policy: IPv6 HD ratio/ Really public involvment References: <10ECB7F03C568F48B9213EF9E7F790D209B13C@wava00s2ke2k01.corp.pvt> <4284CAE1.9040801@well.com> <4284DE8A.1070101@well.com> Message-ID: <42885A2E.F61C6A62@ix.netcom.com> Chip and all, I am amazed that such a trivial thing would even be mentioned on this forum. If you have a problem with following a thread Chip, take a class on Forum list comprehension... Chip Mefford wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Glenn Wiltse wrote: > | Oh, come on... please don't get started on a debate of top or bottom > | posting... or posting in between for that matter. It's trivial attacks > | of this nature that detur some more timid folks from posting. > | > | Glenn Wiltse > > Glenn, > > It was neither an attack, nor trivial. It was a declarative > statement. Such things make threads difficult to follow, and discourge > interjection. > > It is difficult to avoid being misconstrued if context > is not kept. > > This is a pretty intimidating list as it is. There was > a statement made that implied that things might move > along better if there were more input. I made my > observation. > > It seems pretty clear to me, that /right here/ is a good > enough example of me at least, wanting back into lurk > mode most desperately. > > I know this is true for me, I can fairly intuit it > is for others also. > > This is a high traffic list, I have a day job. I try to read > as much of this list as I can, some threads might go on > for a week or so before I even begin on them. > I'm sure I am not alone. > - -- > > | > | On Fri, 13 May 2005, Chip Mefford wrote: > | > | > | Azinger, Marla wrote: > | |>From my experience I have found there are a large number of people > | within the Internet Community that read about 75% of these postings. > | They also form an opinion. However, they refrain from commenting. Why? > | I have been told by many..."because you already said what I was > | thinking" or "because I dont like speaking or commenting in public forum > | so I just wait until someone else says what I'm thinking." > | > | > | There are also those of us who might interject something, but since the > | format is a top-posted, jeaporday style thread, it's difficult > | to contribute without being misconstrued. > | > | Please don't top post. > > !DSPAM:4284cc0e2341125504042! > > | Just so your clear on my posistion, I'll post on both top and bottom. > > | Oh, come on... please don't get started on a debate of top or bottom > | posting... or posting in between for that matter. It's trivial attacks > | of this nature that detur some more timid folks from posting. > > | Glenn Wiltse > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.0 (GNU/Linux) > > iD8DBQFChN6K0STXFHxUucwRAge6AJsE0nb9oTdprWqUJjN8sDufR3YqUQCZAaeT > QhhzkHBBqGs8GAAymP5zpNw= > =Tj9e > -----END PGP SIGNATURE----- Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 From Michael.Dillon at radianz.com Mon May 16 05:09:01 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Mon, 16 May 2005 10:09:01 +0100 Subject: [ppml] IPv6>>32 In-Reply-To: Message-ID: > I think this /48 per room stuff is just a little over the top. > Is this "just because we can"?? Let's try to show a little sense > and some version of reality rather than extreme future fantasy... > are there really going to be 64K *subnets* in each dorm room??? I think people are confused about whether dorm rooms are like private apartments or like hotel rooms. If they are like private apartments, then they should get a /48 but if they are like hotel rooms, then a /64 should be able to service a whole floor if not more. I suspect that the majority of dorms are more like student hotels than they are like private apartments. In any case, I don't think it is fruitful to try to count the number of subnets or hosts in any particular room. > which brings me another complaint about this thread... people > are talking like networks should assign a /64 per host. these are > subnets, people!! they might even have 10s of hosts using one prefix! Again, what are we talking about? Are hosts single machines with a single port providing an IPv6 network attachment point? Or are they devices containing several internal IPv6 networks, each communicating with different external IPv6 networks doing jobs like service monitoring, control plane, data collection... Again, I don't think it is fruitful to start getting into the internal architecture of devices to decide whether or not they are hosts. If the person in charge of said device says that a /64 is required, then I'm happy to give a /64. Simple rules of thumb can be applied to resolve these kinds of issues. --Michael Dillon From Michael.Dillon at radianz.com Mon May 16 05:13:26 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Mon, 16 May 2005 10:13:26 +0100 Subject: [ppml] IPv6>>32 In-Reply-To: Message-ID: > Your enterprise does not have to be particularly large for renumbering to > be a complex task. Imagine even a small company with a couple of hundred > customers who connect over VPN tunnels. Now, imagine renumbering all of > the virtual addresses used on the client side and all of the tunnel end > point addresses for that series of customer connections in order to > switch providers. I'm afraid I can't imagine this since I do not have the IPv6 operational experience to extrapolate. I do know enough to realize thatr my IPv4 experience does not apply. Does anyone here know of a resource that explains how IPv6 renumbering is accomplished in a real-world operational context? I know that there are many medium-sized networks who have gone through IPv6 renumbering recently as they transitioned off the 6-bone tunnels and onto native IPv6 networks. --Michael Dillon From stephen at sprunk.org Mon May 16 10:48:37 2005 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 16 May 2005 09:48:37 -0500 Subject: [ppml] IPv6>>32 References: Message-ID: <003f01c55a26$8050c040$6601a8c0@stephen> Thus spake > > I think this /48 per room stuff is just a little over the top. > > Is this "just because we can"?? Let's try to show a little sense > > and some version of reality rather than extreme future fantasy... > > are there really going to be 64K *subnets* in each dorm room??? > > I think people are confused about whether dorm rooms are > like private apartments or like hotel rooms. If they are > like private apartments, then they should get a /48 but if > they are like hotel rooms, then a /64 should be able to > service a whole floor if not more. I suspect that the majority > of dorms are more like student hotels than they are like > private apartments. In any case, I don't think it is fruitful > to try to count the number of subnets or hosts in any particular > room. I would classify dorms as "student hotels" and assign a /64 per floor (or per building even) unless a student specifically asked for their own /64 or /48. Unfortunately, I'm not sure that's permitted under existing policy if the student is paying the university -- or if a guest is paying a hotel -- for Internet access. Extending this to the absurd, if the university (or other ISP) were offering service via 802.11, would we still require them to hand out a /48 per user/customer? Are there even any consumer-grade devices that work in such a scenario? > > which brings me another complaint about this thread... people > > are talking like networks should assign a /64 per host. these > > are subnets, people!! they might even have 10s of hosts using > > one prefix! > > Again, what are we talking about? Are hosts single machines with > a single port providing an IPv6 network attachment point? Or are > they devices containing several internal IPv6 networks, each > communicating with different external IPv6 networks doing jobs > like service monitoring, control plane, data collection... > Again, I don't think it is fruitful to start getting into the > internal architecture of devices to decide whether or not they > are hosts. The reality is that today and for the conceivable future a single human will only have a few to a few dozen devices needing a handful of addresses each -- and that's allowing for a lot of growth from today's norm of one IP per user -- which is well within the realm of simple, existing, cheap L2 technology. We can throw around ideas of fruit crates (or even fruits) that need their own subnets for internal communication, but until such devices actually appear (and IMHO, it will not be within my lifetime), we shouldn't be wasting 80 bits of addressing on each human when only one to five bits will be used in the vast majority of cases. > If the person in charge of said device says that > a /64 is required, then I'm happy to give a /64. Agreed. But policy shouldn't _force_ people to deal with having their own /64 or /48 when they're happy getting one or more /128s out of a shared pool. > Simple rules of thumb can be applied to resolve these kinds of > issues. ARIN doesn't operate on simple rules of thumb; it operates on policies. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From bmanning at vacation.karoshi.com Mon May 16 11:31:57 2005 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 16 May 2005 15:31:57 +0000 Subject: [ppml] IPv6>>32 In-Reply-To: References: Message-ID: <20050516153157.GB29534@vacation.karoshi.com.> On Mon, May 16, 2005 at 10:13:26AM +0100, Michael.Dillon at radianz.com wrote: > > Your enterprise does not have to be particularly large for renumbering > to > > be a complex task. Imagine even a small company with a couple of > hundred > > customers who connect over VPN tunnels. Now, imagine renumbering all of > > the virtual addresses used on the client side and all of the tunnel end > > point addresses for that series of customer connections in order to > > switch providers. > > I'm afraid I can't imagine this since I do not have the IPv6 > operational experience to extrapolate. I do know enough to realize > thatr my IPv4 experience does not apply. Does anyone here know of > a resource that explains how IPv6 renumbering is accomplished in > a real-world operational context? I know that there are many > medium-sized networks who have gone through IPv6 renumbering recently > as they transitioned off the 6-bone tunnels and onto native > IPv6 networks. > > --Michael Dillon having renumbered both v4 and v6, it has been my experience that renubmering v6 networks is much more complex than IPv4... if only due to the fact that there are more places in an IPv6 network that "think" they are supposed to be responsible for autoconfiguring everything else in the network. and these nodes have to be told to shut up. --bill From stephen at sprunk.org Mon May 16 11:38:01 2005 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 16 May 2005 10:38:01 -0500 Subject: [ppml] IPv6>>32 References: <1115994295.17083.14.camel@ablate.merit.edu> <95480F3F9E0865059C929E46@imac-en0.delong.sj.ca.us> <026e01c557f8$39f28c30$6601a8c0@stephen> <8A3E9A9D47115A1D6796AB55@imac-en0.delong.sj.ca.us> Message-ID: <009801c55a30$546c7050$6601a8c0@stephen> Thus spake "Owen DeLong" > --On Friday, May 13, 2005 3:05 PM -0500 Stephen Sprunk wrote: > > I agree that's what the letter of the policy states, but I can't imagine > > that's what was intended. > > > > Assigning a /48 to each student violates simple common sense. > > Yes, I know there's enough /48s for every human on the planet, > > but we're going to have serious problems down the road if we start > > allocating a /48 for each host, which is the vast majority of cases > > in a dorm today and for the conceivable future. Burning a /64 per > > host is bad enough, but I could be convinced to accept that if Merit > > said they liked that idea (I personally doubt they do). > > I think by default, each student should get a /64. If, however, the > student expresses need for multiple subnets, then, I think a /48 is > exactly what was intended under the policy. "6.5.4.1 Assignment address space size Assignments are to be made in accordance with the existing guidelines (RFC3177,RIRs-on-48), which are summarized here as: - /48 in the general case, except for very large subscribers - /64 when it is known that one and only one subnet is needed by design - /128 when it is absolutely known that one and only one device is connecting." This appears to prevent ISPs (i.e. universities) from assigning anything longer than a /48 to customers (i.e. students) in most cases unless they do not qualify as "end sites". "6.2.9. End site An end site is defined as an end user (subscriber) who has a business relationship with a service provider that involves: 1. that service provider assigning address space to the end user 2. that service provider providing transit service for the end user to other sites 3. that service provider carrying the end user's traffic. 4. that service provider advertising an aggregate prefix route that contains the end user's assignment" AFAICT, each student at a university qualifies as an "end site". Therefore, unless the specific criteria for a /64 or /128 are met for each student, which is certainly not guaranteed nor feasible to determine, each student must be assigned a /48. Interestingly, the above could also be (mis)read to say that businesses need to assign a /48 to each employee. > I'm not making any value judgments at this point as to whether the > policy is good or bad, but, that is my understanding of its intent. I think you may be right about its intent, but if we are correct then that intent was not correctly written into the policy. > > Not to mention what actually deploying such a setup would do to > > the existing IPv4 addressing plan. What are the odds ARIN would > > approve Merit (today, ignoring their legacy /8) requesting an IPv4 > > /12 so they could give every student (38,000 cited elsewhere in > > the thread) a /29? That's what we'd be forcing them to do if they > > had to provide a subnet per student. > > This is where IPv4 != IPv6 and there does start to be some reason to > consider that addresses are no longer scarce. In IPv4, it is hard to > imagine assigning a static address to every person on the planet. > In IPv6, it is hard to imagine the population being sufficient that > each person could not have a /64. I'm working with the assumption that v6 and v4 will be deployed with the same topology, which has yet to be disproven. If we give each student an IPv6 /64 (or /48), then we'd need to give them an IPv4 /29 or shorter too. > > Perhaps some vendor will come out with a whiz-bang device that > > allows a shared IPv4 subnet while routing IPv6 natively, but I'm not > > aware of anything like that on the market or even proposed for > > development. > > I guess I'm not understanding the situation you are describing here. > There are several ways to do 6:4 gateways which would allow you to > run v4 and v6 on the same segment. We're talking about native v4 and native v6, not some gatewayed or NATed service. > There is nothing which requires you to match your v4 topology to > your v6 topology. I'm not aware of any off-the-shelf consumer-grade solution which allows them to be different. > Most Cisco routers can bridge any protocol which is not routed on > a given interface, so, I think CRB should be possible between v4/v6 > as you describe, although I have not tested it. So now we're requiring every student to purchase a Cisco router (not a $50 Linksys box) to put in front of their one or two PCs? And we don't even know if that would work? Keep in mind that most dorms (and hotels) currently allow users to plug in a single PC and start working without any sort of L3 device in the unit at all. Any IPv6 model that requires putting an L3 device in the unit is already making things more expensive, possibly to the point of making the transition not financially viable, and there doesn't appear to be any way around that if we require a /48 per user or per room. Even a /64 per user or per room significantly raises the administrative costs for both v4 and v6, but at least that's technically feasible today. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From L.Howard at stanleyassociates.com Mon May 16 13:38:17 2005 From: L.Howard at stanleyassociates.com (Howard, W. Lee) Date: Mon, 16 May 2005 13:38:17 -0400 Subject: [ppml] IPv6>>32 Message-ID: > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Stephen Sprunk > Sent: Monday, May 16, 2005 11:38 AM > To: Owen DeLong; Larry J. Blunk; Michael.Dillon at radianz.com > Cc: ppml at arin.net > Subject: Re: [ppml] IPv6>>32 > > > "6.5.4.1 Assignment address space size > Assignments are to be made in accordance with the existing > guidelines (RFC3177,RIRs-on-48), which are summarized here as: > - /48 in the general case, except for very large subscribers > - /64 when it is known that one and only one subnet is needed > by design > - /128 when it is absolutely known that one and only one > device is connecting." > > This appears to prevent ISPs (i.e. universities) from > assigning anything longer than a /48 to customers (i.e. > students) in most cases unless they do not qualify as "end sites". Sounds to me like it's a design question. Is dorm connectivity designed to support multiple subnets per room? If not (as I tend to think) each port gets a /64. I would expect dorms with multiple occupants to have multiple ports, regardless of whether the switch is in the room or somewehre else, but if the university prefers to install a switch with VLANs then a /48 is required. > AFAICT, each student at a university qualifies as an "end > site". Therefore, unless the specific criteria for a /64 or > /128 are met for each student, which is certainly not > guaranteed nor feasible to determine, each student must be > assigned a /48. > > Interestingly, the above could also be (mis)read to say that > businesses need to assign a /48 to each employee. Depends on the use of the network. As the Manager of Network Engineering for Stanley Associates, I would not assign a /48 to each employee, because I don't want them installing alien crud on my network. YMMV > > > Not to mention what actually deploying such a setup would > do to the > > > existing IPv4 addressing plan. What are the odds ARIN > would approve > > > Merit (today, ignoring their legacy /8) requesting an IPv4 /12 so > > > they could give every student (38,000 cited elsewhere in > the thread) > > > a /29? That's what we'd be forcing them to do if they had to > > > provide a subnet per student. > > > > This is where IPv4 != IPv6 and there does start to be some > reason to > > consider that addresses are no longer scarce. In IPv4, it > is hard to > > imagine assigning a static address to every person on the > planet. In > > IPv6, it is hard to imagine the population being sufficient > that each > > person could not have a /64. > > I'm working with the assumption that v6 and v4 will be > deployed with the same topology, which has yet to be > disproven. If we give each student an IPv6 /64 (or /48), > then we'd need to give them an IPv4 /29 or shorter too. I don't understand this assumption. When I explain IPv6 to people around me, I compare IPv6 /64 to IPv4 /32+NAT, but without the (arguably evil) complexities of NAT. Clearly the topologies can't be the same, because there's not enough space in IPv4 to make it so. More likely, IMHO, is for organizations using IPv4 with 10/8 NAT to use native IPv6 addresses under dual stacks. > > > Perhaps some vendor will come out with a whiz-bang device that > > > allows a shared IPv4 subnet while routing IPv6 natively, > but I'm not > > > aware of anything like that on the market or even proposed for > > > development. > > > > I guess I'm not understanding the situation you are > describing here. > > There are several ways to do 6:4 gateways which would allow > you to run > > v4 and v6 on the same segment. > > We're talking about native v4 and native v6, not some > gatewayed or NATed service. I didn't think native IPv4 was specified; removing that part of the conversation doesn't change the context any. > > There is nothing which requires you to match your v4 > topology to your v6 topology. > > I'm not aware of any off-the-shelf consumer-grade solution > which allows them to be different. There's no reason to match them, so there's no solution for doing so. At the organization's (LIR's/ISP's/university's) edge they'll run native IPv6 and NATed IPv4; you wouldn't expect that to be consumer grade. Even if they're running native IPv4, you can extend the depth of the network with IPv6 without offering the same depth with IPv4 (i.e., you can have subnets all the way down to /64). Even if you want matching topologies, IPv4 allows VLSM, so you'd only assign a /29 (or /30) where it's needed, not necessarily to every student. > Keep in mind that most dorms (and hotels) currently allow > users to plug in a single PC and start working without any > sort of L3 device in the unit at all. Any IPv6 model that > requires putting an L3 device in the unit is already making > things more expensive, possibly to the point of making the > transition not financially viable, and there doesn't appear > to be any way around that if we require a /48 per user or per > room. Even a /64 per user or per room significantly raises > the administrative costs for both v4 and v6, but at least > that's technically feasible today. There's still a layer 3 device, it's the NIC. Maybe you meant L3 router; it exists, it's just not in the dorm room. Routing a /64 or /48 to a specific port does not mean there has to be a router at the other end; it's perfectly reasonable for a single host to be on that subnet. Lee From owen at delong.com Mon May 16 14:05:27 2005 From: owen at delong.com (Owen DeLong) Date: Mon, 16 May 2005 11:05:27 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: References: Message-ID: <0C6E5E07A4E46DB973418A91@imac-en0.delong.sj.ca.us> > I think people are confused about whether dorm rooms are > like private apartments or like hotel rooms. If they are > like private apartments, then they should get a /48 but if > they are like hotel rooms, then a /64 should be able to > service a whole floor if not more. I suspect that the majority > of dorms are more like student hotels than they are like > private apartments. In any case, I don't think it is fruitful > to try to count the number of subnets or hosts in any particular > room. > Well... Most dorm rooms are occupied for one or more semesters, and, are rarely available for single night or week-long rentals. As such, I'd say they bear much more similarity to an apartment than a hotel room. How is it that you think they are more like hotels? My understanding of the difference between a hotel and an apartment is the normal length of stay. Sure, there are residential hotels, but, I think that for this discussion, those are essentially a form of apartment as well. Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From owen at delong.com Mon May 16 14:08:55 2005 From: owen at delong.com (Owen DeLong) Date: Mon, 16 May 2005 11:08:55 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: References: Message-ID: > = Person who has requested that I remove attributions when I quote him >> = Owen DeLong (me) >> Your enterprise does not have to be particularly large for renumbering > to >> be a complex task. Imagine even a small company with a couple of > hundred >> customers who connect over VPN tunnels. Now, imagine renumbering all of >> the virtual addresses used on the client side and all of the tunnel end >> point addresses for that series of customer connections in order to >> switch providers. > > I'm afraid I can't imagine this since I do not have the IPv6 > operational experience to extrapolate. I do know enough to realize > thatr my IPv4 experience does not apply. Does anyone here know of > a resource that explains how IPv6 renumbering is accomplished in > a real-world operational context? I know that there are many > medium-sized networks who have gone through IPv6 renumbering recently > as they transitioned off the 6-bone tunnels and onto native > IPv6 networks. Why is it that you dream that IPv6 renumbering will affect tunnel endpoints for IPSEC and ACL entries differently from the way that IPv4 renumbering effects them? Admittedly, I have very minimal IPv6 opex with this, but, what little I have suggests that there is more similarity than difference. In general, due to security considerations, these addresses are statically assigned and manually propogated to the configuration files of multiple devices (and often to multiple configuration files per device) across organizational unit and even organizational boundaries. Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From memsvcs at arin.net Mon May 16 14:24:04 2005 From: memsvcs at arin.net (Member Services) Date: Mon, 16 May 2005 14:24:04 -0400 Subject: [ppml] Policy Proposal 2005-1: Provider Independent IPv6 Assignments for End-sites - to be revised Message-ID: <4288E544.9000507@arin.net> The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), has reviewed policy proposal 2005-1: Provider Independent IPv6 Assignments for End-sites and has determined that while there is no community consensus in favor of the proposal there is consensus that the proposal should be revised and discussed further. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting in April, 2005. Minutes of the Public Policy Meeting can be found at http://www.arin.net/meetings/minutes/ARIN_XV/index.html. The results of the AC meeting were reported by the Chair of the AC at the member meeting. This report can be found at http://www.arin.net/meetings/minutes/ARIN_XV/mem_minutes.html#anchor_4. The AC will work with the author of the proposal to make the community suggested revisions and return the proposal to the ppml for further discussion. The current policy proposal text is provided below and is also available at http://www.arin.net/policy/proposals/2005_1.html. The ARIN Internet Resource Policy Evaluation Process can be found at http://www.arin.net/policy/irpep.html. Regards, Member Services American Registry for Internet Numbers (ARIN) ##### Policy Proposal 2005-1: Provider Independent IPv6 Assignments for End-sites Policy statement To be added to NRPM Section 6, IPv6, a new sub-section: 6.11 Assignments to End-sites with Autonomous System Numbers Any end-site which meets the current criteria for assignment of an autonomous system number (ASN) shall also qualify for one IPv6 prefix assignment of the minimum size justified under the ARIN guidelines for assignment by an LIR. If the organization grows to require more space, it will not be entitled to an additional block, but rather may obtain a new, replacement block of sufficient size to meet its needs in exchange for making the commitment to return its existing block within 24 months, so that it may be reassigned. Policy Rationale (if provided) There is a legitimate and growing need for provider independent addressing for end-site organizations. While there were and are technical reasons for limiting this in the IPv4 world, they need to be solved in the IPv6 world, or, we will not see widespread adoption of IPv6. This policy does not promote extreme growth in the routing table, as it would provide support for fewer than 70,000 IPv6 prefixes if every organization that currently has an ASN were to get an assignment, grow, and, be in the 24 month renumbering period. Realistically, it is unreasonable to think that this policy would contribute even 10,000 routes to the IPv6 table in the near term future. This policy provides for reasonable IPv6 provider independent assignments without creating a land-grab, explosive routing table growth, or a IPv6 swamp. All such assignments under this policy shall be subject to the same renewal criteria as IPv4 end-user assignments with a fee structure to be set by ARIN in the usual and customary way. Concerns were expressed about being able to reclaim this space and about a land rush. Should an IPv6 land rush occur under this policy (an ASN land rush would be required first), the ARIN BOT has emergency authority to suspend this or any other policy in the interests of the internet with appropriate review at the next public policy meeting. As to reclamation, it is quite clear in the Registration Services Agreement: 4. Conditions of service ... (d) Changes to Services. Applicant acknowledges and agrees that ARIN fulfills a critical role in the continued evolution of the Internet and, accordingly, ARIN may, in its sole and absolute discretion, change, modify, suspend, or make improvements to any aspect of the Services, temporarily or permanently, at any time without specific notice to Applicant, and ARIN will not be liable for doing so. ARIN will have the right from time to time to change the amount of the fees or institute new fees relating to the Services, as set forth in Section 6, but such changes to fees will only take effect upon the renewal of the Services. Also, according to subsequent sections of the agreement, ARIN may simply choose not to renew the agreement with 30 days notice to the applicant. Either of these actions makes reclamation quite possible. From memsvcs at arin.net Mon May 16 14:26:11 2005 From: memsvcs at arin.net (Member Services) Date: Mon, 16 May 2005 14:26:11 -0400 Subject: [ppml] Policy Proposal 2005-3: Lame Delegations - last call Message-ID: <4288E5C3.50604@arin.net> The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), has reviewed policy proposal 2005-3: Lame Delegations and has determined that there is community consensus in favor of the proposal to move it to last call. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting in April, 2005. Minutes of the Public Policy Meeting can be found at http://www.arin.net/meetings/minutes/ARIN_XV/index.html. The results of the AC meeting were reported by the Chair of the AC at the member meeting. This report can be found at http://www.arin.net/meetings/minutes/ARIN_XV/mem_minutes.html#anchor_4. The policy proposal text is provided below and is also available at http://www.arin.net/policy/proposals/2005_3.html. Comments are encouraged. All comments should be provided to ppml at arin.net. This last call will expire at 12:00 Noon, Eastern Time, June 1, 2005. The ARIN Internet Resource Policy Evaluation Process can be found at http://www.arin.net/policy/irpep.html. Regards, Member Services American Registry for Internet Numbers (ARIN) ##### Policy Proposal 2005-3: Lame Delegations Policy statement This policy proposal replaces section 7.2 of the ARIN NRPM. ARIN will actively identify lame DNS name server(s) for reverse address delegations associated with address blocks allocated, assigned or administered by ARIN. Upon identification of a lame delegation, ARIN shall attempt to contact the POC for that resource and resolve the issue. If, following due diligence, ARIN is unable to resolve the lame delegation, ARIN will update the WHOIS database records resulting in the removal of lame servers. Policy Rationale (if provided) The policy as stated could not be implemented without placing an undue burden on ARIN staff resources. The procedures mandated in the policy require a shifting of registration service resources from such activities as IP Analyst support for on-going registration actions as well as the telephonic and email help desks. Removing the procedures from the policy allows the Director of Registration Services the flexibility of meeting all registration services needs and managing the identification, notification, and removal of lame delegations. Timetable for implementation: 90 days after adoption From memsvcs at arin.net Mon May 16 14:25:36 2005 From: memsvcs at arin.net (Member Services) Date: Mon, 16 May 2005 14:25:36 -0400 Subject: [ppml] Policy Proposal 2005-2: Directory Services Overhaul - to be revised Message-ID: <4288E5A0.6070505@arin.net> The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), has reviewed policy proposal 2005-2: Directory Services Overhaul and has determined that while there is no community consensus in favor of the proposal there is consensus that the proposal should be revised and discussed further. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting in April, 2005. Minutes of the Public Policy Meeting can be found at http://www.arin.net/meetings/minutes/ARIN_XV/index.html. The results of the AC meeting were reported by the Chair of the AC at the member meeting. This report can be found at http://www.arin.net/meetings/minutes/ARIN_XV/mem_minutes.html#anchor_4. The AC will work with the author of the proposal to make the community suggested revisions and return the proposal to the ppml for further discussion. The current policy proposal text is provided below and is also available at http://www.arin.net/policy/proposals/2005_2.html. The ARIN Internet Resource Policy Evaluation Process can be found at http://www.arin.net/policy/irpep.html. Regards, Member Services American Registry for Internet Numbers (ARIN) ##### Policy Proposal 2005-2: Directory Services Overhaul Policy statement Replace all of section three with the following rewrite. 3. Directory Services 3.1 ARIN Directory Services Databases The ARIN Public Information Database (APID) is a collection of information created and collected by ARIN during the due course of business which the ARIN membership has deemed public information and decided to publish. The ARIN Confidential Information Database (ACID) is a collection of information created and collected by ARIN during the due course of business which the ARIN membership has deemed is confidential information that should be kept under a strict privacy policy. 3.2 Directory Information Made Public ARIN shall publish verified contact information and the resource(s) allocated (including identification for that allocation, like date of allocation or other information identified by ARIN) in the APID in the following cases: * All resources delegated by ARIN. * If allowed by the parent delegation, and requested by the contact listed with the parent, a subdelegation of a resource. ARIN shall insure all contact information in the APID is verified from time to time and is correct to the best of ARIN's ability. ARIN staff shall maintain verification criteria and post it on the ARIN web site. 3.2.1 Non-Responsive Contacts If ARIN is unable to verify contact information via the normal verification procedure ARIN shall attempt to notify the parent of the resource to have the information updated. If there is no parent, or if the data is not corrected in a reasonable amount of time the resource shall be SUSPENDED. Once the resource is suspended ARIN shall make one more request of all contacts listed with the resource and the parent resource (if available), and if no response is received in a reasonable amount of time the resource shall be reclaimed. Third parties may report the inability to make contact with a party via information in the APID. In this case ARIN shall attempt the contact verification procedure for that contact immediately. If a response is received, ARIN should document that a problem occurred, and the response from the resource holder. Offenders who fail to respond to third parties more than 4 times per month for three months may have their resources reclaimed at the discretion of ARIN staff. If a third party submits reports of the inability to make contact that are subsequently disproven, ARIN may choose to ignore reports from specific companies, people, e-mail addresses, or any other classification means as appropriate. The ARIN staff shall publish the time thresholds and procedural details to implement this policy on the ARIN web site. If a resource is reclaimed under no circumstances shall the holder of that resource be entitled to a refund of any fees. 3.3 Data Distribution 3.3.1 Methods of Access ARIN shall publish the APID in the following methods using industry standard practices: * Via the WHOIS protocol. * Via a query form accessible via the HTTP protocol. * Via FTP to users who complete the bulk data form. * Via CDROM to users who complete the bulk data form. * Via the RWHOIS protocol. 3.3.1.1 Outside Sources ARIN may refer a query to a outside source (for instance via RWHOIS or HTTP redirect). Outside sources must: 1. Have an AUP deemed compatible with the ARIN AUP by ARIN staff. 2. Meet the requirements in section 3.3.3. 3. Support the applications in section 3.3.1. 4. Prohibit the applications in section 3.3.2. 3.3.2 Acceptable Usage Policy All data provided shall be subject to an AUP. The AUP shall be written by ARIN staff and legal and posted on the ARIN website. ARIN may require a signed copy of the AUP before providing bulk data. 3.3.3 Requirements for Internet Accessible Services For any method of access which is provided in real time via the Internet the following requirements must be met: * The distributed information service must be operational 24 hours a day, 7 days a week to both the general public and ARIN staff. The service is allowed reasonable downtime for server maintenance according to generally accepted community standards. * The distributed information service must allow public access to reassignment information. The service may restrict the number of queries allowed per time interval from a host or subnet to defend against DDOS attacks, remote mirroring attempts, and other nefarious acts. * The distributed information service must return current information. 3.4 Distribution of the ARIN Public Information Database 3.4.1 Supported Uses ARIN shall make the APID available for the following uses (supported uses): 1. ARIN's use in implementing ARIN policies and other business. 2. Community verification, allowing members of the community to confirm the proper users of the various resources ARIN controls. 3. Statistic gathering by ARIN and third parties on resource utilization. 4. As a contact database to facilitate communication with the person or entity responsible for a particular resource. 3.4.2 Prohibited Uses ARIN prohibits the use of the APID for the following uses: 1. Sending any unsolicited commercial correspondence advertising a product or service to any address (physical or electronic) listed in the APID. 2. Using data in the APID to facilitate violating any state, federal, or local law. 3.4.3 Other Uses ARIN shall allow all non-prohibited uses of the APID, however unless those uses are listed as a supported use the data set may be changed in such a way as to render them ineffective, or they may be blocked outright as deemed necessary by ARIN staff. Users of applications not listed who are concerned that they are supported should introduce a proposal to add their application to the supported list. 3.5 Distribution of the ARIN Confidential Information Database ARIN Staff shall use industry standard procedures to prevent the distribution of any data in the ARIN Confidential Information Database. 3.6 Implementation Details ARIN Staff shall document all implementation specific details for directory services in a single document available on the web site. The document must contain, but is not limited to: * Database field definitions. * Update procedures. * Templates. * Points of contact. * Copies of the AUP. * Verification procedures. 3.7 [Routing Registry] Copy Verbatim from the existing 3.4. Section 4.2.3.7.4: Replace with: All reassignment information for current blocks shall be submitted to ARIN prior to submitting a request for a new allocation. Section 4.2.3.7.6: Strike. Policy Rationale (if provided) Various proposals affecting directory services have come and gone in the last 5 years leaving the policy affecting directory services fragemented. Also during that time deployments and laws have changed. Several large DSL and cable providers now offer subnets to residential customers that may require them to be registered with ARIN. Several laws have been passed that may restrict the personal information that can be published. This proposal attempts to provide a unified policy that is easier to understand, and is updated to deal with these new issues. Timetable for implementation: 6-18 months, depending on staff impact. From memsvcs at arin.net Mon May 16 14:26:43 2005 From: memsvcs at arin.net (Member Services) Date: Mon, 16 May 2005 14:26:43 -0400 Subject: [ppml] Policy Proposal 2004-8: Allocation of IPv6 Address Space by the Internet Assigned Numbers Authority (IANA) Policy to Regional Internet Registries - last call Message-ID: <4288E5E3.5080300@arin.net> The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), has reviewed policy proposal 2004-8: Allocation of IPv6 Address Space by the Internet Assigned Numbers Authority (IANA) Policy to Regional Internet Registries and has determined that there is community consensus in favor of the proposal to move it to last call. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting in April, 2005. Minutes of the Public Policy Meeting can be found at http://www.arin.net/meetings/minutes/ARIN_XV/index.html. The results of the AC meeting were reported by the Chair of the AC at the member meeting. This report can be found at http://www.arin.net/meetings/minutes/ARIN_XV/mem_minutes.html#anchor_4. The policy proposal text is provided below and is also available at http://www.arin.net/policy/proposals/2004_8.html. Comments are encouraged. All comments should be provided to ppml at arin.net. This last call will expire at 12:00 Noon, Eastern Time, June 1, 2005. The ARIN Internet Resource Policy Evaluation Process can be found at http://www.arin.net/policy/irpep.html. Regards, Member Services American Registry for Internet Numbers (ARIN) ##### Policy Proposal 2004-8: Allocation of IPv6 Address Space by the Internet Assigned Numbers Authority (IANA) Policy to Regional Internet Registries Policy statement This document describes the policy governing the allocation of IPv6 address space from the IANA to the Regional Internet Registries (RIRs). This document does not stipulate performance requirements in the provision of services by IANA to an RIR in accordance with this policy. Such requirements will be specified by appropriate agreements between ICANN and the NRO. 1. Allocation Principles * The unit of IPv6 allocation (and therefore the minimum IPv6 allocation) from IANA to an RIR is a /12 * The IANA will allocate sufficient IPv6 address space to the RIRs to support their registration needs for at least an 18 month period. * The IANA will allow for the RIRs to apply their own respective chosen allocation and reservation strategies in order to ensure the efficiency and efficacy of their work. 2. Initial Allocations * On inception of this policy, each current RIR with less than a /12 unallocated address space, shall receive an IPv6 allocation from IANA * Any new RIR shall, on recognition by ICANN receive an IPv6 allocation from the IANA 3. Additional Allocations A RIR is eligible to receive additional IPv6 address space from the IANA when either of the following conditions are met. * The RIR's AVAILABLE SPACE of IPv6 addresses is less than 50% of a /12. * The RIR's AVAILABLE SPACE of IPv6 addresses is less than its established NECESSARY SPACE for the following 9 months. In either case, IANA shall make a single IPv6 allocation, sufficient to satisfy the established NECESSARY SPACE of the RIR for an 18 month period. 3.1 Calculation of AVAILABLE SPACE The AVAILABLE SPACE of IPv6 addresses of a RIR shall be determined as follows: AVAILABLE SPACE = CURRENTLY FREE ADDRESSES + RESERVATIONS EXPIRING DURING THE FOLLOWING 3 MONTHS - FRAGMENTED SPACE FRAGMENTED SPACE is determined as the total amount of available blocks smaller than the RIR's minimum allocation size within the RIR's currently available stock. 3.2 Calculation of NECESSARY SPACE If the applying Regional Internet Registry does not establish any special needs for the period concerned, NECESSARY SPACE shall be determined as follows: NECESSARY SPACE = AVERAGE NUMBER OF ADDRESSES ALLOCATED MONTHLY DURING THE PAST 6 MONTHS * LENGTH OF PERIOD IN MONTHS If the applying RIR anticipates that due to certain special needs the rate of allocation for the period concerned will be different from the previous 6 months, it may determine its NECESSARY SPACE as follows: Calculate NECESSARY SPACE as its total needs for that period according to its projection and based on the special facts that justify these needs. Submit a clear and detailed justification of the above mentioned projection (Item A). If the justification is based on the allocation tendency prepared by the Regional Internet Registry, data explaining said tendency must be enclosed. If the justification is based on the application of one or more of the Regional Internet Registry's new allocation policies, an impact analysis of the new policy/policies must be enclosed. If the justification is based on external factors such as new infrastructure, new services within the region, technological advances or legal issues, the corresponding analysis must be enclosed together with references to information sources that will allow verification of the data. If IANA does not have elements that clearly question the Regional Internet Registry's projection, the special needs projected for the following 18 months, indicated in Item A above, shall be considered valid. 4. Announcement of IANA Allocations The IANA, the NRO, and the RIRs will make announcements and update their respective web sites regarding an allocation made by the IANA to an RIR. ICANN and the NRO will establish administrative procedures to manage this process. From memsvcs at arin.net Mon May 16 14:27:05 2005 From: memsvcs at arin.net (Member Services) Date: Mon, 16 May 2005 14:27:05 -0400 Subject: [ppml] Policy Proposal 2004-3: Global Addresses for Private Network Inter-Connectivity - last call Message-ID: <4288E5F9.1080400@arin.net> The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), has reviewed policy proposal 2004-3: Global Addresses for Private Network Inter-Connectivity and has determined that there is community consensus in favor of the proposal to move it to last call. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting in April, 2005. Minutes of the Public Policy Meeting can be found at http://www.arin.net/meetings/minutes/ARIN_XV/index.html. The results of the AC meeting were reported by the Chair of the AC at the member meeting. This report can be found at http://www.arin.net/meetings/minutes/ARIN_XV/mem_minutes.html#anchor_4. The policy proposal text is provided below and is also available at http://www.arin.net/policy/proposals/2004_3.html. Comments are encouraged. All comments should be provided to ppml at arin.net. This last call will expire at 12:00 Noon, Eastern Time, June 1, 2005. The ARIN Internet Resource Policy Evaluation Process can be found at http://www.arin.net/policy/irpep.html. Regards, Member Services American Registry for Internet Numbers (ARIN) ##### Policy Proposal 2004-3: Global Addresses for Private Network Inter-Connectivity Policy statement End-users not currently connected to an ISP and/or not planning to be connected to the Internet are encouraged to use private IP address numbers reserved for non-connected networks (see RFC 1918). When private, non-connected networks require interconnectivity and the private IP address numbers are ineffective, globally unique addresses may be requested and used to provide this interconnectivity. This text supersedes section 4.3.5 Non-connected Networks. Policy Rationale (if provided) In order to provide clarification for current ARIN practice concerning the use of Global Addresses for private network interconnectivity, the change above to the ARIN Number Resource Policy Manual is proposed. Current wording of Section 4.3.5 Non-connected Networks: End-users not currently connected to an ISP and/or plan not to be connected to the Internet are encouraged to use private IP numbers reserved for non-connected networks (see RFC 1918 ). From owen at delong.com Mon May 16 14:29:45 2005 From: owen at delong.com (Owen DeLong) Date: Mon, 16 May 2005 11:29:45 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: <003f01c55a26$8050c040$6601a8c0@stephen> References: <003f01c55a26$8050c040$6601a8c0@stephen> Message-ID: <691C6E2CE51D449A3CEAB760@imac-en0.delong.sj.ca.us> > I would classify dorms as "student hotels" and assign a /64 per floor (or > per building even) unless a student specifically asked for their own /64 > or /48. Unfortunately, I'm not sure that's permitted under existing > policy if the student is paying the university -- or if a guest is paying > a hotel -- for Internet access. > Regardless of whether they are apartments or hotels, this is, of course permitted under current policy. The policy doesn't say how you can or cannot structure your networks. What it does say is that if a subnet is justified, the minimum subnet size is /64. If multiple subnets are required and the OU in question wishes to receive a self-managed allocation visible in whois, then the minimum allocation unit is /48. If an org is to become an LIR, the minimum allocation unit is /32 and there are requirements to justify that. So, on simple request, one can receive a /48 or /64 or /128 depending on what one requests. Above that, one must meet the requirements of an LIR or provide sufficient justification to your LIR for additional /48s. > Extending this to the absurd, if the university (or other ISP) were > offering service via 802.11, would we still require them to hand out a > /48 per user/customer? Are there even any consumer-grade devices that > work in such a scenario? > No ISP is required to hand out a /48 per customer. They are, however, required to give a /48 to each customer that expresses need/desire for one. I don't think this is absurd. > The reality is that today and for the conceivable future a single human > will only have a few to a few dozen devices needing a handful of addresses > each -- and that's allowing for a lot of growth from today's norm of one > IP per user -- which is well within the realm of simple, existing, cheap > L2 technology. > Actually, that's not entirely true. I know several humans that use more IP space than that even in existing IPv4. I also know of lots of scenarios where a lot more space than that is concealed behind NAT because of IPv4 constraints. The reality is that more and more of our interdevice communication is starting to use IP for transport. The additional reality is that more and more interdevice communication is starting to be done (think ala universal remotes, or the ability of the coffee maker, oven, microwave, etc. to synchronize the completion of breakfast, etc.). The reality is that we know these things are coming. They're not speculative fruit cakes or fruit. Also, we've already seen the growing use of RFIDs and the desire of many users to have them use IP. The requirement for a /48 for every customer is absurd, but, it's also inaccurate. A customer may receive a /128, a /64, or a /48 at said customer's discretion. That's a good thing. We can argue about where those boundaries should be, but, giving each customer the ability to get a host, a network, or a collection of networks at their discretion is a good idea. > We can throw around ideas of fruit crates (or even fruits) that need their > own subnets for internal communication, but until such devices actually > appear (and IMHO, it will not be within my lifetime), we shouldn't be > wasting 80 bits of addressing on each human when only one to five bits > will be used in the vast majority of cases. > Fruit crates with IP based RFID tags do already exist. >> If the person in charge of said device says that >> a /64 is required, then I'm happy to give a /64. > > Agreed. But policy shouldn't _force_ people to deal with having their own > /64 or /48 when they're happy getting one or more /128s out of a shared > pool. > It doesn't. Nothing in the policy says you can't make that user a /128 within your /48 or allocate a /48 for such static assignments. >> Simple rules of thumb can be applied to resolve these kinds of >> issues. > > ARIN doesn't operate on simple rules of thumb; it operates on policies. > Right... The policy just specifies what you have to allocate on customer request. It doesn't say you have to allocate that to customers that don't request it. Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From jdhoule at att.com Mon May 16 14:32:06 2005 From: jdhoule at att.com (Houle, Joseph D (Joe), CMO) Date: Mon, 16 May 2005 13:32:06 -0500 Subject: [ppml] IPv6>>32 Message-ID: Folks: I'm starting to get lost here. One doesn't "get" an address block unless one is willing to "manage addresses", right. Whether "get" means "assign" or "allocate". Dorm rooms don't get blocks, ports don't get blocks, students don't get blocks, single-offices don't get blocks, employees don't get blocks. (OK, so maybe there are exceptions to the "offices" and "employees" in a research or non-production environment). In general the IP infrastructure provider: corporate IT, university telecom, etc "gets" the block for the subnet, then end hosts "learn/picks" an address out of that block (likely via some form of auto discovery/DHCP). Joe Houle -----Original Message----- From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On Behalf Of Stephen Sprunk Sent: Monday, May 16, 2005 11:38 AM To: Owen DeLong; Larry J. Blunk; Michael.Dillon at radianz.com Cc: ppml at arin.net Subject: Re: [ppml] IPv6>>32 Thus spake "Owen DeLong" > --On Friday, May 13, 2005 3:05 PM -0500 Stephen Sprunk wrote: > > I agree that's what the letter of the policy states, but I can't imagine > > that's what was intended. > > > > Assigning a /48 to each student violates simple common sense. > > Yes, I know there's enough /48s for every human on the planet, > > but we're going to have serious problems down the road if we start > > allocating a /48 for each host, which is the vast majority of cases > > in a dorm today and for the conceivable future. Burning a /64 per > > host is bad enough, but I could be convinced to accept that if Merit > > said they liked that idea (I personally doubt they do). > > I think by default, each student should get a /64. If, however, the > student expresses need for multiple subnets, then, I think a /48 is > exactly what was intended under the policy. "6.5.4.1 Assignment address space size Assignments are to be made in accordance with the existing guidelines (RFC3177,RIRs-on-48), which are summarized here as: - /48 in the general case, except for very large subscribers - /64 when it is known that one and only one subnet is needed by design - /128 when it is absolutely known that one and only one device is connecting." This appears to prevent ISPs (i.e. universities) from assigning anything longer than a /48 to customers (i.e. students) in most cases unless they do not qualify as "end sites". "6.2.9. End site An end site is defined as an end user (subscriber) who has a business relationship with a service provider that involves: 1. that service provider assigning address space to the end user 2. that service provider providing transit service for the end user to other sites 3. that service provider carrying the end user's traffic. 4. that service provider advertising an aggregate prefix route that contains the end user's assignment" AFAICT, each student at a university qualifies as an "end site". Therefore, unless the specific criteria for a /64 or /128 are met for each student, which is certainly not guaranteed nor feasible to determine, each student must be assigned a /48. Interestingly, the above could also be (mis)read to say that businesses need to assign a /48 to each employee. > I'm not making any value judgments at this point as to whether the > policy is good or bad, but, that is my understanding of its intent. I think you may be right about its intent, but if we are correct then that intent was not correctly written into the policy. > > Not to mention what actually deploying such a setup would do to > > the existing IPv4 addressing plan. What are the odds ARIN would > > approve Merit (today, ignoring their legacy /8) requesting an IPv4 > > /12 so they could give every student (38,000 cited elsewhere in > > the thread) a /29? That's what we'd be forcing them to do if they > > had to provide a subnet per student. > > This is where IPv4 != IPv6 and there does start to be some reason to > consider that addresses are no longer scarce. In IPv4, it is hard to > imagine assigning a static address to every person on the planet. > In IPv6, it is hard to imagine the population being sufficient that > each person could not have a /64. I'm working with the assumption that v6 and v4 will be deployed with the same topology, which has yet to be disproven. If we give each student an IPv6 /64 (or /48), then we'd need to give them an IPv4 /29 or shorter too. > > Perhaps some vendor will come out with a whiz-bang device that > > allows a shared IPv4 subnet while routing IPv6 natively, but I'm not > > aware of anything like that on the market or even proposed for > > development. > > I guess I'm not understanding the situation you are describing here. > There are several ways to do 6:4 gateways which would allow you to > run v4 and v6 on the same segment. We're talking about native v4 and native v6, not some gatewayed or NATed service. > There is nothing which requires you to match your v4 topology to > your v6 topology. I'm not aware of any off-the-shelf consumer-grade solution which allows them to be different. > Most Cisco routers can bridge any protocol which is not routed on > a given interface, so, I think CRB should be possible between v4/v6 > as you describe, although I have not tested it. So now we're requiring every student to purchase a Cisco router (not a $50 Linksys box) to put in front of their one or two PCs? And we don't even know if that would work? Keep in mind that most dorms (and hotels) currently allow users to plug in a single PC and start working without any sort of L3 device in the unit at all. Any IPv6 model that requires putting an L3 device in the unit is already making things more expensive, possibly to the point of making the transition not financially viable, and there doesn't appear to be any way around that if we require a /48 per user or per room. Even a /64 per user or per room significantly raises the administrative costs for both v4 and v6, but at least that's technically feasible today. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From owen at delong.com Mon May 16 14:43:25 2005 From: owen at delong.com (Owen DeLong) Date: Mon, 16 May 2005 11:43:25 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: <009801c55a30$546c7050$6601a8c0@stephen> References: <1115994295.17083.14.camel@ablate.merit.edu> <95480F3F9E0865059C929E46@imac-en0.delong.sj.ca.us> <026e01c557f8$39f28c30$6601a8c0@stephen> <8A3E9A9D47115A1D6796AB55@imac-en0.delong.sj.ca.us> <009801c55a30$546c7050$6601a8c0@stephen> Message-ID: <049DCEBE23FBA21E9B7111A1@imac-en0.delong.sj.ca.us> --On Monday, May 16, 2005 10:38 AM -0500 Stephen Sprunk wrote: > Thus spake "Owen DeLong" >> --On Friday, May 13, 2005 3:05 PM -0500 Stephen Sprunk > wrote: >> > I agree that's what the letter of the policy states, but I can't >> > imagine that's what was intended. >> > >> > Assigning a /48 to each student violates simple common sense. >> > Yes, I know there's enough /48s for every human on the planet, >> > but we're going to have serious problems down the road if we start >> > allocating a /48 for each host, which is the vast majority of cases >> > in a dorm today and for the conceivable future. Burning a /64 per >> > host is bad enough, but I could be convinced to accept that if Merit >> > said they liked that idea (I personally doubt they do). >> >> I think by default, each student should get a /64. If, however, the >> student expresses need for multiple subnets, then, I think a /48 is >> exactly what was intended under the policy. > > "6.5.4.1 Assignment address space size > Assignments are to be made in accordance with the existing guidelines > (RFC3177,RIRs-on-48), which are summarized here as: > - /48 in the general case, except for very large subscribers > - /64 when it is known that one and only one subnet is needed by design > - /128 when it is absolutely known that one and only one device is > connecting." > > This appears to prevent ISPs (i.e. universities) from assigning anything > longer than a /48 to customers (i.e. students) in most cases unless they > do not qualify as "end sites". > No... In most cases, it can be assumed that a student needs only one subnet by design. If the student invalidates said assumption, then, a /48 is required. > "6.2.9. End site > An end site is defined as an end user (subscriber) who has a business > relationship with a service provider that involves: > 1. that service provider assigning address space to the end user > 2. that service provider providing transit service for the end user to > other sites > 3. that service provider carrying the end user's traffic. > 4. that service provider advertising an aggregate prefix route that > contains the end user's assignment" > > AFAICT, each student at a university qualifies as an "end site". > Therefore, unless the specific criteria for a /64 or /128 are met for > each student, which is certainly not guaranteed nor feasible to > determine, each student must be assigned a /48. > Right. However, the ISP can easily make presumptive policies that state "It is assumed unless the student requests otherwise that the student's use of campus internet in their dorm room does not require more than a single subnet. As such, the default allocation to students is a /64. If more is needed, the student should submit a written request and a /48 will be assigned." I believe such a policy would meet the test and that ARIN would accept allocations done through such a policy as compliant. > Interestingly, the above could also be (mis)read to say that businesses > need to assign a /48 to each employee. > If the business is acting as an LIR for the employee rather than treating the employee as part of said businesses' end site, then, yes, that would be true. However, the same option above would apply. >> I'm not making any value judgments at this point as to whether the >> policy is good or bad, but, that is my understanding of its intent. > > I think you may be right about its intent, but if we are correct then that > intent was not correctly written into the policy. > I'm not convinced of that. I think that some wordsmithing or clarification could improve readability and clarity, but, I'm not convinced that the policy does not say what it means. Remember, also, that the policy you are criticizing states that it is strictly a summary of the RFC. A detailed read of the RFC (which I don't have time to do right now, and, don't remember clearly enough to quote from memory), I believe, reveals the intent pretty clearly as I stated it. > I'm working with the assumption that v6 and v4 will be deployed with the > same topology, which has yet to be disproven. If we give each student an > IPv6 /64 (or /48), then we'd need to give them an IPv4 /29 or shorter too. > Why? Why do we necessarily have to give the student any IPv4 space at all? I have yet to understand this particular assumption or where it came from. Ignoring your feeling that this assumption should be disproven, I just can't find a basis for the assumption to be made in the first place. >> I guess I'm not understanding the situation you are describing here. >> There are several ways to do 6:4 gateways which would allow you to >> run v4 and v6 on the same segment. > > We're talking about native v4 and native v6, not some gatewayed or NATed > service. > Again, I'm not sure why someone who is receiving end-site V6 allocation necessarily needs a V4 assignment. I understand you think that is desirable, but, I don't understand why you think it is necessary. >> There is nothing which requires you to match your v4 topology to >> your v6 topology. > > I'm not aware of any off-the-shelf consumer-grade solution which allows > them to be different. > I'm not aware of any need for such a device. At the consumer-grade end of things, I think it makes much more sense for the consumer to be either V4 or V6. At some point, one must pick a minimum unit of change. The single consumer (household, dorm-room, etc.) seems like a pretty small unit to me. >> Most Cisco routers can bridge any protocol which is not routed on >> a given interface, so, I think CRB should be possible between v4/v6 >> as you describe, although I have not tested it. > > So now we're requiring every student to purchase a Cisco router (not a $50 > Linksys box) to put in front of their one or two PCs? And we don't even > know if that would work? > No. We're requiring every student to be either V6 or V4. If they're V4, then, they may be limited to a single public address. If they're V6, they get additional abilities to get public addresses. > Keep in mind that most dorms (and hotels) currently allow users to plug > in a single PC and start working without any sort of L3 device in the > unit at all. Any IPv6 model that requires putting an L3 device in the > unit is already making things more expensive, possibly to the point of > making the transition not financially viable, and there doesn't appear to > be any way around that if we require a /48 per user or per room. Even a > /64 per user or per room significantly raises the administrative costs > for both v4 and v6, but at least that's technically feasible today. > There's nothing that says a campus couldn't support this under existing policy. Imagine it this way: Default: A single device is plugged into the campus network and receives a /128 address from the dorm's /64 segment. Student requests single network: Student is assigned a static /64 which student configures into L3 device local segment. Student connects remote segment to wall. Remote receives dynamic /128 address from dorm's /64 segment and advertises students /64 to upstream default gateway. Student requests multiple networks: Student is assigned a static /48. Otherwise, same as previous example. Student can build any appropriate topology within dorm room beyond that. Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From owen at delong.com Mon May 16 14:50:44 2005 From: owen at delong.com (Owen DeLong) Date: Mon, 16 May 2005 11:50:44 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: References: Message-ID: --On Monday, May 16, 2005 1:32 PM -0500 "Houle, Joseph D (Joe), CMO" wrote: > Folks: > I'm starting to get lost here. One doesn't "get" an address block > unless one is willing to "manage addresses", right. Whether "get" > means "assign" or "allocate". Dorm rooms don't get blocks, ports don't > get blocks, students don't get blocks, single-offices don't get blocks, > employees don't get blocks. (OK, so maybe there are exceptions to the > "offices" and "employees" in a research or non-production environment). > In general the IP infrastructure provider: corporate IT, university > telecom, etc "gets" the block for the subnet, then end hosts > "learn/picks" an address out of that block (likely via some form of auto > discovery/DHCP). > Your first 3 sentences are correct. After that, you embed unfounded assumptions which don't work. Dorm rooms don't get blocks, ports don't get blocks. Students, single offices, employees, etc. may or may not get blocks depending on network management policy, recipient request, recipient need, etc. YMMV. Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From iggy at merit.edu Mon May 16 16:10:13 2005 From: iggy at merit.edu (Glenn Wiltse) Date: Mon, 16 May 2005 16:10:13 -0400 (EDT) Subject: [ppml] Universities (was IPv6>>32) In-Reply-To: <42861349.2020203@hotnic.net> References: <1115994295.17083.14.camel@ablate.merit.edu> <95480F3F9E0865059C929E46@imac-en0.delong.sj.ca.us> <026e01c557f8$39f28c30$6601a8c0@stephen> <8A3E9A9D47115A1D6796AB55@imac-en0.delong.sj.ca.us> <42861349.2020203@hotnic.net> Message-ID: FYI... (not nessarly directed specificly toward the posting included bellow...) It seems our counterparts in Asia beleive it's perfectly legitimate to assign a /48 to a residence... Even in some cases where there may initialy be only one computer connected. If we were to mimic their policys, it would seem assigning a /48 per doorm room, or to the people residing in a doorm room would be perfectly acceptable. -=-=-=- APNIC IPv6 Guidelines Section 8) 8.1 Assignment size. RFC 3177 and the "IPv6 address allocation and assignment policy" state that a single ends site should ussualy be assigned a /48. Residential subscribers can receive a /48 when connecting through on-demand or always-on connections such as ADSL or CATV. If an end site is expected to grow, an LIR may assign a /48 to an end site where a /64 or /128 may initially seem more appropriate (for example an end site with a single computer) An LIR must submit a second opion request to APNIC if it plans to assign more then a /48 to an end site (see Section 8.2) =-=-=-=-(sorry if there are any typos in that, I typed it by hand)-=-=-=-= On Sat, 14 May 2005, Kevin Loch wrote: > Owen DeLong wrote: > > I think by default, each student should get a /64. If, however, the student > > expresses need for multiple subnets, then, I think a /48 is exactly what was > > intended under the policy. > > It's not about wether a student needs 65k subnets, it's about wether > they need 2. Assigning 2 /64's to a student would violate current > policy where assigning a /48 would not. > > Interestingly, while they could assign a /48 per _student_, they could > not assign a /48 per _room_. "Assignments" are made to legal entities > and show up in swip/rwhois. They only get one /48 per campus for their > own infrastructure, so a /64 per room could be done but a /48 could not. > > If a University was sure they would not be assigning /48's to anyone > (faculty, on/off campus students, vendors, commercial/industrial > partners) then a /48 per campus would be all they need. If they plan on > assigning /48's then they should get a /32. > > I expect most universities will eventually ask for and receive their > own /32. For that reason, reigonal networks that serve them should > probably not get a large allocation (> /32) based on total downstream > university customers. > > - Kevin > > > !DSPAM:42866b3a990237791197! > > From david.kessens at nokia.com Mon May 16 17:46:19 2005 From: david.kessens at nokia.com (David Kessens) Date: Mon, 16 May 2005 14:46:19 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: <003f01c55a26$8050c040$6601a8c0@stephen> References: <003f01c55a26$8050c040$6601a8c0@stephen> Message-ID: <20050516214618.GB6770@nokia.com> Stephen, On Mon, May 16, 2005 at 09:48:37AM -0500, Stephen Sprunk wrote: > > I would classify dorms as "student hotels" and assign a /64 per floor (or > per building even) unless a student specifically asked for their own /64 or > /48. Unfortunately, I'm not sure that's permitted under existing policy if > the student is paying the university -- or if a guest is paying a hotel -- > for Internet access. > > Extending this to the absurd, if the university (or other ISP) were offering > service via 802.11, would we still require them to hand out a /48 per > user/customer? Are there even any consumer-grade devices that work in such > a scenario? I think you read too much in the policy. The policy is very liberal and intented to be that way. You can assign a /48 if there is a chance that the end-user/your customer will need more than one /64. In fact, it is recommended to assign a /48 in that case. However, it is not required in any way. Nothing will stop you from being more conservative than the recommendations in your assignments as an LIR. Whether that is smart to do is a completely different issue. What the policy describes is the maximum amount of address space that you can assign to an end-user/customer without getting in trouble with the RIR. You really cannot get into trouble with the RIR by being more conservative than the policy. Obviously, your customer might not agree with you being more conservative than what is allowed and choose a different provider if the end-user/customer has a need for more address space. As for my personal opinion, yes I do think that the policy is perhaps a bit too generous, especially in the case for more commodity style Internet services like DSL/cable/dorm rooms/WLAN deployments. Therefore, I think it would make sense to add a category for this kind users which would broadly fit into what most people describe as "SOHO" users. David Kessens --- From owen at delong.com Mon May 16 18:04:48 2005 From: owen at delong.com (Owen DeLong) Date: Mon, 16 May 2005 15:04:48 -0700 Subject: [ppml] Universities (was IPv6>>32) In-Reply-To: References: <1115994295.17083.14.camel@ablate.merit.edu> <95480F3F9E0865059C929E46@imac-en0.delong.sj.ca.us> <026e01c557f8$39f28c30$6601a8c0@stephen> <8A3E9A9D47115A1D6796AB55@imac-en0.delong.sj.ca.us> <42861349.2020203@hotnic.net> Message-ID: <0875EA3C015285FBB49A0F90@imac-en0.delong.sj.ca.us> --On Monday, May 16, 2005 4:10 PM -0400 Glenn Wiltse wrote: > FYI... (not nessarly directed specificly toward the posting included > bellow...) > > It seems our counterparts in Asia beleive it's perfectly legitimate > to assign a /48 to a residence... Even in some cases where there may > initialy be only one computer connected. > That is in line with the RFC and current allocation policy. > If we were to mimic their policys, it would seem assigning a /48 per > doorm room, or to the people residing in a doorm room would be perfectly > acceptable. > Right... That's what I would expect. Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From owen at delong.com Mon May 16 18:08:45 2005 From: owen at delong.com (Owen DeLong) Date: Mon, 16 May 2005 15:08:45 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: <20050516214618.GB6770@nokia.com> References: <003f01c55a26$8050c040$6601a8c0@stephen> <20050516214618.GB6770@nokia.com> Message-ID: <4860FFD1B02ACBE82A079E33@imac-en0.delong.sj.ca.us> > As for my personal opinion, yes I do think that the policy is perhaps > a bit too generous, especially in the case for more commodity style > Internet services like DSL/cable/dorm rooms/WLAN deployments. > Therefore, I think it would make sense to add a category for this kind > users which would broadly fit into what most people describe as "SOHO" > users. So... Just out of curiosity, what would your suggested policy for this class of users be? I tend to think /64 and possibly a new /56 category, but, certainly I would have trouble thinking that relegating anyone who might match the SOHO category to being unable to qualify for multiple subnets is a bad idea. I think the gains of octet boundaries are worth the tradeoffs (the dns hacks to handle VLSM IN-ADDR delegation really are hacky). Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From stephen at sprunk.org Mon May 16 18:18:42 2005 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 16 May 2005 17:18:42 -0500 Subject: [ppml] IPv6>>32 References: <003f01c55a26$8050c040$6601a8c0@stephen> <20050516214618.GB6770@nokia.com> Message-ID: <03a801c55a67$1d631050$6601a8c0@stephen> Thus spake "David Kessens" > On Mon, May 16, 2005 at 09:48:37AM -0500, Stephen Sprunk wrote: > > I would classify dorms as "student hotels" and assign a /64 per > > floor (or per building even) unless a student specifically asked for > > their own /64 or /48. Unfortunately, I'm not sure that's permitted > > under existing policy if the student is paying the university -- or if > > a guest is paying a hotel -- for Internet access. > > ... > > I think you read too much in the policy. The policy is very liberal > and intented to be that way. You can assign a /48 if there is a chance > that the end-user/your customer will need more than one /64. In fact, > it is recommended to assign a /48 in that case. However, it is not > required in any way. > > Nothing will stop you from being more conservative than the > recommendations in your assignments as an LIR. 6.5.4.1 says "Assignments are to be made in accordance with the existing guidelines (RFC3177,RIRs-on-48)" and then quotes RFC 3177's own summary. Digging a into RFC 3177 itself, we find in section 3 "In particular, we recommend ... Home network subscribers, connecting through on-demand or always-on connections should receive a /48." Don't be distracted by RFC 3177 using the terms "should" and "recommend"; ARIN policy imports those suggestions and turns them into rules by omitting similarly liberal wording, even if that wasn't the intent -- and I think it was. I don't see any leeway for an LIR to assign less than a /48 to "home network subscribers", which dorm residents certainly are. > Whether that is smart to do is a completely different issue. What > the policy describes is the maximum amount of address space > that you can assign to an end-user/customer without getting in > trouble with the RIR. You really cannot get into trouble with the > RIR by being more conservative than the policy. I think the intent was to establish not only a maximum assignment, but also a minimum assignment. > Obviously, your customer might not agree with you being more > conservative than what is allowed and choose a different provider > if the end-user/customer has a need for more address space. > > As for my personal opinion, yes I do think that the policy is > perhaps a bit too generous, especially in the case for more > commodity style Internet services like DSL/cable/dorm rooms/ > WLAN deployments. Therefore, I think it would make sense to > add a category for this kind users which would broadly fit into > what most people describe as "SOHO" users. We'd have to drop the reference to RFC 3177 in that case, since it explicitly calls out SOHO users as deserving a /48 even if they don't ask for (or need) one. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From lea.roberts at stanford.edu Mon May 16 18:49:22 2005 From: lea.roberts at stanford.edu (Lea Roberts) Date: Mon, 16 May 2005 15:49:22 -0700 (PDT) Subject: [ppml] IPv6>>32 In-Reply-To: <4860FFD1B02ACBE82A079E33@imac-en0.delong.sj.ca.us> Message-ID: hi Owen - On Mon, 16 May 2005, Owen DeLong wrote: > > As for my personal opinion, yes I do think that the policy is perhaps > > a bit too generous, especially in the case for more commodity style > > Internet services like DSL/cable/dorm rooms/WLAN deployments. > > Therefore, I think it would make sense to add a category for this kind > > users which would broadly fit into what most people describe as "SOHO" > > users. > > So... Just out of curiosity, what would your suggested policy for this > class of users be? I tend to think /64 and possibly a new /56 category, > but, certainly I would have trouble thinking that relegating anyone > who might match the SOHO category to being unable to qualify for multiple > subnets is a bad idea. I think the gains of octet boundaries are worth > the tradeoffs (the dns hacks to handle VLSM IN-ADDR delegation really > are hacky). At the recent ARIN and RIPE meetings, the possiblity of adding a /56 assignment bucket was being openly discussed! FWIW, reverse for IPv6 is done on hex digits (aka nibbles), so /60 and /52 assignments would not suffer from IN-ADDR "hacky-ness" (see rfc3596 :-) From kloch at hotnic.net Mon May 16 19:14:52 2005 From: kloch at hotnic.net (Kevin Loch) Date: Mon, 16 May 2005 19:14:52 -0400 Subject: [ppml] IPv6>>32 In-Reply-To: <03a801c55a67$1d631050$6601a8c0@stephen> References: <003f01c55a26$8050c040$6601a8c0@stephen> <20050516214618.GB6770@nokia.com> <03a801c55a67$1d631050$6601a8c0@stephen> Message-ID: <4289296C.6050905@hotnic.net> Stephen Sprunk wrote: > Don't be distracted by RFC 3177 using the terms "should" and "recommend"; > ARIN policy imports those suggestions and turns them into rules by omitting > similarly liberal wording, even if that wasn't the intent -- and I think it > was. I don't see any leeway for an LIR to assign less than a /48 to "home > network subscribers", which dorm residents certainly are. An ISP does not have to assign space to every customer. The customer may use ISP infrastructure space out of the /48 for each POP. In a university, this may be a /64 for each building. On a cable system it might be a /64 for each cable segment. There are no rules or guidelines for how an ISP may use the /48 for each POP. Only when Assignment event occurrs does the customer become an "end site" and the assignment guidelines kick in. - Kevin From david.kessens at nokia.com Mon May 16 19:38:58 2005 From: david.kessens at nokia.com (David Kessens) Date: Mon, 16 May 2005 16:38:58 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: <4860FFD1B02ACBE82A079E33@imac-en0.delong.sj.ca.us> References: <003f01c55a26$8050c040$6601a8c0@stephen> <20050516214618.GB6770@nokia.com> <4860FFD1B02ACBE82A079E33@imac-en0.delong.sj.ca.us> Message-ID: <20050516233858.GA4902@nokia.com> Owen, On Mon, May 16, 2005 at 03:08:45PM -0700, Owen DeLong wrote: > > As for my personal opinion, yes I do think that the policy is perhaps > > a bit too generous, especially in the case for more commodity style > > Internet services like DSL/cable/dorm rooms/WLAN deployments. > > Therefore, I think it would make sense to add a category for this kind > > users which would broadly fit into what most people describe as "SOHO" > > users. > > So... Just out of curiosity, what would your suggested policy for this > class of users be? I tend to think /64 and possibly a new /56 category, > but, certainly I would have trouble thinking that relegating anyone > who might match the SOHO category to being unable to qualify for multiple > subnets is a bad idea. I think the gains of octet boundaries are worth > the tradeoffs (the dns hacks to handle VLSM IN-ADDR delegation really > are hacky). I think it is more useful to agree (or disagree :-)) whether creation of such a category makes sense at all before diving into the exact details on what the limits should be. a /56 for SOHO users that need more than one subnet would work for me and a /64 otherwise. However, I think an answer on whether creation of such a category is useful is way more important (for the moment). David Kessens --- From RLindsey at coinfotech.com Mon May 16 19:59:32 2005 From: RLindsey at coinfotech.com (Randy Lindsey) Date: Mon, 16 May 2005 17:59:32 -0600 Subject: [ppml] IPv6>>32 Message-ID: <8D528F7C177242458A7AB5C5C13B675F1CC51A@oak.cit.office> > > > As for my personal opinion, yes I do think that the policy is > > > perhaps a bit too generous, especially in the case for more > > > commodity style Internet services like DSL/cable/dorm rooms/WLAN deployments. > > > Therefore, I think it would make sense to add a category for this > > > kind users which would broadly fit into what most people describe as "SOHO" > > > users. > > > > So... Just out of curiosity, what would your suggested policy for this > > class of users be? I tend to think /64 and possibly a new /56 > > category, but, certainly I would have trouble thinking that relegating > > anyone who might match the SOHO category to being unable to qualify > > for multiple subnets is a bad idea. I think the gains of octet > > boundaries are worth the tradeoffs (the dns hacks to handle VLSM > > IN-ADDR delegation really are hacky). > > I think it is more useful to agree (or disagree :-)) whether creation of > such a category makes sense at all before diving into the exact details on > what the limits should be. a /56 for SOHO users that need more than one > subnet would work for me and a /64 otherwise. However, I think an answer > on whether creation of such a category is useful is way more important > (for the moment). Categories should not be based on who you are (home, SOHO, enterprise) but rather on what you do with the address space and your justification for it. I don't think it is rocket science to set some criteria around number of hosts, number of subnets etc. similar to the current justification. A very simple (and no doubt inadequate) set of categories would be: - 1 host (are we really talking about global routing entries at this level?) - 1 subnet (um, what size?) - 2-5 subnets - 6-20 subnets Etc. Randy Lindsey Colorado Information Technologies, Inc. http://www.coinfotech.com From david.kessens at nokia.com Mon May 16 20:04:43 2005 From: david.kessens at nokia.com (David Kessens) Date: Mon, 16 May 2005 17:04:43 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: <03a801c55a67$1d631050$6601a8c0@stephen> References: <003f01c55a26$8050c040$6601a8c0@stephen> <20050516214618.GB6770@nokia.com> <03a801c55a67$1d631050$6601a8c0@stephen> Message-ID: <20050517000442.GB4902@nokia.com> Stephen, On Mon, May 16, 2005 at 05:18:42PM -0500, Stephen Sprunk wrote: > > 6.5.4.1 says "Assignments are to be made in accordance with the existing > guidelines (RFC3177,RIRs-on-48)" and then quotes RFC 3177's own summary. > Digging a into RFC 3177 itself, we find in section 3 "In particular, we > recommend ... Home network subscribers, connecting through on-demand or > always-on connections should receive a /48." > > Don't be distracted by RFC 3177 using the terms "should" and "recommend"; > ARIN policy imports those suggestions and turns them into rules by omitting > similarly liberal wording, even if that wasn't the intent -- and I think it > was. I don't see any leeway for an LIR to assign less than a /48 to "home > network subscribers", which dorm residents certainly are. You are really looking for a problem that doesn't exist. ARIN is in the business of good stewardship of IP address space. I would like to hear from the first person who got in trouble with a RIR because you assigned less address space then requested by a customer, even if you didn't follow ARIN's recommendation to assign more. > I think the intent was to establish not only a maximum assignment, but also > a minimum assignment. No the intent was (among others) to change the mindset such that users would have plenty of address space when they want to run an ipv6 based network so that address considerations would not force them to deploy technologies that limit the usefulness of their Internet connections. The minimums/recommendations in the rfc help to support this intent but they are not the intent itself. > > Obviously, your customer might not agree with you being more > > conservative than what is allowed and choose a different provider > > if the end-user/customer has a need for more address space. > > > > As for my personal opinion, yes I do think that the policy is > > perhaps a bit too generous, especially in the case for more > > commodity style Internet services like DSL/cable/dorm rooms/ > > WLAN deployments. Therefore, I think it would make sense to > > add a category for this kind users which would broadly fit into > > what most people describe as "SOHO" users. > > We'd have to drop the reference to RFC 3177 in that case, since it > explicitly calls out SOHO users as deserving a /48 even if they don't ask > for (or need) one. Or write a new rfc that updates 3177. David Kessens --- From david.kessens at nokia.com Mon May 16 20:24:58 2005 From: david.kessens at nokia.com (David Kessens) Date: Mon, 16 May 2005 17:24:58 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: <8D528F7C177242458A7AB5C5C13B675F1CC51A@oak.cit.office> References: <8D528F7C177242458A7AB5C5C13B675F1CC51A@oak.cit.office> Message-ID: <20050517002457.GC4902@nokia.com> Randy, On Mon, May 16, 2005 at 05:59:32PM -0600, Randy Lindsey wrote: > > Categories should not be based on who you are (home, SOHO, enterprise) > but rather on what you do with the address space and your justification > for it. I don't think it is rocket science to set some criteria around > number of hosts, number of subnets etc. similar to the current > justification. > > A very simple (and no doubt inadequate) set of categories would be: > - 1 host (are we really talking about global routing entries at this > level?) > - 1 subnet (um, what size?) > - 2-5 subnets > - 6-20 subnets You are obviously right with this one. I used the term "SOHO" in the context of a groups of users with simular needs that are currently getting rather large assignments of address space for which it is questionable that they ever need that many subnets. The recommendation would probably read something more along the lines like: If there is any chance that the user needs more than one subnet, assignment of a "SomethingSmallerThan/48" is recommended. The user is allowed to get a /48 if explicitly requested and a "SomethingSmallerThan/48" is not enough as stated by the user. David Kessens --- From owen at delong.com Tue May 17 04:09:22 2005 From: owen at delong.com (Owen DeLong) Date: Tue, 17 May 2005 01:09:22 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: <03a801c55a67$1d631050$6601a8c0@stephen> References: <003f01c55a26$8050c040$6601a8c0@stephen> <20050516214618.GB6770@nokia.com> <03a801c55a67$1d631050$6601a8c0@stephen> Message-ID: <2147483647.1116292161@[172.17.1.152]> > Don't be distracted by RFC 3177 using the terms "should" and "recommend"; > ARIN policy imports those suggestions and turns them into rules by > omitting similarly liberal wording, even if that wasn't the intent -- and > I think it was. I don't see any leeway for an LIR to assign less than a > /48 to "home network subscribers", which dorm residents certainly are. > I don't see the ARIN policy the same way you do. I think it is equally liberal to RFC 3177 and states that the summary is just that, a summary. I don't see anything in the ARIN policy that says you MUST issue a /48 to such a subscriber, only that you can. > I think the intent was to establish not only a maximum assignment, but > also a minimum assignment. > I don't read it that way. I read it as the intent was to establish maximum assignments and a limited number of assignment sizes (e.g. /128, /64, /48, and <=/32). Whether those are the right limited sizes or not, I am not sure. I think we will need more opex before we can determine that. However, I do think there is benefit to having a limited number of IDR assignment sizes and having all of those sizes line up on octet boundaries. > We'd have to drop the reference to RFC 3177 in that case, since it > explicitly calls out SOHO users as deserving a /48 even if they don't ask > for (or need) one. > I think that would be a mistake. I think that the number of SOHO users that need more than one /64 will increase, and, I think there was some good reasoning behind RFC 3177. I wouldn't mind seeing it possible to allocate /56 to such users, and, I wouldn't mind seeing what is currently a /64 become a /32 (with a correspoonding 32 bit shift on everything else), but, there seems to be substantial resistance to that for reasons I don't fully understand. As such, I don't really see a need for more than some fine tuning to the current policy in terms of sizing. Owen -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From Michael.Dillon at radianz.com Tue May 17 05:52:36 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Tue, 17 May 2005 10:52:36 +0100 Subject: [ppml] IPv6>>32 In-Reply-To: <009801c55a30$546c7050$6601a8c0@stephen> Message-ID: > AFAICT, each student at a university qualifies as an "end site". Therefore, > unless the specific criteria for a /64 or /128 are met for each student, > which is certainly not guaranteed nor feasible to determine, each student > must be assigned a /48. You have provided absolutely no evidence to show the feasibility or lack of feasability of determining whether or not the student fits the criteria for a /64 or /128. In fact, the student is a customer of the university. We might reasonably expect that the university and the customer are capable of communicating with each other. Therefore we might reasonably assume that it is feasible for the university to ASK their customers whether or not more than one subnet is required. In fact, it is common practice for universities to ask students about their preferences in music, study practices, free time activities, etc. They do this to determine the compatibility of students sharing a room or sharing a floor. In any case, a dorm is really a student hotel. When you go to a hotel, you get what the hotel offers, nothing more. If the hotel only offers 10-baseT ethernet port in your room with a DHCP server and Squid web proxy, then that is what you get. Same rule applies to student hotels in universities. Each university will decide on their offer and that is that. No doubt some more liberal universities will offer their students up to 16 static IPv6 addresses for their room but other will offer only one and expect that the power users will tunnel their networks out to a gateway service. Whether that is best practice or not is irrelevant. Students in dorms tend to not worry about whether or not something is best practice, after all they are learning and one effective way to learn is to experiment with all the wrong techniques and learn firsthand why they are bad. In any case, I see nothing here that indicates there is a problem with IPv6 policy. > I'm not aware of any off-the-shelf consumer-grade solution which allows them > to be different. I'm not aware of any "consumer class" students who want to use IPv6 in the dorm. This is still an early adopter protocol. Consumer grade products don't appear until later in the game. However, policies should not consider whether or not consumer grade products exist. Policies define the right and fair way to allocated addresses. If that requires a consumer grade product to deploy effectively, then people need to talk to hardware vendors about the problem, not to ARIN. --Michael Dillon From Michael.Dillon at radianz.com Tue May 17 06:01:03 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Tue, 17 May 2005 11:01:03 +0100 Subject: [ppml] IPv6>>32 In-Reply-To: <0C6E5E07A4E46DB973418A91@imac-en0.delong.sj.ca.us> Message-ID: > How is it that you think they are more like hotels? Services. Dorm rooms usually include hotel-like services. When I was in uni, a maid came once a week to clean everybody's room. We had cooked meals provided 3 times a day if we wanted it. There was no lease for the room. It was bundled with the educational services. If you leave university you have to move out of the dorm as well. However, a university dorm is not a hotel and it is not an apartment. I think we all agree that in our society the university is a special type of entity. It is not a business or a government department or non-profit organization. It is a university, period. --Michael Dillon From jwkckid1 at ix.netcom.com Tue May 17 07:55:45 2005 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Tue, 17 May 2005 04:55:45 -0700 Subject: [ppml] IPv6>>32 References: <003f01c55a26$8050c040$6601a8c0@stephen> <20050516214618.GB6770@nokia.com> <03a801c55a67$1d631050$6601a8c0@stephen> <2147483647.1116292161@[172.17.1.152]> Message-ID: <4289DBBF.745810D6@ix.netcom.com> Owen and all, Owen DeLong wrote: > > Don't be distracted by RFC 3177 using the terms "should" and "recommend"; > > ARIN policy imports those suggestions and turns them into rules by > > omitting similarly liberal wording, even if that wasn't the intent -- and > > I think it was. I don't see any leeway for an LIR to assign less than a > > /48 to "home network subscribers", which dorm residents certainly are. > > > I don't see the ARIN policy the same way you do. I think it is equally > liberal to RFC 3177 and states that the summary is just that, a summary. > I don't see anything in the ARIN policy that says you MUST issue a /48 > to such a subscriber, only that you can. Agreed. And it would seem reasonable that definitive but still flexible set of criteria should be delineated as to when such an allocation when requested is justified and should be issued. > > > > I think the intent was to establish not only a maximum assignment, but > > also a minimum assignment. > > > I don't read it that way. I read it as the intent was to establish maximum > assignments and a limited number of assignment sizes (e.g. /128, /64, /48, > and <=/32). Whether those are the right limited sizes or not, I am not > sure. > I think we will need more opex before we can determine that. However, I do > think there is benefit to having a limited number of IDR assignment sizes > and having all of those sizes line up on octet boundaries. Also agreed here. Still under what criterion such IDR assignments are made needs to be delineated... > > > > We'd have to drop the reference to RFC 3177 in that case, since it > > explicitly calls out SOHO users as deserving a /48 even if they don't ask > > for (or need) one. > > > I think that would be a mistake. I think that the number of SOHO users that > need more than one /64 will increase, and, I think there was some good > reasoning behind RFC 3177. I wouldn't mind seeing it possible to allocate > /56 > to such users, and, I wouldn't mind seeing what is currently a /64 become a > /32 (with a correspoonding 32 bit shift on everything else), but, there > seems to be substantial resistance to that for reasons I don't fully > understand. > As such, I don't really see a need for more than some fine tuning to the > current policy in terms of sizing. Also agreed here. But it should be exacting as to form/language so that the policy is easily understood and far less subject to interpretation. > > > Owen > > -- > If this message was not signed with gpg key 0FE2AA3D, it's probably > a forgery. > > ------------------------------------------------------------------------ > > Part 1.2 Type: application/pgp-signature > Encoding: 7bit Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 From bicknell at ufp.org Tue May 17 10:39:59 2005 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 17 May 2005 10:39:59 -0400 Subject: [ppml] IPv6>>32 In-Reply-To: References: <0C6E5E07A4E46DB973418A91@imac-en0.delong.sj.ca.us> Message-ID: <20050517143959.GB62201@ussenterprise.ufp.org> In a message written on Tue, May 17, 2005 at 11:01:03AM +0100, Michael.Dillon at radianz.com wrote: > Dorm rooms usually include hotel-like services. When I was > in uni, a maid came once a week to clean everybody's room. > We had cooked meals provided 3 times a day if we wanted it. > There was no lease for the room. It was bundled with the > educational services. If you leave university you have to > move out of the dorm as well. Wow. I wish I went to your university. I got no maid. Meals were a separate contract, offered in separate buildings. The room was paid for separately from tuition, and was paid for a semester at a time. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From owen at delong.com Tue May 17 14:24:24 2005 From: owen at delong.com (Owen DeLong) Date: Tue, 17 May 2005 11:24:24 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: References: Message-ID: <21E07770FFEBCF5377ADC172@imac-en0.delong.sj.ca.us> > Dorm rooms usually include hotel-like services. When I was > in uni, a maid came once a week to clean everybody's room. Interesting. That is different from any of the dorms with which I am familiar. It has been some time, so, policies may have changed, but, last I looked, this was not the case at any of the University of California, Stanford, University of British Columbia (Vancouver), or California State Universities. > We had cooked meals provided 3 times a day if we wanted it. This was not bundled with the dorm at any of the universities I am familiar with. > There was no lease for the room. It was bundled with the > educational services. If you leave university you have to > move out of the dorm as well. While university attendance was a prerequisite/condition of the dorm lease, university attendence did not necessarily include a dorm room. There was an additional rental fee and agreement. Finally, some dorms I knew included a telephone line (attached to university PBX), while others required students to purchase their own phone service, if desired. Others still did not have telecommunications wiring to each dorm room and provided pay phones in common areas of the building. > > However, a university dorm is not a hotel and it is not > an apartment. I think we all agree that in our society the > university is a special type of entity. It is not a business > or a government department or non-profit organization. It is > a university, period. > So... I think there are university dorms that resemble hotels as you describe, but, also, ones that come much closer to apartments and still others that are different altogether. However, there are universities that are businesses. There are also universities which are government departments, and, finally, there are some which are run as NPOs. Stanford University and Menlo College are examples of universities that are run as businesses. The University of California and California State Universities are examples of government agencies (if you don't believe this, look at their legal entitlements in the California Constitution some time and the legal powers granted to the Board of Regents). I don't have a convenient example of an NPO university off the top of my head, but, I know some exist. In any case, if they offer IP services to their students in dorm rooms, then, they have the choice under current policy of whether the end site is the campus, collection of dorm buildings, dorm building, dorm room, or, each student. Depending on where they place the end site, each student may qualify for a /128, multiple /128s, a /64, or a /48. I think it would be hard to justify each student being an LIR. Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From owen at delong.com Tue May 17 14:29:32 2005 From: owen at delong.com (Owen DeLong) Date: Tue, 17 May 2005 11:29:32 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: <4289DBBF.745810D6@ix.netcom.com> References: <003f01c55a26$8050c040$6601a8c0@stephen> <20050516214618.GB6770@nokia.com> <03a801c55a67$1d631050$6601a8c0@stephen> <2147483647.1116292161@[172.17.1.152]> <4289DBBF.745810D6@ix.netcom.com> Message-ID: <9EEFF13C150F5863008401A9@imac-en0.delong.sj.ca.us> >> I don't see the ARIN policy the same way you do. I think it is equally >> liberal to RFC 3177 and states that the summary is just that, a summary. >> I don't see anything in the ARIN policy that says you MUST issue a /48 >> to such a subscriber, only that you can. > > Agreed. And it would seem reasonable that definitive but still > flexible set of criteria should be delineated as to when such > an allocation when requested is justified and should be issued. > I'm not so sure about that. I think that leaving such delineation up to the ISP is quite prudent at this time. Personally, if we were to codify it, then, the only codification I would accept would be "on customer request". > Also agreed here. Still under what criterion such IDR assignments > are made needs to be delineated... > Why? Why not leave it up to the ISP and customer to determine within the constraints of the existing policy? [snip] increasing SOHO users needing multiple space / possibly /56 > Also agreed here. But it should be exacting as to form/language > so that the policy is easily understood and far less subject to > interpretation. > I think that clarification would be good, but, I don't think that codification is necessary or desirable at this time. I think leaving the decision between the LIR and end-site is the prudent approach right now. I agree that we should do what we can to make sure LIRs and end-sites know what the policy allows and what options are available within the policy. Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From lea.roberts at stanford.edu Tue May 17 14:45:54 2005 From: lea.roberts at stanford.edu (Lea Roberts) Date: Tue, 17 May 2005 11:45:54 -0700 (PDT) Subject: [ppml] IPv6>>32 In-Reply-To: <21E07770FFEBCF5377ADC172@imac-en0.delong.sj.ca.us> Message-ID: On Tue, 17 May 2005, Owen DeLong wrote: > > However, there are universities that are businesses. There are also > universities which are government departments, and, finally, there > are some which are run as NPOs. > > Stanford University and Menlo College are examples of universities that > are run as businesses. if by NPO, you mean Non-Profit Organization, Stanford is one. That's why we had to divest BARRNet when the internet started making money... :-) > > I don't have a convenient example of an NPO university off the top of my > head, but, I know some exist. From owen at delong.com Tue May 17 14:55:14 2005 From: owen at delong.com (Owen DeLong) Date: Tue, 17 May 2005 11:55:14 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: References: Message-ID: --On Tuesday, May 17, 2005 11:45 AM -0700 Lea Roberts wrote: > On Tue, 17 May 2005, Owen DeLong wrote: >> >> However, there are universities that are businesses. There are also >> universities which are government departments, and, finally, there >> are some which are run as NPOs. >> >> Stanford University and Menlo College are examples of universities that >> are run as businesses. > > if by NPO, you mean Non-Profit Organization, Stanford is one. That's why > we had to divest BARRNet when the internet started making money... :-) > OK... I stand corrected. Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From bicknell at ufp.org Tue May 17 15:07:54 2005 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 17 May 2005 15:07:54 -0400 Subject: [ppml] IPv6>>32 In-Reply-To: <20050509151218.GA61248@ussenterprise.ufp.org> References: <20050509151218.GA61248@ussenterprise.ufp.org> Message-ID: <20050517190754.GA89108@ussenterprise.ufp.org> Cable and Wireless just made a presentation at Nanog about their IPv6 deployment. You can find it at: http://www.nanog.org/mtg-0505/steinegger.html Slide 6, entitled "Addressing" has some interesting facts about how they have chosen to deploy IPv6, which includes use of their /21 (11 bits larger than the default /32 allocation). While I think all the numbers are interesting to talk about, two points are particularly interesting with respect to my original post on this thread. I quote: "All links, regardless of interface type, do get /64 assigned to simplify operations, IP admin, DNS and management." "No stateless autoconfig anywhere." So, they are assigning /64's everywhere, yet explicitly not using the one feature the fixed subnet size (currently) enables. So, for something that in IPv4 we can number with a single bit (using a /31 on a point to point link), they are using 64 bits to do the same job. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From jwkckid1 at ix.netcom.com Wed May 18 03:41:02 2005 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Wed, 18 May 2005 00:41:02 -0700 Subject: [ppml] IPv6>>32 References: <21E07770FFEBCF5377ADC172@imac-en0.delong.sj.ca.us> Message-ID: <428AF18C.29080F74@ix.netcom.com> Owen and all, I also do not have the same experiences Michael evidently had, and so far as I can recall, no one else I know of had these same experiences regarding university attendance. Dorm costs/fees were not bundled with tuition at U of T or at SMU where I went to school. The only place/school I can recall that has a similar arrangement that I can attest to would be the Naval Academy and Navel staff and war colleges. And this was only for non-married attendies/cadets. Owen DeLong wrote: > > Dorm rooms usually include hotel-like services. When I was > > in uni, a maid came once a week to clean everybody's room. > > Interesting. That is different from any of the dorms with which > I am familiar. It has been some time, so, policies may have > changed, but, last I looked, this was not the case at any > of the University of California, Stanford, University of > British Columbia (Vancouver), or California State Universities. > > > We had cooked meals provided 3 times a day if we wanted it. > > This was not bundled with the dorm at any of the universities I > am familiar with. > > > There was no lease for the room. It was bundled with the > > educational services. If you leave university you have to > > move out of the dorm as well. > > While university attendance was a prerequisite/condition of the > dorm lease, university attendence did not necessarily include > a dorm room. There was an additional rental fee and agreement. > > Finally, some dorms I knew included a telephone line (attached > to university PBX), while others required students to purchase > their own phone service, if desired. Others still did not > have telecommunications wiring to each dorm room and provided > pay phones in common areas of the building. > > > > > However, a university dorm is not a hotel and it is not > > an apartment. I think we all agree that in our society the > > university is a special type of entity. It is not a business > > or a government department or non-profit organization. It is > > a university, period. > > > So... I think there are university dorms that resemble hotels > as you describe, but, also, ones that come much closer to apartments > and still others that are different altogether. > > However, there are universities that are businesses. There are also > universities which are government departments, and, finally, there > are some which are run as NPOs. > > Stanford University and Menlo College are examples of universities that > are run as businesses. > > The University of California and California State Universities are examples > of government agencies (if you don't believe this, look at their legal > entitlements in the California Constitution some time and the legal powers > granted to the Board of Regents). > > I don't have a convenient example of an NPO university off the top of my > head, but, I know some exist. > > In any case, if they offer IP services to their students in dorm rooms, > then, > they have the choice under current policy of whether the end site is the > campus, collection of dorm buildings, dorm building, dorm room, or, each > student. Depending on where they place the end site, each student may > qualify for a /128, multiple /128s, a /64, or a /48. I think it would > be hard to justify each student being an LIR. > > Owen > > -- > If it wasn't crypto-signed, it probably didn't come from me. > > ------------------------------------------------------------------------ > > Part 1.2 Type: application/pgp-signature > Encoding: 7bit Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 From jwkckid1 at ix.netcom.com Wed May 18 03:58:27 2005 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Wed, 18 May 2005 00:58:27 -0700 Subject: [ppml] IPv6>>32 References: <003f01c55a26$8050c040$6601a8c0@stephen> <20050516214618.GB6770@nokia.com> <03a801c55a67$1d631050$6601a8c0@stephen> <2147483647.1116292161@[172.17.1.152]> <4289DBBF.745810D6@ix.netcom.com> <9EEFF13C150F5863008401A9@imac-en0.delong.sj.ca.us> Message-ID: <428AF59F.FD763A8E@ix.netcom.com> Owen and all, Owen DeLong wrote: > >> I don't see the ARIN policy the same way you do. I think it is equally > >> liberal to RFC 3177 and states that the summary is just that, a summary. > >> I don't see anything in the ARIN policy that says you MUST issue a /48 > >> to such a subscriber, only that you can. > > > > Agreed. And it would seem reasonable that definitive but still > > flexible set of criteria should be delineated as to when such > > an allocation when requested is justified and should be issued. > > > I'm not so sure about that. I think that leaving such delineation > up to the ISP is quite prudent at this time. The problem or problems I see with this approach is that ISP's frequently have significant turnover in management folks as well as are bought out, merge or change ownership status i.e. going private or go public. In such occurrences ISP Policy or knowledge thereof frequently changes and many times dramatically. As such, continuity is lost or interpreted dramatically leaving ISP's actual customers at risk unnecessarily. > Personally, if we were > to codify it, then, the only codification I would accept would be > "on customer request". I would agree this would be ONE way or addressing the issue. But given my above, perhaps not the best or necessary way.. > > > > Also agreed here. Still under what criterion such IDR assignments > > are made needs to be delineated... > > > Why? Why not leave it up to the ISP and customer to deterine within > the constraints of the existing policy? No reason, as long as that policy is sufficiently delineated... > > > [snip] increasing SOHO users needing multiple space / possibly /56 > > > Also agreed here. But it should be exacting as to form/language > > so that the policy is easily understood and far less subject to > > interpretation. > > > I think that clarification would be good, but, I don't think that > codification is necessary or desirable at this time. It's probably not desirable true, but I would say it is or is nearly necessary. > I think leaving > the decision between the LIR and end-site is the prudent approach right > now. Having this decision as far down as possible is my personal preference as well. I am not arguing that. I do however believe a need to have some well defined guidelines and/or parameters contained and codified as part of the policy yet flexible, which is difficult to do at times and as a function of language, is and has been necessary for reasons or continuity and broad understanding. > > > I agree that we should do what we can to make sure LIRs and end-sites > know what the policy allows and what options are available within the > policy. Good. But this *May* not be all that is needed. Recommendations as to provide for what not to do may also be necessary, and I believe is given human nature. > > > Owen > > -- > If it wasn't crypto-signed, it probably didn't come from me. > > ------------------------------------------------------------------------ > > Part 1.2 Type: application/pgp-signature > Encoding: 7bit Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 From owen at delong.com Wed May 18 03:33:05 2005 From: owen at delong.com (Owen DeLong) Date: Wed, 18 May 2005 00:33:05 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: <428AF59F.FD763A8E@ix.netcom.com> References: <003f01c55a26$8050c040$6601a8c0@stephen> <20050516214618.GB6770@nokia.com> <03a801c55a67$1d631050$6601a8c0@stephen> <2147483647.1116292161@[172.17.1.152]> <4289DBBF.745810D6@ix.netcom.com> <9EEFF13C150F5863008401A9@imac-en0.delong.sj.ca.us> <428AF59F.FD763A8E@ix.netcom.com> Message-ID: <2147483647.1116376384@[172.17.1.152]> > The problem or problems I see with this approach is that ISP's > frequently have significant turnover in management folks as well > as are bought out, merge or change ownership status i.e. going > private or go public. In such occurrences ISP Policy or knowledge > thereof frequently changes and many times dramatically. As such, > continuity is lost or interpreted dramatically leaving ISP's actual > customers at risk unnecessarily. > This is a business issue and a customer service issue between the ISPs and their customers. It is not part of address space stewardship, and, is therefore out of scope for ARIN policy. >> Personally, if we were >> to codify it, then, the only codification I would accept would be >> "on customer request". > > I would agree this would be ONE way or addressing the issue. > But given my above, perhaps not the best or necessary way.. > I think it is absolutely necessary. ARIN micromanaging the relationships between customers and ISPs through address policy is a very slippery slope. The issue you raise is not an address policy issue, but, a business relationship issue. >> >> >> > Also agreed here. Still under what criterion such IDR assignments >> > are made needs to be delineated... >> > >> Why? Why not leave it up to the ISP and customer to deterine within >> the constraints of the existing policy? > > No reason, as long as that policy is sufficiently delineated... > I believe it is sufficiently delineated, but, could use some clarification. >> >> >> [snip] increasing SOHO users needing multiple space / possibly /56 >> >> > Also agreed here. But it should be exacting as to form/language >> > so that the policy is easily understood and far less subject to >> > interpretation. >> > >> I think that clarification would be good, but, I don't think that >> codification is necessary or desirable at this time. > > It's probably not desirable true, but I would say it is or is nearly > necessary. > I think it's not only unnecessary, but, potentially harmful. >> I think leaving >> the decision between the LIR and end-site is the prudent approach right >> now. > > Having this decision as far down as possible is my personal preference > as well. I am not arguing that. I do however believe a need to have some > well defined guidelines and/or parameters contained and codified as > part of the policy yet flexible, which is difficult to do at times and > as a function of language, is and has been necessary for reasons > or continuity and broad understanding. > Well... The current policy says exactly what we've described above, and, is being implemented by ARIN staff at this time as we have described above. As such, I can accept that some clarification may be necessary to ensure that a wider audience concurs with this shared understanding, but, I don't see any need to change the meaning of the policy or alter it's current implementation in this particular area. >> >> >> I agree that we should do what we can to make sure LIRs and end-sites >> know what the policy allows and what options are available within the >> policy. > > Good. But this *May* not be all that is needed. Recommendations > as to provide for what not to do may also be necessary, and I believe > is given human nature. > I'm not sure I follow what you mean here. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From jwkckid1 at ix.netcom.com Wed May 18 07:03:01 2005 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Wed, 18 May 2005 04:03:01 -0700 Subject: [ppml] IPv6>>32 References: <003f01c55a26$8050c040$6601a8c0@stephen> <20050516214618.GB6770@nokia.com> <03a801c55a67$1d631050$6601a8c0@stephen> <2147483647.1116292161@[172.17.1.152]> <4289DBBF.745810D6@ix.netcom.com> <9EEFF13C150F5863008401A9@imac-en0.delong.sj.ca.us> <428AF59F.FD763A8E@ix.netcom.com> <2147483647.1116376384@[172.17.1.152]> Message-ID: <428B20E2.5797D8B5@ix.netcom.com> Owen and all, Owen DeLong wrote: > > The problem or problems I see with this approach is that ISP's > > frequently have significant turnover in management folks as well > > as are bought out, merge or change ownership status i.e. going > > private or go public. In such occurrences ISP Policy or knowledge > > thereof frequently changes and many times dramatically. As such, > > continuity is lost or interpreted dramatically leaving ISP's actual > > customers at risk unnecessarily. > > > This is a business issue and a customer service issue between the > ISPs and their customers. It is not part of address space stewardship, > and, is therefore out of scope for ARIN policy. I for one am and have always been very reluctant in regulation and/or policy from the public sector, whatever the source, from driving business decisions. Unfortunately as Address space management and thereby use is directly tied to business operation, it is and seems to me has been clear that some policies governing and/or directing/channeling business decisions from ARIN or any other RIR is not only necessary to a degree, but wise for all stakeholders... > > > >> Personally, if we were > >> to codify it, then, the only codification I would accept would be > >> "on customer request". > > > > I would agree this would be ONE way or addressing the issue. > > But given my above, perhaps not the best or necessary way.. > > > I think it is absolutely necessary. ARIN micromanaging the relationships > between customers and ISPs through address policy is a very slippery > slope. The issue you raise is not an address policy issue, but, a > business relationship issue. > > >> > >> > >> > Also agreed here. Still under what criterion such IDR assignments > >> > are made needs to be delineated... > >> > > >> Why? Why not leave it up to the ISP and customer to deterine within > >> the constraints of the existing policy? > > > > No reason, as long as that policy is sufficiently delineated... > > > I believe it is sufficiently delineated, but, could use some clarification. > > >> > >> > >> [snip] increasing SOHO users needing multiple space / possibly /56 > >> > >> > Also agreed here. But it should be exacting as to form/language > >> > so that the policy is easily understood and far less subject to > >> > interpretation. > >> > > >> I think that clarification would be good, but, I don't think that > >> codification is necessary or desirable at this time. > > > > It's probably not desirable true, but I would say it is or is nearly > > necessary. > > > I think it's not only unnecessary, but, potentially harmful. > > >> I think leaving > >> the decision between the LIR and end-site is the prudent approach right > >> now. > > > > Having this decision as far down as possible is my personal preference > > as well. I am not arguing that. I do however believe a need to have some > > well defined guidelines and/or parameters contained and codified as > > part of the policy yet flexible, which is difficult to do at times and > > as a function of language, is and has been necessary for reasons > > or continuity and broad understanding. > > > Well... The current policy says exactly what we've described above, and, is > being implemented by ARIN staff at this time as we have described above. > As such, I can accept that some clarification may be necessary to ensure > that a wider audience concurs with this shared understanding, but, I don't > see any need to change the meaning of the policy or alter it's current > implementation in this particular area. > > >> > >> > >> I agree that we should do what we can to make sure LIRs and end-sites > >> know what the policy allows and what options are available within the > >> policy. > > > > Good. But this *May* not be all that is needed. Recommendations > > as to provide for what not to do may also be necessary, and I believe > > is given human nature. > > > I'm not sure I follow what you mean here. > > Owen > > ------------------------------------------------------------------------ > > Part 1.2 Type: application/pgp-signature > Encoding: 7bit Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 From L.Howard at stanleyassociates.com Thu May 19 13:58:55 2005 From: L.Howard at stanleyassociates.com (Howard, W. Lee) Date: Thu, 19 May 2005 13:58:55 -0400 Subject: [ppml] IPv6>>32 Message-ID: > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Owen DeLong > Sent: Monday, May 16, 2005 2:51 PM > To: Houle, Joseph D (Joe), CMO; Stephen Sprunk; Larry J. > Blunk; Michael.Dillon at radianz.com > Cc: ppml at arin.net > Subject: RE: [ppml] IPv6>>32 > > Dorm rooms don't get blocks, ports don't get blocks. > Students, single offices, employees, etc. may or may not get > blocks depending on network management policy, recipient > request, recipient need, etc. > > YMMV. MMV. In my experience, people don't get blocks, devices get addresses. Some of those devices may be routers, which may have blocks of addresses for the devices attached to them. So the question of how big a block is appropriate for the room is moot--the right question is how many addresses are required for a routed segment, based on the number of devices connected there. Lee > Owen From lea.roberts at stanford.edu Thu May 19 14:18:46 2005 From: lea.roberts at stanford.edu (Lea Roberts) Date: Thu, 19 May 2005 11:18:46 -0700 (PDT) Subject: [ppml] IPv6>>32 In-Reply-To: Message-ID: On Thu, 19 May 2005, Howard, W. Lee wrote: > > -----Original Message----- > > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > > Behalf Of Owen DeLong > > Sent: Monday, May 16, 2005 2:51 PM > > To: Houle, Joseph D (Joe), CMO; Stephen Sprunk; Larry J. > > Blunk; Michael.Dillon at radianz.com > > Cc: ppml at arin.net > > Subject: RE: [ppml] IPv6>>32 > > > > Dorm rooms don't get blocks, ports don't get blocks. > > Students, single offices, employees, etc. may or may not get > > blocks depending on network management policy, recipient > > request, recipient need, etc. > > > > YMMV. > > MMV. In my experience, people don't get blocks, devices get > addresses. Some of those devices may be routers, which may > have blocks of addresses for the devices attached to them. > So the question of how big a block is appropriate for the > room is moot--the right question is how many addresses are > required for a routed segment, based on the number of > devices connected there. > I don't that's really the question in IPv6 as the minimum routed segment, according to the current address plan, is /64, which certainly supports a *REALLY LARGE* number of devices. The question is more about whether there needs to be more than one routed segment per room...?? /Lea From owen at delong.com Thu May 19 14:45:03 2005 From: owen at delong.com (Owen DeLong) Date: Thu, 19 May 2005 11:45:03 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: References: Message-ID: <4C3B1FF52BC3C1FE5D83A6CE@imac-en0.delong.sj.ca.us> > I don't that's really the question in IPv6 as the minimum routed segment, > according to the current address plan, is /64, which certainly supports a > *REALLY LARGE* number of devices. > > The question is more about whether there needs to be more than one routed > segment per room...?? I concur. However, I think the only possible answer is sometimes <1 (few device(s) per room with multiple rooms sharing a routed segment), sometimes 1 (each room gets a routed segment), and, sometimes many. To me, it doesn't make sense for ARIN policy to get down to this level of implementation detail. That should be between the LIR and the end user (university and student/dorm/campus in this case). Current policy allows for all of these possibilities. There seems to be some confusion about this as some people don't seem to read the policy that way, so, I can, perhaps see a need to clarify current policy to make sure that people understand that the routed segment boundary can occur anywhere they choose to put it in their network, and, that it is OK to issue a single subnet where it's appropriate. I can also see the potential desire to be able to allocate groups of routed segments smaller than /48 (which isn't currently allowed as I read the policy). If we do, we should put them at least on 4 bit boundaries (allowing /48, /52, /56, and /60) or 8 bit boundaries (allowing /48 and /56). Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From L.Howard at stanleyassociates.com Thu May 19 18:30:10 2005 From: L.Howard at stanleyassociates.com (Howard, W. Lee) Date: Thu, 19 May 2005 18:30:10 -0400 Subject: [ppml] IPv6>>32 Message-ID: > > MMV. In my experience, people don't get blocks, devices get > > addresses. Some of those devices may be routers, which may have > > blocks of addresses for the devices attached to them. So > the question > > of how big a block is appropriate for the room is moot--the right > > question is how many addresses are required for a routed segment, > > based on the number of devices connected there. > > > I don't that's really the question in IPv6 as the minimum > routed segment, according to the current address plan, is > /64, which certainly supports a *REALLY LARGE* number of devices. > > The question is more about whether there needs to be more > than one routed segment per room...?? Good point. Sounds again like an architecture question--are there separate layer 2 networks within this topology? If so, > /64. I would argue that dorm rooms in particular don't need to be addressed for the future, since the device set every 6 months; if the school eventually rolls out minifridges with IPv6 addressability (so Mr. Dillon's maid can restock the minibar) then a new infrastructure is needed anyway, and it will require new numbering. Lee > /Lea From david.conrad at nominum.com Thu May 19 19:56:36 2005 From: david.conrad at nominum.com (David Conrad) Date: Thu, 19 May 2005 16:56:36 -0700 Subject: [ppml] IPv6>>32 In-Reply-To: References: Message-ID: Lea, On May 19, 2005, at 11:18 AM, Lea Roberts wrote: > I don't that's really the question in IPv6 as the minimum routed > segment, > according to the current address plan, is /64, which certainly > supports a > *REALLY LARGE* number of devices. As I understand it, the point of the /64 isn't assigning each address rather it is to provide space for auto-configuration. By design, the lower 64 bits are going to be extremely sparse. Rgds, -drc From Ed.Lewis at neustar.biz Fri May 20 13:52:52 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Fri, 20 May 2005 13:52:52 -0400 Subject: [ppml] A technical request (regarding AAAA for chia.arin.net) Message-ID: In a discussion on an IETF mailing list this was mentioned: (http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00818.html) "... ARIN could register an AAAA record for chia.arin.net as glue through its registrar and then that record would be returned, too." Can someone at ARIN request that chia's AAAA record be added as glue? And the same for any other ARIN nameserver that has IPv6? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ed.Lewis at neustar.biz Fri May 20 13:56:18 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Fri, 20 May 2005 13:56:18 -0400 Subject: [ppml] tying back to 2005-1 Message-ID: I'm assuming that the mega-thread "IPv6>>32" and it's threadlets are related to the proposed policy 2005-1. I have a few questions in that context. Is the policy's reference to "minimum size" saying that the allocation is to be a prefix of /48? "If the organization grows to require more space" - does this mean that the organization has hit the HD ratio limit? Does the organization have to register all of it's used addresses (SWIP?) to indicate this? Will such address allocations be "non-aggregatable?" Is the intent to allocate these addresses from one segment of address space range because of that? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From cathym at arin.net Fri May 20 14:35:44 2005 From: cathym at arin.net (Cathy Murphy) Date: Fri, 20 May 2005 14:35:44 -0400 (EDT) Subject: [ppml] A technical request (regarding AAAA for chia.arin.net) In-Reply-To: References: Message-ID: Thanks, Ed. We took note of the discussion earlier on namedroppers and are already pursuing this. For future reference, DNS related requests should be submitted to whatever the RNAME email address is for our zones. Currently, that is bind at arin.net. Regards, Cathy Murphy ARIN On Fri, 20 May 2005, Edward Lewis wrote: > In a discussion on an IETF mailing list this was mentioned: > > (http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00818.html) > > "... ARIN > could register an AAAA record for chia.arin.net as glue through its > registrar and then that record would be returned, too." > > Can someone at ARIN request that chia's AAAA record be added as glue? And the > same for any other ARIN nameserver that has IPv6? > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-571-434-5468 > NeuStar > > If you knew what I was thinking, you'd understand what I was saying. From bicknell at ufp.org Fri May 20 15:12:35 2005 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 20 May 2005 15:12:35 -0400 Subject: [ppml] tying back to 2005-1 In-Reply-To: References: Message-ID: <20050520191235.GA66562@ussenterprise.ufp.org> In a message written on Fri, May 20, 2005 at 01:56:18PM -0400, Edward Lewis wrote: > I'm assuming that the mega-thread "IPv6>>32" and it's threadlets are > related to the proposed policy 2005-1. As the original poster of "IPv6>>32", my straw man proposal had nothing specifically to do with 2005-1. I do think some of the sub-threads wandered into that area though. As I see it, there are several interdependent issues to discuss: - Is a /64 of "host space" a good idea. (IPv6>>32) - What is the proper measure of utilization. [Straight percentage, HD Ratio, with either, what is the choice of threshold.] - Should IPv6 space be made available to non-ISP's? (2005-1) - Should IPv6 space be made available to non-Internet networks? Unfortunately, they are very much linked in important ways, where a change in one area can cause huge consequences in another. Complicate that with the current lack of operational experience at all levels and it's extremely difficult to reach a consensus. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From lea.roberts at stanford.edu Fri May 20 15:43:20 2005 From: lea.roberts at stanford.edu (Lea Roberts) Date: Fri, 20 May 2005 12:43:20 -0700 (PDT) Subject: [ppml] tying back to 2005-1 In-Reply-To: Message-ID: On Fri, 20 May 2005, Edward Lewis wrote: > I'm assuming that the mega-thread "IPv6>>32" and it's threadlets are > related to the proposed policy 2005-1. > AS Leo has answered... it's his thread, all spun off from his proposal to shift IPv6 addresses 32 bits to the right (hence >>32 :-). Not alot has had to do with 2005-1 except occasionally. > I have a few questions in that context. I'm sure Owen will answer these, too, but I'll take a cut at it, too. And remember that 2005-1 did not acheive consensus as proposed and so it will have to mutate in reponse to the feedback received. > Is the policy's reference to "minimum size" saying that the > allocation is to be a prefix of /48? It says whatever the applicant would be able to receive directly whatever they would qualify for if receiving space from an LIR. For a single site organization, that would likely be a /48. For a multi-site applicant, perhaps they could argue the current policy entitles them to a /48 per site... certainly alot of the posts in the IPv6>>32 thread have asserted these "rights" and "requirements". > "If the organization grows to require more space" - does this mean > that the organization has hit the HD ratio limit? Does the > organization have to register all of it's used addresses (SWIP?) to > indicate this? > > Will such address allocations be "non-aggregatable?" Is the intent > to allocate these addresses from one segment of address space range > because of that? These were considered operational/implementation details that shouldn't be spelled out in the policy itself... again the assumption was that whatever criteria an LIR should use would be applied. /Lea From Ed.Lewis at neustar.biz Fri May 20 15:58:12 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Fri, 20 May 2005 15:58:12 -0400 Subject: why I ask ... Re: [ppml] tying back to 2005-1 In-Reply-To: References: Message-ID: >These were considered operational/implementation details that shouldn't >be spelled out in the policy itself... again the assumption was that >whatever criteria an LIR should use would be applied. My reason for asking is to be better prepared to express opinions on the policy and to "vote" "the right way" the next time the policy is brought up. (Leaving details to "assumptions" doesn't help draw wider interest in the policy development process.) I'm not asking that the questions and their answers be put into the policy text. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From lea.roberts at stanford.edu Fri May 20 16:11:24 2005 From: lea.roberts at stanford.edu (Lea Roberts) Date: Fri, 20 May 2005 13:11:24 -0700 (PDT) Subject: why I ask ... Re: [ppml] tying back to 2005-1 In-Reply-To: Message-ID: On Fri, 20 May 2005, Edward Lewis wrote: > >These were considered operational/implementation details that shouldn't > >be spelled out in the policy itself... again the assumption was that > >whatever criteria an LIR should use would be applied. > > My reason for asking is to be better prepared to express opinions on > the policy and to "vote" "the right way" the next time the policy is > brought up. (Leaving details to "assumptions" doesn't help draw > wider interest in the policy development process.) > > I'm not asking that the questions and their answers be put into the > policy text. They are certainly reasonable questions and should be discussed here. Now that the IPv6>>32 flames are turning to coals, we can always start back on 2005-1... I'm sure that will bring out some equally spirited and strongly held views! :-) have a great week-end, all!! /Lea From kloch at hotnic.net Fri May 20 16:34:11 2005 From: kloch at hotnic.net (Kevin Loch) Date: Fri, 20 May 2005 16:34:11 -0400 Subject: [ppml] tying back to 2005-1 In-Reply-To: References: Message-ID: <428E49C3.2020805@hotnic.net> > It says whatever the applicant would be able to receive directly whatever > they would qualify for if receiving space from an LIR. For a single site > organization, that would likely be a /48. For a multi-site applicant, > perhaps they could argue the current policy entitles them to a /48 per > site... certainly alot of the posts in the IPv6>>32 thread have asserted > these "rights" and "requirements". The policy definition of "end site" has nothing to do with physical locations. As I read it a single customer with multiple separate physical locations would still have to use just one /48 to not trigger the RIR review process. The policy acknowledges that this will likely evolve as we gain operational experience. I suggest that exceptions be made for end sites that have separate physical locations connecting to different POP's of the same ISP. If they connect to the same POP I don't see the problem with sharing a /48. - Kevin From owen at delong.com Mon May 23 03:09:22 2005 From: owen at delong.com (Owen DeLong) Date: Mon, 23 May 2005 00:09:22 -0700 Subject: [ppml] tying back to 2005-1 In-Reply-To: References: Message-ID: <6FE35EB2ADCB59983880D5F5@[172.17.1.152]> --On Friday, May 20, 2005 13:56 -0400 Edward Lewis wrote: > I'm assuming that the mega-thread "IPv6>>32" and it's threadlets are > related to the proposed policy 2005-1. > Only in so much as they are both IPv6 oriented. They do not attempt to, in any way, address the same issue that 2005-1 was aimed at. > I have a few questions in that context. > > Is the policy's reference to "minimum size" saying that the allocation is > to be a prefix of /48? > The 2005-1 reference to minimum size is intended to be non-specific so that if ARIN changes the minimum allocation unit, generally, it will change for this policy as well. Under current guidelines, yes, it would be a /48. > "If the organization grows to require more space" - does this mean that > the organization has hit the HD ratio limit? Does the organization have > to register all of it's used addresses (SWIP?) to indicate this? > Since this is an end site and an assignment, not an allocation, SWIP would not be applicable. Yes, it would require at least meeting the HD ratio limit, but, I would tend to think that the following criteria would apply: Need for more subnets than can be contained in current assignment (e.g. if /48 is current assignment, org would have to show need for more than 65,536 subnets. OR Need for more than 64 bits per subnet such that a smaller number of subnets would still encompass a /48). > Will such address allocations be "non-aggregatable?" Is the intent to > allocate these addresses from one segment of address space range because > of that? 2005-1 provides for assignments, not allocations. I'm not sure what you mean by non-aggregatable. If you mean "Is the expectation that these assignments will probably be advertised with a unique routing policy?", then, the answer is yes. As to the second part of your question, I think that is the kind of thing that would usually be left up to ARIN staff. If you feel it's important, you could propose it as an amendment to the policy and we could see how people feel about it. I tend to think staff would probably do that anyway, just to make their workflow more efficient if nothing else. Owen -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From owen at delong.com Mon May 23 03:18:30 2005 From: owen at delong.com (Owen DeLong) Date: Mon, 23 May 2005 00:18:30 -0700 Subject: why I ask ... Re: [ppml] tying back to 2005-1 In-Reply-To: References: Message-ID: <9C34F7CD7047C99A1F7D355C@[172.17.1.152]> --On Friday, May 20, 2005 15:58 -0400 Edward Lewis wrote: > >> These were considered operational/implementation details that shouldn't >> be spelled out in the policy itself... again the assumption was that >> whatever criteria an LIR should use would be applied. > > My reason for asking is to be better prepared to express opinions on the > policy and to "vote" "the right way" the next time the policy is brought > up. (Leaving details to "assumptions" doesn't help draw wider interest > in the policy development process.) > Permit me to rephrase for Lea... These are operational/implementation details that are generally left up to ARIN staff in other policies. However, the policy explicitly stated that the amount of space issued here would be directly tied to the amount of space that would be issued by an applicable LIR if the end site were going through the LIR process instead of ARIN. That was not an assumption... It was spelled out in the policy. There are already existing guidelines for what LIRs can issue under what circumstances, but, by the nature of IPv6, they are in rapid flux, so, it seemed to make sense to tie this policy to those policies by reference, thus preventing any sort of dichotomy of riches between the LIR and ARIN processes. > I'm not asking that the questions and their answers be put into the > policy text. Understood... I hope I have sufficiently answered you question. If not, please let me know. Thanks, Owen -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From memsvcs at arin.net Wed May 25 08:09:55 2005 From: memsvcs at arin.net (Member Services) Date: Wed, 25 May 2005 08:09:55 -0400 Subject: [ppml] Policy Proposal 2005-5: IPv6 HD ratio Message-ID: <20050525120958.4B8181FEE7@mercury.arin.net> On May 19, 2005, the ARIN Advisory Council (AC) concluded its review of proposed policy 'IPv6 HD ratio' and agreed to forward it as a formal proposal for discussion by the community. This proposal is designated 2005-5: IPv6 HD ratio. The policy proposal text is below and can be found at: http://www.arin.net/policy/proposals/2005_5.html All persons in the community are encouraged to discuss policy proposal 2005-5 in the weeks leading to the ARIN Public Policy Meeting in Los Angeles, CA, scheduled for October 26-28, 2005. Both the discussion on the PPML and at the public policy meeting will be used to determine the community consensus regarding this policy proposal. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html ARIN's Policy Proposal Archive can be found at: http://www.arin.net/policy/proposal_archive.html Regards, Member Services American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal 2005-5: IPv6 HD ratio Author: Andrew Dul Policy term: permanent Policy statement: Change HD ratio used for IPv6 allocations to 0.94 This would modify sections 6.5.2.2 & 6.7 (including the HD-ratio to percentage table) of the NRPM. Rationale: Recent research has shown that based upon certain growth models the current IPv6 allocation policy using the HD ratio of 0.8 will allocate between a /1 and /4 of Ipv6 address space over the period of about 60 years. http://www.ietf.org/internet-drafts/draft-huston-ipv6-hd-metric-00.txt By changing the HD ratio to 0.94, this would require LIRs to have a higher utilization of the /48s that are assigned to end sites before being able to obtain additional allocations. This policy would change the threshold for an LIR holding a /32 from approximately 11% to 51%. An LIR with a /20 would have a utilized percentage of approximately 31% vs. the current 2%. This policy may also prevent the hoarding of IPv6 addresses by current organizations with large customer bases, but no substantial current IPv6 network. Timetable for implementation: Within 30 days of ratification by the BoT. From memsvcs at arin.net Wed May 25 08:09:26 2005 From: memsvcs at arin.net (Member Services) Date: Wed, 25 May 2005 08:09:26 -0400 Subject: [ppml] Policy Proposal 2005-4: AfriNIC Recognition Policy Message-ID: <20050525120928.F21A21FEE5@mercury.arin.net> On May 19, 2005, the ARIN Advisory Council (AC) concluded its review of proposed policy 'AfriNIC Recognition Policy' and agreed to forward it as a formal proposal for discussion by the community. This proposal is designated 2005-4: AfriNIC Recognition Policy. The policy proposal text is below and can be found at: http://www.arin.net/policy/proposals/2005_4.html All persons in the community are encouraged to discuss policy proposal 2005-4 in the weeks leading to the ARIN Public Policy Meeting in Los Angeles, CA, scheduled for October 26-28, 2005. Both the discussion on the PPML and at the public policy meeting will be used to determine the community consensus regarding this policy proposal. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html ARIN's Policy Proposal Archive can be found at: http://www.arin.net/policy/proposal_archive.html Regards, Member Services American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal 2005-4: AfriNIC Recognition Policy Author: Andrew Dul Policy term: permanent Policy statement: Remove section 4.8 entitled "Policy for the African Portion of the ARIN Region" of the NRPM. Rationale: The ARIN BoT recently suspended section 4.8 of the NRPM upon recognition of AfriNIC as an RIR by ICANN. Section 4.8 of the NRPM applied only to areas of the ARIN region that are now covered by AfriNIC. Timetable for implementation: Within 30 days of ratification by the BoT. From Ed.Lewis at neustar.biz Wed May 25 11:14:06 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Wed, 25 May 2005 11:14:06 -0400 Subject: [ppml] Policy Proposal 2005-5: IPv6 HD ratio In-Reply-To: <20050525120958.4B8181FEE7@mercury.arin.net> References: <20050525120958.4B8181FEE7@mercury.arin.net> Message-ID: At 8:09 -0400 5/25/05, Member Services wrote: >http://www.arin.net/policy/proposals/2005_5.html >Policy Proposal 2005-5: IPv6 HD ratio > >Author: Andrew Dul > >Policy term: permanent > >Policy statement: Change HD ratio used for IPv6 allocations to 0.94 > >This would modify sections 6.5.2.2 & 6.7 (including the HD-ratio to >percentage table) of the NRPM. > >Rationale: Recent research has shown that based upon certain growth models >the current IPv6 allocation policy using the HD ratio of 0.8 will allocate >between a /1 and /4 of Ipv6 address space over the period of about 60 years. > >http://www.ietf.org/internet-drafts/draft-huston-ipv6-hd-metric-00.txt > >By changing the HD ratio to 0.94, this would require LIRs to have a higher >utilization of the /48s that are assigned to end sites before being able to >obtain additional allocations. This policy would change the threshold for >an LIR holding a /32 from approximately 11% to 51%. >An LIR with a /20 would have a utilized percentage of approximately 31% vs. >the current 2%. I have two questions, not addressed in the ID referenced above. (Note that the document at that URL will expire before the October meeting. I would therefore encourage PPML'ers to help get the draft through to the RFC Editor to become a document that can be permanently referenced.) 1) Will the tightening of the HD-ratio mean that ARIN will have to turn around addressing requests faster? I am not saying there is a problem now, but raising the HD-ration means that I would have to delay asking for new space until I passed the 0.8 threshold and until I hit the new one. Delaying here means losing lead time from request to need to use. 2) Will the tightening of the HD-ratio mean a significantly more dense use of the space resulting in more incidents of end-user renumbering if their needs grow? Another question I have is related to what is in the draft. The draft illustrates the benefits of a 0.94 HD-ratio over 0.8, but I don't see that 0.94 is established as "optimal." Why not 0.93? 0.95? Quoting the conclusions of the draft: "It is recommended that further study of address efficiency metrics and the relationship between network structure and address efficiency models considered as part of such a study. Consideration should be given to the viability of specifying a higher HD-Ratio value as representing a more relevant model of internal network structure, internal routing and internal address aggregation structures." The conclusions section mentions only the 0.8 HD-ratio. The conclusions do not mention 0.94 at all. >This policy may also prevent the hoarding of IPv6 addresses by current >organizations with large customer bases, but no substantial current IPv6 >network. > >Timetable for implementation: Within 30 days of ratification by the BoT. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From kloch at hotnic.net Wed May 25 14:27:01 2005 From: kloch at hotnic.net (Kevin Loch) Date: Wed, 25 May 2005 14:27:01 -0400 Subject: [ppml] Policy Proposal 2005-5: IPv6 HD ratio In-Reply-To: References: <20050525120958.4B8181FEE7@mercury.arin.net> Message-ID: <4294C375.1090709@hotnic.net> Edward Lewis wrote: > 1) Will the tightening of the HD-ratio mean that ARIN will have to > turn around addressing requests faster? I am not saying there is a > problem now, but raising the HD-ration means that I would have to > delay asking for new space until I passed the 0.8 threshold and until > I hit the new one. Delaying here means losing lead time from request > to need to use. With HD=0.94 and an allocation of /32 the threshold would be about 50%. You would have about 32,000 customer assignments left at that point. Lead time should not be an issue. > 2) Will the tightening of the HD-ratio mean a significantly more dense > use of the space resulting in more incidents of end-user renumbering > if their needs grow? The threshold appplies to total number of /48's. The choice of dense or sparse assignment policy does not affect the threshold. - Kevin From Michael.Dillon at radianz.com Thu May 26 05:29:59 2005 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 26 May 2005 10:29:59 +0100 Subject: [ppml] Policy Proposal 2005-5: IPv6 HD ratio In-Reply-To: Message-ID: > >http://www.ietf.org/internet-drafts/draft-huston-ipv6-hd-metric-00.txt > I would therefore encourage PPML'ers to help get the draft > through to the RFC Editor to become a document that can be > permanently referenced.) That sounds like an awfully convoluted process. Is there some law preventing ARIN from copying that document to its own servers so that it can be referenced by the people making decisions on ARIN policy? If the IETF sees some reason to make this into an RFC before ARIN makes its policy decision, that is nice, but I don't think we should make ARIN's decisions dependent on the IETF's publishing decisions or their system of classifying publications. --Michael Dillon From Ed.Lewis at neustar.biz Thu May 26 08:52:38 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Thu, 26 May 2005 08:52:38 -0400 Subject: [ppml] Policy Proposal 2005-5: IPv6 HD ratio In-Reply-To: References: Message-ID: At 10:29 +0100 5/26/05, Michael.Dillon at radianz.com wrote: >> >http://www.ietf.org/internet-drafts/draft-huston-ipv6-hd-metric-00.txt > >> I would therefore encourage PPML'ers to help get the draft >> through to the RFC Editor to become a document that can be >> permanently referenced.) > >That sounds like an awfully convoluted process. Is there some >law preventing ARIN from copying that document to its own servers >so that it can be referenced by the people making decisions on >ARIN policy? If the IETF sees some reason to make this into >an RFC before ARIN makes its policy decision, that is nice, >but I don't think we should make ARIN's decisions dependent on >the IETF's publishing decisions or their system of classifying >publications. I'm not a lawyer, so I won't touch the question about law. Here is the reality though. 1) The URL is temporal. What is there will disappear in a few months. Just for the sake of being able to read it the week before the ARIN meeting, it has to available somewhere else. 2) If the document is updated (and it probably will, if just to correct some simple typographical errors), the location of the document will change (-01, -02, etc.) Once the new edition is out, the old edition is pulled - so, say that comments contributed get Geoff to make an update on June 31st, the above URL will become a dead pointer before the expiration of the document. (Yes, June 31st - a fake date.) 3) An Internet Draft is a document that has no offer of vetting. E.g., let's say Geoff's calculator is wrong - there's no telling in the document. An RFC is a document that has gone through some review, meaning it is somewhat vetted. I should add that the vetting and permanent storage of the document need to be accomplished in the IETF. But as far as I know, there is no ARIN document series as of now. (There is a RIPE document series.) What I am encouraging is that this document be vetted and put into a permanent location, possibly within the the IETF, possibly in some other form recognized by ARIN. I have already sent comments to Geoff. All I am asking is that others read the document and if you feel the need to send in comments, do so. (For example, the selection of 0.94 is not clearly identified as the best choice in Geoff's document. Why not 0.93 or 0.95?) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From L.Howard at stanleyassociates.com Thu May 26 12:58:40 2005 From: L.Howard at stanleyassociates.com (Howard, W. Lee) Date: Thu, 26 May 2005 12:58:40 -0400 Subject: [ppml] Policy Proposal 2005-5: IPv6 HD ratio Message-ID: > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Kevin Loch > Sent: Wednesday, May 25, 2005 2:27 PM > To: ppml at arin.net > Subject: Re: [ppml] Policy Proposal 2005-5: IPv6 HD ratio > > > Edward Lewis wrote: > > > 1) Will the tightening of the HD-ratio mean that ARIN will > have to > turn around addressing requests faster? I am not > saying there is a > problem now, but raising the HD-ration > means that I would have to > delay asking for new space > until I passed the 0.8 threshold and until > I hit the new > one. Delaying here means losing lead time from request > to > need to use. > > With HD=0.94 and an allocation of /32 the threshold would be > about 50%. You would have about 32,000 customer assignments > left at that point. Lead time should not be an issue. Since the HD Ratio purportedly takes network hierarchy into account, let's do the same while discussing it. You might have 32,768 /48s remaining, but not necessarily contiguous or in the part of the network where they're needed. Carve your /32 into 16 regional networks, (let's say British Columbia, Northwest US, and Central-West US are three regions) each of which has 1/16 of the /32, or a /36. Divvy the region into metro areas of /39 each, and you only have 512 /48s in each area. It's easy to imagine running out of space in one area while not meeting the HD Ratio. Of course, cleverer folk among us will realize that you have foolishly squandered your addresses by assigning the same size block to every network. What you should have done is to assign a /39 to British Columbia (sorry, guys) and a /35 to San Francisco. Even then, SF only have 8192 /48s, while BC has 512; it still might not be enough. Of course, since you can't delegate those ugly, off-byte allocation sizes to regional servers, you'll have to delegate multiple /40s. Or you shouldn't have assigned so many /48s to end users who didn't need them, nevermind what the policies say. > > 2) Will the tightening of the HD-ratio mean a > significantly more dense > use of the space resulting in > more incidents of end-user renumbering > if their needs grow? > > The threshold appplies to total number of /48's. The choice > of dense or sparse assignment policy does not affect the threshold. If you require a higher host density, you have fewer reservations of adjacent blocks when you go back for more. You may have reserved the next /48 for your first customer, but if you have to exceed 50% assignment, that reservation will have to be used before you can request more space. If Customer #1 outgrows their /48, they will have to renumber to a different /47, or have two discontiguous /48s. > - Kevin If we must have an HD Ratio, I'd raise it. Lee From memsvcs at arin.net Thu May 26 13:02:11 2005 From: memsvcs at arin.net (Member Services) Date: Thu, 26 May 2005 13:02:11 -0400 Subject: [ppml] Last Call Reminder Message-ID: <42960113.4060402@arin.net> This is a reminder that the following policy proposals are in last call on the ARIN Public Policy Mailing List through 12:00 Noon, Eastern Time, June 1, 2005: 2004-3: Global Addresses for Private Network Inter-Connectivity http://www.arin.net/policy/proposals/2004_3.html 2004-8: Allocation of IPv6 Address Space by the Internet Assigned Numbers Authority (IANA) Policy to Regional Internet Registries http://www.arin.net/policy/proposals/2004_8.html 2005-3: Lame Delegations http://www.arin.net/policy/proposals/2005_3.html All persons in the community are encouraged to provide comments during this last call period. Per the Internet Resource Policy Evaluation Process, the ARIN Advisory Council will take these comments into consideration when conducting the Last Call Review to determine final community consensus regarding these policy proposals. Mailing list subscription information and archives can be found at: http://www.arin.net/mailing_lists/ ARIN's Policy Proposal Archive can be found at: http://www.arin.net/policy/proposal_archive.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) From gih at apnic.net Thu May 26 20:23:00 2005 From: gih at apnic.net (Geoff Huston) Date: Fri, 27 May 2005 10:23:00 +1000 Subject: [ppml] Policy Proposal 2005-5: IPv6 HD ratio In-Reply-To: References: Message-ID: <6.0.1.1.2.20050527102140.0693b3c0@localhost> At 10:52 PM 26/05/2005, Edward Lewis wrote: I have already sent comments to Geoff. All I am asking is that others read the document and if you feel the need to send in comments, do so. (For example, the selection of 0.94 is not clearly identified as the best choice in Geoff's document. Why not 0.93 or 0.95?) yes indeed -comments would be greatly appreciated! I'm looking here on this list of course, but I'll take comments any way you want to send them! regards Geoff From David.Poch at telus.com Thu May 26 21:32:19 2005 From: David.Poch at telus.com (David Poch) Date: Thu, 26 May 2005 19:32:19 -0600 Subject: [ppml] 2004-3: Global Addresses for Private Network Inter-Connectivity Message-ID: <041DA392ED1E6246B2BCB500C949C5C401A95CD5@ABMSG110.corp.ads> Can an ISP apply for address space under this policy as an end user of IP Addresses (for their own enterprise network, or for infrastructure that will not be connected to the internet)? If so must they use a different org ID than they use to obtain address space they reassign to their customers? -------------- next part -------------- An HTML attachment was scrubbed... URL: