On 13 Jul 2024, at 17:03, 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. > > 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. > > Thanks, > Bill >
This is great, thanks for working on it. Adding this identification is a clean way of dealing with the disambiguation of nodes and I think it should be progressed. Nick _______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
