[Cbor] Re: Zone identifiers (issue #62, pr #63)

[Joe Hildebrand <[e-mail]>]

I see a couple of possible approaches:

- Explicitly declare zone identifiers out of scope with a small amount of text.  This probably assumes that nobody will need to use EDN to help fix the identified zone identifier problems.

- Pull ip'' app-strings out into a separate doc as an extension to EDN, so that it can proceed at its own pace.

— 
Joe Hildebrand

> On Aug 23, 2024, at 4:53 AM, Carsten Bormann <[e-mail]> wrote:
> 
> Unfortunately, the instability in the way IPv6 zones are identified in various documents appears to cause complexity in our own specifications.
> 
> I would like to contain this complexity as much as possible, not smearing it over all documents that handle IP addresses in CBOR.
> Our main document here is RFC 9164, "(CBOR) Tags for IPv4 and IPv6 Addresses and Prefixes”.
> 
> Just as a reminder for the background (I’m not an expert in this, so please send corrections):
> 
> RFC 4007 only knows the concept of zone indices.
> It does not really say what these are in general, but 
>  "An implementation SHOULD support at least numerical indices that are
>   non-negative decimal integers as <zone_id>.  The default zone index,
>   which should typically be 0 (see Section 6), is included in the
>   integers."
> Index 0 is reserved for “the default zone”.
> 
> The document also defines a text format for IP addresses, 
> 
>   As a
>   common notation to specify the scope zone, an implementation SHOULD
>   support the following format:
> 
>            <address>%<zone_id>
> 
> There is no binary format for zone identifiers in RFC 4007.
> Apparently, <zone_id> is a decimal unsigned integer; there is no discussion of leading zeros.
> However, Section 11.2 also mentions a “non-null string”; there is no mention of a character set (or a definition of “non-null”):
> 
>   An implementation MAY support other kinds of non-null strings as
>   <zone_id>.  However, the strings must not conflict with the delimiter
>   character.  The precise format and semantics of additional strings is
>   implementation dependent.
> 
> The index-based format has not been universally implemented; many IP implementations use interface names (as in “eth0”) for zone identifiers.
> 
> RFC 5952 provides "A Recommendation for IPv6 Address Text
> Representation", but ignores zone identifiers.
> 
> RFC 6874, "Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers”, is trying to remedy that (and the fact that RFCs 3986 obviously doesn’t RFCs 4007’s address zone identifiers):
> 
>   This document describes how the zone identifier of an IPv6 scoped
>   address, defined as <zone_id> in the IPv6 Scoped Address Architecture
>   (RFC 4007), can be represented in a literal IPv6 address and in a
>   Uniform Resource Identifier that includes such a literal address.  It
>   updates the URI Generic Syntax specification (RFC 3986) accordingly.
> 
> Because the choice of % as a delimited for zone_id conflicts with the use of % for percent-encoding in URIs, the URI format defined in RFC 6874 was never consistently implemented and is generally considered to be dead.
> 
> Before this status quo was arrived at, there was an attempt to do a 6874bis (2022, now expired), which restricts zone identifiers to the URI characters in “unreserved”:
> 
>> A zone identifier MUST contain only ASCII characters classified as "unreserved" for use in URIs [RFC3986]. This excludes characters such as "]" or even "%" that would complicate parsing. For the avoidance of doubt, note that a zone identifier consisting of "25" or starting with "25" is valid and is used in some operating systems. A parser MUST NOT apply percent decoding to the IPv6 address literal in a URI, including cases such as http://[fe80::abcd%25] and http://[fe80::abcd%25xy].¶
> 
> Several active I-D documents claim to obsolete RFC 6874:
> 
> * draft-ietf-6man-zone-ui
>  This tries to rescue the %-based zone_id by removing the percent-encoding ambiguity as well as suggesting (not defining!) an alternative delimiter (“-“).
> It struggles with the numeric vs. “human-readable” concepts of zone identifiers:
> 
>   The RFC 4007 model assumes that the human-readable zone identifier is
>   mapped by the operating system into a numeric interface index.
> 
> * draft-schinazi-httpbis-link-local-uri-bcp
> 
> This proposes to essentially get rid of zone identifiers.
> 
>                      .oOo.
> 
> In summary, this is not a stable ground on which to build other specifications.  Therefore, draft-ietf-cbor-end-literals does not define additional literals for CBOR data items that employ zone identifiers; these can be added later (say, ipz’’).
> Until then, CBOR data items that contain zone identifiers can be constructed as they have been before edn-literal extension; how to do this is described in RFC 9164.
> 
> RFC 9164 supports the inclusion of a zone identifier in the “interface format” CBOR data item (Section 3.3), which besides a full IP address can provide a prefix length and a zone identifier (*).
> It does not consider the ambiguity with respect to the character set of zone identifiers, so it says:
> 
>   Interface Format definitions support an optional third element to the
>   array, which is to be used as the IPv6 link-local zone identifier
>   from Section 6 of [RFC4007]; for symmetry, this is also provided for
>   IPv4 as in [RFC4001] and [RFC6991].  The zone identifier may be an
>   integer, in which case it is to be interpreted as the interface
>   index.  It may be a text string, in which case it is to be
>   interpreted as an interface name.
> 
> This does not provide the unconstrained generality of RFC 4007 “human-readable” zone identifiers, so maybe this should have been a text string *or* a byte string (or a byte string only).
> 
> One of the examples in Section 3.2 actually contains a byte string where the above definition (and the CDDL in Section 5) only allows text strings.
> 
>   54([h'fe8000000000020202fffffffe030303', 64, 'eth0'])
> 
> This awaits generating and agreeing on the result of processing an errata report.
> 
>                        .oOo.
> 
> https://github.com/cbor-wg/edn-literal/issues/62
> asks whether Zone-IDs should be included in the IP address syntax for ip’’.
> Given the above, I believe this should be added when the zone-id quicksand stabilizes; I do believe this will take at least another couple of years, as it includes obtaining buy-in from browser vendors.
> 
> ip’’ mainly is used to notate tag 54/52 (RFC 9164) and their unwrapped forms.
> Only the “interface format” of tag 54/42 provides for zone identifiers; no syntax for interface format (neither prefix length nor zone identifier) is provided by ip’’.  The new text proposed in 
> 
>  https://github.com/cbor-wg/edn-literal/pull/63/files
> 
> points this out, as well as the ease of constructing the interface format by hand (using ip’’ for the actually address component inside that).
> 
> I didn’t see a need to further engage the zone_id topic at this point of its development and think the text in the PR is now fine.
> A comment on PR #23 asks for more text on this, restating information from RFC 9164 in other words [1].
> I see no upside and lots of unneeded confusion by opening this can of worms.
> I definitely do not want to copy the examples already given in RFC 9164, in particular while one of those probably needs errata processing.
> Again, none of these are supported (or need support) from ip’’.
> 
> 
> Further advice would be appreciated.
> 
> Grüße, Carsten
> 
> (*): This is distinct from the "prefix format” of Section 3.1.2, for which IP’’ does provide syntax.
> 
> [1]: https://www.ietf.org/archive/id/draft-bormann-restatement-01.html#name-perils-of-restatements
> 
> _______________________________________________
> CBOR mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]