Bottomley: Creating a home IPv6 network
One of the things you’d think from the above is that IPv6 always auto configures and, while it is true that if you simply plug your laptop into the ethernet port of a cable modem it will just automatically configure, most people have a more complex home setup involving a router, which needs some special coaxing before it will work. That means you need to obtain additional features from your ISP using special DHCPv6 requests."
Posted Sep 19, 2020 9:17 UTC (Sat)
by dottedmag (subscriber, #18590)
[Link]
Posted Sep 19, 2020 10:43 UTC (Sat)
by istenrot (subscriber, #69564)
[Link] (43 responses)
Posted Sep 19, 2020 11:14 UTC (Sat)
by leromarinvit (subscriber, #56850)
[Link] (35 responses)
Is there any technical limitation preventing one from creating a subnet smaller than /64, or is that just a convention? 64 bits would be way more than enough for even the least efficient subnetting scheme I can think of for anything resembling a home network.
Posted Sep 19, 2020 11:20 UTC (Sat)
by mpr22 (subscriber, #60784)
[Link] (30 responses)
There might be something else, of course.
Posted Sep 19, 2020 12:06 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (1 responses)
I think that's the conspiracy theorists getting paranoid ...
Of course it depends on the number of computers on your local network, but even if you use your local long pid as part of your local address, that's still 4 billion computers on the local net before you run out of addresses.
Isn't 2^64 thought to be more than the number of grains in the Sahara, or stars in the Universe?
Anyway, how is that supposed to work for a *server*, as opposed to a client, which *needs* to be found or there's no point having it ...
Cheers,
Posted Sep 19, 2020 14:27 UTC (Sat)
by nix (subscriber, #2304)
[Link]
Downside: pain for routers. A lot of pain for RBLs (though, as with DNS, RBL for IPv6 remains a bit of a mess...)
Posted Sep 19, 2020 22:22 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Sep 20, 2020 1:51 UTC (Sun)
by gerdesj (subscriber, #5446)
[Link] (26 responses)
We should be able to come up with a way of ditching letters. Heck, "thorne" was kicked out and we are all the better for it. However, now we have hoards of people who think that the first word in "Ye olde ... " is pronounced "ye" and not "the" or "thee". Of course, I didn't put a real letter thorne in my example, I simply hit Y. I think thorne should be rehabilitated because the various varieties of sounds similar to th, f, v etc do actually sound a bit different to each other and do have an effect. That grouping of sounds is quite important in english and could do with some reinforcements and perhaps a return of an old ally.
Sorry - IPv6:
The original address space design is all fine for me. The reasoning for 128 bit addresses: Make it vast and ensure everyone can do what they want. Give end users a /48 and they can have 256 sites with 256 networks each. It doesn't matter if they use them, they have the option. There are quite a few /48s and yet ...
That seems to have turned into: OK let the plebs have a /56 that's still 16x16 or 1x256. ... lol, let's give the little shits a /64 and let's fuck it up properly and get them to waste hours on trying to subnet a /64. For hilarity, lets change the prefix at odd times and fuck up your network. That last scenario (/64) is quite rare here but does happen.
IPv6 address space is vast so it would make sense to dole out a /48 and say an additional /64 or smaller for the ptp link. That way you can do IPSEC with a single P2, then you use your firewall to do the hard work of worrying about what can speak to what. My ISP - ENTANET (UK) has decided that the ptp link isn't worth worrying about and have ditched them. So my WAN only has a link local address. I am looking for another ISP.
Multi WAN. If you don't have your own private address space (lots of loot) and a BGB peering arrangement in place then you can whistle. You then have network prefix translation or NAT by a different name. Of course the PI thing means routing table fragmentation which buggers up those nice aggregations.
Change ISP. When you change ISP all your addresses change. Yes there is ULA. I've dropped it as a solution for this because that's not what ULA is useful for. I have opted for documentation and change planning instead.
IPv6 is not perfect. It does fix a lot of snags. It is grossly misunderstood, mainly by people who have not deployed it. It does have some shortcomings. On the whole I actually prefer it.
Roll on IPvX.
Posted Sep 20, 2020 4:55 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link] (22 responses)
The raw IP should be treated as an ephemeral transport that more-of-less follows the topology of the underlying physical network, and protocols on top of it do failover and multi-homing. LISP was an interesting idea, but it's going nowhere fast. Multipath TCP is another good attempt and it seems to be gaining traction.
Posted Sep 20, 2020 9:32 UTC (Sun)
by jem (subscriber, #24231)
[Link] (21 responses)
Posted Sep 20, 2020 11:00 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link] (20 responses)
> Or IPv6 in general?
IPv6 has a Rube-Goldberg machine with on-link prefix discovery, through multicast.
> This is essentially the same mechanism as the Type header in an Ethernet frame. In IPv4 you need to guess if the packet contains options by first looking at the header length, and that does not tell anything about what those options are.
Top-of-the-line routers and load balancers these days can do hundreds of gigabits per second, meaning that the router has only a few nanoseconds to process a packet. Even with multi-queue systems we are still looking at maybe hundreds of CPU (or whatever network processor) cycles. Just for reference, light travels around 20 centimeters in copper in 1 nanonsecond.
And it's not like extension headers are used for obscure purposes. They are needed for packet fragmentation and reassembly. So it's no wonder that quite a few routers simply drop packets with IPv6 extension headers. https://www.potaroo.net/ispcol/2020-06/m6w.html has more on this.
As a result, fragmentation and PMTU in IPv6 is a whole stinking mess, even worse than in IPv4.
Posted Sep 20, 2020 13:46 UTC (Sun)
by jem (subscriber, #24231)
[Link] (15 responses)
So why is there a Header Length (IHL) field in the IPv4 header? Oh, maybe you mean the 99.9 % of IP packets on the net that don't have options and thus have a fixed size header? If you look at it this way, IPv6 TCP headers have a fixed offset too. The difference is that the IPv4 Protocol header field has been replaced with the Next Header field. The Next Header field can contain an ID for the first extension header, or, if there is no extension (the 99.9 % case) it contains the ID of the upper layer protocol in the payload (6 for TCP).
I don't understand why you see this as an inferior mechanism in comparison to IPv4, where you first have to check the header length to see if there are options to begin with.
>My personal pet peeve are on-link prefixes. IPv4 has a rather simple approach with subnetting and broadcasting, that is intuitive and translates well into hardware.
IPv6 isn't that different. You have a subnet which divides the addresses into a upper network part and a lower host part. Multicasting is used instead of broadcasting, which has the advantage of not disturbing hosts with broadcast packets they have no interest in.
Try telling people on a Cisco Networking Basics course about the simplicity of IPv4. Half of the course deals with calculating subnets, converting addresses and netmasks from decimal to binary to check if an address belongs to a subnet or not, or how to divide subnets into sub-subnets of different sizes. A *beginner* on an IPv6 network course only needs to know the upper 64 bits are the network part.
I think the biggest hurdle to IPv6 adoption really is fear of change. The arguments against IPv6 remind me of the type of arguments people use against battery electrical vehicles.
IPv6 does work, and a lot of people are using it today without even knowing that they do. My IPv6 internt connection really was plug and play: connect the wires, turn on power and go. All PCs, phones and tablets picked up an IPv6 address and started using it from day one. My smart TV does not support IPv6, so it uses IPv4 instead with no problem.
>Just for reference, light travels around 20 centimeters in copper in 1 nanonsecond.
Copper is that quick? 33 per cent faster than light in vacuum? :)
Posted Sep 20, 2020 14:12 UTC (Sun)
by Wol (subscriber, #4433)
[Link] (1 responses)
And yes I know the actual speed is affected by the permittivity of the material. I know sound travels faster through solids than air, I'm not surprised that it's different different in copper, but does light really travel *through* copper? :-)
Cheers,
Posted Sep 20, 2020 23:55 UTC (Sun)
by gerdesj (subscriber, #5446)
[Link]
Of course not, quantums do that ... or is it holes going backwards? Can't remember.
Posted Sep 20, 2020 18:42 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link] (12 responses)
> Oh, maybe you mean the 99.9 % of IP packets on the net that don't have options and thus have a fixed size header?
> I don't understand why you see this as an inferior mechanism in comparison to IPv4, where you first have to check the header length to see if there are options to begin with.
> IPv6 isn't that different. You have a subnet which divides the addresses into a upper network part and a lower host part.
> Multicasting is used instead of broadcasting, which has the advantage of not disturbing hosts with broadcast packets they have no interest in.
> Try telling people on a Cisco Networking Basics course about the simplicity of IPv4. Half of the course deals with calculating subnets, converting addresses and netmasks from decimal to binary to check if an address belongs to a subnet or not, or how to divide subnets into sub-subnets of different sizes. A *beginner* on an IPv6 network course only needs to know the upper 64 bits are the network part.
> I think the biggest hurdle to IPv6 adoption really is fear of change. The arguments against IPv6 remind me of the type of arguments people use against battery electrical vehicles.
> My IPv6 internt connection really was plug and play
> Copper is that quick? 33 per cent faster than light in vacuum? :)
Posted Sep 20, 2020 19:36 UTC (Sun)
by jem (subscriber, #24231)
[Link] (11 responses)
You keep saying this, but provide no explanation to why the IPv6 design is much worse. Or why it is a dumb design in the first place, and what would be a better design.
>IPv6 allows mixed-sized networks on the same link. With various interesting interactions. Nobody uses that, but it's supported.
Everybody uses that. Link-local is fe80::/10. What are the "interesting interactions"?
>And this makes simple discovery protocols to become much more complicated and involved, even though they use the same broadcast in the end (Ethernet has no native multicasting!).
Again, you do not substantiate how the protocols become much more complicated and involved. This smells like FUD. And Ethernet does have native multicast. Unless you have a shitty network card, the card does its best to filter out multicast packets the host has not subscribed to, at the card level.
>You have to do all the same subneting stuff for IPv6, even on the beginner level (to explain how prefixes work).
All a beginner needs to know is the 64+64 split. My point was that learning to administer IPv4 networking is much more difficult.
>It's really not. IPv6 turned out to be inferior to IPv4 in operational issues,
Here we go again...
> and it doesn't provide anything terribly important for users.
How about a working Internet for all current and future users? The net keeps growing and is quickly outgrowing itself. There is a limit on how much IPv4 NAT can help alleviate the problems, and looking at how much IPv6 has been deployed worldwide already, one can ask whether the Internet at the current scale would even be possible without it.
Posted Sep 20, 2020 20:03 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link] (10 responses)
In IPv6 you have to read the next header, jump to that header, parse it, get the next next header. Possibly many times, as there are no recursion limits.
> Everybody uses that. Link-local is fe80::/10. What are the "interesting interactions"?
Can you honestly tell without looking into Wiki how on-link cache works? Can you honestly tell that it's easier or better than a fixed subnet in IPv4? Do you know what tools can be used to examine that cache? What about negative cache entries? What happens if they overflow?
If you still think you know how it works, here's another question: why does a host _have_ to listen to RA messages if it's using DHCPv6? And what would it do with to its battery life?
I personally implemented an IPv6 stack for a low-RAM battery-powered device so I know for sure that it's WAY more complicated than IPv4. Doubly so if you want to make it robust and efficient.
> All a beginner needs to know is the 64+64 split. My point was that learning to administer IPv4 networking is much more difficult.
> How about a working Internet for all current and future users? The net keeps growing and is quickly outgrowing itself. There is a limit on how much IPv4 NAT can help alleviate the problems
Don't get me wrong, I think that IPv6 is needed to avoid at least some of the bogosity of CGNAT. But it doesn't change my opinion that IPv6 is a pig that needs a lot of thrust to fly.
Posted Sep 21, 2020 5:54 UTC (Mon)
by jem (subscriber, #24231)
[Link] (9 responses)
Ok, I get your point. But then the TCP headers are not at a fixed address after all, like you said earlier. Your ASIC will have to read the header length and add it to the start of the packet. Then you will also have to read the Type header field to check that the payload is TCP. Or at least the hardware has to check that both fields contain the common values (no options, type TCP).
>In IPv6 you have to read the next header, jump to that header, parse it, get the next next header. Possibly many times, as there are no recursion limits.
The fast path is: check the Next Header to see if it contains the value 6 (TCP). If it does, you'll find the TCP header at a true constant offset. If the packet contains extension headers i guess you will probably have to do some extra processing anyway.
>NAT effectively multiplies the IPv4 address space by about 100x. So there is no practical limit on the number of IPv4 users. All it does is breaking end-to-end connectivity, but this is not a big problem anymore.
Even if you can multiply the address space by 100, are you sure NAT overall can scale that far? T-Mobile opted for IPv6-only in the handset, combined with 464XLAT. They are now on a path to a future that is only getting better as more services are available directly over IPv6, like Google (including YouTube), Facebook, Netflix, etc.
And why is breaking end-to-end connectivity not a problem anymore? The demand for public addresses has gone up because everybody wants to move to the cloud. RFC 1918 addresses can only go that far, which made Facebook switch to IPv6 for their internal network.
Posted Sep 21, 2020 6:16 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (8 responses)
> The fast path is: check the Next Header to see if it contains the value 6 (TCP).
> Even if you can multiply the address space by 100, are you sure NAT overall can scale that far?
> T-Mobile opted for IPv6-only in the handset, combined with 464XLAT. They are now on a path to a future that is only getting better as more services are available directly over IPv6, like Google (including YouTube), Facebook, Netflix, etc.
> And why is breaking end-to-end connectivity not a problem anymore? The demand for public addresses has gone up because everybody wants to move to the cloud. RFC 1918 addresses can only go that far, which made Facebook switch to IPv6 for their internal network.
Mind you, I would love to switch everything to IPv6. I make sure that all my applications support it. I just don't see it happening any time soon (i.e. the next 10 years).
While a lot of this is due to inertia and probably would have happened with any successor of IPv4, the general awfulness of IPv6 certainly doesn't help a bit.
Posted Sep 21, 2020 9:44 UTC (Mon)
by farnz (subscriber, #17727)
[Link] (7 responses)
A core router should not be looking at the packet contents anyway, so would not be looking at the Next Header/Type field to begin with. In a load balancer setup, you'd do what you do in IPv4 and drop all packets with extension headers/options, because they're not relevant - IPv6 did at least make a lot of effort to ensure that "drop all packets with extension headers" is a reasonable default behaviour for all devices.
And 464XLAT does save quite a bit in hardware cost on modern fast networks; it moves some heavy data consumers (Netflix, YouTube) into stateless routing instead of NAT. Hotspot from my phone on EE uses IPv6 as a result to save hardware costs at the network end; they've not bothered doing separate hotspots because the total usage of hotspot devices (as opposed to phones and hotspots from phones) is so low that the hardware savings are outweighed by support costs.
I do agree that IPv6 suffers from second-system syndrome; however, it also suffers from being designed before the dot-com boom, and failed to take three important changes (that happened after it was designed!) into account (ordered below from least important to most important):
Posted Sep 21, 2020 16:35 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (6 responses)
> And 464XLAT does save quite a bit in hardware cost on modern fast networks; it moves some heavy data consumers (Netflix, YouTube) into stateless routing instead of NAT.
> Hotspot from my phone on EE uses IPv6 as a result to save hardware costs at the network end; they've not bothered doing separate hotspots because the total usage of hotspot devices (as opposed to phones and hotspots from phones) is so low that the hardware savings are outweighed by support costs.
Posted Sep 21, 2020 17:14 UTC (Mon)
by farnz (subscriber, #17727)
[Link] (5 responses)
> > And 464XLAT does save quite a bit in hardware cost on modern fast networks; it moves some heavy data consumers (Netflix, YouTube) into stateless routing instead of NAT.
> > Hotspot from my phone on EE uses IPv6 as a result to save hardware costs at the network end; they've not bothered doing separate hotspots because the total usage of hotspot devices (as opposed to phones and hotspots from phones) is so low that the hardware savings are outweighed by support costs.
Posted Sep 21, 2020 17:40 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (4 responses)
> Because those heavy data consumers are IPv6-enabled already, so they require zero NAT state, just stateless IPv6 routing. You only need NAT state for things that go to IPv4, not for IPv6 enabled services.
Once it's installed, the financial pressure to move to IPv6 is basically gone.
The main advantage for T-Mobile was improving the internal network management, because they were running out of private (and squatted) IPv4 space. But this is not an issue for smaller ISPs.
> I'm surprised - my contacts at EE tell me that they've cloned their setup from their colleagues at T-Mobile USA; they haven't yet been able to IPv6 enable iPhone hotspots because of issues relating to routing from WiFi/USB to cell, but it's in progress with Apple helping them work out what's going wrong and where, so that it can be fixed.
Posted Sep 21, 2020 18:14 UTC (Mon)
by farnz (subscriber, #17727)
[Link] (3 responses)
Sure, but emergent behaviour is what we see in IPv4 as well - e.g. the lack of use of IPv4 options is for the same reasons, as they were definitely meant to be used, too. And the IPv6 designers did do a reasonable amount of work to ensure that routers etc didn't need to worry about extension headers - e.g. fragmentation is an endpoint thing only, not a router thing. While I don't think they did enough, it's clear that they were thinking in terms of avoiding the need for routers to comprehend more than the fixed header.
Also, while that's $20 (because you need a HA pair for mobile network use) per customer, the box is still 10x more expensive than a plain IPv6 router that has no connection count limit, and a much higher throughput; when you can reduce the number of CGNAT boxes by 50% because the high volume traffic is gone, you save a lot of money. Maybe not on a small network where 10,000 is a lot of customers, but it's a big saving on larger networks.
And on my Google Pixel 2, hotspot traffic doesn't go through NAT on the phone device for IPv6 - there's a /64 assigned to my handset, it takes one address (which it uses on the cell interface), and the rest of the /64 is used for other devices on the hotspot. This is still a single IPv6 circuit so doesn't require its own EPS bearer (which is what doubles the costs), but it means I have real IPv6 while tethered, and 464XLAT on the phone (using NAT) for IPv4.
Posted Sep 21, 2020 19:32 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
> the box is still 10x more expensive than a plain IPv6 router that has no connection count limit, and a much higher throughput; when you can reduce the number of CGNAT boxes by 50% because the high volume traffic is gone, you save a lot of money. Maybe not on a small network where 10,000 is a lot of customers, but it's a big saving on larger networks.
This really is a painful problem and right now IPv6 is a net financial loss, not gain. This is reflected in world-wide IPv6 deployment patterns, with poor countries not getting it (they can't afford additional operational expense).
> And on my Google Pixel 2, hotspot traffic doesn't go through NAT on the phone device for IPv6 - there's a /64 assigned to my handset, it takes one address (which it uses on the cell interface), and the rest of the /64 is used for other devices on the hotspot.
Posted Sep 22, 2020 10:32 UTC (Tue)
by farnz (subscriber, #17727)
[Link] (1 responses)
So, having had a chance to chat to my network contact, he broadly agrees with you on IPv6 on the Internet side, but says that the real driver of IPv6 and 464XLAT is not Internet data - it's VoLTE. For poorer countries, he suggests that the newer network kit that's just entering the second-hand market is going to drive IPv6 on mobile there.
Firstly, VoLTE is not reliable if the VoLTE network is IPv4 only - it has to be an IPv6 network using globally unique addresses (i.e. from your RIR assignment) to work reliably. Reliable VoLTE roaming has driven up call durations on charged roaming destinations (thus more revenue for those operators). However, this implies that you're running IPv6 network-wide for VoLTE; as the marketing blurb for your CGNAT box points out, modern CGNAT boxes are as good at NAT64 as they are at NAT64, so you can reduce your operational costs by running an IPv6-only network, rather than having an IPv4 network for data traffic and an IPv6 network for voice.
Secondly, they're now seeing cheap kit on the market that, instead of having an ATM interface (whether real, or emulated over Ethernet) for 2G/3G voice, handles 2G/3G voice by translating it to IMS voice (using IPv6) over the Ethernet it already has for 4G. So, if you set up an IPv6 network for VoLTE, you get 2G/3G voice moved off legacy ATM onto your VoLTE network.
Put those two together, and you've got a powerful opex reduction case for a poor country - when you add 4G and VoLTE for whatever reason (whether to take advantage of the cheap handsets built for Reliance Jio, or because it gives you a marketing point, or just to pick up some sweet roaming revenue), you can switch to an all-IPv6 Ethernet backbone, remove a lot of power-hungry legacy kit relating to old 2G and ATM networks, and then do IPv6 and 464XLAT because it's cheaper than maintaining an IPv6 network *and* an IPv4 network.
From EE's point of view (rich country), the reason to do IPv6 on the cellular network was two-fold:
Posted Sep 22, 2020 19:35 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link]
And it also appears that large networks have a motivation to move to IPv6 simply because there's not enough space in IPv4 for them. I wonder if "market consolidation" in the ISP area is what will finally push IPv6 over the hump.
Posted Sep 20, 2020 16:30 UTC (Sun)
by ebiederm (subscriber, #35028)
[Link] (3 responses)
Which means given a reasonable quality of implementation you don't need to read into the IPv6 header to do load balancing in a router.
Posted Sep 20, 2020 18:57 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
Along with priority and class fields they basically just uselessly waste 28 bits in every packet. There are multiple RFCs looking at WTF we are going to do with these fields that are just here right now.
Posted Sep 21, 2020 17:18 UTC (Mon)
by zlynx (guest, #2285)
[Link] (1 responses)
It's really the same problem you have load balancing TLS encrypted HTTP/2 where instead of multiple connections you have everything in a single TCP flow. There's no visibility unless the load balancer is also doing the TLS termination and handling the HTTP/2 multiplexing.
If users are going to do it wrong then make them suffer. It's not as if we'd let people get away with using random UDP source ports, so don't let them get away with any other broken thing.
Allowing people to ignore a feature or refusing to use it because it might break something, somewhere, is what made ECN take so long to roll out. Oh no! Some firewall box somewhere in Ethiopia is blocking "evil bits" whatever shall we do?
Don't make it possible to even use the Internet if people firewall block ICMP either. Break it. Break it all.
Posted Sep 21, 2020 17:22 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link]
> Don't make it possible to even use the Internet if people firewall block ICMP either. Break it. Break it all.
Posted Sep 20, 2020 14:16 UTC (Sun)
by Wol (subscriber, #4433)
[Link]
:-) :-)
What letter would you use to represent the last consonant of the word "lake"? Or was that "loch"? Or "lough"? How many other variations of the word "lake", with variations in pronounciation, do we have?
That's the problem with Mark Twain's prescription - he obviously never heard of dialects :-)
Cheers,
Posted Sep 21, 2020 20:39 UTC (Mon)
by eduperez (guest, #11232)
[Link] (1 responses)
There is absolutely no reason not to issue at least a /60 (or larger) to home users, but I fear that ignorance and greed will prevail.
Posted Sep 21, 2020 20:58 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Sep 19, 2020 17:13 UTC (Sat)
by khim (subscriber, #9252)
[Link] (3 responses)
We are in classfull networks era of IPv6. To reduce complexity of ASICs only first 64 bits are used in routing protocols in "big", carrier-grade hardware.
But there are no technical reasons which make it impossible for you to use smaller subnets on "small" networks, where routing is fully implemented in software...
Posted Sep 19, 2020 21:03 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (2 responses)
Cheers,
Posted Sep 22, 2020 23:20 UTC (Tue)
by Vipketsh (guest, #134480)
[Link] (1 responses)
IPv6 hosts (not routers) don't have a routing table in the IPv4 sense with prefixes and netmasks (i.e. subnets). The way IPv6 works is that when you want to send a packet to an address (the full 128-bit) you ask your local router where to send it. That router may tell you to send it to itself, to some other router, or that the address is on-link and you can send it directly (after discovering its link-layer address). The host then caches the destination and next-hop address pairs (both full 128-bit addresses).
To optimise all these lookups the router may tell you that entire prefixes are on-link, but those don't have to be /64 bit at all. To make everything more complicated these prefixes and any other information you are given may be revoked at any time by the router.
The auto-configuration prefix (the /64 prefix you use to create a unique address for yourself) doesn't have to be advertised as an on-link prefix.
IPv6 doesn't touch on how these routers get their information to tell you what to do. I'm sure there are rfc's dealing with how these routers should work in the context of the internet to get efficient prefix aggregations and other nice properties, but none of that is mandated by the protocol itself.
Posted Sep 23, 2020 6:25 UTC (Wed)
by jem (subscriber, #24231)
[Link]
IPv6 has a lot more in common with IPv4 than you think. IPv6 hosts do have a routing table, you do not ask the local router for every packet where to send it. Instead, the host consults the routing table, just like with IPv4. The mechanisms for setting up the routing table and discovering the router(s) and neighboring hosts is different.
There may not be such a thing as a "network address", but was that ever a thing in IPv4 either, other for documentation purposes?
>IPv6 doesn't touch on how these routers get their information to tell you what to do. I'm sure there are rfc's dealing with how these routers should work in the context of the internet to get efficient prefix aggregations and other nice properties, but none of that is mandated by the protocol itself.
Neither does the IPv4 *protocol* itself, but there are RFCs dealing with all that...
Posted Sep 20, 2020 8:18 UTC (Sun)
by tudor2k3 (guest, #76089)
[Link] (2 responses)
Posted Sep 20, 2020 8:47 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Moreover, some hardware routers won't even _allow_ you to use smaller subnets because they use only the first /64 (or even /48) of the address to look up the route.
Posted Sep 20, 2020 8:52 UTC (Sun)
by jem (subscriber, #24231)
[Link]
Posted Sep 28, 2020 20:00 UTC (Mon)
by tudor2k3 (guest, #76089)
[Link] (2 responses)
Posted Sep 28, 2020 20:30 UTC (Mon)
by zdzichu (subscriber, #17118)
[Link]
Posted Sep 29, 2020 6:16 UTC (Tue)
by jem (subscriber, #24231)
[Link]
Obviously he/she is not going to use 264 addresses, but more than one subnet. An IPv6 subnet cannot easily be smaller than /64, as has been pointed out several times in these comments, and also in Bottomley's original article.
Posted Oct 7, 2020 19:14 UTC (Wed)
by scientes (guest, #83068)
[Link]
After experiences with only getting one ipv6 address, I would be happy with /112. The real issue is that ipv6 is STILL considered optional, like right now I am connected by LTE and have no ipv6 address AND am behind a NAT.
Posted Sep 19, 2020 13:14 UTC (Sat)
by abo (subscriber, #77288)
[Link] (20 responses)
Given an upstream ISP which enables DHCPv6-PD (which seem to be the only redeeming property of Comcast) then the router can be completely autoconfigured. Acquire an address, acquire a prefix, set up route to LAN interfaces. If the router in turn implements DHCPv6-PD (and upstream provides a short enough prefix) then even a network with multiple cascading routers can set itself up without any manual steps.
I'm not sure what kind of default firewall policy would be best, though. Connection tracking, block incoming connections? That would again require a separate service for two IPv6 enabled hosts to contact each other.
Posted Sep 19, 2020 14:26 UTC (Sat)
by Lennie (subscriber, #49641)
[Link] (3 responses)
How about default blocked incoming with top part of the port range opened up:
https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_nu...
Posted Sep 19, 2020 18:11 UTC (Sat)
by abo (subscriber, #77288)
[Link] (1 responses)
Excluding incoming connections to "guessable" addresses may mitigate that though, while still allowing communication using ephemeral private addresses.
Posted Sep 22, 2020 14:17 UTC (Tue)
by Lennie (subscriber, #49641)
[Link]
The alternatives would be: default closed or default open for IPv6.
I personally am not convinced default open is a good solution for IPv6. My suggestion is a safe default.
And default closed for incoming connection means IPv6 doesn't have no end to end connectivity at all by default which is one of the advantages IPv6 could give us which it wouldn't have anymore.
A port range open high up in the port range I think would only gives us: happy surprises because it would mean some things 'just work', nothing fancy to do.
Posted Sep 21, 2020 16:20 UTC (Mon)
by raven667 (subscriber, #5198)
[Link]
Posted Sep 19, 2020 18:09 UTC (Sat)
by marcH (subscriber, #57642)
[Link] (4 responses)
Exactly: this very long blog will be useful if you have a complex network too or run into problems but otherwise it really gives the wrong impression. With Comcast and OpenWRT, IPv6 Just Worked for me with _absolutely zero change_ to the default configuration and it has let me do NAT-free calls for years. The default IPv6 firewalling rules have of course already been duplicated from IPv4 by OpenWRT for you.
I'm not pretending IPv6 will Just Work for as many people as IPv4 but the length, complexity and number of configuration bits in this blog gives the totally wrong impression that it will rarely Just Work.
I experienced only one LAN-to-LAN issue that I discovered only when I started working from home. It's some interaction between odhcpd and NetworkManager and it has now been fixed: https://bugs.openwrt.org/index.php?do=details&task_id...
+ one Avahi init race which is very rare (for me) and easy to work around when it happens https://github.com/lathiat/avahi/issues/117 . It is not even an IPv6 issue, IPv6 only seems to make it a bit more likely to trigger.
PS: I think the easiest to solve the duplicated firewall configuration problem is to generate most of it, I bet some tools/people already do that.
Posted Sep 20, 2020 10:39 UTC (Sun)
by flussence (guest, #85566)
[Link] (3 responses)
Posted Sep 20, 2020 15:19 UTC (Sun)
by TomH (subscriber, #56149)
[Link] (2 responses)
Then I actually tried to migrate from iptables to nftables for the first time and discovered that "inet" is actually next to useless because you can't filter on source or destination addresses when using it! I had assumed you would be able to match on a mixed set of IPv4 and IPv6 addresses but no, you just can't use address filters.
Which is why I wound up writing a rather hacky preprocessor that takes an "inet" family source generates "ip" and "ip6" family sources from it...
Posted Sep 22, 2020 1:38 UTC (Tue)
by jkingweb (subscriber, #113039)
[Link]
Posted Sep 24, 2020 6:12 UTC (Thu)
by flussence (guest, #85566)
[Link]
nftables has all of ipset's functionality built in and rulesets are supposed to be built around that. Separate rules to classify the network layer (one for ip and one for ip6 - not one for each address), just like you'd have two rules at the transport layer for tcp/udp.
Posted Sep 19, 2020 22:33 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link]
The other way is to use a statefull firewall with UDP/TCP hole punching.
Posted Sep 20, 2020 2:47 UTC (Sun)
by zaitcev (guest, #761)
[Link] (2 responses)
Posted Sep 21, 2020 4:41 UTC (Mon)
by backerman (guest, #103085)
[Link]
Comcast is certainly an excellent ISP compared to DSL—which isn't even broadband—and the network core is well-run from what I understand. Unfortunately, their service is irredeemably compromised by the incompetent management responsible for their last-mile physical plant and by the state legislatures they've successfully lobbied to keep out competition. There's no comparison between fiber and HFC, and even if they did have FTTP Comcast is still 50% too expensive without a promotional rate.
Posted Sep 22, 2020 15:08 UTC (Tue)
by mathstuf (subscriber, #69389)
[Link]
So yeah, when things work, they're fine. But when you need to interact with them as a human (rather than a source of income), they're an absolutely atrocious entity.
Posted Sep 20, 2020 22:57 UTC (Sun)
by jejb (subscriber, #6654)
[Link] (1 responses)
Not entirely: you have to configure how big a prefix to ask for and you have to configure which of your delegated subnets goes with which of your lan interfaces. I think it may just work if you have a single LAN interface because the default request looks to be a single /64, but once you have more than one interface, you need manual configuration.
> If the router in turn implements DHCPv6-PD (and upstream provides a short enough prefix) then even a network with multiple cascading routers can set itself up without any manual steps.
Well, that's another OpenWRT issue: dnsmasq doesn't support serving DHCPv6-PD so it won't support cascading prefix delegations to downstream routers.
Posted Sep 21, 2020 17:25 UTC (Mon)
by bangert (subscriber, #28342)
[Link]
Posted Sep 25, 2020 11:55 UTC (Fri)
by jschrod (subscriber, #1646)
[Link] (4 responses)
I would have thought most people have servers there, too, nowadays. Be it a NAS, or a media server, or whatever. And for them, pure autoconfiguration is not sufficient.
Posted Sep 25, 2020 14:57 UTC (Fri)
by zdzichu (subscriber, #17118)
[Link]
Posted Sep 25, 2020 15:34 UTC (Fri)
by jem (subscriber, #24231)
[Link]
Posted Sep 26, 2020 14:49 UTC (Sat)
by abo (subscriber, #77288)
[Link]
Posted Sep 26, 2020 22:41 UTC (Sat)
by zlynx (guest, #2285)
[Link]
If Comcast renumbers my IPv6 prefix that system will be at ::5 wherever it goes. I would need to update the public DNS AAAA records manually.
Posted Sep 20, 2020 2:50 UTC (Sun)
by zaitcev (guest, #761)
[Link] (1 responses)
Posted Sep 20, 2020 9:19 UTC (Sun)
by abo (subscriber, #77288)
[Link]
Bottomley: Creating a home IPv6 network
Bottomley: Creating a home IPv6 network
Bottomley: Creating a home IPv6 network
Bottomley: Creating a home IPv6 network
Bottomley: Creating a home IPv6 network
wol
Bottomley: Creating a home IPv6 network
Bottomley: Creating a home IPv6 network
/64 provides more than enough addresses for that, but the way addresses are reserved is a bit awkward for an address-per-connection mode.
Bottomley: Creating a home IPv6 network
Bottomley: Creating a home IPv6 network
Bottomley: Creating a home IPv6 network
Bottomley: Creating a home IPv6 network
Well, for one thing it just doesn't work on the Internet.
It's a poster child for the second system syndrome. My personal pet peeve are on-link prefixes. IPv4 has a rather simple approach with subnetting and broadcasting, that is intuitive and translates well into hardware.
IPv4 has fixed offset for the TCP header. So if you want to do, for example, load balancing based on the TCP port you only need to look at fixed locations. It can be literally implemented by a simple counter and a comparator chain in hardware.
Bottomley: Creating a home IPv6 network
Bottomley: Creating a home IPv6 network
Wol
Bottomley: Creating a home IPv6 network
Bottomley: Creating a home IPv6 network
It's the same mistake from the dawn of the IPv4.
Yep. For very much the same reasons.
It's the same dumb design, but made much worse.
IPv6 allows mixed-sized networks on the same link. With various interesting interactions. Nobody uses that, but it's supported.
And this makes simple discovery protocols to become much more complicated and involved, even though they use the same broadcast in the end (Ethernet has no native multicasting!).
You have to do all the same subneting stuff for IPv6, even on the beginner level (to explain how prefixes work). The only major simplification was getting rid of non-contiguous netmasks that IPv4 supports (but nobody uses in practice). It's just that IPv6 today is learned after IPv4.
It's really not. IPv6 turned out to be inferior to IPv4 in operational issues, and it doesn't provide anything terribly important for users.
So is IPv4 with NAT.
Light in vacuum is 30 centimeters per nanosecond. Electric signal in copper is around 20 in practice.
Bottomley: Creating a home IPv6 network
Bottomley: Creating a home IPv6 network
OK. In IPv4 to get to the TCP ports info you just need to read the IPv4 header length, walk that many words and that's it. There's no flexibility.
This is an implementation detail (btw, link-local addresses are yet another complication that is absent in IPv4). Consider this situation: you have /96 and /120 subnets on one link. How would hosts talk to each other?
Incorrect. A beginner will need to know about PD at the very least, including subnetting within the network /64 part. It's all the same knowledge as required for IPv4.
NAT effectively multiplies the IPv4 address space by about 100x. So there is no practical limit on the number of IPv4 users. All it does is breaking end-to-end connectivity, but this is not a big problem anymore.
Bottomley: Creating a home IPv6 network
Bottomley: Creating a home IPv6 network
Yup. Modern high-throughput load ballancers actually do that while the packet is being received.
There are no fast paths in core routers. That's a very hard-learned lesson - anything on the "slow path" just becomes a DDoS attack vector or is useless.
Yep. So far it's scaling just fine. Now that all major ISPs have CGNAT hardware, the push to move to IPv6 is basically gone.
You might note that T-Mobile hasn't bothered pushing IPv6 to their hotspots. In the end, 464 XLAT doesn't save much in hardware cost, it just allows to move IPv4 to the edges of the network and move the core onto IPv6. It pays off in case of humongous networks like T-Mobile that simply don't have enough private IPv4 space for their _internal_ addressing.
Cloud is indeed a major consumer of IPv4. It's more than 10% of the total IPv4 address space by some measures. However it can be compressed quite a lot, a typical cloud application doesn't actually _need_ IPv4 if it uses cloud-provided load ballancers (that can use SNI). So I personally don't foresee huge amount of pressure from that side.
Bottomley: Creating a home IPv6 network
Bottomley: Creating a home IPv6 network
Why is it reasonable?
Why? 464XLAT requires just as much NAT state on the outer edge of the network as anything else, you need it to map 4-tuples onto IPv6 addresses.
There are no large mobile operators in the US that do IPv6 for phone-based hotspots, I should have explained more carefully.
Bottomley: Creating a home IPv6 network
> Why is it reasonable?
It's reasonable because extension headers are not normally used - their presence implies something unusual going on, just as IP options do in IPv4.
> Why? 464XLAT requires just as much NAT state on the outer edge of the network as anything else, you need it to map 4-tuples onto IPv6 addresses.
Because those heavy data consumers are IPv6-enabled already, so they require zero NAT state, just stateless IPv6 routing. You only need NAT state for things that go to IPv4, not for IPv6 enabled services.
> There are no large mobile operators in the US that do IPv6 for phone-based hotspots, I should have explained more carefully.
I'm surprised - my contacts at EE tell me that they've cloned their setup from their colleagues at T-Mobile USA; they haven't yet been able to IPv6 enable iPhone hotspots because of issues relating to routing from WiFi/USB to cell, but it's in progress with Apple helping them work out what's going wrong and where, so that it can be fixed.
Bottomley: Creating a home IPv6 network
I don't think IPv6 designers thought that they are optional, the fragmentation header definitely was designed to be used. It's basically an emergent behavior because people have been ignoring extension headers.
That helps, but not as much as you'd think. A single CGNAT box can sustain around 500 million connections at around 300GBps ( https://www.a10networks.com/wp-content/uploads/A10-DS-Thu... ). This is enough for about 10000 customers at around $10 per customer one-time investment.
You CAN get IPv6 for phones, but hotspot traffic goes through NAT on the phone device (and then through 464 XLAT). Apparently, adding another IPv6 circuit to each phone will double the price for ISPs.
Bottomley: Creating a home IPv6 network
Bottomley: Creating a home IPv6 network
$10 includes HA. And it actually gets cheaper as you scale up, because you only need to keep a couple of spare units to pick up the load if one unit fails. Kinda like RAID-5 vs RAID-1.
The thing is, you still need CGNAT anyway because a large part of the Internet is not accessible by IPv6. And it has to be sized to handle the worst case - lots of clients going to an IPv4-only site and watching 4K videos. There are still plenty of them: Amazon Prime Video, Twitch, TikTok, Disney+, etc.
That's nice! I've tried that with my Pixel 4 and I'm not getting IPv6 from either T-Mobile or AT&T.
Bottomley: Creating a home IPv6 network
Bottomley: Creating a home IPv6 network
Bottomley: Creating a home IPv6 network
Bottomley: Creating a home IPv6 network
Bottomley: Creating a home IPv6 network
Bottomley: Creating a home IPv6 network
Typically balancing is done based on a 4-tuple, not on individual subflows from a client. QUIC is going to be interesting to watch, though.
I don't mind that, but business people paying the bills do.
Bottomley: Creating a home IPv6 network
Wol
Bottomley: Creating a home IPv6 network
Bottomley: Creating a home IPv6 network
Bottomley: Creating a home IPv6 network
Bottomley: Creating a home IPv6 network
Wol
Bottomley: Creating a home IPv6 network
Bottomley: Creating a home IPv6 network
Bottomley: Creating a home IPv6 network
Bottomley: Creating a home IPv6 network
Bottomley: Creating a home IPv6 network
Bottomley: Creating a home IPv6 network
Bottomley: Creating a home IPv6 network
So already six /64 networks utilized before even thinking about anything exotic. And /64 is needed for SLAAC.
Bottomley: Creating a home IPv6 network
Bottomley: Creating a home IPv6 network
Bottomley: Creating a home IPv6 network
Bottomley: Creating a home IPv6 network
Bottomley: Creating a home IPv6 network
Bottomley: Creating a home IPv6 network
Bottomley: Creating a home IPv6 network
Bottomley: Creating a home IPv6 network
Bottomley: Creating a home IPv6 network
Bottomley: Creating a home IPv6 network
Bottomley: Creating a home IPv6 network
Bottomley: Creating a home IPv6 network
Bottomley: Creating a home IPv6 network
The consensus seems to be that you should be blocking incoming connections to temporary IPv6 addresses and allow requests to stable addresses. This makes sure that the client communicated their stable address to the other party with the intent of starting an incoming connection.
Bottomley: Creating a home IPv6 network
Bottomley: Creating a home IPv6 network
Bottomley: Creating a home IPv6 network
Bottomley: Creating a home IPv6 network
Bottomley: Creating a home IPv6 network
Bottomley: Creating a home IPv6 network
Bottomley: Creating a home IPv6 network
Bottomley: Creating a home IPv6 network
Bottomley: Creating a home IPv6 network
Bottomley: Creating a home IPv6 network
Bottomley: Creating a home IPv6 network
Bottomley: Creating a home IPv6 network