All I have a draft in BESS that uses RFC 8950 and applies it to all BGP AFI/SAFI use case of a single IPv6 peer that can advertise any IPv4 NLRI and as well the converse use case of a single IPv4 peer that can advertise any IPv6 NLRI.
https://datatracker.ietf.org/doc/draft-ietf-bess-v4-v6-pe-all-safi/ There are IGP routing protocol mechanisms that can can do the same and advertise both IPv4 and IPv6 prefixes over a single neighbor. RFC 5120 ISIS MT Multi topology -IPv6 MT has a common control plane but separate data plane. Both IPV4 and IPV6 link state are in common LSDB single ISIS neighbor. https://datatracker.ietf.org/doc/html/rfc5120 RFC 4915 OSPF Multi topology -IPv6 MT has a common control lane and separate data plane. Both IPV4 and IPV6 link state are in common LSDB single ISIS neighbor. https://www.rfc-editor.org/rfc/rfc4915.html OSPFv3 has the address families feature - This is not what you are looking for but though I would mention. https://datatracker.ietf.org/doc/html/rfc5838 Maps different address families such as multicast IPv6, Unicast IPv4, Multicast IPv4 to different instance ID. This puts all the control plane under a single process umbrella however each instance keeps its separate LSDB and neighbor. Thanks <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* *M 301 502-1347* On Mon, Jan 22, 2024 at 9:39 AM Warren Kumari <war...@kumari.net> wrote: > 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 >
_______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
