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
