"but Android doesn't support that"
Where does Android come into play? Is this a typo or misprint? Or am I missing something?
A bug in Windows 10 is undermining Microsoft's efforts to roll out an IPv6-only network at its Seattle headquarters. According to Redmond's principal network engineer Marcus Keane, the software giant is struggling to move over to the decade-old networking technology due to a DHCPv6 bug in Windows 10, which made it "impossible …
"The horrible irony of Microsoft waiting on its own team to fix a networking bug aside"
But this is how it should happen!
Microsoft should use and "dogfood" test all these features - and take the pain of working out any bugs before expecting the rest of us to do it....
"Microsoft should use and "dogfood" test all these features - and take the pain of working out any bugs before expecting the rest of us to do it...."
Ummm ... isn't that exactly the process that the article describes?
This isn't a product launch that has gone wrong. MS have tried an internal roll-out. They have found a number of problems. They are leaning on vendors (other parts of themselves included) to provide solutions. Once those solutions are ready, they will be available for everyone else.
(It shouldn't even take very long. Linux probably already supports the protocols, so the router vendor will probably just add the relevant packages to their stock image and re-run their test suite.)
The article does describe that, but the dogfood comment was hinting that leading off with "the irony of etc" was a bum steer since this isn't irony but an example of a deliberate use before selling policy.
And reading the article I get the impression that you are underselling the other players' problems with IPv6, though I've little experience on a narrow range of equipment to draw on.
> ... this isn't irony but an example of a deliberate use before selling policy
I disagree: (a) it's not about selling anyway, and (b) you'd imagine (OK, it's Microsoft, you wouldn't) that they'd have some consistency in their various products and the kit they bought for the job.
"Linux probably already supports the protocols"
as a matter of fact, it does.
https://en.wikipedia.org/wiki/Comparison_of_IPv6_support_in_operating_systems
(some of the info appears to be out of date, however)
For FreeBSD, I added isc-dhcp from the ports collection, and configured 2 instances, one for IPv4, the other for IPv6. it works pretty well. (I did this several years ago, working well since)
"Ummm ... isn't that exactly the process that the article describes?"
No, this is about a decade old protocol that MS already claim to support. Now they find that not only does android not support a specific function, neither do some routers and, most tellingly of all, neither is Windows in an enterprise environment supporting the features that would be expected in that situation, despite MS claiming IPv6 support. They've found a workaround for the Android issue but not for the Windows issue.
Where does Android come into play?
I agree - there I was expecting an article which, according to the headlines, is about problems in Windows - to find that actually it's a problem about Android not supporting one of the core protocols. Ie, ANDROID IS BROKEN !
Oh yes, and then something about some windows service not being IPv6 capable, almost a minor thing that.
No, but Microsoft conviniently forget to mention many windows phone models doesn't support it either. There is also a very good reason why android does RDNSS instead of DCHPv6 (tethering being one). I applaud Google for not compromising the platform platform at the expense of many for the benefit for the few.
"No, but Microsoft conveniently forget to mention many windows phone models doesn't support it either"
I doubt anyone at MS would have one, we have been unable to get MS's current windows phone models for 2 months (Shooting themselves in the foot for companies actually wanting to use and deploy them expecting we will wait for flashy phone)
Android does support RDNSS, but you know what doesn't support it? Windows!
So really, if each manufacturer is left to pick and choose what standards they want to implement (Why the F*CK doesn't Windows support open file systems like ZFS, EXT, etc!?!), then why does Android get the blame just because Microsoft chose to implement DHCPv6 and not RDNSS? If Google were upgrading, they'd probably be complaining how difficult it was to get windows PCs on their IPv6 network without DHCPv6.
Everyone is to blame here, just easy to hate on Android when you're Microsoft.
"Why the F*CK doesn't Windows support open file systems like ZFS, EXT, etc!?"
Because it doesn't need to and there is no requirement to as near zero removable devices are formatted in those file systems? The normal Windows options of FAT, FAT32, exFAT, UDF, NTFS and REFS are enough for most of us...
(There are, of course, ext2/ext3fs drivers available for Windows, and I dare say shims for other filesystems are also out there. I use it for pulling backups from my Dad's windows PC for offsite storage on the same volumes that have my Linux backups (with an offsite copy at parents' place, of course.)
"Why the F*CK doesn't Windows support open file systems like ZFS, EXT, etc!?"
In theory it could, if there were IFS (installable filesystem) drivers for them. I'm presuming that's what Paragon uses for their commercial EXTx and HFS+ commercial products. I thought that would have been a *much* better solution to high-capacity and *securable* microSD; get the industry to decide to support EXT4 for removable storage, and simply provide a driver installer for adding it to IFS (you'd only need to install the driver once, and it would support ALL devices using EXT4). But this is the same industry that insists on 500+ proprietary variations on the power-brick adapters, when it would be way cheaper to decide on 5 standardized ones.
@ AC
I applaud Google for not compromising the platform platform at the expense of many for the benefit for the few.
So you applaud Google for not supporting a protocol that's designed specifically to allow a network admin to decide how their network is used and by whom ? There's a lot, lot more to DHCP than just supplying the address of a DNS resolver !
@TheVogon
Because it doesn't need to and there is no requirement to as near zero removable devices are formatted in those file systems?
Actually, there is plenty of need for plenty of people. The reason very few removable devices are formatted in "useful" filesystems is simply because MS have deliberately not supported other file systems - as in don't support anything Not Invented Here - as is their normal mode of operation.
So we get removable devices formatted as ExFAT even though FAT is ... staying polite ... "a poor choice" for a large proportion of usage. Because, no manufacturer is going to ship something that's going to cause a significant proportion of purchasers to return it as "not working" - even when it's costing them money (through MS's shakedown racket) to do so.
Look at what they did with things like TCP/IP (amongst network protocols) and internet browsers - every step of the way they did their best to maintain proprietary standards until eventually (in these cases) they found that they didn't in fact have enough clout to get their own way.
TL;DR version - Microsoft will not support anything unless it either benefits them to do so, or they are forced to do so. They certainly do not do things because they think it will benefit their customers !
"Can someone remind us again why the Internet Engineering Task Force decided not to make this next-gen networking protocol backward-compatible?"
Who knows. IPv4 was, kinda, a bit of a kludge even for its time, with limitations built in that are akin to "nobody will ever need more than 640k"...
Perpetuating that is undesirable. However, I'm not convinced that the replacement is kludge free either.
"But it's OK. You can just proxy everything to get around that. As long as your protocol is supported by the proxy...."
But you don't need to proxy it. You can just route it with IPv6... IPv6 was built to reinstate end-to-end connectivity on the Internet and all connected networks.
Tish, fie and fiddlesticks!
If end-to-end connectivity exposes your systems to security problems YOU HAVE BIGGER PROBLEMS ALREADY.
Secondly, surely it hasn't escaped your notice that for the past, what, 15 years, the de facto vector for 98% of security compromises and data breaches have been clientside attacks that render the supposed security benefits of NAT completely worthless?
"Data snoopers"?? Who on earth are "data snoopers" when they're at home? Sounds like a phrase you'd see in a BTL comment on the Grauniad or, indeed, Daily Mail.
> I mean, it's not like anything fundamental that everyone uses is missing like, say, NAT or anything?
Arrgggg, surely we're past having to educate people about this now. NAT was a dirty hack, it's not required. There is large enough address range not to run out and if you like security (which we all do) you have firewalls and the security extensions.
FFS.
"NAT was a dirty hack, it's not required. There is large enough address range not to run out and if you like security (which we all do) you have firewalls and the security extensions."
This is all true, but it assumes access to that address range is easy to get. NAT is the difference between being able to add a second subnet to your own network, or having to try to talk your ISP into allocating you another netblock. Many places are still handing out a single /64 which IPv6 does not allow to be subdivided further. It's like going back to the old days where you had to beg (and pay) your ISP for extra static IPs every time you wanted to add a machine.
Puzzled by the downvotes for the above comment. Could someone explain which bit they disagree with?Nextweek's statements are all factually correct. You might not LIKE them, you may think they were bad decisions, but it's true: NAT is/was a dirty hack, and it's not required by IPv6. I do hope this isn't still about people clinging to the idea that NAT is a security control? (in 2017? Nahhhh... surely not.... ?)
""Can someone remind us again why the Internet Engineering Task Force decided not to make this next-gen networking protocol backward-compatible?""
Presumably because that would have been massively restrictive, and have meant lots of legacy baggage?
The move to IPv6 might be very slow, but it is starting to happen - and will likely accelerate with the widespread use of IoT - and the exhaustion of IPv4 addresses. Companies like Colt had an IPv6 backbone network several years ago...
IPv6 is at least partly backwards compatible in terms of you can easily gateway most IP traffic from one format to the other.
Making it backwards compatible is pretty much impossible because everything from the networking API downwards assumed a fixed length of 32 bits for addresses.
Making it workable was always going to be possible, but if you look at the history of IPv6 just about everything, including the autoconfiguration of endpoints has had multiple alternative mechanisms which have been adopted and then deprecated at various points in time. Every time IPv6 is nearly "there" someone seems to find a new wheeze that pushes it back to the horizon. After being soundly thrashed by the IETF for daring to suggest the adoption of an existing ISO protocol for IPv6, the IAB seems largely to have quit the scene and the ensuing free-for-all has left IPv6 a tangled mess of contradictions that are still being worked through - to what practical end remains to be seen.
The issue is that IPv6 firmly lives in a retro style alternate reality as far as address configuration is concerned.
Namely, when the protocol was designed, someone, in his infinite wisdom decided that IP address assignment and configuration is a major problem. As a result it was stuffed into the protocol in a manner which is _NOT_ expandable in the future. It is a fixed feature set by far inferior to what v4 networks get via DHCP today. Very cute. Very retro. Very useless. Unfortunately expected by most implementations (including Android). (*)
To add insult to injury as a result of the rabid multicast obsession existing in v6, DHCP for v6 was moved off broadcast and ports 67-68 to multicast and a different port making it subtly incompatible in the process.
The end result of mixing retro and deliberate breakage is that a lot of the v6 networks do not work properly for some clients because they need the "other" configuration method.
To complete the raving lunatic design idiocy fest of v6 ip configuration v4 DHCP is prohibited to offer v6 addresses and configuration information. THAT is criminal in its lunacy as it only exists because a number of lunatics (most of them are known by name by the way) who were instrumental in making v6 being adopted so slowly deliberately denied this rather obvious configuration fallback option. In the name of "purity" of the "beautiful" v6 lunatic asylum.
(*) That is MSFT problem as they are trying to roll out the network managed fully by DHCP + DNS as used by AD and not v6 autoconfiguration which is done by your upstream router.
er, trying to digest what you're saying here.
strangely, IPv6 works pretty well on my LAN and via a tunnel through he.net [it's one of the free IPv6 tunnel services, yeah]. I've got DNS returning AAAA records and everything. the only trouble I've had is with an old wifi router that seems to want to be the IPv6 gateway for the LAN, even though there's already a gateway for IPv6 [so I plugged the WAN port into the LAN, assigned it to a different IPv4 and IPv6 address, problem 'solved'].
So aside from the ancient wifi router not being set up properly for what _I_ happen to do with it, everything ELSE works quite well, including Windows 7. 10 seemed to work last time I tried it. But seriously, I'm just using off-the-shelf open source things, FreeBSD, Linux, isc-dhcp, and a tunnel via he.net .
This isn't "rocket surgery" (as Ladonna Harvey, a local radio personality, puts it - heh).
Of course, I've got my FreeBSD firewall blocking anything incoming to ports that are "open" because the windows firewall can't be trusted...
SO, Micro-shaft: What's SO HARD???
If your network is small enough to be described as "my LAN" then its entirely possible that there are issues at large scale that you're not seeing on "my LAN", as Microsoft have quite a large, diverse and complex internal network.
It's also entirely possible that some of the coders at MS who worked on the network stack are idiots, in fairness.
My money's on a little of both.
SO, Micro-shaft: What's SO HARD???
Managing the network. For lots of clients. Properly. Something you do not need to do. Size matters I am afraid.
In order to manage the network fully, Microsoft uses DHCP and couples that with DNS integrating the whole thing off AD.
That works only half-way on v6 because v6 was engineered originally to provide such information off upstream router(s). First and foremost, what is being provided in the router advertisement is only a subset of what you can and should get off DHCP in a well managed network. Second, it equated management == router which is major design limitation. Third, it makes all clients equal which is clearly incorrect in large networks. Different clients get different answers (that is the case even on my home network).
What Microsoft is doing is the right thing (for once) - trying to manage it correctly via DHCP.
What is getting in the way is the fundamentally broken v6 ip autoconfiguration design which makes all clients equal and provides them with information off a router. The router should not be an active configuration management element in a large network. It should shift packets, not perform configuration duties.
If v6 clients could get v6 information in their v4 DHCP request the whole thing would have been a non-issue. Unfortunately, due to the infinite wisdom of some people who have not done real work for decades and mostly make a living by doing raving lunatic rants about the superiority of v6 that was prohibited in the spec.
"What Microsoft is doing is the right thing (for once) - trying to manage it correctly via DHCP."
I'm already doing that. I have the routing advertisements going around, AND isc-dhcp running for both IPv4 _AND_ IPv6. When I ran Windows 10 on it [back in the 'insider' days, as a sanity test] it _seemed_ to work, but I didn't test it very long. Windows 7 seems to work ok, and I had IPv6 working on an XP box, even. [I needed to know what ports it listens on so I could firewall them with the FreeBSD gateway/router].
So I think I'm qualified to criticize Micro-shaft when they're trying to do exactly what _I_ did a few years ago. And it's _NOT_ "rocket surgery".
(actually the info over on he.net was helpful, as well as other documentation available online)
So,when I fire up the installer for a debian Linux box, the installer correctly discovers the IPv6 routing information and starts downloading packages via IPv6. When I connect a 'droid device to my network, it routes properly via IPv6. And of course everything else that's configured.
As for Active Directory - that's a Micro-shaft problem, not mine. If it's not inherently broken, it should work just fine as well. Maybe they should try using a Samba server running on Linux or FreeBSD ???
> The router should not be an active configuration management element in a large network. It should shift packets, not perform configuration duties.
Classic rookie mistake to confuse the physical platform that's running some service with the nominal function for that platform. There's no particular reason why you can't run configuration management on a (small) router but mandating that it should be so is entirely illogical, its not a router function (or like you say, "its there to shift packets").
Indeed, modern home routers run DHCP(v4), dual-stack DNS and dual-stack routing in one box. And very likely VoIP as well. Enterprise routers usually run a DHCP relay however, with the actual DHCP server centralised. But having each router announce the prefixes it supports is an elegant plus point for IPv6; there really isn't a down side for the operations people, since they have to configure the prefix into the router anyway, it might as well generate its own announcements.
"If v6 clients could get v6 information in their v4 DHCP request the whole thing would have been a non-issue. "
Yes, the lack of feature-equivalence between DHCP and DHCPv6 is an issue. I think it will come in time, despite the zealots. The main gap is a small one: getting the next hop router from DHCPv6.
No, getting v6 information via DHCP/v4 is a *bad* idea operationally. v6 operations should not depend on correct v4 operation, nor vice versa. That way you are inviting complex failure modes, and all kinds of difficulty ten years down the road when IPv4 becomes the legacy.
"Who knows. IPv4 was, kinda, a bit of a kludge even for its time, with limitations built in that are akin to "nobody will ever need more than 640k"..."
Thats not really a good analogy. Back when Gates made that famous quote large programs were already routinely using a few hundred K so make up your own mind as to why he said it. OTOH when IP was invented they had TWO machines on the network both of which were large minicomputers that your average Joe had no hope of ever affording so a theoretical maximum of 4.2 BILLION addresses probably seemed pretty darn generous. Perhaps they should have forseen the massive expansion of the internet plus the microcomputer and PC revolution, but to be fair not many other people did either and hindsight is always 20/20.
"Thats not really a good analogy. Back when Gates made that famous quote large programs were already routinely using a few hundred K so make up your own mind as to why he said it. "
In fairness to Gates, there's no evidence he ever said that. The quote was also attributed to IBM in general prior to appearing with Gates' name.
As for IPv4, IIRC they more or less realized that the 32 bit address space was a problem by the time they rolled it out; it was 1981, so there were already quite a few more than 2 computers connected to the ARPA/internet by that point. The idea was that it would be obsoleted and abandoned by about 1995...
"1981? ITYM 1974."
The paper describing the idea of the Internet Protocol was published in 1974. I was discussing the actual roll-out of (specifically) IP Version 4, which was 1981 - by which point, they were quite clear on the idea that 4 billion addresses was going to time-limit it pretty badly - which is why I used the term 'by the time they rolled it out'. :)
Don't take my word for it; read the RFC: https://tools.ietf.org/html/rfc791 (clearly dated 1981).
I'm afraid is one the issues is IPv6 was designed in the early 1990s, when the Internet and LANs were far smaller and simpler - using less complicated and integrated services.
So they didn't care at all about compatibility, probably thinking it would have replaced IPv4 soon. It didn't happen, LANs became very large and complex, and the Internet too. And nobody revised IPv6...
For example it's no surprise Windows uses DHCP6, because AD, DNS and DHCP need to work together - and thereby addresses assigned by routers need - I guess - some form of integration not yet available.
" why the Internet Engineering Task Force decided not to make this next-gen networking protocol backward-compatible?"
For the zillionth time: because it's mathematically and logically impossible to do so.
IPv4 has fixed-length addresses and no provision in the packet for extensibility of the address. So, by definition, an IPv4 protocol stack cannot understand packets with bigger addresses. So, by simple logic, a computer can speak IP4, or IPv6, or both at the same time, but each packet on the wire is one or the other*.
The way we achieve the appearance of backward compatibility is the so called dual stack model - but sadly that means the computer/router/whatever needs separate code paths for the two protocols. For example, DHCP runs over IPv4 and DHCPv6 runs over IPv6 - two different animals. Hence the reported problem, plus the fact that Google in their infinite wisdom have refused to put a DHCPv6 client in Android.
*By the way, apparently this was known before IPv6 was even designed: RFC1671.
I wish they would just scrap IPv6 and come up with a better IPv4 replacement. I can memorise IPv4 addresses, IPv6? hell no. Its been almost 20 years, IPv4 is practically exhausted of addresses and still most don't use it, and even this article shows when you have a big tech company like Microsoft and they cannot get IPv6 implemented without endless problems what luck do we have.
You don't need luck. Just skill. It looks exactly like luck to the observer, but it's not.
Give them time, and it will work just fine. And then they pass the new methods onto you, and Bob's your uncle, you have IPv6 on your W10 thing and can turn it on your router and make IPv6 calls to all your favorite I-places. Done deal. Or you can panic because of one article. Either way, I have a good time of it!
So, please let one tech news article sour you on the adoption of a highly useful protocol update that will remedy the dwindling availability of legacy addresses. Also, provide a spurious recommendation that "all should be scraped and done over from scratch!" There you go! Now, pretend you are relevant. There you go!
one article? I've been loosely following IPv6 for what seems like close to a dozen years now and I still have absolutely no interest in it (and yes I do run networks as part of my regular job, have been for nearly 17 years now though network engineer is not my "primary" role). The only real place these days where it MIGHT be needed is client networks, whether it is broadband, mobile etc. Many of those are on carrier grade NAT (including my phone on AT&T's network, just checked again 10.x IP address and no it's not on wifi). I have never had an issue tethering through my phone to AT&Ts CGNAT for any reason (other than shit signal strength).
My org has a need for a small number (3 /27s) of IPv4 space in our data centers, lots of name based virtual hosting via Citrix Netscalers and SNI for SSL allows a large amount of reuse of external IPs. I have a server at a colo in hurricane electric with about a half dozen IPs (they even asked me if I wanted IPv6 and I said no because, well I don't care about it).
I too dislike the hex-like addressing scheme. But at the end of the day IPv6 gives me nothing. Now if it is implemented upstream from me in a transparent way then I don't give a shit.
The people I have seen that seem to complain the most about NAT and IPv6 seem to be heavy proponents of peer to peer stuff, or VoIP or other use cases where NAT has historically had some issues with. Though VoIP through NAT doesn't seem to have been a problem for maybe a decade now for most, and I really have no interest in peer to peer anything.
Oh and those that bitch about overlapping IP spaces, which I admit can be an issue for larger companies that may be connecting to many others, or acquiring companies. Personally though I have not witnessed an IP overlapping issue that either I or a network engineer at a company I worked at has had to deal with since I want to say roughly 2004 (maybe that's a hint that companies I have been at often times have no VPNs etc to outside organizations)
Feel free to keep playing around with your IPv6 tunnels though if it makes you happy. I understand the "big guys" in the service providers need to get serious about IPv6 in many cases, but 98.424324325% of the rest of the world needn't care.
"Give them time, and it will work just fine."
How much longer do we need for IPv6 to "Just Worktm". It's only been 10 years or since IPv6 was unleashed on the world.
I suspect the comment about "luck" being required is that even a company as big as MS with wide ranging technical IT skills is having problems even 10 years into IPv6 being "live". That's a clusterfuck of the first order.
It really ought to be as "plug'n'play" as IPv4 by now.
"It really ought to be as "plug'n'play" as IPv4 by now."
For home users it pretty much is, assuming they have a router recent enough to handle it. It took me about a week to realize my cable company had turned on IPv6, because it just worked. While SLAAC isn't great for corporate networks it works a treat for a typical home setup.
"I can memorise IPv4 addresses" That's nice. Why not use DNS? It's quite stable nowadays and seems to scale quite well.
You didn't type 104.20.250.41 into your browser to get here and 104.20.251.41 is also this site and Cloudflare need a host header to get you to el Reg, anyway. Why on earth do you memorise IP addresses?
OK - I do understand that the fear of the unknown is kicking in but that not the real problem with IPv6. Try running a few IPv6 networks (I do) and you'll discover far more exciting problems. For example, try getting Private Address space so that you can easily survive a change of ISP. https://tools.ietf.org/html/rfc4193 goes some way to help. What about multi links to the intertubes? My work PC has lots of IPv6 addresses - we have five internet connections - and each connection causes multiple addresses along with link local, ULA and $DEITY knows what else. Firewall rules are a bit of a giggle as well.
DNS generally is quite stable you are correct, but I would have to believe that many people that deal with networking stuff do have several of their key IP addresses memorized if nothing else out of habbit. Of course I am referring to internal IPs, I don't memorize IP addresses of websites. But of things like key network devices, key servers etc, often the IPs just stick.(not that I practice and try to memorize them).
I do remember one time a looong time ago, someone edited a zone file, and put an invalid character in it, and reloaded bind. Bind gave a syntax error but kept using the old zone file. Fast forward 6 months and the server is rebooted or BIND has to be restarted for some reason and the zone drops out (the important zone) big problems.. fortunately I wasn't at the company anymore when that happened :) At about that time I started writing my own custom DNS validation script, which at the present time does a dozen different checks as part of the zone update process to make sure it goes through smoothly or aborts before anything bad can happen. I recall one time more recently a co worker put an invalid character in a host name and ran the script, which runs named-checkzone as part of the integrity checks. The zone checker passed, but then my zone check failed when it noticed the DNS did not reload the zone properly(serial number didn't match what was in the zone). Took a while to track down thought it was a bug in my script but turns out it did exactly what it was supposed to do. I was happy.
I can think of dozens if not hundreds of times over the years I have used raw IP addresses to try to connect and test stuff when things went foobar, or when I just wasn't sure what was going on(and I can't remember the last time I had a problem with DNS availability at the server end(e.g. my production network runs 8 load balanced name servers internally and yes use Dynect DNS for external), normally the issues are client based).
Now MAC addresses, those I never remember, hell I can't even remember or recognize the MAC prefix yet alone the whole thing.
"someone edited a zone file, and put an invalid character in it, and reloaded bind. Bind gave a syntax error but kept using the old zone file."
I use multiple Icinga checks for key DNS records - use a monitoring system for monitoring. I keep a list of "bootstrap" IP addresses stored in two places and a time-stamped print out - that's part of our BC and DR plan.
You do your risk assessments (often based on bitter personal experience) and then you mitigate the risks. One person's memory is not a valid mitigation for most organisations.
I do have a few IP addresses committed to memory but only by accident.
Scrap - no.
Kill some idiocies - yes.
In this order:
1. RA. Router advertisements (what MSFT is having an issue with) is an obsolete method of configuration. In the days of DHCP it is a solution asking for a problem.
2. Remove other (auto)configuration functions of ICMPv6, leave only the basics to match v4 subset.
3. Allow v4 DHCP to provide clients with v6 addressing and configuration information
4. Allow deterministic assignment of flow labels instead of mandating them to be random which in turn means you have to have an out of band signaling protocol to use them.
Optional:
5. ask everyone who opens his mouth about the sanctity of the end-to-end principle at the IETF to start their rants with a vested interest disclaimer providing info on which agency they take payroll from. It is sacred only for 3 letter agencies as it makes their job easier.
That is pretty much all it takes - it is not a lot. Most of it is trivial, obvious, makes sense and is opposed purely on techno-religious shamanism grounds.
is about as quaint as remembering phone numbers.
Face it - one of the goals of ANY new IP version is to extend the address range. So no matter how you design the protocol, you end up with more numbers per address. Saying that it is easier to remember 172.217.22.174 than 2a00:1450:400f:802::200e just does not make sense. What you CAN remember is "google.com".
Which is why we invented DNS.
On normal size internal (IPV4) networks it's common practice to assign a static range for things like servers and infrastructure such as UPS's, switches ,printers and copiers. I know the internal IP's of most of my equipment, since it's all done logically. Servers are 0-10, network infrastructure (managed switches, UPS's) are 11-19, network printers are 20-40, 60-99 is space left intentionally blank and 100-240 is DHCP. 253 & 254 are the firewall and modems, respectively.
Admittedly, I'm an SME so my offices tend to be smaller, but I can remember the addresses of all of my critical infrastructure at each office since I generally have to remember two digits for the equipment (ie, 20 for the copier), and two digits for the office. (ie, 10.0.1.20 for copier 1 at head office, 10.0.2.20 for copier 1 at branch office 1, etc)
Impossible to remember IP's, heh. What are you, a home user?
IPv6 is despised by most people who have had to use it because it's fucking awful to use compared to IPv4, and this is why the migration is so slow. In a sane world, the answer would be to address at least some of the problems and come up with something usable.
Simply adding an extra two fields to IPv4 (eg, 254.254.254.254.254.254 as IPv4E) would have solved the space problems fairly indefinitely, and we'd have finished with the rollout years ago because it wouldn't have tried to implement an unwanted agenda to networking that nobody really understands or particularly cares about, your entire skillset would have been carried across and everybody who wanted to memorise IP's would go from remembering "ten, zero, four, twenty" to ten, three zero's, four, twenty". Instead you go from "ten, zero, four, twenty" to "2a00:1450:400f:802::200e",
Given that there are still companies out there running on WinNT boxes which get the job done, precisely why anybody expected companies to dump perfectly working newish IPv4 infrastructure to replace it with hideously expensive IPv6 firewalls etc is a bit of a mystery to me.
Especially given that any management recognises that human resistance is a serious issue, precisely why IPv6 appears to have been designed specifically to antagonise the admins responsible for forcing through the requisite equipment purchases for an IPv6 rollout against bitter opposition from management and finance is something of a mystery to me. Coming up with something that would cause more resistance and less enthusiasm from IT staff would surely require considerable amounts of deliberate effort.
I don't really get the impression anyone is memorizing the IPs of ALL their favourite web pages, as you seem to be implying. But their own Exchange server, say, or a Domain Controller? Yeah, those are worth knowing off the top of your head so that if your DNS does drop dead for some reason you can fix it.
I've never, ever worked anywhere with dedicated IT staff where no-one knows at least one of their own IP addresses, and I doubt many other people have either - even if you personally don't know any, the guy in charge of networking will.
It's not like remembering v6 addresses is even particularly hard. You can set most of the address to be zeros, which means you only have to remember approximately 64 bits:
2001:db8:42:1::5
which compares pretty well to v4 where you have to remember two 32-bit addresses:
203.0.113.42+192.168.1.5
Heck, the v6 address is shorter! If you think this needs to be hard then you haven't used v6 much.
Agreed, I used to think IPv6 addresses were impossible to remember until I set up a practical network and played with it. For a small network you only have to remember the prefix once, and the rest is easy since you can skip all the zeroes. So, e.g., the router is 2001:db8:5:1::1, DNS is 2001:db8:5:1::2, the printer in the coffee room is 2001:db8:5:1::deca:fbad, etc. ;) (Although to be honest, if you're not assigning DNS names to your printers under either IP version you're really only making things harder on yourself.)
Carefully chosen hex addresses can actually be pretty memorable. Comcast's IPv6 DNS servers are 2001:558:feed::1 and 2001:558:feed::2, not really much harder than 75.75.75.75 and 75.75.76.76.
is about as quaint as remembering phone numbers.
What a silly statement.
You're mugged, phone, wallet and keys stolen. How are you going to ring your loved ones to let them know you're going to be late if you don't have at least one key number (eg "home") memorised? Or are you not so encumbered with the concept of "loved ones"?
As others have mentioned by now, DNS sometimes fails. Having some key addresses memorised helps.
It's interesting to see a large non-networking company going IPv6 only on the client side. The problem with v6 is that v4 is still just fine in most circumstances. NAT is a hack, yes, but it's everywhere and allows for an extended life for IPv4. Internal hosts generally don't need end-to-end Internet addressability, especially these days.
Obviously this can't be done easily, but I wish someone would come up with an "IPv7" that has more backward compatibility. IPv4's address space is small enough for humans to understand, and it's easy to communicate a 4-octet IP address verbally to someone.
Interestingly enough, IaaS cloud services are IPv4...and I think the major reason for that is because they don't want to alienate people who've worked in IPv4 networks for decades. They could have easily used this as the opportunity to get rid of IPv4, but it's easier.
The main limitation of NAT is 16 bit ports. If port addresses were expanded to 32 bits, we'd probably be fine with IPv4 pretty much forever. It would increase security not being able to directly address the billions of IoT devices we're told to expect over the next decade. We all know if they are on IPv6 and directly addressable, the OEMs will have open ports for that addressibility in the name of convenience and/or added features, and security will as usual be an afterthought.
NAT is an ugly hack, but it has probably saved the world from countless hacks that would have happened otherwise if ISPs gave everyone a /48 for their home and all devices were sitting out in the open.
"The main limitation of NAT is 16 bit ports. If port addresses were expanded to 32 bits, we'd probably be fine with IPv4 pretty much forever. "
It all sounds so easy until you realize that the port number is a fixed field in the IPv4 header and changing it would break backwards compatibility and that would have most of the same deployment issues that IPv6 has.
It all sounds so easy until you realize that the port number is a fixed field in the IPv4 header and changing it would break backwards compatibility and that would have most of the same deployment issues that IPv6 has.
So just implement lossy compression of port numbers, duh!
I'm a genius.
This post has been deleted by its author
"The main limitation of NAT is 16 bit ports. If port addresses were expanded to 32 bits, we'd probably be fine with IPv4 pretty much forever."
For larger networks you can set up source NAT pools, so that connections are spread over a number of IP addresses instead of a single NAT address (e.g., the NAT router), thus avoiding the 16-bit port number limit. Cisco has supported this since when NAT became a thing.
16-bit ports are only a limit for NAT if the implementation is stupid. Instead of matching the flow on just the local port, you should use the triplet { local port, remote addr, remote port }.
There are even entire countries (with far more than 2^16 clients active at any time) sharing a single IP address.
"There are even entire countries (with far more than 2^16 clients active at any time) sharing a single IP address."
Yes. And I wonder how many "RESTful" transactions per minute fail half way through as a result. This is a prime example of applying enough thrust and obtaining a flying pig.
Just look at what happened when people used ADSL modems, or were on the same subnet with some of the early fibre deployment. Once I mentioned it while teaching in a networking course - and the day after the students came with lots of data they got from their "neighbors" (XP days, lots of easily accessible admin shares... it was also a course made for "disadvantaged" young people - ethics was not one of their strong points.. hope I was then able to teach some of it too...)
The biggest catalyst for IPv6 has been mobile devices. Mobile networks are already doing carrier-grade NAT for IPv4, with all the ugliness that entails. (It seems OK until you have tethering that creates another NAT behind the NAT, then things get tricky.) IPv6 actually works better when it's available, and many carriers have deployed it. It's just not very noticeable because few people look at the network configuration of their phone. My T-Mobile phone usually gets a globally-routeable IPv6 address and an RFC1918 IPv4 one.
I actually think this is a proud moment. Most of these problems could have been predicted by talking to engineers with working knowledge of IPv6 (hello, Comcast, Verizon, T-Mobile, et al!) and Microsoft is pushing through changes with their vendors that will benefit all users of their equipment. Anyone want to hazard a guess as to the vendors? I suspect we'll soon see Cisco announce new IPv6 support in its wireless products.
Let's go down the list of issues reported:
1) Routers do not support RDNSS - Yep. This is common and anyone with working knowledge, literally anyone, would know this. You cannot deploy without testing for Android. MS are getting this fixed.
2) Wireless auth is only support on IPv4 - Slightly less common knowledge than RDNSS, but it only takes one test setup to identify, and it is common knowledge at enterprises that have attempted IPv6 deployments. Granted, these are few and far between for now.
3) Apps - This should be a known factor as well, since some of the earliest mass v6 deployments were phones. I saw a presentation at NANOG a couple of years back about the apps that broke with v6 (WhatsApp was a prime offender, because their DNS replies were too huge and the shit app didn't know how to process them). They ended up creating a 464 XLAT architecture so they could run Android on a v6-only network without breaking things, IIRC (464 being a v6-only network with v4 relays both on the Android device and at the network edge, in this case).
All told, this sounds like a great development for IPv6. I look forward to more network infrastructure supporting it natively!
BTW, who likes NAT? I can only think of one real advantage it has.
"BTW, who likes NAT? I can only think of one real advantage it has."
The trouble is that most users thing NAT means most of their devices are hidden from the Internet automatically: a secure-first situation. But from what I've read, this isn't totally true. The ISP (which provides your IP address/block) can actually directly connect into your LAN with a little knowledge and the proper routing tables. If the ISP can do that, anyone else (like the State) can persuade/coerce the ISP to do it on their behalf.
Until such an event makes the news and breaks the myth of NAT "invisibility", it's gonna be hard to convince people.
PS. To all those saying just extend IPv4, the problem is that IPv4 can't be extended. It's 32-bit address and 16-bit port limits are hard-coded. Because of this, devices that only grok IPv4 can ONLY address devices with IPv4 addresses: no ifs, ands, or buts. It's like trying to cram 24 eggs in a carton only built for 12; something will break along the way. So your only option is to start fresh, and if you're going to start fresh, why not try to keep the issues you're having now from cropping up in the future? Things like overly-complicated routing tables, the kind that are knocking routers to their knees...
"But from what I've read, this isn't totally true. The ISP (which provides your IP address/block) can actually directly connect into your LAN with a little knowledge and the proper routing tables."
Don't know what you've been reading but no they can't unless you have a router with no firewall on it or you actually use the ISP provided router/firewall. I do networking for a living and rule one is you own and control your border (for a given value of own).
Nearly all of an ISPs customers are going to be using 192.168.0/24 for their LAN. They (ISP) will need to be able to distinguish each one (customer) to be able to do as you suggest and that will mean a lot of NAT and the customer router will have to be complicit to return network packets to them. Then there is the little matter of the firewall at your end. If it blocks all inbound access from connections that were not started from the inside then that applies to your ISP as well.
It starts to get a bit more complicated when we consider active FTP, SIP n RTP and the delights of IPSEC int. al.
"Don't know what you've been reading but no they can't unless you have a router with no firewall on it or you actually use the ISP provided router/firewall. I do networking for a living and rule one is you own and control your border (for a given value of own)."
Here's the problem. YOU'RE within the ISP's borders. And since the ISP knows which external IP they gave you, they can go from there to your router and, if the firewall wasn't there, route packets from there to your LAN. Another networking expert demonstrated it a few months ago.
Point is, it's not the NAT that guards your LAN from the outside but the firewall. And there's NOTHING stopping you from putting a firewall between your LAN and the IPv6 Internet. IOW, NAT is giving a false sense of security; attention needs to be focused on the firewall instead, which doesn't go away with IPv6.
I for one, like NAT. Having independence from IP addressing from an external entity is nice. My first real job back in the 90s we had a /24 for the office, all computers had a real internet IP(statically assigned if I recall right), I believe they have a firewall but I don't remember. I do remember at one point the ISP said they were forcing an IP range change on us, and it was quite a lot of effort at the time to change everything over(I wasn't in the IT group but did help with some things on the side). With DHCP on the client side that would be easier these days for sure.
Obviously(or not who knows what people expect these days) my nearly 1,000 servers/VMs use static IPs (assigned during provisioning), and it's very handy to know I can hook up any ISP externally I want on any IP space and not have to worry about changing things internally since NAT takes care of that for me.
IPv6 folks like to pimp that you can just get a routed subnet that is portable across ISPs etc, which I'm sure in some cases(or maybe most, I don't know) is possible, but it's still extra steps that doesn't bring me any benefit to make up for the headache that is IPv6.
I also like the ability to define my own internal networks, obviously with IPv4 being in short supply for a long time doing it with real IPs for most orgs is impossible. So NAT to the rescue. At the end of the day NAT works for the vast majority of use cases out there, and as the old saying goes if it ain't broke don't fix it.
I even use NAT within my laptop, my VMs running in vmware workstation have a "host only adapter" configured with a private subnet that connects to my laptop so no matter what subnet my laptop happens to be on I can always connect to the VMs (host file entries) since the internal IP is always there.
"I also like the ability to define my own internal networks, obviously with IPv4 being in short supply for a long time doing it with real IPs for most orgs is impossible. So NAT to the rescue. At the end of the day NAT works for the vast majority of use cases out there, and as the old saying goes if it ain't broke don't fix it."
So do that anyways using an internal range and SNAT at the border. IPv6 only killed the one to many NAT the other types are still supported.
In fact, two topology scramblers are built into the IPv6 spec. One (basically a 1-to-1 NAT, which they've never had issues with) allows you to rearrange external-to-internal v6 IPs at the router level so that the internal and external numbers don't match up so you don't give away your LAN structure. The other assigns ephemeral v6 IPs to all outgoing connections, which prevents using backtracking as an intrusion tool (not only does the random IPs prevent structure snooping but being ephemeral they don't last so even if you snoop the number it won't connect back once you're done).
"BTW, who likes NAT? I can only think of one real advantage it has."
let me guess - the automatic firewalling of "all of those open ports" on the typical windows machine?
that's the only REAL advantage that I can think of. That and sharing the same connection with a single 'connected' device, but that part was a given...
> that's the only REAL advantage that I can think of. That and sharing the same connection with a single 'connected' device, but that part was a given...
Try this:
All my connections go out of the network over a VPN.
I have multiple endpoints in distinct locations with automatic fail-over between them
I want to be able to connect to IPv6 endpoints (but am far less worried about others being able to connect back to me).
With a single endpoint, I might just number the lan using a subnet that gets routed to the endpoint, and tell the endpoint to route packets for the relevant subnets back down the tunnel. It works, all's happy.
But then that endpoint fails and we fail-over to endpoint 2. It also supports IPv6, but obviously has different prefixes routed to it. The LAN now won't work without renumbering.
So, I have three realistic options,
- forsake the VPN and use the subnet assigned by my ISP (assuming they actually support it, which they currently don't). That's a crap option
- configure the LAN so it automatically renumbers following a failover. Do-able but needlessly fiddly
- Use NAT on the endpoints. Simple to set up
Guess which option I've gone with? Granted it's a bit of an edge case, but I don't think it's _that_ unusual a requirement
I have no idea what you guys are talking about with all this 'NAT gives a false sense of security' rubbish. I've never heard anyone claim that NAT is a security feature or that you don't need a firewall with it, because it's patently untrue and no-one with twenty minutes of network training would say it.
It exists purely to get around the address space limitations of IP4 and everyone I've ever discussed it with (at least, everyone who understood what NAT meant) has agreed that should ALWAYS be used in conjunction with a firewall. That really shouldn't be news to anyone.
In a large network DHCP provides a lot more information than IP addresses, often including boot servers, time servers, directory servers, etc. It also allows tracking which machine got which IP address, something IPv6 does not provide otherwise, but which is often vital on a corporate network.
I read that "what chance is there" as for more typical SMB type shops. T-mobile is obviously a very large service provider which has tons of internal network expertise on staff. When I deployed my first layer 3 network back in 2004 the network engineer I was working with was struggling with the concept of routing(maybe took him a good 18 months or so to really start to think at layer 3, that concept was new to me too at the time though I picked it up quick).
Another network engineer I worked with years later struggled with the concept of why it's a bad idea to set tcp/udp session timeouts on a firewall to "1 week", and why the state table filled up and the firewall stopped passing new traffic why failing over to the backup didn't fix the problem(state replication duh). His solution until I came along was to power cycle both firewalls simultaneously (and he said Cisco support did not have any ideas either as to the cause of the outages -- they didn't realize it was state table related until I showed up).
So point is there are a lot of network engineers out there that well have a hard enough time in the IPv4 world, don't try to put IPv6 on them. Yet alone people who aren't "network engineers" who don't even understand the concepts of say a default gateway.
We should get away from that stupid MTU of 1500 as well.
I fully agree.
How does the IPv6 64KB "ordinary" MTU and 4GB Jumbogram MTU sound ?
Put into perspective - yesterdays whole memory stick capacity can be held in a single IPv6 frame !!!
This is just another iteration of the technology treadmill. We've seen paper tape, 800 bit per inch magnetic tape and X.25 links. The IT industry should be more than capable of handling technology evolution, its just part of what we do..
I hadn't yet heard of IPv6's larger MTU sizes (or if I did I forgot) but I would be curious just to see the amount of impact it has to performance vs IPv4 on 1500 or 9k jumbo. Most folks tend to think that 9k jumbo doesn't really give any real benefit over 1500 even at 10G speeds. Myself I do run jumbo frames for a dedicated cluster network segment for my vmware hosts (mainly for vmotion / fault tolerance traffic on dedicated NICs). Evacuating a VM host I can pretty much peg the 10G link(only time I ever come close to saturating a 10G link) though I haven't done any comparisons with standard frame sizes or measuring cpu usage etc.
I also allocate 9k frame sizes for my iSCSI stuff though the clients to-date are all standard frame so with MTU auto negotiation the jumbo never gets used on iSCSI (I had plans to put clients in dedicated jumbo frame VLANs but never really needed to).
"We should get away from that stupid MTU of 1500 as well."
Not all of networking is software - there are physical things like switches involved. Your comment looks to me like kneejerk layer 3+ thinking. The 1500 thing has been around for a very long time and has stood us in good stead for decades.
For switches etc to function at the speeds that we enjoy, they have to have fixed in hardware sized "buffers" (for want of a better and correct word - I don't do hardware).
It is frankly astonishing to me how well things still hang together and 1500 is still a pretty good choice for most networking. iSCSI and a few other things generally benefit from Jumbo Frames but not all networking. There are also mini JFs (1508) for PPPo(?:A|E) so that a full eth frame can be sent without fragmentation.
What is the tyranny of 1500 any way?
Most Ethernet related chips can actually handle 2048, which makes a lot of sense since it's a far more logical limit. Extending it a bit past 1500 to support the most common case where you need to stuff extra things into the Ethernet frame is perfectly logical - PMTUD is so widely broken across the Internet that a connection with <1500 MTU is little better than useless without MSS clamping.
IIRC the 1500 limit has to do with cable lengths in shared Ethernet segments which isn't really a relevant limitation nowadays...
The limit may have come from there, but since the limit exists everything was designed and built around it. You can't just change it. Jumbo frames only work on network segments where every single device on that segment supports it and all have it enabled. It's not easy to get right.
At least IPv6 mandated that the minimum was 1280, which is much better than the minimum allowed by IPv4, so at least when using IPv6 you could use a pretty decent size and not worry about MTU discovery at all.
But too many routers and switch chips and network cards (wired and wireless) and all sorts of tunneling protocols, etc all know 1500 or so is the standard, and most have hard limits that don't allow you to exceed that by very much.
Yes, we need 128 bit addresses. Really?? An address for every grain of sand on the planet?
Yes, the 4 billion addresses for IPv4 isn't enough for every human on the planet, but 96 bits more, not really useful. IPv7 ought to pare it down a bit to something more reasonable. In my book, I'd settle for 48 bits, which strangely is the address field on ethernet (there may be something there).
Yes, Microsoft needs to eat its own dog food, hopefully BEFORE it releases things to the general public. This seems only right! There is the big FAIL!
"Yes, we need 128 bit addresses. Really?? An address for every grain of sand on the planet?"
You don't run routers for a living do you? The whole point of 128 bit addresses is efficient address aggregation. Unfortunately Private Address space will probably screw that up *sigh*.
The idea is that an ISP has a few (perhaps one) prefixes and each customer gets a /48 or /56. Even a /56 is enough for 256 /64 subnets and a /48 is enough for 256 (sites) * 256 /64 subnets or 16 (things) with 16 (sub things) with 256 subnets. A /64 subnet is huge, so no running out of addresses.
The IPv4 internet routing table is bloody massive nowadays but the IPv6 one _should_ be quite small because your addresses fit neatly within your ISPs, which fit within ... etc etc. Each entry will be bigger but there will be fewer of them.
Anyone wondering why even a home user might need VLANs has not been following the IoT discussion or noticed how it would be nice to have multiple wifi SSIDs that are segregated properly. One day its possible that we will all have multiple VLANs at home. Its not the fault of the IPv6 designers that your ISP is a twat that doesn't care about your security.
"doesn't that whole concept of route organization go out the window if people start taking their subnets with them to other ISPs (perhaps in other parts of the world?)
or does that not happen at the low end (is that what you mean by "private address space" ?)"
Broadly, yes. When you sign up with an ISP, they will allocate you a portion of their IPv6 space (a prefix - should be /48 but may be /56 or even /64) and all your devices will use that prefix via DHCPv6 or SLAAC etc to set themselves up.
Now, if you change ISP, your entire IP addressing will change! This is fine(ish) for home users that rely solely on a dynamic setup and a flat single LAN. Hopefully their printers are found via broadcasts or similar and the telly supports things properly.
So you might want to buy your own globally unique address space. This costs real money - £K per year. Then you will need to get your ISP(s) to route your range for you or allow a BGP peering arrangement with you. This will also cost rather a lot. The perceived cost of a renumbering exercise for a few 1000 machines will far outweigh the cost of PI address ownership. I predict that many companies will go down this route and hence cause the global routing tables to expand to what effect I don't know but I expect we'll see a repeat of the 100,000 IPv4 entries blowing up internet routers happen again in a new IPv6 guise.
At least in RIPE land, legitimate (as opposed to black market) IP address assignments don't cost anything. At most you might have to pay an administrative fee.
Provided you have a proper connection (not "broadband") to a real ISP they shouldn't mind announcing a prefix for you. BGP might cost you a bit but certainly not much.
I know of one company that pay less than 200 pounds per month each for their two 1G connections with full BGP.
A bug in Windows 10 is undermining Microsoft's efforts to roll out an IPv6-only network at its Seattle headquarters.
What bug? The whole article, and it doesn't mention or describe "a bug in Win 10" anywhere other than that sentence.
Was the first sentence added by the headdline writer? Or what?
Indeed! It says two issues are being addressed by router manufacturers and that Android can't handle the new DNS thingmy. The starting couple of paragraphs sort of describe a windows issue but not in enough depth to be sure that's where the problem lies.
El Reg trying to spin the story as anti-ms to get the comments flowing? Why, are there supposed to be adverts on these pages?
The slowness of IPv6 adoption is depressing. Technically it is quite old hat by now, and really quite nice when you get used to it... Ten years ago I worked on a telecom product that used IPv6 extensively, even for its internal communication between units. The OS was a variant of FreeBSD, and the CPU power about tenth of what you nowadays get in low-end laptops. I sort of expected IPv6 to become common in a few years. Never underestimate the inertia of installed base...
I blame windows for slowing down the implementation of IPv6.
Mostly, it would be due to ISPs not wanting to deal with the fact that there will be NO NAT DEVICE between the windows computer and the intarwebs.
This means that the plethora of well-known listening ports will be EXPOSED TO THE INTARWEBS again. Just like a dialup connection USED to be (and in some cases, probably still is).
So guess who gets to deal with the tech support issues caused by viruses, zero-day exploits, and so forth? That's right the ISP!
As a result, they don't want to deal with it. having to set up a tunnel through a free service (like he.net) is like an "intelligence test" of sorts. For average 'plug it in and it works' users, it's a security disaster waiting to happen.
And I blame WINDOWS for that. Their machines should NEVER expose ports like that. They should listen on localhost, NOT the entire address space! And MIcro-shaft's firewall is a *JOKE* at best. In any case, with the latest SMB exploit waiting to happen, I'm sure that Micro-shaft will have PLENTY of headaches and patches when they FINALLY get around to making IPv6 support good enough for ISPs to support it, too.
Actually, Windows has been shipping with a enabled-by-default firewall that blocks inbound connections from the internet for over 10 years now.
On top of that, most people are sitting behind a router that does inbound firewalling on top of that, so in general there are *two* firewalls between your well-known listening ports and THE INTARWEBS. This is not the problem that it once was back in the dial-up days (where nobody used a router and Windows didn't have a firewall).
Blocking incoming connections is not something NAT is needed for. A device that blocks incoming connections and does nothing else is _far_ simpler (as in smaller, cheaper, and with less things that can go wrong) than doing NAT.
Plus, even if not blocking everything, the standard Windows ports have been blocked in network borders for ages now.
"Plus, even if not blocking everything, the standard Windows ports have been blocked in network borders for ages now."
except that it's a moving target. Windows Vista, 7, "Ape", and now Win-10-nic each seem to add NEW ports to be concerned about. And the Windows built-in firewall is pretty much a JOKE, in my opinion. It's still "Windows" between ethernet and the listening applications, after all...
With many phones using IPv6, roll-out of IPv6 may be happening quicker than you think.
Take a look at the following graph from Google: https://www.google.com/intl/en/ipv6/statistics.html
Seems like over 15% of users access Google through IPv6 today. That's a lot more than I expected!
I certainly use IPv6 a fair bit at home since my ISP supports it.
My modem happens to have a rather odd bug, where once in a while (every few months) it suddenly stops sending packets for IPv4, while my IPv6 packets get through fine. I don't know how it does this, since all it sees is PPPoE packets from my router, so the modem should have no clue, but somehow it does. Rebooting the modem fixes it.
The funny thing is that it takes hours for me to realize that the problem has happened, since google stuff (gmail, etc) all works fine, facebook works fine, but links to other things stop opening and I start to wonder what is going on, before finally remembering the stupid modem problem and go reboot it and suddenly gain access to the IPv4 world again. Quite a bit of the internet does work with IPv6 only these days it seems.
I'm playing around with IPv6 just now. The somewhat laudable aim of IPv6 is every device should have a unique global address. Fine, NAT is less than ideal as it make protocols more complex and the Internet less end to end.
But smaller ISP users (despite IPv6's massive address space) still give out very dynamic IPv6 addresses, even though they often give out a large '/56'. Just as dynamic as their v4's. The solution from the standards is requesting a private allocation, you can carry ISP to ISP. Good luck doing that if you are not a huge corp, I'm sure BT home broadband will happily add a global routing entry for you. But I doubt this will even be possible if you are a medium to large company going through an ISP switch.
Okay so I can't live in the ivory tower that protocol designers do, I can't change ISPs and keep my addresses. So the solution is to use ULA (private IPv6 addresses) for internal comms. But I have servers so I'd like to statically set them v6/v4, but I don't think I can statically set the v6 ULA and leave the v6 Global routable dynamic.
So my preference, and I'd imagine when the real world internal networks get to IPv6, is to just use ULA internally and use NPT (Network Prefix Translation) to connect to the Internet. Now NPT is much better than NAT at it's a one to one mapping of IPv6 external to IPv6 internal addresses (no port translation stuff of IPv4 NAT, every internal IPv6 maps to a unique external IPv6).
But if you set ULA only on interfaces (all I'm told) will use IPv4 for Internet connectivity. So the only way around this is to pick an out of standard ULA (that is just unallocated space in IPv6) and it should work. But now I've broken one of the nice things of ULA if I do it properly, namely if you go to one of the randomisers to allocate the address, you should in future be able to plug any two ULA networks together and the addresses shouldn't collide (as the space is so huge). And I'm non-standard.
Maybe I'm missing something, but I think we are yet to see IPv6 deployment bodging that will make it practical for the real world (like NAT was for IPv4).
You seem to have missed the fact that you are no longer tied to having 1 IP address per machine. It is expected to have both an ULA and a global prefix assigned to each LAN machine.
Use DNS views for .local domain to present the ULA for internal machines. That way your machines can use their ULA for LAN communications and whatever random value global-scope has that day for outbound WAN connections. Anything that needs to receive global connections should have fixed IPs so you can either setup a NAT66 to map those to the ULA or assign the appropriate global IP as a third address on the machine presenting that service.
What you end up with is static IPs for services provided to the world, an ephemeral global-scope range for outbound connections, and a static ULA range for internal traffic.
I see all that, yes. the question was:
"But I have servers so I'd like to statically set them v6/v4, but I don't think I can statically set the v6 ULA and leave the v6 Global routable dynamic."
These require outbound Internet services for these servers. Internal LAN servers getting stuff of the Internet (e.g. update servers, virus scanner updates etc).
I do this with SLAAC. Either accept that the bottom 64 bits will be generated from the server's MAC address, or look for token support in your OS of choice (`ip token` on Linux).
You then advertise the prefixes you want via RA - you can advertise multiple prefixes, so you advertise the fixed ULA prefix, and the dynamic global prefix - and the OS will generate multiple addresses, one for each prefix.
Is your network connected to the internet? If so then it's part of the internet, and hence falls under "should be IPv6".
Of course if your network really isn't connected to the internet then you can go ahead and keep using v4 (or IPX or whatever) on it, but very few networks are isolated these days.
My router is connected to the internet and should be IPv6.
My internal network, which is currently only differenciated by IPv4 address class, and is on the internet while technically not having an internet IP, could run on IPv4. It's a far more efficient use of IP addresses.
I don't understand how you misunderstood that? It's not an isolated case, everyone has that experience, unless you plug your computer directly into the internet without using a router or modem?
And yes, one day we will run out of IPv6 addresses. It won't be in our lifetimes, but it will happen. Then my idea will make even more sense, except IPv4 won't exist anymore.
I didn't misunderstand; you just can't do that. If you want to connect a network to the v6 internet then you use v6 on it. You can't use v4 because there's not enough space in the v4 header to indicate which v6 host you want to connect to.
If you don't want to connect your network to the internet then that's fine; you can use a proxy over whatever local protocol you want (or just have no internet access). Pretty much nobody does that though.
Because that's just not how it works. IPv6 quite rightly unifies a lot of things that were merely afterthoughts to IPv4, and cuts quite a lot of crap too.
Just because "we always did it that way" doesn't mean it's the best or most practical way of doing it.
Long, long ago when PCs were few and expensive, and networking them together was very hard (and required expensive experts) they were designed to make linking them together on a network as easy as possible. Think happy puppy glad that everyone is their friend.
Then PCs appeared in homes and still were happy puppies; however not all strangers were trustworthy. However so much work had been put into ease of connection that nobody wanted to change this. "Use a firewall" was the solution. Can you say Zone Alarm, children? Good. Now can you install and configure it?
Woe, though, firewalls were even more complicated than networking and had the annoying habit of asking you if they should allow you to do every little thing that was obviously vital. Can you say "Yes..yes...yes...YES....... Oh, just turn the fucking thing off!" children? Potty mouth!
Then PCs became cheaper (although IP addresses didn't) so someone invented NAT. Suddenly there was an example of the law of unintended consequences.
Bear with me for a short while; to connect to a program on a computer over a network that program has to be listening for the incoming call on a specific port. Happy puppies respond to everything. To route data over a network the router just accepts all the data and passes it on. The router doesn’t have to run any/many services so it doesn't have to listen to any ports. Early routers often didn't even have web servers. They were managed over serial ports using real metal wires.
So the unintended consequence was that all unsolicited incoming calls were just dropped because the router wasn't listening for them. It only listened for replies to connections it had initiated.
This was NOT a firewall. It just looked very like one when viewed from the Internet. Can you say "shields up" children? Well done!
So NAT suddenly increased the security of Internet connected PCs without the PC makers having to do anything hard and expensive.
Over time, of course, there was feature creep. Games wanted to call out on one port and listen on another. So UPnP was born and did much to reduce the security. As attacks became more sophistcated and routers had more ports open to do vital and clever things router manufacturers had to add a firewall. This was a good thing because clever users could do clever things but happy fluffy bunnies and waggy puppies didn't really have to worry.
So the home was a happy place because everything came in to one point and was managed by an off the shelf router which (with luck) didn't need anything more than just plugging in by that nice engineering man in the grubby van.
So here we are today in 2017 with our nice cosy walled garden where what happens in Chez Vegas stays in Chez Vegas (more or less). We are being told that we should replace our nice cosy set up with a new kind of setup. Unfortunately this setup was designed 20 years ago and may well be designed to solve the problems which were obvious 20 years ago but which may not be the biggest problems now.
However some things have now become a religion so beware of criticising them, Best Beloved, because bad people will come with sticks to beat you.
You're right -- NAT has indeed become a religion. The reality is that it's not required for security in the slightest. In v6, everything comes into your home via the router, and the router drops all inbound connections unless explicitly configured otherwise. That should sound familiar, because it's the exact behavior that you're attributing to NAT.
(In fact, as mentioned earlier in the comments, NAT often gives people a false sense of security, because it doesn't actually block any connections at all. Anybody that can send packets to your router with a dest IP set to 192.168.1.x can connect to your LAN machines regardless of any NAT going on on the router. It's true that most of the internet won't be able to do that, but your ISP certainly can, and so can any government agencies that feel like leaning on the ISP. You want your network to be actually secure? You can't use NAT for that.)
"Anybody that can send packets to your router with a dest IP set to 192.168.1.x can connect to your LAN machines regardless of any NAT going on on the router."
On an IMPROPERLY CONFIGURED router, yes. It's not that hard to create rules to block all incoming AND outgoing connections to/from RFC1918 addresses. I would assume that router makers would be smart enough to do this. If not, I'd like a list of FAIL, please...
Or the other choice: use 'bridge mode' on whatever 'thing' plugs into the intarweb, and firewall it with your OWN 'dual home' box, running Linux or FreeBSD. You could even set it up as an IPv6 gateway, via a free IPv4/IPv6 tunnel. Yeah. I do that.
Yep, that's the point. If you configure a firewall then inbound connections will be blocked, but it's important to realize that configuring NAT doesn't automatically give you the firewall. The false sense of security comes when people set up NAT and expect it to block all inbound connections. Obviously doing NAT with no firewall is IMPROPERLY CONFIGURED, but a surprising number of people don't realize that!
(I find it interesting that v4 routers with no firewall are considered rare and improperly configured and irrelevant because of how broken they are, yet v6 routers with no firewall are apparently ubiquitous and acceptable and it's v6 at fault for the lack of firewall somehow, instead of the router manufacturer. Why the double standard?)
It takes no account of the real world, privacy is an afterthought kludge and has about zero ability to work with IP4.
I hope the IETF has been working on an IPv8 that interworks properly with IPv4 and that can be easily configured for privacy and security by default on home users "edge routers + firewall + modem + Wifi Airpoint devices.
Essentially we can only turn off IPv4 when EVERYONE is using IPv6, that's not realistic. Nor is the configuration of a home LAN other than for network specialists.
IP6 may be a wet dream for Google and IoT, but it's not fit for purpose for ordinary consumers or to allow seamless transition to IP6 from IP4.
The problem -- which el reg conveniently forgot in order to drive comments -- is that v4 isn't forward compatible, so it's not possible to make something which is somehow magically backwards compatible with it. Any approach you can take ends up looking like either 6to4, Teredo, NAT64+DNS64 or NAT64+464XLAT. Which as you can see already exist for v6.
I'll also note that v6 is both private and secure by default out of the box on current devices, and has been so for years (or at least it's no more terrible on those fronts than v4 is).
Trouble is, people can't see into the future, and constraints can usually prevent extensibility, such as being forced into a 32-bit address limit (because processors of the time in use for IPv4 hardware were limited to 32-bit registers and the like).