From Keith at jcc.com Fri May 1 13:42:57 2009 From: Keith at jcc.com (Keith W. Hare) Date: Fri, 1 May 2009 13:42:57 -0400 Subject: [arin-discuss] IPv6 Hurdles Message-ID: As a relatively small end user, I see a number of hurdles to implementing IPv6: 1. Finding supported equipment that supports IPv6 2. Getting IPv6 service from my ISP 3. Learning enough to configure and use IPv6 4. Pushing business application vendors to support IPv6 1. Finding supported equipment that supports IPv6 At the moment, finding equipment that support IPv6 is the biggest road block. I'm not looking for millions of dollars worth of equipment, I'm looking for thousands of dollars worth of equipment. I don't have a sales rep from any of the networking vendors. My primary source for network equipment are places such as PC Connection, CDW, etc. Try going to the websites for several of the computer retailers and search for IPv6. Either equipment that supports IPv6 is not yet available, or marketing doesn't think IPv6 is sufficiently important to mention it in the specifications. Sure, I could find a linux download that supports IPv6 and build my own firewall, but networking and firewalls are not my primary job -- I do them because somebody has to. I'm looking for off-the-shelf supported equipment. 2. Getting IPv6 service from my ISP My ISP does not yet support IPv6. I do have a sales contact at my ISP and it sounds like the ISP is working on beginning to think about planning to deploy IPv6. However, there is no benefit in pushing the ISP when I can't figure out what network equipment to purchase. 3. Learning enough to configure and use IPv6 Learning IPv6 is on my list. I even have an IPv6 book on my shelf. However, without network equipment, what's the point? 4. Pushing business application vendors to support IPv6 I don't think the business applications we use support IPv6 yet. However, without network equipment, I can't test and can't push the vendors. Summary Until I can go to computer vendor's web store, search for IPv6, and find network equipment, IPv6 will not be real. There is a stalemate here. The equipment vendors are not providing IPv6 because there is no customer demand. The customers are not demanding IPv6 because there must not be a need for IPv6 since vendors are not marketing IPv6. The recent ARIN letter from John Curran may kick the discussion up a notch. If it does, the letter was worth the cost. The ARIN IPv6 wiki (http://www.getipv6.info) is a start, but is still pretty sketchy. A really useful addition to the IPv6 wiki would be a section that documents what equipment and software versions support IPv6, and the approximate cost. Making it possible to find equipment that supports IPv6 will certainly increase the IPv6 adoption rate. Keith ______________________________________________________________ Keith W. Hare JCC Consulting, Inc. keith at jcc.com 600 Newark Road Phone: 740-587-0157 P.O. Box 381 Fax: 740-587-0163 Granville, Ohio 43023 http://www.jcc.com USA ______________________________________________________________ From dbrick at kom.net Fri May 1 14:31:27 2009 From: dbrick at kom.net (Douglas Brick) Date: Fri, 1 May 2009 11:31:27 -0700 Subject: [arin-discuss] IPv6 Hurdles In-Reply-To: References: Message-ID: <18939.16383.741399.412192@dbrick.sea0.speakeasy.net> I just saw this the other day on the nanog 46 agenda: Tutorial: Deploy a Production IPv6 Network in 30 Minutes or less Moderator: Richard Steenbergen Abstract: A completely practical step by step guide to configuring IPv6 in a production network without breaking anything, for people who hate IPv6 and don't have it deployed currently. The goal would be that everyone who leaves the room should be able to successfully deploy an IPv6 network on top of an existing v4 network on any common Juniper/Cisco hardware, without needing to be IPv6 experts or lovers of the protocol. I also want to talk about practical techniques for addressing management so you can successfully deploy IPv6 without having successfully rewritten all of your internal management tools to fully support it, and other tricks to minimize the pain. http://nanog.org/meetings/nanog46/abstracts.php?pt=MTM3MyZuYW5vZzQ2&nm=nanog46 On Friday, 1 May 2009, at 13:42:57, Keith W. Hare wrote: > As a relatively small end user, I see a number of hurdles to > implementing IPv6: [....] > There is a stalemate here. The equipment vendors are not providing > IPv6 because there is no customer demand. The customers are not > demanding IPv6 because there must not be a need for IPv6 since > vendors are not marketing IPv6. From spiffnolee at yahoo.com Fri May 1 15:05:39 2009 From: spiffnolee at yahoo.com (Lee Howard) Date: Fri, 1 May 2009 12:05:39 -0700 (PDT) Subject: [arin-discuss] IPv6 Hurdles In-Reply-To: References: Message-ID: <478649.75043.qm@web63307.mail.re1.yahoo.com> ----- Original Message ---- > From: Keith W. Hare > To: "arin-discuss at arin.net" > Sent: Friday, May 1, 2009 1:42:57 PM > Subject: [arin-discuss] IPv6 Hurdles > > 1. Finding supported equipment that supports IPv6 > > At the moment, finding equipment that support IPv6 is the biggest road block. What kind of equipment are you looking for? Current desktop OSes support IPv6. Most routers and switches do, but YMMV depending on features needed. I found this website listing vendors support IPv6, but I don't know whether it's claimed support or tested support: http://www.ipv6-to-standard.org/ DoD also listed supported devices for IPv6: http://jitc.fhu.disa.mil/apl/ipv6.html I've added these to the ARIN wiki: http://www.getipv6.info/index.php/Device_Support > Sure, I could find a linux download that supports IPv6 and build my own > firewall, but networking and firewalls are not my primary job -- I do them > because somebody has to. I'm looking for off-the-shelf supported equipment. If networking's not your thing, there's no shame in hiring a consultant or VAR to build it (or just design it) for you. > 2. Getting IPv6 service from my ISP Google "IPv6 tunnel" to find an ISP who will tunnel IPv6 for you. Usually very cheap. > 3. Learning enough to configure and use IPv6 > > Learning IPv6 is on my list. I even have an IPv6 book on my shelf. However, > without network equipment, what's the point? So you have a plan. You need to write your addressing plan, develop your architecture, write use cases, update your systems. btw, many IPv6 books are out of date and trying to cash in on hype and FUD. Some book reviews: http://www.getipv6.info/index.php/Book_Reviews > 4. Pushing business application vendors to support IPv6 > > I don't think the business applications we use support IPv6 yet. However, > without network equipment, I can't test and can't push the vendors. What applications? Most business applications are network-layer-agnostic, and should work fine. Operations support systems (monitoring, alerting, reporting, security) may need work, but vi and PeachTree should be fine. At least some databases support IPv6 to at least some extent, but you'd have to ask them. > Summary > > Until I can go to computer vendor's web store, search for IPv6, and find network > equipment, IPv6 will not be real. IPv6 isn't a feature. Go to the same vendor's web store and enter "IPv4" and you don't see many products. > The ARIN IPv6 wiki (http://www.getipv6.info) is a start, but is still pretty > sketchy. > > A really useful addition to the IPv6 wiki would be a section that documents what > equipment and software versions support IPv6, and the approximate cost. Making > it possible to find equipment that supports IPv6 will certainly increase the > IPv6 adoption rate. >From the main page, click IPv6 Deployment and Migration Planning. You'll see a link to Device Support. Yes, it would be nice to see more devices listed, but I'm not sure it's realistic to list every software version of each device, and providing cost would be inappropriate for ARIN. Lee From clb at midasnetworks.com Fri May 1 15:15:55 2009 From: clb at midasnetworks.com (Chris Boyd) Date: Fri, 1 May 2009 14:15:55 -0500 Subject: [arin-discuss] IPv6 Hurdles In-Reply-To: References: Message-ID: <84B79AB7-C33F-4533-B4AF-74FC64581B88@midasnetworks.com> On May 1, 2009, at 12:42 PM, Keith W. Hare wrote: > A really useful addition to the IPv6 wiki would be a section that > documents what equipment and software versions support IPv6, and the > approximate cost. Making it possible to find equipment that supports > IPv6 will certainly increase the IPv6 adoption rate. Can we please include a field for comments from people who have actually tested or deployed it as well? Knowing what knobs in a Cisco 6500 running IPv6 (or even v4 :-) make it blow up would be enourmously useful. --Chris From Keith at jcc.com Fri May 1 15:45:57 2009 From: Keith at jcc.com (Keith W. Hare) Date: Fri, 1 May 2009 15:45:57 -0400 Subject: [arin-discuss] IPv6 Hurdles In-Reply-To: <478649.75043.qm@web63307.mail.re1.yahoo.com> References: <478649.75043.qm@web63307.mail.re1.yahoo.com> Message-ID: > -----Original Message----- > From: Lee Howard [mailto:spiffnolee at yahoo.com] > Sent: Friday, May 01, 2009 3:06 PM > To: Keith W. Hare; arin-discuss at arin.net > Subject: Re: [arin-discuss] IPv6 Hurdles > >... > > Until I can go to computer vendor's web store, search for > IPv6, and find network > > equipment, IPv6 will not be real. > > IPv6 isn't a feature. Go to the same vendor's web store and > enter "IPv4" and > you don't see many products. > > ... A feature is anything the vendor thinks differentiates a product from the competition such that customers are more likely to purchase that product. IPv4 support no longer differentiates a product so there is no point in mentioning it. IPv6 support should differentiate products for another couple of years. When IPv6 support becomes as common as IPv4 support is today, there no longer will be any point in mentioning IPv6 support. Keith From info at arin.net Fri May 1 16:58:31 2009 From: info at arin.net (Member Services) Date: Fri, 01 May 2009 16:58:31 -0400 Subject: [arin-discuss] ARIN XXIII Report Message-ID: <49FB6277.2080700@arin.net> The report of ARIN XXIII Public Policy and Members Meeting, held in San Antonio, will be available no later than the 5PM on Friday 8 May, 2009. The report will include presentations, summary notes, and transcripts of the entire meeting. Archives of the meeting's webcast will be posted to the website as soon as they are available, and no later than two weeks from now. A notification will be sent to the ARIN Announce mailing list at that time. Regards, Member Services American Registry for Internet Numbers (ARIN) From Keith at jcc.com Fri May 1 17:21:19 2009 From: Keith at jcc.com (Keith W. Hare) Date: Fri, 1 May 2009 17:21:19 -0400 Subject: [arin-discuss] IPv6 Hurdles In-Reply-To: <478649.75043.qm@web63307.mail.re1.yahoo.com> References: <478649.75043.qm@web63307.mail.re1.yahoo.com> Message-ID: <95ec7d042f84aa9ff6fdd3c9a92ba1ef49fb67c3@jcc.com> > -----Original Message----- > From: Lee Howard [mailto:spiffnolee at yahoo.com] > Sent: Friday, May 01, 2009 3:06 PM > To: Keith W. Hare; arin-discuss at arin.net > Subject: Re: [arin-discuss] IPv6 Hurdles > > > > > ----- Original Message ---- > > From: Keith W. Hare > > To: "arin-discuss at arin.net" > > Sent: Friday, May 1, 2009 1:42:57 PM > > Subject: [arin-discuss] IPv6 Hurdles > > > > 1. Finding supported equipment that supports IPv6 > > > > At the moment, finding equipment that support IPv6 is the > biggest road block. > > What kind of equipment are you looking for? Current desktop > OSes support > IPv6. Most routers and switches do, but YMMV depending on > features needed. Most specifically, I need a firewall. > I found this website listing vendors support IPv6, but I > don't know whether it's > claimed support or tested support: http://www.ipv6-to-standard.org/ > DoD also listed supported devices for IPv6: > http://jitc.fhu.disa.mil/apl/ipv6.html > I've added these to the ARIN wiki: > http://www.getipv6.info/index.php/Device_Support > The DOD list is useful. However the number of different vendors with tested firewall products is small. > > Sure, I could find a linux download that supports IPv6 and > build my own > > firewall, but networking and firewalls are not my primary > job -- I do them > > because somebody has to. I'm looking for off-the-shelf > supported equipment. > > If networking's not your thing, there's no shame in hiring a > consultant or VAR > to build it (or just design it) for you. My point is that I am not willing to build my own firewall. I want off-the-shelf supported products. > ... > > From the main page, click IPv6 Deployment and Migration > Planning. You'll see a > link to Device Support. Yes, it would be nice to see more > devices listed, but I'm not > sure it's realistic to list every software version of each > device, and providing cost > would be inappropriate for ARIN. There has to be a useful point somewhere between listing nothing and listing every possible combination. Cost is really a surrogate for the approximate organization size a device is designed to support. For example, I'm looking for equipment to support an organization with less than 250 employees. I'm not looking for equipment to support the world wide network backbone. Keith From mksmith at adhost.com Fri May 1 17:40:39 2009 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Fri, 1 May 2009 14:40:39 -0700 Subject: [arin-discuss] IPv6 Hurdles In-Reply-To: <95ec7d042f84aa9ff6fdd3c9a92ba1ef49fb67c3@jcc.com> References: <478649.75043.qm@web63307.mail.re1.yahoo.com> <95ec7d042f84aa9ff6fdd3c9a92ba1ef49fb67c3@jcc.com> Message-ID: <17838240D9A5544AAA5FF95F8D52031605EC165F@ad-exh01.adhost.lan> > > 1. Finding supported equipment that supports IPv6 > > > > At the moment, finding equipment that support IPv6 is the > biggest road block. > > What kind of equipment are you looking for? Current desktop > OSes support > IPv6. Most routers and switches do, but YMMV depending on > features needed. Most specifically, I need a firewall. - The Cisco ASA - Juniper Netscreen - Secure Computing Sidewinder - Fortinet - Checkpoint Obviously you will want to make sure the particular product and software rev is appropriate for v6, but they're out there. Regards, Mike From Matthew.Wilder at telus.com Fri May 1 17:42:13 2009 From: Matthew.Wilder at telus.com (Matthew Wilder) Date: Fri, 1 May 2009 15:42:13 -0600 Subject: [arin-discuss] IPv6 Hurdles In-Reply-To: <95ec7d042f84aa9ff6fdd3c9a92ba1ef49fb67c3@jcc.com> References: <478649.75043.qm@web63307.mail.re1.yahoo.com> <95ec7d042f84aa9ff6fdd3c9a92ba1ef49fb67c3@jcc.com> Message-ID: This is a perfect, practical testimonial showing how IPv6 needs to cross the chasm. If you've read Geoffrey A. Moore's Crossing the Chasm, you know what I am talking about. The focus and mindset of the innovators and early adopters is fundamentally different than even the early majority of a set of people. To innovators and early adopters, technology is the end, and not a means to end. Of course to the early majority, technology (in this case IPv6) is only a means to an end (connectivity). What I am trying to get at here is that IPv6 first of all needs to become more relevant, and ARIN's recent messages have been great. It is very helpful in raising awareness with senior management when you can point to clear warnings from resource stewards like ARIN. Koodos. Vendors of all sorts of network equipment need to help IPv6 cross the chasm by offering complete off-the-shelf solutions for the early majority. The innovators and early adopters don't need this level of support, since they care enough to figure it all out for themselves. But before IPv6 is going to be standard in our networks, it will require a bigger cross-section of vendors treating it like a necessary and robust standard. Matthew Wilder -----Original Message----- From: arin-discuss-bounces at arin.net [mailto:arin-discuss-bounces at arin.net] On Behalf Of Keith W. Hare Sent: Friday, May 01, 2009 2:21 PM To: Lee Howard; arin-discuss at arin.net Subject: Re: [arin-discuss] IPv6 Hurdles > -----Original Message----- > From: Lee Howard [mailto:spiffnolee at yahoo.com] > Sent: Friday, May 01, 2009 3:06 PM > To: Keith W. Hare; arin-discuss at arin.net > Subject: Re: [arin-discuss] IPv6 Hurdles > > > > > ----- Original Message ---- > > From: Keith W. Hare > > To: "arin-discuss at arin.net" > > Sent: Friday, May 1, 2009 1:42:57 PM > > Subject: [arin-discuss] IPv6 Hurdles > > > > 1. Finding supported equipment that supports IPv6 > > > > At the moment, finding equipment that support IPv6 is the > biggest road block. > > What kind of equipment are you looking for? Current desktop OSes > support IPv6. Most routers and switches do, but YMMV depending on > features needed. Most specifically, I need a firewall. > I found this website listing vendors support IPv6, but I don't know > whether it's claimed support or tested support: > http://www.ipv6-to-standard.org/ DoD also listed supported devices for > IPv6: > http://jitc.fhu.disa.mil/apl/ipv6.html > I've added these to the ARIN wiki: > http://www.getipv6.info/index.php/Device_Support > The DOD list is useful. However the number of different vendors with tested firewall products is small. > > Sure, I could find a linux download that supports IPv6 and > build my own > > firewall, but networking and firewalls are not my primary > job -- I do them > > because somebody has to. I'm looking for off-the-shelf > supported equipment. > > If networking's not your thing, there's no shame in hiring a > consultant or VAR to build it (or just design it) for you. My point is that I am not willing to build my own firewall. I want off-the-shelf supported products. > ... > > From the main page, click IPv6 Deployment and Migration Planning. > You'll see a link to Device Support. Yes, it would be nice to see > more devices listed, but I'm not sure it's realistic to list every > software version of each device, and providing cost would be > inappropriate for ARIN. There has to be a useful point somewhere between listing nothing and listing every possible combination. Cost is really a surrogate for the approximate organization size a device is designed to support. For example, I'm looking for equipment to support an organization with less than 250 employees. I'm not looking for equipment to support the world wide network backbone. Keith _______________________________________________ ARIN-Discuss You are receiving this message because you are subscribed to the ARIN Discussion Mailing List (ARIN-discuss at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-discuss Please contact info at arin.net if you experience any issues. From gdolley at arpnetworks.com Fri May 1 17:54:32 2009 From: gdolley at arpnetworks.com (Garry Dolley) Date: Fri, 1 May 2009 14:54:32 -0700 Subject: [arin-discuss] IPv6 Hurdles In-Reply-To: References: Message-ID: <20090501215432.GC4537@garry-thinkpad.arpnetworks.com> On Fri, May 01, 2009 at 01:42:57PM -0400, Keith W. Hare wrote: > As a relatively small end user, I see a number of hurdles to implementing IPv6: > > 1. Finding supported equipment that supports IPv6 I haven't had much trouble with this. All my Linux and *BSD systems support IPv6, same with my Cisco gear. There are some things that don't, like my PDUs and IPMI devices. However, these are not things I would access from the "outside" anyway. Keep in mind that the transition to IPv6 does not mean IPv4 is going to stop working across the board. You can still use it internally within your network for as long as you like, using RFC1918 address space. So let's pretend the Internet is all on IPv6 now. How do I access my PDUs and IPMI devices? Well, I VPN into my network over IPv6 and access those devices using legacy IPv4. Easy. This methodology could be supported for many years to come and not hinder IPv6 deployment. > 2. Getting IPv6 service from my ISP Get an Apple Airport Extreme and it'll automatically put you on IPv6 over an anycast 6to4 tunnel. Not that fastest stuff around, but it works out of the box (at least in my experience). I imagine other home router vendors are doing the same. For a more robust setup, just use a tunnel broker. Most are free. And, if by ISP, you mean an ISP at your data center, well if they don't support IPv6 yet, then consider getting a more progressive one ;) About half the people I peer with already support IPv6, as does my network. > 3. Learning enough to configure and use IPv6 No shortcut on this, you just gotta invest the time. A couple good tutorials will get you up to speed with 90% of what you need to know. > 4. Pushing business application vendors to support IPv6 What kind of apps are you looking at? All the open source apps I use already have IPv6. Are you looking at proprietary solutions? -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st From rmoseley at softlayer.com Fri May 1 17:55:38 2009 From: rmoseley at softlayer.com (Ric Moseley) Date: Fri, 1 May 2009 16:55:38 -0500 Subject: [arin-discuss] IPv6 Hurdles In-Reply-To: References: <478649.75043.qm@web63307.mail.re1.yahoo.com><95ec7d042f84aa9ff6fdd3c9a92ba1ef49fb67c3@jcc.com><17838240D9A5544AAA5FF95F8D52031605EC165F@ad-exh01.adhost.lan> Message-ID: I do IPv6 on both the Cisco ASA and Fortinet Fortigate and it works just fine. The Fortinet has GUI support while the ASA is command line only. Thanks. Ric. -----Original Message----- From: arin-discuss-bounces at arin.net [mailto:arin-discuss-bounces at arin.net] On Behalf Of Michael K. Smith - Adhost Sent: Friday, May 01, 2009 4:41 PM To: Keith W. Hare; Lee Howard; arin-discuss at arin.net Subject: Re: [arin-discuss] IPv6 Hurdles > > 1. Finding supported equipment that supports IPv6 > > > > At the moment, finding equipment that support IPv6 is the > biggest road block. > > What kind of equipment are you looking for? Current desktop > OSes support > IPv6. Most routers and switches do, but YMMV depending on > features needed. Most specifically, I need a firewall. - The Cisco ASA - Juniper Netscreen - Secure Computing Sidewinder - Fortinet - Checkpoint Obviously you will want to make sure the particular product and software rev is appropriate for v6, but they're out there. Regards, Mike _______________________________________________ ARIN-Discuss You are receiving this message because you are subscribed to the ARIN Discussion Mailing List (ARIN-discuss at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-discuss Please contact info at arin.net if you experience any issues. The contents of this email message and any attachments are confidential and are intended solely for the addressee. The information may also be legally privileged. This transmission is sent in trust for the sole purpose of delivery to the intended recipient. If you have received this transmission in error; any use, reproduction or dissemination of this transmission is strictly prohibited. If you are not the intended recipient, please immediately notify the sender by reply email and delete this message and all associated attachments. From sweeny at indiana.edu Fri May 1 18:55:33 2009 From: sweeny at indiana.edu (Brent Sweeny) Date: Fri, 01 May 2009 18:55:33 -0400 Subject: [arin-discuss] IPv6 Hurdles In-Reply-To: References: <478649.75043.qm@web63307.mail.re1.yahoo.com><95ec7d042f84aa9ff6fdd3c9a92ba1ef49fb67c3@jcc.com><17838240D9A5544AAA5FF95F8D52031605EC165F@ad-exh01.adhost.lan> Message-ID: <49FB7DE5.3090309@indiana.edu> other relevant questions for such appliances even if they do v6 at all: do they do v6 in hardware or software? how large an upstream pipe can they handle? On 5/1/2009 5:55 PM, Ric Moseley wrote: > I do IPv6 on both the Cisco ASA and Fortinet Fortigate and it works just > fine. The Fortinet has GUI support while the ASA is command line only. > > Thanks. > > Ric. > > -----Original Message----- > From: arin-discuss-bounces at arin.net > [mailto:arin-discuss-bounces at arin.net] On Behalf Of Michael K. Smith - > Adhost > Sent: Friday, May 01, 2009 4:41 PM > To: Keith W. Hare; Lee Howard; arin-discuss at arin.net > Subject: Re: [arin-discuss] IPv6 Hurdles > >>> 1. Finding supported equipment that supports IPv6 >>> >>> At the moment, finding equipment that support IPv6 is the >> biggest road block. >> >> What kind of equipment are you looking for? Current desktop >> OSes support >> IPv6. Most routers and switches do, but YMMV depending on >> features needed. > > Most specifically, I need a firewall. > > - The Cisco ASA > - Juniper Netscreen > - Secure Computing Sidewinder > - Fortinet > - Checkpoint > > Obviously you will want to make sure the particular product and software > rev is appropriate for v6, but they're out there. > > Regards, > > Mike > > _______________________________________________ > ARIN-Discuss > You are receiving this message because you are subscribed to > the ARIN Discussion Mailing List (ARIN-discuss at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-discuss > Please contact info at arin.net if you experience any issues. > > > The contents of this email message and any attachments are confidential > and are intended solely for the addressee. The information may also be > legally privileged. This transmission is sent in trust for the sole > purpose of delivery to the intended recipient. If you have received this > transmission in error; any use, reproduction or dissemination of this > transmission is strictly prohibited. If you are not the intended > recipient, please immediately notify the sender by reply email and > delete this message and all associated attachments. > _______________________________________________ > ARIN-Discuss > You are receiving this message because you are subscribed to > the ARIN Discussion Mailing List (ARIN-discuss at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-discuss > Please contact info at arin.net if you experience any issues. From mksmith at adhost.com Fri May 1 20:42:20 2009 From: mksmith at adhost.com (Michael K. Smith) Date: Fri, 01 May 2009 17:42:20 -0700 Subject: [arin-discuss] IPv6 Hurdles In-Reply-To: <49FB7DE5.3090309@indiana.edu> Message-ID: On 5/1/09 3:55 PM, "Brent Sweeny" wrote: > other relevant questions for such appliances even if they do v6 at all: do > they do v6 in hardware or software? how large an upstream pipe can they > handle? > These are the types of questions that we all (should) ask about our IPv4 applications/devices as well, so I hope it's not a show-stopper for IPv6. The product documentation from the various vendors on v6 is pretty deep, although not as deep as it will be when it's as ubiquitous as v4. But, putting it into production now and working with the vendor to iron out bugs and limitations is a better idea than waiting until you have to install the gear because there are no v4 addresses left. Regards, Mike From Matthew.Wilder at telus.com Wed May 6 10:43:40 2009 From: Matthew.Wilder at telus.com (Matthew Wilder) Date: Wed, 6 May 2009 08:43:40 -0600 Subject: [arin-discuss] IPv6 End User Assignments Message-ID: I have a question about subnet size for end user sites (and a few thoughts as well). What size of IPv6 subnet would you imagine an ADSL customer (consumer, not business) would get from their ISP? The NRPM actually has nifty guidelines around subnet assignment here: /64 when it is known that one and only one subnet is needed /56 for small sites, those expected to need only a few subnets over the next 5 years. /48 for larger sites I would assume that with the average Joe ADSL user, one subnet is enough. Whether or not an ISP would make that assumption in their provisioning of the service might be another question. Either way, I would bet that a /64 would suffice for 99% of users. I can see value in assigning a /56 to every user so that they can subnet to their hearts' content to save any trouble of renumbering down the road, not that an average consumer would have a lot of renumbering to do. That said, I was a little surprised to see on the slashdot article about the ARIN letter (http://tech.slashdot.org/article.pl?sid=09/04/30/2051235&art_pos=2) that a comment came out suggesting every household would have a /48 assigned to it. What was more surprising is that no comments surfaced to correct this claim. My understanding of /48 is along with the NRPM: that /48 subnets are for "larger sites". Not many consumers would use much of their 65,536 /64 subnets in a /48 (at least in my estimation). This got me to do some exploring. I know that French telcos have already got IPv6 available for their ADSL customers. So with the help of Google translation, I got the following page from a telco called Nerim: http://translate.google.com/translate?hl=en&sl=fr&u=http://www.nerim.fr/ipv6&ei=iaEASrPINZritAPxjqX-BQ&sa=X&oi=translate&resnum=1&ct=result&prev=/search%3Fq%3Dnerim%2Bipv6%26hl%3Den%26rls%3Dcom.microsoft:en-US If you read near the bottom of the translated text, you will see "For access, IPv6 allocation is a / 48..." A /48 for a consumer? This made me curious to see what RIPE NCC says about end user assignments. They have similar language about the /64 being the minimum, in the case that no subnetting is required. They skip over /56 (which makes me appreciate the ARIN policy) directly to /48. They leave it to the LIR and ISP to determine what size of assignments to make for end sites. So, all this back to the original question: What kind of IPv6 subnet would YOU expect a North American ISP to assign to their residential ADSL customer? Kindly, Matthew Wilder matthew.wilder at telus.com From berger at shout.net Wed May 6 11:05:03 2009 From: berger at shout.net (Mike Berger) Date: Wed, 06 May 2009 10:05:03 -0500 Subject: [arin-discuss] IPv6 End User Assignments In-Reply-To: References: Message-ID: <4A01A71F.8070205@shout.net> I would expect a North American ISP to allocate a single IPv6 address and charge a huge fee for a subnet for their residential ADSL customers. Matthew Wilder wrote: > I have a question about subnet size for end user sites (and a few thoughts as well). > > What size of IPv6 subnet would you imagine an ADSL customer (consumer, not business) would get from their ISP? The NRPM actually has nifty guidelines around subnet assignment here: > > /64 when it is known that one and only one subnet is needed > /56 for small sites, those expected to need only a few subnets over the next 5 years. > /48 for larger sites > ... > > So, all this back to the original question: > What kind of IPv6 subnet would YOU expect a North American ISP to assign to their residential ADSL customer? > From michael.dillon at bt.com Wed May 6 11:30:27 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 6 May 2009 16:30:27 +0100 Subject: [arin-discuss] IPv6 End User Assignments In-Reply-To: Message-ID: <28E139F46D45AF49A31950F88C497458F86FF6@E03MVZ2-UKDY.domain1.systemhost.net> > What size of IPv6 subnet would you imagine an ADSL customer > (consumer, not business) would get from their ISP? The NRPM > actually has nifty guidelines around subnet assignment here: > > /64 when it is known that one and only one subnet is needed > /56 for small sites, those expected to need only a few > subnets over the next 5 years. > /48 for larger sites > > I would assume that with the average Joe ADSL user, one > subnet is enough. Whether or not an ISP would make that > assumption in their provisioning of the service might be > another question. An ISP would be very stupid to make that assumption. Let's be clear here. The English language definition of the word "assume" is to accept without verification or proof. In other words, when you don't know something, then you might make an assumption in the absence of knowledge, or not. If the ISP does not "know" that there will only be one subnet required, but just "assumes" that only one will be required, then the ISP is not following the policy. In fact the policy is rather poorly written. It should start by saying that a normal assignment is a /48. If the site is a small site expected to need only a few subnets over the next 5 years, then a /56 assignment MAY be made. A /64 assignment should only be made when it is known that one and only one subnet is required. A good example of sites with a /64 assignment would be a remote repeater station on top of a mountain or a fishing boat, or a kiosk at a trade show. > That said, I was a little surprised to see on the slashdot > article about the ARIN letter > (http://tech.slashdot.org/article.pl?sid=09/04/30/2051235&art_ > pos=2) that a comment came out suggesting every household > would have a /48 assigned to it. What was more surprising is > that no comments surfaced to correct this claim. That's because most ISPs will indeed be assigning a /48 to all of their consumer customers. Only a few larger ISPs with very large consumer subscriber bases, who are concerned with meeting the HD ratio in 5 years when their /20 allocation runs out, will be assigning consumers with a /56. > My understanding of /48 is along with the NRPM: that /48 > subnets are for "larger sites". Not many consumers would use > much of their 65,536 /64 subnets in a /48 (at least in my estimation). Your understanding is wrong probably because you are looking in the wrong places. This is not a policy issue, it is related to the design of the IPv6 architecture. You will find better information in RFCs and in books or presentations about IPv6. The ARIN wiki has many references to introductory materials as well as a page on addressing based on the distilled knowledge of several ISPs on the NANOG list. > So, all this back to the original question: > What kind of IPv6 subnet would YOU expect a North American > ISP to assign to their residential ADSL customer? /48 as per standard. --Michael Dillon From eric at grokthis.net Wed May 6 11:47:38 2009 From: eric at grokthis.net (Eric Windisch) Date: Wed, 6 May 2009 11:47:38 -0400 Subject: [arin-discuss] IPv6 End User Assignments In-Reply-To: <4A01A71F.8070205@shout.net> References: <4A01A71F.8070205@shout.net> Message-ID: <4C295947-6294-4708-AF39-386435A967F9@grokthis.net> On May 6, 2009, at 11:05 AM, Mike Berger wrote: > I would expect a North American ISP to allocate a single IPv6 address > and charge a huge fee for a subnet for their residential ADSL > customers. The minimum reasonable size would be a /64 (a single address would be a /128). It should be noted that a /64 doesn't entirely exclude customers from subnetting, but it will cause problems with router advertisement and other features. I don't think that anyone with experience deploying IPv6 would argue for subnets smaller than a /64, so its not worth discussing further. Another thought I have: what about routing? Right now, while you might not see a lot of users configuring subnets at home, there is a much larger number of "power users" that configure their own routers and firewalls for purposes besides simply running NAT. With IPv6, if an ISP only provides a bridged /64, customer's machines will connect directly to the ISP and will not pass through any customer-premises routing equipment. At best, customers could configure a layer-3 switch or bridging firewall. To me, the logical deployment seems to provide a /128 address, and route a /64, /56, or /48 into that. My fear is that this will be hidden inside a cable modem or other CPE that the customer won't have direct access to, similar to how it is currently, except that currently we at least have NAT and can avoid proper routing. A /128 address should be given directly to the customer for routing their subnet through their own devices. Regards, Eric Windisch From bicknell at ufp.org Wed May 6 12:03:24 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 6 May 2009 12:03:24 -0400 Subject: [arin-discuss] IPv6 End User Assignments In-Reply-To: References: Message-ID: <20090506160324.GA19965@ussenterprise.ufp.org> Simple answers. All original IPv6 documentation said a /48 per customer (more or less). The ARIN region has been the most agressive at documenting exceptions to this rule. For instance it was pointed out providing more than a /128 to a dial-up user may not really make sense, or if you're a colo doing all the routing for folks you might well supply a /64 to a customer as you route them a VLAN, rather than /48's. The output is the rules you now see in the NRPM. I think there is still an expectation that if you're providind DSL/Cable etc high speed service to home users they will get something that can be subnetted, e.g. a /56 at a minimum. In a message written on Wed, May 06, 2009 at 08:43:40AM -0600, Matthew Wilder wrote: > What size of IPv6 subnet would you imagine an ADSL customer (consumer, not business) would get from their ISP? The NRPM actually has nifty guidelines around subnet assignment here: > > /64 when it is known that one and only one subnet is needed > /56 for small sites, those expected to need only a few subnets over the next 5 years. > /48 for larger sites Note that the text you site is from 6.5.4.1, https://www.arin.net/policy/nrpm.html#six541 They are guidelines. The first paragraph still allows you to assign a /48 to every customer. If you want to go that route for your business, you can still do that. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ From kreg at directcom.com Wed May 6 12:21:04 2009 From: kreg at directcom.com (Kreg Roenfeldt) Date: Wed, 06 May 2009 10:21:04 -0600 Subject: [arin-discuss] IPv6 End User Assignments In-Reply-To: <4C295947-6294-4708-AF39-386435A967F9@grokthis.net> References: <4A01A71F.8070205@shout.net> <4C295947-6294-4708-AF39-386435A967F9@grokthis.net> Message-ID: <4A01B8F0.3060108@directcom.com> Eric Windisch wrote: > To me, the logical deployment seems to provide a /128 address, and > route a /64, /56, or /48 into that. My fear is that this will be > hidden inside a cable modem or other CPE that the customer won't have > direct access to, similar to how it is currently, except that > currently we at least have NAT and can avoid proper routing. A /128 > address should be given directly to the customer for routing their > subnet through their own devices. Agreed. Lazy deployed ISP's in my area have often launched broadband to residential homes and businesses by being the gateway for the customer and requiring only a bridged device and a customer to have a switch for adding additional IP's. This causes very messing layouts. Point to Point end connections (/32 in ipv4), on ATM, PPP, PPPoE, etc, to each customer providing 1 IP address per account, and optional additional service for routing subnets to that 1 IP representing the customer is a very clean way to deploy, bill, and adjust address space. Anything else seems wasteful and requiring prediction of future. Deploying as a "standard", a subnet every time seems wasteful and defeating the purpose of why are are having to move to a 128bit IP system. I know 99% of my customers won't have a clue what the word subnet is. -=Kreg From berger at shout.net Wed May 6 12:40:13 2009 From: berger at shout.net (Mike Berger) Date: Wed, 06 May 2009 11:40:13 -0500 Subject: [arin-discuss] IPv6 End User Assignments In-Reply-To: <4C295947-6294-4708-AF39-386435A967F9@grokthis.net> References: <4A01A71F.8070205@shout.net> <4C295947-6294-4708-AF39-386435A967F9@grokthis.net> Message-ID: <4A01BD6D.9020706@shout.net> My experience with U.S. ISP's is that "reasonable" doesn't enter into the equation. They like to charge a premium for anything beyond the most basic service. When you consider how ISP's connect their clients, they could certainly offer single addresses to their customers. We have fiber from two providers. A couple of years ago we'd be part of the Sonet ring and de-mux on site. Now we just have a fiber connection to a transceiver that runs from their switch. The original question wasn't about what was reasonable, but what U.S. ISP's would most likely do. They're not the same thing. Eric Windisch wrote: > > On May 6, 2009, at 11:05 AM, Mike Berger wrote: > >> I would expect a North American ISP to allocate a single IPv6 address >> and charge a huge fee for a subnet for their residential ADSL customers. > > The minimum reasonable size would be a /64 (a single address would be > a /128). It should be noted that a /64 doesn't entirely exclude > customers from subnetting, but it will cause problems with router > advertisement and other features. I don't think that anyone with > experience deploying IPv6 would argue for subnets smaller than a /64, > so its not worth discussing further. > From bicknell at ufp.org Wed May 6 12:42:33 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 6 May 2009 12:42:33 -0400 Subject: [arin-discuss] IPv6 End User Assignments In-Reply-To: <4A01B8F0.3060108@directcom.com> References: <4A01A71F.8070205@shout.net> <4C295947-6294-4708-AF39-386435A967F9@grokthis.net> <4A01B8F0.3060108@directcom.com> Message-ID: <20090506164233.GA23363@ussenterprise.ufp.org> In a message written on Wed, May 06, 2009 at 10:21:04AM -0600, Kreg Roenfeldt wrote: > Deploying as a "standard", a subnet every time seems wasteful and > defeating the purpose of why are are having to move to a 128bit IP > system. I know 99% of my customers won't have a clue what the word > subnet is. You might want to look at DHCP-PD, DHCP Prefix Delegation. The idea is that while your customers won't have a clue what a subnet is, their devices may; and want to use them. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From aaronh at bind.com Wed May 6 12:56:45 2009 From: aaronh at bind.com (Aaron Hughes) Date: Wed, 6 May 2009 09:56:45 -0700 Subject: [arin-discuss] IPv6 End User Assignments In-Reply-To: <4A01B8F0.3060108@directcom.com> References: <4A01A71F.8070205@shout.net> <4C295947-6294-4708-AF39-386435A967F9@grokthis.net> <4A01B8F0.3060108@directcom.com> Message-ID: <20090506165645.GG67888@trace.bind.com> US population is roughly 300 million. A /19 would cover 536,870,912 /48s A /27 would cover 536,870,912 /56s 7 billion in the world. A /15 would cover 8,589,934,592 /48s A /23 would cover 8,589,934,592 /56s. Number of total Internet users in the world roughly 1.5 billion or 20% of the population. Number of total Internet users in the US roughly 220 million. Let's say you are Comcast.. ~ 25 million customers. Worst cast you are looking at a /23 to give each one a /48, or roughly best case a /39 for 2x/64s per customer. This is not a repeat of v4. IPv4 ISPs gave a single host to the outside interface of the CPE AND some flavor of space in (RFC1918) 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 for their inside interface. If we implement NAT in v6, we will stop progress with end-to-end application development and make the same silly mistakes we made with v4. The mistake was not wasting space but rather not making the leap to IPv6 when we identified the potential for growth so many years ago. Instead we focused on CIDR/VLSM and NATing everything we could to extend the life of a dying protocol. It is perfectly reasonable to have standard assignment sizes to create an appropriate customer expectation. Your customers do not need to know what a subnet is. If the standard was, for example, to assign a /64 to the WAN and /64 to the LAN with SLAAC enabled, the customer behaves the same way they do today. Those who request more space know what they are doing (generally speaking). Cheers, Aaron On Wed, May 06, 2009 at 10:21:04AM -0600, Kreg Roenfeldt wrote: > > > Eric Windisch wrote: > > To me, the logical deployment seems to provide a /128 address, and > > route a /64, /56, or /48 into that. My fear is that this will be > > hidden inside a cable modem or other CPE that the customer won't have > > direct access to, similar to how it is currently, except that > > currently we at least have NAT and can avoid proper routing. A /128 > > address should be given directly to the customer for routing their > > subnet through their own devices. > Agreed. Lazy deployed ISP's in my area have often launched broadband to > residential homes and businesses by being the gateway for the customer > and requiring only a bridged device and a customer to have a switch for > adding additional IP's. This causes very messing layouts. > > Point to Point end connections (/32 in ipv4), on ATM, PPP, PPPoE, etc, > to each customer providing 1 IP address per account, and optional > additional service for routing subnets to that 1 IP representing the > customer is a very clean way to deploy, bill, and adjust address space. > Anything else seems wasteful and requiring prediction of future. > > Deploying as a "standard", a subnet every time seems wasteful and > defeating the purpose of why are are having to move to a 128bit IP > system. I know 99% of my customers won't have a clue what the word > subnet is. > > -=Kreg > -- > ARIN-Discuss > You are receiving this message because you are subscribed to > the ARIN Discussion Mailing List (ARIN-discuss at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-discuss > Please contact info at arin.net if you experience any issues. -- Aaron Hughes aaronh at bind.com (703) 244-0427 Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8 http://www.bind.com/ From michael.dillon at bt.com Wed May 6 13:09:09 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 6 May 2009 18:09:09 +0100 Subject: [arin-discuss] IPv6 End User Assignments In-Reply-To: <4C295947-6294-4708-AF39-386435A967F9@grokthis.net> Message-ID: <28E139F46D45AF49A31950F88C497458F87152@E03MVZ2-UKDY.domain1.systemhost.net> > The minimum reasonable size would be a /64 (a single address > would be a /128). It should be noted that a /64 doesn't > entirely exclude customers from subnetting, but it will cause > problems with router advertisement and other features. Complicated! > To me, the logical deployment seems to provide a /128 > address, and route a /64, /56, or /48 into that. Even more complicated! Why not keep it simple and just assign each customer a /48. Or if you know that you are in risk of an HD ratio problem then give consumer customers a /56. Simple! When new customers move into town and sign up with you, their existinge equipment and home setup works just the same as it always has, just the /48 prefix changes. --Michael Dillon From michael.dillon at bt.com Wed May 6 13:16:39 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 6 May 2009 18:16:39 +0100 Subject: [arin-discuss] IPv6 End User Assignments In-Reply-To: <4A01B8F0.3060108@directcom.com> Message-ID: <28E139F46D45AF49A31950F88C497458F87172@E03MVZ2-UKDY.domain1.systemhost.net> > Deploying as a "standard", a subnet every time seems wasteful > and defeating the purpose of why are are having to move to a > 128bit IP system. I know 99% of my customers won't have a > clue what the word subnet is. I can guarantee you that 100% of your customers will know the meaning of: We can't install our home media system into your house because of the wierd setup that your ISP has. Of course, if you switch ISPs then there won't be any problems. We have customers on A-net, X-net and Z-net that work perfectly fine. If you want to reinvent the wheel, you go right ahead. --Michael Dillon From Matthew.Wilder at telus.com Wed May 6 13:28:47 2009 From: Matthew.Wilder at telus.com (Matthew Wilder) Date: Wed, 6 May 2009 11:28:47 -0600 Subject: [arin-discuss] IPv6 End User Assignments In-Reply-To: <20090506165645.GG67888@trace.bind.com> References: <4A01A71F.8070205@shout.net> <4C295947-6294-4708-AF39-386435A967F9@grokthis.net> <4A01B8F0.3060108@directcom.com> <20090506165645.GG67888@trace.bind.com> Message-ID: This is where it gets interesting. I doubt the worst case is a /23. Remember, IPv6 has so many bits for the very purpose of clean summarization and easy subnetting. Comcast might want to regionalize their subnetting. And then within each region, they might want to have a nice big block for each edge router so they don't have to constantly add address resources to the router. All of a sudden, instead of assuming a 90% utilization of that block (which is heinously unreasonable and inconsistent with IPv6 intentions) you are looking at maybe 20 - 30% utilization at the /48 assignments. Now they need probably a /21 for those customers. This gets this sort of ISP into the hairy edge of what the HD ratio allows in the best case. Assuming a /48 assignment to an end user counts as 100% utilization of the entire /48 subnet, then they will probably squeak through on the Threshold (https://www.arin.net/policy/nrpm.html#six7). And this discussion here is exactly why I originally through out the question. Why would an ISP assign a /48 so that a consumer can have two large layers of subnetting (16 bits of subnet address to be exact) at the expense of their own routing and summarization? MW Aaron Hughes wrote: > US population is roughly 300 million. > A /19 would cover 536,870,912 /48s > A /27 would cover 536,870,912 /56s > > 7 billion in the world. > A /15 would cover 8,589,934,592 /48s > A /23 would cover 8,589,934,592 /56s. > > Number of total Internet users in the world roughly 1.5 billion or 20% of > the population. > Number of total Internet users in the US roughly 220 million. > > Let's say you are Comcast.. ~ 25 million customers. Worst cast you are > looking at a /23 to give each one a /48, or roughly best case a /39 for 2x/64s > per customer. > > This is not a repeat of v4. > > IPv4 ISPs gave a single host to the outside interface of the CPE AND some > flavor of space in (RFC1918) 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 for > their inside interface. If we implement NAT in v6, we will stop progress > with end-to-end application development and make the same silly mistakes we > made with v4. The mistake was not wasting space but rather not making the > leap to IPv6 when we identified the potential for growth so many years ago. > Instead we focused on CIDR/VLSM and NATing everything we could to extend the > life of a dying protocol. > > It is perfectly reasonable to have standard assignment sizes to create an > appropriate customer expectation. Your customers do not need to know what > a subnet is. If the standard was, for example, to assign a /64 to the WAN > and /64 to the LAN with SLAAC enabled, the customer behaves the same way > they do today. Those who request more space know what they are doing > (generally speaking). > > Cheers, > Aaron From tedm at ipinc.net Wed May 6 13:53:24 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 6 May 2009 10:53:24 -0700 Subject: [arin-discuss] Some data relating to IPv4 address exhaustion (or not) In-Reply-To: <4A017CB6.4040503@cisco.com> References: <49FF15ED.4070902@arin.net><70DE64CEFD6E9A4EB7FAF3A06314106601B4B0AF@mail><49FF4A18.90503@matthew.at> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0B0@mail> <81A2DDDAA9A24CCD8055A0227A6F3F13@tedsdesk> <70DE64CEFD6E9A4EB7FAF3A06314106601B4B0C1@mail> <412B07CDC53F4AA9B44AD9DAECF9843D@tedsdesk> <4A017CB6.4040503@cisco.com> Message-ID: <7B3806B2AB0A46B2B5763BC3BBF5EFCE@tedsdesk> In simple terms, yes. In my opinion there are other, more accurate, controlling variables in the equation of IP address consumption, SOME of these variables are also controlling variables of world economic growth. It is like saying that US auto ownership is a controlling variable of US oil consumption. There is a casual relationship there but I think in the overall analysis, both those figures track US economic activity more than they track each other. If you want to play with this, here's some suggestions of controlling variables: Growth of networkable hosts - this is the count of all networkable hosts in the world at any given time and is easily estimated by graphing the uptake of MAC addresses. Distribution of networkable hosts - this is the density of networkable hosts in a given area. The idea here is that just because a host has a network interface, it is not necessarly plugged into anything and it takes a critical mass of hosts in a given "cultural group" to ignite the demand for Internet connectivity. You could estimate this figure by assuming that, say, today 80% of all networkable hosts exist in a cultural group that has reached critical mass, and developing a historical graph. You could also divide up the world into areas and count the number of routers on the Internet in those areas. I say "cultural group" because it's obvious if, for example, a person is a member of a culture which doesn't have much of interest on the Internet (Amish perhaps?) they might have a computer but they likely wouldn't have interest in connecting it to the Internet. They would more likely be interested in connecting it to an internal network like a corporate network or something which wouldn't demand connectivity. Type of networkable hosts - some hosts like PC's running Windows or Mac's running MacOS demand full time Internet connectivity for patch updates, and are most likely to be connected to the Internet. Some hosts, like a network print server, may spend their entire production life never sending a packet to the Internet. The distribution figures of various host types can be roughly estimated by looking at cell network expansion (number of cell towers, since smart phones demand MAC addresses but seldom use public IP addresses, and smartphone use is a percentage of all cell phone use) computer sales, and MAC address uptake. Location of host growth. Some areas of the world are growing in IPv6 demand much more than North America and are not growing in IPv4 demand. Length if time networkable hosts are in service in a given area - this is the idea that the longer a "cultural group" of networkable hosts are in service, the more likely that they will connect. My gut feeling, though, is that the reason we are seeing a rolloff of IPv4 uptake is that the largest consumers of IPv4 - the cellular networks - commenced shifting to IPv6 several years ago, and I am guessing that the very last IPv4 block that was handed out to a cell network for assignment to phones was handed out in 2008. The $64,000 question, though, is what are the other large consumers of IPv4 planning on doing? I'm thinking specifically of the cable TV networks but there's also the wireless and DSL people too. They certainly see IPv4-runout getting closer and closer and clearly they will have to shift to IPv6. If they wait until the last /8 is assigned then shift, runout will happen more quickly than if they shift a year or so in advance. Recall I posted a week ago that I think there's a good chance that IPv4 runout will not be a single, cataclysmic event that will happen on a single date, but will be more gradual. For example, a common myth is that the automobile made the horse drawn carriage obsolete and signaled the end of buggy whip manufacture. In actual fact, there are still buggy whip manufacturers today. Horse drawn carriage manufacturing didn't die at a single date - it was a process that took years for carriage & buggy whip manufacture to die down to the niche market it is today. (people love to talk about similar shifts like the introduction of electricity and introduction of the telephone as happening with lightning speed when they happened, but those are myths, too) Note that I've set followups to arin-discuss Ted > -----Original Message----- > From: Eliot Lear [mailto:lear at cisco.com] > Sent: Wednesday, May 06, 2009 5:04 AM > To: Ted Mittelstaedt > Cc: 'arin ppml'; William Lehr > Subject: Some data relating to IPv4 address exhaustion (or not) > > Ted, > > Here are some interesting data points for this group to consider. > According to the U.N., world economic growth dropped from 3.5-4% in > 2003-2007 to 2.5% in 2008, and the prediction is for around > 1% growth in 2009. At the same time, Geoff Huston's numbers > have been shifting to the right. In the case of IANA the > number has shifted out 6 months in 6 months. We have not > seen quite the same shift for RIR numbers, however. Is world > economic growth a controlling variable in the equation of IP > address consumption, or merely a coincidence, and how can we tell? > > Eliot > From eric at grokthis.net Wed May 6 13:55:31 2009 From: eric at grokthis.net (Eric Windisch) Date: Wed, 6 May 2009 13:55:31 -0400 Subject: [arin-discuss] IPv6 End User Assignments In-Reply-To: <28E139F46D45AF49A31950F88C497458F87152@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458F87152@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <0B90C2EF-47B7-4D75-8827-93CA0B8B4F5E@grokthis.net> > >> To me, the logical deployment seems to provide a /128 >> address, and route a /64, /56, or /48 into that. > Even more complicated! > Why not keep it simple and just assign each customer a > /48. Or if you know that you are in risk of an HD ratio > problem then give consumer customers a /56. It is "just" a /48 assignment, but it is routed through a /128, as opposed to bridged to the customer. If the traffic was bridged, there certainly wouldn't be a whole lot of subnetting happening at the residential level because Layer-3 switches aren't very affordable. Do you really want to have the CPE be nothing but a switch? Surely, it would be simple, and it would allow customers to operate with no more equipment than they already own. However, it would come at a huge expense to the customer's functionality. The methodology of routing through a /128 would be quite similar to how IPv4 is being deployed, except that it would now be visible on the residential customer's router as it is already on commercial IPv4 deployments. If you are afraid of changing the methodology, I don't see why you would want to take the ability of a customer to have a router, something that customers are already familiar with owning and installing, even at a residential level, and forcing them to have nothing more complicated than a switch? I know that Layer-3 switching can nullify much of my argument here, and perhaps that is both a good thing and a reason not to bother with properly routing subnets into the CPE. Maybe in the 5 or 10 year plan, this will be an affordable option and preferable on the residential level? Right now, though, this is nothing more than a dream (but then again, so are residential IPv6 deployments) Regards, Eric Windisch From aaronh at bind.com Wed May 6 13:59:11 2009 From: aaronh at bind.com (Aaron Hughes) Date: Wed, 6 May 2009 10:59:11 -0700 Subject: [arin-discuss] IPv6 End User Assignments In-Reply-To: References: <4A01A71F.8070205@shout.net> <4C295947-6294-4708-AF39-386435A967F9@grokthis.net> <4A01B8F0.3060108@directcom.com> <20090506165645.GG67888@trace.bind.com> Message-ID: <20090506175911.GH67888@trace.bind.com> Matthew, You are highly likely correct. Regional aggregation will be implemented by any reasonable ISP. Also, if ISPs did assign /48s to each customer your math is correct, each ISP of this massive size would need a /21ish. Also, I agree a /48 is excessive for each customer. For a moment we should separate policy from operations. As architects in the planning phase of a v6 roll-out we get to plan for company needs, customer needs, aggregation, reachability, scalability, etc etc etc. One of the aspects we should all evaluate is wasting space. When I rolled out v6 to my customers, I made the company policy decision to assign /64s to customers by default and /48s to those who requested more than one subnet. This made it rather easy to have 2 pools of aggregatable regional space for customer assignments. The company policy / network architecture fits within certain, what I will call, ARIN guidelines in that it does not violate ARIN policy. Policy has never dictated operational practice. That being said, policy should _allow_ for an implementation that requires /48 assignments to the LIRs respective customers. There are implementations where this makes sense. It is highly unlikely that very large ISPs will be assigning 48s to each customer as it would be a waste of space. This list, just like Planing / Design / Architecture / Operations groups are full of opinions about how things should be implemented. Time will reveal best practices and policies will get updated to reflect them as long as the operational community is involved in the policy process. I am involved in many v6 implementations and none of them assign 48s by default. Cheers, Aaron On Wed, May 06, 2009 at 11:28:47AM -0600, Matthew Wilder wrote: > This is where it gets interesting. I doubt the worst case is a /23. Remember, IPv6 has so many bits for the very purpose of clean summarization and easy subnetting. > > Comcast might want to regionalize their subnetting. And then within each region, they might want to have a nice big block for each edge router so they don't have to constantly add address resources to the router. All of a sudden, instead of assuming a 90% utilization of that block (which is heinously unreasonable and inconsistent with IPv6 intentions) you are looking at maybe 20 - 30% utilization at the /48 assignments. Now they need probably a /21 for those customers. > > This gets this sort of ISP into the hairy edge of what the HD ratio allows in the best case. Assuming a /48 assignment to an end user counts as 100% utilization of the entire /48 subnet, then they will probably squeak through on the Threshold (https://www.arin.net/policy/nrpm.html#six7). > > And this discussion here is exactly why I originally through out the question. Why would an ISP assign a /48 so that a consumer can have two large layers of subnetting (16 bits of subnet address to be exact) at the expense of their own routing and summarization? > > MW > > > Aaron Hughes wrote: > > US population is roughly 300 million. > > A /19 would cover 536,870,912 /48s > > A /27 would cover 536,870,912 /56s > > > > 7 billion in the world. > > A /15 would cover 8,589,934,592 /48s > > A /23 would cover 8,589,934,592 /56s. > > > > Number of total Internet users in the world roughly 1.5 billion or 20% of > > the population. > > Number of total Internet users in the US roughly 220 million. > > > > Let's say you are Comcast.. ~ 25 million customers. Worst cast you are > > looking at a /23 to give each one a /48, or roughly best case a /39 for 2x/64s > > per customer. > > > > This is not a repeat of v4. > > > > IPv4 ISPs gave a single host to the outside interface of the CPE AND some > > flavor of space in (RFC1918) 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 for > > their inside interface. If we implement NAT in v6, we will stop progress > > with end-to-end application development and make the same silly mistakes we > > made with v4. The mistake was not wasting space but rather not making the > > leap to IPv6 when we identified the potential for growth so many years ago. > > Instead we focused on CIDR/VLSM and NATing everything we could to extend the > > life of a dying protocol. > > > > It is perfectly reasonable to have standard assignment sizes to create an > > appropriate customer expectation. Your customers do not need to know what > > a subnet is. If the standard was, for example, to assign a /64 to the WAN > > and /64 to the LAN with SLAAC enabled, the customer behaves the same way > > they do today. Those who request more space know what they are doing > > (generally speaking). > > > > Cheers, > > Aaron -- Aaron Hughes aaronh at bind.com (703) 244-0427 Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8 http://www.bind.com/ From jay at impulse.net Wed May 6 15:23:54 2009 From: jay at impulse.net (Jay Hennigan) Date: Wed, 06 May 2009 12:23:54 -0700 Subject: [arin-discuss] IPv6 End User Assignments In-Reply-To: <0B90C2EF-47B7-4D75-8827-93CA0B8B4F5E@grokthis.net> References: <28E139F46D45AF49A31950F88C497458F87152@E03MVZ2-UKDY.domain1.systemhost.net> <0B90C2EF-47B7-4D75-8827-93CA0B8B4F5E@grokthis.net> Message-ID: <4A01E3CA.5040501@impulse.net> > It is "just" a /48 assignment, but it is routed through a /128, as > opposed to bridged to the customer. If the traffic was bridged, there > certainly wouldn't be a whole lot of subnetting happening at the > residential level because Layer-3 switches aren't very affordable. That's what link-local is for. The /48 (or /56) isn't bridged. It's connected automagically via link-local addresses between the ISP edge and the CPE. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From kreg at directcom.com Wed May 6 15:44:31 2009 From: kreg at directcom.com (Kreg Roenfeldt) Date: Wed, 06 May 2009 13:44:31 -0600 Subject: [arin-discuss] IPv6 End User Assignments In-Reply-To: <4A01E3CA.5040501@impulse.net> References: <28E139F46D45AF49A31950F88C497458F87152@E03MVZ2-UKDY.domain1.systemhost.net> <0B90C2EF-47B7-4D75-8827-93CA0B8B4F5E@grokthis.net> <4A01E3CA.5040501@impulse.net> Message-ID: <4A01E89F.8030105@directcom.com> An HTML attachment was scrubbed... URL: From tedm at ipinc.net Wed May 6 16:37:33 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 6 May 2009 13:37:33 -0700 Subject: [arin-discuss] IPv6 End User Assignments In-Reply-To: <20090506175911.GH67888@trace.bind.com> References: <4A01A71F.8070205@shout.net><4C295947-6294-4708-AF39-386435A967F9@grokthis.net><4A01B8F0.3060108@directcom.com><20090506165645.GG67888@trace.bind.com> <20090506175911.GH67888@trace.bind.com> Message-ID: <934B1E52439543079E627040FBA75BCC@tedsdesk> Aaron, Was space-wasting the only reason you went with a /64 instead of a /48 or /56? For your single point customers, is this /64 intended for use on just a single PC? Such as for example a DSL customer with just a single PC plugged into a bridged DSL modem? Do you consider a customer who has a wireless router with 5-6 PC's on it as needing a subnet ie /48? Ted > -----Original Message----- > From: arin-discuss-bounces at arin.net > [mailto:arin-discuss-bounces at arin.net] On Behalf Of Aaron Hughes > Sent: Wednesday, May 06, 2009 10:59 AM > To: Matthew Wilder > Cc: arin-discuss at arin.net > Subject: Re: [arin-discuss] IPv6 End User Assignments > > Matthew, > > You are highly likely correct. Regional aggregation will be > implemented by any reasonable ISP. Also, if ISPs did assign > /48s to each customer your math is correct, each ISP of this > massive size would need a /21ish. Also, I agree a /48 is > excessive for each customer. > > For a moment we should separate policy from operations. > > As architects in the planning phase of a v6 roll-out we get > to plan for company needs, customer needs, aggregation, > reachability, scalability, etc etc etc. One of the aspects we > should all evaluate is wasting space. > > When I rolled out v6 to my customers, I made the company > policy decision to assign /64s to customers by default and > /48s to those who requested more than one subnet. This made > it rather easy to have 2 pools of aggregatable regional space > for customer assignments. The company policy / network > architecture fits within certain, what I will call, ARIN > guidelines in that it does not violate ARIN policy. Policy > has never dictated operational practice. > > That being said, policy should _allow_ for an implementation > that requires /48 assignments to the LIRs respective > customers. There are implementations where this makes sense. > It is highly unlikely that very large ISPs will be assigning > 48s to each customer as it would be a waste of space. > > This list, just like Planing / Design / Architecture / > Operations groups are full of opinions about how things > should be implemented. Time will reveal best practices and > policies will get updated to reflect them as long as the > operational community is involved in the policy process. > > I am involved in many v6 implementations and none of them > assign 48s by default. > > Cheers, > Aaron > > > On Wed, May 06, 2009 at 11:28:47AM -0600, Matthew Wilder wrote: > > This is where it gets interesting. I doubt the worst case > is a /23. Remember, IPv6 has so many bits for the very > purpose of clean summarization and easy subnetting. > > > > Comcast might want to regionalize their subnetting. And > then within each region, they might want to have a nice big > block for each edge router so they don't have to constantly > add address resources to the router. All of a sudden, > instead of assuming a 90% utilization of that block (which is > heinously unreasonable and inconsistent with IPv6 intentions) > you are looking at maybe 20 - 30% utilization at the /48 > assignments. Now they need probably a /21 for those customers. > > > > This gets this sort of ISP into the hairy edge of what the > HD ratio allows in the best case. Assuming a /48 assignment > to an end user counts as 100% utilization of the entire /48 > subnet, then they will probably squeak through on the > Threshold (https://www.arin.net/policy/nrpm.html#six7). > > > > And this discussion here is exactly why I originally > through out the question. Why would an ISP assign a /48 so > that a consumer can have two large layers of subnetting (16 > bits of subnet address to be exact) at the expense of their > own routing and summarization? > > > > MW > > > > > > Aaron Hughes wrote: > > > US population is roughly 300 million. > > > A /19 would cover 536,870,912 /48s > > > A /27 would cover 536,870,912 /56s > > > > > > 7 billion in the world. > > > A /15 would cover 8,589,934,592 /48s A /23 would cover > 8,589,934,592 > > > /56s. > > > > > > Number of total Internet users in the world roughly 1.5 > billion or > > > 20% of the population. > > > Number of total Internet users in the US roughly 220 million. > > > > > > Let's say you are Comcast.. ~ 25 million customers. Worst > cast you > > > are looking at a /23 to give each one a /48, or roughly > best case a > > > /39 for 2x/64s per customer. > > > > > > This is not a repeat of v4. > > > > > > IPv4 ISPs gave a single host to the outside interface of > the CPE AND > > > some flavor of space in (RFC1918) 10.0.0.0/8, 172.16.0.0/12, > > > 192.168.0.0/16 for their inside interface. If we > implement NAT in > > > v6, we will stop progress with end-to-end application development > > > and make the same silly mistakes we made with v4. The > mistake was > > > not wasting space but rather not making the leap to IPv6 > when we identified the potential for growth so many years ago. > > > Instead we focused on CIDR/VLSM and NATing everything we could to > > > extend the life of a dying protocol. > > > > > > It is perfectly reasonable to have standard assignment sizes to > > > create an appropriate customer expectation. Your customers do not > > > need to know what a subnet is. If the standard was, for > example, to > > > assign a /64 to the WAN and /64 to the LAN with SLAAC > enabled, the > > > customer behaves the same way they do today. Those who > request more > > > space know what they are doing (generally speaking). > > > > > > Cheers, > > > Aaron > -- > > Aaron Hughes > aaronh at bind.com > (703) 244-0427 > Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C > C6 B8 http://www.bind.com/ > _______________________________________________ > ARIN-Discuss > You are receiving this message because you are subscribed to > the ARIN Discussion Mailing List (ARIN-discuss at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-discuss > Please contact info at arin.net if you experience any issues. > From aaronh at bind.com Wed May 6 17:24:08 2009 From: aaronh at bind.com (Aaron Hughes) Date: Wed, 6 May 2009 14:24:08 -0700 Subject: [arin-discuss] IPv6 End User Assignments In-Reply-To: <934B1E52439543079E627040FBA75BCC@tedsdesk> References: <20090506175911.GH67888@trace.bind.com> <934B1E52439543079E627040FBA75BCC@tedsdesk> Message-ID: <20090506212408.GI67888@trace.bind.com> On Wed, May 06, 2009 at 01:37:33PM -0700, Ted Mittelstaedt wrote: > > Aaron, > > Was space-wasting the only reason you went with a /64 instead of > a /48 or /56? Yes. > For your single point customers, is this /64 intended for use on > just a single PC? Such as for example a DSL customer with just a single > PC plugged into a bridged DSL modem? /64 was for any customer with one broadcast domain, 1 to several machines. If they have multiple broadcast domains (more than one), they get a 48. 56 vs 64 was just a flip a coin decision to some extent. There was a ton of discussion on the topic and I just picked one and moved forward. At some point you just have to implement and get some real world experience. I did look at assigning something smaller than a 64 initially and tools turned out to be the deciding factor. Since all of my v4 tools such as allocations/assignments/router config/CRM/ERP/etc store the v4 address as 4 x INT(11), it was rather easy to convert hex to dec and store in the same tables. The mask in this case is also an INT(11). Adding the additional octets would have been much more effort. > Do you consider a customer > who has a wireless router with 5-6 PC's on it as needing a subnet > ie /48? No. a 64 should be fine for that kind of customer assuming all the objects are in the same broadcast domain (e.g. bridged mode on the wireless router). Cheers, Aaron > > Ted > > > > -----Original Message----- > > From: arin-discuss-bounces at arin.net > > [mailto:arin-discuss-bounces at arin.net] On Behalf Of Aaron Hughes > > Sent: Wednesday, May 06, 2009 10:59 AM > > To: Matthew Wilder > > Cc: arin-discuss at arin.net > > Subject: Re: [arin-discuss] IPv6 End User Assignments > > > > Matthew, > > > > You are highly likely correct. Regional aggregation will be > > implemented by any reasonable ISP. Also, if ISPs did assign > > /48s to each customer your math is correct, each ISP of this > > massive size would need a /21ish. Also, I agree a /48 is > > excessive for each customer. > > > > For a moment we should separate policy from operations. > > > > As architects in the planning phase of a v6 roll-out we get > > to plan for company needs, customer needs, aggregation, > > reachability, scalability, etc etc etc. One of the aspects we > > should all evaluate is wasting space. > > > > When I rolled out v6 to my customers, I made the company > > policy decision to assign /64s to customers by default and > > /48s to those who requested more than one subnet. This made > > it rather easy to have 2 pools of aggregatable regional space > > for customer assignments. The company policy / network > > architecture fits within certain, what I will call, ARIN > > guidelines in that it does not violate ARIN policy. Policy > > has never dictated operational practice. > > > > That being said, policy should _allow_ for an implementation > > that requires /48 assignments to the LIRs respective > > customers. There are implementations where this makes sense. > > It is highly unlikely that very large ISPs will be assigning > > 48s to each customer as it would be a waste of space. > > > > This list, just like Planing / Design / Architecture / > > Operations groups are full of opinions about how things > > should be implemented. Time will reveal best practices and > > policies will get updated to reflect them as long as the > > operational community is involved in the policy process. > > > > I am involved in many v6 implementations and none of them > > assign 48s by default. > > > > Cheers, > > Aaron > > > > > > On Wed, May 06, 2009 at 11:28:47AM -0600, Matthew Wilder wrote: > > > This is where it gets interesting. I doubt the worst case > > is a /23. Remember, IPv6 has so many bits for the very > > purpose of clean summarization and easy subnetting. > > > > > > Comcast might want to regionalize their subnetting. And > > then within each region, they might want to have a nice big > > block for each edge router so they don't have to constantly > > add address resources to the router. All of a sudden, > > instead of assuming a 90% utilization of that block (which is > > heinously unreasonable and inconsistent with IPv6 intentions) > > you are looking at maybe 20 - 30% utilization at the /48 > > assignments. Now they need probably a /21 for those customers. > > > > > > This gets this sort of ISP into the hairy edge of what the > > HD ratio allows in the best case. Assuming a /48 assignment > > to an end user counts as 100% utilization of the entire /48 > > subnet, then they will probably squeak through on the > > Threshold (https://www.arin.net/policy/nrpm.html#six7). > > > > > > And this discussion here is exactly why I originally > > through out the question. Why would an ISP assign a /48 so > > that a consumer can have two large layers of subnetting (16 > > bits of subnet address to be exact) at the expense of their > > own routing and summarization? > > > > > > MW > > > > > > > > > Aaron Hughes wrote: > > > > US population is roughly 300 million. > > > > A /19 would cover 536,870,912 /48s > > > > A /27 would cover 536,870,912 /56s > > > > > > > > 7 billion in the world. > > > > A /15 would cover 8,589,934,592 /48s A /23 would cover > > 8,589,934,592 > > > > /56s. > > > > > > > > Number of total Internet users in the world roughly 1.5 > > billion or > > > > 20% of the population. > > > > Number of total Internet users in the US roughly 220 million. > > > > > > > > Let's say you are Comcast.. ~ 25 million customers. Worst > > cast you > > > > are looking at a /23 to give each one a /48, or roughly > > best case a > > > > /39 for 2x/64s per customer. > > > > > > > > This is not a repeat of v4. > > > > > > > > IPv4 ISPs gave a single host to the outside interface of > > the CPE AND > > > > some flavor of space in (RFC1918) 10.0.0.0/8, 172.16.0.0/12, > > > > 192.168.0.0/16 for their inside interface. If we > > implement NAT in > > > > v6, we will stop progress with end-to-end application development > > > > and make the same silly mistakes we made with v4. The > > mistake was > > > > not wasting space but rather not making the leap to IPv6 > > when we identified the potential for growth so many years ago. > > > > Instead we focused on CIDR/VLSM and NATing everything we could to > > > > extend the life of a dying protocol. > > > > > > > > It is perfectly reasonable to have standard assignment sizes to > > > > create an appropriate customer expectation. Your customers do not > > > > need to know what a subnet is. If the standard was, for > > example, to > > > > assign a /64 to the WAN and /64 to the LAN with SLAAC > > enabled, the > > > > customer behaves the same way they do today. Those who > > request more > > > > space know what they are doing (generally speaking). > > > > > > > > Cheers, > > > > Aaron > > -- > > > > Aaron Hughes > > aaronh at bind.com > > (703) 244-0427 > > Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C > > C6 B8 http://www.bind.com/ > > _______________________________________________ > > ARIN-Discuss > > You are receiving this message because you are subscribed to > > the ARIN Discussion Mailing List (ARIN-discuss at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-discuss > > Please contact info at arin.net if you experience any issues. > > -- Aaron Hughes aaronh at bind.com (703) 244-0427 Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8 http://www.bind.com/ From tedm at ipinc.net Wed May 6 18:10:44 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 6 May 2009 15:10:44 -0700 Subject: [arin-discuss] IPv6 End User Assignments In-Reply-To: <20090506212408.GI67888@trace.bind.com> References: <20090506175911.GH67888@trace.bind.com> <934B1E52439543079E627040FBA75BCC@tedsdesk> <20090506212408.GI67888@trace.bind.com> Message-ID: What separates the customer's broadcast domains from yours? I assume there's a router at the customer (DSL modem, cable modem or whatever) and the /64 is on the customer side of the CPE. If that is the case, what is on your side of the CPE? Part of the /64 or a separate subnet? Ted > -----Original Message----- > From: Aaron Hughes [mailto:aaronh at bind.com] > Sent: Wednesday, May 06, 2009 2:24 PM > To: Ted Mittelstaedt > Cc: 'Matthew Wilder'; arin-discuss at arin.net > Subject: Re: [arin-discuss] IPv6 End User Assignments > > > On Wed, May 06, 2009 at 01:37:33PM -0700, Ted Mittelstaedt wrote: > > > > Aaron, > > > > Was space-wasting the only reason you went with a /64 > instead of a > > /48 or /56? > > Yes. > > > For your single point customers, is this /64 intended for use on > > just a single PC? Such as for example a DSL customer with just a > > single PC plugged into a bridged DSL modem? > > > /64 was for any customer with one broadcast domain, 1 to > several machines. If they have multiple broadcast domains > (more than one), they get a 48. 56 vs 64 was just a flip a > coin decision to some extent. There was a ton of discussion > on the topic and I just picked one and moved forward. At > some point you just have to implement and get some real world > experience. > > I did look at assigning something smaller than a 64 initially > and tools turned out to be the deciding factor. Since all of > my v4 tools such as allocations/assignments/router > config/CRM/ERP/etc store the v4 address as 4 x INT(11), it > was rather easy to convert hex to dec and store in the same > tables. The mask in this case is also an INT(11). Adding > the additional octets would have been much more effort. > > > Do you consider a customer > > who has a wireless router with 5-6 PC's on it as needing a > subnet ie > > /48? > > No. a 64 should be fine for that kind of customer assuming > all the objects are in the same broadcast domain (e.g. > bridged mode on the wireless router). > > Cheers, > Aaron > > > > > > > Ted > > > > > > > -----Original Message----- > > > From: arin-discuss-bounces at arin.net > > > [mailto:arin-discuss-bounces at arin.net] On Behalf Of Aaron Hughes > > > Sent: Wednesday, May 06, 2009 10:59 AM > > > To: Matthew Wilder > > > Cc: arin-discuss at arin.net > > > Subject: Re: [arin-discuss] IPv6 End User Assignments > > > > > > Matthew, > > > > > > You are highly likely correct. Regional aggregation will be > > > implemented by any reasonable ISP. Also, if ISPs did > assign /48s to > > > each customer your math is correct, each ISP of this massive size > > > would need a /21ish. Also, I agree a /48 is excessive for each > > > customer. > > > > > > For a moment we should separate policy from operations. > > > > > > As architects in the planning phase of a v6 roll-out we > get to plan > > > for company needs, customer needs, aggregation, reachability, > > > scalability, etc etc etc. One of the aspects we should > all evaluate > > > is wasting space. > > > > > > When I rolled out v6 to my customers, I made the company policy > > > decision to assign /64s to customers by default and /48s to those > > > who requested more than one subnet. This made it rather easy to > > > have 2 pools of aggregatable regional space for customer > > > assignments. The company policy / network architecture > fits within > > > certain, what I will call, ARIN guidelines in that it does not > > > violate ARIN policy. Policy has never dictated > operational practice. > > > > > > That being said, policy should _allow_ for an implementation that > > > requires /48 assignments to the LIRs respective > customers. There are > > > implementations where this makes sense. > > > It is highly unlikely that very large ISPs will be > assigning 48s to > > > each customer as it would be a waste of space. > > > > > > This list, just like Planing / Design / Architecture / Operations > > > groups are full of opinions about how things should be > implemented. > > > Time will reveal best practices and policies will get updated to > > > reflect them as long as the operational community is > involved in the > > > policy process. > > > > > > I am involved in many v6 implementations and none of them > assign 48s > > > by default. > > > > > > Cheers, > > > Aaron > > > > > > > > > On Wed, May 06, 2009 at 11:28:47AM -0600, Matthew Wilder wrote: > > > > This is where it gets interesting. I doubt the worst case > > > is a /23. Remember, IPv6 has so many bits for the very > purpose of > > > clean summarization and easy subnetting. > > > > > > > > Comcast might want to regionalize their subnetting. And > > > then within each region, they might want to have a nice big block > > > for each edge router so they don't have to constantly add address > > > resources to the router. All of a sudden, instead of > assuming a 90% > > > utilization of that block (which is heinously unreasonable and > > > inconsistent with IPv6 intentions) you are looking at > maybe 20 - 30% > > > utilization at the /48 assignments. Now they need probably a /21 > > > for those customers. > > > > > > > > This gets this sort of ISP into the hairy edge of what the > > > HD ratio allows in the best case. Assuming a /48 > assignment to an > > > end user counts as 100% utilization of the entire /48 > subnet, then > > > they will probably squeak through on the Threshold > > > (https://www.arin.net/policy/nrpm.html#six7). > > > > > > > > And this discussion here is exactly why I originally > > > through out the question. Why would an ISP assign a /48 > so that a > > > consumer can have two large layers of subnetting (16 bits > of subnet > > > address to be exact) at the expense of their own routing and > > > summarization? > > > > > > > > MW > > > > > > > > > > > > Aaron Hughes wrote: > > > > > US population is roughly 300 million. > > > > > A /19 would cover 536,870,912 /48s A /27 would cover > 536,870,912 > > > > > /56s > > > > > > > > > > 7 billion in the world. > > > > > A /15 would cover 8,589,934,592 /48s A /23 would cover > > > 8,589,934,592 > > > > > /56s. > > > > > > > > > > Number of total Internet users in the world roughly 1.5 > > > billion or > > > > > 20% of the population. > > > > > Number of total Internet users in the US roughly 220 million. > > > > > > > > > > Let's say you are Comcast.. ~ 25 million customers. Worst > > > cast you > > > > > are looking at a /23 to give each one a /48, or roughly > > > best case a > > > > > /39 for 2x/64s per customer. > > > > > > > > > > This is not a repeat of v4. > > > > > > > > > > IPv4 ISPs gave a single host to the outside interface of > > > the CPE AND > > > > > some flavor of space in (RFC1918) 10.0.0.0/8, 172.16.0.0/12, > > > > > 192.168.0.0/16 for their inside interface. If we > > > implement NAT in > > > > > v6, we will stop progress with end-to-end application > > > > > development and make the same silly mistakes we made > with v4. > > > > > The > > > mistake was > > > > > not wasting space but rather not making the leap to IPv6 > > > when we identified the potential for growth so many years ago. > > > > > Instead we focused on CIDR/VLSM and NATing everything > we could > > > > > to extend the life of a dying protocol. > > > > > > > > > > It is perfectly reasonable to have standard > assignment sizes to > > > > > create an appropriate customer expectation. Your customers do > > > > > not need to know what a subnet is. If the standard was, for > > > example, to > > > > > assign a /64 to the WAN and /64 to the LAN with SLAAC > > > enabled, the > > > > > customer behaves the same way they do today. Those who > > > request more > > > > > space know what they are doing (generally speaking). > > > > > > > > > > Cheers, > > > > > Aaron > > > -- > > > > > > Aaron Hughes > > > aaronh at bind.com > > > (703) 244-0427 > > > Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C > > > C6 B8 http://www.bind.com/ > > > _______________________________________________ > > > ARIN-Discuss > > > You are receiving this message because you are subscribed to the > > > ARIN Discussion Mailing List (ARIN-discuss at arin.net). > > > Unsubscribe or manage your mailing list subscription at: > > > http://lists.arin.net/mailman/listinfo/arin-discuss > > > Please contact info at arin.net if you experience any issues. > > > > > -- > > Aaron Hughes > aaronh at bind.com > (703) 244-0427 > Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C > C6 B8 http://www.bind.com/ > From owen at delong.com Wed May 6 18:12:44 2009 From: owen at delong.com (Owen DeLong) Date: Wed, 6 May 2009 15:12:44 -0700 Subject: [arin-discuss] IPv6 End User Assignments In-Reply-To: References: Message-ID: <588DD93F-F1CD-4AFA-8129-6552008ADBF3@delong.com> On May 6, 2009, at 7:43 AM, Matthew Wilder wrote: > I have a question about subnet size for end user sites (and a few > thoughts as well). > > What size of IPv6 subnet would you imagine an ADSL customer > (consumer, not business) would get from their ISP? The NRPM > actually has nifty guidelines around subnet assignment here: > > /64 when it is known that one and only one subnet is needed > /56 for small sites, those expected to need only a few subnets over > the next 5 years. > /48 for larger sites > > I would assume that with the average Joe ADSL user, one subnet is > enough. Whether or not an ISP would make that assumption in their > provisioning of the service might be another question. Either way, > I would bet that a /64 would suffice for 99% of users. > Were I running such a provider, I would assign a /64 with a /56 automatic on request and a /48 with minimal justification. > I can see value in assigning a /56 to every user so that they can > subnet to their hearts' content to save any trouble of renumbering > down the road, not that an average consumer would have a lot of > renumbering to do. > I figure the average consumer that didn't know they wanted more up front won't have too much trouble renumbering that initial /64 if they have to. Afterall, most of the renumbering can be done with a little global search and replace, and the rest is probably not going to be too painful. Especially if the /64 and a piece of the /56 can coexist for a time which is perfectly feasible from a technical perspective. > That said, I was a little surprised to see on the slashdot article > about the ARIN letter (http://tech.slashdot.org/article.pl?sid=09/04/30/2051235&art_pos=2 > ) that a comment came out suggesting every household would have a / > 48 assigned to it. What was more surprising is that no comments > surfaced to correct this claim. > Please don't take the underinformed press (amateur press?) word for anything in this area. RFC trumps press every day on the internet. RIR policy also applies. The press is as likely to get it wrong about IP as they do about Aviation, Meteorology, or any other detailed technical issue. > My understanding of /48 is along with the NRPM: that /48 subnets are > for "larger sites". Not many consumers would use much of their > 65,536 /64 subnets in a /48 (at least in my estimation). > I have a /48 for my household and expect to use more than 256 subnets over time. The bottom line is that in IPv6, you don't really think about how much of 65,536 subnets will they use, but, rather, is there a chance of using more than 256? OK... The next boundary tends to default to /48. > This got me to do some exploring. I know that French telcos have > already got IPv6 available for their ADSL customers. So with the > help of Google translation, I got the following page from a telco > called Nerim: > http://translate.google.com/translate?hl=en&sl=fr&u=http://www.nerim.fr/ipv6&ei=iaEASrPINZritAPxjqX-BQ&sa=X&oi=translate&resnum=1&ct=result&prev=/search%3Fq%3Dnerim%2Bipv6%26hl%3Den%26rls%3Dcom.microsoft:en-US > > If you read near the bottom of the translated text, you will see > "For access, IPv6 allocation is a / 48..." A /48 for a consumer? > That was the original intent of the IETF. In the ARIN region, we've come to the conclusion that (in part because we probably have more customers than the French ISPs) a /56 is a bit more rational in many cases. > This made me curious to see what RIPE NCC says about end user > assignments. They have similar language about the /64 being the > minimum, in the case that no subnetting is required. They skip > over /56 (which makes me appreciate the ARIN policy) directly to / > 48. They leave it to the LIR and ISP to determine what size of > assignments to make for end sites. > Indeed, the /56 was initially proposed in ARIN policy and has not gained wide acceptance yet in the rest of the world. I think that will likely change over time. I think as /32 holders start to gain more than 65,536 customers, you may well see them starting to try and figure out ways to not use up their next /32 so quickly. > So, all this back to the original question: > What kind of IPv6 subnet would YOU expect a North American ISP to > assign to their residential ADSL customer? > Default: /64 On request: /56 With justification: /48 With _ALOT_ of justification: up to a /32, possibly more. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From aaronh at bind.com Wed May 6 18:19:14 2009 From: aaronh at bind.com (Aaron Hughes) Date: Wed, 6 May 2009 15:19:14 -0700 Subject: [arin-discuss] IPv6 End User Assignments In-Reply-To: References: <20090506175911.GH67888@trace.bind.com> <934B1E52439543079E627040FBA75BCC@tedsdesk> <20090506212408.GI67888@trace.bind.com> Message-ID: <20090506221914.GJ67888@trace.bind.com> Separate /64s in this case where there are point-to-points. For the colocation customers, it's just a /64 of the connected interface. Cheers, Aaron On Wed, May 06, 2009 at 03:10:44PM -0700, Ted Mittelstaedt wrote: > > What separates the customer's broadcast domains from yours? > > I assume there's a router at the customer (DSL modem, cable modem or > whatever) and the /64 is on the customer side of the CPE. If that > is the case, what is on your side of the CPE? Part of the /64 or > a separate subnet? > > Ted > > > -----Original Message----- > > From: Aaron Hughes [mailto:aaronh at bind.com] > > Sent: Wednesday, May 06, 2009 2:24 PM > > To: Ted Mittelstaedt > > Cc: 'Matthew Wilder'; arin-discuss at arin.net > > Subject: Re: [arin-discuss] IPv6 End User Assignments > > > > > > On Wed, May 06, 2009 at 01:37:33PM -0700, Ted Mittelstaedt wrote: > > > > > > Aaron, > > > > > > Was space-wasting the only reason you went with a /64 > > instead of a > > > /48 or /56? > > > > Yes. > > > > > For your single point customers, is this /64 intended for use on > > > just a single PC? Such as for example a DSL customer with just a > > > single PC plugged into a bridged DSL modem? > > > > > > /64 was for any customer with one broadcast domain, 1 to > > several machines. If they have multiple broadcast domains > > (more than one), they get a 48. 56 vs 64 was just a flip a > > coin decision to some extent. There was a ton of discussion > > on the topic and I just picked one and moved forward. At > > some point you just have to implement and get some real world > > experience. > > > > I did look at assigning something smaller than a 64 initially > > and tools turned out to be the deciding factor. Since all of > > my v4 tools such as allocations/assignments/router > > config/CRM/ERP/etc store the v4 address as 4 x INT(11), it > > was rather easy to convert hex to dec and store in the same > > tables. The mask in this case is also an INT(11). Adding > > the additional octets would have been much more effort. > > > > > Do you consider a customer > > > who has a wireless router with 5-6 PC's on it as needing a > > subnet ie > > > /48? > > > > No. a 64 should be fine for that kind of customer assuming > > all the objects are in the same broadcast domain (e.g. > > bridged mode on the wireless router). > > > > Cheers, > > Aaron > > > > > > > > > > > > Ted > > > > > > > > > > -----Original Message----- > > > > From: arin-discuss-bounces at arin.net > > > > [mailto:arin-discuss-bounces at arin.net] On Behalf Of Aaron Hughes > > > > Sent: Wednesday, May 06, 2009 10:59 AM > > > > To: Matthew Wilder > > > > Cc: arin-discuss at arin.net > > > > Subject: Re: [arin-discuss] IPv6 End User Assignments > > > > > > > > Matthew, > > > > > > > > You are highly likely correct. Regional aggregation will be > > > > implemented by any reasonable ISP. Also, if ISPs did > > assign /48s to > > > > each customer your math is correct, each ISP of this massive size > > > > would need a /21ish. Also, I agree a /48 is excessive for each > > > > customer. > > > > > > > > For a moment we should separate policy from operations. > > > > > > > > As architects in the planning phase of a v6 roll-out we > > get to plan > > > > for company needs, customer needs, aggregation, reachability, > > > > scalability, etc etc etc. One of the aspects we should > > all evaluate > > > > is wasting space. > > > > > > > > When I rolled out v6 to my customers, I made the company policy > > > > decision to assign /64s to customers by default and /48s to those > > > > who requested more than one subnet. This made it rather easy to > > > > have 2 pools of aggregatable regional space for customer > > > > assignments. The company policy / network architecture > > fits within > > > > certain, what I will call, ARIN guidelines in that it does not > > > > violate ARIN policy. Policy has never dictated > > operational practice. > > > > > > > > That being said, policy should _allow_ for an implementation that > > > > requires /48 assignments to the LIRs respective > > customers. There are > > > > implementations where this makes sense. > > > > It is highly unlikely that very large ISPs will be > > assigning 48s to > > > > each customer as it would be a waste of space. > > > > > > > > This list, just like Planing / Design / Architecture / Operations > > > > groups are full of opinions about how things should be > > implemented. > > > > Time will reveal best practices and policies will get updated to > > > > reflect them as long as the operational community is > > involved in the > > > > policy process. > > > > > > > > I am involved in many v6 implementations and none of them > > assign 48s > > > > by default. > > > > > > > > Cheers, > > > > Aaron > > > > > > > > > > > > On Wed, May 06, 2009 at 11:28:47AM -0600, Matthew Wilder wrote: > > > > > This is where it gets interesting. I doubt the worst case > > > > is a /23. Remember, IPv6 has so many bits for the very > > purpose of > > > > clean summarization and easy subnetting. > > > > > > > > > > Comcast might want to regionalize their subnetting. And > > > > then within each region, they might want to have a nice big block > > > > for each edge router so they don't have to constantly add address > > > > resources to the router. All of a sudden, instead of > > assuming a 90% > > > > utilization of that block (which is heinously unreasonable and > > > > inconsistent with IPv6 intentions) you are looking at > > maybe 20 - 30% > > > > utilization at the /48 assignments. Now they need probably a /21 > > > > for those customers. > > > > > > > > > > This gets this sort of ISP into the hairy edge of what the > > > > HD ratio allows in the best case. Assuming a /48 > > assignment to an > > > > end user counts as 100% utilization of the entire /48 > > subnet, then > > > > they will probably squeak through on the Threshold > > > > (https://www.arin.net/policy/nrpm.html#six7). > > > > > > > > > > And this discussion here is exactly why I originally > > > > through out the question. Why would an ISP assign a /48 > > so that a > > > > consumer can have two large layers of subnetting (16 bits > > of subnet > > > > address to be exact) at the expense of their own routing and > > > > summarization? > > > > > > > > > > MW > > > > > > > > > > > > > > > Aaron Hughes wrote: > > > > > > US population is roughly 300 million. > > > > > > A /19 would cover 536,870,912 /48s A /27 would cover > > 536,870,912 > > > > > > /56s > > > > > > > > > > > > 7 billion in the world. > > > > > > A /15 would cover 8,589,934,592 /48s A /23 would cover > > > > 8,589,934,592 > > > > > > /56s. > > > > > > > > > > > > Number of total Internet users in the world roughly 1.5 > > > > billion or > > > > > > 20% of the population. > > > > > > Number of total Internet users in the US roughly 220 million. > > > > > > > > > > > > Let's say you are Comcast.. ~ 25 million customers. Worst > > > > cast you > > > > > > are looking at a /23 to give each one a /48, or roughly > > > > best case a > > > > > > /39 for 2x/64s per customer. > > > > > > > > > > > > This is not a repeat of v4. > > > > > > > > > > > > IPv4 ISPs gave a single host to the outside interface of > > > > the CPE AND > > > > > > some flavor of space in (RFC1918) 10.0.0.0/8, 172.16.0.0/12, > > > > > > 192.168.0.0/16 for their inside interface. If we > > > > implement NAT in > > > > > > v6, we will stop progress with end-to-end application > > > > > > development and make the same silly mistakes we made > > with v4. > > > > > > The > > > > mistake was > > > > > > not wasting space but rather not making the leap to IPv6 > > > > when we identified the potential for growth so many years ago. > > > > > > Instead we focused on CIDR/VLSM and NATing everything > > we could > > > > > > to extend the life of a dying protocol. > > > > > > > > > > > > It is perfectly reasonable to have standard > > assignment sizes to > > > > > > create an appropriate customer expectation. Your customers do > > > > > > not need to know what a subnet is. If the standard was, for > > > > example, to > > > > > > assign a /64 to the WAN and /64 to the LAN with SLAAC > > > > enabled, the > > > > > > customer behaves the same way they do today. Those who > > > > request more > > > > > > space know what they are doing (generally speaking). > > > > > > > > > > > > Cheers, > > > > > > Aaron > > > > -- > > > > > > > > Aaron Hughes > > > > aaronh at bind.com > > > > (703) 244-0427 > > > > Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C > > > > C6 B8 http://www.bind.com/ > > > > _______________________________________________ > > > > ARIN-Discuss > > > > You are receiving this message because you are subscribed to the > > > > ARIN Discussion Mailing List (ARIN-discuss at arin.net). > > > > Unsubscribe or manage your mailing list subscription at: > > > > http://lists.arin.net/mailman/listinfo/arin-discuss > > > > Please contact info at arin.net if you experience any issues. > > > > > > > > -- > > > > Aaron Hughes > > aaronh at bind.com > > (703) 244-0427 > > Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C > > C6 B8 http://www.bind.com/ > > -- Aaron Hughes aaronh at bind.com (703) 244-0427 Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8 http://www.bind.com/ From michael.dillon at bt.com Thu May 7 03:52:39 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 7 May 2009 08:52:39 +0100 Subject: [arin-discuss] IPv6 End User Assignments In-Reply-To: <0B90C2EF-47B7-4D75-8827-93CA0B8B4F5E@grokthis.net> Message-ID: <28E139F46D45AF49A31950F88C497458F872F0@E03MVZ2-UKDY.domain1.systemhost.net> > Do you really want to have the CPE be nothing but a switch? > Surely, it would be simple, and it would allow customers to > operate with no > more equipment than they already own. However, it would come at a > huge expense to the customer's functionality. The methodology of > routing through a /128 would be quite similar to how IPv4 is > being deployed, except that it would now be visible on the > residential customer's router as it is already on commercial > IPv4 deployments. You are trying to reinvent DOCSIS and the broadband forum working groups. There is no need since other folks are already working on standard specs for CPE on both cable and DSL connections. If you think they are missing something, contact one of the Broadband Forum working groups and let them know what you think is needed. > If you are afraid of changing the methodology, I don't see > why you would want to take the ability of a customer to have > a router, something that customers are already familiar with > owning and installing, even at a residential level, and > forcing them to have nothing more complicated than a switch? I don't know who you are addressing here, but I certainly did not say that. > Right now, though, this is nothing more than a > dream (but then again, so are residential IPv6 deployments) There are residential IPv6 deployments in some countries. I know for a fact that some large DSL providers have closed trial deployments under way right now in Europe. --Michael Dillon From michael.dillon at bt.com Thu May 7 04:09:16 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 7 May 2009 09:09:16 +0100 Subject: [arin-discuss] IPv6 End User Assignments In-Reply-To: <20090506175911.GH67888@trace.bind.com> Message-ID: <28E139F46D45AF49A31950F88C497458F8732C@E03MVZ2-UKDY.domain1.systemhost.net> > As architects in the planning phase of a v6 roll-out we get > to plan for company needs, customer needs, aggregation, > reachability, scalability, etc etc etc. One of the aspects we > should all evaluate is wasting space. NO! First of all, don't call yourself an architect if you know nothing about the technology. Architects start by learning how things work, then and only then, do they design and plan. You have a warped sense of size and waste. A /21 is hardly massive. With IPv4 I have received several /16 allocations from ARIN, and in IPv6, a /21 or /16 represents the same proportion of the total address space. In the IPv4 world an ISP with a /21 is a small ISP in a single town. Waste is simply not an issue with IPv6. > When I rolled out v6 to my customers, I made the company > policy decision to assign /64s to customers by default and > /48s to those who requested more than one subnet. This made > it rather easy to have 2 pools of aggregatable regional space > for customer assignments. Some of use prefer one pool which can be achieved by giving everyone a /48. On the business side of things, when competitors appear offering a /48, this means that you would already be at parity instead of losing customers steadily because of your stinginess. If I were in your market, I would portray this as evidence of your technical incompetence to encourage your customers to jump ship. (Note that I don't run an ISP so there is no danger of me personally being in your market). > It is highly unlikely that very large ISPs will be assigning > 48s to each customer as it would be a waste of space. It is not a waste of space. Very large ISPs in Europe and Asia already do assign /48s to each customer. ARIN policy allows it in North America as well. > I am involved in many v6 implementations and none of them > assign 48s by default. No doubt due to your influence. But sooner or later these people will educate themselves about IPv6 and will be unhappy with the way that you forced them down an unsustainable path. --Michael Dillon From michael.dillon at bt.com Thu May 7 04:13:27 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 7 May 2009 09:13:27 +0100 Subject: [arin-discuss] IPv6 End User Assignments In-Reply-To: <4A01E89F.8030105@directcom.com> Message-ID: <28E139F46D45AF49A31950F88C497458F87345@E03MVZ2-UKDY.domain1.systemhost.net> > Ok so what my initial comment about /128's at customers wan > interfaces (or directly to their pc's) a good assumption? This is really not an appropriate place to be learning how IPv6 works. Check out ARIN's IPv6 wiki at for educational material and pointers to other learning resources. --Michael Dillon From michael.dillon at bt.com Thu May 7 09:01:31 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 7 May 2009 14:01:31 +0100 Subject: [arin-discuss] IPv6 End User Assignments In-Reply-To: <4A02CA87.8020101@ttec.com> Message-ID: <28E139F46D45AF49A31950F88C497458F879AD@E03MVZ2-UKDY.domain1.systemhost.net> > > You have a warped sense of size and waste. A /21 is hardly massive. > > With IPv4 I have received several /16 allocations from ARIN, and in > > IPv6, a /21 or /16 represents the same proportion of the > total address > > space. > > In the IPv4 world > > an ISP with a /21 is a small ISP in a single town. Waste is > simply not > > an issue with IPv6. > Only large ISP's can afford to do so with impunity. A /32 is > not sufficient for a default allocation of /48 per customer. First of all, /32 is irrelevant. You figure out how much you need and if you are a large ISP, then you will get a /23 or /21 or whatever you can justify. And you justify it based on a /48 to every customer. But let's assume that you got a /48 and exceeded your business plans. Simple. When you are getting low on /48s, just go back to ARIN and get more /32s. ARIN is not likely to runout in your lifetime. If and only if, you project that you will have difficulty meeting the HD ratio when you ask for more /32s, then assign /56 to some or all of your residential customers. This is only likely to be a problem for the very largest ISPs. > That makes it effectively only 16 times larger than an ipv4 > /20, which suggests additional prefixes or renumbering pain. No, no, no. Your statements change nothing. An IPv6 /21 is the same proportion of the total IPv6 space as an IPv4 /21. If an IPv4 ISP with a /21 allocation is using a tiny amount of IPv4 space, then an IPv6 ISP with a /21 is also using a tiny amount of space. The difference is that only the largest ISPs will need a /21 of IPv6 space and it will last them for many years. > People are trying to carve up their allocated space now, in > an intelligent manner as much as possible. Getting it right > at this point could avoid pain later, so this is important. Agreed. Don't apply for a /32 until you have done some analysis first. And if you need a bigger block than /32, get it right from the beginning. --Michael Dillon From jmaimon at chl.com Thu May 7 09:56:04 2009 From: jmaimon at chl.com (Joe Maimon) Date: Thu, 07 May 2009 09:56:04 -0400 Subject: [arin-discuss] IPv6 End User Assignments In-Reply-To: <28E139F46D45AF49A31950F88C497458F8732C@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458F8732C@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <4A02E874.6020408@chl.com> michael.dillon at bt.com wrote: > You have a warped sense of size and waste. A /21 is hardly > massive. With IPv4 I have received several /16 allocations > from ARIN, and in IPv6, a /21 or /16 represents the same > proportion of the total address space. > In the IPv4 world > an ISP with a /21 is a small ISP in a single town. Waste > is simply not an issue with IPv6. This seems contradictory. > It is not a waste of space. Very large ISPs in Europe and > Asia already do assign /48s to each customer. ARIN policy > allows it in North America as well. > Only large ISP's can afford to do so with impunity. A /32 is not sufficient for a default allocation of /48 per customer. That makes it effectively only 16 times larger than an ipv4 /20, which suggests additional prefixes or renumbering pain. A /24 or /28 would be better if indeed /48 per customer is expected to be the norm. People are trying to carve up their allocated space now, in an intelligent manner as much as possible. Getting it right at this point could avoid pain later, so this is important. From dwhite at olp.net Thu May 7 10:34:01 2009 From: dwhite at olp.net (Dan White) Date: Thu, 07 May 2009 09:34:01 -0500 Subject: [arin-discuss] IPv6 End User Assignments In-Reply-To: <4A02E874.6020408@chl.com> References: <28E139F46D45AF49A31950F88C497458F8732C@E03MVZ2-UKDY.domain1.systemhost.net> <4A02E874.6020408@chl.com> Message-ID: <4A02F159.5010808@olp.net> Joe Maimon wrote: > michael.dillon at bt.com wrote: > > >> It is not a waste of space. Very large ISPs in Europe and >> Asia already do assign /48s to each customer. ARIN policy >> allows it in North America as well. >> >> > > Only large ISP's can afford to do so with impunity. A /32 is not > sufficient for a default allocation of /48 per customer. That makes it > effectively only 16 times larger than an ipv4 /20, which suggests > additional prefixes or renumbering pain. > > A /24 or /28 would be better if indeed /48 per customer is expected to > be the norm. > > People are trying to carve up their allocated space now, in an > intelligent manner as much as possible. Getting it right at this point > could avoid pain later, so this is important. > To me, the conservative approach is to assign a /48 to each customer. To do so means that they will never need to ask for more addresses again (in most cases), regardless of their size... and as their provider, it's doesn't make sense to me to suggest what their network should look like today, or what it likely will look like in 5, 10 or 20 years. I tend to stay away from the approach of allocating small subnets today, and then allocate larger ones based on customer need. I prefer to do the heavy lifting up front - /48 via prefix delegation or routing protocol - which will save me the work of reconfiguration their allocation down the road. > A /32 is not sufficient for a default allocation of /48 per customer. > That makes it effectively only 16 times larger than an ipv4 /20 I have two /20 IPv4 allocations, which gives me 8192 possible customers (and I have many less than that). I have a /32 IPv6 allocation which gives me 65536 possible customers at /48, which should easily last me 30 years to retirement! - Dan From dsd at servervault.com Thu May 7 10:49:42 2009 From: dsd at servervault.com (Divins, David) Date: Thu, 7 May 2009 10:49:42 -0400 Subject: [arin-discuss] IPv6 End User Assignments In-Reply-To: <4A02F159.5010808@olp.net> References: <28E139F46D45AF49A31950F88C497458F8732C@E03MVZ2-UKDY.domain1.systemhost.net><4A02E874.6020408@chl.com> <4A02F159.5010808@olp.net> Message-ID: Just to chime in, I am doing /56's with adjacent reservations. The reality is, until I have more customers willing to do IPv6, I won't know how good or bad my address plan is/was. -dsd David Divins Principal Engineer ServerVault Corp. -----Original Message----- From: arin-discuss-bounces at arin.net [mailto:arin-discuss-bounces at arin.net] On Behalf Of Dan White Sent: Thursday, May 07, 2009 10:34 AM To: Joe Maimon Cc: arin-discuss at arin.net Subject: Re: [arin-discuss] IPv6 End User Assignments Joe Maimon wrote: > michael.dillon at bt.com wrote: > > >> It is not a waste of space. Very large ISPs in Europe and >> Asia already do assign /48s to each customer. ARIN policy >> allows it in North America as well. >> >> > > Only large ISP's can afford to do so with impunity. A /32 is not > sufficient for a default allocation of /48 per customer. That makes it > effectively only 16 times larger than an ipv4 /20, which suggests > additional prefixes or renumbering pain. > > A /24 or /28 would be better if indeed /48 per customer is expected to > be the norm. > > People are trying to carve up their allocated space now, in an > intelligent manner as much as possible. Getting it right at this point > could avoid pain later, so this is important. > To me, the conservative approach is to assign a /48 to each customer. To do so means that they will never need to ask for more addresses again (in most cases), regardless of their size... and as their provider, it's doesn't make sense to me to suggest what their network should look like today, or what it likely will look like in 5, 10 or 20 years. I tend to stay away from the approach of allocating small subnets today, and then allocate larger ones based on customer need. I prefer to do the heavy lifting up front - /48 via prefix delegation or routing protocol - which will save me the work of reconfiguration their allocation down the road. > A /32 is not sufficient for a default allocation of /48 per customer. > That makes it effectively only 16 times larger than an ipv4 /20 I have two /20 IPv4 allocations, which gives me 8192 possible customers (and I have many less than that). I have a /32 IPv6 allocation which gives me 65536 possible customers at /48, which should easily last me 30 years to retirement! - Dan _______________________________________________ ARIN-Discuss You are receiving this message because you are subscribed to the ARIN Discussion Mailing List (ARIN-discuss at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-discuss Please contact info at arin.net if you experience any issues. From jmaimon at chl.com Thu May 7 10:50:23 2009 From: jmaimon at chl.com (Joe Maimon) Date: Thu, 07 May 2009 10:50:23 -0400 Subject: [arin-discuss] IPv6 End User Assignments In-Reply-To: <4A02F159.5010808@olp.net> References: <28E139F46D45AF49A31950F88C497458F8732C@E03MVZ2-UKDY.domain1.systemhost.net> <4A02E874.6020408@chl.com> <4A02F159.5010808@olp.net> Message-ID: <4A02F52F.3020803@chl.com> Dan White wrote: > > > To me, the conservative approach is to assign a /48 to each customer. > To do so means that they will never need to ask for more addresses > again (in most cases), regardless of their size... But you, the ISP, will need to ask for more, depending on size. Fail. > > A /32 is not sufficient for a default allocation of /48 per customer. > > That makes it effectively only 16 times larger than an ipv4 /20 > > I have two /20 IPv4 allocations, which gives me 8192 possible > customers (and I have many less than that). I have a /32 IPv6 > allocation which gives me 65536 possible customers at /48, which > should easily last me 30 years to retirement! Its great that for you making IPv6 effectively *only* 16 times larger than ipv4 works out well. However, I think its bad policy. > > - Dan > > From spiffnolee at yahoo.com Thu May 7 10:49:19 2009 From: spiffnolee at yahoo.com (Lee Howard) Date: Thu, 7 May 2009 07:49:19 -0700 (PDT) Subject: [arin-discuss] IPv6 End User Assignments In-Reply-To: <4A02E874.6020408@chl.com> References: <28E139F46D45AF49A31950F88C497458F8732C@E03MVZ2-UKDY.domain1.systemhost.net> <4A02E874.6020408@chl.com> Message-ID: <931204.75297.qm@web63307.mail.re1.yahoo.com> ----- Original Message ---- > From: Joe Maimon > Cc: arin-discuss at arin.net > Sent: Thursday, May 7, 2009 9:56:04 AM > Subject: Re: [arin-discuss] IPv6 End User Assignments > > > > michael.dillon at bt.com wrote: > > > You have a warped sense of size and waste. A /21 is hardly > > massive. With IPv4 I have received several /16 allocations > > from ARIN, and in IPv6, a /21 or /16 represents the same > > proportion of the total address space. > > In the IPv4 world > > an ISP with a /21 is a small ISP in a single town. Waste > > is simply not an issue with IPv6. > > This seems contradictory. > > > It is not a waste of space. Very large ISPs in Europe and > > Asia already do assign /48s to each customer. ARIN policy > > allows it in North America as well. > > > > Only large ISP's can afford to do so with impunity. A /32 is not > sufficient for a default allocation of /48 per customer. That makes it > effectively only 16 times larger than an ipv4 /20, which suggests > additional prefixes or renumbering pain. I don't understand. Show that you've used 36.9% of your /56s, and document your two-year requirements, and you get another (adjacent) /32 (or whatever). How is it different for large and small ISPs? Note that NRPM says: The exact size of the assignment is a local decision for the LIR or ISP to make, using a minimum value of a /64 (when only one subnet is anticipated for the end site) up to the normal maximum of /48, except in cases of extra large end sites where a larger assignment can be justified. The following guidelines may be useful (but they are only guidelines): * /64 when it is known that one and only one subnet is needed * /56 for small sites, those expected to need only a few subnets over the next 5 years. * /48 for larger sites Lee From jmaimon at chl.com Thu May 7 11:09:41 2009 From: jmaimon at chl.com (Joe Maimon) Date: Thu, 07 May 2009 11:09:41 -0400 Subject: [arin-discuss] IPv6 End User Assignments In-Reply-To: <931204.75297.qm@web63307.mail.re1.yahoo.com> References: <28E139F46D45AF49A31950F88C497458F8732C@E03MVZ2-UKDY.domain1.systemhost.net> <4A02E874.6020408@chl.com> <931204.75297.qm@web63307.mail.re1.yahoo.com> Message-ID: <4A02F9B5.3010000@chl.com> Lee Howard wrote: > I don't understand. Show that you've used 36.9% of your /56s, and > document your two-year requirements, and you get another (adjacent) > /32 (or whatever). How is it different for large and small ISPs? > Subnet expansion would eliminate *most* technical difficulties, leaving aside the likely havoc on internal address carving design, summarizations, access-lists or whatever. Cost, time, effort, manpower are not. How far expandable are they? Should a small ISP allocate /48 relying on adjacent expansion or not? In any event, if justification hinges on /56, its pointless to allocate less per customer. Why are some advocating giving customers more than they could ever conceivably use while suggesting that providers should be visiting the well on a potentially frequent basis? Joe From dwhite at olp.net Thu May 7 11:11:17 2009 From: dwhite at olp.net (Dan White) Date: Thu, 07 May 2009 10:11:17 -0500 Subject: [arin-discuss] IPv6 End User Assignments In-Reply-To: <4A02F52F.3020803@chl.com> References: <28E139F46D45AF49A31950F88C497458F8732C@E03MVZ2-UKDY.domain1.systemhost.net> <4A02E874.6020408@chl.com> <4A02F159.5010808@olp.net> <4A02F52F.3020803@chl.com> Message-ID: <4A02FA15.2080103@olp.net> Joe Maimon wrote: > > > Dan White wrote: >> >> >> To me, the conservative approach is to assign a /48 to each customer. >> To do so means that they will never need to ask for more addresses >> again (in most cases), regardless of their size... > > But you, the ISP, will need to ask for more, depending on size. Fail. Please tell me when and how that will happen. I'll be sure to let management know! In all seriousness, I do not ever expect a company of my size and business model to need more addresses, but if I do, ARIN staff have already planned ahead: 2610:b8::/32 - allocated to me The next block of allocated addresses is 2610:c0::/32, which means that potentially I could grow in to a /29 without renumbering or creating additional routing slots - until they need to allocate those blocks to someone else. The point is if you assign your addresses based on future need rather than current need (which I believe is the wisest approach), then you have to ability to maintain a more static network, and a more stable routing table, among other benefits. - Dan From aaronh at bind.com Thu May 7 11:38:11 2009 From: aaronh at bind.com (Aaron Hughes) Date: Thu, 7 May 2009 08:38:11 -0700 Subject: [arin-discuss] IPv6 End User Assignments In-Reply-To: <28E139F46D45AF49A31950F88C497458F8732C@E03MVZ2-UKDY.domain1.systemhost.net> References: <20090506175911.GH67888@trace.bind.com> <28E139F46D45AF49A31950F88C497458F8732C@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <20090507153811.GM67888@trace.bind.com> Michael, E-mail such as yours is disheartening and drives me toward unsubscribing, however, we all really do need to be discussing things such as v6 end user assignments. I want so badly for this to be a positive and educational experience for all of us. This list is intended to be used for discussion. Please focus on mastering the art of leadership rather than attacking others or nit-picking at minor and mostly off-topic points. Based on your e-mails, you appear to be an intelligent person with exceptionally high attention to detail and with the right focus you could really help this community. Your current behavior is creating a good deal of noise that is distracting and takes away from the quality of the discussion. I hope I speak for everyone when I ask for you to reflect upon your delivery and ask that you please take the time to think about the community and the individuals you are interacting with before sending future e-mail. Aaron On Thu, May 07, 2009 at 09:09:16AM +0100, michael.dillon at bt.com wrote: > > As architects in the planning phase of a v6 roll-out we get > > to plan for company needs, customer needs, aggregation, > > reachability, scalability, etc etc etc. One of the aspects we > > should all evaluate is wasting space. > > NO! > > First of all, don't call yourself an architect if you know > nothing about the technology. Architects start by learning > how things work, then and only then, do they design and plan. > You have a warped sense of size and waste. A /21 is hardly > massive. With IPv4 I have received several /16 allocations > from ARIN, and in IPv6, a /21 or /16 represents the same > proportion of the total address space. In the IPv4 world > an ISP with a /21 is a small ISP in a single town. Waste > is simply not an issue with IPv6. > > > When I rolled out v6 to my customers, I made the company > > policy decision to assign /64s to customers by default and > > /48s to those who requested more than one subnet. This made > > it rather easy to have 2 pools of aggregatable regional space > > for customer assignments. > > Some of use prefer one pool which can be achieved by giving > everyone a /48. On the business side of things, when competitors > appear offering a /48, this means that you would already > be at parity instead of losing customers steadily because of > your stinginess. If I were in your market, I would portray > this as evidence of your technical incompetence to encourage > your customers to jump ship. (Note that I don't run an ISP > so there is no danger of me personally being in your market). > > > It is highly unlikely that very large ISPs will be assigning > > 48s to each customer as it would be a waste of space. > > It is not a waste of space. Very large ISPs in Europe and > Asia already do assign /48s to each customer. ARIN policy > allows it in North America as well. > > > I am involved in many v6 implementations and none of them > > assign 48s by default. > > No doubt due to your influence. But sooner or later these > people will educate themselves about IPv6 and will be unhappy > with the way that you forced them down an unsustainable path. > > --Michael Dillon > -- > ARIN-Discuss > You are receiving this message because you are subscribed to > the ARIN Discussion Mailing List (ARIN-discuss at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-discuss > Please contact info at arin.net if you experience any issues. -- Aaron Hughes aaronh at bind.com (703) 244-0427 Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8 http://www.bind.com/ From michael.dillon at bt.com Thu May 7 11:54:46 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 7 May 2009 16:54:46 +0100 Subject: [arin-discuss] IPv6 End User Assignments In-Reply-To: <20090507153811.GM67888@trace.bind.com> Message-ID: <28E139F46D45AF49A31950F88C497458F87D82@E03MVZ2-UKDY.domain1.systemhost.net> > however, we all really do need to be > discussing things such as v6 end user assignments. There are plenty of other places to discuss IPv6 technical issues and the biggest benefit of going elsewhere is that you can find some expert advice there. > I want so > badly for this to be a positive and educational experience > for all of us. So do I. That is why I collected and wrote up about half of the content on ARIN's IPv6 wiki at . > This list is intended to be used for discussion. Please focus > on mastering the art of leadership rather than attacking > others or nit-picking at minor and mostly off-topic points. Sorry, but I'm not here to lead anybody. This list is not for leadership, it's for discussion. I cast in my two bits worth and people either get it, or they don't. > Based on your e-mails, you appear to be an intelligent person > with exceptionally high attention to detail and with the > right focus you could really help this community. Community? I don't see any community here. Sorry but this is the ARIN members discussion list where most days, there is zero discussion. Many members don't even monitor this list. Check the archives to see what I mean. > Your > current behavior is creating a good deal of noise that is > distracting and takes away from the quality of the discussion. And you're behavior is distracting us from the discussion of the topic in the subject line. IPv6 end user assignments. Start by reading and then if you want to see where it came from, follow up the RFCs and Internet drafts referenced on it. You could also Google for something like "dillon nanog ipv6 addressing" and pick up the original discussions that led to this page. It was well over a year ago, maybe two. And if you know of an IPv6 deployment mailing list other than NANOG, feel free to tell us all about it. --Michael Dillon From andya at brin.com Thu May 7 12:00:48 2009 From: andya at brin.com (Andy Alvarado) Date: Thu, 7 May 2009 10:00:48 -0600 (MDT) Subject: [arin-discuss] IPv6 End User Assignments In-Reply-To: <28E139F46D45AF49A31950F88C497458F87D82@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <2062645653.42031241712048242.JavaMail.root@email> Despite the response I agree with Aaron. ----- Original Message ----- From: "michael dillon" To: arin-discuss at arin.net Sent: Thursday, May 7, 2009 9:54:46 AM GMT -07:00 US/Canada Mountain Subject: Re: [arin-discuss] IPv6 End User Assignments > however, we all really do need to be > discussing things such as v6 end user assignments. There are plenty of other places to discuss IPv6 technical issues and the biggest benefit of going elsewhere is that you can find some expert advice there. > I want so > badly for this to be a positive and educational experience > for all of us. So do I. That is why I collected and wrote up about half of the content on ARIN's IPv6 wiki at . > This list is intended to be used for discussion. Please focus > on mastering the art of leadership rather than attacking > others or nit-picking at minor and mostly off-topic points. Sorry, but I'm not here to lead anybody. This list is not for leadership, it's for discussion. I cast in my two bits worth and people either get it, or they don't. > Based on your e-mails, you appear to be an intelligent person > with exceptionally high attention to detail and with the > right focus you could really help this community. Community? I don't see any community here. Sorry but this is the ARIN members discussion list where most days, there is zero discussion. Many members don't even monitor this list. Check the archives to see what I mean. > Your > current behavior is creating a good deal of noise that is > distracting and takes away from the quality of the discussion. And you're behavior is distracting us from the discussion of the topic in the subject line. IPv6 end user assignments. Start by reading and then if you want to see where it came from, follow up the RFCs and Internet drafts referenced on it. You could also Google for something like "dillon nanog ipv6 addressing" and pick up the original discussions that led to this page. It was well over a year ago, maybe two. And if you know of an IPv6 deployment mailing list other than NANOG, feel free to tell us all about it. --Michael Dillon _______________________________________________ ARIN-Discuss You are receiving this message because you are subscribed to the ARIN Discussion Mailing List (ARIN-discuss at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-discuss Please contact info at arin.net if you experience any issues. Andy Alvarado Systems Administrator From Matthew.Wilder at telus.com Thu May 7 12:19:23 2009 From: Matthew.Wilder at telus.com (Matthew Wilder) Date: Thu, 7 May 2009 10:19:23 -0600 Subject: [arin-discuss] IPv6 End User Assignments In-Reply-To: <28E139F46D45AF49A31950F88C497458F87D82@E03MVZ2-UKDY.domain1.systemhost.net> References: <20090507153811.GM67888@trace.bind.com> <28E139F46D45AF49A31950F88C497458F87D82@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: Michael, I have to agree very strongly with Aaron. I would rather you stay out of the conversation if you want to communicate as harshly and disrespectfully as you are. Please don't point out how you are gathering all kinds of information and promoting understanding in one phrase, and then indicate you are not here to lead anybody in another. I can only assume from this you are either insane, or have a gross misunderstanding of the word leadership. This is indeed a community. Until you entered the discussion, people were learning about the best practices of IPv6 deployment. You are certainly making it hard for that conversation to continue. Hoping you can change your approach, Matthew Wilder Michael Dillon wrote: > There are plenty of other places to discuss IPv6 technical issues > and the biggest benefit of going elsewhere is that you can find some > expert advice there. > > Sorry, but I'm not here to lead anybody. This list is not for > leadership, it's for discussion. I cast in my two bits worth and people > either get it, or they don't. > > Community? I don't see any community here. Sorry but this is the ARIN > members discussion list where most days, there is zero discussion. Many > members don't even monitor this list. > Check the archives to see what I mean. > > And you're behavior is distracting us from the discussion of the topic > in the subject line. IPv6 end user assignments. > > Start by reading > > and then if you want to see where it came from, follow up the RFCs and > Internet drafts referenced on it. You could also Google for something > like "dillon nanog ipv6 addressing" and pick up the original discussions > that led to this page. It was well over a year ago, maybe two. > > And if you know of an IPv6 deployment mailing list other than NANOG, > feel free to tell us all about it. From dwhite at olp.net Thu May 7 12:22:30 2009 From: dwhite at olp.net (Dan White) Date: Thu, 07 May 2009 11:22:30 -0500 Subject: [arin-discuss] IPv6 End User Assignments In-Reply-To: <28E139F46D45AF49A31950F88C497458F87D82@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458F87D82@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <4A030AC6.6060401@olp.net> michael.dillon at bt.com wrote: > And if you know of an IPv6 deployment mailing list other than NANOG, > feel free to tell us all about it. > ipv6-ops: http://lists.cluenet.de/mailman/listinfo/ipv6-ops - Dan From bpasdar at batblue.com Thu May 7 12:27:18 2009 From: bpasdar at batblue.com (Babak Pasdar) Date: Thu, 07 May 2009 12:27:18 -0400 Subject: [arin-discuss] IPv6 End User Assignments In-Reply-To: 2062645653.42031241712048242.JavaMail.root@email Message-ID: <20090507162718.8684b784@concur.batblue.com> I agree with Aaron as well and compliment him on his most positive minded response. Most notedly, I do consider this a "Community," and am not the least bit interested in the consistently abusive tone and tenor of the gentleman who has decided he speaks for all of us. Well done Aaron and you have my support. I agree that we do need to dialouge and collaborate to get to a comfortable point with IPv6. Babak _____ From: Andy Alvarado [mailto:andya at brin.com] To: michael.dillon at bt.com, aaronh at bind.com Cc: arin-discuss at arin.net Sent: Thu, 07 May 2009 12:00:48 -0400 Subject: Re: [arin-discuss] IPv6 End User Assignments Despite the response I agree with Aaron. ----- Original Message ----- From: "michael dillon" To: arin-discuss at arin.net Sent: Thursday, May 7, 2009 9:54:46 AM GMT -07:00 US/Canada Mountain Subject: Re: [arin-discuss] IPv6 End User Assignments > however, we all really do need to be > discussing things such as v6 end user assignments. There are plenty of other places to discuss IPv6 technical issues and the biggest benefit of going elsewhere is that you can find some expert advice there. > I want so > badly for this to be a positive and educational experience > for all of us. So do I. That is why I collected and wrote up about half of the content on ARIN's IPv6 wiki at . > This list is intended to be used for discussion. Please focus > on mastering the art of leadership rather than attacking > others or nit-picking at minor and mostly off-topic points. Sorry, but I'm not here to lead anybody. This list is not for leadership, it's for discussion. I cast in my two bits worth and people either get it, or they don't. > Based on your e-mails, you appear to be an intelligent person > with exceptionally high attention to detail and with the > right focus you could really help this community. Community? I don't see any community here. Sorry but this is the ARIN members discussion list where most days, there is zero discussion. Many members don't even monitor this list. Check the archives to see what I mean. > Your > current behavior is creating a good deal of noise that is > distracting and takes away from the quality of the discussion. And you're behavior is distracting us from the discussion of the topic in the subject line. IPv6 end user assignments. Start by reading and then if you want to see where it came from, follow up the RFCs and Internet drafts referenced on it. You could also Google for something like "dillon nanog ipv6 addressing" and pick up the original discussions that led to this page. It was well over a year ago, maybe two. And if you know of an IPv6 deployment mailing list other than NANOG, feel free to tell us all about it. --Michael Dillon _______________________________________________ ARIN-Discuss You are receiving this message because you are subscribed to the ARIN Discussion Mailing List (ARIN-discuss at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-discuss Please contact info at arin.net if you experience any issues. Andy Alvarado Systems Administrator _______________________________________________ ARIN-Discuss You are receiving this message because you are subscribed to the ARIN Discussion Mailing List (ARIN-discuss at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-discuss Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.dillon at bt.com Thu May 7 14:50:48 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 7 May 2009 19:50:48 +0100 Subject: [arin-discuss] IPv6 End User Assignments In-Reply-To: <4A030AC6.6060401@olp.net> Message-ID: <28E139F46D45AF49A31950F88C497458FFC575@E03MVZ2-UKDY.domain1.systemhost.net> > ipv6-ops: > > http://lists.cluenet.de/mailman/listinfo/ipv6-ops I looked through the archives for March and April and saw that there are several real IPv6 experts on that list who have many years of experience with IPv6 deployment. Regardless of Mr. Wilder's opinions, that list is a far better place to discuss IPv6 technical issues like addressing plans. This list is only for ARIN member representatives to discuss things. Only ARIN member reps can join this list. It seems to me that it is best to reserve this list for discussion of ARIN issues that directly pertain to the members, such as fees, member meetings, and so on. --Michael Dillon From Matthew.Wilder at telus.com Thu May 7 15:11:52 2009 From: Matthew.Wilder at telus.com (Matthew Wilder) Date: Thu, 7 May 2009 13:11:52 -0600 Subject: [arin-discuss] IPv6 End User Assignments In-Reply-To: <28E139F46D45AF49A31950F88C497458FFC575@E03MVZ2-UKDY.domain1.systemhost.net> References: <4A030AC6.6060401@olp.net> <28E139F46D45AF49A31950F88C497458FFC575@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: Michael, Please tell me which mailing list would be more appropriate to discuss the interpretation of ARIN's NRPM. I am not proposing a new policy. I originally asked the question of what size IPv6 end user assignments are appropriate because I was seeing information that was apparently in conflict with the NRPM. The NRPM points to the use of /56 subnets for customers who might like to subnet but are not "large sites". And yet I was seeing people talking about /48 subnets being used for households. This apparent conflict, in my mind, was worthy of discussion. If you are beyond that discussion, that's alright, just stay out. For the rest of us who are adults, I would ask that you not hinder this discussion. MW Michael Dillon wrote: > Regardless of Mr. Wilder's opinions, that list is a far better place > to discuss IPv6 technical issues like addressing plans. This list is > only for ARIN member representatives to discuss things. Only ARIN > member reps can join this list. > > It seems to me that it is best to reserve this list for discussion of > ARIN issues that directly pertain to the members, such as fees, member > meetings, and so on. From mrjim at nttec.com Thu May 7 19:16:30 2009 From: mrjim at nttec.com (Jim) Date: Fri, 08 May 2009 07:16:30 +0800 Subject: [arin-discuss] IPv6 End User Assignments In-Reply-To: <20090507153811.GM67888@trace.bind.com> References: <20090506175911.GH67888@trace.bind.com> <28E139F46D45AF49A31950F88C497458F8732C@E03MVZ2-UKDY.domain1.systemhost.net> <20090507153811.GM67888@trace.bind.com> Message-ID: <1241738190.17181.96.camel@xerxes.racequeen.local> Dear Michael, I think most of the people are reading this discussion on ipv6. Yours reply was a disheartening but polite RTFM answer. There are a lot of people that are not engineers on this listserv, and the emails that have been coming are finally something a non geek like me can understand. I have already put my engineers to work on reading the manual and implementing ipv6 in everyplace we can possibly do it, because of these emails. Please don't discourage the discussion. Sincerely, Jim On Thu, 2009-05-07 at 08:38 -0700, Aaron Hughes wrote: > Michael, > > E-mail such as yours is disheartening and drives me toward unsubscribing, however, we all really do need to be discussing things such as v6 end user assignments. I want so badly for this to be a positive and educational experience for all of us. > > This list is intended to be used for discussion. Please focus on mastering the art of leadership rather than attacking others or nit-picking at minor and mostly off-topic points. > > Based on your e-mails, you appear to be an intelligent person with exceptionally high attention to detail and with the right focus you could really help this community. Your current behavior is creating a good deal of noise that is distracting and takes away from the quality of the discussion. > > I hope I speak for everyone when I ask for you to reflect upon your delivery and ask that you please take the time to think about the community and the individuals you are interacting with before sending future e-mail. > > Aaron > > > > > On Thu, May 07, 2009 at 09:09:16AM +0100, michael.dillon at bt.com wrote: > > > As architects in the planning phase of a v6 roll-out we get > > > to plan for company needs, customer needs, aggregation, > > > reachability, scalability, etc etc etc. One of the aspects we > > > should all evaluate is wasting space. > > > > NO! > > > > First of all, don't call yourself an architect if you know > > nothing about the technology. Architects start by learning > > how things work, then and only then, do they design and plan. > > You have a warped sense of size and waste. A /21 is hardly > > massive. With IPv4 I have received several /16 allocations > > from ARIN, and in IPv6, a /21 or /16 represents the same > > proportion of the total address space. In the IPv4 world > > an ISP with a /21 is a small ISP in a single town. Waste > > is simply not an issue with IPv6. > > > > > When I rolled out v6 to my customers, I made the company > > > policy decision to assign /64s to customers by default and > > > /48s to those who requested more than one subnet. This made > > > it rather easy to have 2 pools of aggregatable regional space > > > for customer assignments. > > > > Some of use prefer one pool which can be achieved by giving > > everyone a /48. On the business side of things, when competitors > > appear offering a /48, this means that you would already > > be at parity instead of losing customers steadily because of > > your stinginess. If I were in your market, I would portray > > this as evidence of your technical incompetence to encourage > > your customers to jump ship. (Note that I don't run an ISP > > so there is no danger of me personally being in your market). > > > > > It is highly unlikely that very large ISPs will be assigning > > > 48s to each customer as it would be a waste of space. > > > > It is not a waste of space. Very large ISPs in Europe and > > Asia already do assign /48s to each customer. ARIN policy > > allows it in North America as well. > > > > > I am involved in many v6 implementations and none of them > > > assign 48s by default. > > > > No doubt due to your influence. But sooner or later these > > people will educate themselves about IPv6 and will be unhappy > > with the way that you forced them down an unsustainable path. > > > > --Michael Dillon > > -- > > ARIN-Discuss > > You are receiving this message because you are subscribed to > > the ARIN Discussion Mailing List (ARIN-discuss at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-discuss > > Please contact info at arin.net if you experience any issues. > From steve at ibctech.ca Thu May 7 23:22:44 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Thu, 07 May 2009 23:22:44 -0400 Subject: [arin-discuss] IPv6 End User Assignments In-Reply-To: <1241738190.17181.96.camel@xerxes.racequeen.local> References: <20090506175911.GH67888@trace.bind.com> <28E139F46D45AF49A31950F88C497458F8732C@E03MVZ2-UKDY.domain1.systemhost.net> <20090507153811.GM67888@trace.bind.com> <1241738190.17181.96.camel@xerxes.racequeen.local> Message-ID: <4A03A584.6090007@ibctech.ca> Jim wrote: > Dear Michael, > > I think most of the people are reading this discussion on ipv6. > Yours reply was a disheartening but polite RTFM answer. > > There are a lot of people that are not engineers on this listserv, > and the emails that have been coming are finally something a non geek > like me can understand. I have already put my engineers to work on > reading the manual and implementing ipv6 in everyplace we can possibly > do it, because of these emails. > > Please don't discourage the discussion. I'm but a humble /21 & /32 holder who soaks in everything that can be said about IPv6. In no way do I want to take away from any discussion, nor am I on any 'side', but being an insignificant piece in this puzzle, I can't see how it would hurt for me to say how I can see perhaps how one specific response of Mr. Dillon's could have been a bit disruptive. Perhaps it would be prudent for everyone to just take a breath, and recall that we are all in this together. I'm a relative 'newbie' in this game, but I do follow as closely as possible. Mr. Dillon has *always* had decent and respectable feedback toward IPv6, both in operational and business practises, and his feedback should be taken with a little bit of weight, as should other members who have a significant tally of quality posts. Who gives a fsck about feelings. Someone needs to sort this out. We need: - operational experience feedback - political ideals feedback - business case feedback ...whether it happens on one list or three, just provide something so we get an RFC, and then can produce conclusive policy, mkay? - /56 to every client, with the surrounding /48 reserved, in case that becomes policy - /64 from PE to CE for routability ...that is how this small ISP sees things. Steve From josmon at rigozsaurus.com Fri May 8 02:46:11 2009 From: josmon at rigozsaurus.com (John Osmon) Date: Fri, 8 May 2009 00:46:11 -0600 Subject: [arin-discuss] IPv6 End User Assignments In-Reply-To: <4A03A584.6090007@ibctech.ca> References: <20090506175911.GH67888@trace.bind.com> <28E139F46D45AF49A31950F88C497458F8732C@E03MVZ2-UKDY.domain1.systemhost.net> <20090507153811.GM67888@trace.bind.com> <1241738190.17181.96.camel@xerxes.racequeen.local> <4A03A584.6090007@ibctech.ca> Message-ID: <20090508064611.GA31239@jeeves.rigozsaurus.com> On Thu, May 07, 2009 at 11:22:44PM -0400, Steve Bertrand wrote: [...] > Who gives a fsck about feelings. Someone needs to sort this out. We need: > > - operational experience feedback > - political ideals feedback > - business case feedback > > ...whether it happens on one list or three, just provide something so we > get an RFC, and then can produce conclusive policy, mkay? > > - /56 to every client, with the surrounding /48 reserved, in case that > becomes policy > - /64 from PE to CE for routability > > ...that is how this small ISP sees things. Thanks Steve. You put into words what I'd been thinking (and much more concisely). Folks: Do what you think is right -- but *tell* folks what you're doing (and why). We need more operational experience with IPv6. Both *good* and *bad*. Hopefully, we'll learn the right lessons from each. From gdolley at arpnetworks.com Fri May 8 07:16:05 2009 From: gdolley at arpnetworks.com (Garry Dolley) Date: Fri, 8 May 2009 04:16:05 -0700 Subject: [arin-discuss] IPv6 End User Assignments In-Reply-To: <4A02F159.5010808@olp.net> References: <28E139F46D45AF49A31950F88C497458F8732C@E03MVZ2-UKDY.domain1.systemhost.net> <4A02E874.6020408@chl.com> <4A02F159.5010808@olp.net> Message-ID: <20090508111605.GA29601@garry-thinkpad.arpnetworks.com> On Thu, May 07, 2009 at 09:34:01AM -0500, Dan White wrote: > Joe Maimon wrote: > > michael.dillon at bt.com wrote: > > > > > >> It is not a waste of space. Very large ISPs in Europe and > >> Asia already do assign /48s to each customer. ARIN policy > >> allows it in North America as well. > >> > >> > > > > Only large ISP's can afford to do so with impunity. A /32 is not > > sufficient for a default allocation of /48 per customer. That makes it > > effectively only 16 times larger than an ipv4 /20, which suggests > > additional prefixes or renumbering pain. > > > > A /24 or /28 would be better if indeed /48 per customer is expected to > > be the norm. > > > > People are trying to carve up their allocated space now, in an > > intelligent manner as much as possible. Getting it right at this point > > could avoid pain later, so this is important. > > > > To me, the conservative approach is to assign a /48 to each customer. To > do so means that they will never need to ask for more addresses again > (in most cases), regardless of their size... and as their provider, it's > doesn't make sense to me to suggest what their network should look like > today, or what it likely will look like in 5, 10 or 20 years. > > I tend to stay away from the approach of allocating small subnets today, > and then allocate larger ones based on customer need. I prefer to do the > heavy lifting up front - /48 via prefix delegation or routing protocol - > which will save me the work of reconfiguration their allocation down the > road. > > > A /32 is not sufficient for a default allocation of /48 per customer. > > That makes it effectively only 16 times larger than an ipv4 /20 > > I have two /20 IPv4 allocations, which gives me 8192 possible customers > (and I have many less than that). I have a /32 IPv6 allocation which > gives me 65536 possible customers at /48, which should easily last me 30 > years to retirement! But that 8192 possible customers is if you only give 1 IP per customer (/32) and you have one huge subnet (the /20 itself); isn't that a bit unrealistic? I mean customers will want /29, /28's, etc... no? Most of my customers request more than 1 IP. I see what you're saying mathematically, but still... The 65536 /48's within your /32 is more realistic given that a /48 is probably enough for most customers. They can subnet all they like and still have a lot of addresses. You could indeed sustain 65K customers in your /32 and give them all /48's. -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st From gdolley at arpnetworks.com Fri May 8 07:39:16 2009 From: gdolley at arpnetworks.com (Garry Dolley) Date: Fri, 8 May 2009 04:39:16 -0700 Subject: [arin-discuss] IPv6 End User Assignments In-Reply-To: <588DD93F-F1CD-4AFA-8129-6552008ADBF3@delong.com> References: <588DD93F-F1CD-4AFA-8129-6552008ADBF3@delong.com> Message-ID: <20090508113916.GB29601@garry-thinkpad.arpnetworks.com> On Wed, May 06, 2009 at 03:12:44PM -0700, Owen DeLong wrote: > > On May 6, 2009, at 7:43 AM, Matthew Wilder wrote: > >> My understanding of /48 is along with the NRPM: that /48 subnets are for >> "larger sites". Not many consumers would use much of their 65,536 /64 >> subnets in a /48 (at least in my estimation). >> > I have a /48 for my household and expect to use more than 256 subnets over > time. The > bottom line is that in IPv6, you don't really think about how much of > 65,536 subnets > will they use, but, rather, is there a chance of using more than 256? OK... > The next > boundary tends to default to /48. If you don't mind me asking, what kinds of applications / equipment / use-cases are you running in your household that would require more than 256 subnets? -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st From michael.dillon at bt.com Fri May 8 07:40:11 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 8 May 2009 12:40:11 +0100 Subject: [arin-discuss] IPv6 End User Assignments In-Reply-To: <20090508111605.GA29601@garry-thinkpad.arpnetworks.com> Message-ID: <28E139F46D45AF49A31950F88C497458FFCBF6@E03MVZ2-UKDY.domain1.systemhost.net> > But that 8192 possible customers is if you only give 1 IP per > customer (/32) and you have one huge subnet (the /20 itself); > The 65536 /48's within your /32 is more realistic given that > a /48 is probably enough for most customers. They can subnet > all they like and still have a lot of addresses. You could > indeed sustain 65K customers in your /32 and give them all /48's. This is a nice illustration of how much more efficient IPv6 is even though you give a /48 per customer, and they use a whole /64 per subnet regardless of the number of devices. We've moved from a /32 being enough for one customer (maybe), to a /32 being enough for an entire ISP. A lot of ISPs fall into the size range where this is possible. --Michael Dillon From dwhite at olp.net Fri May 8 09:51:33 2009 From: dwhite at olp.net (Dan White) Date: Fri, 08 May 2009 08:51:33 -0500 Subject: [arin-discuss] IPv6 End User Assignments In-Reply-To: <20090508113916.GB29601@garry-thinkpad.arpnetworks.com> References: <588DD93F-F1CD-4AFA-8129-6552008ADBF3@delong.com> <20090508113916.GB29601@garry-thinkpad.arpnetworks.com> Message-ID: <4A0438E5.9090700@olp.net> Garry Dolley wrote: > But that 8192 possible customers is if you only give 1 IP per > customer (/32) and you have one huge subnet (the /20 itself); isn't > that a bit unrealistic? I mean customers will want /29, /28's, > etc... no? Most of my customers request more than 1 IP. I agree. I was trying to counter point the argument that a /32 IPv6 assignment was not sufficient for a current ISP with an IPv4 /20 (give or take). Clearly it is more than sufficient in my scenario. For IPv6, we need to think in terms of *customers*, not IP addresses. Today, a /20 represents < 4096 customers, but probably represents much less than that. In IPv6, a /32 represents 65536 customers assuming /48 assignments. > If you don't mind me asking, what kinds of applications / equipment > / use-cases are you running in your household that would require > more than 256 subnets? > > Me personally? I expect at some point my network to look roughly like: a /64 for networking equipment/management a /64 for trusted wireless connections a /64 for friends'/visitors' wireless connections (maybe one per friend) a /64 for mobile IPv6 a /64 for trusted wired connections (PCs) a /64 for a server DMZ a /64 for black boxes that I don't have OS level access to (toaters!). Potentially multiple /64s for these, since I may want layer two separation between them. That's probably about as large as I can see getting. But I'm not about to make any assumptions about other customers' connections, or how they may desire to subnet in the next 50 years. I have customers with multiple locations, which will require them to split their /48. - Dan From bicknell at ufp.org Fri May 8 10:23:22 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 8 May 2009 10:23:22 -0400 Subject: [arin-discuss] IPv6 End User Assignments In-Reply-To: <4A0438E5.9090700@olp.net> References: <588DD93F-F1CD-4AFA-8129-6552008ADBF3@delong.com> <20090508113916.GB29601@garry-thinkpad.arpnetworks.com> <4A0438E5.9090700@olp.net> Message-ID: <20090508142322.GA37746@ussenterprise.ufp.org> In a message written on Fri, May 08, 2009 at 08:51:33AM -0500, Dan White wrote: > For IPv6, we need to think in terms of *customers*, not IP addresses. > Today, a /20 represents < 4096 customers, but probably represents much > less than that. In IPv6, a /32 represents 65536 customers assuming /48 > assignments. Actually, the IPv6 folks for years have been saying the correct way to think is in terms of *subnets*. With 2^64 hosts per subnet you never have to worry about running out of addresses on a particular subnet. Thus the entire question becomes how many subnets do you need to divide things administratively? -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 825 bytes Desc: not available URL: From gdolley at arpnetworks.com Fri May 8 15:38:12 2009 From: gdolley at arpnetworks.com (Garry Dolley) Date: Fri, 8 May 2009 12:38:12 -0700 Subject: [arin-discuss] IPv6 End User Assignments In-Reply-To: <4A0438E5.9090700@olp.net> References: <588DD93F-F1CD-4AFA-8129-6552008ADBF3@delong.com> <20090508113916.GB29601@garry-thinkpad.arpnetworks.com> <4A0438E5.9090700@olp.net> Message-ID: <20090508193812.GB20258@garry-thinkpad.arpnetworks.com> On Fri, May 08, 2009 at 08:51:33AM -0500, Dan White wrote: > Garry Dolley wrote: > >> But that 8192 possible customers is if you only give 1 IP per >> customer (/32) and you have one huge subnet (the /20 itself); isn't >> that a bit unrealistic? I mean customers will want /29, /28's, >> etc... no? Most of my customers request more than 1 IP. > > > I agree. I was trying to counter point the argument that a /32 IPv6 > assignment was not sufficient for a current ISP with an IPv4 /20 (give or > take). Clearly it is more than sufficient in my scenario. > > For IPv6, we need to think in terms of *customers*, not IP addresses. > Today, a /20 represents < 4096 customers, but probably represents much less > than that. In IPv6, a /32 represents 65536 customers assuming /48 > assignments. Ah, roger that. Makes sense. > Me personally? I expect at some point my network to look roughly like: > > a /64 for networking equipment/management > a /64 for trusted wireless connections > a /64 for friends'/visitors' wireless connections (maybe one per friend) > a /64 for mobile IPv6 > a /64 for trusted wired connections (PCs) > a /64 for a server DMZ > a /64 for black boxes that I don't have OS level access to (toaters!). > Potentially multiple /64s for these, since I may want layer two separation > between them. > > That's probably about as large as I can see getting. > > But I'm not about to make any assumptions about other customers' > connections, or how they may desire to subnet in the next 50 years. I have > customers with multiple locations, which will require them to split their > /48. Yeah, I was just wondering. > 256 subnets in a household seems like a lot, but judging from your examples above and if you have to support friends/visitors/others in your area, then that could quickly grow. Understood. -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st From gdolley at arpnetworks.com Fri May 8 18:24:28 2009 From: gdolley at arpnetworks.com (Garry Dolley) Date: Fri, 8 May 2009 15:24:28 -0700 Subject: [arin-discuss] IPv6 End User Assignments In-Reply-To: <28E139F46D45AF49A31950F88C497458F86FF6@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458F86FF6@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <20090508222428.GB7774@garry-thinkpad.arpnetworks.com> On Wed, May 06, 2009 at 04:30:27PM +0100, michael.dillon at bt.com wrote: > > So, all this back to the original question: > > What kind of IPv6 subnet would YOU expect a North American > > ISP to assign to their residential ADSL customer? > > /48 as per standard. What standard are you referring to? >From what I'm reading, a longer prefix, such as /56 is acceptable: "Ideally, residential networks would be given an address range of a /48 or /56 [RIPE_Nov07] such that multiple /64 subnets could be used within the residence." [1] 1. RFC 5375 - IPv6 Unicast Address Assignment Considerations, Section 2.4 -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st From michael.dillon at bt.com Sat May 9 08:21:29 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Sat, 9 May 2009 13:21:29 +0100 Subject: [arin-discuss] IPv6 End User Assignments In-Reply-To: <20090508222428.GB7774@garry-thinkpad.arpnetworks.com> Message-ID: <28E139F46D45AF49A31950F88C497458FFD28D@E03MVZ2-UKDY.domain1.systemhost.net> > > /48 as per standard. > > What standard are you referring to? None. "As per standard" is a colloquial way of saying "standard practice" which refers to the way that people have been doing things for the past few years. Of course it all started with an RFC like 3177 which says: -----quoted text------ This document provides recommendations to the addressing registries (APNIC, ARIN and RIPE-NCC) on policies for assigning IPv6 address blocks to end sites. In particular, it recommends the assignment of /48 in the general case, /64 when it is known that one and only one subnet is needed and /128 when it is absolutely known that one and only one device is connecting. The original recommendations were made in an IAB/IESG statement mailed to the registries on September 1, 2000. This document refines the original recommendation and documents it for the historical record. -----end quote------- > From what I'm reading, a longer prefix, such as /56 is acceptable: Yes it is acceptable but it is not standard practice. That change to policy was adopted to address an issue that a few very large ISPs have with the HD ratio. The change was introduced with policy proposal 2005-8 but please note the first sentence of the policy text of these guidelines: The following guidelines may be useful (but they are only guidelines): - /64 when it is known that one and only one subnet is needed - /56 for small sites, those expected to need only a few subnets over the next 5 years. - /48 for larger sites A large part of the rationale for this change to allow /56 was in an earlier version of this Internet draft: There is a good section there explaining how /56 for residential users still maintains RFC 3177's goals. > "Ideally, residential networks would be given an address range of a > /48 or /56 [RIPE_Nov07] such that multiple /64 subnets could > be used within the residence." [1] > > 1. RFC 5375 - IPv6 Unicast Address Assignment Considerations, > Section 2.4 Like I said, /48 for residential networks is still standard practice. I believe that the idea for a /56 first came from Geoff Huston in this analysis: If you have a network architecture which requires you to assign /48s to each POTENTIAL customer, then you are at risk of not qualifying for additional blocks because ARIN only counts ACTUAL customers. But, if you assign /56s to each POTENTIAL customer, you are almost certain to never need to go back to ARIN. Some cable providers need to assign a block to every residence that their cable goes past, which is why the policy was changed to allow for /56 assignments. And, as the policy states, these are only guidelines. Some ISPs will need to assign a /47 or /46 per customer because their business model requires it. Maybe they specialise in connecting hotels who have a complex subnet plan to accomodate guest wifi subnets, room TV subnets, room telephony subnets, maid subnets per trolley, management subnets per section of each floor, banquet room subnets, conference subnets per kiosk, kitchen subnets, staff network subnets, bar wifi subnet, restaurant staff subnets, and lord knows what else. ARIN cannot dictate one size fits all, because increasingly, the ISP business is diversifying and there are all kinds of strange things out there. --Michael Dillon From gdolley at arpnetworks.com Mon May 11 14:56:20 2009 From: gdolley at arpnetworks.com (Garry Dolley) Date: Mon, 11 May 2009 11:56:20 -0700 Subject: [arin-discuss] IPv6 End User Assignments In-Reply-To: <28E139F46D45AF49A31950F88C497458FFD28D@E03MVZ2-UKDY.domain1.systemhost.net> References: <20090508222428.GB7774@garry-thinkpad.arpnetworks.com> <28E139F46D45AF49A31950F88C497458FFD28D@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <20090511185618.GA362@garry-thinkpad.arpnetworks.com> On Sat, May 09, 2009 at 01:21:29PM +0100, michael.dillon at bt.com wrote: > > > /48 as per standard. > > > > What standard are you referring to? > > None. > "As per standard" is a colloquial way of saying "standard > practice" which refers to the way that people have been > doing things for the past few years. Of course it all > started with an RFC like 3177 which says: > > -----quoted text------ > This document provides recommendations to the addressing registries > (APNIC, ARIN and RIPE-NCC) on policies for assigning IPv6 address blocks > to end sites. In particular, it recommends the assignment of > > /48 in the general case, /64 when it is known that one and only one > subnet is needed and /128 when it is absolutely known that one and > only one device is connecting. > > The original recommendations were made in an IAB/IESG statement mailed > to the registries on September 1, 2000. This document refines the > original recommendation and documents it for the historical record. > -----end quote------- > > > From what I'm reading, a longer prefix, such as /56 is acceptable: > > Yes it is acceptable but it is not standard practice. That change to > policy was adopted to address an issue that a few very large ISPs > have with the HD ratio. > > The change was introduced with policy proposal 2005-8 > but please note the first sentence of the policy text > of these guidelines: > > The following guidelines may be useful > (but they are only guidelines): > - /64 when it is known that one and only > one subnet is needed > - /56 for small sites, those expected to > need only a few subnets over the next 5 years. > - /48 for larger sites > > A large part of the rationale for this change to allow /56 > was in an earlier version of this Internet draft: > y/index.html> > > There is a good section there explaining how /56 for > residential users still maintains RFC 3177's goals. > > > "Ideally, residential networks would be given an address range of a > > /48 or /56 [RIPE_Nov07] such that multiple /64 subnets could > > be used within the residence." [1] > > > > 1. RFC 5375 - IPv6 Unicast Address Assignment Considerations, > > Section 2.4 > > Like I said, /48 for residential networks is still > standard practice. > > I believe that the idea for a /56 first came from > Geoff Huston in this analysis: > > > If you have a network architecture which requires you > to assign /48s to each POTENTIAL customer, then you > are at risk of not qualifying for additional blocks > because ARIN only counts ACTUAL customers. But, if > you assign /56s to each POTENTIAL customer, you are > almost certain to never need to go back to ARIN. > Some cable providers need to assign a block to every > residence that their cable goes past, which is why > the policy was changed to allow for /56 assignments. > > And, as the policy states, these are only guidelines. > Some ISPs will need to assign a /47 or /46 per customer > because their business model requires it. Maybe they > specialise in connecting hotels who have a complex > subnet plan to accomodate guest wifi subnets, room > TV subnets, room telephony subnets, maid subnets per > trolley, management subnets per section of each > floor, banquet room subnets, conference subnets per > kiosk, kitchen subnets, staff network subnets, bar > wifi subnet, restaurant staff subnets, and lord knows > what else. ARIN cannot dictate one size fits all, > because increasingly, the ISP business is diversifying > and there are all kinds of strange things out there. > > --Michael Dillon Yeah, I understand what you're saying now. I've been reading RFC 3177 and 5375, and indeed /48 is the standard assignment. I won't plan to assign /64's to my customers b/c I can't be sure they are not going to want to subnet, therefore I should give them the room to do that with a /48. To those on the list that mentioned they are defaulting to /64's, I suggest you read RFC 3177 and 5375, and consider /48's. -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st From chris at uplogon.com Mon May 11 15:00:31 2009 From: chris at uplogon.com (Chris Gotstein) Date: Mon, 11 May 2009 14:00:31 -0500 Subject: [arin-discuss] IPv6 End User Assignments In-Reply-To: <20090511185618.GA362@garry-thinkpad.arpnetworks.com> References: <20090508222428.GB7774@garry-thinkpad.arpnetworks.com> <28E139F46D45AF49A31950F88C497458FFD28D@E03MVZ2-UKDY.domain1.systemhost.net> <20090511185618.GA362@garry-thinkpad.arpnetworks.com> Message-ID: <4A0875CF.1000803@uplogon.com> Garry Dolley wrote: > Yeah, I understand what you're saying now. I've been reading RFC > 3177 and 5375, and indeed /48 is the standard assignment. I won't > plan to assign /64's to my customers b/c I can't be sure they are > not going to want to subnet, therefore I should give them the room > to do that with a /48. > > To those on the list that mentioned they are defaulting to /64's, I > suggest you read RFC 3177 and 5375, and consider /48's. > When you are referring to customers, does this apply to residential end-users connected via, cable, dsl, etc? Chris Gotstein Sr Network Engineer UP Logon/Computer Connection UP 500 N Stephenson Ave Iron Mountain, MI 49801 Phone: 906-774-4847 Fax: 906-774-0335 From gdolley at arpnetworks.com Mon May 11 15:07:25 2009 From: gdolley at arpnetworks.com (Garry Dolley) Date: Mon, 11 May 2009 12:07:25 -0700 Subject: [arin-discuss] IPv6 End User Assignments In-Reply-To: <4A0875CF.1000803@uplogon.com> References: <20090508222428.GB7774@garry-thinkpad.arpnetworks.com> <28E139F46D45AF49A31950F88C497458FFD28D@E03MVZ2-UKDY.domain1.systemhost.net> <20090511185618.GA362@garry-thinkpad.arpnetworks.com> <4A0875CF.1000803@uplogon.com> Message-ID: <20090511190725.GA4979@garry-thinkpad.arpnetworks.com> On Mon, May 11, 2009 at 02:00:31PM -0500, Chris Gotstein wrote: > Garry Dolley wrote: > >> Yeah, I understand what you're saying now. I've been reading RFC >> 3177 and 5375, and indeed /48 is the standard assignment. I won't >> plan to assign /64's to my customers b/c I can't be sure they are >> not going to want to subnet, therefore I should give them the room >> to do that with a /48. >> To those on the list that mentioned they are defaulting to /64's, I >> suggest you read RFC 3177 and 5375, and consider /48's. > > When you are referring to customers, does this apply to residential > end-users connected via, cable, dsl, etc? Yes. RFC 5375 ("IPv6 Unicast Address Assignment Considerations") specifically mentions residential sites / customers: "Consider assigning more than one /64 to a site - A small site may want to enable routing amongst interfaces connected to a gateway device. For example, a residential gateway that receives a /48 and is situated in a home with multiple LANs of different media types (sensor network, wired, Wi-Fi, etc.), or has a need for traffic segmentation (home, work, kids, etc.), could benefit greatly from multiple subnets and routing in IPv6. Ideally, residential networks would be given an address range of a /48 or /56 [RIPE_Nov07] such that multiple /64 subnets could be used within the residence." [1] 1. RFC 5375, Section 2.4 "Network-Level Design Considerations" -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st From lea.roberts at stanford.edu Mon May 11 15:30:00 2009 From: lea.roberts at stanford.edu (Lea Roberts) Date: Mon, 11 May 2009 12:30:00 -0700 (PDT) Subject: [arin-discuss] IPv6 End User Assignments In-Reply-To: <20090511190725.GA4979@garry-thinkpad.arpnetworks.com> Message-ID: Garry (et al) - On Mon, 11 May 2009, Garry Dolley wrote: > On Mon, May 11, 2009 at 02:00:31PM -0500, Chris Gotstein wrote: > > Garry Dolley wrote: > > > >> Yeah, I understand what you're saying now. I've been reading RFC > >> 3177 and 5375, and indeed /48 is the standard assignment. I won't > >> plan to assign /64's to my customers b/c I can't be sure they are > >> not going to want to subnet, therefore I should give them the room > >> to do that with a /48. > >> To those on the list that mentioned they are defaulting to /64's, I > >> suggest you read RFC 3177 and 5375, and consider /48's. > > > > When you are referring to customers, does this apply to residential > > end-users connected via, cable, dsl, etc? > > Yes. > > RFC 5375 ("IPv6 Unicast Address Assignment Considerations") > specifically mentions residential sites / customers: > > "Consider assigning more than one /64 to a site - A small site may > want to enable routing amongst interfaces connected to a gateway > device. For example, a residential gateway that receives a /48 and > is situated in a home with multiple LANs of different media types > (sensor network, wired, Wi-Fi, etc.), or has a need for traffic > segmentation (home, work, kids, etc.), could benefit greatly from > multiple subnets and routing in IPv6. Ideally, residential networks > would be given an address range of a /48 or /56 [RIPE_Nov07] such > that multiple /64 subnets could be used within the residence." [1] > > 1. RFC 5375, Section 2.4 "Network-Level Design Considerations" be advised that while RFC3177 is still "standard", there has been work in IETF to update it with "operational experience", not the least of which is that perhaps assinging a /48 to every user who wants to subnet may be a bit excessive. the /56 option for an individual residence should allow an abundance of subnets for all but extreme cases. and certainly the /64 and /128 options seem overly restrictive in the IPv6 environment. BTW, if you are delegating reverse DNS, then /60 is another small option, since IPv6 reverse is on nibble boundaries. some argue that by limiting the number of subnets to 16, it should handle most small sites but not discourage renumbering when the user's needs change... my personal feeling is that any commercial enterprise should certainly get a /48 by default and any residential user who asks for one should get it, but the default for a normal single family site should be less than /48. as others have mentioned, there are ample reasons to give all IPv6 users the ability to have multiple subnets. certainly any /64 assignments limit the real advantages of moving to IPv6. /Lea From lea.roberts at stanford.edu Mon May 11 16:09:10 2009 From: lea.roberts at stanford.edu (Lea Roberts) Date: Mon, 11 May 2009 13:09:10 -0700 (PDT) Subject: [arin-discuss] IPv6 End User Assignments In-Reply-To: <20090511185618.GA362@garry-thinkpad.arpnetworks.com> Message-ID: Garry (et al) - On Mon, 11 May 2009, Garry Dolley wrote: > Yeah, I understand what you're saying now. I've been reading RFC > 3177 and 5375, and indeed /48 is the standard assignment. I won't > plan to assign /64's to my customers b/c I can't be sure they are > not going to want to subnet, therefore I should give them the room > to do that with a /48. > > To those on the list that mentioned they are defaulting to /64's, I > suggest you read RFC 3177 and 5375, and consider /48's. X From bsmith at cctwireless.com Wed May 13 21:12:55 2009 From: bsmith at cctwireless.com (Berton) Date: Thu, 14 May 2009 01:12:55 +0000 Subject: [arin-discuss] IPv6 End User Assignments Message-ID: <186245879-1242267367-cardhu_decombobulator_blackberry.rim.net-541893815-@bxe1001.bisx.prod.on.blackberry> Ok reading now ------Original Message------ From: Garry Dolley Sender: arin-discuss-bounces at arin.net To: Chris Gotstein Cc: arin-discuss at arin.net Subject: Re: [arin-discuss] IPv6 End User Assignments Sent: May 11, 2009 4:07 PM On Mon, May 11, 2009 at 02:00:31PM -0500, Chris Gotstein wrote: > Garry Dolley wrote: > >> Yeah, I understand what you're saying now. I've been reading RFC >> 3177 and 5375, and indeed /48 is the standard assignment. I won't >> plan to assign /64's to my customers b/c I can't be sure they are >> not going to want to subnet, therefore I should give them the room >> to do that with a /48. >> To those on the list that mentioned they are defaulting to /64's, I >> suggest you read RFC 3177 and 5375, and consider /48's. > > When you are referring to customers, does this apply to residential > end-users connected via, cable, dsl, etc? Yes. RFC 5375 ("IPv6 Unicast Address Assignment Considerations") specifically mentions residential sites / customers: "Consider assigning more than one /64 to a site - A small site may want to enable routing amongst interfaces connected to a gateway device. For example, a residential gateway that receives a /48 and is situated in a home with multiple LANs of different media types (sensor network, wired, Wi-Fi, etc.), or has a need for traffic segmentation (home, work, kids, etc.), could benefit greatly from multiple subnets and routing in IPv6. Ideally, residential networks would be given an address range of a /48 or /56 [RIPE_Nov07] such that multiple /64 subnets could be used within the residence." [1] 1. RFC 5375, Section 2.4 "Network-Level Design Considerations" -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st _______________________________________________ ARIN-Discuss You are receiving this message because you are subscribed to the ARIN Discussion Mailing List (ARIN-discuss at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-discuss Please contact info at arin.net if you experience any issues. Sent from my BlackBerry? wireless device from Cable & Wireless bMobile From steve at ibctech.ca Fri May 15 19:44:43 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Fri, 15 May 2009 19:44:43 -0400 Subject: [arin-discuss] POC Reauthorization Message-ID: <4A0DFE6B.70006@ibctech.ca> hostmaster at arin.net wrote: > In an effort to ensure WHOIS accuracy, ARIN asks you to review your organization's data. This e-mail is being sent to all e-mail addresses associated with the following OrgID: > OrgID: EAGLE-28 > Below is a list of POC handles associated with the IP addresses and AS numbers registered to the organization. Please review each of these POCs in ARIN WHOIS to ensure the data is accurate. > > https://ws.arin.net/whois/?queryinput=SBE96-ARIN [..snip..] The above snipped message I received from ARIN requested that I ensure all POC data to be correct, and to fix the POC objects that need to be updated. Since the message did not ask me to verify my POC information, I know the message can't be related to 2008-7. I've discussed this with a few people off-list, but I'm going to ask this publicly anyway: Why-oh-why, if ARIN is sending out these messages (from what I can tell) to test for bounces, is it not including something to inform the valid POC(s) about the impending IPv4 problem, and what its successor is? What I mean to say, is that I won't mind a little 'on the side' consultancy work when the "we don't need IPv6 right now" are scrambling, but I'm sure that there are small ops out there who may still be in the dark. I discussed privately with a few about using 2008-7 as a vehicle to include a blurb about the v4 runout (and it's urgency), and understandably, I gathered that ARIN may not want to appear as to be sending 'unsolicited' email. However, given that the message I received was 'unsolicited' (and doesn't look like it requires any action on my part), how bad can it hurt if there was even an informational _signature_ appended to it? I'm an op/engineer, so it would be great if someone could explain to me the logic behind not wanting to use POC verification messages as vehicles to inform/remind the number resource holders that time is up... Steve From tedm at ipinc.net Fri May 15 20:35:26 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 15 May 2009 17:35:26 -0700 Subject: [arin-discuss] POC Reauthorization In-Reply-To: <4A0DFE6B.70006@ibctech.ca> References: <4A0DFE6B.70006@ibctech.ca> Message-ID: <413D364F8EF941C7949045F0639A7B0C@tedsdesk> > -----Original Message----- > From: arin-discuss-bounces at arin.net > [mailto:arin-discuss-bounces at arin.net] On Behalf Of Steve Bertrand > Sent: Friday, May 15, 2009 4:45 PM > To: arin-discuss at arin.net > Subject: [arin-discuss] POC Reauthorization > > hostmaster at arin.net wrote: > > > In an effort to ensure WHOIS accuracy, ARIN asks you to > review your organization's data. This e-mail is being sent to > all e-mail addresses associated with the following OrgID: > > > OrgID: EAGLE-28 > > > Below is a list of POC handles associated with the IP > addresses and AS numbers registered to the organization. > Please review each of these POCs in ARIN WHOIS to ensure the > data is accurate. > > > > https://ws.arin.net/whois/?queryinput=SBE96-ARIN > > [..snip..] > > The above snipped message I received from ARIN requested that > I ensure all POC data to be correct, and to fix the POC > objects that need to be updated. > > Since the message did not ask me to verify my POC > information, I know the message can't be related to 2008-7. > Correct. When I sent in my policy proposal for POC cleanup that was later merged with 3 other proposals to create 2008-7, I -also- at the same time sent in a suggestion via the ARIN suggestion box to start testing POC entries. The suggestion was PARTIALLY complied with. Essentially, ARIN was fine with beginning to do this testing - but had to have an NRPM policy change to actually DO anything about failed responses. I suspect also that they only started testing the largest block holders. The tests your getting are completely voluntary. You can ignore them and nothing will happen. 2008-7 changes that, of course. > I've discussed this with a few people off-list, but I'm going > to ask this publicly anyway: > > Why-oh-why, if ARIN is sending out these messages (from what > I can tell) to test for bounces, is it not including > something to inform the valid > POC(s) about the impending IPv4 problem, and what its successor is? > > What I mean to say, is that I won't mind a little 'on the side' > consultancy work when the "we don't need IPv6 right now" are > scrambling, but I'm sure that there are small ops out there > who may still be in the dark. > > I discussed privately with a few about using 2008-7 as a > vehicle to include a blurb about the v4 runout (and it's > urgency), and understandably, I gathered that ARIN may not > want to appear as to be sending 'unsolicited' email. > > However, given that the message I received was 'unsolicited' > (and doesn't look like it requires any action on my part), > how bad can it hurt if there was even an informational > _signature_ appended to it? > > I'm an op/engineer, so it would be great if someone could > explain to me the logic behind not wanting to use POC > verification messages as vehicles to inform/remind the number > resource holders that time is up... > There is nothing preventing this from being done, it is completely up to the discretion of ARIN staff. 2008-7 was specifically written to allow ARIN staff to do this if they wished. 2008-7 takes pains to stay OUT of operational details and this is definitely operational. I would suggest you do what I did which is to submit a formal suggestion via the ARIN suggestion box and see what they say. I would keep in mind, though, that the list of e-mail addresses in the POC database essentially amounts to a mandatory mailing list - after 2008-7 gets done with it, every POC holder will be forced to have an e-mail address in WHOIS that they -must- respond to, which basically means they MUST read mails sent to it. A number of people on this list already aren't happy with this - and this list is a public list! I would guess that a whole lot more people who are NOT subscribed to arin-discuss will be incensed that ARIN has the nerve to require them to answer e-mails otherwise they will lose their IP addressing. The only credibility/leverage that ARIN has to respond to them is the fact that they signed a contract guarenteeing to supply contact info and publish it in WHOIS. And my experience with people leads me to believe that most people absolutely detest being reminded that they are contractually obligated to do something that they really don't want to do. Thus, while the temptation is "wow, look at this great list that we can send all of these Good Thing reminders to, we gotta use it" I would caution against it. The "running out of IPv4" reminder is pretty important, but so are a lot of other things too. It is kind of a slippery slope, if we include this reminder, how are you going to argue against a hundred other pet peeves of people being included in the POC-check e-mail? My 2008 tax form had 2 inches of space devoted all of the "good causes" who lobbied my state legislature to include a "$1 tax refund donation checkoff box" I can remember a few years ago when there was only 1 "good works" checkoff box, the state election fund. Ted From owen at delong.com Fri May 15 20:59:24 2009 From: owen at delong.com (Owen DeLong) Date: Fri, 15 May 2009 17:59:24 -0700 Subject: [arin-discuss] POC Reauthorization In-Reply-To: <413D364F8EF941C7949045F0639A7B0C@tedsdesk> References: <4A0DFE6B.70006@ibctech.ca> <413D364F8EF941C7949045F0639A7B0C@tedsdesk> Message-ID: <7E99A9CC-7906-4CA4-A5CA-5B84C5DB2297@delong.com> > > I suspect also that they only started testing the largest block > holders. > As a very small block holder who received such a message, I can guarantee you that is not the case. Owen From jcurran at arin.net Sat May 16 16:15:45 2009 From: jcurran at arin.net (John Curran) Date: Sat, 16 May 2009 16:15:45 -0400 Subject: [arin-discuss] POC Reauthorization In-Reply-To: <7E99A9CC-7906-4CA4-A5CA-5B84C5DB2297@delong.com> References: <4A0DFE6B.70006@ibctech.ca> <413D364F8EF941C7949045F0639A7B0C@tedsdesk> <7E99A9CC-7906-4CA4-A5CA-5B84C5DB2297@delong.com> Message-ID: <9AF0B7AA-FFD3-4AA6-870F-89FF2B422E24@arin.net> On May 15, 2009, at 8:59 PM, Owen DeLong wrote: >> I suspect also that they only started testing the largest block >> holders. >> > As a very small block holder who received such a message, I can > guarantee you that is not the case. You are correct. ARIN is contacting all POC's, although the process will take several months to complete. More information is available at: /John John Curran Acting President and CEO ARIN