Re: [Int-area] draft-chroboczek-intarea-v4-via-v6 - "IPv4 routes with an IPv6 next hop"

[Gyan Mishra <[e-mail]>]

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 [e-mail] <[e-mail]>*



*M 301 502-1347*



On Mon, Jan 22, 2024 at 9:39 AM Warren Kumari <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/int-area
>