From: Int-area <int-area-boun...@ietf.org> on behalf of Warren Kumari <war...@kumari.net> Sent: 22 January 2024 14:39
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<http://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"). <tp> The BGP instantiation of this I have long known but have never quite got my mind around what an LSR such as OSPF has to offer here. OSPFv3, which some regard as IPv6, has been able to carry IPv4 prefix for some time and it crops up in e.g. ospf-sr-yang (although I do not think is as a particularly SR issue). It is complex in part because LSR has become an ever more tangled mesh of (sub-(sub-)...TLV and I find it hard to know what TLV are valid where. Also, the advertised prefix are associated with flags and OSPFv2 and OSPFv3 flags are different reflecting the different ideas of links and the like in IPv4 and IPv6 so if you are advertising an IPv4 prefix over an IPv6 transport, whose flags are relevant? Probably both as the transport might affect e.g. the flooding while the ultimate user needs the other set of flags. Like I say, I have yet to get my mind around this. Tom Petch 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
