Hi Brian, What you've ended up finding here is that I copied and pasted some text and missed making some edits to it. The "interface" wording is in rfc5837 (which I'm not updating, just copying from) and this text is all supposed to be about a *node* name / hostname.
https://author-tools.ietf.org/api/iddiff?doc_1=draft-fenner-intarea-extended-icmp-hostid&url_2=https://fenner.github.io/icmp-node-id/draft-fenner-intarea-extended-icmp-hostid.txt shows the diff that I've made - so this document no longer talks about interface names except in the references to rfc5837. Bill On Wed, Apr 24, 2024 at 6:41 PM Brian E Carpenter < [email protected]> wrote: > Bill, et al, > > Re: > "The interface name MUST be represented in the UTF-8 charset [RFC3629] > using the Default Language [RFC2277]." > > draft-carpenter-6man-zone-ui is wending its way in 6man, and it's been > suggested that we should clarify the allowed character set for RFC4007 zone > identifiers, which are in practice interface names. At the moment, RFC4007 > simply says they are "strings" without signficant qualification. > > For example, "Ethernet1/1-George.sjc" would be a completely legal zone > identifier under RFC4007. As has also been observed, so would > "blåbærsyltetøy0/0/0". > > Opinions welcome, here or on 6man. Consistency of the two drafts seems > desirable. > > Regards > Brian Carpenter > > On 25-Apr-24 12:16, Bill Fenner wrote: > > 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 > < > 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/ > < > 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 > < > 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 > < > 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 > < > 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 >
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
