On Mon, Jan 22, 2024 at 12:08 PM, Herbie Robinson < [email protected]> wrote:
> 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. > Yup. Fully agreed. Bill Fenner is actually working on a solution to this, and so I've taken the liberty of adding him to the CC list… Bill and Jen Linkova had also suggested something based on the approach used in RFC8335 - "PROBE: A Utility for Probing Interfaces" <https://datatracker.ietf.org/doc/rfc8335/> , and Bill is also working on an update (draft-fenner-int-probe-clarification - "PROBE: A Utility for Probing Interfaces" <https://datatracker.ietf.org/doc/draft-fenner-int-probe-clarification/> ). W > > *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]> 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://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] > https://www.ietf.org/mailman/listinfo/int-area > >
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
