Slashdot Mirror
Vint Cert Warns IPv4 Users: 'Time To Get With the Program' (zdnet.com)
An anonymous reader quotes ZDNet:
Vint Cerf notes that the world ran out of IPv4 address space around 2011, some 13 years after internet engineers started sketching out IPv6, under the belief back then that IPv4 addresses would run out imminently. Since 'World IPv6 Launch' on June 6, 2012, significant progress has been made. Back then just one percent of users accessed Google services over IPv6. Now roughly a quarter of users access Google over IPv6. But Cerf noted that "it's certainly been a long time since the standards were put in place, and it's time to get with the program"...
The Internet Society's snapshot of IPv6 in 2018 notes that Google reports that 49 countries deliver more than five percent of traffic over IPv6. There are also 24 countries where IPv6 traffic is greater than 15 percent, including the US, Canada, Brazil, Finland, India, and Belgium. Additionally, 17 percent of the top million Alexa sites work with IPv6, while 28 percent of the top 1,000 Alexa sites do. Enterprise operations are IPv6's "elephant in the room", according to the Internet Society. Around 25 percent of all internet-connected networks advertise IPv6 connectivity, and the Internet Society suspects that most of the networks that don't are enterprise networks.
The Internet Society's snapshot of IPv6 in 2018 notes that Google reports that 49 countries deliver more than five percent of traffic over IPv6. There are also 24 countries where IPv6 traffic is greater than 15 percent, including the US, Canada, Brazil, Finland, India, and Belgium. Additionally, 17 percent of the top million Alexa sites work with IPv6, while 28 percent of the top 1,000 Alexa sites do. Enterprise operations are IPv6's "elephant in the room", according to the Internet Society. Around 25 percent of all internet-connected networks advertise IPv6 connectivity, and the Internet Society suspects that most of the networks that don't are enterprise networks.
it is 2018, and as of today, Verizon FIOS still doesn't support it. Why? Who knows.
The few managers and consultants I've talked to dislike ipv6 because
They do not want to type long ipv6 addresses. (their or their client's DNS is probably not setup well)
They fear incompatibility. (mostly I heard Exchange Server, which might still need netbios names (I'm not talking wins), even thought microsoft said with Active Directory you don't need netbios resolution, but you do...
Perhaps microsoft should have an end netbios campaign, like they did with ie6.)
Vint Cerf remains loyal. After helping to make the Internet easy to track, now he serves his masters by pushing a tech to make things easier, like fixed IPs even when changing networks or ISPs.
It looks like slashdoters are still stuck with XX century protocol
I'm a Centurylink gigabit customer near Seattle with a static block of IPv4 addresses. Their IPv6 support is still only 6rd, which their implementation only works with a small handful of routers. Sadly, I just found out that my latest router is one that doesn't support it. STILL waiting on that native dual-stack support.
I firmly place all of the blame on the major ISPs at this point. Most have IPv6 dual-stack on their carrier networks, but are sluggish as fuck delivering the packets to the last mile for some ridiculous unknown reason?
You can keep your IP address, 192.168.1.42
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
I'm in total agreement: at least move to IPv5 already, if you aren't ready for IPv6! Sticking with IPv4 is just being stubborn.
We haven't "run out" of IPV4 addresses. Not even remotely so.
A good comparison would be land. There was a time, even within the last 50 years -- where one could (for example) 'stake out' land in Canada. You'd head to unclaimed land, put up your fences, work it and use it -- and in 5 (or 10? it's been a long time since I read up on this), the land would officially be yours.
This is closer to IPV4 realities, than not.
Why?
Because, IPV4 used to be *free*. You needed netblocks, you got netblocks. You request, and they were delivered.
Then they became non-free. Much like land in Canada, you can't just take it and use it, nope -- you have to buy it from someone.
A lot of that goes around, too. One corp selling to another. CorpA leasing to subscribers. ISPs selling additional IP addresses / month, for a fee.
If we had really "run out", I would have to WAIT to connect to the internet. Or, I'd be stuck behind a NAT device (I'm not), because my ISP had to aggregate clients because they had no free IPs.
Truth is, there's loads and loads of IPV4 laying around.
Otherwise, why would people be saying WE'RE GOING TO RUN OUT! for TWENTY FUCKING YEARS, and there's still a shit-tonne of IPs left.
Hmm?
Eh?
Hum?
Bah!
(And yes, SNI alone helped a lot... but that's not the point. Or maybe it is -- because, it's an example of "look -- there's gold all over the ground" and now "we have to dig for it, maybe we'd better use gold more wisely")
I bet in 2050, we'll still primarily be IPV4.
You can keep your IP address, 192.168.1.42
Hey! that's the IP address of my luggage.
Spoken like a mere user. Those of us who've had to connect NATed enterprise networks via VPN, having to find common unused IP spaces, NATing around both ways to get machines from both ends to talk to each other, having to implement DNS zones, know just how wrong this is. IPv6 is a godsend, solving one hell of a lot of problems those of us actually working in networking have. Now, if only more of the management guys listened to us, we'd have moved on to IPv6 for quite a while.
That's pretty ignorant. Because NAT creates very nearly as many problems as it solves.
And if users don't want a device traceable or directly reachable by ipv6 address you can still do NAT with ipv6 too if you want; you just don't HAVE to.
And that's a good reason for NAT and private addresses for IPv6.
In my home net I run fd00::/8 and when the ISP finally get their thumb out of their behind I plan to do a NAT of that.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
ISPs use NAT to provide enough addresses. Services like point to point communication (things like Skype) is difficult because each device does not have a unique address.
And for the internet visible addresses: With IPv6 each subscriber can get as many addresses as is available on the whole internet today (or more). With random address assignment, scanning the address range of just one sunscriber will take as mush effort as scanning the antire internet today. So even if the devices are available, they will not be easy to find.
Would someone tell me how this happened? We were the fucking vanguard of networking in this country. The IPv4 was the IP to own. Then the other guys came out with TCP. Were we scared? Hell, no. Because we hit back with a little thing called DNS. That's IPv4 and easy to remember english names. For usability. But you know what happened next? Shut up, I'm telling you what happened—the bastards went to IPv6. Now we're standing around with our cocks in our hands, selling four numbers and names. Usability or not, suddenly we're the chumps. Well, fuck it. We're going to IPv12.
#DeleteFacebook
That's probably the biggest problem with IPv6 - an attempt to solve more than what's really necessary with one blow.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
You don't have to scan the whole space, It wouldn't be that hard for someone to setup some rogue internet ads, gather up all the IPs that hit those ads, then target those IPs.
Chicken and egg. In Azure, the only way you can get a public IPv6 address is by using a load balancer. You can't just put a single VM up on IPv6. Even if some other provider does offer better IPv6 support, Azure is #2 atm, so they'll need better IPv6 support as well.
192.168.1.x is just too damned crowded.
I moved to 192.168.2.x ages ago.
--- Mercutio was right.
My ISP doesn't give me IPv6 connectivity. So I'm sunk.
Is this segment of the population just hell bend on NO PROGRESS for anything or anyone? Seriously, shut up.
That's pretty ignorant. Because NAT creates very nearly as many problems as it solves. And if users don't want a device traceable or directly reachable by ipv6 address you can still do NAT with ipv6 too if you want; you just don't HAVE to.
Users have little choice on being traceable, it's what the ISP offers. Why do we bother with dynamic IPs, DHCP leases and all that stuff? Because IPs were/are a limited resource and when we were on dial-up reserving an IP for every customer was excessive. With always-on/mobile broadband most devices are always-on and and the IPv6 address space is massive. While there are some laws in some countries to preserve IP-customer history it's usually not forever and it takes a warrant to access. With IPv6 it'd be totally possible to move to a static default, you are path::to::ISP::customerNumber::MAC and it's yours forever and everything you do is linked by default. That's worse than Microsoft's Advertising ID because you can't effectively turn it off and switching to Linux doesn't help. At best maybe you can fake a new device every time and make them think you're a coffee shop or something.
Live today, because you never know what tomorrow brings
$ dig tech.slashdot.org aaaa
tech.slashdot.org. 59 IN CNAME www.slashdot.org.
$ dig www.slashdot.org aaaa
(no answer)
The World in which IPv6 Was a Good Design. I found this brief history on IP and Ethernet to be quite informative. It also suggests a possible way forward for mobile IP (by basically putting another layer on top).
Editor, A1-AAA AmeriCaptions
MAC addresses aren't fixed, so changing it and regenerating your IPv6 address would be a way to avoid being traced (most if not all IPv6 generators use MAC addresses as a parameter and a fixed algorithm, so regenerating it without changing the MAC will give you the same address every time). That said, it is much more of a pain in the ass than just going to a coffee shop and logging on when you want to be anonymous. Also with coffee shops you need to either move around or know to clear your IP cache or the fuzz will be able to trace back to you eventually.
Not a criminal, but worked on network security enough to know how to be invisible if I need to be.
But with IP privacy, those addresses will soon become invalid. Meanwhile, with a simple firewall rule, they will be non-responsive anyway.
are use really using fd00::/8 or are you proeperly using a fd::/48 from that network?
XML is like violence. If it doesn't solve the problem, use more.
And now is up to us to pick up the pieces.
They simply made the address field too small.
And do not but that "this was an experimental network, we couldn't have known" weasel-talk.
You see, about the same time Vint and Bob were working on their little 4 Bytes in the Address Field protocol (1981), Other people were also working on similar protocols.
Some Guys at OSI were working at CLNP, and guess what? That has 20 (5 times more!) Bytes in the Address Field...
Some other guys at Xerox were working on IDP, which has, hear this 12 Bytes! on the Address Field...
Those guys at Xerox and OSI knew how to think big, and were real visionaries. Other people realized big address fields were needed. Too bad uncle Vint and Uncle Bob did not...
But, by luck of the dice and historic accident, IP emerged as "the" network layer protocol. Fair enough.
When world + dog realized that IP had not enough addresses, the IAB came up with a nice solution: Use CLNP. Good, that thing was _already_ implemented debuged and tested in most routers in the world, client implementations existed (and were debuged and tested) for most OSs in the world, and all the IP (pun intended, I mean, intellectual property, such licesinsing and patents) was already sorted out. There is even an RFC (1347). Work and migration could have started then and there in 1992!
But even if you dislike OSI, you could have used IPX (a decendant of IDP with 12 Bytes addresses). Again, IPX had rock solid implementations for pretty much all OSs at the time, was implemented in every single router, and had all the Licensing/Intellectual properties sorted out. There is also and RFC for that (RCF 1791). So, again, the migration could have started then and there in 1995!
But the IETF, suffering from a bad case of Not Invented HEre Syndrome, did what is called the "palace coup" and decided to disregard the orders of the IAB, and create IPv6. What were Vinton's opinions on that? I think he stayed mum (or even worse, cheered the move).
What we know now as IPv6 was voted as "the way to go" between 1994 and 1995 , and the firts implementation (on AIX) appeared in 1997. And was not until 2000 that most OSs had production quality IPv6. So, we lost between 5 and 7 years of transition time (depending of if you preffer using CLNP or IPX)... And countless man-hours were wasted reimplementing the Long Address wheel in every OS and every Router and Every modem, and .... you get the drift. And is a weird one at that which, for example, does not have a header checksum...
And after all this, old uncle Vint is pontificating on the need of migrating fast to IPv6? Get a grip!
PS: In NO way is this post intended to diminish the contributions of Vint and Bob to networking. Those contributions are huge. is just to point out the incoungruence of getting us in this mess in the first place and then pontificating for us to hurry up!
*** Suerte a todos y Feliz dia!
And if users don't want a device traceable or directly reachable by ipv6 address you can still do NAT with ipv6 too if you want; you just don't HAVE to.
Originaly, the creators of IPv6 (and the IETF) did not want _anything_ to do with NAT.
Only because of pressure from users and vendors did they _finally_ gave in and defined NAT for IPv6.
Just look at the RFCs. IPv6 was declared a Draf Standard in 1997. The IAB emited an RFC (5902) "starting" to consider the Issue in 2010, and we got an experimental standard (RFC6296) in 2011, so, 14 years were NAT on IPv6 was simply NOT POSSIBLE.
Fact check first, say comments are ignorant latter.
*** Suerte a todos y Feliz dia!
Spectrum still has no IPv6 support. It really is getting to be ridiculous that its 2018 and there is still no IPv6 support. When, if ever? Do these companies need to be fined to compel them to upgrade>
I know I'll get burned for saying this but IPv6 fails the scratch and sniff test. I've grown up around the IPv4 dilemma yet no-one I know that I worked with (contractor worked at 30+ different businesses) ever seemed to fully grasp IPv6. Workers don't get it, vendors don't get it, network providers don't get it, telcos don't even seem to get it. Based on the fact that we've been at this for 15years+ and it still hasn't gained any traction it's time to call it a failure and move on.
Wrong. You could not be more off the mark here. A lot of applications rely on a peer to peer connection, it can include a gaming application, peer to peer video conferencing and so on. Having to pay for central server/cloud resources to proxy this stuff around would drive up the cost unnecessarily . It unnecessary wastes bandwidth and congests the networks, slowing things down, to have to transmit data through servers. The bottom line, we need more IP addresses. Most users DO want their own IP address even if they don't know what an IP address is, because the applications they use work much better with it.
That error should be fixed.
There is not a single ISP on the NBN in Australia who provides IPv6 over FTTC. That is new technology launched in 2018. Way to go NBNco!
bash$
> With IPv6 it'd be totally possible to move to a static default, you are path::to::ISP::customerNumber::MAC and it's yours forever and everything you do is linked by default.
RFC4941.
That's probably the biggest problem with IPv6 - an attempt to solve more than what's really necessary with one blow.
That and not making the slightest attempt at backward compatibility. Like those guys lived in an ivory tower or something.
When all you have is a hammer, every problem starts to look like a thumb.
The financial services industry will NOT use IPv6 because multicast doesn't work properly on switches, there is no good way to filter unwanted traffic.
When all you have is a hammer, every problem starts to look like a thumb.
They tested IPv6 service about 7 years ago, but took away my IPv6 routers at the end of the trial period. All I have left are my static IPv4 addresses.
All static IPv4 Comcast customers get at least a static /56 allocation whether you know about it or use it or not. Check your Comcast business account portal. Assigned IPv6 network will be listed there.
We probably won't. Devices having a public IP isn't a problem; just because you have a public IP doesn't mean it's possible to connect to it. ISPs provide routers that have firewalls, and the firewalls block inbound connections. Your "average joe blow" just plugs that in and they're fine.
What happens today is that people buy IP cameras, and then they go "hey, how do I view this from the office?", followed shortly by port forwarding to the camera or putting it in the DMZ. 30 seconds later, somebody finds the camera in a random port scan, because the v4 internet is tiny and it's very easy to exhaustively scan the entire thing. With v6, this isn't going to happen -- it's nigh on impossible to find devices by randomly scanning the internet, because it's just too big. Of course that doesn't make the device itself secure, but it should render random network scanning useless as a technique for spreading worms, which should improve the security of the internet as a whole.
Now there IS no shortage of IPv4# any more, since the invention of NAT. The only reason for IPv6 now is total traceability
As a user I want to be able to directly communicate with others without my communications being mediated by a centralized server owned by corporate stalkers and governments. NAT makes this very difficult to achieve.
There is a certain logic in hiding behind a single IP and thinking this does something for your privacy. In some ways it's true. In most ways that matter it's an illusion.
Most CGN implementations use a port mapping structure in which each user is allocated a logged predictable fixed subset of ephemeral ports. Source port can be logged by any server you visit and used to uniquely ID you vs. others using the same address even though everyone is behind a NAT with the same public IP.
Obviously the gambit at all layers of the stack from exploitation of DNS caches, TLS resumption, browser fingerprints, cookies and sessions applies to Internet users especially web users.
So for me given the choice in terms of freedom and privacy I chose IPv6. I can use privacy addresses if I want to thwart correlation within my network. Having a reasonable chance of directly communicating with peers is worth way more to me in terms of capabilities, freedom and privacy.
and the ability to directly address any device... something most users do not want.
What your saying is not only wrong but completely backwards. IPv6 is SAFER than IPv4.
The reality is there are no consumer IPv6 capable routers that don't do SPI by default. IPv6 SPI affords users more secure than IPv4 NAT due to absence of ALG and associated packet mangling codes.
I'm confused. Where do you get the idea that they made no attempt at backward compatibility? We have 6to4, Teredo, NAT64+(DNS64/464XLAT), 6rd and DS-lite, we have standard APIs that work with both v4 and v6 addresses interchangeably and you can run the two protocols in parallel on the exact same networks and hosts and they won't interfere with each other. What part of that comes under "no attempt at backward compatibility"?
Perhaps you mean that you can't make connections from unmodified v4-only hosts to v6-only ones, but that's impossible because of the pigeonhole principle, and it would be a little unfair to criticise v6 for not doing something that's impossible.
Direct connectivity is impossible, and any attempt at working around that results in something that looks like one of the transition techs that we already have. So what more could they possibly have done?
Corporations hold onto NAT for reasons that are real, not imagined, and not easily overcome by smoothly worded IPv6 talking points.
NAT is a security risk.
In reality I have broken it down to a /64 with a random 40 bit and also a random 8 bit subnet part. But in order to not expose what I have on my local net I still prepare to NAT it.
I understand that people think that NAT is bad, but it's not always bad since it also offers the ability to hide what you have from your ISP and some ISPs would like to control and know what you have in number of devices etc. It's after all a privacy issue to use NAT, not that it's technically better.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
That and not making the slightest attempt at backward compatibility.
Are you joking? There have been countless RFCs dealing with compatibility from every which way. How many more do we need?
https://en.wikipedia.org/wiki/...
IPv6 day was the grownups sending a pretty clear message that clowning around with transition schemes were no longer appreciated. They demand a production quality IPv6 network at least as capable and reliable as IPv4.
This means all of these crummy tunneling overlays ended up being unused, unappreciated and ultimately rather pointless.
Like those guys lived in an ivory tower or something.
Ivory towers full of pigeon poop I bet. At least they appreciate the pigeonhole principle.
The financial services industry will NOT use IPv6 because multicast doesn't work properly on switches, there is no good way to filter unwanted traffic.
It's called RA Guard.
Because there's no way to make it work. v4 is incapable of talking to v6, because there isn't enough space in the v4 destination address field for the v6 address to go. You'd need to somehow make every v6 address also be a v4 address, but that won't work because there are only 32 bits available in v4 and that's nowhere close to enough. There's nothing v6 can do about this, because it's v4's problem.
One possible workaround would be to do NAT with v6 on the inside, but doing that would only allow outbound connections from v6 to v4. Also it's called NAT64 and it's already a thing that exists and you can use it and it works. Is that good enough for you?
I'm confused. Where do you get the idea that they made no attempt at backward compatibility?
Other than it being a layer 3 protocol, ipv6 is incompatible with ipv4, please don't act stupid. As a protocol ipv6 is completely incompatible with ipv4. Must I express this in words of fewer syllables?
When all you have is a hammer, every problem starts to look like a thumb.
You don't know WTF you're talking about.
When all you have is a hammer, every problem starts to look like a thumb.
Typical ipv6 goon, patronizing. Yah, that's going to work. News for you: ipv6 mafia are the clowns. Not just my opinion.
Don't shoot the messenger. It's what content wanted. Google counts milliseconds of latency in terms of millions of dollars in lost revenue.
To them it is either native IPv6 with similar reliability and capability or IPv4. They are not interested in losing money on tunneled overlay schemes. This reality is something many "IPv6 goons" had no appreciation for. Goons only cared about clever ways to get everyone IPv6 with duck tape and bailing wire if need be as soon and as fast as possible. The "goons" were laughed out of the room by big content.
I just went over a bunch of ways in which it isn't incompatible. Do those not count?
Perhaps you could explain how it could've been made any more compatible than it already is? I don't mind how many syllables you use, so long as you describe something that would actually work.
In the ways that count, ipv6 is incompatible. As everybody says, but you.
When all you have is a hammer, every problem starts to look like a thumb.
IGMP is not an ipv6 protocol.
When all you have is a hammer, every problem starts to look like a thumb.
> They really really should have engineered some sort of backward-compatibility into it
It's really easy to say this, but if you sit down and think about it you'll realize that it's not possible to do. v4 isn't forwards compatible, so v6's hands are tied, and there's nothing that anybody could've done about that or could do about it in the future because it's not due to any flaw in v6 but rather due to a flaw in v4. Criticizing v6's designers for not doing something that's impossible seems incredibly unfair to me.
If you think you have a way of doing it, then great -- share it. I keep asking people to do this, and for some reason they never actually do.
(Also, if you think v6 adoption is still relatively low then you haven't been paying any attention to the stats. Google's published statistics are a little bit under 25% worldwide, and Facebook are seeing days where their US traffic is primarily v6. Those numbers should be higher, but they're not exactly low.)
Alright, let's go with that for now. The next question is: what could they possibly have done about it?
v4 isn't forwards compatible, and doesn't support anything more than 32 bits of addresses. This is ultimately a flaw in v4, and there's nothing that v6 could have done to avoid it. What should the designers of v6 have done to avoid this problem? What changes could have been made to make it backwards compatible?
It also ensures the existing providers can lock up the market, because new upstarts cannot get any addresses, or can't get enough to provide a comparable service to the existing providers.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Ok, was just seeing if people were using ULAs incorrectly. As designed it means pretty much never having to have the headache of a conflict when somehow getting routed to another private network, though for most people in practice I have been afraid the required 40 bits of random would exacerbate "I can't type this" sort of problems.
I think I'm less worried about people who know enough and take the time to properly do ULA addressing on their network not NATing than I'm worried about the family who buys a random cheap gateway and turns it on not setting up anything. Today that cheapo device can't help but to effectively firewall that user off for lack of a subnet, but for the default for the random endpoints to get globally addressable addresses *and* the chances of that device bothering to have a properly configured firewall... wel...
XML is like violence. If it doesn't solve the problem, use more.
On the other hand the networks where we in the financial industry use multicast is all over private lines anyways so address contention is not a problem there and thus IPv4 is no problem there either.
Vint Cerf followed up his Commodore 64 with the Commodore Plus/4. It's better because it has more bytes available for BASIC programs!
IPv6 doesnt change much of that, but it adds the ability for true peer-to-peer connections, and allows the use of larger pools to pick addresses from, making it much harder to do network mapping. IPv6 isnt about privacy, but it doesnt make anything worse in that regard, and in some ways it makes it harder for spies.
Saying IPv6 is for traceability is the networking equivalent of being and anti-vaxxer.
I got me a block in the 10.x.x.x space, shhhh, don't tell anyone else about it!
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
I warn Vint Cerf: if you had not done such a crappy job of designing IPv6 then you would not be whining now about why people do not want to use it. The warning: next time let somebody competent lead the project, if there is any next time for you.
Bleah. Vint Cerf, narcissist, responsible for arguably the most expensive technological mistake in history.
Still getting downmods for calling Vint Cerf what he is. If you had ever met him, you would know too.
I have. Leaves nothing to the imagination.
When all you have is a hammer, every problem starts to look like a thumb.
Right, you got it. The same argument applies to data centers and nearly everywhere else that tech investment is really concentrated.
When all you have is a hammer, every problem starts to look like a thumb.
Alright, let's go with that for now. The next question is: what could they possibly have done about it?
They could have banned Vint Cerf from the steering committee, great start. Then get down and seriously figure out the least painful way to extend the IPv4 address space. Too hard for Vint Cerf to comprehend, apparently. Maybe you also unless you are just being disingenuous, which is a distinct possibility.
Nobody said anything about forward compatible, do you know the difference? (I doubt it.)
there's nothing that v6 could have done to avoid i
Intellectually embarrassing claim for you to make.
When all you have is a hammer, every problem starts to look like a thumb.
When I still had AT&T U-Verse, not only did they not provide IPv6 but they took steps to block IPv6 over IPv4 tunneling so maybe someone should talk to them? I complained to the FCC and they approved the practice.
Most are not "just sitting" on large unused blocks. They may have a lot of total unused IPs, but most of their blocks are in use. This idea has been addressed soooo many times before. Even if everyone spent the several years re-numbering their devices to consolidate IPs and messing with routing, they could give back 1-3 months of IPs. Spending a dollar to save a penny.
IPv4 is non-extendable in any useful way. That RFC is about as much of a joke as https://tools.ietf.org/html/rf... Computers must look like magic to you. If someone can't get something done, they must not be waving their magic wand hard enough.
Beyond brainstorming, anyone who takes extending IPv4 seriously should not be in change of anything related to networking. It's not an ivory tower issue. It's the limitations of logic in our Universe.
IPv4 is non-extendable in any useful way.
Says who, you? A bald assertion without support.
That RFC is about as much of a joke as...
That RFC was the first draft of IPv6, before a lot of the really stupid stuff got put in. Feel dumb? You should.
Beyond brainstorming, anyone who takes extending IPv4 seriously should not be in change of anything related to networking.
Nobody who has anything to do with technology should listen to anything you say, you have adequately destroyed your credibility. Typical IPv6 fanboi... thinks it's great and everybody should do it, but isn't sure why. Is sure that nothing else could possibly be better. Likes to trot out talking points spammed by the IPv6 mafia. Doesn't know how do to anything else.
When all you have is a hammer, every problem starts to look like a thumb.
Perhaps you could spend less time insulting me (and Vint Cerf; what on earth did that man do to you?) and more time answering the question.
Dumping 80 pages of whitepaper on me isn't very reasonable, but okay, I went through it. The interesting part of RFC1710 looks like section 5. However, section 5 doesn't describe any backwards compatibility that "counts", under your definition. It describes SIPP versions of dual stack (element 1), 6to4 (element 2), dual stack again (element 3), NAT64 (element 4) and I'm not sure about element 5 but it says "does not look like it will be needed" so I'm not sure the mechanism there was ever even developed.
Dual stack, 6to4 and NAT64 are all things that we have already in v6, and I argued above that they are backwards compatibility, but you claimed that they weren't "in the ways that count", and I agreed to go along with that for the time being. So... by your own definition, these don't count.
Presumably, then, you weren't referring to section 5 of RFC1710 when you linked me to it. Could you tell me which sections of the RFC you were thinking about, that describe a method of backwards compatibility that counts under your definition? Or perhaps just describe the mechanism itself?
(I also went through the first few sections of the IPAE whitepaper, but again it doesn't seem to describe any mechanism that would qualify. Again, if I'm wrong then please point me to the relevant part.)
>> there's nothing that v6 could have done to avoid i
> Intellectually embarrassing claim for you to make.
The claim is essentially the pigeonhole principle, which isn't intellectually embarrassing in the slightest. You clearly believe the pigeonhole principle is either wrong or can be sidestepped here, but your inability to articulate how is doing a poor job of convincing me that you know how, or even that such a method exists.
(Of course it can be sidestepped with methods like 6to4, but we need a method that "counts", and so far you haven't been able to describe one despite being given ample opportunity to do so.)
If we had really "run out", I would have to WAIT to connect to the internet. Or, I'd be stuck behind a NAT device (I'm not), because my ISP had to aggregate clients because they had no free IPs.
Many ISPs already put subscribers behind NAT, particularly mobile ISPs and home ISPs in later-to-develop countries. The only way to get your own IPv4 address from those ISPs is to upgrade to business class service with a static IP.
That's what copy/paste and mDNS are for.
Copy/paste is practical within a single device but not, to my knowledge, across devices. What solution do you recommend for synchronizing the clipboard across devices that run Windows, macOS, X11/Linux, Chrome OS, Android, and iOS?
IPv4 is non-extendable in any useful way.
Says who, you? A bald assertion without support.
I don't need support, it's a logic problem. I don't feel a need to disprove 2+2=5. I'll give you the benefit of the doubt and assume you're trolling.
/sigh Last attempt, in case you're not trolling. Riddle me this. How do you change IPv4 without changing IPv4? This is what you're advocating. The IPv4 extensions are not transparent, they require updating many devices and have translation devices in front of other devices that cannot be updated. If you're going to go through all of the hassle to update most devices, why not just throw it out and start over rather than making a cluster fk of a protocol?
If you think IPv6 is bad, an extended version of IPv4 will be 100x worse. The only benefit is the transition might kind of be better, but the end result will be a festering pile of crap. IPv6 is the bite the bullet, do it right, way. It may not be perfect, but perfect is impossible for the scale of IP.
I feel so dirty for continuing this argument. Like I'm arguing with a flat earther.
...as he said when he was on campus a couple years ago, google's self-driving cars that have NO steering wheel and NO pedals.
" Why do we bother with dynamic IPs, DHCP leases and all that stuff? Because IPs were/are a limited resource and when we were on dial-up reserving an IP for every customer was excessive."
You aren't entirely wrong. But the bigger reason for dynamic IP and DHCP was simply convenience. Grandma didn't need to know her IP address to use the AOL CD.
IT people could centrally manage desktop and laptop IP allocations for subnets and etc without having to program it into each PC.
When laptops came along, DHCP allows you move around and connect to different networks with a minimum of hassle.
It wasn't really primarily about ip address space limitations; although, yes, that certainly was a factor, especially in the later years.
"With IPv6 it'd be totally possible to move to a static default, you are path::to::ISP::customerNumber::MAC and it's yours forever and everything you do is linked by default"
Yes, it would be *possible* to do this. But that's really not much of step beyond what they can already do for most cable, dsl, and fibre users, where the addresses are 'dynamic' but often remain stable for years and only get changed when services / infrastructure are changed.
And with ip v6, it would still be trivial to use VPN proxies, use random macs, and connect from public wifi APs.
ISPs *may* also go the other way; and flip the script, and NAT your ipv6 address by default. Then they can sell targeted advertising. If they gave you a global static public ip address by default -- like you said that's great advertising id... why would they give that away when they could sell it?? :)
Also, static is usually an upcharge today -- not just because of limited ip address space. (consider that whether you are on dynamic or static; and you are using cable/DSL/fibre you still need an ip address dedicated to you pretty much 24x7 so the demand on the ip pool is the same) but they charge extra for static because you need it to more easily run servers etc; and that won't change with ipv6. So again, static-by-default is giving up a revenue stream -- because some customers will need static and will pay extra for it.
Finally, even if the ISP went static by default, all you have to do is hire an ipv6 VPN service, and you are back to the same level of privacy you have now. To the outside world you originate at the VPN, and anyone who wants to know who you are will need to subpoena the VPN provider for logs. Obviously that won't work in a regime that both requires static ip and bans the use of VPNs... but if you live under such a regime you have a political problem not a technical one.
But people do want to use it. They just can't because telcos don't support it. Minor telcos do. The ones that realise that investment is not a dirty word. It's not Vint Cerf's fault that some groups thrive on fucking their locked in users. At least when you invite over a prostitute you get some enjoyment out of it.
"Originaly, the creators of IPv6 (and the IETF) did not want _anything_ to do with NAT."
Yes and?
"Only because of pressure from users and vendors did they _finally_ gave in and defined NAT for IPv6"
So ipv6 does NAT. Which is what I said.
"Fact check first, say comments are ignorant latter."
What was there to fact check? The comment was ignorant. Ipv6 does nat. And not only is it there, but its there precisely because of heavy pressure from users and vendors. That's a good sign that its not just going to be there, but that it will actually get used.
I don't need support, it's a logic problem
But your logic is lacking, so you need support.
By claiming that IPv4 can't be extended you are the flat earther. IPv6 is already an example of such an extension, it's just a crappy one that alienates millions of users with its stupidly long addresses, NIH way of doing everything needless incompatibility with IPv4 address space and many other bizarre details. If you don't know how those issues could have been ameliorated, then you should fucking get down off your high horse because you are incompetent. Sheesh, you sound like a Vint Cerf clone, and that is how we got into this big sticky expensive mess. You are the problem, you are the flat earther. And yes, I feel more stupid after discussing this with the likes of you.
When all you have is a hammer, every problem starts to look like a thumb.
Crazy idea: if nobody can do any better, then maybe they didn't fuck it up? Maybe they already did make it as good as it could possibly be.
Both stateful firewalling and NAT require state tracking, so they're often implemented in the same piece of software or hardware. Nevertheless, the firewalling and the NAT parts are logically separate components. The NAT part is responsible for rewriting addresses, and the firewall part is responsible for deciding which packets to drop.
The logic is pretty well-supported: v4 is limited to 32 bit addresses, so there's no way for it to specify which v6 host it wants to communicate with. That, right there, kills your ability to do perfect backwards compatibility. There are some ways around that limitation, but v6 implements those ways and you already dismissed them as not counting further up.
If you think it's possible to do full backwards compatibility in a way that you'd accept, then you could easily convince us by just describing a way to do it (a valid way, one that works and doesn't have the limitations of the existing ways). The fact that you can't -- and then call us incompetent, as if it was our fault that you can't answer -- just makes it more and more obvious that you don't actually have a way to do it.
Did you mean to have a discussion with yourself?
That, right there, kills your ability to do perfect backwards compatibility.
That's where you fall off the rails and descend into a morass of wankery, right there. Perfect is the enemy of good enough. Users can deal with erring out because of not upgrading their network stack yet, after all that's exactly where IPv6 started. Effective workarounds include tunnelling and NAT, as you know (but probably will pretend not to know). The asshattery that you are promulgating is that, now breaking everything is justified, including not even trying to embed IPv4 in the IPv6 space, and a huge pile of other saliva drivellingly bad misbegotten design features. Sad to see that Steve Deering, former sensible designer of multicast, went on to become a central figure in the IPv6 debacle, how did that happen? He should have known better.
When all you have is a hammer, every problem starts to look like a thumb.
I already mentioned, multiple times, tunnelling and NAT as viable backwards compatibility options that are already available in v6, but if you remember, I asked you if those counted and your response was "In the ways that count, ipv6 is incompatible" and you called me stupid for mentioning them as a way to do backwards compatibility.
That's why I've been asking you to tell us your idea for making it compatible in a way that you consider as counting -- because as far as I can tell it's not possible to do, and I don't think it's fair in the slightest to blame v6 for not doing something that's not possible in the first place. Or are you now admitting that 6to4 and NAT64 actually do count as backwards compatibility?
Embedding v4 into the v6 space is easy enough, but how does that get you backwards compatibility? We already have ::ffff:<v4 addr> which does the embedding, but how do you enable two-way communication? If you could somehow also embed v6 into the v4 space then it'd be pretty easy, but there's not enough space in v4 to do that (if there was we wouldn't need v6 in the first place).
This post is either the 4th or the 5th time that I've asked you to describe a way of doing backwards compatibility in a way that would satisfy you. I think it's about time you either did so, or admitted that v6 is already doing the best backwards compatibility that it can given the constraints that it's working under.
Look, IPv6 is a monumental failure, that is not in doubt, and you are an apologist for it. We both know what the addressing issues are, and we both know what the solutions are. Just give up on the wanking about perfect forward backward compatibility please. You are wasting your own time, and mine. Bye. Hopefully forever, and enjoy you IPv6 island with nobody on it.
When all you have is a hammer, every problem starts to look like a thumb.
Yes while a firewall explicitly blocks packets by design according to your specified rules, NAT loses packets due to breaking the way the system works.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
It sounds like you've done a 180 and now agree that v6's backwards compatibility does in fact exist and works well enough, even though it doesn't and can't work perfectly (like I pointed out at the beginning and have been pointing out the whole time). That's good to hear, even though your attitude sure doesn't suggest you've realized that you've done it.
Incidentally, I posted this from a machine that only has v6. Slashdot works fine from this machine, and in fact I've yet to find a website that doesn't work from it. How is that an island, any more so than NAT44 already is?
It sounds like you've done a 180 and now agree that v6's backwards compatibility does in fact exist and works well enough
No, IPv6 backward compatibility with IPv4 is crap as everybody knows, even if you admit that dual stack is a valid and sensible thing, which I do not. And to avoid outing yourself as a disingenuous prat, please admit that dual stack should never have been necessary for migration. And now we will never be rid of it. But being rid of you would be nice, if you are completely unable to admit the obvious and insist on defending the indefensible, an intellectual crime.
When all you have is a hammer, every problem starts to look like a thumb.
Just like every homeowner is expected to buy connectivity and addressing from their isp?
And when smartphones were new, a lot of people were reluctant to buy a cellular data plan because they were already buying connectivity from their home ISP. Some householders just don't want yet another perpetual utility bill, which means yet another company dipping into the family's checking account and potentially exposing said account to accidental or fraudulent withdrawals that cause overdrafts.
if you're content to use the same domain as thousands of others then there are many free options
You mean free dynamic DNS? One drawback of this has been that Let's Encrypt issues only 20 certificates per registrable domain per week. The dynamic DNS provider has to apply to Mozilla for inclusion on the Public Suffix List, which is administered on a Microsoft-run website. Some are unwilling, and last I checked, others' applications were in a months-long backlog.
and nothing to stop the isp from allocating a subdomain to their customers.
Of course there is: The major last mile ISPs have a business policy not to let home users run servers in the first place. I concede that ISPs have power to amend this policy, but you'd have to show ISPs a good case for amending this policy, as upgrades to more expensive business-class service make them money.
Plus there is always .local and llmnr/mdns if you don't need global reachability of your hostnames.
Neither Let's Encrypt nor any other trusted-by-default HTTPS certificate authority does .local. It violates the CAB Forum's Baseline Requirements.
So you at least agree that it exists, and neither of us have been able to come up with any better ways of doing it so it seems likely that it's about as good as it can get. I guess you can argue it's not good enough, but if it can't be made any better then you can't really criticize v6 for not making it any better. (Instead, criticize v4 for not allowing any better mechanism.)
I'd say that dual stack never was necessary. It has always been possible to remove v4 from your network; v6 doesn't force you to keep it. The fact that I'm running a single-stack v6 desktop right now, with access to v4-only sites, demonstrates that. It's just that it's the only real way to keep existing v4-only software and devices working, and if that's something that you care about then what better choice do you have? If you do in fact have a better option then I'm all ears, but I'm not sure what you could possibly do that would work with existing v4-only stuff.
464XLAT support in OSs would've been, and would still be, really damn useful for dealing with v4-only software, but that doesn't help v4-only devices.
neither of us have been able to come up with any better ways of doing it [more of the same blather]
You don't know that, but what both of us do know is that you are not willing to even try, the only question question is, what is the out-of-band reason why? Because your position is surely not based on any deep analysis, or if it is, then you suck at tech and should probably find another job. Sales maybe, or sanitation engineering.
When all you have is a hammer, every problem starts to look like a thumb.
Obviously, you deal with the IPv4 devices on your network just the same way as always, by talking strict IPv4 to them. You arrange things so that they ignore any packets with extended addresses, even running the bad old 32 bit stack. But with an updated stack, the additional address bits are recognized and routed. Note: this is *not* dual stack, it is "extended stack". This is what IPv6 should have been, but the genius ivory tower guys, politicians, and anti-nat Nazis had their way with it, leading predictably to the current fiasco.
When all you have is a hammer, every problem starts to look like a thumb.
I'm willing to try, and I have tried, but I very quickly hit the pidginhole principle and I can't think of any way around that other than the ways that we are already using. I've gone over other people's suggestions too, but they generally either don't work or they suffer from the same issues that v6 already suffers from.
And you're right, I don't know that you haven't come up with anything. I just don't get why you'd keep it to yourself if you had.
Ah, so you did have the start of an idea... but I'm not really seeing how it differs from dual stack. It looks like you're suggesting to have an unmodified v4 stack to handle talking to v4 hosts, plus an "extended v4" stack to handle talking to v6 hosts. Or perhaps you're suggesting combining them into the same piece of code, but even if you did that, so long as you're using two different addresses and are talking two different wire protocols then it's still effectively dual stack. Calling it something different doesn't help.
How does your suggestion let v6 hosts talk to v4 hosts? "By using v4", okay. How does it let v4 hosts talk to v6 hosts? I don't see a way of making that work that isn't "by using v6". And how do routers handle routing it? Again it seems to require that the router do v6. If there's a difference in the backwards compatibility afforded by this vs by dual stack, I'm having trouble seeing it. What's the difference that I'm missing?
Ah, so you did have the start of an idea
Fuck you. I have looked at it in detail, unlike you, and I am the not only one. When you have done at least some basic homework, get back to me. Your empty rhetoric in place of technical knowledge is just too irritating.
When all you have is a hammer, every problem starts to look like a thumb.
What I meant was, you didn't seem to have followed it through to the conclusion. It's easy to say "obviously you arrange things so that", but when you start trying to work out what the wire protocol will look like in order to do that, it seems to me that it's going to look very much like v6 already does. (If not, feel free to explain how you'd do it.)
We already followed IPv6 through to conclusion: dual stacks to the end of time. That is, in a word, failure. You conflate dual stack with extended protocol. These two things are not the same. If you think that they are, and you presume to waste internet bits with your ignorant spam about it, it just shows that you are too stupid to be entrusted with anything of importance. I hope that you are just an armchair asshole, and not an actual actor in this sad tale of software misengineering.
When all you have is a hammer, every problem starts to look like a thumb.