I've only worked at one company that had full IPv6 support. Even on my current 1GbE fibre setup with a small startup, they still don't have IPv6 rolled out to residents yet. :( I feel like one big hurdle is IPv6 usability. You can write down and easily remember IPv4 addresses. IPv6 netmasks can get really confusing. They make sense if you expand out every block, but in reality, IPv6 requires a lot of tooling to chop…
I love it when people make this argument. The IPv6 adoption hurdle is NOT the usability of v6 addresses. 99% of the world thinks that IPv4 addresses are a horrorshow and would never bother to memorize one or even write one down. They use DNS because they are human beings. The layout of the address behind the DNS they couldn't care less about.
A brief history of IPv4 address space exhaustion
71–80 of 89 posts
Re: A brief history of IPv4 address space exhaustion
#72Re: A brief history of IPv4 address space exhaustion
#73I find DJB's take on this interesting: https://cr.yp.to/djbdns/ipv6mess.html EDIT: Dan has many excellent points, but I'd like to quote my favorite: The IPv6 designers made a fundamental conceptual mistake: they designed the IPv6 address space as an alternative to the IPv4 address space, rather than an extension to the IPv4 address space. Indeed, what were they thinking! It's certainly an undeniable fact that IPv6 ad…
Re: A brief history of IPv4 address space exhaustion
#74Earlier quoted context omitted.
The main benefit of IPv6 is that it allows all endpoints to have a real IPv6 address, including the ones that don't have a real IPv4 address. It serves its purpose if it allows end user devices to directly communicate with each other even if cloud servers with real IPv4 addresses continue to use IPv4 until the end of time.
Wouldn't it be expected to have a firewall with "NAT" type rules anyways? Inbound blocked until an outbound flow is made? And UPnP seems to get around this right now anyways. At least, every NAT'd connection I'm on, when I run a Bittorrent client, I have no trouble getting inbound connections.
There are known solutions for this.
For host firewalls, the application can open a port for itself during installation.
For network firewalls, the firewall can implement Port Control Protocol (RFC6887), which supports opening even IPv6 ports.
> And UPnP seems to get around this right now anyways. At least, every NAT'd connection I'm on, when I run a Bittorrent client, I have no trouble getting inbound connections.
UPnP is a rubbish fire. The protocol itself is badly designed and unnecessarily complicated and many of the implementations are broken. Section 9 of RFC6886 is informative.
One of the common failure modes is that a client will create a port mapping with a random UPnP device that isn't the real gateway. Many applications will then falsely indicate that incoming connections are working but none ever come through.
And it's still sharing an IP address. Only one device can have the ssh port, or the SMTP port, or any other port.
IPv6 + Port Control Protocol fixes all of that.
Re: A brief history of IPv4 address space exhaustion
#75I find DJB's take on this interesting: https://cr.yp.to/djbdns/ipv6mess.html EDIT: Dan has many excellent points, but I'd like to quote my favorite: The IPv6 designers made a fundamental conceptual mistake: they designed the IPv6 address space as an alternative to the IPv4 address space, rather than an extension to the IPv4 address space. Indeed, what were they thinking! It's certainly an undeniable fact that IPv6 ad…
IPv10[0] makes IPv4 an extension of the IPv6 space. It'll be interesting to see if this takes off, but it doesn't really seem to solve the whole problem. All nodes in the path would have to support IPv10 for it to work. [0] https://datatracker.ietf.org/doc/draft-omar-ipv10/
There is neither "rough consensus" (besides that the author should have their posting privileges on the IETF lists removed) and certainly not any "running code". They've been trying to get IETF people to care about their harebrained "IPv10" scheme since November 2016; that they have yet to realise that their scheme is useless and that nobody seriously cares is about as depressing as seeing that internet-draft getting cited.
The term "crank" (https://en.wikipedia.org/wiki/Crank_(person)) is applicable here.
Re: A brief history of IPv4 address space exhaustion
#76Earlier quoted context omitted.
How much progress is simply due to mobile? Not a bad thing, but legacy ISPs seem to be updating at a glacial pace.
Comcast is one of the leaders in this space in the US. They are nearing 100% deployment and their X1 platform is supposed to run IPv6 only internally (SetTop Boxes to their content source). Verizon on the other hand hasn't done shit.
Re: A brief history of IPv4 address space exhaustion
#77Earlier quoted context omitted.
Your router has a firewall, external computers can't just send packets to the internal addresses. NAT is not a firewall.
So IPv6 firewall rules are common now for consumer routers?
My mum's boring broadband connection, with a free router supplied by the ISP in the UK, has the functionality next to the port forwarding settings for IPv4.
That's typical. Look up IPv6 pinhole to see how ISPs document it.
Re: A brief history of IPv4 address space exhaustion
#78Earlier quoted context omitted.
IPv10[0] makes IPv4 an extension of the IPv6 space. It'll be interesting to see if this takes off, but it doesn't really seem to solve the whole problem. All nodes in the path would have to support IPv10 for it to work. [0] https://datatracker.ietf.org/doc/draft-omar-ipv10/
The internet-draft you linked is not a proposal that anyone should take seriously. Here is an actual, non-mocking review of that I-D: https://www.ietf.org/mail-archive/web/int-area/current/msg05... . To put it diplomatically, that author does not seem to have a proper understanding of IPv6 deployment nor of any relevant prior art. There is neither "rough consensus" (besides that the author should have their posting p…
- Understands that the proposal requires that "anything [that] will process a L3 packet" be upgraded to understand the new packet format, but seems to believe it's a simple matter of making the OS developers (which are "few") "push new updates globally".
- Seems to believe having the proposal ratified by the IETF is both necessary and sufficient for the proposal to be adopted everywhere.
Edit: the author is now requesting that the internet-draft be removed from the database: https://www.ietf.org/mail-archive/web/ietf/current/msg103018...
Re: A brief history of IPv4 address space exhaustion
#79Earlier quoted context omitted.
So IPv6 firewall rules are common now for consumer routers?
Yes. My mum's boring broadband connection, with a free router supplied by the ISP in the UK, has the functionality next to the port forwarding settings for IPv4. That's typical. Look up IPv6 pinhole to see how ISPs document it.
But I wonder, is it a fair assumption that the router that you get will either 1) not route IPv6 at all, or 2) route IPv6, and by default deny incoming traffic? Problematic would be ones that routed IPv6, and by default accepted incoming traffic.
Re: A brief history of IPv4 address space exhaustion
#80Earlier quoted context omitted.
IPv10[0] makes IPv4 an extension of the IPv6 space. It'll be interesting to see if this takes off, but it doesn't really seem to solve the whole problem. All nodes in the path would have to support IPv10 for it to work. [0] https://datatracker.ietf.org/doc/draft-omar-ipv10/
The internet-draft you linked is not a proposal that anyone should take seriously. Here is an actual, non-mocking review of that I-D: https://www.ietf.org/mail-archive/web/int-area/current/msg05... . To put it diplomatically, that author does not seem to have a proper understanding of IPv6 deployment nor of any relevant prior art. There is neither "rough consensus" (besides that the author should have their posting p…
Some parts of it are laughable such as
IPv10 support on "all" Internet connected hosts can be deployed
in a very short time by technology companies developing OSs
(for hosts and networking devices, and there will be no
dependence on enterprise users and it is just a software
development process in the NIC cards of all hosts to allow
encapsulating both IPv4 and IPv6 in the same IP packet header.
But it does have an interesting take on stateless IPv4 IPv6 communication, specifically IPv4 -> IPv6. Obviously it wouldn't work as described without a full deployment, but it seems like something could be done there.For instance, if an IPv4-only host wanted to communicate to an IPv6-only host, it could send packets to a well-known NAT46 anycast address with an IP option of the destination host. The NAT46 host could then create the IPv6 packet with the correct destination and IPv4-mapped source.
He suggested using the IPv4 routing table for IPv4-mapped IPv6 addresses, which wouldn't be loop-free unless every router was dual stack and did the same thing. However, with what I described, it seems like any dual-stack host (or router) could perform the translation in a loop-free manner.