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.8traceroute 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 packetformat 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… WThanks, 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]
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
