Hi there all, I discovered that I'd somehow misnamed a draft that Juliusz Chroboczek , Toke Høiland-Jørgensen, and myself had written — somehow I'd managed to name it draft-chroboczek-int-v4-via-v6, instead of draft-chroboczek-intarea-v4-via-v6.
Anyway, it is targeted at intarea, and so I renamed and submitted it, so that it will now actually show up in the IntArea list of documents… The document proposes "v4-via-v6" routing, a technique that uses IPv6 next-hop addresses for routing IPv4 packets, thus making it possible to route IPv4 packets across a network where routers have not been assigned IPv4 addresses. 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" <https://datatracker.ietf.org/doc/rfc9229/>), 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. W
_______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
