11.7 Combinations of Delimiter Characters

11.7 Combinations of Delimiter Characters

There are other kinds of delimiter characters defined for IPv6 addresses. In this subsection, we describe how they should be combined with the format for non-global addresses.

The IPv6 addressing architecture [1] also defines the syntax of IPv6 prefixes. If the address portion of a prefix is non-global and its scope zone should be disambiguated, the address portion SHOULD be in the format. For example, a link-local prefix fe80::/64 on the second link can be represented as follows:

fe80::%2/64

In this combination, it is important to place the zone index portion before the prefix length when we consider parsing the format by a name-to-address library function [11]. That is, we can first separate the address with the zone index from the prefix length, and just pass the former to the library function.

The preferred format for literal IPv6 addresses in URLs is also defined [12]. When a user types the preferred format for an IPv6 non-global address whose zone should be explicitly specified, the user could use the format for the non-global address combined with the preferred format.

However, the typed URL is often sent on the wire, and it would cause confusion if an application did not strip the <zone_id> portion before sending. Note that the applications should not need to care about which kind of addresses they're using, much less parse or strip out the <zone_id> portion of the address.

Also, the format for non-global addresses might conflict with the URI syntax [13], since the syntax defines the delimiter character (%) as the escape character. This conflict would require, for example, that the <zone_id> part for zone 1 with the delimiter be represented as '%251'. It also means that we could not simply copy a non-escaped format from other sources as input to the URI parser. Additionally, if the URI parser does not convert the escaped format before passing it to a name-to-address library, the conversion will fail. All these issues would decrease the benefit of the textual representation described in this section.

Hence, this document does not specify how the format for non-global addresses should be combined with the preferred format for literal IPv6 addresses. In any case, it is recommended to use an FQDN instead of a literal IPv6 address in a URL, whenever an FQDN is available.