On Mon, Jan 22, 2024 at 2:23 PM Warren Kumari <[email protected]> wrote:
> > > > > 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/> > ). > > > I tried probe command on my Mac with bash shell, got command not found. Behcet > 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 >
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
