Should distributors disable IPv4-mapped IPv6?

Posted Jun 8, 2016 22:40 UTC (Wed) by Cyberax (✭ supporter ✭, #52523)
In reply to: Should distributors disable IPv4-mapped IPv6? by paulj
Parent article: Should distributors disable IPv4-mapped IPv6?

> In the former case, it means 'new' hosts can still easily send packets toward other 'new' even across 'old', un-upgraded sections of network, if they know the address.
Only if they BOTH have valid IPv4s. At which point you're back to double-stack model.

Should distributors disable IPv4-mapped IPv6?

Posted Jun 8, 2016 23:26 UTC (Wed) by nybble41 (subscriber, #55106) [Link]

>> In the former case, it means 'new' hosts can still easily send packets toward other 'new' even across 'old', un-upgraded sections of network, if they know the address.
> Only if they BOTH have valid IPv4s.

Not quite. There does need to be a gateway with a public IPv4 address on each side, but it doesn't need to be the host itself. This is similar to the situation with 6to4: you can have any number of IPv6 hosts with 6to4 addresses behind a 6to4 gateway with a single IPv4 address, and they can all communicate with other hosts similarly located behind other 6to4 gateways. Packets are routed IPv6 to the local gateway, then IPv4 to the remote gateway, and finally IPv6 again to the destination. (Naturally, if you have an IPv6 route to the destination's 6to4 address then you can avoid the gateways entirely.)

The problem which would be alleviated by having *only* 6to4 ("extended" IPv4) addresses would be communication between a host with a 6to4 address and one with a native IPv6 address (and no 6to4). This situation requires a relay to translate between encapsulated 6to4 packets and the IPv6 Internet, which was always a weak point—the other being routers that arbitrarily drop 6to4 packets just because they aren't TCP or UDP, which could have been prevented, albeit with some overhead, by encapsulating 6to4 traffic in UDP instead of giving it a new IP protocol number. As a rule any traffic which required the services of a 6to4 anycast relay would not be routed efficiently, even assuming the packet wasn't filtered and the relay wasn't overloaded. The best you could hope for is that the packets reach a relay quickly, in both directions, since the correct routing can't be determined until after the packet has been translated.

Should distributors disable IPv4-mapped IPv6?

Posted Jun 10, 2016 9:21 UTC (Fri) by paulj (subscriber, #341) [Link] (5 responses)

Neither 'new' hosts needs to run a legacy stack. Indeed, if the legacy space is exhausted, a legacy address might not be available. They do need to have a prefix that is a valid routing label in the 'old' space and routes to appropriate gateway(s) for that prefix should be advertised in that 'old' space.

Should distributors disable IPv4-mapped IPv6?

Posted Jun 10, 2016 9:48 UTC (Fri) by farnz (subscriber, #17727) [Link] (4 responses)

Let's use 6to4 addresses only, for now, just to make it clear, and use the "dotted quad" notation anywhere there's an IPv4 address, not just at the end.

If I have IPv4 192.0.2.0 and IPvN 2002:192.0.2.0::/64, and you have IPvN 2002:192.0.2.0:ffff::/64, what obliges me, as the user of 192.0.2.0, to route your IPvN packets and not just drop them on the floor as "not for me"? Indeed, what prevents me from claiming the entirety of 2002:192.0.2.0::/48 as "mine"?

Should distributors disable IPv4-mapped IPv6?

Posted Jun 10, 2016 10:29 UTC (Fri) by paulj (subscriber, #341) [Link] (3 responses)

I think my reply to raven667 goes into that: http://lwn.net/Articles/690723/

Once the legacy space is out, further assignments must of course be from a prefix that is constant in the legacy space. It would be the assigning authority that determines that.

As to what stops you advertising other people's space - or greater prefixes spanning many assigned spaces, well nothing really stops you technically in BGP as used today. However, there are socio-political-commercial checks. E.g., what stops you advertising 2001::/16 to todays public Inter6net?

Should distributors disable IPv4-mapped IPv6?

Posted Jun 10, 2016 10:33 UTC (Fri) by farnz (subscriber, #17727) [Link] (2 responses)

What stops me not advertising 2002:192.0.2.0::/48 at all in the IPvN space, and just advertising 192.0.2.0 in the IPv4 space, thus allowing me to hijack any suballocations? In IPv6, it's simple - if I control 192.0.2.0, I control the entirety of 2002:192.0.2.0::/48 anyway, and thus hijacking it isn't an issue.

And, from the description you're giving of post-runout allocations, we'd effectively sacrifice 32 bits of address as "dead" - especially since people are likely to optimize their IPvN routing to go down fast paths if those bits are the static "no matching v4" prefix, and to just route over IPv4 otherwise, forcing people who want to switch off IPv4 routing to continue to take part in the v4 network indefinitely, or lose reachability.

Should distributors disable IPv4-mapped IPv6?

Posted Jun 10, 2016 10:49 UTC (Fri) by paulj (subscriber, #341) [Link] (1 responses)

You're talking about the case where legacy has run out, and further allocations all come from X::/32, right? And you're asking, what stops you advertising X/32 in the IPv4 network?

Well, what stops you advertising /any/ prefix X in IPv4 today that you don't have a right to advertise? What you're asking is exactly equivalent to "What stops me advertising 64/8?" or "what stops me advertising 184/8?" It's an interesting discussion, but not specific to transition mechanisms for extending IP address bits.

As for sacrificing dead bits, why do you think they have to be /32? There's no reason we couldn't have used foresight in the 90s to reserve a /8 in the v4 space for the extended space. Where I wrote "further assignments must of course be from a prefix that is constant in the legacy space" I didn't intend that to mean that prefix would have to be the full width of the legacy space.

Should distributors disable IPv4-mapped IPv6?

Posted Jun 10, 2016 10:59 UTC (Fri) by farnz (subscriber, #17727) [Link]

Because I fully expect router vendors to do the same sort of shit as they do today, and do anything to win benchmarks. If you can be 0.01% faster by special-casing IPvN to the "extended" prefix, and using IPv4 routing for the remainder of the IPv4 network, that's what you'll do, and you'll blame other people when it breaks, right up until you're proven to be at fault.

Thus, I pay the pain of IPv4 routing for much, much longer than I need to - I may have access to far better IPvN connectivity (e.g. he.net were doing some incredible - Cogent-beating - deals on IPv6-only transit at one point), but I'm stuck with IPv4 indefinitely.