| < draft-ietf-6man-rfc6874bis-00.txt | draft-ietf-6man-rfc6874bis-01.txt > | |||
|---|---|---|---|---|
| 6MAN B. Carpenter | 6MAN B. Carpenter | |||
| Internet-Draft Univ. of Auckland | Internet-Draft Univ. of Auckland | |||
| Obsoletes: 6874 (if approved) S. Cheshire | Obsoletes: 6874 (if approved) S. Cheshire | |||
| Updates: 3986, 3987 (if approved) Apple Inc. | Updates: 3986, 3987 (if approved) Apple Inc. | |||
| Intended status: Standards Track R. Hinden | Intended status: Standards Track R. Hinden | |||
| Expires: 19 September 2022 Check Point Software | Expires: 7 October 2022 Check Point Software | |||
| 18 March 2022 | 5 April 2022 | |||
| Representing IPv6 Zone Identifiers in Address Literals and Uniform | Representing IPv6 Zone Identifiers in Address Literals and Uniform | |||
| Resource Identifiers | Resource Identifiers | |||
| draft-ietf-6man-rfc6874bis-00 | draft-ietf-6man-rfc6874bis-01 | |||
| Abstract | Abstract | |||
| This document describes how the zone identifier of an IPv6 scoped | This document describes how the zone identifier of an IPv6 scoped | |||
| address, defined as <zone_id> in the IPv6 Scoped Address Architecture | address, defined as <zone_id> in the IPv6 Scoped Address Architecture | |||
| (RFC 4007), can be represented in a literal IPv6 address and in a | (RFC 4007), can be represented in a literal IPv6 address and in a | |||
| Uniform Resource Identifier that includes such a literal address. It | Uniform Resource Identifier that includes such a literal address. It | |||
| updates the URI Generic Syntax and Internationalized Resource | updates the URI Generic Syntax and Internationalized Resource | |||
| Identifier specifications (RFC 3986, RFC 3987) accordingly, and | Identifier specifications (RFC 3986, RFC 3987) accordingly, and | |||
| obsoletes RFC 6874. | obsoletes RFC 6874. | |||
| skipping to change at page 1, line 49 ¶ | skipping to change at page 1, line 49 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on 19 September 2022. | This Internet-Draft will expire on 7 October 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2022 IETF Trust and the persons identified as the | Copyright (c) 2022 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
| license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
| Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
| and restrictions with respect to this document. Code Components | and restrictions with respect to this document. Code Components | |||
| extracted from this document must include Revised BSD License text as | extracted from this document must include Revised BSD License text as | |||
| described in Section 4.e of the Trust Legal Provisions and are | described in Section 4.e of the Trust Legal Provisions and are | |||
| provided without warranty as described in the Revised BSD License. | provided without warranty as described in the Revised BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
| 2. Issues with Implementing RFC 6874 . . . . . . . . . . . . . . 4 | 2. Issues with Implementing RFC 6874 . . . . . . . . . . . . . . 4 | |||
| 3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 4 | 3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 4. URI Parsers . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 4. URI Parsers . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 | 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 | |||
| 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 | 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 | 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 | |||
| 7.2. Informative References . . . . . . . . . . . . . . . . . 8 | 7.2. Informative References . . . . . . . . . . . . . . . . . 9 | |||
| Appendix A. Options Considered . . . . . . . . . . . . . . . . . 9 | Appendix A. Options Considered . . . . . . . . . . . . . . . . . 10 | |||
| Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 10 | Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 11 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
| 1. Introduction | 1. Introduction | |||
| The Uniform Resource Identifier (URI) syntax specification [RFC3986] | The Uniform Resource Identifier (URI) syntax specification [RFC3986] | |||
| defined how a literal IPv6 address can be represented in the "host" | defined how a literal IPv6 address can be represented in the "host" | |||
| part of a URI. Two months later, the IPv6 Scoped Address | part of a URI. Two months later, the IPv6 Scoped Address | |||
| Architecture specification [RFC4007] extended the text representation | Architecture specification [RFC4007] extended the text representation | |||
| of limited-scope IPv6 addresses such that a zone identifier may be | of limited-scope IPv6 addresses such that a zone identifier may be | |||
| concatenated to a literal address, for purposes described in that | concatenated to a literal address, for purposes described in that | |||
| specification. Zone identifiers are especially useful in contexts in | specification. Zone identifiers are especially useful in contexts in | |||
| which literal addresses are typically used, for example, during fault | which literal addresses are typically used, for example, during fault | |||
| diagnosis, when it may be essential to specify which interface is | diagnosis, when it may be essential to specify which interface is | |||
| used for sending to a link-local address. It should be noted that | used for sending to a link-local address. It should be noted that | |||
| zone identifiers have purely local meaning within the node in which | zone identifiers have purely local meaning within the node in which | |||
| they are defined, often being the same as IPv6 interface names. They | they are defined, usually being the same as IPv6 interface names. | |||
| are completely meaningless for any other node. Today, they are | They are completely meaningless for any other node. Today, they are | |||
| meaningful only when attached to addresses with less than global | meaningful only when attached to link-local addresses, but it is | |||
| scope, but it is possible that other uses might be defined in the | possible that other uses might be defined in the future. | |||
| future. | ||||
| The IPv6 Scoped Address Architecture specification [RFC4007] does not | The IPv6 Scoped Address Architecture specification [RFC4007] does not | |||
| specify how zone identifiers are to be represented in URIs. | specify how zone identifiers are to be represented in URIs. | |||
| Practical experience has shown that this feature is useful or | Practical experience has shown that this feature is useful or | |||
| necessary, in at least three use cases: | necessary, in multiple use cases: | |||
| 1. When using a web browser for simple debugging actions involving | 1. A web browser may be used for simple debugging actions involving | |||
| link-local addresses on a host with more than one active link | link-local addresses on a host with more than one active link | |||
| interface. | interface. | |||
| 2. When using a web browser to configure or reconfigure a device | 2. A web browser must sometimes be used to configure or reconfigure | |||
| which only has a link local address and whose only configuration | a device which only has a link local address and whose only | |||
| tool is a web server, again from a host with more than one active | configuration tool is a web server, again in a host with more | |||
| link interface. | than one active link interface. | |||
| 3. When using an HTTP-based protocol for establishing link-local | 3. The Apple and open-source CUPS printing mechanism [CUPS] | |||
| relationships, such as the Apple CUPS printing mechanism [CUPS]. | [OP-CUPS] uses an HTTP-based protocol [RFC3510][RFC7472] to | |||
| establish link-local relationships, so requires the specification | ||||
| of the relevant interface. | ||||
| 4. The Microsoft Web Services for Devices (WSD) virtual printer port | ||||
| mechanism can generate an IPv6 Link Local URL in which the zone | ||||
| identifier is present and necessary, but is not recognized by any | ||||
| current browser. | ||||
| It should be noted that whereas some operating systems and network | It should be noted that whereas some operating systems and network | |||
| APIs support a default zone identifier as described in [RFC4007], | APIs support a default zone identifier as described in [RFC4007], | |||
| others do not, and for them an appropriate URI syntax is particularly | others do not, and for them an appropriate URI syntax is particularly | |||
| important. | important. | |||
| In the past, some browser versions directly accepted the IPv6 Scoped | In the past, some browser versions directly accepted the IPv6 Scoped | |||
| Address syntax [RFC4007] for scoped IPv6 addresses embedded in URIs, | Address syntax [RFC4007] for scoped IPv6 addresses embedded in URIs, | |||
| i.e., they were coded to interpret a "%" sign following the literal | i.e., they were coded to interpret a "%" sign following the literal | |||
| address as introducing a zone identifier [RFC4007], instead of | address as introducing a zone identifier [RFC4007], instead of | |||
| introducing two hexadecimal characters representing some percent- | introducing two hexadecimal characters representing some percent- | |||
| encoded octet [RFC3986]. Clearly, interpreting the "%" sign as | encoded octet [RFC3986]. Clearly, interpreting the "%" sign as | |||
| introducing a zone identifier is very convenient for users, although | introducing a zone identifier is very convenient for users, although | |||
| it is not supported by the URI syntax [RFC3986] or the | it is not supported by the URI syntax in [RFC3986] or the | |||
| Internationalized Resource Identifier (IRI) syntax [RFC3987]. | Internationalized Resource Identifier (IRI) syntax in [RFC3987]. | |||
| Therefore, this document updates RFC 3986 and RFC 3987 by adding | Therefore, this document updates RFC 3986 and RFC 3987 by adding | |||
| syntax to allow a zone identifier to be included in a literal IPv6 | syntax to allow a zone identifier to be included in a literal IPv6 | |||
| address within a URI. | address within a URI. | |||
| It should be noted that in contexts other than a user interface, a | It should be noted that in contexts other than a user interface, a | |||
| zone identifier is mapped into a numeric zone index or interface | zone identifier is mapped into a numeric zone index or interface | |||
| number. The MIB textual convention InetZoneIndex [RFC4001] and the | number. The MIB textual convention InetZoneIndex [RFC4001] and the | |||
| socket interface [RFC3493] define this as a 32-bit unsigned integer. | socket interface [RFC3493] define this as a 32-bit unsigned integer. | |||
| The mapping between the human-readable zone identifier string and the | The mapping between the human-readable zone identifier string and the | |||
| numeric value is a host-specific function that varies between | numeric value is a host-specific function that varies between | |||
| skipping to change at page 4, line 44 ¶ | skipping to change at page 5, line 14 ¶ | |||
| 3. Specification | 3. Specification | |||
| According to IPv6 Scoped Address syntax [RFC4007], a zone identifier | According to IPv6 Scoped Address syntax [RFC4007], a zone identifier | |||
| is attached to the textual representation of an IPv6 address by | is attached to the textual representation of an IPv6 address by | |||
| concatenating "%" followed by <zone_id>, where <zone_id> is a string | concatenating "%" followed by <zone_id>, where <zone_id> is a string | |||
| identifying the zone of the address. However, the IPv6 Scoped | identifying the zone of the address. However, the IPv6 Scoped | |||
| Address Architecture specification gives no precise definition of the | Address Architecture specification gives no precise definition of the | |||
| character set allowed in <zone_id>. There are no rules or de facto | character set allowed in <zone_id>. There are no rules or de facto | |||
| standards for this. For example, the first Ethernet interface in a | standards for this. For example, the first Ethernet interface in a | |||
| host might be called %0, %1, %en1, %eth0, or whatever the implementer | host might be called %0, %1, %25, %en1, %eth0, or whatever the | |||
| happened to choose. Also, %25 would be valid. | implementer happened to choose. | |||
| In a URI, a literal IPv6 address is always embedded between "[" and | In a URI, a literal IPv6 address is always embedded between "[" and | |||
| "]". This document specifies how a <zone_id> can be appended to the | "]". This document specifies how a zone identifier can be appended | |||
| address. According to the text in Section 2.4 of [RFC3986], "%" must | to the address. The URI syntax defined by [RFC3986] does not allow | |||
| be percent-encoded as "%25" to be used as data within a URI. | the presence of a percent ("%") character within an IPv6 address | |||
| However, in the formal ABNF syntax of RFC 3986, this only applies | literal. For this reason, it is backwards compatible to allow the | |||
| where the "pct-encoded" element appears. For this reason, it is | use of "%" within an IPv6 address literal as a delimiter only, such | |||
| possible to extend the ABNF such that the scoped address | that the scoped address fe80::abcd%en1 would appear in a URI as | |||
| fe80::abcd%en1 would appear in a URI as http://[fe80::abcd%en1] or | http://[fe80::abcd%en1] or https://[fe80::abcd%en1]. | |||
| https://[fe80::abcd%en1]. | ||||
| A <zone_id> MUST contain only ASCII characters classified as | This use of "%" as a delimiter applies only within an IPv6 address | |||
| literal, and is irrelevant to and exempt from the percent-encoding | ||||
| mechanism [RFC3986]. | ||||
| A zone identifier MUST contain only ASCII characters classified as | ||||
| "unreserved" for use in URIs [RFC3986]. This excludes characters | "unreserved" for use in URIs [RFC3986]. This excludes characters | |||
| such as "]" or even "%" that would complicate parsing. The <zone_id> | such as "]" or even "%" that would complicate parsing. For the | |||
| "25" cannot be forbidden since it is valid in some operating systems, | avoidance of doubt, note that a zone identifier consisting of "25" or | |||
| so a parser MUST NOT apply percent decoding to a URI such as | starting with "25" is valid and is used in some operating systems. A | |||
| http://[fe80::abcd%25]. | 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]. | ||||
| If an operating system uses any other characters in zone or interface | If an operating system uses any other characters in zone or interface | |||
| identifiers that are not in the "unreserved" character set, they | identifiers that are not in the "unreserved" character set, they | |||
| cannot be used in a URI. | cannot be used in a URI. | |||
| We now present the corresponding formal syntax. | We now present the corresponding formal syntax. | |||
| The URI syntax specification [RFC3986] formally defines the IPv6 | The URI syntax specification [RFC3986] formally defines the IPv6 | |||
| literal format in ABNF [RFC5234] by the following rule: | literal format in ABNF [RFC5234] by the following rule: | |||
| skipping to change at page 6, line 7 ¶ | skipping to change at page 6, line 29 ¶ | |||
| This syntax fills the gap that is described at the end of | This syntax fills the gap that is described at the end of | |||
| Section 11.7 of the IPv6 Scoped Address Architecture specification | Section 11.7 of the IPv6 Scoped Address Architecture specification | |||
| [RFC4007]. It replaces and obsoletes the syntax in Section 2 of | [RFC4007]. It replaces and obsoletes the syntax in Section 2 of | |||
| [RFC6874]. | [RFC6874]. | |||
| The established rules for textual representation of IPv6 addresses | The established rules for textual representation of IPv6 addresses | |||
| [RFC5952] SHOULD be applied in producing URIs. | [RFC5952] SHOULD be applied in producing URIs. | |||
| The URI syntax specification [RFC3986] states that URIs have a global | The URI syntax specification [RFC3986] states that URIs have a global | |||
| scope, but that in some cases their interpretation depends on the | scope, but that in some cases their interpretation depends on the | |||
| end-user's context. URIs including a ZoneID are to be interpreted | end-user's context. URIs including a zone identifier are to be | |||
| only in the context of the host at which they originate, since the | interpreted only in the context of the host at which they originate, | |||
| ZoneID is of local significance only. | since the zone identifier is of local significance only. | |||
| The IPv6 Scoped Address Architecture specification [RFC4007] offers | The IPv6 Scoped Address Architecture specification [RFC4007] offers | |||
| guidance on how the ZoneID affects interface/address selection inside | guidance on how the zone identifier affects interface/address | |||
| the IPv6 stack. Note that the behaviour of an IPv6 stack, if it is | selection inside the IPv6 stack. Note that the behaviour of an IPv6 | |||
| passed a non-null zone index for an address other than link-local, is | stack, if it is passed a non-null zone index for an address other | |||
| undefined. | than link-local, is undefined. | |||
| In cases where the RFC 6874 encoding is currently used between | ||||
| specific software components rather than between a browser and a web | ||||
| server, such usage MAY continue indefinitely. | ||||
| 4. URI Parsers | 4. URI Parsers | |||
| This section discusses how URI parsers, such as those embedded in web | This section discusses how URI parsers, such as those embedded in web | |||
| browsers, might handle this syntax extension. Unfortunately, there | browsers, might handle this syntax extension. Unfortunately, there | |||
| is no formal distinction between the syntax allowed in a browser's | is no formal distinction between the syntax allowed in a browser's | |||
| input dialogue box and the syntax allowed in URIs. For this reason, | input dialogue box and the syntax allowed in URIs. For this reason, | |||
| no normative statements are made in this section. | no normative statements are made in this section. | |||
| In practice, although parsers respect the established syntax, they | In practice, although parsers respect the established syntax, they | |||
| are coded pragmatically rather than being formally syntax-driven. | are coded pragmatically rather than being formally syntax-driven. | |||
| Typically, IP address literals are handled by an explicit code path. | Typically, IP address literals are handled by an explicit code path. | |||
| Parsers have been inconsistent in providing for ZoneIDs. Most have | Parsers have been inconsistent in providing for zone identifiers. | |||
| no support, but there have been examples of ad hoc support. For | Most have no support, but there have been examples of ad hoc support. | |||
| example, some versions of Firefox allowed the use of a ZoneID | For example, some versions of Firefox allowed the use of a zone | |||
| preceded by a bare "%" character, but this feature was removed for | identifier preceded by a bare "%" character, but this feature was | |||
| consistency with established syntax [RFC3986]. As another example, | removed for consistency with established syntax [RFC3986]. As | |||
| some versions of Internet Explorer allowed use of a ZoneID preceded | another example, some versions of Internet Explorer allowed use of a | |||
| by a "%" character encoded as "%25", still beyond the syntax allowed | zone identifier preceded by a "%" character encoded as "%25", still | |||
| by the established rules [RFC3986]. This syntax extension is in fact | beyond the syntax allowed by the established rules [RFC3986]. This | |||
| used internally in the Windows operating system and some of its APIs. | syntax extension is in fact used internally in the Windows operating | |||
| system and some of its APIs. | ||||
| It is desirable for all URI parsers to recognise a ZoneID according | It is desirable for all URI parsers to recognise a zone identifier | |||
| to the syntax defined in Section 3. | according to the syntax defined in Section 3. Any code handling | |||
| percent-encoding or percent-decoding must be aware that the "%" | ||||
| character preceding the zone identifier is never itself percent- | ||||
| encoded, as specified by ABNF above. In terms of Section 2.4 of | ||||
| [RFC3986], this "%" character is acting as a delimiter, not as data. | ||||
| URIs including a ZoneID have no meaning outside the originating HTTP | URIs including a zone identifier have no meaning outside the | |||
| client node. However, in some use cases, such as CUPS mentioned | originating HTTP client node. However, in some use cases, such as | |||
| above, the URI will be reflected back to the client. | CUPS mentioned above, the host address embedded in the URI will be | |||
| reflected back to the client, using exactly the representation of the | ||||
| zone identifier that the client sent. | ||||
| The various use cases for the ZoneID syntax will cause it to be | The various use cases for the zone identifier syntax will cause it to | |||
| entered in a browser's input dialogue box. Thus, URIs including a | be entered in a browser's input dialogue box. Thus, URIs including a | |||
| ZoneID are unlikely to occur in HTML documents. However, if they do | zone identifier are unlikely to occur in HTML documents. However, if | |||
| (for example, in a diagnostic script coded in HTML), it would be | they do (for example, in a diagnostic script coded in HTML), it would | |||
| appropriate to treat them exactly as above. | be appropriate to treat them exactly as above. | |||
| 5. Security Considerations | 5. Security Considerations | |||
| The security considerations from the URI syntax specification | The security considerations from the URI syntax specification | |||
| [RFC3986] and the IPv6 Scoped Address Architecture specification | [RFC3986] and the IPv6 Scoped Address Architecture specification | |||
| [RFC4007] apply. In particular, this URI format creates a specific | [RFC4007] apply. In particular, this URI format creates a specific | |||
| pathway by which a deceitful zone index might be communicated, as | pathway by which a deceitful zone index might be communicated, as | |||
| mentioned in the final security consideration of the Scoped Address | mentioned in the final security consideration of the Scoped Address | |||
| Architecture specification. | Architecture specification. | |||
| However, this format is only meaningful for link-local addresses | However, this format is only meaningful for link-local addresses | |||
| under prefix fe80::/10. It is not necessary for web browsers to | under prefix fe80::/10. It is not necessary for web browsers to | |||
| verify this, or to validate the ZoneID, because the operating system | verify this, or to validate the zone identifier, because the | |||
| will do so when the address is passed to the socket API, and return | operating system will do so when the address is passed to the socket | |||
| an error code if the ZoneID is invalid. | API, and return an error code if the zone identifier is invalid. | |||
| It is conceivable that this format could be misused to probe a local | ||||
| network configuration in some way. However, that would only be | ||||
| possible for an attacker that had already gained sufficient control | ||||
| of a host to originate HTTP messages. Such an attacker could more | ||||
| easily probe using basic mechanisms such as the "ping" command. | ||||
| 6. Acknowledgements | 6. Acknowledgements | |||
| The lack of this format was first pointed out by Margaret Wasserman | The lack of this format was first pointed out by Margaret Wasserman | |||
| and later by Kerry Lynn. A previous draft document by Bill Fenner | and later by Kerry Lynn. A previous draft document by Bill Fenner | |||
| and Martin Dürst [LITERAL-ZONE] discussed this topic but was not | and Martin Dürst [LITERAL-ZONE] discussed this topic but was not | |||
| finalised. Michael Sweet and Andrew Cady explained some of the | finalised. Michael Sweet and Andrew Cady explained some of the | |||
| difficulties caused by RFC 6874. The ABNF syntax proposed above was | difficulties caused by RFC 6874. The ABNF syntax proposed above was | |||
| drafted by Andrew Cady. | drafted by Andrew Cady. | |||
| Valuable comments and contributions were made by Karl Auer, Carsten | Valuable comments and contributions were made by Karl Auer, Carsten | |||
| Bormann, Benoit Claise, Martin Dürst, Stephen Farrell, Brian | Bormann, Benoit Claise, Martin Dürst, Stephen Farrell, Brian | |||
| Haberman, Ted Hardie, Philip Homburg, Tatuya Jinmei, Yves Lafon, | Haberman, Ted Hardie, Philip Homburg, Tatuya Jinmei, Yves Lafon, | |||
| Barry Leiba, Radia Perlman, Tom Petch, Michael Richardson, Tomoyuki | Barry Leiba, Ben Maddison, Radia Perlman, Tom Petch, Michael | |||
| Sahara, Juergen Schoenwaelder, Nico Schottelius, Dave Thaler, Martin | Richardson, Tomoyuki Sahara, Juergen Schoenwaelder, Nico Schottelius, | |||
| Thomson, Ole Troan, and others. | Dave Thaler, Martin Thomson, Ole Troan, Shang Ye, and others. | |||
| 7. References | 7. References | |||
| 7.1. Normative References | 7.1. Normative References | |||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
| DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
| <https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
| skipping to change at page 8, line 26 ¶ | skipping to change at page 9, line 21 ¶ | |||
| Address Text Representation", RFC 5952, | Address Text Representation", RFC 5952, | |||
| DOI 10.17487/RFC5952, August 2010, | DOI 10.17487/RFC5952, August 2010, | |||
| <https://www.rfc-editor.org/info/rfc5952>. | <https://www.rfc-editor.org/info/rfc5952>. | |||
| [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
| 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | |||
| May 2017, <https://www.rfc-editor.org/info/rfc8174>. | May 2017, <https://www.rfc-editor.org/info/rfc8174>. | |||
| 7.2. Informative References | 7.2. Informative References | |||
| [CUPS] Apple, "CUPS open source printing system", 2021, | [CUPS] Apple, "Apple CUPS", 2022, <https://www.cups.org/>. | |||
| <https://www.cups.org/>. | ||||
| [LITERAL-ZONE] | [LITERAL-ZONE] | |||
| Fenner, B. and M. Dürst, "Formats for IPv6 Scope Zone | Fenner, B. and M. Dürst, "Formats for IPv6 Scope Zone | |||
| Identifiers in Literal Address Formats", Work in Progress, | Identifiers in Literal Address Formats", Work in Progress, | |||
| October 2005. | October 2005. | |||
| [OP-CUPS] Sweet, M., "OpenPrinting CUPS", 2022, | ||||
| <https://openprinting.github.io/cups/>. | ||||
| [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. | [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. | |||
| Stevens, "Basic Socket Interface Extensions for IPv6", | Stevens, "Basic Socket Interface Extensions for IPv6", | |||
| RFC 3493, DOI 10.17487/RFC3493, February 2003, | RFC 3493, DOI 10.17487/RFC3493, February 2003, | |||
| <https://www.rfc-editor.org/info/rfc3493>. | <https://www.rfc-editor.org/info/rfc3493>. | |||
| [RFC3510] Herriot, R. and I. McDonald, "Internet Printing | ||||
| Protocol/1.1: IPP URL Scheme", RFC 3510, | ||||
| DOI 10.17487/RFC3510, April 2003, | ||||
| <https://www.rfc-editor.org/info/rfc3510>. | ||||
| [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. | [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. | |||
| Schoenwaelder, "Textual Conventions for Internet Network | Schoenwaelder, "Textual Conventions for Internet Network | |||
| Addresses", RFC 4001, DOI 10.17487/RFC4001, February 2005, | Addresses", RFC 4001, DOI 10.17487/RFC4001, February 2005, | |||
| <https://www.rfc-editor.org/info/rfc4001>. | <https://www.rfc-editor.org/info/rfc4001>. | |||
| [RFC6874] Carpenter, B., Cheshire, S., and R. Hinden, "Representing | [RFC6874] Carpenter, B., Cheshire, S., and R. Hinden, "Representing | |||
| IPv6 Zone Identifiers in Address Literals and Uniform | IPv6 Zone Identifiers in Address Literals and Uniform | |||
| Resource Identifiers", RFC 6874, DOI 10.17487/RFC6874, | Resource Identifiers", RFC 6874, DOI 10.17487/RFC6874, | |||
| February 2013, <https://www.rfc-editor.org/info/rfc6874>. | February 2013, <https://www.rfc-editor.org/info/rfc6874>. | |||
| [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer | [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer | |||
| Protocol (HTTP/1.1): Message Syntax and Routing", | Protocol (HTTP/1.1): Message Syntax and Routing", | |||
| RFC 7230, DOI 10.17487/RFC7230, June 2014, | RFC 7230, DOI 10.17487/RFC7230, June 2014, | |||
| <https://www.rfc-editor.org/info/rfc7230>. | <https://www.rfc-editor.org/info/rfc7230>. | |||
| [RFC7472] McDonald, I. and M. Sweet, "Internet Printing Protocol | ||||
| (IPP) over HTTPS Transport Binding and the 'ipps' URI | ||||
| Scheme", RFC 7472, DOI 10.17487/RFC7472, March 2015, | ||||
| <https://www.rfc-editor.org/info/rfc7472>. | ||||
| Appendix A. Options Considered | Appendix A. Options Considered | |||
| The syntax defined above allows a ZoneID to be added to any IPv6 | The syntax defined above allows a zone identifier to be added to any | |||
| address. The 6man WG discussed and rejected an alternative in which | IPv6 address. The 6man WG discussed and rejected an alternative in | |||
| the existing syntax of IPv6address would be extended by an option to | which the existing syntax of IPv6address would be extended by an | |||
| add the ZoneID only for the case of link-local addresses. It was | option to add the zone identifier only for the case of link-local | |||
| felt that the solution presented in this document offers more | addresses. It was felt that the solution presented in this document | |||
| flexibility for future uses and is more straightforward to implement. | offers more flexibility for future uses and is more straightforward | |||
| to implement. | ||||
| The various syntax options considered are now briefly described. | The various syntax options considered are now briefly described. | |||
| 1. Leave the problem unsolved. | 1. Leave the problem unsolved. | |||
| This would mean that per-interface diagnostics would still have | This would mean that per-interface diagnostics would still have | |||
| to be performed using ping or ping6: | to be performed using ping or ping6: | |||
| ping fe80::abcd%en1 | ping fe80::abcd%en1 | |||
| skipping to change at page 10, line 31 ¶ | skipping to change at page 11, line 41 ¶ | |||
| Advantage: allows use of browser; consistent with general URI | Advantage: allows use of browser; consistent with general URI | |||
| syntax. | syntax. | |||
| Disadvantage: somewhat ugly and confusing; doesn't allow simple | Disadvantage: somewhat ugly and confusing; doesn't allow simple | |||
| cut and paste. | cut and paste. | |||
| Appendix B. Change log | Appendix B. Change log | |||
| This section is to be removed before publishing as an RFC. | This section is to be removed before publishing as an RFC. | |||
| * draft-ietf-6man-rfc6874bis-01, 2022-04-07: | ||||
| - Extended use cases | ||||
| - Clarified relationship with RFC3986 language | ||||
| - Allow for legacy use of RFC6874 format | ||||
| - Augmented security considerations | ||||
| - Editorial and reference improvements | ||||
| * draft-ietf-6man-rfc6874bis-00, 2022-03-19: | * draft-ietf-6man-rfc6874bis-00, 2022-03-19: | |||
| - WG adoption | - WG adoption | |||
| - Clarified security considerations | - Clarified security considerations | |||
| * draft-carpenter-6man-rfc6874bis-03, 2022-02-08: | * draft-carpenter-6man-rfc6874bis-03, 2022-02-08: | |||
| - Changed to bare % signs. | - Changed to bare % signs. | |||
| End of changes. 29 change blocks. | ||||
| 82 lines changed or deleted | 135 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||