I think the ICMP problem needs to be addressed. Perhaps with an IPv4 option to embed the identity of the router (IPv6 address or some other way to identify the owner). One of the main purposes of traceroute is to identify the router that is dropping packets. It will not be helpful if all the routers have the same name.
From: Int-area <[email protected]> On Behalf Of Bob Hinden Sent: Monday, January 22, 2024 11:24 AM To: Warren Kumari <[email protected]> Cc: Internet Area <[email protected]> Subject: [EXTERNAL] Re: [Int-area] draft-chroboczek-intarea-v4-via-v6 - "IPv4 routes with an IPv6 next hop" [EXTERNAL SENDER: This email originated from outside of Stratus Technologies. Do not click links or open attachments unless you recognize the sender and know the content is safe.] ________________________________ Warren, Just to confirm, this is: https://datatracker.ietf.org/doc/draft-chroboczek-int-v4-via-v6/<https://protect-us.mimecast.com/s/VDvBCOY6RYt2ZpXWcvIT2O/> currently at -02. Correct? I think this is a good idea and support it. I will try to review it and provide more comments. The ICMP behavior is an interesting problem. Bob On Jan 22, 2024, at 6:39 AM, Warren Kumari <[email protected]<mailto:[email protected]>> 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<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"). 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://protect-us.mimecast.com/s/NAz7CR6j76fg0vl2iqM5AE/>), 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 [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/int-area<https://www.ietf.org/mailman/listinfo/int-area>
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
