Huh? No, the MAC was never a part of the publicly-visible v6 address.
I know you're talking about SLAAC, but SLAAC is just a convenient way of picking a unique address. Changing the address wouldn't result in e.g. the packet being sent to a different MAC. Even sending packets to link-local addresses still does NDP, rather than parse the MAC out of the address.
The 64/64-bit split was in fact a result of (then planned) Bluetooth having 64 bit MACs. Moreover, the initial IPv6 RFCs did not have privacy extensions for SLAAC: https://www.rfc-editor.org/info/rfc2464/#section-4
> Even sending packets to link-local addresses still does NDP, rather than parse the MAC out of the address.
Broadly it's true that historically there was this idea for ethernet networks at least. It was always optional though. Even in that long obsolete rfc2464 it's described as the way to do SLAAC which was optional even in 1998.
This kind of thing doesn't normally count as violation of layering though. In protocol design its common to leverage identifiers from lower layers for addressing. For example many workings of the internet would be hard to imaging with the rule that you could not use IP addresses and ports in upper level protocols (like DNS, P2P protocols, etc)
The early RFCs were written more informally, so it's hard to say what was optional. However, the consensus was that SLAAC was supposed to be the main way to configure IPv6, along with fully manual configuration.
> In protocol design its common to leverage identifiers from lower layers for addressing.
Yes, that's why my email has the IP address of the mail server. And why my WhatsUp contains the IMEI of my phone.
Notice how a) it's doing NDP, and b) the link-local is fe80::506c:e9ff:fe08:9ba3 while the MAC is 00:23:6e:5b:b8:2b? The "506c:e9ff:fe08:9ba3" part of the address isn't being treated as a MAC address by the protocol -- it's just some opaque bytes.
Yes, those bytes can be picked by looking at a MAC address, but that's only one way to pick them and the protocol doesn't treat those bytes as having any particular significance, and in particular it never assumes they contain a MAC or tries to use them as an actual MAC, so it doesn't qualify as a layering violation.
Get me onto the network that's on the WAN interface of your router, disable the firewall on it, and I will.
How do you want to go about doing this? Although, 100% of the time people have asked me to do this they chicken out at actually doing it, so I suppose you will too. You might prefer to test with some network namespaces instead.
We believe that it is not possible to have a "flag-day" form of
transition in which all hosts and routers must change over at
once. The size, complexity, and distributed administration of the
Internet make such a cutover impossible.
IPng is a new version of IP which is designed to be an evolutionary step
from IPv4. It is a natural increment to IPv4. It can be installed as a
normal software upgrade in internet devices and is interoperable with
the current IPv4. Its deployment strategy was designed to not have any
"flag" days.
If saying "we can't have/didn't do a flag day" in the design documents, and then not having a flag day, isn't enough to stop you from arguing that v6 should have been engineered without a flag day, I have to wonder what v6 could possibly have done to make you happy with it.
NAT is accepted for transition purposes; for example NAT64 makes it trivial to connect from v6-only clients to v4 servers, and is used by some large ISPs (e.g. T-Mobile in the US) to avoid running v4 inside their access network.
But v6 _is_ backwards compatible though? It's got dual stack, Teredo, 6to4, 6rd, 6over4, ISATAP, 6in4/4in6, NAT64/DNS64, 464xlat, DS-lite, MAP-T/E, 4rd, LW4over6... how is this not backwards compatible? You could make a reasonable argument that it has too many backwards compatibility methods, even.
> The “you don’t have to use NAT anymore” is great theoretically, but it renders a lot of casual network maintainers mental model of network security obsolete without a clear and simple alternative
If your mental model of security relies on NAT then your mental model was wrong, and obsoleting it was the right thing to do.
If v6 made you realize this, then it seems it's more intuitive than v4+NAT was for you.
All you've done there is reinvent v6 with a combination of dual stack, NAT64 and 6to4, plus add a flag day.
You haven't fixed any of the problems involved in deploying v6, and you added a step that was known 35 years ago to be impossible on the Internet. This isn't a useful contribution, it's just a waste of time that you could have spent on doing v6.
That's basically no burden at all. If we cut the address length down to increase throughput, we would get a one-time increase of about 0.8% -- but consider how much faster Internet connections have gotten over the past 30 years. They've improved by about 0.8% per week on average. You're worrying about something that's smaller than one or two weeks of natural progress in Internet connection speeds
Rather than trying to minmax the address length, it makes more sense to sacrifice a few bits per packet to the addresses, wait a week or two on average to get the lost throughput back, and then spend those bits elsewhere to make other things easier. (For example, avoiding NAT is an obvious one, but even just "everything is a /64" removes the need to ever need to think about the size of a network.)
If you can spend a few address bits to make something easier elsewhere, that's a good trade. Maybe start worrying if the addresses were a kilobit long or something, but they aren't even close to that.
People are at work during the week, and work networks have a lower average deployment of v6 then home networks do. As evidence, you can also see the impact of holidays and COVID-19 lockdowns on the size of the dips.
If we're talking tangible, real-world threats in existing ISPs, then NAT is doing nothing to protect you. In fact it's doing the exact opposite, because without NAT you wouldn't be able to connect out from your network.
Even if you want to ignore the fact that most attacks arrive via outbound connections and restrict the discussion to just inbound ones... remove NAT and the exact same set of people that could connect to you before can still connect to you, so it's doing nothing for your inbound connections.
I know you're talking about SLAAC, but SLAAC is just a convenient way of picking a unique address. Changing the address wouldn't result in e.g. the packet being sent to a different MAC. Even sending packets to link-local addresses still does NDP, rather than parse the MAC out of the address.
reply