On Sat, Jul 13, 2024 at 9:03 AM, Bill Fenner <fen...@fenron.com> 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 -- int-area@ietf.org > To unsubscribe send an email to int-area-le...@ietf.org >
_______________________________________________ Int-area mailing list -- int-area@ietf.org To unsubscribe send an email to int-area-le...@ietf.org
