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.
12. Security Considerations
A limited scope address without a zone index has security
implications and cannot be used for some security contexts. For
example, a link-local address cannot be used in a traffic selector of
a security association established by Internet Key Exchange (IKE)
when the IKE messages are carried over global addresses. Also, a
link-local address without a zone index cannot be used in access
control lists.
The routing section of this document specifies a set of guidelines
whereby routers can prevent zone-specific information from leaking
out of each zone. If, for example, multicast site boundary routers
allow site routing information to be forwarded outside of the site,
the integrity of the site could be compromised.
Since the use of the textual representation of non-global addresses
is restricted to use within a single node, it does not create a
security vulnerability from outside the node. However, a malicious
node might send a packet that contains a textual IPv6 non-global
address with a zone index, intending to deceive the receiving node
about the zone of the non-global address. Thus, an implementation
should be careful when it receives packets that contain textual non-
global addresses as data.
13. Contributors
This document is a combination of several separate efforts. Atsushi
Onoe took a significant role in one of them and deeply contributed to
the content of Section 11 as a co-author of a separate proposal.
14. Acknowledgements
Many members of the IPv6 working group provided useful comments and
feedback on this document. In particular, Margaret Wasserman and Bob
Hinden led the working group to make a consensus on IPv6 local
addressing. Richard Draves proposed an additional rule to process
Routing header containing scoped addresses. Dave Thaler and Francis
Dupont gave valuable suggestions to define semantics of zone indices
in terms of related API. Pekka Savola reviewed a version of the
document very carefully and made detailed comments about serious
problems. Steve Bellovin, Ted Hardie, Bert Wijnen, and Timothy
Gleeson reviewed and helped improve the document during the
preparation for publication.
15. References
15.1. Normative References
[1] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
Addressing Architecture", RFC 3513, April 2003.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[4] Conta, A. and S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification", RFC 2463, December 1998.
15.2. Informative References
[5] Huitema, C. and B. Carpenter, "Deprecating Site Local
Addresses", RFC 3879, September 2004.
[6] Draves, R., "Default Address Selection for Internet Protocol
version 6 (IPv6)", RFC 3484, February 2003.
[7] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration
of Link-Local IPv4 Addresses", Work in Progress.
[8] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6
Specification", RFC 2473, December 1998.
[9] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[10] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493,
February 2003.
[11] Gilligan, R., "Scoped Address Extensions to the IPv6 Basic
Socket API", Work in Progress, July 2002.
[12] Hinden, R., Carpenter, B., and L. Masinter, "Format for Literal
IPv6 Addresses in URL’s", RFC 2732, December 1999.
[13] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 3986, January
2005.
Authors’ Addresses
Stephen E. Deering
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
Brian Haberman
Johns Hopkins University Applied Physics Laboratory
11100 Johns Hopkins Road
Laurel, MD 20723-6099
USA
Phone: +1-443-778-1319
EMail: brian@innovationslab.net
Tatuya Jinmei
Corporate Research & Development Center, Toshiba Corporation
1 Komukai Toshiba-cho, Saiwai-ku
Kawasaki-shi, Kanagawa 212-8582
Japan
Phone: +81-44-549-2230
Fax: +81-44-520-1841
EMail: jinmei@isl.rdc.toshiba.co.jp
Erik Nordmark
17 Network Circle
Menlo Park, CA 94025
USA
Phone: +1 650 786 2921
Fax: +1 650 786 5896
EMail: Erik.Nordmark@sun.com
Brian D. Zill
Microsoft Research
One Microsoft Way
Redmond, WA 98052-6399
USA
Phone: +1-425-703-3568
Fax: +1-425-936-7329
EMail: bzill@microsoft.com
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.