Hi all, I've updated the node ID ICMP extension draft that I presented in intarea in Brisbane. The motivation for this work is that we got a request from a customer to append the hostname to the interface name field in the RFC5837 response, e.g.,
2 10.2.2.3 <INC:99,10.10.2.3,"Ethernet1/1-George.sjc",mtu=1500> 11.322 ms and I thought it was more productive to create a standard way to encode the hostname in the message itself. The change from the -00 document is that on a suggestion from Reji Thomas, I've made the packet format a strict subset of that in RFC5837. Since this data is intended for presentation to users, this is useful since one doesn't have to write a whole new TLV parser; one can reuse the one that already exists for RFC5837 and just change the user-visible output. Sample hop output from traceroute with this additional info printed as "NODE": 2 10.2.2.3 <INC:99,10.10.2.3,"Ethernet1/1",mtu=1500;NODE:2001:db8::137f,"George.sjc"> 11.322 ms This represents an RFC5837 "incoming interface" info record with ifIndex 99, incoming address 10.10.2.3, etc., and a node ID IP address 2001:db8::137f. In this example the IPv4 addresses are private, but the node ID IP address can be a global IPv6 address. The IANA has assigned Class-Num 5 to this document. Your feedback on this idea is most welcome. Name: draft-fenner-intarea-extended-icmp-hostid Revision: 01 Title: Extending ICMP for Node Identification Date: 2024-04-23 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/archive/id/draft-fenner-intarea-extended-icmp-hostid-01.txt Status: https://datatracker.ietf.org/doc/draft-fenner-intarea-extended-icmp-hostid/ HTML: https://www.ietf.org/archive/id/draft-fenner-intarea-extended-icmp-hostid-01.html HTMLized: https://datatracker.ietf.org/doc/html/draft-fenner-intarea-extended-icmp-hostid Diff: https://author-tools.ietf.org/iddiff?url2=draft-fenner-intarea-extended-icmp-hostid-01 Abstract: RFC5837 describes a mechanism for Extending ICMP for Interface and Next-Hop Identification, which allows providing additional information in an ICMP error that helps identify interfaces participating in the path. This is especially useful in environments where each interface may not have a unique IP address to respond to, e.g., a traceroute. This document introduces a similar ICMP extension for Node Identification. It allows providing a unique IP address and/or a textual name for the node, in the case where each node may not have a unique IP address (e.g., the IPv6 nexthop deployment case described in draft-chroboczek-intarea-v4-via-v6). Thanks, Bill
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
