Thanks Bill. I'd still appreciate opinions whether 6man should define the RFC 4007 zone identifier more precisely than just calling it a "string". In practice it's the same as what operating systems call an "interface name", so the text of RFC 5837 and 2863 is of interest.
Regards Brian Carpenter On 27-Apr-24 07:27, Bill Fenner wrote:
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 <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] <mailto:[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> <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/> <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> <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> <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> <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] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/int-area <https://www.ietf.org/mailman/listinfo/int-area>
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
