Warren Kumari <[email protected]> wrote:
> This isn't yet another "let's rewrite part of the header and override
> some bits", nor some new protocol / tunneling thing. It simply notes
> that routers only need to determine the outgoing interface (and
> usually MAC address) for a packet, and so it's perfectly acceptable
> for the next-hop for e.g 192.0.2.0/24 to be e.g 2001:db8::2342. The
> router don't care...
>
> While this may be initially surprising to many people, it's actually
> nothing "special", nor really groundbreaking - it's just how IP
> routing works. However, because it is surprising, it is not getting
> widely used — and that means that many interfaces need IPv4 addresses
> where they otherwise would not.
>
> In fact, this functionality is already supported in (at least!):
> Arista EOS (since EOS-4.30.1)
> The Babel protocol
> Linux (since kernel version 5.2)
> Mikrotik RouterOS (since before 7.11beta2)
> and the BGP protocol (see RFC8950 - "Advertising IPv4 Network Layer
> Reachability Information (NLRI) with an IPv6 Next Hop").
>
> So, if this already works, why are we writing a document?!
>
> A few reasons, including:
> 1: This behavior / capability is surprising to many people - this
> means that people are "forced" to use IPv4 addresses where they
> otherwise would not.
>
> 2: There should be an easy way to reference this type of
> behaviour/deployment - the genesis of this document that Babel
> supports this (RFC9229 - "IPv4 Routes with an IPv6 Next Hop in the
> Babel Routing Protocol"), but had to describe the behavior because
> there was nothing to point at.
>
> 2: A large number of implementations don't currently support it (or,
> at least, the tooling / CLI / UI doesn't allow configurations like the
> above).
>
> 3: There are some unsettled questions around the ICMP behavior — e.g:
> if a router has to send an ICMP packet too big, and it doesn't have an
> IPv4 address, what should it do?
>
> We'd really appreciate review and feedback — again, this isn't
> documenting a major "change", but more noting this the design of
> command lines, tooling, etc should allow it.
Warrn's list of characteristics and reasons remind me of the IPv4
Unicast Extensions proposals.
(draft-schoen-intarea-unicast-lowest-address-05 et al)
The unicast extensions are more widely supported than the v4-via-v6
behavior. As Warren said, it already works, but it's poorly documented,
so we want to improve that. Both Amazon and Google are publicly
documented as using the extensions internally. And one of the proposals
(a unicast lowest address per subnet) is a completely local change that
doesn't involve changes anywhere else in the Internet.
The v4-via-v6 behavior requires violating various existing RFCs, because
(like unicast extensions) it turns formerly erroneous behavior into
useful behavior. IP gateways that push packets via un-numbered
interfaces were never contemplated by the Internet standards. (From
the point of view of an IPv4 host somewhere on the Internet, a
gateway interface elsewhere that has no IPv4 address is un-numbered.)
I would be happy to see intarea take v4-via-v6 seriously. Especially if
the working group can create a solid fix for ICMP, which at first glance
may require Internet-wide changes to accommodate receiving and
processing a new format in ICMP packets (an issue that the unicast
extensions doesn't have). Perhaps by working on this proposal, intarea
can pull itself out of the mode in which every IP protocol improvement
idea goes there to die.
John
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
