Remember "Internet-In-A-Box"?
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)
On Jul 14, 2015, at 4:46 PM, Stephen Satchell <list@satchell.net> 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”.
MCI (way back, original MCI when I worked there) had “MCI One” that was similar with bundled voice/internet/etc, may be what you’re thinking of or not…
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.
While I don’t disagree on a dummy package so to speak, I spent *years* explaining IPv4 to my mother, to no avail, so I highly doubt anyone can explain IPv6 to anyone outside of this (NANOG) group with any certainty, even if you call it “IPv6 for Dummies.” The “bundle” that you are talking about would have to be *literally* plug-n-play such that the end user would have no idea that it was IPv6 vs. IPv4 vs. any-other-IPv-anything.
Just my pair-o-pennies(tm)
Just my opinion after 25+ years of doing this stuff and trying to explain what I (or we) do to family/friends/etc. -b
In article <A1F92A0E-98F6-4AC0-AAA3-3FD7739D535E@the-watsons.org>, Brett Watson <brett@the-watsons.org> writes
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”.
MCI (way back, original MCI when I worked there) had MCI One that was similar with bundled voice/internet/etc, may be what you’re thinking of or not
There were numerous Internet "in a box" type products available in the 1994-95 timeframe, based largely on the existing Compuserve "in a box". I was responsible for the first one to go on sale in the UK, through a large chain of electronics retailers. The ISP was UK-Online. The commercial reason for the packs was to put the product in front of as many potential customers as possible, and make it easy to buy. Cover-disks on magazines had quite a wide circulation but didn't fully address the financial issues because... ...the corresponding operational reason was to overcome the bootstrapping problem of how do you sign someone up for an account and take a pre-payment if they aren't already online? A cover-disk could solve the problem of pre-installing the software needed, which in those days was generally a paid-for 3rd-party Stack and some kind of bulk-licenced browser (eg Trumpet + Netscape); but involved giving users a certain period of 'free trial', unless you employed the somewhat clumsy option of having them call in with credit card details during the set-up process. What an "in-a-box" product achieved was the ability to get wider distribution, because the retailer was typically receiving a 30% margin on his sale and therefore happy to have it on his shelves, but the ISP was also getting the 70% [less manufacturing cost, obviously] in order to part-fund the first month's access and the licence on the software, after which the person is online and can subscribe fully if they wish to continue. Even back then, there was the secondary effect that having spammers sign up to your service using a succession of "free trial" cover disks wasn't something to be encouraged. How any of this is relevant to IPv6 "in-a-box" I will leave as an exercise for the reader. Although my own inclination is to say it's much more to do with grappling with legacy hardware and operating systems that don't (either happily or at all) support IPv6, than getting a reasonably recent PC/CPE configured automagically via an existing IPv4 connection. -- Roland Perry
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. 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. Mike
Mike, I agree that something like that needs to be done. Maybe I’ll do it. In the meantime, have you got an IPv6 lab set up? I’m guessing that with your /32 allocation in hand, you likely do. Have you run through HE.net’s excellent personal IPv6 certification program? Until you gain fluency in IPv6, you won’t understand any advice anyway. If you’re already reasonably skilled at IPv6 manipulations, then you should be able to start designing a practical IPv6 deployment scheme. The essential processes are (a) getting IPv6 into your provisioning system, so you keep track of your assignments, and (b) distributing /48 (or whatever) prefixes to customers across your core network. (b) depends entirely on your IGP (OSPF, iBGP, MPLS, etc) and the CPE at your customers. -mel
On Jul 14, 2015, at 5:02 PM, Mike <mike-nanog@tiedyenetworks.com> 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.
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.
Mike
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. - Pete
In message <55A5B526.8030804@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: marka@isc.org
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
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
On Jul 15, 2015, at 08:57 , Matthew Kaufman <matthew@matthew.at> 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
* Owen DeLong <owen@delong.com>
On Jul 15, 2015, at 08:57 , Matthew Kaufman <matthew@matthew.at> 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/configurati... Tore
On Thu, Jul 16, 2015 at 07:59:14AM +0200, Tore Anderson wrote:
* Owen DeLong <owen@delong.com>
On Jul 15, 2015, at 08:57 , Matthew Kaufman <matthew@matthew.at> 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/configurati...
Strange. dns-server-address IS available to be configured on my MX box running 13.3R4. It is however not there for SRX on 12.1X44-D50.
On Fri 2015-Jul-17 12:36:51 -0400, Chuck Anderson <cra@WPI.EDU> wrote:
On Thu, Jul 16, 2015 at 07:59:14AM +0200, Tore Anderson wrote:
* Owen DeLong <owen@delong.com>
On Jul 15, 2015, at 08:57 , Matthew Kaufman <matthew@matthew.at> 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/configurati...
Strange. dns-server-address IS available to be configured on my MX box running 13.3R4.
It is however not there for SRX on 12.1X44-D50.
...or 12.1X46-D35.1 (JTAC bumped the rec'd release June 29th, so it's in the lab). -- Hugo hugo@slabnet.com: email, xmpp/jabber PGP fingerprint (B178313E): CF18 15FA 9FE4 0CD1 2319 1D77 9AB1 0FFD B178 313E (also on textsecure & redphone)
On 7/15/15, 11:57 AM, "NANOG on behalf of Matthew Kaufman" <nanog-bounces@nanog.org on behalf of matthew@matthew.at> 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
In message <55A682E6.1050607@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: marka@isc.org
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
On Jul 15, 2015, at 22:46 , Matthew Kaufman <matthew@matthew.at> 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
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?
On Thu 2015-Jul-16 12:32:19 +1000, Mark Andrews <marka@isc.org> 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 hugo@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
In message <20150716060336.GA4261@bamboo.slabnet.com>, Hugo Slabbert writes:
--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?
Once you have two methods of doing things, neither of which is manditory to implement, you can only get interoperate with everything if you implement both. The whole "we can't open a second socket" to do DHCP + SLACC because it is "too complicated" or "we don't want to run a second server" was nonsense. The direct consequence of doing that was Android not working on networks that supply other config over DHCP. We ship servers that speak multiple protocols on one multiple ports in the one binary. It isn't and never has been hard to do that.
-- Hugo
hugo@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
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Thu 2015-Jul-16 21:19:54 +1000, Mark Andrews <marka@isc.org> wrote:
In message <20150716060336.GA4261@bamboo.slabnet.com>, Hugo Slabbert writes:
--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?
Once you have two methods of doing things, neither of which is manditory to implement, you can only get interoperate with everything if you implement both. The whole "we can't open a second socket" to do DHCP + SLACC because it is "too complicated" or "we don't want to run a second server" was nonsense. The direct consequence of doing that was Android not working on networks that supply other config over DHCP.
We ship servers that speak multiple protocols on one multiple ports in the one binary. It isn't and never has been hard to do that.
Not disagreeing with you. The discussion was just exhaustively expounded in that thread over (by my count) 182 messages, with very little to show for it. We can take another run at flinging words on the topic and trying to get Google to implement a DHCPv6 client in Android, but I have my doubts about how effective that will be.
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
-- Hugo hugo@slabnet.com: email, xmpp/jabber PGP fingerprint (B178313E): CF18 15FA 9FE4 0CD1 2319 1D77 9AB1 0FFD B178 313E (also on textsecure & redphone)
Internet in a box. Wasn't that the Japanese thing with the Woody Woodpecker logo and the (translated) English text: "Touch Woody, the Internet pecker"? Didn't go over to well in English speaking parts as I recall ...
Internet in a box.
Wasn't that the Japanese thing with the Woody Woodpecker logo and the (translated) English text: "Touch Woody, the Internet pecker"?
Didn't go over to well in English speaking parts as I recall ...
But it eventually evolved into ChatRoulette. -- Dave Pooser Cat-Herder-in-Chief, Pooserville.com
On Jul 15, 2015, at 19:32 , Mark Andrews <marka@isc.org> wrote:
In message <55A682E6.1050607@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
On Wed, 15 Jul 2015 22:32:19 -0400, Mark Andrews <marka@isc.org> wrote:
You can blame the religious zealots that insisted that everything DHCP does has to also be done via RA's.
I blame the anti-DHCP crowd for a lot of things. RAs are just dumb. There's a reason IPv4 can do *everything* through DHCP -- hell, even boot menu lists are sent in dhcp pakcets.
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.
Just like no "IP stack" was fixable in the 80's. No. Just, No. There are millions upon millions of internet users I wouldn't trust to double click setup.exe.
None of which is the fault of the protocol.
Actually, it's 100% the fault of the protocol. IPv6-only networking has been a cluster-f*** from day one. And it still doesn't f'ing work today. Until there is *A* standard to implement, that stands still for more than an hour before something else "critical" gets bolted on to it, people are going to continue to ignore IPv6. Yes, my XP machines work fine with IPv6... on a network using SLAAC, where IPv4 (DHCPv4) is still enabled and providing the various bits necessary to do anything other than ping my gateway.
Ricky Beamwrote:
On Wed, 15 Jul 2015 22:32:19 -0400, Mark Andrews <marka@isc.org> wrote:
You can blame the religious zealots that insisted that everything DHCP does has to also be done via RA's.
I blame the anti-DHCP crowd for a lot of things. RAs are just dumb. There's a reason IPv4 can do *everything* through DHCP -- hell, even boot menu lists are sent in dhcp pakcets.
The reason is that DHC was the longest lived working group in IETF history. It took over 15 years of changes to get what you consider a working implementation. At the point the IPv6 RA was specified, it was very difficult for people to get addressing and routers consistently configured via dhcp, let alone everything else that was added.
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.
Just like no "IP stack" was fixable in the 80's. No. Just, No. There are
millions
upon millions of internet users I wouldn't trust to double click setup.exe.
None of which is the fault of the protocol.
Actually, it's 100% the fault of the protocol. IPv6-only networking has been a cluster-f*** from day one. And it still doesn't f'ing work today. Until there is *A* standard to implement, that stands still for more than an hour before something else "critical" gets bolted on to it, people are going to continue to ignore IPv6.
So if you want to wait for a stable specification, why did you ever implement IPv4? Here we are 35+ years later and there are still changes to the base IPv4 header in the works. http://tools.ietf.org/rfcmarkup?doc=draft-dreibholz-ipv4-flowlabel How could anyone ever implement a target that has continued to move for that long a period? With over 5,000 documents describing the continuous changes to IPv4, there is obviously "A standard to implement" in there somewhere. Clearly some people have figured out how to deploy IPv6, but if you want to wait, that is your choice.
Yes, my XP machines work fine with IPv6... on a network using SLAAC, where IPv4 (DHCPv4) is still enabled and providing the various bits necessary to
do
anything other than ping my gateway.
The XP implementation was never expected to last as long as it did, The delay in shipping the Vista/W7 stack resulted in quite a bit of functionality being late. The entire point of the XP implementation was to put a working API in the hands of app developers. It was never intended to be used in IPv6-only networks 15 years after its release. Tony
On 15 July 2015 at 02:02, Mike <mike-nanog@tiedyenetworks.com> 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
Did you deploy Mikrotik routers by any chance? -mel beckman
On Jul 15, 2015, at 3:29 AM, Baldur Norddahl <baldur.norddahl@gmail.com> wrote:
On 15 July 2015 at 02:02, Mike <mike-nanog@tiedyenetworks.com> 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
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 mikea@mikea.ath.cx Tired old sysadmin
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" <nanog-bounces@nanog.org on behalf of mike-nanog@tiedyenetworks.com> 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
On Jul 14, 2015, at 4:46 PM, Stephen Satchell <list@satchell.net> 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.
If a consumer internet connection works I wouldn't expect the typical user to have to know that IPv6 exists, let alone anything about it. If you need to manually see anything at that level then hasn't the ISP, OS vendor or app developer done something horribly wrong? IPv6 for dummies for app developers and small ISPs, OTOH ... Cheers, Steve
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.
These days, wouldn't that be a pre-loaded tablet or smartphone with internal cell card - generally delivered pre-configured, in a cardboard box? :-) -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra
In Japan, they had that on a CD in 1994, just after the law changed. Lines snaked across the floor at Interop in the huge new Makuhari Messe conference center in Chiba. -jsq
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.
These days, wouldn't that be a pre-loaded tablet or smartphone with internal cell card - generally delivered pre-configured, in a cardboard box? :-)
This stuff has been consumerized. If you walk into any vzw store you can for $99 and $60 a month no contract walk out with a mifi with v6. You don't even have to ask, or configure anything, pretty much as it should be, the consumer wants internet, Facebook email, and all the upper layer services that the find valuable enough to pay a service provider and buy hardware for. Running an ISP or IT department assumes a certain amount of familiarity with the craft, which means you should be buying the picees that meet your needs, rather than what other people think you need. Sent from my iPhone
On Jul 14, 2015, at 16:46, Stephen Satchell <list@satchell.net> 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)
On Tue, Jul 14, 2015 at 4:46 PM, Stephen Satchell <list@satchell.net> 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".
Ah, Spry Inc, where are you now? I still have the tee shirt and the totebag... https://en.wikipedia.org/wiki/Internet_in_a_Box http://images.search.yahoo.com/images/view;_ylt=AwrTcXcg6qVVBN4AYA42nIlQ;_ylu=X3oDMTIycGdrdTYyBHNlYwNzcgRzbGsDaW1nBG9pZAMyZTA0OTNhZjcyNzRlZTlhMjA5NjYzNWYzMDQxYWFmYQRncG9zAzQEaXQDYmluZw--?.origin=&back=http%3A%2F%2Fimages.search.yahoo.com%2Fyhs%2Fsearch%3Fp%3Dinternet%2Bin%2Ba%2Bbox%26type%3D__alt__ddc_linuxmint_com%26fr%3Dsfp%26fr2%3Dpiv-web%26hsimp%3Dyhs-linuxmint%26hspart%3Dddc%26tab%3Dorganic%26ri%3D4&w=270&h=252&imgurl=archive.cigarweekly.com%2Fimages%2Fint-in-a-box.jpg&rurl=http%3A%2F%2Farchive.cigarweekly.com%2Fmagazine%2Fcigarticles%2F02-04-2008%2Flife%2C-computers-and-the-partagas-serie-d-no.-4%3A-one-man-s-journey&size=14.2KB&name=Here+is+what+%3Cb%3EInternet+in+a+Box%3C%2Fb%3E+looked+like.&p=internet+in+a+box&oid=2e0493af7274ee9a2096635f3041aafa&fr2=piv-web&fr=sfp&tt=Here+is+what+%3Cb%3EInternet+in+a+Box%3C%2Fb%3E+looked+like.&b=0&ni=21&no=4&ts=&tab=organic&sigr=1402hm764&sigb=14ugkuu5g&sigi=11fniht2d&sigt=11iu4mkfg&sign=11iu4mkfg&fr=sfp&fr2=piv-web&hsimp=yhs-linuxmint&hspart=ddc&type=__alt__ddc_linuxmint_com I may even have my original box around, still unopened. ^_^; Ah, now you've got me all nostalgic.... Matt
participants (26)
-
Baldur Norddahl -
Brett Watson -
Chuck Anderson -
Dave Pooser -
Hugo Slabbert -
Joel Jaeggli -
John Kinsella -
John S. Quarterman -
Keith Medcalf -
Lee Howard -
Marco Davids -
Mark Andrews -
Matthew Kaufman -
Matthew Petach -
Mel Beckman -
Mike -
mikea -
Miles Fidelman -
Owen DeLong -
Peter Kristolaitis -
Ricky Beam -
Roland Perry -
Stephen Satchell -
Steve Atkins -
Tony Hain -
Tore Anderson