Hi Brian, There's no relationship between this work and RFC4620. Bob suggested looking at this after my presentation in Brisbane, and in response in https://github.com/fenner/icmp-node-id/issues/1 I write:
ICMP node information allows an ICMP request message (similar to ping) to request information such as node name, IP addresses, IPv4 addresses, from a remote node. The request allows asking for one piece of information at a time (e.g., "what is your name" or "what IP addresses do you have?"). The reply for the node name is in DNS format (e.g., \x03www\x07example\x03com), and has an MBZ 4-byte field at the start. The reply for the IP addresses is just the bytes of the address, with a TTL; the type of address (IPv6 or IPv4) is determined by the query. The RFC5837 packet format is much more suited to data that the responder is choosing what data to reply with. Bob's suggestion was based around the idea of reusing existing code/structures, and the update to reuse the RFC5837 format addresses this in a better (IMO) way. Bill On Wed, Jul 24, 2024 at 7:43 AM Brian Haberman <[email protected]> wrote: > Hey Bill, > How do you see this draft affecting RFC 4620? > > Regards, > Brian > > On 7/15/24 3:41 PM, Warren Kumari wrote: > > On Sat, Jul 13, 2024 at 9:03 AM, Bill Fenner <[email protected]> wrote: > > > >> Hi, > >> > >> I've submitted version -02 of https://datatracker.ietf.org/doc/ > >> draft-fenner-intarea-extended-icmp-hostid/ , which is an RFC4884-based > >> ICMP extension that allows supplying a textual hostname and/or a single > >> identifying IPv4/IPv6 address for a node. This is intended to address > >> deployments where IPv4 addresses are scarce, and are therefore reused. > >> RFC5837 can supply the incoming interface IP address, but in a scarcity > >> environment an interface may not have an IP address. The source IP > address > >> of an ICMP error may be an IPv4 address that is reused through the > domain - > >> a theoretical example of this from draft-chroboczek-intarea-v4-via-v6 is > >>> $ traceroute -n 8.8.8.8 > >> traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 52 byte packets > >> 1 192.168.0.1 1.894 ms 1.953 ms 1.463 ms > >> 2 192.0.0.8 9.012 ms 8.852 ms 12.211 ms > >> 3 192.0.0.8 8.445 ms 9.426 ms 9.781 ms > >> 4 192.0.0.8 9.984 ms 10.282 ms 10.763 ms > >> 5 192.0.0.8 13.994 ms 13.031 ms 12.948 ms > >> 6 192.0.0.8 27.502 ms 26.895 ms > >> 7 8.8.8.8 26.509 ms > >> > >> This extension allows each of the intermediate nodes 2-6 to include > >> identifying information, whether a hostname or a single IPv4 or IPv6 > >> address, to disambiguate nodes in this kind of IP address scarcity > >> deployment. > >> > > > > > > Excellent, thank you! > > > > Just before the draft cut-off I draft-chroboczek-intarea-v4-via-v6/ > > <https://datatracker.ietf.org/doc/draft-chroboczek-intarea-v4-via-v6/> > to > > refer to > > > https://datatracker.ietf.org/doc/draft-fenner-intarea-extended-icmp-hostid/ > . > > > > Regardless of what happens with draft-chroboczek-intarea-v4-via-v6 > > <https://datatracker.ietf.org/doc/draft-chroboczek-intarea-v4-via-v6/>, > I > > think that we should progress draft-fenner-intarea-extended-icmp-hostid > > < > https://datatracker.ietf.org/doc/draft-fenner-intarea-extended-icmp-hostid/ > > > > . > > > > I often run traceroutes and see things like: > > traceroute www.apple.com > > traceroute to e6858.dscx.akamaiedge.net (184.31.197.27), 64 hops max, 40 > > byte packets > > 1 10.0.7.1 (10.0.7.1) 2.949 ms 3.133 ms * > > 2 10.9.8.4 (10.9.8.4) 3.430 ms 3.433 ms * > > 3 192.168.5.1 (192.168.5.1) 4.321 ms 4.345 ms 6.555 ms > > > > Being able to have things like: > > traceroute www.apple.com > > traceroute to e6858.dscx.akamaiedge.net (184.31.197.27), 64 hops max, 40 > > byte packets > > 1 foo.bar.net (10.0.7.1) 2.949 ms 3.133 ms * > > 2 baz.boop.com (10.9.8.4) 3.430 ms 3.433 ms * > > 3 I_Like_Cheese (192.168.5.1) 4.321 ms 4.345 ms 6.555 ms > > > > Would be very helpful - yes, people could put whatever they like in this, > > but that's true of reverse DNS too. > > > > I presented this document in Brisbane; since that time I changed the > packet > >> format to be a subset of the format defined by RFC5837 to be able to > >> re-use packet generation and parsing code. > >> > >> Any feedback is greatly appreciated. > >> > > > > My (no hats) feedback: > > This should be adopted - it seems simple, clean, elegant and a good idea… > > > > W > > > > > > > >> Thanks, > >> Bill > >> > >> _______________________________________________ > >> Int-area mailing list -- [email protected] > >> To unsubscribe send an email to [email protected] > >> > > > > > > _______________________________________________ > > Int-area mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > _______________________________________________ > Int-area mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
