Re: Remember "Internet-In-A-Box"?
In message <55a5b526.8030...@alter3d.ca>, Peter Kristolaitis writes: > On 7/14/2015 8:02 PM, Mike wrote: > > The flame wars and vitrol and rhetoric is too much noise for me to > > derive anything useful from. Someone needs to stand up and lead. I > > will happily follow. > > "Too much noise" has been v6's problem from the start. Every time I've > looked at v6 for use in the enterprise or even at home over the last ~15 > years, the answer is always "wait -- v6 isn't standardized yet", > "implement now -- v6 is ready for production", "wait -- v6 is missing > critical features", "implement now -- v6 is easier than v4" and "wait -- > v6 is too complex, and we don't have the best practices figured out yet" > -- all simultaneously, depending on who you ask, the phase of the moon, > local weather patterns, etc.And, to a significant degree, that's > still happening today. > > That's exarcerbated by the long development cycle, multiple conflicting > revisions/implementations over the years, and a severe case of feature > creep. Most people started to tune out around the third time we heard > "it's really here, for real this time!", and were completely > underwhelmed (or overwhelmed, as the case may be) when the "really here > for real" version arrived after a long hype cycle. > > So basically IPv6 is the Duke Nukem Forever of the networking > world. Took forever to get here, was completely underwhelming when it > did, and wasn't compelling enough for people to pony up money for other > than as a curiosity. Unfortunately v6 is an essential part of making > the Internet continue to work, because in any other scenario it would > have been abandoned as vaporware 10-15 years ago. If a product is in > development for 20 years, the expectation is that it's perfect out of > the box, reduced to the simplest possible implementation, and easily > understood -- and that's not what we have. Yet I can take a Windows XP box. Tell it to enable IPv6 and it just works. Everything that a node needed existed when Windows XP was released. The last 15 years has been waiting for ISP's and CPE vendors to deliver IPv6 as a product. This is not to say that every vendor deployed all the parts of the protocol properly but they existed. Most of the noise was people saying "We don't need IPv6" and second guessing the design decisions because they still had IPv4 think. If you look at the protocol it basically hasn't changed in the last 15 years. There has been minor tweak but what was there was complete enough to deploy. > - Pete -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Remember "Internet-In-A-Box"?
Mark is right and I couldn't agree more with him. On 15/07/15 08:22, Mark Andrews wrote: > Yet I can take a Windows XP box. Tell it to enable IPv6 and it > just works. Everything that a node needed existed when Windows XP > was released. The last 15 years has been waiting for ISP's and CPE > vendors to deliver IPv6 as a product. This is not to say that every > vendor deployed all the parts of the protocol properly but they > existed. > > Most of the noise was people saying "We don't need IPv6" and second > guessing the design decisions because they still had IPv4 think. > If you look at the protocol it basically hasn't changed in the last > 15 years. There has been minor tweak but what was there was complete > enough to deploy. > -- Marco smime.p7s Description: S/MIME Cryptographic Signature
Re: Remember "Internet-In-A-Box"?
On 15 July 2015 at 02:02, Mike wrote: > I am a small provider with a 16 bit asn, a /20 and a /22 of ipv4 and a /32 > of v6, but no clue yet how to get from where I am today to where we all > should be. The flame wars and vitrol and rhetoric is too much noise for me > to derive anything useful from. Someone needs to stand up and lead. I will > happily follow. > > Whats really needed, is for you gods of ipv6, to write that 'ipv6 for ipv4 > dummies', targeting service providers and telling us exactly what we need > to do. No religious wars about subnet allocation sizes or dhcpv6 vs slaac > or anything. Tell us how to get it onto our network, give us reasonable > deployment scenarios that leverage our experience with IPv4 and tell us > what we are going to tell our customers. Help us understand WHY nat is not > a security model, and how to achieve the same benefits we have with nat > now, in an ipv6 enabled world. You can't be a "dummy" and a service provider... There is a million ways to implement a service provider network and that goes for both IPv4 and IPv6. Writing a simple text that covers all possibilities is impossible. What is your setup like? Implementing IPv6 can be very simple, almost just run the "on" command. Or it can be very hard. It depends on what equipment you got and what features you need. And your luck. In my case it turned out to be hard. I thought it would be easy. I bought equipment that had IPv6 written all over it and it was a greenfield network. The plan was to have IPv6 from birth. That was not to be. A year later knew far too much about: DHCPv6 relay chaining - not supported. Relay chaining is when you have the access switch tag the DHCPv6 request with a customer identifier and then your access router has to do DHCPv6 relay on that. DHCPv6 relay in supervlan - not supported. IPv6 must not be enabled at the same time as MPLS layer 2 VPN (VPLS). DHCPv6-PD: When we said we had DHCPv6 support we meant IA_NA not IA_PD. DHCPv6 snooping not supported with prefix delegation. MPLS VPNv6 not supported. IPv6 prefixes more specific than /64 gets routed in CPU without any warnings. No support for route injection by DHCPv6-PD snooping. Oh and they just said they fixed most of the above issue in a new firmware that is not compatible with the hardware I got. I am afraid that even in 2015 many IPv6 implementations are still half baked. I was left feeling like I was the first guy to actually test this stuff. I managed to duct tape it all together despite the above limitations. But forget about easy. Regards, Baldur
Re: Dual stack IPv6 for IPv4 depletion
On 15 July 2015 at 01:34, Owen DeLong wrote: > For one thing a /32 is nowhere near enough for anything bigger than a > modest ISP today. Many will need /28, /24, or even larger. The biggest ones > probably need /16 or even /12 in some cases. > What is the definition of a modest and a large ISP? In the RIPE region even the smallest ISP can get a /29 with no documentation necessary. But likely that is all they will ever get because policy requires that you use that /29 at about 30% efficiency if you do /48 allocations to end users. You would need more than a million users to get a /24. I do not think the RIPE region has an ISP large enough to apply for a /16 or anything near it. Therefore we can conclude that if ARIN manages to use up all the /3 address space currently reserved for allocation, we will still be able to get address space in Europe for the next thousands years :-). It is thought that RIPE will not use up the /12 that IANA allocated to RIPE - ever. Personally I believe the ARIN policy is the sane one. But we need to abide by the rules in the region we live in. Regards, Baldur
ATT wireless IPv6
Does anyone know what the story is here? They have some transparent proxies for IPv4 traffic and I was wondering if they were to be IPv6 enabled soon or if IPv6 will reach the handset. Thanks, Jared Mauch
Re: Remember "Internet-In-A-Box"?
Did you deploy Mikrotik routers by any chance? -mel beckman > On Jul 15, 2015, at 3:29 AM, Baldur Norddahl > wrote: > >> On 15 July 2015 at 02:02, Mike wrote: >> >> I am a small provider with a 16 bit asn, a /20 and a /22 of ipv4 and a /32 >> of v6, but no clue yet how to get from where I am today to where we all >> should be. The flame wars and vitrol and rhetoric is too much noise for me >> to derive anything useful from. Someone needs to stand up and lead. I will >> happily follow. >> >> Whats really needed, is for you gods of ipv6, to write that 'ipv6 for ipv4 >> dummies', targeting service providers and telling us exactly what we need >> to do. No religious wars about subnet allocation sizes or dhcpv6 vs slaac >> or anything. Tell us how to get it onto our network, give us reasonable >> deployment scenarios that leverage our experience with IPv4 and tell us >> what we are going to tell our customers. Help us understand WHY nat is not >> a security model, and how to achieve the same benefits we have with nat >> now, in an ipv6 enabled world. > > > You can't be a "dummy" and a service provider... > > There is a million ways to implement a service provider network and that > goes for both IPv4 and IPv6. Writing a simple text that covers all > possibilities is impossible. What is your setup like? > > Implementing IPv6 can be very simple, almost just run the "on" command. Or > it can be very hard. It depends on what equipment you got and what features > you need. And your luck. > > In my case it turned out to be hard. I thought it would be easy. I bought > equipment that had IPv6 written all over it and it was a greenfield > network. The plan was to have IPv6 from birth. That was not to be. > > A year later knew far too much about: > > DHCPv6 relay chaining - not supported. Relay chaining is when you have the > access switch tag the DHCPv6 request with a customer identifier and then > your access router has to do DHCPv6 relay on that. > > DHCPv6 relay in supervlan - not supported. > > IPv6 must not be enabled at the same time as MPLS layer 2 VPN (VPLS). > > DHCPv6-PD: When we said we had DHCPv6 support we meant IA_NA not IA_PD. > DHCPv6 snooping not supported with prefix delegation. > > MPLS VPNv6 not supported. > > IPv6 prefixes more specific than /64 gets routed in CPU without any > warnings. > > No support for route injection by DHCPv6-PD snooping. > > Oh and they just said they fixed most of the above issue in a new firmware > that is not compatible with the hardware I got. > > I am afraid that even in 2015 many IPv6 implementations are still half > baked. I was left feeling like I was the first guy to actually test this > stuff. > > I managed to duct tape it all together despite the above limitations. But > forget about easy. > > Regards, > > Baldur
RE: Dual stack IPv6 for IPv4 depletion
-Original Message- From: John R. Levine [mailto:jo...@iecc.com] Sent: Tuesday, July 14, 2015 4:50 PM To: Chuck Church Cc: nanog@nanog.org Subject: RE: Dual stack IPv6 for IPv4 depletion >This is IPv6. Why shouldn't they have their own PI space? Same way it happens today. Business starts out small, uses IP space from their single ISP. Couple years later, they're bigger and want to dual-home for better uptime or other reasons. Unless there is something stopping them from advertising their ISP 'A' space out to ISP 'B' in IPv6 land, we're probably going to see the same things we see with IPv4 no? Chuck
Re: Remember "Internet-In-A-Box"?
On 7/15/15 1:28 PM, Baldur Norddahl wrote: You can't be a "dummy" and a service provider... oh? :)
Re: ARIN IPV4 Countdown
On 7/14/15, 11:16 PM, "NANOG on behalf of Randy Bush" wrote: >> While the base curve it runs on is running ahead of the measured traffic >> curve, the measure of IPv6 enabled browsers is a reasonable indicator >>for >> what is happening. > >we're an isp, with ipv6 enabled since 1997. we measure real traffic, >not wishes of what could be. I don¹t know how much of your traffic is IPv6, but ³10% by the time we retire² sure looks like a prediction. If it¹s number of users, that¹s well above 10%. IPv6 support in a couple of video streaming devices would push it well past that. I hope you¹re right about retiring at 10%it would be great to have the resources to retire this year. Lee > >randy >
Re: 'gray' market IPv4
Price varies significantly by prefix length, and somewhat by region. Regional variance may not be as much as it used to be. Lee On 7/14/15, 6:15 PM, "NANOG on behalf of Pavel Odintsov" wrote: >Hello, folks! > >I have finished multiple (and 5th in RIPE) inter RIR subnet moves in RIPE >region. We have moved multiple /21-/20 networks and awerage cost was about >$10 per ip. > >On Tuesday, July 14, 2015, Martin Hannigan wrote: > >> On Tue, Jul 14, 2015 at 10:22 AM, Matt Kelly > > wrote: >> >> > This list is actual sale prices, >> > http://www.ipv4auctions.com/previous_auctions/ >> > >> > >> > -- >> > Matt >> > >> > >> > On July 14, 2015 at 10:14:05 AM, Justin Wilson - MTIN (li...@mtin.net >> ) >> > wrote: >> > >> > Thes folks (and I am not advertising or affiliated with them) publish >>a >> > list of most recent transfer completed: >> > >> > http://ipv4marketgroup.com/broker-services/buy/ >> > >> > >> http://ipv4marketgroup.com/broker-services/buy/ vs. >> http://www.ipv4auctions.com/previous_auctions/ >> >> >> If you compare the pricing that both have made available you will find >>one >> is posting average prices exponentially higher than the other. When you >> trend the granular auction site data the auction numbers demonstrate a >> trend would expect, that smaller prefixes are more expensive since it >> takes a similar amount of effort to process a /24 as it does a /20. >>Dollar >> differences between a /24 unit and a /17 unit move the needle >> significantly. >> >> Based on both of both sets of public data its easy to conclude that >> auctions will work for at least small buyers of space if they're >> sophisticated enough to address the RIR issues. If you do decide to take >> the simple broker approach (not all are simple and not all approaches >>are >> suitable to simple brokers), use an RFP. And Yelp. :-) >> >> Best, >> >> -M< >> > > >-- >Sincerely yours, Pavel Odintsov >
Re: Remember "Internet-In-A-Box"?
On Wed, Jul 15, 2015 at 04:27:08PM +0300, John Kinsella wrote: > On 7/15/15 1:28 PM, Baldur Norddahl wrote: > >You can't be a "dummy" and a service provider... > > oh? :) Counterexample: Cox. They refuse to even admit to me that they are even considering IPV6. -- Mike Andrews, W5EGO mi...@mikea.ath.cx Tired old sysadmin
Re: Dual stack IPv6 for IPv4 depletion
On 7/15/15 3:43 AM, Baldur Norddahl wrote: > On 15 July 2015 at 01:34, Owen DeLong wrote: > >> For one thing a /32 is nowhere near enough for anything bigger than a >> modest ISP today. Many will need /28, /24, or even larger. The biggest ones >> probably need /16 or even /12 in some cases. >> > > What is the definition of a modest and a large ISP? > > In the RIPE region even the smallest ISP can get a /29 with no > documentation necessary. But likely that is all they will ever get because > policy requires that you use that /29 at about 30% efficiency if you do /48 > allocations to end users. > > You would need more than a million users to get a /24. > > I do not think the RIPE region has an ISP large enough to apply for a /16 > or anything near it. there are 4 organizations that originate something on the order of a /19 1 AS7922 ORG+TRN Originate: 36318243454976 /18.95 Transit: 38476054528 /28.84 COMCAST-7922 - Comcast Cable Communications, Inc.,US 2 AS3320 ORG+TRN Originate: 35219269156864 /19.00 Transit: 569424150528 /24.95 DTAG Deutsche Telekom AG,DE 3 AS5511 ORG+TRN Originate: 35188667187200 /19.00 Transit: 17818772963328 /19.98 OPENTRANSIT Orange S.A.,FR 4 AS17676 ORG+TRN Originate: 18695992639488 /19.91 Transit: 12885032960 /30.42 GIGAINFRA Softbank BB Corp.,JP > Therefore we can conclude that if ARIN manages to use up all the /3 address > space currently reserved for allocation, we will still be able to get > address space in Europe for the next thousands years :-). It is thought > that RIPE will not use up the /12 that IANA allocated to RIPE - ever. > > Personally I believe the ARIN policy is the sane one. But we need to abide > by the rules in the region we live in. > > Regards, > > Baldur > signature.asc Description: OpenPGP digital signature
Re: Dual stack IPv6 for IPv4 depletion
Reasonability, like beauty, is in the eye of the beholder, but I thank you for the compliment. :) The short answer is "yes, that constitutes being prudent". The longer answer is "it depends on what you consider the wildest dreams". There's a couple of factors playing in. First, look at every /64 that is assigned as an IPv4 /32 that someone is running NAT behind. This is flat out WRONG from a routing perspective, but from an allocation perspective, it's very much exactly what's happening because of SLAAC and the 48-bit MAC address basis for it. Since /64 is the minimum, that leaves us with less than half of the available bit mask in which to hand out that 1/8th the address space. Still oodles of addresses, but worth noting and is probably one reason why some of the "conservationists" react the way they do. Next, let's look at the wildest dreams aspect. The current "implementation" I'm thinking of in modern pop culture is Big Hero 6 (the movie, not the comics as I've never read them). Specifically, Hiro's "microbots". Each one needs an address to be able to communicate with the controller device. Even with the numbers of them, can probably be handled with a /64, but you'd also probably want them in separate "buckets" if you're doing separated tasks. Even so, a /48 could EASILY handle it. Now make them the size of a large-ish molecule. Or atom. Or protons. Nanotech or femtotech that's advanced enough gets into Clarke's Law - any sufficiently advanced technology is indistinguishable from magic - but in order to do that they need to communicate. If you think that won't be possible in the next 30 years, you probably haven't been paying attention. However, that's - barring a fundamental breakthrough - probably a decade or two off. Meanwhile we've got connected soda cans to worry about. I wrote my email as a way of pointing out that maybe the concerns (on both sides)- aren't baseless, but at the same time maybe there's a way to split the difference. It's not too much of a stretch to see that, soon, 256 subnets may not actually be enough to deal with the connected world and "Internet of Things" that's currently being developed. But would 1024? How about 4096? Is there any need in the next 10-15 years for EVERYONE to be getting handed 65,536 /64 subnets? Split the difference, go with a /52 and suddenly you've got FOUR THOUSAND subnets for individual users so that their soda cans can tell the suspension on their car that it's been opened and please smooth out the ride. Frankly, both sides seem intent on overkill in their preferred direction, and it's not particularly hard to meet in the middle. On Tue, Jul 14, 2015 at 8:38 PM, Doug Barton wrote: > On 7/14/15 6:23 AM, George Metz wrote: > >> It's always easier to be prudent from the get-go than it is to rein in the >> insanity at a later date. Just because we can't imagine a world where IPv6 >> depletion is possible doesn't mean it can't exist, and exist far sooner >> than one might expect. >> > > I've been trying to stay out of this Nth repetition of the same > nonsensical debate, since neither side has anything new to add. However > George makes a valid point, which is "learn from the mistakes of the past." > > So let me ask George, who seems like a reasonable fellow ... do you think > that creating an addressing plan that is more than adequate for even the > wildest dreams of current users and future growth out of just 1/8 of the > available space (meaning of course that we have 7/8 left to work with > should we make a complete crap-show out of 2000::/3) constitutes being > prudent, or not? > > And please note, this is not a snark, I am genuinely interested in the > answer. I used to be one of the people responsible for the prudent use of > the integers (as the former IANA GM) so this is something I've put a lot of > thought into, and care deeply about. If there is something we've missed in > concocting the current plan, I definitely want to know about it. > > Even taking into account some of the dubious decisions that were made 20 > years ago, the numbers involved in IPv6 deployment are literally so > overwhelming that the human brain has a hard time conceiving of them. > Combine that with the conservation mindset that's been drilled into > everyone regarding IPv4 resources, and a certain degree of over-enthusiasm > for conserving IPv6 resources is understandable. But at the same time, > because the volume of integers is so vast, it could be just as easy to slip > into the early-days v4 mindset of "infinite," which is why I like to hear a > good reality check now and again. :) > > Doug > > -- > I am conducting an experiment in the efficacy of PGP/MIME signatures. This > message should be signed. If it is not, or the signature does not validate, > please let me know how you received this message (direct, or to a list) and > the mail software you use. Thanks! > >
Re: Remember "Internet-In-A-Box"?
I google¹d ³IPv6 for Dummies² and found this: https://www.wesecure.nl/upload/documents/tinymce/IPv6.pdf It¹s licensed from the For Dummies series, written and published by Infoblox. more below. . . On 7/14/15, 8:02 PM, "NANOG on behalf of Mike" wrote: > > >On 07/14/2015 04:46 PM, Stephen Satchell wrote: >> This goes back a number of years. There was a product that literally >> was a cardboard box that contained everything one needed to get >> started on the Internet. Just add a modem and a computer, and you >> were on your way. No fuss, no "learning curve". >> >> I'm beginning to think that someone needs to create a similar product, >> but for IPv6 internet. The Internet service providers would provide >> the same sort of kit to get people started. Just add a CSU/DSU (like >> a cable modem) and a computer, and you are on your way. >> >> Also, I think we need a *real* book called "IPv6 for Dummies" (maybe >> even published by IDG Books) that walks through all the beginner >> stuff. There's beginner stuff that I've seen by using a search >> engine; a dead-tree book, though, may well be better for Joe Average. >> >> Just my pair-o-pennies(tm) >> >> > >I am a small provider with a 16 bit asn, a /20 and a /22 of ipv4 and a >/32 of v6, but no clue yet how to get from where I am today to where we >all should be. The flame wars and vitrol and rhetoric is too much noise >for me to derive anything useful from. Someone needs to stand up and >lead. I will happily follow. I also co-authored RFC6782, intended to be guidance for landline ISPs deploying IPv6: http://tools.ietf.org/html/rfc6782 We really tried to make it step-by-step, and you don¹t necessarily need to hit each step (as we explain in the document). > >Whats really needed, is for you gods of ipv6, to write that 'ipv6 for >ipv4 dummies', targeting service providers and telling us exactly what >we need to do. No religious wars about subnet allocation sizes or dhcpv6 >vs slaac or anything. Tell us how to get it onto our network, give us >reasonable deployment scenarios that leverage our experience with IPv4 >and tell us what we are going to tell our customers. Help us understand >WHY nat is not a security model, and how to achieve the same benefits we >have with nat now, in an ipv6 enabled world. Send me private email and we can set up time to talk. I won¹t know the IPv6 capabilities of every piece of equipment you have, but I might be able to help you plan. Lee > >Mike > > > >
Re: Dual stack IPv6 for IPv4 depletion
>Same way it happens today. Business starts out small, uses IP space from >their single ISP. Couple years later, they're bigger and want to dual-home >for better uptime or other reasons. Unless there is something stopping them >from advertising their ISP 'A' space out to ISP 'B' in IPv6 land, we're >probably going to see the same things we see with IPv4 no? Sigh. We can hope that ISP B would push back a little and tell the customer that it's a lot easier to get v6 space, and once they do, they will have their own IP space forever and not be in thrall to ISP A. It would be nice if it were possible to implement BCP 38 in IPv6, since this is the reason it isn't in IPv4. R's, John
Re: Dual stack IPv6 for IPv4 depletion
On 15 Jul 2015 15:25:05 -, "John Levine" said: > It would be nice if it were possible to implement BCP 38 in IPv6, since this > is the reason it isn't in IPv4. There isn't any technical reason that an organization can't fix its edge so it doesn't urinate bad IPv6 traffic all over the Internet. pgpRr9b63YbT3.pgp Description: PGP signature
Re: Dual stack IPv6 for IPv4 depletion
On 7/15/2015 8:25 AM, John Levine wrote: It would be nice if it were possible to implement BCP 38 in IPv6, since this is the reason it isn't in IPv4. Too bad the hazards of allowing people to use arbitrary source addresses weren't known when IPv6 was designed. Matthew Kaufman
Re: Dual stack IPv6 for IPv4 depletion
> On Jul 15, 2015, at 03:43 , Baldur Norddahl wrote: > > On 15 July 2015 at 01:34, Owen DeLong wrote: > >> For one thing a /32 is nowhere near enough for anything bigger than a >> modest ISP today. Many will need /28, /24, or even larger. The biggest ones >> probably need /16 or even /12 in some cases. >> > > What is the definition of a modest and a large ISP? > > In the RIPE region even the smallest ISP can get a /29 with no > documentation necessary. But likely that is all they will ever get because > policy requires that you use that /29 at about 30% efficiency if you do /48 > allocations to end users. Which is fine… 30% of a /29 at /48 is 524,288 end-sites served. For a residential provider, I’d say that’s a medium-sized provider. A large provider would be one that serves several million end-sites. There are at least a handful of providers in the US for example, that have 10,000,000+ customers. A /29 wouldn’t be enough for them. RIPEs policy ignores the inefficiencies created by topology and that’s kind of unfortunate in my opinion, but so far it doesn’t appear too egregious, so I haven’t taken the time to propose better policy. > You would need more than a million users to get a /24. Sure. Many ISPs have more than a million end-sites (note end-sites != users). In many cases customer and end-site are synonymous, but in many cases, a single customer may have many end-sites. For example, a business which has several buildings in a campus may treat each building as an end-site. A multi-tenant building would likely treat each tenant as a separate end-site. etc. > I do not think the RIPE region has an ISP large enough to apply for a /16 > or anything near it. Perhaps. There are at least 2 ISPs in the US that I know of with 20,000,000+ customers. Since the NA in NANOG stands for North America, I kind of figured that the situation in North America ought to be considered somewhat relevant. > Therefore we can conclude that if ARIN manages to use up all the /3 address > space currently reserved for allocation, we will still be able to get > address space in Europe for the next thousands years :-). It is thought > that RIPE will not use up the /12 that IANA allocated to RIPE - ever. I doubt even with our current policy, ARIN is unlikely to use up the /12 in my lifetime or even in the lifetime of the IPv6 protocol. Even if we do, I doubt we will use more than 2 or 3 /12s ever. > Personally I believe the ARIN policy is the sane one. But we need to abide > by the rules in the region we live in. I agree with you, but as the author of the current ARIN ISP IPv6 policy, I may be biased. ;-) Owen
Re: Remember "Internet-In-A-Box"?
On 7/14/2015 11:22 PM, Mark Andrews wrote: Yet I can take a Windows XP box. Tell it to enable IPv6 and it just works. Everything that a node needed existed when Windows XP was released. The last 15 years has been waiting for ISP's and CPE vendors to deliver IPv6 as a product. This is not to say that every vendor deployed all the parts of the protocol properly but they existed. This is only true for dual-stacked networks. I just tried to set up an IPv6-only WiFi network at my house recently, and it was a total fail due to non-implementation of relatively new standards... starting with the fact that my Juniper SRX doesn't run a load new enough to include RDNSS information in RAs, and some of the devices I wanted to test with (Android tablets) won't do DHCPv6. The XP box is in an even worse situation if you try to run it on a v6-only network. And yet we've known for years now that dual-stack wasn't going to be an acceptable solution, because nobody was on track to get to 100% IPv6 before IPv4 runout happened. Go to any business with hardware that is 3-5 years old in its IT infrastructure and devices ranging from PCs running XP to the random consumer gear people bring in (cameras, printers, tablets, etc.) and see how easy it is to get everything talking on an IPv6-only (no IPv4 at all) network... including using IPv6 to do automatic updates and all the other pieces that need to work. We're nowhere near ready for that. Matthew Kaufman
Re: Dual stack IPv6 for IPv4 depletion
It would be nice if it were possible to implement BCP 38 in IPv6, since this is the reason it isn't in IPv4. There isn't any technical reason that an organization can't fix its edge so it doesn't urinate bad IPv6 traffic all over the Internet. In IPv4 systems, the problem is (so I have been told by some largish ISPs) that a dual homed customer gets address ranges from ISPs A and B, and sends traffic with A addresses to the B interface. The ISPs have no practical way to tell legit dual homed traffic from malicious, particularly when there is a chain of resellers in between. If the ISP tells the customer to send the traffic over the right interface, the usual response is "if you don't want our business, I'm sure we can find another ISP that does." Like I said, it would be nice if ISPs could persuade their v6 customers to get their own PI space early on, because if they don't they'll have exactly the same problem. R's, John
Re: Dual stack IPv6 for IPv4 depletion
> On Jul 15, 2015, at 08:20 , George Metz wrote: > > Reasonability, like beauty, is in the eye of the beholder, but I thank you > for the compliment. :) > > The short answer is "yes, that constitutes being prudent". The longer > answer is "it depends on what you consider the wildest dreams". > > There's a couple of factors playing in. First, look at every /64 that is > assigned as an IPv4 /32 that someone is running NAT behind. This is flat > out WRONG from a routing perspective, but from an allocation perspective, > it's very much exactly what's happening because of SLAAC and the 48-bit MAC > address basis for it. Since /64 is the minimum, that leaves us with less > than half of the available bit mask in which to hand out that 1/8th the > address space. Still oodles of addresses, but worth noting and is probably > one reason why some of the "conservationists" react the way they do. Then they are being silly. The thinking for IPv6 was a 64-bit address in toto until SLAAC was proposed and 64 bits were added to enable that. Even at 64 bits, you have more than 4 billion times as many network numbers as you had host numbers in all of IPv4. > Next, let's look at the wildest dreams aspect. The current "implementation" > I'm thinking of in modern pop culture is Big Hero 6 (the movie, not the > comics as I've never read them). Specifically, Hiro's "microbots". Each one > needs an address to be able to communicate with the controller device. Even > with the numbers of them, can probably be handled with a /64, but you'd > also probably want them in separate "buckets" if you're doing separated > tasks. Even so, a /48 could EASILY handle it. Right… > Now make them the size of a large-ish molecule. Or atom. Or protons. > Nanotech or femtotech that's advanced enough gets into Clarke's Law - any > sufficiently advanced technology is indistinguishable from magic - but in > order to do that they need to communicate. If you think that won't be > possible in the next 30 years, you probably haven't been paying attention. Sure, but do you really think that IPv6 can handle that in all the other ways? I think we’ll need a new protocol to do that for reasons other than address space limitations well before we run out of IPv6 addresses. > However, that's - barring a fundamental breakthrough - probably a decade or > two off. Meanwhile we've got connected soda cans to worry about. True. > I wrote my email as a way of pointing out that maybe the concerns (on both > sides)- aren't baseless, but at the same time maybe there's a way to split > the difference. It's not too much of a stretch to see that, soon, 256 > subnets may not actually be enough to deal with the connected world and > "Internet of Things" that's currently being developed. But would 1024? How > about 4096? Is there any need in the next 10-15 years for EVERYONE to be > getting handed 65,536 /64 subnets? Split the difference, go with a /52 and > suddenly you've got FOUR THOUSAND subnets for individual users so that > their soda cans can tell the suspension on their car that it's been opened > and please smooth out the ride. There are two ways to waste addresses. One is to allocate them to users who don’t actually use all of them. The other is to keep them on the shelf in the free pool until well past the useful life of the protocol. I don’t see splitting the difference at /52 as being any more useful than leaving it at /48. Certainly it is an incremental improvement over /56 and wildly better than /60, but it remains an unnecessarily inferior solution. > Frankly, both sides seem intent on overkill in their preferred direction, > and it's not particularly hard to meet in the middle. Perhaps, but it’s also not hard to do harmful things with the best of intent. Owen > > On Tue, Jul 14, 2015 at 8:38 PM, Doug Barton wrote: > >> On 7/14/15 6:23 AM, George Metz wrote: >> >>> It's always easier to be prudent from the get-go than it is to rein in the >>> insanity at a later date. Just because we can't imagine a world where IPv6 >>> depletion is possible doesn't mean it can't exist, and exist far sooner >>> than one might expect. >>> >> >> I've been trying to stay out of this Nth repetition of the same >> nonsensical debate, since neither side has anything new to add. However >> George makes a valid point, which is "learn from the mistakes of the past." >> >> So let me ask George, who seems like a reasonable fellow ... do you think >> that creating an addressing plan that is more than adequate for even the >> wildest dreams of current users and future growth out of just 1/8 of the >> available space (meaning of course that we have 7/8 left to work with >> should we make a complete crap-show out of 2000::/3) constitutes being >> prudent, or not? >> >> And please note, this is not a snark, I am genuinely interested in the >> answer. I used to be one of the people responsible for the prudent use of >> the integers (as the former IANA GM) so this is som
Re: Remember "Internet-In-A-Box"?
> On Jul 15, 2015, at 08:57 , Matthew Kaufman wrote: > > On 7/14/2015 11:22 PM, Mark Andrews wrote: >> >> Yet I can take a Windows XP box. Tell it to enable IPv6 and it >> just works. Everything that a node needed existed when Windows XP >> was released. The last 15 years has been waiting for ISP's and CPE >> vendors to deliver IPv6 as a product. This is not to say that every >> vendor deployed all the parts of the protocol properly but they >> existed. > > This is only true for dual-stacked networks. I just tried to set up an > IPv6-only WiFi network at my house recently, and it was a total fail due to > non-implementation of relatively new standards... starting with the fact that > my Juniper SRX doesn't run a load new enough to include RDNSS information in > RAs, and some of the devices I wanted to test with (Android tablets) won't do > DHCPv6. That’s a pretty old load then, as I’ve had RDNSS on my SRX-100 for several years now. > The XP box is in an even worse situation if you try to run it on a v6-only > network. Only if you care about DNS. > And yet we've known for years now that dual-stack wasn't going to be an > acceptable solution, because nobody was on track to get to 100% IPv6 before > IPv4 runout happened. An IPv6-only DNS server with RFC-1918 IPv4 connectivity to your XP box does solve the problem in question. > Go to any business with hardware that is 3-5 years old in its IT > infrastructure and devices ranging from PCs running XP to the random consumer > gear people bring in (cameras, printers, tablets, etc.) and see how easy it > is to get everything talking on an IPv6-only (no IPv4 at all) network... > including using IPv6 to do automatic updates and all the other pieces that > need to work. We're nowhere near ready for that. Anyone who has that already has IPv4 addresses on all that ancient gear, so they can, in fact, dual stack at least that fraction of their network. How about helping them deploy instead of continually trying to throw red herrings in their path. Owen
Re: Remember "Internet-In-A-Box"?
On 7/15/15, 11:57 AM, "NANOG on behalf of Matthew Kaufman" wrote: > >Go to any business with hardware that is 3-5 years old in its IT >infrastructure and devices ranging from PCs running XP to the random >consumer gear people bring in (cameras, printers, tablets, etc.) and see >how easy it is to get everything talking on an IPv6-only (no IPv4 at >all) network... including using IPv6 to do automatic updates and all the >other pieces that need to work. We're nowhere near ready for that. This is painfully true. I don¹t have much sympathy for Windows XP, since it¹s a year past extended End of Support, and it¹s a 15-year-old operating system, now five generations obsolete? But specific-purpose consumer electronics are failures: not just cameras, but game consoles, set-top boxes, audio-video systems. Even security critical stuff like software updates, anti-virus updates, CRL checks, are almost completely unavailable over IPv6. Unless you run a large enough enterprise to have your own update servers; then they can pull updates over IPv4, and serve clients over IPv6. However, if you dual-stack now, you¹ll be able to identify which things are still dependent on IPv4, and either engineer differently, or substitute equipment over time. Lee > >Matthew Kaufman > >
Re: Dual stack IPv6 for IPv4 depletion
Mark Andrews wrote: In message We don't use Class E because were using up IPv4 space too quickly to make it worthwhile to make it work cleanly for everyone. That is a self fulfilling prophecy. I suspect a 16 /8 right about now would be very welcome for everybody other then the ipv6 adherents. Seems like procrastination is only bad when its your baby. The jury is still out on class E, but the verdict is in for the community who created it. Joe
Re: Dual stack IPv6 for IPv4 depletion
On 7/15/15 8:20 AM, George Metz wrote: Reasonability, like beauty, is in the eye of the beholder, but I thank you for the compliment. :) I call them like I see them. :) The short answer is "yes, that constitutes being prudent". Ok, good news so far. :) The longer answer is "it depends on what you consider the wildest dreams". There's a couple of factors playing in. First, look at every /64 that is assigned as an IPv4 /32 that someone is running NAT behind. Ok, that's a relatively common analogy, even if it isn't quite technically correct. This is flat out WRONG from a routing perspective, but from an allocation perspective, it's very much exactly what's happening because of SLAAC and the 48-bit MAC address basis for it. Since /64 is the minimum, that leaves us with less than half of the available bit mask in which to hand out that 1/8th the address space. I have my own issues with RA/SLAAC, but let's leave those aside for a second. It's probably a more correct analogy (although still not completely accurate) to say that a /64 is equivalent to an IPv4 /24, or some other small network that would be utilized by an end user with the expectation that there are multiple devices running in it. I agree with you that you'd never want to route that /64, but you (generally) wouldn't want to route a /24, or more accurately something like a /28, either. Also, as Owen pointed out, the original concept for IPv6 networking was a 64 bit address space all along. The "extra" (or some would say, "wasted") 64 bits were tacked on later. Still oodles of addresses, but worth noting and is probably one reason why some of the "conservationists" react the way they do. It's easy to look at the mandatory /64 limit and say "See, the address space is cut in half to start with!" but it's not accurate. Depending on who's using it a single /64 could have thousands of devices, up to the limit of the broadcast domain on the network gear. At minimum even for a home user you're going to get "several" devices. Next, let's look at the wildest dreams aspect. The current "implementation" I'm thinking of in modern pop culture is Big Hero 6 (the movie, not the comics as I've never read them). Specifically, Hiro's "microbots". Each one needs an address to be able to communicate with the controller device. Even with the numbers of them, can probably be handled with a /64, but you'd also probably want them in separate "buckets" if you're doing separated tasks. Even so, a /48 could EASILY handle it. Right, 65k /64s in a /48. Now make them the size of a large-ish molecule. Or atom. Or protons. Nanotech or femtotech that's advanced enough gets into Clarke's Law - any sufficiently advanced technology is indistinguishable from magic - but in order to do that they need to communicate. If you think that won't be possible in the next 30 years, you probably haven't been paying attention. I do see that as a possibility, however in this world that you're positing, how many of those molecules need to talk to the big-I Internet? Certainly they need to communicate internally, but do they need routable space? Also, stay tuned for some math homework. :) I wrote my email as a way of pointing out that maybe the concerns (on both sides)- aren't baseless, Please note that I try very hard not to dismiss anyone's concerns as baseless, whether I agree with them or not. As I mentioned in my previous message, I believe I have a pretty good understanding of how the "IPv6 conservationists" think. My concern however is that while their concerns have a basis, their premise is wrong. but at the same time maybe there's a way to split the difference. It's not too much of a stretch to see that, soon, 256 subnets may not actually be enough to deal with the connected world and "Internet of Things" that's currently being developed. But would 1024? How about 4096? Is there any need in the next 10-15 years for EVERYONE to be getting handed 65,536 /64 subnets? So, here's where the math gets to be both fun, and mind-boggling. :) There are 32 /8s in 2000::/3. Let's assume for sake of argument that we've "wasted" two whole /8s with various drama. There are 2 to the 40th power /48s in a /8, multiply by 30, and divide by 10 billion (to represent a fairly future-proof number of people on the planet). That's 3,298.5 /48s per person. So you asked an interesting question about whether or not we NEED to give everyone a /48. Based on the math, I think the more interesting question is, what reason is there NOT to give everyone a /48? You want to future proof it to 20 billion people? Ok, that's 1,600+ /48s per person. You want to future proof it more to 25% sparse allocation? Ok, that's 400+ /48s per person (at 20 billion people). At those levels even if you gave every person's every device a /48, we're still not going to run out, in the first 1/8 of the available space. Split the difference, go with a /52 That's not sp
Re: Dual stack IPv6 for IPv4 depletion
On 7/15/15 10:24 AM, Joe Maimon wrote: > > > Mark Andrews wrote: >> In message >> > >> We don't use Class E because were using up IPv4 space too quickly >> to make it worthwhile to make it work cleanly for everyone. > > That is a self fulfilling prophecy. > > I suspect a 16 /8 right about now would be very welcome for everybody > other then the ipv6 adherents. > > Seems like procrastination is only bad when its your baby. > > The jury is still out on class E, but the verdict is in for the > community who created it. joel@ubuntu:~$ uname -a Linux ubuntu 3.8.0-44-generic #66~precise1-Ubuntu SMP Tue Jul 15 04:01:04 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux joel@ubuntu:~$ sudo ifconfig eth0:0 240.0.0.1/24 SIOCSIFADDR: Invalid argument SIOCSIFFLAGS: Cannot assign requested address SIOCSIFNETMASK: Cannot assign requested address now go test that on every exisitng ipv4 device on the planet that's not getting an upgrade. it doesn't extend the life of ipv4 usefully and it wouldn't have if we started 10 years ago either. the goal in stringing along ipv4 is to not hose your current or potential customers rather than prevent still more obstacles to their success. joel > Joe > signature.asc Description: OpenPGP digital signature
Re: Dual stack IPv6 for IPv4 depletion
On 7/15/15 10:24 AM, Joe Maimon wrote: I suspect a 16 /8 right about now would be very welcome for everybody other then the ipv6 adherents. Globally we were burning through about a /8 every month or two in "the good old days." So in the best case scenario we'd get 32 more months of easy to get IPv4, but at an overwhelming cost to re-implement every network stack. This option was considered back in the early 2000's when I was still involved in the discussion, and rejected as impractical. -- I am conducting an experiment in the efficacy of PGP/MIME signatures. This message should be signed. If it is not, or the signature does not validate, please let me know how you received this message (direct, or to a list) and the mail software you use. Thanks! signature.asc Description: OpenPGP digital signature
Re: Dual stack IPv6 for IPv4 depletion
Hi, On Jul 14, 2015, at 8:53 PM, Karl Auer wrote: > Space was handed out more or less willy-nilly - so some US > organisations ended up with multiple A-classes each, while later on all > of Vietnam got one /26. IIRC (I was running APNIC at the time), when the first organization from Vietnam approached APNIC for address space, we allocated a /22 to them and reserved the /16 from which that allocation was made for other ISPs in Vietnam (as was the policy back then). > That's the big difference - IPv6 has been designed to provide abundant > address space. There is no amount of fixed address space that can't be consumed with stupid allocation policies. Regards, -drc signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Dual stack IPv6 for IPv4 depletion
>I suspect a 16 /8 right about now would be very welcome for everybody >other then the ipv6 adherents. It would, if the software supported it. But it doesn't. Is there any reason to think the world would update its TCP stacks to handle those extra IPv4 addresses any sooner than it'd update its stacks to handle IPv6? Doesn't seem likely. R's, John
Re: Dual stack IPv6 for IPv4 depletion
> On Jul 15, 2015, at 10:24 , Joe Maimon wrote: > > > > Mark Andrews wrote: >> In message >> > >> We don't use Class E because were using up IPv4 space too quickly >> to make it worthwhile to make it work cleanly for everyone. > > That is a self fulfilling prophecy. > > I suspect a 16 /8 right about now would be very welcome for everybody other > then the ipv6 adherents. But it wouldn’t be right now. It would be after everyone put lots of effort into updating lots of systems so that they could support those 16 /8s. By the time you’ve done that, you might as well have focused that effort on making those same systems do IPv6. > Seems like procrastination is only bad when its your baby. Not really… This isn’t a question of procrastination or not. It’s a question of given that roughly the same effort is required to do thing A or thing B and thing A (class E) leads nowhere in the long run while thing B provides a permanent solution, it makes much more sense to focus said effort on thing B than to postpone thing B in favor of thing A. > The jury is still out on class E, but the verdict is in for the community who > created it. Not really. I think if you really consider what would be required for deployment of class E, you’ll find that there truly is no there there. Owen
Re: Dual stack IPv6 for IPv4 depletion
> On Jul 15, 2015, at 11:32 , David Conrad wrote: > > Hi, > > On Jul 14, 2015, at 8:53 PM, Karl Auer wrote: >> Space was handed out more or less willy-nilly - so some US >> organisations ended up with multiple A-classes each, while later on all >> of Vietnam got one /26. > > IIRC (I was running APNIC at the time), when the first organization from > Vietnam approached APNIC for address space, we allocated a /22 to them and > reserved the /16 from which that allocation was made for other ISPs in > Vietnam (as was the policy back then). > >> That's the big difference - IPv6 has been designed to provide abundant >> address space. > > There is no amount of fixed address space that can't be consumed with stupid > allocation policies. > True. However, are you making the argument that any of the current or proposed allocation policies are, in fact, stupid in such a way that this is likely? If so, which ones? If not, then how is that relevant to the current discussion of what to do in terms of deployment given existing policies? Owen
Re: Dual stack IPv6 for IPv4 depletion
On Wed, Jul 15, 2015 at 2:11 PM, Doug Barton wrote: > On 7/15/15 8:20 AM, George Metz wrote: > >> >> Snip! > Also, as Owen pointed out, the original concept for IPv6 networking was a > 64 bit address space all along. The "extra" (or some would say, "wasted") > 64 bits were tacked on later. > > Still oodles of addresses, but worth >> noting and is probably one reason why some of the "conservationists" >> react the way they do. >> > > It's easy to look at the mandatory /64 limit and say "See, the address > space is cut in half to start with!" but it's not accurate. Depending on > who's using it a single /64 could have thousands of devices, up to the > limit of the broadcast domain on the network gear. At minimum even for a > home user you're going to get "several" devices. Allow me to rephrase: "A single /32 could have thousands of devices, up to the limit of a 10/8 NATted behind it". This, plus the fact that it WAS originally 64-bit and was expanded to include RA/SLAAC, is why I chose that analogy. > Next, let's look at the wildest dreams aspect. The current >> "implementation" I'm thinking of in modern pop culture is Big Hero 6 >> (the movie, not the comics as I've never read them). Specifically, >> Hiro's "microbots". Each one needs an address to be able to communicate >> with the controller device. Even with the numbers of them, can probably >> be handled with a /64, but you'd also probably want them in separate >> "buckets" if you're doing separated tasks. Even so, a /48 could EASILY >> handle it. >> > > Right, 65k /64s in a /48. > > Now make them the size of a large-ish molecule. Or atom. Or protons. >> Nanotech or femtotech that's advanced enough gets into Clarke's Law - >> any sufficiently advanced technology is indistinguishable from magic - >> but in order to do that they need to communicate. If you think that >> won't be possible in the next 30 years, you probably haven't been paying >> attention. >> > > I do see that as a possibility, however in this world that you're > positing, how many of those molecules need to talk to the big-I Internet? > Certainly they need to communicate internally, but do they need routable > space? Also, stay tuned for some math homework. :) So, you're advising that all these trillions of nanites should, what, use NAT? Unroutable IP space of another kind? Why would we do that when we've already got virtually unlimited v6 address space? See what I mean? Personally I'd suspect something involving quantum states would be more likely for information passage, but who knows what the end result is? > I wrote my email as a way of pointing out that maybe the concerns (on >> both sides)- aren't baseless, >> > > Please note that I try very hard not to dismiss anyone's concerns as > baseless, whether I agree with them or not. As I mentioned in my previous > message, I believe I have a pretty good understanding of how the "IPv6 > conservationists" think. My concern however is that while their concerns > have a basis, their premise is wrong. I wasn't intending yourself as the recipient keep in mind. However, IS their premise wrong? Is prudence looking at incomprehensible numbers and saying "we're so unlikely to run out that it just doesn't matter" or is prudence "Well, we have no idea what's coming, so let's be a little less wild-haired in the early periods"? The theory being it's a lot harder to take away that /48 30 years from now than it is to just assign the rest of it to go along with the /56 (or /52 or whatever) if it turns out they're needed. I personally like your idea of reserving the /48 and issuing the /56. > So you asked an interesting question about whether or not we NEED to give > everyone a /48. Based on the math, I think the more interesting question > is, what reason is there NOT to give everyone a /48? You want to future > proof it to 20 billion people? Ok, that's 1,600+ /48s per person. You want > to future proof it more to 25% sparse allocation? Ok, that's 400+ /48s per > person (at 20 billion people). > > At those levels even if you gave every person's every device a /48, we're > still not going to run out, in the first 1/8 of the available space. > > Split the difference, go with a /52 >> > > That's not splitting the difference. :) A /56 is half way between a /48 > and a /64. That's 256 /64s, for those keeping score at home. > It's splitting the difference between a /56 and a /48. I can't imagine short of the Nanotech Revolution that anyone really needs eight thousand separate networks, and even then... Besides, I recall someone at some point being grumpy about oddly numbered masks, and a /51 is probably going to trip that. :) I think folks are missing the point in part of the conservationists, and all the math in the world isn't going to change that. While the... let's call them IPv6 Libertines... are arguing that there's no mathematically foreseeable way we're going to run out of addresses even at /48s for the proverbial soda cans, the
Re: Dual stack IPv6 for IPv4 depletion
> > I wasn't intending yourself as the recipient keep in mind. However, IS > their premise wrong? Is prudence looking at incomprehensible numbers and > saying "we're so unlikely to run out that it just doesn't matter" or is > prudence "Well, we have no idea what's coming, so let's be a little less > wild-haired in the early periods"? The theory being it's a lot harder to > take away that /48 30 years from now than it is to just assign the rest of > it to go along with the /56 (or /52 or whatever) if it turns out they're > needed. I personally like your idea of reserving the /48 and issuing the > /56. Yes… Their premise is wrong. We’re not talking about /48s for soda cans. We’re talking about /48s for end-sites… Households, individual business buildings, etc. The soda can is probably just one host on a /64 somewhere within that /48. Every six-pack in your house probably fits in the same /64. > > >> So you asked an interesting question about whether or not we NEED to give >> everyone a /48. Based on the math, I think the more interesting question >> is, what reason is there NOT to give everyone a /48? You want to future >> proof it to 20 billion people? Ok, that's 1,600+ /48s per person. You want >> to future proof it more to 25% sparse allocation? Ok, that's 400+ /48s per >> person (at 20 billion people). >> >> At those levels even if you gave every person's every device a /48, we're >> still not going to run out, in the first 1/8 of the available space. >> >> Split the difference, go with a /52 >>> >> >> That's not splitting the difference. :) A /56 is half way between a /48 >> and a /64. That's 256 /64s, for those keeping score at home. >> > > It's splitting the difference between a /56 and a /48. I can't imagine > short of the Nanotech Revolution that anyone really needs eight thousand > separate networks, and even then... Besides, I recall someone at some point > being grumpy about oddly numbered masks, and a /51 is probably going to > trip that. :) It’s not about the number of networks. It’s about the number of bits available to provide flexibility in automating topology to create pluggable network components that just work. We’ve only begun to explore the new capabilities of DHCPv6-PD within a site. Clamping down the size of a “site” to less than the original design-criteria considered when DHCPv6-PD was developed will, in fact, stifle innovation in this area most likely. > I think folks are missing the point in part of the conservationists, and > all the math in the world isn't going to change that. While the... let's > call them IPv6 Libertines... are arguing that there's no mathematically > foreseeable way we're going to run out of addresses even at /48s for the > proverbial soda cans, the conservationists are going, "Yes, you do math > wonderfully. Meantime is it REALLY causing anguish for someone to only get > 256 (or 1024, or 4096) networks as opposed to 65,536 of them? If not, why > not go with the smaller one? It bulletproofs us against the unforeseen to > an extent.” The problem is that the conservationists are arguing against /48s for soda cans while the libertines are not arguing for that. /48 protects against the unforeseen pretty well. Even if it doesn’t, that’s why we also have the /3 safeguard. If we turn out to have gotten it wrong… If it turns out that we use up all of the first /3 before we run out of useful life in the protocol, then I’m all for coming up with different policy for the remaining /3s. Even if you want to argue that we have to keep handing out addresses while we develop that policy, I’ll say you can hand out the second /3 in the same way while we develop the more restrictive policy for the remaining 74.99% of the total address space. Short of something incredibly surprising, we’re not going to exhaust that first /3 in less than 50 years even if we give many /48s to every end site on the planet. In case of something really surprising, it would be even more surprising if we found a way to make IPv6 scale to that on many levels other than address space: 1. IPv6 developers punted on the routing problem and insisted that aggregation was the desired alternative to solving the routing problem. In reality, I think this will most likely be the first scaling limit we see in IPv6, but I could be wrong. Aggregation is somewhere between inconvenient and infeasible as we have seen with IPv4 where we managed to get some small gains when aggregation was first introduced and we took the routing table from ~65,000 entries to ~45,000. Look where it is now. More than 500,000 entries and continuing to grow. More multihoming and more individual PI prefixes are going to become the norm, not less. 2. IP is a relatively high overhead protocol. Putting an IPv6 sta
Re: Dual stack IPv6 for IPv4 depletion
On 7/15/15 12:43 PM, George Metz wrote: On Wed, Jul 15, 2015 at 2:11 PM, Doug Barton mailto:do...@dougbarton.us>> wrote: On 7/15/15 8:20 AM, George Metz wrote: Snip! Also, as Owen pointed out, the original concept for IPv6 networking was a 64 bit address space all along. The "extra" (or some would say, "wasted") 64 bits were tacked on later. Still oodles of addresses, but worth noting and is probably one reason why some of the "conservationists" react the way they do. It's easy to look at the mandatory /64 limit and say "See, the address space is cut in half to start with!" but it's not accurate. Depending on who's using it a single /64 could have thousands of devices, up to the limit of the broadcast domain on the network gear. At minimum even for a home user you're going to get "several" devices. Allow me to rephrase: "A single /32 could have thousands of devices, up to the limit of a 10/8 NATted behind it". This, plus the fact that it WAS originally 64-bit and was expanded to include RA/SLAAC, is why I chose that analogy. Sure, so in that context it's a valid analogy, but my point still stands. We're not talking about routable/PI space for customers, even at the /48 level. Now it is true that the CW seems to be leaning towards /48 being the largest routable prefix *for commercial networks*, but that's orthogonal to the issue of home users. I do see that as a possibility, however in this world that you're positing, how many of those molecules need to talk to the big-I Internet? Certainly they need to communicate internally, but do they need routable space? Also, stay tuned for some math homework. :) So, you're advising that all these trillions of nanites should, what, use NAT? Unroutable IP space of another kind? Why would we do that when we've already got virtually unlimited v6 address space? See what I mean? Personally I'd suspect something involving quantum states would be more likely for information passage, but who knows what the end result is? I very carefully tried to skirt the issue, since NAT is a hot-button topic for the most ardent of the IPv6 zealots. You were positing a world where we need addressing at a molecular level, my point is simply that in that world we may or may not be dealing with publicly routable space; but *more importantly*, even if we are, we're still covered. I wrote my email as a way of pointing out that maybe the concerns (on both sides)- aren't baseless, Please note that I try very hard not to dismiss anyone's concerns as baseless, whether I agree with them or not. As I mentioned in my previous message, I believe I have a pretty good understanding of how the "IPv6 conservationists" think. My concern however is that while their concerns have a basis, their premise is wrong. I wasn't intending yourself as the recipient keep in mind. However, IS their premise wrong? Is prudence looking at incomprehensible numbers and saying "we're so unlikely to run out that it just doesn't matter" Yeah, that's totally not what I'm saying, and I don't think even the most ardent IPv6 zealot is saying it either. What I'm saying is that there is a very solid, mathematical foundation on which to base the conclusion that ISPs handing out /48s to end users is a very reasonable thing to do. or is prudence "Well, we have no idea what's coming, so let's be a little less wild-haired in the early periods"? The theory being it's a lot harder to take away that /48 30 years from now than it is to just assign the rest of it to go along with the /56 (or /52 or whatever) if it turns out they're needed. I personally like your idea of reserving the /48 and issuing the /56. Thanks. :) I do recognize that even with all of the math in the world we don't know what the world will look like in 20 years, so *some degree* of pragmatism is valuable, especially as we're ramping up deployment. But your argument that it'll be hard to take away the /48 is almost certainly wrong. This isn't like handling out "Class A's" and "Class B's" in the early days of IPv4, when we're talking home users we're talking about PA space, which can be withdrawn at will. Even at the RIR level, assuming some unimaginable future where 400+ /48s per human on the planet isn't enough, they can simply revise their policies to require justification at some other level per user than /48, thereby proclaiming that an ISP's existing space is "adequate" by administrative fiat. In that sense I actually believe that we've learned the lessons from the early days of IPv4, and that we've adequately accounted for them in the current set of policies. ... and not to flog the expired equine, but we're still only talking about 1/8 of the available space. I'm not being snarky when I say that we really are dealing with numbers that are so large that it's hard for the hum
Re: another tilt at the Verizon FIOS IPv6 windmill
On 7/13/15, 3:43 PM, "NANOG on behalf of Ricky Beam" wrote: >On Sun, 12 Jul 2015 17:32:33 -0400, Ca By wrote: >> Yes, move your business to TWC. TWC has a proven v6 deployment and is >> actively engaged in the community, as where vz Fios is not. > >Yes, because TWC-BC's IPv6 support is stellar. Sorry, I misspelled >"non-existent". Business Class DOCSIS customers get a prefix automatically (unless you provide your own gateway and DHCPv6 isn¹t enabled). Since it¹s dynamic, it might change; working on providing stable prefixes. http://www.timewarnercable.com/en/support/internet/topics/ipv6.html > >Their "DIA" (metro-e) stuff, *might*, but I doubt it. > Does, but since it requires BGP or static route configuration, you have to ask. Lee
Re: Dual stack IPv6 for IPv4 depletion
On Wed, 15 Jul 2015 15:20:08 -0400, Owen DeLong wrote: That's the big difference - IPv6 has been designed to provide abundant address space. There is no amount of fixed address space that can't be consumed with stupid allocation policies. True. However, are you making the argument that any of the current or proposed allocation policies are, in fact, stupid in such a way that this is likely? What seems like a great idea today becomes tomorrow's "what the f*** were they thinking".
RE: Dual stack IPv6 for IPv4 depletion
George Metz wrote: > > snip > > Split the difference, go with a /52 > >> > > > > That's not splitting the difference. :) A /56 is half way between a > > /48 and a /64. That's 256 /64s, for those keeping score at home. > > > > It's splitting the difference between a /56 and a /48. I can't imagine short > of > the Nanotech Revolution that anyone really needs eight thousand separate > networks, and even then... Besides, I recall someone at some point being > grumpy about oddly numbered masks, and a /51 is probably going to trip > that. :) > > I think folks are missing the point in part of the conservationists, and all > the > math in the world isn't going to change that. While the... let's call them > IPv6 > Libertines... are arguing that there's no mathematically foreseeable way > we're going to run out of addresses even at /48s for the proverbial soda > cans, the conservationists are going, "Yes, you do math wonderfully. > Meantime is it REALLY causing anguish for someone to only get > 256 (or 1024, or 4096) networks as opposed to 65,536 of them? If not, why > not go with the smaller one? It bulletproofs us against the unforeseen to an > extent." You are looking at this from the perspective of a network manager, and not considering the implications of implementing plug-n-play for consumers. A network manager can construct a very efficient topology with a small number of bits, but automation has to make "gross waste" trade-offs to "just work" when a consumer plugs things together without understanding the technology constraints. Essentially the conservationist argument is demanding waste, because the unallocated prefixes will still be sitting on the shelf in 400 years. It would be better to allocate them now and allow innovation at the cpe level, rather than make it too costly for cpe vendors to work around all the random allocation sizes in addition to the random ways people plug the devices together. > > As an aside, someone else has stated that for one reason or another IPv6 is > unlikely to last more than a couple of decades, and so even if something > crazy happened to deplete it, the replacement would be in place anyhow > before it could. I would like to ask what about the last 20 years of IPv6 > adoption in the face of v4 exhaustion inspires someone to believe that just > because it's better that people will be willing to make the change over? TDM voice providers had 100 years of history on their side, but voip won, because cheaper always wins.
Re: another tilt at the Verizon FIOS IPv6 windmill
On Wed, 15 Jul 2015 16:20:11 -0400, Lee Howard wrote: Business Class DOCSIS customers get a prefix automatically (unless you provide your own gateway and DHCPv6 isn¹t enabled). I looked last night at the office in Cary, NC. NO RAs are seen on the link coming from the Ubee (bridged) providing our dynamic/DOCSIS connection. Without an RA, nothing will attempt IPv6. (I've not checked the one in Raleigh that's also a hotspot) Residential? sure, there's lot of v6 there -- has been for over a year. But as I'm an Earthlink customer, and those morons cannot be bothered to give TWC one of their *5* UNUSED /32's, all I get is: (IA_PD IAID:327681 T1:0 T2:0 (status code no prefixes)) --Ricky
Re: Dual stack IPv6 for IPv4 depletion
On Wed, 15 Jul 2015 16:23:36 -0400, "Ricky Beam" said: > What seems like a great idea today becomes tomorrow's "what the f*** were > they thinking". However, this statement doesn't provide any actual guidance, as it's potentially equally applicable to the "give each end customer a /48" crew and the "Give them all a /56" crew. Actually, not true - in fact, it's demonstrable that a residential customer can run through a /56. Just get a largish house, put up one router using CeroWRT (or, I suspect a current/recent OpenWRT) that burns through 6-7 subnet allocations), and then put a second one at the other end of the house and it burns through 6-7. The second one has to dhcp-pd request at least 3 bits for itself, which leaves the first one only 5 bits, of which *it* will burn at least 3. If you create any VLANs at all, you just burned 4 and 4 bits, and there goes that /56. And that's burned all the subnets in a /56 *just hooking up 2 plug and play routers*. There's none left for doing anything experimental/different. (And I suspect Dave Taht can provide several CeroWRT config checkboxes that will each burn another 1-3 bits each if you click on them and hit "apply" :) pgpZ7MycwlIPn.pgp Description: PGP signature
Re: Dual stack IPv6 for IPv4 depletion
On July 15, 2015 at 09:20 o...@delong.com (Owen DeLong) wrote: > > There are two ways to waste addresses. One is to allocate them to users who > don
Re: Dual stack IPv6 for IPv4 depletion
On 7/15/15 1:48 PM, valdis.kletni...@vt.edu wrote: On Wed, 15 Jul 2015 16:23:36 -0400, "Ricky Beam" said: What seems like a great idea today becomes tomorrow's "what the f*** were they thinking". However, this statement doesn't provide any actual guidance, as it's potentially equally applicable to the "give each end customer a /48" crew and the "Give them all a /56" crew. Actually, not true - in fact, it's demonstrable that a residential customer can run through a /56. Just get a largish house, put up one router using CeroWRT (or, I suspect a current/recent OpenWRT) that burns through 6-7 subnet allocations), and then put a second one at the other end of the house and it burns through 6-7. The second one has to dhcp-pd request at least 3 bits for itself, which leaves the first one only 5 bits, of which *it* will burn at least 3. If you create any VLANs at all, you just burned 4 and 4 bits, and there goes that /56. And that's burned all the subnets in a /56 *just hooking up 2 plug and play routers*. There's none left for doing anything experimental/different. (And I suspect Dave Taht can provide several CeroWRT config checkboxes that will each burn another 1-3 bits each if you click on them and hit "apply" :) I tend to think that you're correct here, Validis; which is why I suggest reserving the /48 per customer whatever they decide to assign. I think the problem of expanding the assignment to a more reasonable size will happen on its own since at some point the support calls for "hey, I need more space!" will become a burden. Doug -- I am conducting an experiment in the efficacy of PGP/MIME signatures. This message should be signed. If it is not, or the signature does not validate, please let me know how you received this message (direct, or to a list) and the mail software you use. Thanks! signature.asc Description: OpenPGP digital signature
Re: Dual stack IPv6 for IPv4 depletion
> On Jul 15, 2015, at 13:23 , Ricky Beam wrote: > > On Wed, 15 Jul 2015 15:20:08 -0400, Owen DeLong wrote: That's the big difference - IPv6 has been designed to provide abundant address space. >>> >>> There is no amount of fixed address space that can't be consumed with >>> stupid allocation policies. >> >> True. However, are you making the argument that any of the current or >> proposed allocation policies are, in fact, stupid in such a way that this is >> likely? > > What seems like a great idea today becomes tomorrow's "what the f*** were > they thinking". But I can already say “what the F*** were they thinking about /60. I can kind of see it being valid on /56. I have a harder time arguing about /52s, but once you go that far is there any meaningful difference that makes it worth the trouble not going to /48? Besides, if /48s don’t become tomorrows what the f*** were they thinking, then it will be something else. I will point out that nobody has said “what the F*** were they thinking” when they made it possible to use 4GB of RAM instead of just 640k, but lots of people have said “what the F*** were they thinking when they limited it to 640k.” Owen
Re: Dual stack IPv6 for IPv4 depletion
> On Jul 15, 2015, at 13:55 , Barry Shein wrote: > > > On July 15, 2015 at 09:20 o...@delong.com (Owen DeLong) wrote: >> >> There are two ways to waste addresses. One is to allocate them to users who >> don,Abt actually use all of them. >> >> The other is to keep them on the shelf in the free pool until well past the >> useful >> life of the protocol. > > I'd add a third which is segmentation and I think that's a real > threat. That is, assigning large chunks to specific functions by > policy usually in support of technical needs. For example IPv4's > multicast block. Poof, 224/4 gone. Or similar. > > Suddenly it's not 2^N bits it's just N bits. > > My claim is that such segmentation tends to grow over time as people > find good arguments to segment. > fd00::/8 is already wasted on ULA. fe80::/10 (effectively fe00::/8) is already allocated (somewhat wastefully, as a /64 probably would do the trick) to link local ff00::/8 is already allocated to multicast. That covers multicast and RFC-1918. Are there any other IPv4 segmentations that you can think of? I’m not being snarky… I’m genuinely interested. Given that we came up with 3 total segmentations in IPv4 over the course of 30 years of IPv4 protocol use, which consumed a total of /4(multicast)+/8+/12+/16(RFC-1918)+/16(link local) of IPv4 and 3 /8s of IPv6. Even if we toss 5 more /8s to segmentation over the next 30 years, I think we’re OK, though we would have burned through a /5 at that point in segmentation. I think effectively, we can consider that e000::/3 is essentially set aside for such purposes and we still have 5/8ths of the address space after burning through the current /3 of unicast and a second /3 of unicast while we contemplate a more restrictive policy. Owen > -- >-Barry Shein > > The World | b...@theworld.com | http://www.TheWorld.com > Purveyors to the Trade | Voice: 800-THE-WRLD| Dial-Up: US, PR, Canada > Software Tool & Die| Public Access Internet | SINCE 1989 *oo*
Re: Dual stack IPv6 for IPv4 depletion
On Wed, 15 Jul 2015 17:23:52 -0400, Owen DeLong wrote: I will point out that nobody has said “what the F*** were they thinking” when they made it possible to use 4GB of RAM instead of just 640k, but lots of people have said “what the F*** were they thinking when they limited it to 640k.” Actually, they did. And "PAE" was invented. (or "re-invented", as various paging mechanisms had existed for many decades by then)
Re: Dual stack IPv6 for IPv4 depletion
On Wed, 15 Jul 2015 17:34:13 -0400, Owen DeLong wrote: That covers multicast and RFC-1918. Are there any other IPv4 segmentations that you can think of? ... Given that we came up with 3 total segmentations in IPv4 over the course #1-3,#4 RFC-1918 is 3 "segments" and we recently added a 4th (for CGN). #5 Localhost (127/8) #6 Multicast (224/4) #7 "Class E" (240/4) #8 0/8 #9 255/8 (technically, part of class e, but it's called out specifically in various RFCs)
Re: ATT wireless IPv6
On 15/07/15 04:54, Jared Mauch wrote: > Does anyone know what the story is here? They have some transparent proxies > for IPv4 traffic and I was wondering if they were to be IPv6 enabled soon or > if IPv6 will reach the handset. Hmmm... I'm seeing my rmnet1 interface on my Galaxy S5 as having an address out of the 2600:380:46ae::/38 space which is allocated to AT&T Mobility. -- /*=[ Jake Khuon ]=+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| NETWORKS | +==*/ signature.asc Description: OpenPGP digital signature
Re: ATT wireless IPv6
> On Jul 15, 2015, at 6:29 PM, Jake Khuon wrote: > > On 15/07/15 04:54, Jared Mauch wrote: >> Does anyone know what the story is here? They have some transparent proxies >> for IPv4 traffic and I was wondering if they were to be IPv6 enabled soon or >> if IPv6 will reach the handset. > > Hmmm... I'm seeing my rmnet1 interface on my Galaxy S5 as having an > address out of the 2600:380:46ae::/38 space which is allocated to AT&T > Mobility. I exchanged a few emails earlier today with someone and it seems to depend on your APN. If you have the VoLTE APN on your device you can get IPv6, including when tethering. The APN you want is nxtgenphone. If you have a device where you can not edit the APN settings (iPhone) you can not use the IPv6 enabled VoLTE APN. I suspect this will be enabled if they launch VoLTE on the iPhone. - Jared
Re: Dual stack IPv6 for IPv4 depletion
joel jaeggli wrote: On 7/15/15 10:24 AM, Joe Maimon wrote: The jury is still out on class E, but the verdict is in for the community who created it. joel@ubuntu:~$ uname -a Linux ubuntu 3.8.0-44-generic #66~precise1-Ubuntu SMP Tue Jul 15 04:01:04 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux joel@ubuntu:~$ sudo ifconfig eth0:0 240.0.0.1/24 SIOCSIFADDR: Invalid argument SIOCSIFFLAGS: Cannot assign requested address SIOCSIFNETMASK: Cannot assign requested address So your point is that those who claimed it would not help managed to make it so? Would it have really hurt to remove experimental status and replace it with use at your own risk status? Even now? now go test that on every exisitng ipv4 device on the planet that's not getting an upgrade. Thanks to (continuing) shortsightedness that course of action is still foreclosed. it doesn't extend the life of ipv4 usefully and it wouldn't have if we started 10 years ago either. You dont know either of those. However, by continuing to insist on them, you make it so. the goal in stringing along ipv4 is to not hose your current or potential customers rather than prevent still more obstacles to their success. joel At this point, you are running the risk of conflating your goals with your technical objections to the goals of others. And this has always been the real underlying issue. Joe
Re: Dual stack IPv6 for IPv4 depletion
Ricky Beam wrote: On Wed, 15 Jul 2015 15:20:08 -0400, Owen DeLong wrote: That's the big difference - IPv6 has been designed to provide abundant address space. There is no amount of fixed address space that can't be consumed with stupid allocation policies. True. However, are you making the argument that any of the current or proposed allocation policies are, in fact, stupid in such a way that this is likely? What seems like a great idea today becomes tomorrow's "what the f*** were they thinking". There will be ample evidence of what any and all of were saying. Thinking, maybe not.
Re: Dual stack IPv6 for IPv4 depletion
Doug Barton wrote: On 7/15/15 10:24 AM, Joe Maimon wrote: I suspect a 16 /8 right about now would be very welcome for everybody other then the ipv6 adherents. Globally we were burning through about a /8 every month or two in "the good old days." So in the best case scenario we'd get 32 more months of easy to get IPv4, but at an overwhelming cost to re-implement every network stack. This option was considered back in the early 2000's when I was still involved in the discussion, and rejected as impractical. Removing experimental status does not equate with the burden of making it equivalent use to the rest of the address space. How about the ARIN burn rate post IANA runout? How long does 16 /8 last then? What would be wrong with removing experimental status and allowing one of the /8 to be used for low barrier to /16 assignment to any party demonstrating a willingness to coax usability of the space? Yes, any such effort has to run the gauntlet of IETF/IANA/RIR policy. CGN /10 managed. This could too, if all the naysayers would just step out of the way.
Re: Dual stack IPv6 for IPv4 depletion
John Levine wrote: I suspect a 16 /8 right about now would be very welcome for everybody other then the ipv6 adherents. It would, if the software supported it. But it doesn't. Is there any reason to think the world would update its TCP stacks to handle those extra IPv4 addresses any sooner than it'd update its stacks to handle IPv6? Doesn't seem likely. R's, John Are you really equating an incremental silent update to remove something between one if statement or slightly more and an entire protocol stack that when active fundamentally changes the host networking behavior? This objection hinges on the assumption that if there is even ONE host on the network that will not accept that address, then the entire effort was a waste. Because there would then be no difference to the many many IPv4 (and IPv6) updates that were made with no guarantee of universal adoption. Its not really standards place to make that judgement call. Worse, it is not the standards role to ensure the outcome by making that judgement call. Joe
Re: Dual stack IPv6 for IPv4 depletion
On 07/15/2015 02:23 PM, Owen DeLong wrote: I will point out that nobody has said “what the F*** were they thinking” when they made it possible to use 4GB of RAM instead of just 640k, but lots of people have said “what the F*** were they thinking when they limited it to 640k.” That 640k was the architectural limit imposed on Intel 16-bit 8086 system implementations, once you allocated fixed space for ROM. This was specific to the "IBM PC". This has to do with the 20-bit addressing used in the 8086. One could "grow" the address space externally, and some computer systems (not "IBM PC compatible") did so. Again, the 4-GB RAM limits is an architectural limit of the hardware; there is no "speed-of-light" limit in the amount of DRAM one can have in a system. Let's review the bidding on Internet Protocol, shall we? APRANET NCP (1970) -- 8-bit host Version 0 -- can't figure out the limit, if any; 4-bit "chunks" Version 1 -- 16-bit net/host address Version 2 -- variable! in octet increments Version 3 -- (not available) Version 4-78jun -- variable! in octet increments Version 4-78sep -- 32 bit net/host address, Class A (8-bit net) Version 5 -- (experimental circuit-switch protocol) Version 6 -- 128-bit
Re: Dual stack IPv6 for IPv4 depletion
In message <55a6ee2b.5040...@ttec.com>, Joe Maimon writes: > joel jaeggli wrote: > > On 7/15/15 10:24 AM, Joe Maimon wrote: > >> > >> The jury is still out on class E, but the verdict is in for the > >> community who created it. > > > > joel@ubuntu:~$ uname -a > > Linux ubuntu 3.8.0-44-generic #66~precise1-Ubuntu SMP Tue Jul 15 > > 04:01:04 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux > > > > joel@ubuntu:~$ sudo ifconfig eth0:0 240.0.0.1/24 > > SIOCSIFADDR: Invalid argument > > SIOCSIFFLAGS: Cannot assign requested address > > SIOCSIFNETMASK: Cannot assign requested address > > > > So your point is that those who claimed it would not help managed to > make it so? No. The test was there before the requests which is why people were saying that it wouldn't work without upgrading lots of machines. > Would it have really hurt to remove experimental status and replace it > with use at your own risk status? Even now? No, but you couldn't assign the addresses to users for another decade or more without there being problems. We still haven't removed all the class based code out there and that is 20 years now. For quite a while one had to be careful to not use the first and last blocks when subnetting. The use of addresses ending in .0 (class C) or .0.0 (class B) is still problematic with supernets. > > now go test that on every exisitng ipv4 device on the planet that's not > > getting an upgrade. > > Thanks to (continuing) shortsightedness that course of action is still > foreclosed. > > > > > it doesn't extend the life of ipv4 usefully and it wouldn't have if we > > started 10 years ago either. > > You dont know either of those. > > However, by continuing to insist on them, you make it so. Do you think adding 2 more years would have done anything except let people procrastinate for 2 more years before starting to deploy IPv6? Vendors have had 15 years to develop products that support IPv6. That was more than enough time. We added IPv6 support to BIND back in the 1990's. DHCP has supported IPv6 just about as long. F was running on IPv6 years before the root servers officially supported IPv6. Just in time is nice if it works but it hasn't. We have people that are only contactable over IPv6 because they are now behind CGNs but everyone doesn't have IPv6 available to them. That is a failure of the industry to deploy IPv6 in time. > > the goal in stringing along ipv4 is to not hose your current or > > potential customers rather than prevent still more obstacles to their > > success. > > > > joel > > > > At this point, you are running the risk of conflating your goals with > your technical objections to the goals of others. And this has always > been the real underlying issue. > > Joe -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Dual stack IPv6 for IPv4 depletion
> On Jul 15, 2015, at 7:45 PM, Joe Maimon wrote: > > > > Doug Barton wrote: >> On 7/15/15 10:24 AM, Joe Maimon wrote: >>> I suspect a 16 /8 right about now would be very welcome for everybody >>> other then the ipv6 adherents. >> >> Globally we were burning through about a /8 every month or two in "the >> good old days." So in the best case scenario we'd get 32 more months of >> easy to get IPv4, but at an overwhelming cost to re-implement every >> network stack. >> >> This option was considered back in the early 2000's when I was still >> involved in the discussion, and rejected as impractical. >> > > > Removing experimental status does not equate with the burden of making it > equivalent use to the rest of the address space. > > How about the ARIN burn rate post IANA runout? How long does 16 /8 last then? > > What would be wrong with removing experimental status and allowing one of the > /8 to be used for low barrier to /16 assignment to any party demonstrating a > willingness to coax usability of the space? > > Yes, any such effort has to run the gauntlet of IETF/IANA/RIR policy. > > CGN /10 managed. This could too, if all the naysayers would just step out of > the way. This isn’t really a giant set of naysayers IMHO, but there is enough embedded logic in devices that it doesn’t make that much sense. Either you can survive with some type of NAT or you can’t. Many of my devices would not be missing capabilities if I had just IPv6 on them with some gateway to reach the IPv4 internet. I could likely make a short list of the sites that I really need access to that are IPv4 only. With Amazon/Walmart day, they would be well suited to have a fast IPv6 site :) It’s just a few operating systems that need to be changed: windows linux various *bsd flavors macos I don’t think it’s impossible, but so many things check for 224 > A > 1 it would be a large bit of work to fix those. This is excluding the routing equipment. What i’ve learned is that stuff like the netgear/linksys you have at your house spends around ~6 months in the supply chain before it reaches you. these all need to be updated as well as the “big iron” stuff like cisco/juniper/arista as well as their embedded OS underneath, so maybe QNX or something else ‘odd’. That effort would need to have everyone moving in the same direction now which seems unlikely. - Jared
Re: Dual stack IPv6 for IPv4 depletion
Owen DeLong wrote: On Jul 15, 2015, at 10:24 , Joe Maimon wrote: I suspect a 16 /8 right about now would be very welcome for everybody other then the ipv6 adherents. But it wouldn’t be right now. It would be after everyone put lots of effort into updating lots of systems so that they could support those 16 /8s. I propose allowing and accepting that people get to decide on their own where to focus their efforts. I dont believe in top down management. I also dont believe that the available pool of other people efforts is a zero sum game. By the time you’ve done that, you might as well have focused that effort on making those same systems do IPv6. See above. Seems like procrastination is only bad when its your baby. Not really… This isn’t a question of procrastination or not. It’s a question of given that roughly the same effort is required to do thing A or thing B and thing A (class E) leads nowhere in the long run while thing B provides a permanent solution, it makes much more sense to focus said effort on thing B than to postpone thing B in favor of thing A. See above. And really? "same effort?" The jury is still out on class E, but the verdict is in for the community who created it. Not really. I think if you really consider what would be required for deployment of class E, you’ll find that there truly is no there there. Owen I am not advocating class E adoption. I am advocating removal of barrier to adoption and I will go so far as to advocate a bootstrapped incentive for adoption, for those who get to choose on their own how to focus their own efforts. Its nice to point out that we are rehashing the exact debate you and I had a few years back. Self-fulfilling. Joe
Re: Dual stack IPv6 for IPv4 depletion
On 7/15/15 4:35 PM, Joe Maimon wrote: > At this point, you are running the risk of conflating your goals with > your technical objections to the goals of others. And this has always > been the real underlying issue. My goal in an operational capacity is to continue to hold onto the quality and utility of IPv4 services until my customers don't need them anymore whether that comes 5 years from now, 10 or never. balkanzing them on the basis of what prefixes they can reach, and consigning new or growning entrants to address ranges that poorly serve the installed base doesn't serve that end. IPv4 as a mature deployed technology is quite successful at resisting innovation whether in the forwarding plane or at the transport. When I consider where I should be expending resources on IPv4 inovation or elsewhere, I look to minimize the NRE I have to expend sustaining IPv4. > Joe > signature.asc Description: OpenPGP digital signature
Re: Dual stack IPv6 for IPv4 depletion
On Wed, 15 Jul 2015 19:35:07 -0400, Joe Maimon wrote: So your point is that those who claimed it would not help managed to make it so? Would it have really hurt to remove experimental status and replace it with use at your own risk status? Even now? No. The point is it's been wired into everything that has ever existed that it's an invalid address. Even if the "experimental" had been moved 15 years ago, there would still be devices today that CANNOT use one of those addresses, and further, is 100% incapable of talking to anything using one. Interestingly, Cisco, who proposed using the space, still has those restrictions embedded in everything they make. (Of course, their non-nexus switches still have token-ring and fddi translation vlans hardcoded.) Factor in the people who cannot do math and think multicast is "anything greater than 224.0.0.0", and you have a section of address space that is permanently unusable. (like 1.1.1.0/24 and 1.2.3.0/24) I'm not going to name names, but I've see proprietary code -- from more than one source -- that did that, because "bge [branch greater or equal] is a single instruction." If you think that's a "lame optimization", then you should be hunting down *everything* responsible for SLAAC.
Re: Dual stack IPv6 for IPv4 depletion
Jared Mauch wrote: This isn’t really a giant set of naysayers IMHO, but there is enough embedded logic in devices that it doesn’t make that much sense. Enough to scuttle all previous drafts. linux a little google comes up with this http://www.gossamer-threads.com/lists/linux/kernel/866043 It defies reason to compare that kind of update to ipv6. various *bsd flavors That effort would need to have everyone moving in the same direction now which seems unlikely. - Jared All I ever wanted to see was that the (minimal) effort was made possible. No guarantee of its success should be required for that. Even now. Because by doing so, you guarantee failure. Joe
Re: Dual stack IPv6 for IPv4 depletion
> On Jul 15, 2015, at 16:45 , Joe Maimon wrote: > > > > Doug Barton wrote: >> On 7/15/15 10:24 AM, Joe Maimon wrote: >>> I suspect a 16 /8 right about now would be very welcome for everybody >>> other then the ipv6 adherents. >> >> Globally we were burning through about a /8 every month or two in "the >> good old days." So in the best case scenario we'd get 32 more months of >> easy to get IPv4, but at an overwhelming cost to re-implement every >> network stack. >> >> This option was considered back in the early 2000's when I was still >> involved in the discussion, and rejected as impractical. >> > > > Removing experimental status does not equate with the burden of making it > equivalent use to the rest of the address space. > > How about the ARIN burn rate post IANA runout? How long does 16 /8 last then? Assuming you could somehow make 16 /8s available, do you really think that anyone would accept the idea of allocating all of them to a single RIR, let alone the one in North America? I tend to doubt it. So ARIN’s burn rate post-runout really isn’t all that relevant. > What would be wrong with removing experimental status and allowing one of the > /8 to be used for low barrier to /16 assignment to any party demonstrating a > willingness to coax usability of the space? The wasted effort of people whose time is better spent deploying IPv6. > Yes, any such effort has to run the gauntlet of IETF/IANA/RIR policy. Which I would rather have those folks focused on something useful than wasting their time on this. > CGN /10 managed. This could too, if all the naysayers would just step out of > the way. The /10 did not require modifying every system on the internet or even any systems on the internet. It just required setting aside a block. Even then, it was actually more effort than it should have required, but it was pretty minimal. OTOH, it provided an actual usable solution to a real world problem. What you are proposing just wastes a lot of people’s time with nothing to show for it. Owen
Re: Dual stack IPv6 for IPv4 depletion
> On Jul 15, 2015, at 14:43 , Ricky Beam wrote: > > On Wed, 15 Jul 2015 17:23:52 -0400, Owen DeLong wrote: >> I will point out that nobody has said “what the F*** were they thinking” >> when they made it possible to use 4GB of RAM instead of just 640k, but lots >> of people have said “what the F*** were they thinking when they limited it >> to 640k.” > > Actually, they did. And "PAE" was invented. (or "re-invented", as various > paging mechanisms had existed for many decades by then) Huh? You’re missing the point or deliberately ignoring it, hard to tell which. Vast address availability has never lead to WTF moments. Restrictive addressing, OTOH, has created many WTF moments. I look at NAT and I think WTF were they thinking, but it was an unfortunate consequence of the 32-bit limitation of IPv4. It’s an effort at coping with the limitations, however misguided it may be. I look at providers handing out /60 and I think WTF are they thinking. There’s no legitimate reasoning behind it. Why repeat the same mistakes again by limiting IPv6 deployments to something less than /48? As to your arguments on segmentation, no, RFC1918 is 3 segments because, again, of limitations in IPv4. In IPv6, it’s still only one segment. Arguing that the 4th (which actually isn’t RFC-1918) is a segmentation isn’t entirely valid as it’s more of an allocation than a segmentation and in any case, all of them are more than covered in the single existing IPv6 segmentation of fc00::/0 or even fd00::/9. Class E isn’t so much a segmentation as an early error that never got corrected. By the time anyone recognized the need to fix class E, it was easier to move to IPv6 than to repair that part of IPv4, so we moved on. 255/8 is not really still applicable and does not apply to IPv6 in any way, so I don’t think you can count that one. Same with 0/8. These weren’t segmentations, they were limitations of the technology at the time those RFCs were written. You can argue that localhost is a segmentation, I suppose, but in IPv6, it has reserved ::1/128. Everything else in ::/3 is still available to the best of my knowledge. So, in terms of total impact on IPv6, we’ve got three segmentations other than Unicast that are carried forward from IPv4. No more, no less. (unless someone comes up with something not yet mentioned). Owen
Re: Dual stack IPv6 for IPv4 depletion
Are you really equating an incremental silent update to remove something between one if statement or slightly more and an entire protocol stack that when active fundamentally changes the host networking behavior? Yeah. On the devices I have, there's no practical difference between a one line update and a complete reload. Either you update the software or you don't, and mostly you don't. PCs and servers are easy, embedded routers and printers and the like are not. R's, John
Re: Dual stack IPv6 for IPv4 depletion
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 7/15/2015 6:00 PM, John R. Levine wrote: >> Are you really equating an incremental silent update to remove >> something between one if statement or slightly more and an entire >> protocol stack that when active fundamentally changes the host >> networking behavior? > > Yeah. On the devices I have, there's no practical difference > between a one line update and a complete reload. Either you > update the software or you don't, and mostly you don't. PCs and > servers are easy, embedded routers and printers and the like are > not. And on your mobile devices, for the most part you are reliant upon your carrier to make software updates available to you in a timely and utilitarian manner. In other words, don't hold your breath. Carriers are the major barrier to both feature upgrades and security fixes/enhancements. It is tremendously frustrating. - - ferg - -- Paul Ferguson PGP Public Key ID: 0x54DC85B2 Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlWnA/oACgkQKJasdVTchbJAWAD8DhRq1QlPZlZhH8Apr66od+NU Tz8F1bLqu6+3dymwNJEBANjyOh0jwwHhIZk1hOy/jIj8lCuUkYQjuFZlzZFYfwh8 =NuSw -END PGP SIGNATURE-
Re: Dual stack IPv6 for IPv4 depletion
On 7/15/15 4:45 PM, Joe Maimon wrote: Doug Barton wrote: On 7/15/15 10:24 AM, Joe Maimon wrote: I suspect a 16 /8 right about now would be very welcome for everybody other then the ipv6 adherents. Globally we were burning through about a /8 every month or two in "the good old days." So in the best case scenario we'd get 32 more months of easy to get IPv4, but at an overwhelming cost to re-implement every network stack. This option was considered back in the early 2000's when I was still involved in the discussion, and rejected as impractical. Removing experimental status does not equate with the burden of making it equivalent use to the rest of the address space. How about the ARIN burn rate post IANA runout? How long does 16 /8 last then? What would be wrong with removing experimental status and allowing one of the /8 to be used for low barrier to /16 assignment to any party demonstrating a willingness to coax usability of the space? Yes, any such effort has to run the gauntlet of IETF/IANA/RIR policy. CGN /10 managed. This could too, if all the naysayers would just step out of the way. Joe, In this post, and in your many other posts today, you seem to be asserting that this would work if "$THEY" would just get out of the way, and let it work. You've also said explicitly that you believe that this is an example of top-down dictates. I know you may find this hard to believe, but neither of these ideas turn out to be accurate. A little history ... In 2004 I was the manager of the IANA. Tony Hain came to me and said that he'd been crunching some numbers and his preliminary research indicated that the burn rate on IPv4 was increasing fairly dramatically, and that runout was likely to happen a lot sooner than folks expected it would. Various people started doing their own research along similar lines and confirmed Tony's findings. So amongst many others, I started taking various steps to "get ready" for IPv4 runout. One of those steps was to talk to folks about the feasibility of utilizing Class E space. Now keep in mind that I have no dog in this hunt. I've never been part of an RIR, I've never worked for a network gear company, I'm a DNS guy. To me, bits are bits. I was told, universally, that there was no way to make Class E space work, in the public Internet or private networks (because the latter was being considered as an expansion of 1918). There are just too many barriers, not the least of which is the overwhelming number of person-years it would take to rewrite all the software that has assumptions about Class E space hard coded. Further, the vendors we spoke to said that they had no intention of putting one minute's worth of work into that project, because the ROI was basically zero. In order for address space to "work" the standard is universal acceptance ... and that was simply never going to happen. There are literally hundreds of millions of devices in active use right now that would never work with Class E space because they cannot be updated. Of course it's also true that various folks, particularly the IETF leadership, were/are very gung ho that IPv6 is the right answer, so any effort put into making Class E space work is wasted effort; which should be spent on deploying IPv6. On a *personal* level I agree with that sentiment, but (to the extent I'm capable of being objective) I didn't let that feeling color my effort to get an honest answer from the many folks I talked to about this. But all that said, nothing is stopping YOU from working on it. :) The IETF can't stop you, the vendors can't stop you, no one can stop you ... if you think you can make it work, by all means, prove us all wrong. :) Find some others that agree with you, work on the code, do the interoperability tests, and present your work. You never know what might happen. In the meantime, please stop saying that not using this space was dictated from the top down, or that any one party/cabal/etc. is holding you back, because neither of those are accurate. Good luck, Doug -- I am conducting an experiment in the efficacy of PGP/MIME signatures. This message should be signed. If it is not, or the signature does not validate, please let me know how you received this message (direct, or to a list) and the mail software you use. Thanks! signature.asc Description: OpenPGP digital signature
RE: Dual stack IPv6 for IPv4 depletion
Joe Maimon wrote: > Jared Mauch wrote: > > > > > This isn’t really a giant set of naysayers IMHO, but there is enough > embedded logic in devices that it doesn’t make that much sense. > > Enough to scuttle all previous drafts. > > > linux > > a little google comes up with this > > http://www.gossamer-threads.com/lists/linux/kernel/866043 > > It defies reason to compare that kind of update to ipv6. > > > various *bsd flavors > > > That effort would need to have everyone moving in the same direction > now which seems unlikely. > > > > - Jared > > All I ever wanted to see was that the (minimal) effort was made possible. > No guarantee of its success should be required for that. Even now. > > Because by doing so, you guarantee failure. Joe, It appears you are asking for the world to sanction your local efforts. There is nothing stopping you from deploying and using that space if you can. Asking for a change in the standards status though will only lead to confusion and anguish. If 15 years ago it had been, or would now be changed to unicast, people would expect to be able to use it as they use the rest of the space. Those with access to source for all their devices could accomplish that, but everyone else would have to beat on vendors and wait an indeterminate time to get usable code, and that still would not fix rom based devices. On the other hand people with source don't need any standards change, they can just turn it on. If you want the additional effort to manage a global distribution of the space so it is not just an extension of 1918, then you have to acknowledge that it would only last a few weeks at best. While ARIN managed to change policy and slow things down, when APnic flamed out they burned through 6 /8's in 8 weeks and were accelerating, while Ripe was burning through one every 3 months, and Lacnic was accelerating through their last one over 4 months. So ignoring pent up demand since they have all been out for awhile now, and assuming that they space was generically usable, you get 8 weeks tops. Recognizing that they are not generically usable though it will likely take quite a bit longer than that. This is not being a naysayer, it is simply presenting issues that have been raised and considered many times over the last 15 years. There is a lot of work to make that space usable, and as you pointed out above the smallest part of that is the code change. In the context of the amount of work required in relation to the few weeks of gain that would result, it has always been difficult to establish much interest. At the end of the day it is not that much more work to fix all the devices to run IPv6. At that point you have no limitations, while 240/4 still leads to the place where the IPv4 pool is exhausted. Tony
Re: M$ no v6 or just me?
Thanks for the tests that show the NODATA is from the authoritative nameserver. To clarify, Google DNS does not filter either or any of these domains. Yunhong On Tue, Jul 14, 2015 at 8:05 PM, Yang Yu wrote: > On Wed, Jul 15, 2015 at 4:33 AM, Nicholas Warren > wrote: > > Surely Microsoft has IPv6 connectivity? Is there a problem with my dns, > or is Microsoft not available over v6? > > > > Thanks, > > Nich > > > > probably not Google DNS filtering > > > test point 1 > > $ dig e10088.dspb.akamaiedge.net @n0dspb.akamaiedge.net > > ; <<>> DiG 9.10.2-P2 <<>> e10088.dspb.akamaiedge.net @ > n0dspb.akamaiedge.net > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51914 > ;; flags: qr aa rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 > ;; WARNING: recursion requested but not available > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;e10088.dspb.akamaiedge.net.IN > > ;; AUTHORITY SECTION: > dspb.akamaiedge.net.1000IN SOA n0dspb.akamaiedge.net. > hostmaster.akamai.com. 1436917052 1000 1000 1000 1800 > > ;; Query time: 51 msec > ;; SERVER: 96.7.248.137#53(96.7.248.137) > ;; WHEN: Wed Jul 15 08:37:32 KST 2015 > ;; MSG SIZE rcvd: 119 > > > > test point 2 > > $ dig e10088.dspb.akamaiedge.net @n0dspb.akamaiedge.net > > ; <<>> DiG 9.8.1-P1 <<>> e10088.dspb.akamaiedge.net @ > n0dspb.akamaiedge.net > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27887 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 > ;; WARNING: recursion requested but not available > > ;; QUESTION SECTION: > ;e10088.dspb.akamaiedge.net.IN > > ;; ANSWER SECTION: > e10088.dspb.akamaiedge.net. 20 IN 2600:1408:10:18f::2768 > e10088.dspb.akamaiedge.net. 20 IN 2600:1408:10:181::2768 > e10088.dspb.akamaiedge.net. 20 IN 2600:1408:10:188::2768 > > ;; Query time: 18 msec > ;; SERVER: 88.221.81.193#53(88.221.81.193) > ;; WHEN: Tue Jul 14 16:37:17 2015 > ;; MSG SIZE rcvd: 128 > > > I get different IPs for n0dspb.akamaiedge.net / n0dscb.akamaiedge.net > every time. > > So it depends on source IP of the query and which akamai DNS server is > answering? >
Re: Remember "Internet-In-A-Box"?
In message <55a682e6.1050...@matthew.at>, Matthew Kaufman writes: > On 7/14/2015 11:22 PM, Mark Andrews wrote: > > > > Yet I can take a Windows XP box. Tell it to enable IPv6 and it > > just works. Everything that a node needed existed when Windows XP > > was released. The last 15 years has been waiting for ISP's and CPE > > vendors to deliver IPv6 as a product. This is not to say that every > > vendor deployed all the parts of the protocol properly but they > > existed. > > This is only true for dual-stacked networks. I just tried to set up an > IPv6-only WiFi network at my house recently, and it was a total fail due > to non-implementation of relatively new standards... starting with the > fact that my Juniper SRX doesn't run a load new enough to include RDNSS > information in RAs, and some of the devices I wanted to test with > (Android tablets) won't do DHCPv6. You can blame the religious zealots that insisted that everything DHCP does has to also be done via RA's. This means that everyone has to implement everything twice. Something Google should have realised when they releases Android. > The XP box is in an even worse situation if you try to run it on a > v6-only network. Which is fixable with a third party DHCPv6 client / manual configuration of the nameservers. > And yet we've known for years now that dual-stack wasn't going to be an > acceptable solution, because nobody was on track to get to 100% IPv6 > before IPv4 runout happened. > > Go to any business with hardware that is 3-5 years old in its IT > infrastructure and devices ranging from PCs running XP to the random > consumer gear people bring in (cameras, printers, tablets, etc.) and see > how easy it is to get everything talking on an IPv6-only (no IPv4 at > all) network... including using IPv6 to do automatic updates and all the > other pieces that need to work. We're nowhere near ready for that. None of which is the fault of the protocol. Blame the equipement vendors for being negligent. > Matthew Kaufman > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Remember "Internet-In-A-Box"?
On 7/15/15 7:32 PM, Mark Andrews wrote: Go to any business with hardware that is 3-5 years old in its IT infrastructure and devices ranging from PCs running XP to the random consumer gear people bring in (cameras, printers, tablets, etc.) and see how easy it is to get everything talking on an IPv6-only (no IPv4 at all) network... including using IPv6 to do automatic updates and all the other pieces that need to work. We're nowhere near ready for that. None of which is the fault of the protocol. Blame the equipement vendors for being negligent. I could blame the people doing IT in those environments too, but that doesn't make it so that nobody needs IPv4 addresses to deploy servers to keep talking to these folks. Matthew Kaufman
Re: Remember "Internet-In-A-Box"?
* Owen DeLong > > On Jul 15, 2015, at 08:57 , Matthew Kaufman wrote: > > This is only true for dual-stacked networks. I just tried to set up > > an IPv6-only WiFi network at my house recently, and it was a total > > fail due to non-implementation of relatively new standards... > > starting with the fact that my Juniper SRX doesn't run a load new > > enough to include RDNSS information in RAs, and some of the devices > > I wanted to test with (Android tablets) won't do DHCPv6. > > That’s a pretty old load then, as I’ve had RDNSS on my SRX-100 for > several years now. Interesting. Which JUNOS version are you running, exactly? According to Juniper's web site, RDNSS support showed up in JUNOS 14.1, which isn't available for the SRX series (nor is any later version). http://www.juniper.net/techpubs/en_US/junos15.1/topics/reference/configuration-statement/dns-server-address-edit-protocols-router-advertisement.html Tore
Re: Remember "Internet-In-A-Box"?
On 07/15/2015 07:32 PM, Mark Andrews wrote: None of which is the fault of the protocol. Blame the equipement vendors for being negligent. I'm sorry, it is just me? Or is the issue before us to fix the PROBLEM and not fix the BLAME? Pointing fingers isn't going to help get us to widespread IPv6 use. Go to any business with hardware that is 3-5 years old in its IT infrastructure and devices ranging from PCs running XP to the random consumer gear people bring in (cameras, printers, tablets, etc.) and see how easy it is to get everything talking on an IPv6-only (no IPv4 at all) network... including using IPv6 to do automatic updates and all the other pieces that need to work. We're nowhere near ready for that. So, what is the SOLUTION, or the start of a SOLUTION?
Re: Remember "Internet-In-A-Box"?
On Thu 2015-Jul-16 12:32:19 +1000, Mark Andrews wrote: --snip-- You can blame the religious zealots that insisted that everything DHCP does has to also be done via RA's. This means that everyone has to implement everything twice. Something Google should have realised when they releases Android. oi...do we want to go down that road[1][2] again? -- Hugo h...@slabnet.com: email, xmpp/jabber PGP fingerprint (B178313E): CF18 15FA 9FE4 0CD1 2319 1D77 9AB1 0FFD B178 313E (also on textsecure & redphone) [1] http://mailman.nanog.org/pipermail/nanog/2015-June/075915.html [2] https://code.google.com/p/android/issues/detail?id=32621 signature.asc Description: Digital signature
Re: Remember "Internet-In-A-Box"?
> On Jul 15, 2015, at 19:32 , Mark Andrews wrote: > > > In message <55a682e6.1050...@matthew.at>, Matthew Kaufman writes: >> On 7/14/2015 11:22 PM, Mark Andrews wrote: >>> >>> Yet I can take a Windows XP box. Tell it to enable IPv6 and it >>> just works. Everything that a node needed existed when Windows XP >>> was released. The last 15 years has been waiting for ISP's and CPE >>> vendors to deliver IPv6 as a product. This is not to say that every >>> vendor deployed all the parts of the protocol properly but they >>> existed. >> >> This is only true for dual-stacked networks. I just tried to set up an >> IPv6-only WiFi network at my house recently, and it was a total fail due >> to non-implementation of relatively new standards... starting with the >> fact that my Juniper SRX doesn't run a load new enough to include RDNSS >> information in RAs, and some of the devices I wanted to test with >> (Android tablets) won't do DHCPv6. > > You can blame the religious zealots that insisted that everything > DHCP does has to also be done via RA's. This means that everyone > has to implement everything twice. Something Google should have > realised when they releases Android. Actually, no. In this case, the problem isn’t the things RA does, but the things his implementation of RA doesn’t do (RDNSS). Without RDNSS, android would still be brain-damaged and unable to figure out what an IPv6 nameserver is. The only way it would be able to talk to the IPv6 internet was if it got nameservers from DHCP4. At least with RDNSS, a thin lightweight client can get nameservers on IPv6. At least with RDNSS, a network administrator that doesn’t want to have to do DHCPv6 doesn’t have to in most cases. >> The XP box is in an even worse situation if you try to run it on a >> v6-only network. > > Which is fixable with a third party DHCPv6 client / manual configuration > of the nameservers. Nope… XP’s resolver is utterly and completely incapable of transmitting an IPv6 DNS request. You _HAVE_ to have an IPv4 resolver reachable to the box or forego any idea of using DNS. Owen
Re: Remember "Internet-In-A-Box"?
> On Jul 15, 2015, at 22:46 , Matthew Kaufman wrote: > > > > On 7/15/15 7:32 PM, Mark Andrews wrote: >> >> >> Go to any business with hardware that is 3-5 years old in its IT >> infrastructure and devices ranging from PCs running XP to the random >> consumer gear people bring in (cameras, printers, tablets, etc.) and see >> how easy it is to get everything talking on an IPv6-only (no IPv4 at >> all) network... including using IPv6 to do automatic updates and all the >> other pieces that need to work. We're nowhere near ready for that. >> None of which is the fault of the protocol. Blame the equipement vendors >> for being negligent. >> > > I could blame the people doing IT in those environments too, but that doesn't > make it so that nobody needs IPv4 addresses to deploy servers to keep talking > to these folks. > > Matthew Kaufman Need is not the problem. Availability is a problem now. It’s going to be a more difficult problem in the future. The sooner we get to where they are using IPv6 even if they’re just dual-stacked, the sooner availability becomes less of a problem due to the elimination of need. Since availability isn’t going to get better, really, the only option to make the situation better is to eliminate need. The best way to eliminate need for IPv4 is IPv6. It’s really as simple as that. Owen
