IPv4, IPv6, and a sudden change in attitude(apenwarr.ca)
apenwarr.ca
IPv4, IPv6, and a sudden change in attitude
https://apenwarr.ca/log/20200708
183 comments
There are widely used ways to deploy IPv6 networks compatible with the IPv4 internet.
NAT64/DNS64 (iOS): Your device only gets an IPv6 address, but when it queries an ipv4onlydomain.com, it receives an IPv6 address mapped to the domains IPv4 address. When it sends packets to it, they are translated by the ISP to IPv4. All their customers remain IPv6-only. This method requires apps to be able to handle IPv6 addresses, which Apple enforced.
XLAT464 (Android, Windows): your device gets an IPv6 address. The OS translates IPv4 packets to a special range of IPv6 before sending them out, because you’re only connected over IPv6. The ISP translates them to IPv4 to reach legacy services.
The benfit is: absolutely no NAT for IPv6 packets. Complete end-to-end connectivity.
192.168.0.1 shouldn’t be glorified. Good riddance. We have mDNS now, just have the user type router.local into their browser.
NAT64/DNS64 (iOS): Your device only gets an IPv6 address, but when it queries an ipv4onlydomain.com, it receives an IPv6 address mapped to the domains IPv4 address. When it sends packets to it, they are translated by the ISP to IPv4. All their customers remain IPv6-only. This method requires apps to be able to handle IPv6 addresses, which Apple enforced.
XLAT464 (Android, Windows): your device gets an IPv6 address. The OS translates IPv4 packets to a special range of IPv6 before sending them out, because you’re only connected over IPv6. The ISP translates them to IPv4 to reach legacy services.
The benfit is: absolutely no NAT for IPv6 packets. Complete end-to-end connectivity.
192.168.0.1 shouldn’t be glorified. Good riddance. We have mDNS now, just have the user type router.local into their browser.
You can also do the ipv4 to IPv6 translation on the server itself, then the server is can be purely IPv6 attached.
Fun trivia:
A few years ago I wrote a kernel module, that together with existing kernel mechanisms allowed almost all transition tech at a time, and ended up in a bunch of CPEs:
https://github.com/ayourtch/nat46/tree/master/nat46/modules
You can see the pull request activity... two pull requests in the past month... before that it was last time in 2017. So some things seem to be moving.
Fun trivia:
A few years ago I wrote a kernel module, that together with existing kernel mechanisms allowed almost all transition tech at a time, and ended up in a bunch of CPEs:
https://github.com/ayourtch/nat46/tree/master/nat46/modules
You can see the pull request activity... two pull requests in the past month... before that it was last time in 2017. So some things seem to be moving.
> The benfit is: absolutely no NAT for IPv6 packets. Complete end-to-end connectivity.
do the privacy extensions (which I've heard of, but don't get at even a basic level) allow a little privacy in this scenario?
do the privacy extensions (which I've heard of, but don't get at even a basic level) allow a little privacy in this scenario?
Privacy extensions means that every host on your network picks a random IP to make outbound connections from. They pick new random IPs periodically (by default usually after 24 hours), while keeping the old ones for a short period (by default usually 7 days) so that existing connections aren't broken. Rebooting or connecting to a new network will also remove the existing privacy addresses and generate new ones.
Remote servers will see the privacy address, but they won't know which machine the address belongs to. The addresses will also be abandoned after a maximum of a week, so you can't trawling through your old server logs to find active v6 addresses either.
They'll still be able to see what network you're coming from, but that's not something that NATing outbound connections from your network would help with anyway.
Remote servers will see the privacy address, but they won't know which machine the address belongs to. The addresses will also be abandoned after a maximum of a week, so you can't trawling through your old server logs to find active v6 addresses either.
They'll still be able to see what network you're coming from, but that's not something that NATing outbound connections from your network would help with anyway.
> If you plan to migrate your customers to IPv6 then you are a lunatic.
Well...
Comcast made IPv6 on-by-default to all residential customers some time ago (IIRC) and available (not sure if on-by-default) to all business customers. [1] Verizon requires all LTE devices to support v6 [2] and achieved >70% penetration in 2016 [3] (I'm too lazy to find a more recent statistic.) T-Mobile launched v6only in 2014 [4] and hit >90% in 2018. [5]
> Eventually, of course, the dam is going to break and IPv6 will become ubiquitous. ISPs will decide that buying blocks of IPv4 addresses costs more than providing new customers with IPv6 plus some kind of carrier-grade NAT for legacy IPv4 addresses. More website hosting companies will support IPv6 in response, and suddenly IPv4 will be so last-decade.
In short, that happened.
[1] https://business.comcast.com/help-and-support/internet/comca... [2] https://www.apnic.net/wp-content/uploads/2017/01/vzw_apnic_1... [3] https://archive.today/20160719154102/http://www.worldipv6lau... [4] https://www.internetsociety.org/resources/deploy360/2014/cas... [5] https://pc.nanog.org/static/published/meetings/NANOG73/1645/...
Well...
Comcast made IPv6 on-by-default to all residential customers some time ago (IIRC) and available (not sure if on-by-default) to all business customers. [1] Verizon requires all LTE devices to support v6 [2] and achieved >70% penetration in 2016 [3] (I'm too lazy to find a more recent statistic.) T-Mobile launched v6only in 2014 [4] and hit >90% in 2018. [5]
> Eventually, of course, the dam is going to break and IPv6 will become ubiquitous. ISPs will decide that buying blocks of IPv4 addresses costs more than providing new customers with IPv6 plus some kind of carrier-grade NAT for legacy IPv4 addresses. More website hosting companies will support IPv6 in response, and suddenly IPv4 will be so last-decade.
In short, that happened.
[1] https://business.comcast.com/help-and-support/internet/comca... [2] https://www.apnic.net/wp-content/uploads/2017/01/vzw_apnic_1... [3] https://archive.today/20160719154102/http://www.worldipv6lau... [4] https://www.internetsociety.org/resources/deploy360/2014/cas... [5] https://pc.nanog.org/static/published/meetings/NANOG73/1645/...
My big issue with Comcast IPv6 is the IP range is constantly changing. Makes it hard to statically assign servers.
I still have not figured out how to get an IPv6 lease from Comcast at my home; anyone who can point to a recent guide on doing so would be greatly appreciated!
Do you have one of their rentals, or your own hardware? It should be automatic on the former.
It's my own hardware, an Arris SB6121. Maybe that's the problem?
The comcast connection I have with my own cable modem uses DHCPv6 with a /56 prefix. Beyond that you'll have to search for instructions on how to set it up with whatever router you are using.
Maybe I haven't tried since Comcast turned on v6 for everyone, but I just set up /etc/network/interfaces as specified in https://wiki.debian.org/IPv6PrefixDelegation and it just worked this time!
> ISPs will decide that buying blocks of IPv4 addresses costs more than providing new customers with IPv6 plus some kind of carrier-grade NAT for legacy IPv4 addresses.
This implies an ISP can do math. Frontier acquired lots of IPv4 addresses w/ it's $10B purchase of Verizon assets(in 2015 & $7B in 2010 & 2B of AT&T).
Frontier has no plans to ever deploy IPv6.
This implies an ISP can do math. Frontier acquired lots of IPv4 addresses w/ it's $10B purchase of Verizon assets(in 2015 & $7B in 2010 & 2B of AT&T).
Frontier has no plans to ever deploy IPv6.
> If you plan to migrate your customers to IPv6 then you are a lunatic.
According to https://www.google.com/intl/en/ipv6/statistics.html#tab=per-..., IPv6 adoption in the US is above 42%. Was that all done by lunatics?
According to https://www.google.com/intl/en/ipv6/statistics.html#tab=per-..., IPv6 adoption in the US is above 42%. Was that all done by lunatics?
By migrate I think the OP meant take away their IPv4 address. IPv6 adoption may be at 42% but unless it is at 99.999% you will have a lot of issues when not allocating an IPv4 address.
It doesn't have to be that high. Tell a small business that in exchange for small percentage of their customers going elsewhere they can sell their IPv4 address for $ and some will take it.
Not necessarily. I have no v4 on my desktop and I'm not hitting a lot of issues. It only becomes an issue if you don't implement some form of backwards compatibility.
I occasionally find websites that are broken and don't load, but that only happens rarely and it's not exactly a problem that's exclusive to v6.
I occasionally find websites that are broken and don't load, but that only happens rarely and it's not exactly a problem that's exclusive to v6.
I would not be surprised if the breakdown of those users was near 100% for mobile users and less for broadband.
IoT should be the primary adopter of IPv6. those devices don't need to be able to access every server on the internet, and they only run into problems if they connect to a wifi that doesn't support IPv6
if you disagree, i'd appreciate if you could explain why...
if you disagree, i'd appreciate if you could explain why...
You're not wrong, but this:
> they only run into problems if they connect to a wifi that doesn't support IPv6
is like 99% of the problems IPv6 devices encounter.
> they only run into problems if they connect to a wifi that doesn't support IPv6
is like 99% of the problems IPv6 devices encounter.
thanks. i didn't realize it would be that bad.
at least it's a solveable problem, because it's in the customers sphere of influence, whereas getting all websites i am interested in onto IPv6 is not.
at least it's a solveable problem, because it's in the customers sphere of influence, whereas getting all websites i am interested in onto IPv6 is not.
Now I'm confused. Excuse me if I paraphrase your dialogue to illustrate my confusion:
em-bee: IPV6 IoT only run into problems if X
avianlyric: X is like 99% of the problems IPv6 devices encounter.
em-bee: thanks. i didn't realize it would be that bad.
What new information did avianlyric bring? Was that not a re-statement of what came before?
em-bee: IPV6 IoT only run into problems if X
avianlyric: X is like 99% of the problems IPv6 devices encounter.
em-bee: thanks. i didn't realize it would be that bad.
What new information did avianlyric bring? Was that not a re-statement of what came before?
the 99% :-)
only running into problems if X
implies that X is a small problem.
but 99% points out that X is a big problem.
only running into problems if X
implies that X is a small problem.
but 99% points out that X is a big problem.
The address space of IPv6 can certainly make things like sensor nets ubiquitous. 5G will certainly drive ipv6 more i think.
I'm familiar with at least one use case. The largest company that builds the NICs for smart meters has its own custom wireless network technology, but on top of that runs IPv6 so that it can communicate with millions of devices.
[deleted]
> Eventually, of course, the dam is going to break and IPv6 will become ubiquitous.
By all accounts, many of us in the networking space predicted that this would absolutely, positively, without a doubt occur by 2010.
By all accounts, many of us in the networking space predicted that this would absolutely, positively, without a doubt occur by 2010.
Yes, in hindsight a lot of people were hopelessly optimistic about the timeline. That doesn't mean it will never come to pass. The increasingly dire economics of IPv4 will force a disruptive change at some point, and IPv6 remains the heir apparent.
> the vital importance of 192.168.0.1, and are going to be puzzled when this doesn't work any more
Just keep shipping routers that support both IPv4 and IPv6 and you won't have a problem. If IPv6 gets popular enough, you won't even need NAT on that interface--it will just be an admin network. This is only an issue when major OSes start dropping IPv4.
Just keep shipping routers that support both IPv4 and IPv6 and you won't have a problem. If IPv6 gets popular enough, you won't even need NAT on that interface--it will just be an admin network. This is only an issue when major OSes start dropping IPv4.
Yeah, we live in a culture where thinking about anything but next quarter revenue is discouraged in companies. In such a culture, anything but a status quo is not going to happen easily.
See also fossil fuels.
See also fossil fuels.
No, most companies actually do think in long term. Problem is, most people/companies are wrong about most things they think long term on.
The problem with ip6, if there was only just 1, is that they cared more about the engineering than what customers wanted/needed. their attitude was: if they dont use it, well they are just stupid, everyone else will use it and have to switch anyways.
The problem with ip6, if there was only just 1, is that they cared more about the engineering than what customers wanted/needed. their attitude was: if they dont use it, well they are just stupid, everyone else will use it and have to switch anyways.
That's how having shareholders works unfortunately, as that's their main interest.
The article was worth it just for this gem:
'If we were feeling snarky, we could perhaps describe IPv6 as "the String Theory of networking": a decades-long boondoggle that attracts True Believers, gets you flamed intensely if you question the doctrine, and which is notable mainly for how much progress it has held back.'
'If we were feeling snarky, we could perhaps describe IPv6 as "the String Theory of networking": a decades-long boondoggle that attracts True Believers, gets you flamed intensely if you question the doctrine, and which is notable mainly for how much progress it has held back.'
This trend has been bothering me a lot lately.
In standards bodies you will have a 'True Believer' about a particular topic. They will push it for years and years, and eventually get their way. The idea isn't bad, and would be great if included in the spec from day one. Unfortunately adding it to what we have today causes massive breakage/incompatibility.
Maybe I am just being resistant to good change. It just is frustrating because in most cases the 'True Believer' isn't going to go worry about the real-world impact of the change.
This phenomena seems to be hurting a lot of programming languages as well. So much harder to say no, and idealistic people are always going to find a way :)
In standards bodies you will have a 'True Believer' about a particular topic. They will push it for years and years, and eventually get their way. The idea isn't bad, and would be great if included in the spec from day one. Unfortunately adding it to what we have today causes massive breakage/incompatibility.
Maybe I am just being resistant to good change. It just is frustrating because in most cases the 'True Believer' isn't going to go worry about the real-world impact of the change.
This phenomena seems to be hurting a lot of programming languages as well. So much harder to say no, and idealistic people are always going to find a way :)
I like to see the other side (that of the true believer) as well. If all (or most) can agree on that it is the right thing to do and the current way of doing it is wrong, why oppose the change for 20 years saying it will cause breakage? If the change had been made at the beginning, any breakage would have been dealt with long ago. (I’m specifically not talking about change for the sake of making changes.)
I think, like python 2->3, the chaos and confusion of trying to pull off a "clean slate reboot" is very rarely successful or worth it.
There wasn't really any way to avoid what v6 did though. v4 can't handle addresses that are bigger than 32 bits, and that's the end of it.
v6 also has pretty much every backwards compatibility mechanism that can work with v4. It's hard to see how it could've done any better, and nobody I've ever talked to has managed to come up with anything that a) would work and b) isn't already a thing v6 does or can do.
I've seen plenty of proposals that don't satisfy those two conditions (like, "just add an octet" or "just make the numbers go up to 999")...
v6 also has pretty much every backwards compatibility mechanism that can work with v4. It's hard to see how it could've done any better, and nobody I've ever talked to has managed to come up with anything that a) would work and b) isn't already a thing v6 does or can do.
I've seen plenty of proposals that don't satisfy those two conditions (like, "just add an octet" or "just make the numbers go up to 999")...
Back in late 90's back when I was working in OSI networking I realised that IPv6 was a bad standard.
IPv6 is great if you control lots of components that need to talk to one another. Life is much simpler when you can trivially have thousands of globally routable addresses. It provides great value without having to be 100% deployed and for that, I am grateful.
I liken it to a commercial kitchen. Large numbers of identical steel pans, everything measured in grams, Cambros, walk-in refrigeration. Ideas and tech that are unlikely to catch on in the home kitchen, but when you operate at a larger scale, invaluable.
I liken it to a commercial kitchen. Large numbers of identical steel pans, everything measured in grams, Cambros, walk-in refrigeration. Ideas and tech that are unlikely to catch on in the home kitchen, but when you operate at a larger scale, invaluable.
> ...everything measured in grams...
> Ideas and tech that are unlikely to catch on in the home kitchen
Given the posting time I’d guess you were likely not US based so I found this surprising.
Even if that is so, then I continue to be surprised every time I rediscover the fact that the US hasn’t moved towards metrification.
Edit: rereading this the wording is harsher than intended. So to add: Either way the wording tickled me for some reason. Whether intentional or not, thank you (genuinely) for the smile this morning.
> Ideas and tech that are unlikely to catch on in the home kitchen
Given the posting time I’d guess you were likely not US based so I found this surprising.
Even if that is so, then I continue to be surprised every time I rediscover the fact that the US hasn’t moved towards metrification.
Edit: rereading this the wording is harsher than intended. So to add: Either way the wording tickled me for some reason. Whether intentional or not, thank you (genuinely) for the smile this morning.
Aren't all imperial units standardized on metric values nowadays? So technically Americans are using metric, they just use a different notation?
I mean in theory a foot is defined as xyz centimeters but i don't think that matters for any practical purpose.
1 foot is exactly 30.48 cm, thanks to Carl Edvard Johansson.
Yes, I think you're right.
Product specs are often in inches like 3.9 inches (which is ~ 100mm)
Although sometimes it's the opposite - computer pins are commonly 2.54 mm apart (0.1 inches)
Product specs are often in inches like 3.9 inches (which is ~ 100mm)
Although sometimes it's the opposite - computer pins are commonly 2.54 mm apart (0.1 inches)
> the US hasn’t moved towards metrification.
I couldn't care less about which system is used, i just want there to be only one. I'm not a fan of owning two sets of tools, and I'm not a fan of working on a car and coming across something I need my second tool set for because people can't figure out what system to use.
I couldn't care less about which system is used, i just want there to be only one. I'm not a fan of owning two sets of tools, and I'm not a fan of working on a car and coming across something I need my second tool set for because people can't figure out what system to use.
Metric units are a mouthful. Centiliter <-> ounce. Kilometer <-> mile. Centimeter <-> inch.
I think having easy-to-pronounce names for the metric units would help. Kliks are much better than kilometers.
I think having easy-to-pronounce names for the metric units would help. Kliks are much better than kilometers.
I've never heard anyone say Centiliter. It's milliliters or liters. You find cl or dl on bottles but I've never encountered it in spoken language.
Which is nice because having fewer units make it easier to compare, even if converting in metric system is easy.
Which is nice because having fewer units make it easier to compare, even if converting in metric system is easy.
In some countries like Slovakia, they say deci for decilitre.
This is rather common in France. We use centiliters quite often when speaking.
Shot glasses are 2cl around here.
I believe they're 2cl in all of Europe, never heard anyone use it outside of refering to it.
In my experience kilometre is pronounced “k”, centimetre is pronounced “ten mil”, and centilitre is “hundred mil”.
In more worldly/sciencey/engineering parts of the US, I tried shortening metric like that and then I ran into this fucking abomination of a measurement, which is also abbreviated to "mil" in the US:
https://en.wikipedia.org/wiki/Thousandth_of_an_inch
I'm 100% American and I despise the imperial system so much. Maybe our plummeting stature in world politics and power will force us to convert. Not exactly the way I wanted it to go but a silver lining is still a silver lining.
https://en.wikipedia.org/wiki/Thousandth_of_an_inch
I'm 100% American and I despise the imperial system so much. Maybe our plummeting stature in world politics and power will force us to convert. Not exactly the way I wanted it to go but a silver lining is still a silver lining.
Yup, I'm an Aussie, born when inches and miles ruled and I live ninety two "k" from my office and I drink beer from three seventy "mil" stubbies (glass bottles). Not hard at all
Completely agreed. And being in the UK, and of a certain age, I still use inches, miles, pounds and stone but I think that’s due to familiarity during childhood. I don’t use Fahrenheit like my parents did though when describing the weather. Oddly, I also tend to use metres instead of feet/miles for distances that aren’t drivable, or human-height related.
It’s also interesting that in speech I often hear (and find myself), contracting to the SI prefix itself when the unit can be derived from context.
For example: “It’s 25 millis” [long]
It’s also interesting that in speech I often hear (and find myself), contracting to the SI prefix itself when the unit can be derived from context.
For example: “It’s 25 millis” [long]
When I go to buy wood I buy 2" by 4" in 4.8 metre lengths. Was buying screws the other day and I was asking for 3 and a half inch and he was saying that's 90 or something that. I had only written everything in imperial because another guy there uses that. We seem to be stuck in a half and half place.
Hah yes when I buy timber I ask for a four by two inch quote that is labeled as 50mm by 100mm planed all round and measures 45mm by 90mm. The length is usually correct.
Fasteners are categorized using a higher-level system because there are multiple, independent dimensions--thread pitch, thread width, shank width, unthread shank length, threaded shank length, head type, tip type, etc--at play, and the relationships are relatively arbitrary (AFAIU--maybe there's some sophisticated, deliberate geometry at play I'm not aware of). There's no such thing as a 3 1/2" screw--there are many different types of screws that are 3 1/2" long, and they each have a particular label. So you can't really directly compare the qualities of metric or American standard fastener sizing systems.
> AFAIU--maybe there's some sophisticated, deliberate geometry at play I'm not aware of
Some earlier fastener standards were somewhat arbitrary, but mechanical engineers have calculated "optimal" values for these parameters, and e.g. the ISO metric screw thread parameters are based on such calculations.
Some earlier fastener standards were somewhat arbitrary, but mechanical engineers have calculated "optimal" values for these parameters, and e.g. the ISO metric screw thread parameters are based on such calculations.
I must put you on to my carpenter friend then, seems he's wrong. Not in America btw.
If you do a particular type of work, such as building decks, then 3 1/2" will mean a very specific type of screw. But if you go into a good hardware store (Ace, a smaller, neighborhood chain, is often better than big-box Home Depot or Lowes in terms of variety) and tell the clerk you want a 3 1/2" long screw, things can get frustrating rather quickly unless you can provide some context. When you're working with wood, it's easier to fudge things, but when you're working with machine screws, details like pitch and shank profile often cannot be ignored.
Yeah, I live in Europe. When I go to a restaurant in North America, they have beer in 335,341,474 ml cans, draught beer in pints, 12oz, 16oz etc. Very confusing.
If I ask the waiters, they also have have no cloue about what gets me the me most beer for my money. (I did check it all with units(1) now, but will probably have forgotten it next time I need it)
The argument for Fahrenheit over Celsius is actually relatively strong: http://lethalletham.com/posts/fahrenheit.html
I also have a soft spot for fractional units and different bases (e.g. 12, 60, etc) over decimal, but I can admit the practical case is comparatively weak and inconsequential.
I also have a soft spot for fractional units and different bases (e.g. 12, 60, etc) over decimal, but I can admit the practical case is comparatively weak and inconsequential.
The author states that the best system is the one you're used to, in his conclusion.
Earlier he says that he doesn't like the other system because it uses negative numbers for temperatures that aren't that cold and that also it's good to be able to avoid using negative numbers. Those seem like very subjective reasons to me.
> aren't that cold
Something very relative to where the author lived and developed the preference. This changes from person to person, and region to region. "Not that cold" could be -25C in Siberia (well... not with the recent heatwave) or +25C in Quatar.
It makes sense for the whole world to use a common measuring system (and not just for temperature), perhaps even one where 1 degree is equal to 1 degree Kelvin since this would fit better with the science crowd. But whatever point of reference is chosen it will definitely fall short of expectation in different parts of the world. The freezing point of water as the 0 is as good as any. Body temperature (~37C) could also be a universal 0 with plenty of advantages and disadvantages that I never considered.
Something very relative to where the author lived and developed the preference. This changes from person to person, and region to region. "Not that cold" could be -25C in Siberia (well... not with the recent heatwave) or +25C in Quatar.
It makes sense for the whole world to use a common measuring system (and not just for temperature), perhaps even one where 1 degree is equal to 1 degree Kelvin since this would fit better with the science crowd. But whatever point of reference is chosen it will definitely fall short of expectation in different parts of the world. The freezing point of water as the 0 is as good as any. Body temperature (~37C) could also be a universal 0 with plenty of advantages and disadvantages that I never considered.
37C as the universal would put these parts permanently in negative temperatures. Freezing point of water is a good one especially when you think of the effect ice has on so many things
True, one of the disadvantages I was thinking of is truly high magnitude lows and low highs. The scale would reasonably go from -100 to +15. It would be a universally familiar 0 point. I do agree that water freezing is a very practical point or reference if there's ever been one.
I don't think body temperature is very familiar in any other context. Nothing feels special about that temperature when I walk outside; it's just somewhere in the middle of "too hot".
Room temperature has benefits as a basis point, water freezing does too, everything else is much more arbitrary.
Room temperature has benefits as a basis point, water freezing does too, everything else is much more arbitrary.
> Nothing feels special about that temperature when I walk outside; it's just somewhere in the middle of "too hot".
It's probably worse then that since "real feel" is strongly influenced by humidity or wind. What I meant is that body temperature is more or less universally applicable to all humans, something relatable but with no benefit over the freezing point of water.
Room temperature isn't that much better. It's a bit more useful than body temperature but far less precise, could be anything between 18 and 24 C depending on who you ask.
It's probably worse then that since "real feel" is strongly influenced by humidity or wind. What I meant is that body temperature is more or less universally applicable to all humans, something relatable but with no benefit over the freezing point of water.
Room temperature isn't that much better. It's a bit more useful than body temperature but far less precise, could be anything between 18 and 24 C depending on who you ask.
very subjective indeed. i find that knowing whether water will feeeze or snow will melt without having to memorize a number for that rather useful.
well, actually memorizing a number is probably not a problem. i realized that the real advantage is to be able to look whether the number is positive or negative without taking a close look at the actual value.
I don't agree that is quite strong. He starts with a number of purely subjective requirements that make Fahrenheit look good and ignores all other use cases. Such as centering the zero around the freezing point of water is quite useful, since it makes it obvious when one has to deal with frozen water in various variants.
Further, the melting point of water can readily be reproduced with astonishing precision, which is often sufficient for the calibration of temperature sensors.
People cite this as a reason so often, but is it really so hard to remember the number 32? The boiling point of water is something I think more people tend to forget, but no one ever cites that as a reason to use SI... It seems like the crux of the argument is just that the US drools and Europe rules and haha aren't Americans so stupid?
Fahrenheit is honestly more useful, because 0 is uncomfortably cold and 100 is uncomfortably hot. Trying to figure out what temperature I need a jacket or AC for in Centigrade requires a lot more memorization -- and it's something I deal with far more on a day to day basis...
Fahrenheit is honestly more useful, because 0 is uncomfortably cold and 100 is uncomfortably hot. Trying to figure out what temperature I need a jacket or AC for in Centigrade requires a lot more memorization -- and it's something I deal with far more on a day to day basis...
The argument for using SI is simply that you are a) using the same units as everyone else b) using a set of units that connect neatly together so one can actually do meaningful calculations with them. And °C is not part of SI either, but is only a constant offset away from Kelvin - which is.
And why is 0 is uncomfortably cold and 100 is uncomfortably hot more useful? Same thing as in the article.. avoiding negative numbers - why?
And why is 0 is uncomfortably cold and 100 is uncomfortably hot more useful? Same thing as in the article.. avoiding negative numbers - why?
> IPv6 is great if you control lots of components that need to talk to one another.
And that's the fallacy. Those things don't need to talk to each other (my toaster doesn't need to talk to your fridge), they do talk to a well defined peer (gateway, server, whatever). There might be someday more than a few billion networked things out there, but there won't be even remotely a billion gateways on the Internet in the foreseeable future.
Enterprises generally don't like outside elements access elements within their network at will. That's not going to change, it will always be through some form of gateway.
And that's the fallacy. Those things don't need to talk to each other (my toaster doesn't need to talk to your fridge), they do talk to a well defined peer (gateway, server, whatever). There might be someday more than a few billion networked things out there, but there won't be even remotely a billion gateways on the Internet in the foreseeable future.
Enterprises generally don't like outside elements access elements within their network at will. That's not going to change, it will always be through some form of gateway.
There are still benefits to using unique address space on all networks though. The fact that my fridge doesn't need to talk to your toaster isn't a reason for us to not do v6.
If you've never had to deal with clashing RFC1918 blocks when doing a VPN or network merger, consider yourself lucky. It's a giant headache that can never be properly fixed, yet v6 completely avoids it.
If you've never had to deal with clashing RFC1918 blocks when doing a VPN or network merger, consider yourself lucky. It's a giant headache that can never be properly fixed, yet v6 completely avoids it.
I've only witnessed it on the sidelines (while the internationally distributed company I worked for was acquired).
> It's a giant headache that can never be properly fixed, yet v6 completely avoids it.
It's a headache, sure. But that it can't be fixed is hyperbole. All it takes is reassignment of IP addresses, there are plenty after all. The headache comes only from IP addresses stored in places they don't belong. If they were only stored in the DHCP and DNS servers, a script could fix this in no time. Part of the problem I witnessed was, that people are hesitant to use DHCP for static IP addresses (servers) and some devices (switches) are incapable of using DHCP.
I also observed (much earlier) misguided sysadmins using a scheme encoding location of a device in its name. That of course let to horrible long, unpronounceable names and people remembering and using rather its IP address (that danger of course is greatly reduced with IPv6 ;-}
> It's a giant headache that can never be properly fixed, yet v6 completely avoids it.
It's a headache, sure. But that it can't be fixed is hyperbole. All it takes is reassignment of IP addresses, there are plenty after all. The headache comes only from IP addresses stored in places they don't belong. If they were only stored in the DHCP and DNS servers, a script could fix this in no time. Part of the problem I witnessed was, that people are hesitant to use DHCP for static IP addresses (servers) and some devices (switches) are incapable of using DHCP.
I also observed (much earlier) misguided sysadmins using a scheme encoding location of a device in its name. That of course let to horrible long, unpronounceable names and people remembering and using rather its IP address (that danger of course is greatly reduced with IPv6 ;-}
You haven't seen the full depths of it then.
I originally wrote "a giant headache that never goes away", but changed it because it is possible to renumber the networks. But... that doesn't properly fix the problem. You'll hit the exact same issue the next time you go through a merger.
Worse, RFC1918 isn't actually that big. There are plenty of companies out there that have either exhausted it or have to be very very careful with their use of it to avoid running out. At some point you run out of space to renumber into. You're also going to have issues with e.g. VPNs to people's home networks, where renumbering isn't viable.
I originally wrote "a giant headache that never goes away", but changed it because it is possible to renumber the networks. But... that doesn't properly fix the problem. You'll hit the exact same issue the next time you go through a merger.
Worse, RFC1918 isn't actually that big. There are plenty of companies out there that have either exhausted it or have to be very very careful with their use of it to avoid running out. At some point you run out of space to renumber into. You're also going to have issues with e.g. VPNs to people's home networks, where renumbering isn't viable.
This motivated me to bite the bullet and jump through the hoops to set up an IPv6 address for my personal server. I got all the way to the end and then just when everything looked like it was working, I tried to load the page and... nothing. Turns out my home network doesn't currently have an IPv6 address. Comcast in the SFBA seems to alternate giving out IPv6 addresses and then taking them away again every few months or so.
Works on my phone, though, so ¯\_(ツ)_/¯...
Works on my phone, though, so ¯\_(ツ)_/¯...
Hurricane Electric was giving out free tunnels for a while, they might still be.
They still do that; I have one set up on my router.
The main problem with it is that the tunnel server is hosted in Sweden, and while sometimes it's actually lower latency than my IPv4 connection (due to better routing, I guess), every geolocating website (eg. YouTube) thinks I'm Swedish :/
The main problem with it is that the tunnel server is hosted in Sweden, and while sometimes it's actually lower latency than my IPv4 connection (due to better routing, I guess), every geolocating website (eg. YouTube) thinks I'm Swedish :/
Yep I run into that too.
Also I have to block IPv6 for Netflix and Yahoo because they block HE IPv6 addresses.
Also I have to block IPv6 for Netflix and Yahoo because they block HE IPv6 addresses.
Look into setting up a ULA IPv6 network
My ISP doesn’t support IPv6 either. I get 0/10 on WiFi vs. 10/10 on mobile using Test Your IPv6. [1]
[1]: https://test-ipv6.com/
I’ve considered emailing to ask them to support it but haven’t come up with a persuasive reason for why they should.
[1]: https://test-ipv6.com/
I’ve considered emailing to ask them to support it but haven’t come up with a persuasive reason for why they should.
> but haven’t come up with a persuasive reason for why they should.
I don't know about you, but whenever I see an ISP, hosting provider, or website that supports IPv6 I think: These guys know what they are doing, they care about quality, and they actually plan for the future.
I'd much rather do business with someone that supports IPv6 because of the above impression.
If I was running my own business that provided network related products or services I'd make IPv6 support required because I don't want to seem like I'm incompetent/lazy/ignorant.
So in short the persuasive reason is that it would improve their reputation. Technical people notice these things and base their recommendations on these sorts of impressions.
I don't know about you, but whenever I see an ISP, hosting provider, or website that supports IPv6 I think: These guys know what they are doing, they care about quality, and they actually plan for the future.
I'd much rather do business with someone that supports IPv6 because of the above impression.
If I was running my own business that provided network related products or services I'd make IPv6 support required because I don't want to seem like I'm incompetent/lazy/ignorant.
So in short the persuasive reason is that it would improve their reputation. Technical people notice these things and base their recommendations on these sorts of impressions.
This was one factor when I chose my current ISP, they have provided IPv6 for a long time.
Find out what your ASN is (e.g. https://www.ultratools.com/tools/asnInfo) and then look it up on peering dB:
https://www.peeringdb.com/
It'll give you an idea if your ISP is advertising IPv6 routing on their network if they have some prefixes. So whether it's something they're working on or not.
https://www.peeringdb.com/
It'll give you an idea if your ISP is advertising IPv6 routing on their network if they have some prefixes. So whether it's something they're working on or not.
Thanks! Didn’t know I could look this up. Looks like my ISP has no IPv6 prefixes so far.
I have gigabit fiber through AT&T. So do my parents 30 miles away.
I get a 0/10 from the test-ipv6.com site
I logged into my parents network and they get a 10/10
As I said we live 30 miles away and we both got fiber 2 years ago.
I get a 0/10 from the test-ipv6.com site
I logged into my parents network and they get a 10/10
As I said we live 30 miles away and we both got fiber 2 years ago.
Still some distance to go, but Google see 30% of traffic from IPv6 now. It’s slowly getting there.
https://www.google.com/intl/en/ipv6/statistics.html
Also, with most cloud hosting (AWS et. al.) it’s fairly trivial to enable dual stack support.
https://www.google.com/intl/en/ipv6/statistics.html
Also, with most cloud hosting (AWS et. al.) it’s fairly trivial to enable dual stack support.
> Also, with most cloud hosting (AWS et. al.) it’s fairly trivial to enable dual stack support.
I say AWS IPv6 support is pretty atrocious. You still can not set up pure IPv6 VPC, even for internal use, afaik most AWS services are still accessible only through IPv4, IPv6 VPC has lots of weird limitations, etc etc. Somewhat sad, considering that one would think AWS would be one to benefit from v6
I say AWS IPv6 support is pretty atrocious. You still can not set up pure IPv6 VPC, even for internal use, afaik most AWS services are still accessible only through IPv4, IPv6 VPC has lots of weird limitations, etc etc. Somewhat sad, considering that one would think AWS would be one to benefit from v6
Agree, it's sad and strange that they can't provide that.
Still, hosting an IPv6 service on AWS is fairly simple (at least in my experience).
Still, hosting an IPv6 service on AWS is fairly simple (at least in my experience).
Google Compute Engine still does not support IPv6 for internal networking, only for external-facing load balancers, despite having made vague noises about it being "in progress" for the better part of a decade.
Are there any specific features of IPv6 you need for inner-cloud connectivity?
If you are spinning up enough resources to exhaust even a /16 of IPv6, you can probably use your monthly bill as leverage to force the issue.
If you are spinning up enough resources to exhaust even a /16 of IPv6, you can probably use your monthly bill as leverage to force the issue.
Interestingly, you can clearly see the effect of the pandemic if you zoom into this year. The swing between access from IPv4-leaning business networks during the week to more IPv6-leaning home/mobile networks on the weekends has greatly reduced.
What percentage of that is from cellular networks?
This article demonstrates yet another way that Postel's Law is a terrible design principle.
The amount of damage adherence to Postel's Law has caused can never be exaggerated. It has made securing TLS extremely difficult. It makes every kind of migration or evolution difficult, and interferes with securing anything.
The way to enforce The Anti-Postel's Law is with tests that include requests and responses to be rejected, and fuzzers that explore the whole boundary of well-formed interaction. Such a test will never detect every improper toleration, but it will make equipment and programs that don't conform hardly ever work, until they are fixed.
People used to like compilers that were lax about syntax requirements and provided lots of extensions. GNU compilers obliged, for a while, and then stopped. Now, even users of Microsoft compilers have demanded Standard conformance, and have nearly got it. A compiler that won't report errors is a way to generate lock-in. That was fine with Microsoft until they understood that it was locking them in, too.
The amount of damage adherence to Postel's Law has caused can never be exaggerated. It has made securing TLS extremely difficult. It makes every kind of migration or evolution difficult, and interferes with securing anything.
The way to enforce The Anti-Postel's Law is with tests that include requests and responses to be rejected, and fuzzers that explore the whole boundary of well-formed interaction. Such a test will never detect every improper toleration, but it will make equipment and programs that don't conform hardly ever work, until they are fixed.
People used to like compilers that were lax about syntax requirements and provided lots of extensions. GNU compilers obliged, for a while, and then stopped. Now, even users of Microsoft compilers have demanded Standard conformance, and have nearly got it. A compiler that won't report errors is a way to generate lock-in. That was fine with Microsoft until they understood that it was locking them in, too.
IPv4 continues to exist because consumers are subject to ISP monopolies.
"Symmetric bandwidth" or "Running my own server" are not criteria that can be used to choose an ISP because there is NO ISP that offers either one in most of the country (US).
Since nobody can run their own servers, there is no pull for a larger chunk of addresses that would drive IPv6 adoption.
"Symmetric bandwidth" or "Running my own server" are not criteria that can be used to choose an ISP because there is NO ISP that offers either one in most of the country (US).
Since nobody can run their own servers, there is no pull for a larger chunk of addresses that would drive IPv6 adoption.
Then relatively easy solution is to not give ISPs licensees to operate if they don't provide IPv6. Sounds more like an administrative problem for the government than a technology issue. Same applies to many other problems caused by monopolies. That's why there is anti-trust, or at least should be.
The ISPs only have a monopoly because the government literally makes it illegal to start a competing ISP in many areas. Even local governments were forbidden from competing with Comcast et al. in some cities.
> The ISPs only have a monopoly because
They have a lot of money.
They can out lobby you. They can undercut your pricing. And they cut "selectively upgrade" areas that would be profitable to come into.
Google couldn't cut through them. Mainly because as soon as Google threatened to come somewhere *WHOA MAGIC! POOF!" and the ISPs suddenly had orders of magnitude more bandwidth for half the price. Funny that.
They have a lot of money.
They can out lobby you. They can undercut your pricing. And they cut "selectively upgrade" areas that would be profitable to come into.
Google couldn't cut through them. Mainly because as soon as Google threatened to come somewhere *WHOA MAGIC! POOF!" and the ISPs suddenly had orders of magnitude more bandwidth for half the price. Funny that.
That may be how they gained their monopoly, but they keep their monopoly because overbuilding an additional network is very expensive, very tedious (need pole access), and very hard to sell (it's going to be hard to convince most people to join because the internet is better, people think it's a commodity). And, incumbents can drop prices to keep you out, while keeping them high elsewhere.
So it's something government can fix. The problem is that anti-trust became almost toothless due to corruption and monopolies buying policy.
Not offering symmetric bandwidth has technical reasons. You only have a limited amount of bandwidth with most technologies and the vast majority of consumers is much better off having higher download than upload speeds.
I'm actually glad that ISPs default to only giving one IP address per household. Not having most devices directly reachable from the internet is an extra layer of security. It should never be the only one but can be an extra step to make it harder for atttackers to introduce malware.
I'm actually glad that ISPs default to only giving one IP address per household. Not having most devices directly reachable from the internet is an extra layer of security. It should never be the only one but can be an extra step to make it harder for atttackers to introduce malware.
No technical reason today, except for ISPs not upgrading to modern technology (fiber optics) because of being short term profit cheapskates.
This is not true. With fiber, if you want to go full-duplex, you need to specify which frequencies you want to use per direction. Because 99.9% of users use much, much more downlink thank uplink, it does not make sense to reserve an equal amount of bandwidth for up and downlink, because that would reduce the uplink bandwidth per fibre. Symmetric bandwidth is wasteful for everyone but the content providers (who might even want asymmetric bandwidth but with more up than downlink).
I think you are thinking of coax (cable) and not FTTH. Fiber has a much wider frequency range and one tends to think in wavelength terms and not frequency.
And rarely is more than two wavelengths used for connecting customers (leaving most capacity of the fiber unused).
With FTTH there are two common deployment strategies: dedicated fiber per customer (then there is no reason at all why it wouldn't be symmetric) or (G)PON. With GPON the issue is that multiple customers share the downlink and uplink. And while it's easy to make the downstream burstable (meaning you can use more than 1Gbit/N - with N being the number of customers sharing the upstream GPON port), since only the ISP transmits in that direction for the upstream each customer gets assigned a timeslot to transmit (since GPON only uses a single wavelength for transmit and another one for receive). This means that even if the connection is symmetric at the ISP end (1G down and 1G up) one customer only gets 1G/N uplink bandwidth while they might briefly be able to completely saturate the downstream.
With FTTH there are two common deployment strategies: dedicated fiber per customer (then there is no reason at all why it wouldn't be symmetric) or (G)PON. With GPON the issue is that multiple customers share the downlink and uplink. And while it's easy to make the downstream burstable (meaning you can use more than 1Gbit/N - with N being the number of customers sharing the upstream GPON port), since only the ISP transmits in that direction for the upstream each customer gets assigned a timeslot to transmit (since GPON only uses a single wavelength for transmit and another one for receive). This means that even if the connection is symmetric at the ISP end (1G down and 1G up) one customer only gets 1G/N uplink bandwidth while they might briefly be able to completely saturate the downstream.
NG-PON2 improves on that by a huge margin: https://en.wikipedia.org/wiki/NG-PON2
There is no reason, except if you don't invest to have enough bandwidth for your users, which you shouldn't have a problem with, given the available technology. So again, it's not a technical issue. No need to be a cheapskate and excuse it with "wastefulness". Available bandwidth is growing faster than what you can use.
Yes, there is also no reason why I don’t have a personal road built from my house to my workplace reserved solely for me, it’s only a matter of investment. Almost nobody needs that investment, and if you’re going to lay more fibre, you’re better off providing even more downlink capacity.
Available bandwidth still grows faster than what you can use. So there is no reason not to provide symmetrical bandwidth. And price of that bandwidth is also only going down.
Many fiber to the home deployments are running shared medium (PON/GPON) which has physical limitations on upstream bandwidth because of TDMA and the optical properties. Typical GPON data rates are 2.4 gbps down / 1.2 gbps up, which is at least better than common ratios on DSL and DOCSIS.
You could run a separate strand to each house, or use fancier optics for DWDM, but both of those add significant expense.
You could run a separate strand to each house, or use fancier optics for DWDM, but both of those add significant expense.
That's why there is NG-PON2 in the works. And it's only going to increase further.
Your broadband argument does not work in 2020. The technology exists for symmetric.
NAT is not security.
Here's an article from F5:
https://www.f5.com/services/resources/white-papers/the-myth-...
And why would the devices be reachable over the internet?
Your router should firewall by default its LAN side subnets.
NAT is not security.
Here's an article from F5:
https://www.f5.com/services/resources/white-papers/the-myth-...
And why would the devices be reachable over the internet?
Your router should firewall by default its LAN side subnets.
NAT isn't "security", but it does provide some nice privacy benefits (so IPv6 should absolutely be combined with carrier grade NAT).
Carrier grade NAT does not give the user choice of what they want to do with their network.
If you want to employ NAT on your network, that should be your choice, not your ISP's.
If you want to employ NAT on your network, that should be your choice, not your ISP's.
I don't know what "the choice of what they want to do with their network" means. Is there something that you are able to do with a dynamic IP address that you are somehow unable to do behind NAT+PCP? (I mostly hear people complain about stuff that makes no sense, like "I can't do peer to peer connections", when the core problem there was already 100% solved by PCP.)
Instead of NAT there exist a "best practices" firewall setup that mimics what people expect from NAT, available in various home routers in the last 5 years.
The privacy features of NAT are due to the NAT part (mixing your traffic together with all the other traffic so you look like a single entity rather than multiple), not a firewall (which is merely a side effect of a NAT and has nothing to do with privacy).
The vast majority of consumers don't know or care about IPv6.
There seems to be more competition here in France than in the US but while I've previously used ISPs with IPv6 support my current one does not. Even as someone who prefers to have IPv6 it's not something I considered when signing up and I probably wouldn't pay much extra for it, as a consumer.
Symmetric bandwidth and connections for anything more than a personal server are available here but only on business plans. Those are easily more than 10x consumer prices so I can't imagine going for them unless you need the SLA's.
There seems to be more competition here in France than in the US but while I've previously used ISPs with IPv6 support my current one does not. Even as someone who prefers to have IPv6 it's not something I considered when signing up and I probably wouldn't pay much extra for it, as a consumer.
Symmetric bandwidth and connections for anything more than a personal server are available here but only on business plans. Those are easily more than 10x consumer prices so I can't imagine going for them unless you need the SLA's.
One terrible way to switch to Ipv6 faster is to make existing services available only on ipv6.
Or create some cutting edge application that will work only on ipv6
I know ipv4 users like author mentioned will still be able to access them because someone else will plug in. We are stuck with ipv4 for decades, aren't we?
Or create some cutting edge application that will work only on ipv6
I know ipv4 users like author mentioned will still be able to access them because someone else will plug in. We are stuck with ipv4 for decades, aren't we?
> We are stuck with ipv4 for decades, aren't we?
Probably. All the IPv4 only devices being made now aren't going to get IPv6 and they don't have the capacitor plague or junky lead free solder of the early 2000s to kill them. They'll probably live a long life, or at least until 2038.
Probably. All the IPv4 only devices being made now aren't going to get IPv6 and they don't have the capacitor plague or junky lead free solder of the early 2000s to kill them. They'll probably live a long life, or at least until 2038.
Most IPv4-only things I see are cheap IoT junk whose requisite cloud services will shut down well before that.
Ipv4 will not be going away because the long tail is very long, but it'll become irrelevant at some point for day-to-day stuff
A vps host I use offered v6 only servers for $2 cheaper but they removed that plan probably because people kept getting confused.
> We are stuck with ipv4 for decades, aren't we?
This was always going to be the case, even with more speedy adoption op IPv6. It's also not really a problem.
Making services just available for IPv6 is going to be a recipe for disaster of the service, you've now made the service unavailable for 80-90% of your audience, and they can't do a thing to fix it (their ISP has to). You need to be better than start-up-era Google, Facebook, YouTube or Netflix to push through that and force ISPs to adopt IPv6 to support you. Basically impossible.
Forced adoption is a much better model. Apple forcing iOS apps to work on only IPv6 connections if they want to get into the app store probably is one of the largest drivers of adoption by businesses small and large, and IaaS providers especially.
This was always going to be the case, even with more speedy adoption op IPv6. It's also not really a problem.
Making services just available for IPv6 is going to be a recipe for disaster of the service, you've now made the service unavailable for 80-90% of your audience, and they can't do a thing to fix it (their ISP has to). You need to be better than start-up-era Google, Facebook, YouTube or Netflix to push through that and force ISPs to adopt IPv6 to support you. Basically impossible.
Forced adoption is a much better model. Apple forcing iOS apps to work on only IPv6 connections if they want to get into the app store probably is one of the largest drivers of adoption by businesses small and large, and IaaS providers especially.
Given that ipv6 makes it much easier to track individual devices, I'm sure ad companies would be happy to have it deployed. I think Google could strongarm isps into supporting ipv6.
You are behind the times by at least 12 years. Look up "IPv6 privacy extension"
https://tools.ietf.org/html/rfc4941
https://tools.ietf.org/html/rfc4941
Closer to 20 years: https://tools.ietf.org/html/rfc3041
To give you some idea of the time frame: Windows XP uses privacy addresses.
To give you some idea of the time frame: Windows XP uses privacy addresses.
You're locking out 67% according to Google's latest figures.
51% in the USA.
Still too many to make it practical, but getting there.
51% in the USA.
Still too many to make it practical, but getting there.
That's good to hear :) I had numbers from a good while ago in my head then.
The 'noise' on this plot of Google IPv6 adoption is interesting:
https://www.google.com/intl/en/ipv6/statistics.html
It looks quite periodic when you zoom in: at first I thought it might be different adoption rates in different timezones, but there's only one sample available per day so that doesn't explain it. Anyone know what might be going on?
It looks quite periodic when you zoom in: at first I thought it might be different adoption rates in different timezones, but there's only one sample available per day so that doesn't explain it. Anyone know what might be going on?
It's higher on weekends and holidays, which is presumably connected to mobile devices having a significantly higher rate of IPv6 adoption.
You can see on the graph between March 10 and March 24 the significant increase in the number of people working from home by the proportion of ipv6 usage
You can also see the much higher utilization of IPv6 at the end of December that's pretty consistent for the last few years.
Not just mobile, the big US cable ISPs have been doing IPv6 for years. People go home and everything is IPv6 and they don't even know.
That makes sense - thanks for that!
> That is, the ability for your connections to keep going even if you hop between IP addresses. If you had IP mobility, then you could migrate connections between your two internets in real time, based on live quality feedback.
This bit is solved pretty well by https://en.wikipedia.org/wiki/Multipath_TCP, but of course, both ends of a TCP connection have to support it.
This bit is solved pretty well by https://en.wikipedia.org/wiki/Multipath_TCP, but of course, both ends of a TCP connection have to support it.
In 2008 I was asked in one company to add ipv6 from a network stack because it was going ot be a government mandate to support ipv6. That came and went. In 2015 I was asked to add VLAN support to another network stack https://tools.ietf.org/rfc/rfc5517.txt to allow duplicate ipv4 address to co-exist in the same network. Ipv4 is not going anywhere, it doesn't have to. IpV6 is an effective way to segment your network at the hardware level.
What I am severely disappointed about is Microsoft restricting Teredo to their Xbox services.
Previously it was quite easy to get IPv6 connectivity at home when your provider only offered IPv4. In fact you'd get IPv6 connectivity by default. But at some point 1 or 2 years ago that just stopped working altogether, and my recent attempts to get IPv6 over Teredo back failed: you can establish tunnel, but it does not transmit packages to IPv6 hosts.
Now I am at the hands of my ISP.
Previously it was quite easy to get IPv6 connectivity at home when your provider only offered IPv4. In fact you'd get IPv6 connectivity by default. But at some point 1 or 2 years ago that just stopped working altogether, and my recent attempts to get IPv6 over Teredo back failed: you can establish tunnel, but it does not transmit packages to IPv6 hosts.
Now I am at the hands of my ISP.
A lack of fail-over is a problem at almost every level. Like how if my home internet has gone out and I've connected over wifi to my phone's hotspot, I have to disable my ethernet adapter before I can get at the outside world over wifi.
As long as Reddit is ip4 only, ip4 won't go anywhere...
NAT64+DNS64 works fine for Reddit. I run my desktop without a v4 address and have no problems with it.
I'm running the NAT64 myself, but it could be done by the ISP just fine, at which point they wouldn't need to provision me with a v4 address. There are major ISPs out there that do exactly this (for example T-Mobile in the US).
I'm running the NAT64 myself, but it could be done by the ISP just fine, at which point they wouldn't need to provision me with a v4 address. There are major ISPs out there that do exactly this (for example T-Mobile in the US).
Honestly, having worked for a hosting company in the past that was fastidious about IPv6 support, I can say a couple of things:
* It is almost definitely not worth it commercially, unless you've carved out your space in the community of people who specifically want IPv6
* It is much, much harder to work with than IPv4 and I don't believe this is only a lack of exposure
* Dual stacking is expensive and requires staff to pursue training with very uncertain levels of reward
IPv4 address space shortages.. could have been addressed by doubling the number of bits in an IPv4 address, rather than throwing out the many tools that already worked.
The last point in particular is heresy to network engineers, but perfect sense to commercial types. Adoption should be cheap, if not free. The huge up front human cost of training people to operate IPv6 is uneconomical. A 64bit IPv4.1 would be fine for decades.
* It is almost definitely not worth it commercially, unless you've carved out your space in the community of people who specifically want IPv6
* It is much, much harder to work with than IPv4 and I don't believe this is only a lack of exposure
* Dual stacking is expensive and requires staff to pursue training with very uncertain levels of reward
IPv4 address space shortages.. could have been addressed by doubling the number of bits in an IPv4 address, rather than throwing out the many tools that already worked.
The last point in particular is heresy to network engineers, but perfect sense to commercial types. Adoption should be cheap, if not free. The huge up front human cost of training people to operate IPv6 is uneconomical. A 64bit IPv4.1 would be fine for decades.
Where would these extra 32 bits come from? This simple IPv4.1 would still require all networking hardware and software to be updated. The protocol would also not be backwards compatible and people would still want dual stack. I imagine adoption would not be that much easier than IPv6 adoption, while missing out on the additional improvements that come with IPv6.
> while missing out on the additional improvements that come with IPv6.
Can you give some examples of what these additional improvements are?
Can you give some examples of what these additional improvements are?
There are a few. Things like the way addresses are given out (appending your Mac address to the local prefix), large address spaces (IPv6 could number every atom in existence and then some) which then permits getting rid of NAT, and especially CGNAT (carrier grade NAT).
Generally speaking the administrative hacks which enable the internet to keep going as-is can go away. NAT in particular breaks lots of applications which is why STUN/TURN servers are needed for many VoIP applications today, so that two NATed clients can talk directly.
The address space issues mean that even if the registry gives out silly allocations (like the UK's MoD having a /8) the space is so near infinite that it won't matter. Even the most incompetent governance can't exhaust the address space.
Generally speaking the administrative hacks which enable the internet to keep going as-is can go away. NAT in particular breaks lots of applications which is why STUN/TURN servers are needed for many VoIP applications today, so that two NATed clients can talk directly.
The address space issues mean that even if the registry gives out silly allocations (like the UK's MoD having a /8) the space is so near infinite that it won't matter. Even the most incompetent governance can't exhaust the address space.
Appending MAC to address is a privacy nightmare and is going away with privacy extensions. (I dont want people to know what NIC i have and potentially track me by looking up who bought it).
Because of that DHCP may be needed and ARP as well... nice right?
Getting rid of NAT is also questionable and there are now tools to do NAT with IPv6. So common sense and learned practices win. (I still prefer NAT and firewall, dedicated servers can have port forwarding or separare ip allocated)
Address space is the only feature worth anything as original poster mentioned.
This is a nice read on needless issues due to redesign of working protocol: https://blog.bimajority.org/2014/09/05/the-network-nightmare...
Because of that DHCP may be needed and ARP as well... nice right?
Getting rid of NAT is also questionable and there are now tools to do NAT with IPv6. So common sense and learned practices win. (I still prefer NAT and firewall, dedicated servers can have port forwarding or separare ip allocated)
Address space is the only feature worth anything as original poster mentioned.
This is a nice read on needless issues due to redesign of working protocol: https://blog.bimajority.org/2014/09/05/the-network-nightmare...
There is no use for NAT under IPv6 at all. It's sole purpose was to work around the IPv4 address space shortage. Any perceived security benefit was coincidental. NAT should not do the job of a firewall.
NAT hides all devices I have in my network from the world.
Nobody from the outside will know who made request x from the n devices in the network.
NAT is mainly privacy/obfuscation.
Can you do that with a firewall?
Another use case is connectivity:
- digital ocean gives 16 ipv6 addresses, how can I vpn through it with more hosts without NAT?
- me as a lone node on another network want to host a VPN but have a limited set of IPv6 addresses available.
- tethering
Note: I will actually be setting up a network with NATv6, DHCPv6 and a firewall in about a month, so I do need it, and since tools are available, I am not the only one.
Nobody from the outside will know who made request x from the n devices in the network.
NAT is mainly privacy/obfuscation.
Can you do that with a firewall?
Another use case is connectivity:
- digital ocean gives 16 ipv6 addresses, how can I vpn through it with more hosts without NAT?
- me as a lone node on another network want to host a VPN but have a limited set of IPv6 addresses available.
- tethering
Note: I will actually be setting up a network with NATv6, DHCPv6 and a firewall in about a month, so I do need it, and since tools are available, I am not the only one.
> NAT is mainly privacy/obfuscation.
That is not the original purpose of NAT. What about IPv6 privacy extensions?
> Another use case is connectivity:
Ok, there might be valid use cases for NATv6 (I am not an expert), but it shouldn't be necessary for typical consumer home networks.
I have no problems with NAT as long as it a) doesn't block incoming traffic (that is the job of a firewall) b) doesn't perform symmetric address/port translation (breaks peer-to-peer applications).
That is not the original purpose of NAT. What about IPv6 privacy extensions?
> Another use case is connectivity:
Ok, there might be valid use cases for NATv6 (I am not an expert), but it shouldn't be necessary for typical consumer home networks.
I have no problems with NAT as long as it a) doesn't block incoming traffic (that is the job of a firewall) b) doesn't perform symmetric address/port translation (breaks peer-to-peer applications).
Not the original purpose of NAT, sure, but it achieves that goal much better then IPv6
Privacy extensions are a hack and still uniquely identify someone even if it changes once a day.
NAT hides them all the time.
If I have 100 nodes, good luck identifying them over PNAT as an ISP, without PNAT you have nice tags per each node... they change once a day but you match to last days traffic.
Onto connectivity:
a) block incoming traffic - sure - blocking with firewall, NAT is redundant, its a poor mans firewall BUT if you misconfigure the firewall or is disabled, you are screwed, whereas NAT just works.
b) break peer-to-peer applications.
Port NAT is needed for privacy, so this is a given.
I also like it breaking peer-to-peer apps I only want specific nodes to be able to host stuff if ever.
For home networks STUN/TURN works just fine without having external parties know who is placing the call.
Privacy extensions are a hack and still uniquely identify someone even if it changes once a day.
NAT hides them all the time.
If I have 100 nodes, good luck identifying them over PNAT as an ISP, without PNAT you have nice tags per each node... they change once a day but you match to last days traffic.
Onto connectivity:
a) block incoming traffic - sure - blocking with firewall, NAT is redundant, its a poor mans firewall BUT if you misconfigure the firewall or is disabled, you are screwed, whereas NAT just works.
b) break peer-to-peer applications.
Port NAT is needed for privacy, so this is a given.
I also like it breaking peer-to-peer apps I only want specific nodes to be able to host stuff if ever.
For home networks STUN/TURN works just fine without having external parties know who is placing the call.
STUN doesn't work for symmetric NATs and TURN is not a solution (the traffic gets relayed over the server, which defeats the purpose of a peer-to-peer system).
Port restricted NAT is sufficient: it serves the actual purpose without breaking peer-to-peer systems.
Note: I'm currently developing a peer-to-peer app.
Port restricted NAT is sufficient: it serves the actual purpose without breaking peer-to-peer systems.
Note: I'm currently developing a peer-to-peer app.
> Because of that DHCP may be needed and ARP as well... nice right?
ARP is not a thing in IPv6. NDP is, and has always been, a required part of the spec.
(I agree with the rest of your post)
ARP is not a thing in IPv6. NDP is, and has always been, a required part of the spec.
(I agree with the rest of your post)
One is a much smaller full global routing table.
Well, the obvious one is having 2^128 addresses instead of just 2^64 addresses.
Dual stacking with 64 (or more) bits and 32 bits would otherwise use the same software. It would be cheaper, require less training, and require less development. It would therefore not face the old, established IPv6 problems covered in the article, and could even treat the old IPv4 ranges as a /32 within the 64 bit address space. Rather than being more than twice as expensive in terms of expertise and development, it would be nearly as cheap as doing nothing.
I'm sorry, what? Extending the bits in IPv4 will break compatibility completely. Everything will need upgrades just the same as to support IPv6, so you might as well go all the way at that point.
How is it much harder to work with?
How is it much harder to work with?
It's a minor detail, but an IPv4 address is easier for humans to use.
It's easier to read, type, remember, share over the phone or even just plan with in a spreadsheet.
It's easier to read, type, remember, share over the phone or even just plan with in a spreadsheet.
My Danish phone number is 10 digits, including the +45.
It would be pretty ridiculous to limit the number of phone connections in Japan by forcing them to use Danish-style 8-digit numbers, but that is the situation with IPv4.
It would be pretty ridiculous to limit the number of phone connections in Japan by forcing them to use Danish-style 8-digit numbers, but that is the situation with IPv4.
I'm not arguing against IPv6, just explaining how IPv4 can be easier to use.
There is a weird persistent idea that all anyone really needed to do was "extend ipv4 addresses" and everything ipv4 related would have remained compatible.
No, it still absolutely would have completely broken everything and anything that used ipv4, all the tools would still need to be thrown out.
There is basically no way such a proposal could work and maintain any sane level of compatibility.
Its evident right on its face, how exactly would an ipv4 only tool connect to a 64 bit "ipv4.1 address" ?
No, it still absolutely would have completely broken everything and anything that used ipv4, all the tools would still need to be thrown out.
There is basically no way such a proposal could work and maintain any sane level of compatibility.
Its evident right on its face, how exactly would an ipv4 only tool connect to a 64 bit "ipv4.1 address" ?
There were proposals for backwards compatible addressing schemes. But they were rejected for a "clean slate" approach. Almost 30 years later, we can see how successful that was...
EIP (Extended Internet Protocol) [0] was proposed in 1992 as a replacement for IPv4:
"EIP achieves maximum backward compatibility with IP by making the extended space appear to be an IP option to the IP hosts and routers.
When an IP host receives an EIP packets, the EIP Extension field is safely ignored as it appears to the IP hosts as an new, therefore an unknown, IP option. As a result, there is no need for translation for in-coming EIP packets destined to IP hosts and there is also no need for subnet routers to be upgraded during the transition period."
[0] https://www.rfc-editor.org/rfc/rfc1385.html
EIP (Extended Internet Protocol) [0] was proposed in 1992 as a replacement for IPv4:
"EIP achieves maximum backward compatibility with IP by making the extended space appear to be an IP option to the IP hosts and routers.
When an IP host receives an EIP packets, the EIP Extension field is safely ignored as it appears to the IP hosts as an new, therefore an unknown, IP option. As a result, there is no need for translation for in-coming EIP packets destined to IP hosts and there is also no need for subnet routers to be upgraded during the transition period."
[0] https://www.rfc-editor.org/rfc/rfc1385.html
IPv6 can do that too though! 6in4 is exactly equivalent to the proposed EIP extension. EIP still splits the internet into the old legacy v4 internet and the new EIP internet that cannot communicate with the old internet, since while you can send packets to a v4-only host it won't know what to do with it. You need to preserve this extra information - and IPv4 simply cannot do that. You cannot fit more than 32 bit of information into 32 bit..
This proposal essentially ended up as part of v6 in the form of 6to4. 6to4 uses an L4 protocol rather than an IP option, but that's more or less equivalent (and since there are a fair few routers on the internet that drop packets with unknown IP options it ends up working better).
But v6 doing something has never stopped people from complaining that v6 sucks for not doing the thing in question...
But v6 doing something has never stopped people from complaining that v6 sucks for not doing the thing in question...
I didn't know this was a thing, but it is always a pleasure to know people thought of something like this when I was a toddler.
Do you admin a medium or larger network? Despite the strength of your comment it also illustrates some ignorance.
"No way", "weird persistent idea".
This despite many reasonable people suggesting it.
Deploying IPv6 at scale is deploying a totally different protocal. What is irritating is that it's not just a larger set of bits, everything changed making adoption and tooling MUCH much harder.
"All the tools would need to be thrown out"
Totally and absolutely false. Because an extended Ipv4 would have the same underlying concepts you could modify the tools and continue to use them.
From address assignment (3 ways now) to the dynamic address privacy extensons (don't actually play well with IPSEC configs) to doing renumberings on prefix changes (100% nightmare) to all the training / learning new things (costs money in bigger orgs) they seem to have purposely made this change extremely hard.
Good news, I'm on board more or less with the migration at this point, and if I am a good marker of average reasonable interested in new things but not wasting tons of time then this is a good sign.
But boy they could have made this whole thing easier
"No way", "weird persistent idea".
This despite many reasonable people suggesting it.
Deploying IPv6 at scale is deploying a totally different protocal. What is irritating is that it's not just a larger set of bits, everything changed making adoption and tooling MUCH much harder.
"All the tools would need to be thrown out"
Totally and absolutely false. Because an extended Ipv4 would have the same underlying concepts you could modify the tools and continue to use them.
From address assignment (3 ways now) to the dynamic address privacy extensons (don't actually play well with IPSEC configs) to doing renumberings on prefix changes (100% nightmare) to all the training / learning new things (costs money in bigger orgs) they seem to have purposely made this change extremely hard.
Good news, I'm on board more or less with the migration at this point, and if I am a good marker of average reasonable interested in new things but not wasting tons of time then this is a good sign.
But boy they could have made this whole thing easier
> "All the tools would need to be thrown out"
> Totally and absolutely false. Because an extended Ipv4 would have the same underlying concepts you could modify the tools and continue to use them.
Exactly. ARP64 and DHCP64 etc would be minor modifications and much easier to pick up.
> Totally and absolutely false. Because an extended Ipv4 would have the same underlying concepts you could modify the tools and continue to use them.
Exactly. ARP64 and DHCP64 etc would be minor modifications and much easier to pick up.
A huge part of that is due to BSD Sockets, which require in-depth application support for any difference in connection parameters.
Maintaining compatibility was never an option. But the most sensible solution to running out of address space is simply to extend the address space. Instead IPv6 decides to change the format into something which is not really human readable, and decides to kill NAT as well. Which was really a terrible decision imo. I like NAT, I like having addresses that I can remember, and I hate the idea of having a unique globally routable address for every device.
The primary argument for adopting IPv6 is that IPv4 will be exhausted. Not that there’s something good about IPv6 that I would want to have. Personally I hope it never succeeds in getting sufficient adoption, so that eventually we can have a good IPv7 that’s just a bigger version of IPv4.
The primary argument for adopting IPv6 is that IPv4 will be exhausted. Not that there’s something good about IPv6 that I would want to have. Personally I hope it never succeeds in getting sufficient adoption, so that eventually we can have a good IPv7 that’s just a bigger version of IPv4.
That's not all that IPv6 changed. There is a reason even places like google cloud have not implemented ipv6 (and these are huge scale players). They changed so many things around the protocol that you need new firewall experts, new configuration experts etc etc
That's right: network engineers who speak IPv6 reliably enough to deploy it are rare. Network engineers brave enough to deploy V6 only are even rarer.
What do you like about NAT?
Funny enough, to the last point, someone drafted an IPv4+ spec that does something like that.
see https://tools.ietf.org/html/draft-tang-ipv4plus-03
Basically adds an optional area code to encode more addressable bits.
see https://tools.ietf.org/html/draft-tang-ipv4plus-03
Basically adds an optional area code to encode more addressable bits.
> It is almost definitely not worth it commercially, unless you've carved out your space in the community of people who specifically want IPv6
I mean if you're addressing mobile, IPv6 hosting means skipping carrier NAT64 for at least t-mobile and jio. Probably other carriers too.
I mean if you're addressing mobile, IPv6 hosting means skipping carrier NAT64 for at least t-mobile and jio. Probably other carriers too.
Generally high chances you'll get better connection with any LTE network, as having only v6 to the mobile terminal (phone/modem) is much cheaper - which drove v6 adoption heavily.
The extension to a 64 bit address with few other changes was called SIP and was proposed in 1992 (!).
https://tools.ietf.org/html/draft-historic-simple-ip-03
https://tools.ietf.org/html/draft-historic-simple-ip-03
TUBA, which used existing technology and tools to support 18-20 byte addresses (yes, byte, not bit) was ready and implemented on two different platforms by ~1991.
From an ISP's point of view IPv6 is a lot of No Business Case. Those three words are the death knell for any proposal to do anything in any business that expects to be here next year. It has exactly nothing to do with the geeky I-could-have-designed-it-better arguments about the technology.
If you are an ISP that is a going concern, with a bunch of customers sitting on IPv4 addresses, then handing out IPv6 addresses makes no difference, except when it breaks something. You still have to give your customers just as many IPv4 addresses. So why bother?
If you plan to migrate your customers to IPv6 then you are a lunatic. Its going to break stuff. Lots of websites don't exist on IPv6, and customers are going to notice. Also your customers have spent the last 20 years slowly picking up bits of IPv4 lore, like the vital importance of 192.168.0.1, and are going to be puzzled when this doesn't work any more. All of this translates into higher support costs and more customer churn.
Also, your allocated block of IPv4 addresses is a valuable asset in its own right; not only does it have real financial value (around $20 per address at present), but it also acts as a barrier to entry for competitors; if you want to set up in business as an ISP you are going to have to acquire some IPv4 address blocks from somewhere, and they aren't making any more of them. Managers are trained to look for barriers to entry to their industry, and the current IPv4 situation is exactly that. No sane manager is going to do something to make it easier for new competitors.
Eventually, of course, the dam is going to break and IPv6 will become ubiquitous. ISPs will decide that buying blocks of IPv4 addresses costs more than providing new customers with IPv6 plus some kind of carrier-grade NAT for legacy IPv4 addresses. More website hosting companies will support IPv6 in response, and suddenly IPv4 will be so last-decade.