INTERNET-DRAFT T. Jinmei, Toshiba October 21, 1999 A. Onoe, Sony An Extension of Format for IPv6 Scoped Addresses Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026 [STD-PROC]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet Draft will expire on April 21, 2000. Abstract This document defines an extension of the format for IPv6 scoped addresses. In the format, a scope identifier is attached to a scoped address in order to supplement the ambiguity of the semantics of the address. Using the format with some library routines will make scope-aware applications simpler. 1. Introduction There are several types of scoped addresses defined in the "IPv6 Addressing Architecture" [ADDRARCH]. Since uniqueness of a scoped address is guaranteed only within the according scope, the semantics for a scoped address is ambiguous on a scope boundary. For example, when a user specifies to send a packet from a node to a link-local address of another node, the user must specify the link of the destination as well, if the node is attached to more than one link. This characteristic of scoped addresses may introduce additional cost to scope-aware applications; a scope-aware application may have to provide a way to specify an instance of a scope for each scoped address (e.g. a specific link for a link-local address) that the application uses. Also, it is hard for a user to "cut and paste" a scoped address due to the ambiguity of its scope. draft-ietf-ipngwg-scopedaddr-format-00.txt [Page 1] INTERNET-DRAFT Format for IPv6 Scoped Addresses October 1999 This document defines an extension of the format for scoped addresses in order to overcome this inconvenience. Using the extended format with some appropriate library routines will make scope-aware applications simpler. 1.1 Requirements The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, if and where they appear in this document, are to be interpreted as described in [KEYWORDS]. 2. Proposal The proposed format for scoped addresses is where is a literal IPv6 address, is a string to identify the scope of the address, and is a string to distinguish between and . It can't be assumed that a same identifier is common to all nodes in the according scope. Hence the proposed format MUST be used only within a node and MUST NOT be sent on a wire. This also means that any character or string can be used as unless it conflicts with other symbols used in literal IPv6 addresses (for instance, ":" would be confusing and should not be used as .) However, the notation of and should be common within a single node. The proposed format should be applied to multicast addresses as well as to unicast addresses. Here are examples. If the dash character (`-') is used as and numerical identifiers are used as , the following addresses fe80::1234 (whose link identifier is 1) fec0::5678 (whose site identifier is 2) ff02::9abc (whose link identifier is 5) ff08::def0 (whose organization identifier is 10) would be represented as follows: fe80::1234-1 fec0::5678-2 ff02::9abc-5 ff08::def0-10 As mentioned above, other strings could be used as and . The addresses in the example could be represented as follows: Address fe80::1234,ether1 `,' "ether1" fec0::5678%foo.com `%' "foo.com" draft-ietf-ipngwg-scopedaddr-format-00.txt [Page 2] INTERNET-DRAFT Format for IPv6 Scoped Addresses October 1999 ff02::9abc++A "++" "A" ff08::def0=ORG=XY-net "=ORG=" "XY-net" 3. Interaction with API The proposed format would be useful with some library functions defined in the "Basic Socket API" [BASICAPI], that translate a nodename to an address, or vice versa. For example, if getaddrinfo() parses a literal IPv6 address in the proposed format and fill an identifier according to in the sin6_scope_id field of a sockaddr_in6 structure, then an application would be able to just call getaddrinfo() and would not have to care about scopes. Also, if getnameinfo() returns IPv6 scoped addresses in the proposed format, a user or an application would be able to reuse the result by a simple "cut and paste" method. Note that these extensions to the API ensure lower compatibility and do not affect any existing applications. 4. Issues This document does not define a specific string for , since it would be used only within a node and hence be implementation dependent. However, it might be better to define a standard one in order to ensure portability on various implementations. In this document, it is assumed that an identifier of a scope is not necessarily common in the scope. However, it would be useful if some common notation is introduced (e.g. an organization name for a site). In such a case, the proposed format could be commonly used to designate a single interface (or a set of interfaces for a multicast address) in a scope. When the network configuration of a node changes, the change may affect . Suppose that the case where numerical identifiers are sequentially used as . When a network card is newly inserted in the node, some identifiers may have to be renumbered accordingly. This would be inconvenient, especially when addresses with the numerical identifiers are stored in non-volatile storage and reused after rebooting. There is the preferred format for literal IPv6 addresses in URL's [URLFORMAT]. When the preferred format is used for an IPv6 scoped address, it might have to be combined with the proposed format defined in the document. For example, http://[fec0::1234-bar.com]:80/index.html should be used instead of http://[fec0::1234]:80/index.html draft-ietf-ipngwg-scopedaddr-format-00.txt [Page 3] INTERNET-DRAFT Format for IPv6 Scoped Addresses October 1999 (in this example, the dash character '-' is used as , and the string "bar.com" is used as .) The combination would introduce some restrictions to and . For instance, `]' should not appear in nor in . 5. Implementation Experiences The WIDE KAME IPv6 stack implements the extension to the getaddrinfo() and the getnameinfo() functions described in Section 3 of this document. The source code is available as free software, bundled in the KAME IPv6 stack kit. The current implementation supports the extension only for link-local (unicast and multicast) addresses. Also, the implementation assumes that there is one-to-one mapping between links and interfaces, and hence it uses interface names as for links. As it uses the atmark(@). For instance, the implementation shows its routing table as follows: Internet6: Destination Gateway Flags Intface default fe80::fe32:93d1@ef0 UG ef0 This means that the default router is fe80::fe32:93d1 on the link identified by interface "ef0". A user can "cut and paste" the result in order to telnet to the default router like this: % telnet fe80::fe32:93d1@ef0 6. Security Considerations The use of this approach to represent IPv6 scoped addresses does not introduce any known new security concerns, since the use is restricted within a single node. 7. Authors' Addresses Tatuya JINMEI Research and Development Center, Toshiba Corporation 1 Komukai Toshiba-cho, Kawasaki-shi Kanagawa 210-8582, JAPAN Tel: +81-44-549-2238 Fax: +81-44-520-1841 Email: jinmei@isl.rdc.toshiba.co.jp Atsushi Onoe Internet Systems Laboratory, IN Laboratories, Sony Corporation 6-7-35 Kitashinagawa, Shinagawa-ku, Tokyo 141-0001, JAPAN Tel: +81-3-5448-4620 Fax: +81-3-5448-4622 Email: onoe@sm.sony.co.jp draft-ietf-ipngwg-scopedaddr-format-00.txt [Page 4] INTERNET-DRAFT Format for IPv6 Scoped Addresses October 1999 8. References [ADDRARCH] Hinden, R., Deering, S., "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [BASICAPI] Gilligan, R. E., Thomson, S., Bound, J., Stevens, W., "Basic Socket Interface Extensions for IPv6", RFC 2553, March 1999. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [STD-PROC] Bradner, S., The Internet Standards Process -- Revision 3, RFC 2026, October 1996. [URLFORMAT] Hinden, R., Carpenter, B., Masinter, L., "Preferred Format for Literal IPv6 Addresses in URL's", Internet Draft, September 1999, draft-ietf-ipngwg-scopedaddr-format-00.txt [Page 5]