The draft seems entirely too focused on the guts of the per-packet
routing decision. This misses the system-wide implications of the
proposal.
The draft treats IPv4 and IPv6 as symmetric and equal, such that you
could route packets for either or both, over a network that support just
one.
So I started to wonder why something like this didn't get used during
the early days of IPv6. The entirety of the Internet supported IPv4
traffic routing at that time. This extension would seem equally useful
to ISPs that want to offer IPv6 to their end-users without adding and
maintaining IPv6 addresses on their entire already-working network of
IPv4 routers.
Wouldn't it have been simple to just have the edge routers offer IPv6 to
customer nodes, while the internals of the ISP's network continued to
use their existing IPv4 addresses and routing? But that didn't happen.
Instead, early IPv6 adopters had to connect using overlay tunnels
that *encapsulated* IPv6 traffic in IPv4 packets. So what are we
missing about the simplicity of this proposal?
The document's focus is on routing IPv4 traffic for end-nodes via
what it characterizes as an IPv6-only core network.
But the rub is that every node of that IPv6-only core network (in this
vision) nevertheless must know about IPv4 routing. And apparently all
of those routers are completely happy about receiving an IPv4 packet
over some interface, routing it, and sending it out another interface,
not encapsulated in anything at the Internet level. In other words, the
draft does not envision deployment in an IPv6-only network of IPv6-only
routers.
That dual-stack assumption was not true when IPv6 was young and
end-users were unable to get their ISP to support it. That's why such a
vision was not deployed back then.
It looks like the situation in which this behavior is useful, is one
in which:
* Every router in the network of interest has full support for both
IPv4 and IPv6.
* The network of interest wants to support end-users who use IPv4,
and/or IPv6 addresses.
but
* Every router in the network of interest doesn't want to have both
kinds of address assigned to each of its interfaces, as the
RFCs normally require.
How many networks are there like this, really?
So let's now look at how the vision would actually work today.
Let's assume that there is a route for 123.0.0.1/24 whose next hop is
2023:0124::0666, which is on interface eth7. Does a packet for
123.1.2.3 get sent out as an IPv4-over-Ethernet packet on eth7? How
could it be addressed to 2023:0124::0666 as an IPv4-over-Ethernet
packet?
Perhaps the 2023:0124::1 address does not get used at all? It is just a
placeholder for the MAC address of an un-numbered IPv4 router that
exists somewhere connected to eth7 and happens to have the same MAC
address as that IPv6 router?
Or else, when a v4 packet is sent down a v6 interface, does it get
encapsulated in a v6 packet that's then encapsulated in an Ethernet
frame?
The document is silent on all these details.
It seems like the idea is to save money by not requiring increasingly
expensive IPv4 addresses on every router interface, but instead to push
the costs onto the rest of the Internet, which would have to upgrade
their software to support some kind of odd change to ICMP.
It also looks like something like this would probably work as long as
there is a single unique IPv4 address assigned to each router (not one
IPv4 address per interface). That address could be used for ICMP
replies on any interface. Does that work?
John
PS: The draft seems to confuse IPv6 link-local addresses (FE8x::, RFC
3513) with IPv6 unique local addresses (FDxx::, RFC 4193). Link-local
addresses are not useful beyond the nodes that touch a physical network
like an Ethernet. So a routing protocol could not usefully carry such
addresses to nodes that don't touch that physical Ethernet. In
addition, those link-local addresses are not even unique at a single
router, so they require an additional interface-ID (e.g. the "%eth5" in
FE80::1234%eth5) that has no way to be carried in routing protocols. On
the other hand, IPv6 unique local addresses ARE ordinary unicast
addresses, are routable within a subnetwork, and could be used for a
self-configuring router network.
IPv4 has link-local addresses as well as IPv6 (169.254/16, RFC 3927).
If an underlying core network containing link-local IPv6 addresses would
actually work, then it would work for an IPv4 core as well as IPv6 core.
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
