Internet-Draft Kazu Yamamoto draft-yamamoto-wideipv6-comm-model-00.txt NAIST Expires in six months Atsushi Onoe Sony Akira Kato The University fo Tokyo September 1996 The IPv6 communication model Status of this Memo This document is an Internet-Draft. 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." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This memo discusses semantics of communication with IPv6 addresses. This model introduces three address scope classes, node-local, site-local, and global, for both IPv6 unicast and multicast addresses. For a given packet, all addresses in the packet including those in the routing header must be in the same address scope class. Since the sockaddr_in6 address data structure is extended to be able to hold an interface index number, a kernel and applications can exchange interface information. A source address is uniquely determined with the destination address and the outgoing interface. This memo also clarifies packet processing mechanism for the input, forward, and output function. 1. Introduction Though RFC1884[1] introduced scope for IPv6 address architecture, its semantics is not clear. For example, the following questions are often asked: (1) Are semantics of unicast scope and that of multicast scope equal? (2) What are site-local-use addresses? (3) How to use multicast scope? (4) How to select a source address for a given destination address? YAMAMOTO [Page 1]
Internet-Draft The IPv6 communication model September 1996 (5) How does a routing daemon know an incoming interface where routing advertisement announced to link-local multicast comes? This memo intends to clarify semantics of IPv6 address scope and to define a communication model for IPv6. It is intended to provoke discussion to lead a general consensus. 2. Address Scope Class To avoid confusion of terminology, this memo first defines one term "address scope class" or "scope-class" as a short representation. Each IPv6 address is categorized to exactly one scope-class out of node-local, link-local, and global. An IPv6 addresses in node-local scope-class are valid inside the node only. Likewise IPv6 addresses in link-local scope-class are valid inside the link only. IPv6 addresses in global scope-class are valid in the entire Internet. Concrete categorization will be discussed later in this memo. Please note that this memo carefully distinguishes the term "scope" for multicast in RFC1884 and the term "scope-class". For convenience, this memo defines one function called "SC()" which takes one IPv6 address as argument and returns a scope-class out of node-local, link-local, and global. Their total ordering is also defined as follows: node-local < link-local < global To ensure communication, this memo defines a basic principle for a given IPv6 packet as follows: SC(src) = SC(r1) = SC(r2) = ... = SC(rn) = SC(dst) where "src" is the source address, "dst" is the destination address, and r1, r2, ..., rn are intermediate nodes specified in the routing header. This basic principle can be logically proved as follows: (1) In general, SC(src) must be greater than or equal to SC(dst). That is, SC(src) >= SC(dst) must be satisfied. If not, it is often happened that the receiving node cannot send back packets to the sending node. (2) If two nodes are on the same link, SC(dst) may be greater than SC(src). For example, node A sends a packet to node B where scope-class of its source address is link-local and that of destination is global. In this case, node B can send back packets to node A where scope-class of its source address is global and that of destination is link-local. Unfortunately, there is no way to tell that the two nodes are on the same link YAMAMOTO [Page 2]
Internet-Draft The IPv6 communication model September 1996 in IPv6 scheme. (3) If two nodes are not on the same link, the following condition must be satisfied according to (1): SC(src) >= SC(r1) >= SC(r2) >= ... >= SC(rn) >= SC(dst) Considering a reply packet, the following condition must be satisfied: SC(src) <= SC(r1) <= SC(r2) <= ... <= SC(rn) <= SC(dst) Therefore, the following condition must be satisfied to ensure communication for two nodes which are not on the same link. SC(src) = SC(r1) = SC(r2) = ... = SC(rn) = SC(dst) (4) According to (2) and (3), the basic principle is introduced. 3. Address Scope Class Categorization Each IPv6 address are categorized to scope-class as follows: Unicast and Anycast SC(::1) = node-local Memo: the loopback address SC(FE80::/10) = link-local Memo: link-local-use addresses SC(others) = global Memo: any other addresses including site-local-use addresses and provider based addresses Multicast SC(FF?1/16) = node-local Memo: node local scope multicast addresses SC(FF?2/16) = link-local Memo: link local scope multicast addresses SC(FF/8) = global Memo: any other multicast addresses including site-local scope, organization-local scope, global scope Both the loopback address and node-local scope multicast addresses are valid inside a node by definition. So, it is reasonable to give them node-local scope-class. Link-local-use addresses are IP representations of MAC addresses and are necessary for NDP[2]. They are valid inside the link by definition. Link-local scope multicast addresses are also valid inside the link by definition. So, it is reasonable to categorize them to link-local scope-class. Any communication rather than NDP can be done with global scope-class addresses, though, it is basically a good idea to use link-local scope-class address to YAMAMOTO [Page 3]
Internet-Draft The IPv6 communication model September 1996 ensure that packets are not forwarded to other links. Good examples are kinds of routing protocol. RFC1884 defines neither semantics of site-local-use unicast addresses nor that of site-local scope of multicast addresses. It was suggested to define scope-class for each multicast scope such as site-local and organization-local for a sophisticated communication model. Suppose that lower 64 bits are chosen to be unique inside a site and upper 64 bits are assigned by its provider. A global address is generated by concatenating the upper 64 bits and the lower 64 bits while a site-local-use address is generated by concatenating FEC0::/64 and the lower 64 bits. In this case, it is easy to change the provider to another and to maintains communication inside the site using the site-local-use address during the reassign period of global address. But it is very likely that poor hosts cannot handle such sophisticated communication. For address reassignment, another mechanism such as auto-configuration should be developed. Unfortunately organization-local-use address are not defined in RFC1884, so organization-local scope-class for organization-local multicast addresses cannot be defined. This violates the basic principle. Moreover, address selection is much difficult in this model. For instance, with given a name of target host, how to resolve both its link-local-use address and global address and then how to select the best one out of them? If sites/organizations are allowed to be connected by a router, it must have multiple routing tables for the sites/organizations. This makes packet forwarding mechanism very complicated. This memo tries to make the communication model as simple as possible for feasibility inheriting reasonable parts of the IPv4 communication model. Thus, scope-class of site-local-use addresses is global and they are used as PRIVATE defined in [3], that is, free but not unique in the Internet. Likewise, site-local scope multicast and organization-local scope multicast are categorized as global scope-class. Their scope is used for filtering purpose. 4. Link-local Scope-class and Interface Selection Applications such as routing daemon cannot determine incoming/outgoing interface for a given link-local scope-class address in the original IPv6 scheme. So, it is necessary to define generic API to resolve this problem. This memo defines an interface index member for the sockaddr_in6 address data structure specified in [4]. The interface index number is unique on a node and orthogonal against IPv6 address. That is, the interface index number is not encoded into an IPv6 address. struct sockaddr_in6 { u_char sin6_len; /* length of this struct */ u_char sin6_family; /* AF_INET6 */ u_int16m_t sin6_port; /* Transport layer port # */ u_int32m_t sin6_flowinfo; /* IPv6 flow information */ YAMAMOTO [Page 4]
Internet-Draft The IPv6 communication model September 1996 u_int32m_t sin6_ifindx; /* Interface Index */ u_int32m_t sin6_pad; /* Reserved */ struct in6_addr sin6_addr; /* IPv6 address */ }; An application specifies an outgoing interface for sending data with the interface index number to the kernel. If the destination address is in node-local scope-class, the kernel ignores the specified interface index number and chooses the loopback interface. If in link-local scope-class, the kernel use the specified interface index number to choose interface. If the destination address is unicast and in global scope-class, the kernel ignores the specified interface index number and chooses a interface according to the routing table. For the case where the destination address is multicast and in global scope-class, this memo does not define any actions and leaves it as an open problem. When you send a multicast packet, this structure may be more useful than specifying the outgoing interface via the setsockopt() function. Discussion is required. The kernel tells the application the incoming interface for the incoming packet with the interface index number. 5. Source Address Selection Any physical interface must have exactly one link-local-use address. Any physical interface must have one "primary" global scope-class address and may have one or more "secondary" global scope-class addresses. The loopback interface has only "::1", node-local scope-address. If a destination address is in node-local scope-class, the source address must be "::1". If a destination address is in link-local scope-class, the source address must be the link-local-use address of the outgoing interface. For example, consider the case to send data to "FF01::1", all node multicast address. An application specifies an interface index number as well as the destination address. Kernel can select the link-local-use address of the given interface. If a destination address is in global scope-class, the source address must be one of primary global scope-class addresses assigned to interfaces. If a source address has been already chosen for the communication (like TCP), it is used independent on the outgoing interface. Otherwise (like UDP), the primary global scope-class address of the outgoing interface is selected as a source address. That is, as far as global scope-class unicast addresses are concerned, a node can listen to all packets destined to all addresses assigned to its interfaces but must use the primary global scope-class addresses when it speaks. The BSD API bind() function specifies a listening address and a YAMAMOTO [Page 5]
Internet-Draft The IPv6 communication model September 1996 listening port. This rule can apply for both unicast address and multicast address. If the bind() function is called with a specific unicast address, the source address of the communication is the unicast address. If the bind() function is called with IPV6ADDR_ANY_INIT or a multicast address, both the destination address of the incoming packet and the incoming interface can be resolved by the recvfrom() function thanks to sockaddr_in6 extension defined in this memo. The source address of outgoing packets generated by the sendto() function and the outgoing interface are determined by the rule described up above. 6. Packet Processing This section defines how to process packets according to their scope-class. It is supposed that hosts have input and output routines for IPv6 packets. It is also assumed that routers have a forward routine in additions to input and output routines. Illegal packets are filtered out on the beginning of each routines as follows: routine (PACKET) { if (SC(src of PACKET) is NG) { Discard the packet. Generate an ICMP error message if necessary. } if (SC(dst of PACKET) is NG) { Discard the packet. Generate an ICMP error message if necessary. } Do the routine job. } Here is a summary table for the three routines. <input> <forward> <output> Source Unicast unspecified OK not clear(*1) OK loopback from lo0(*2) meaningless(*3) to lo0(*4) link OK NG OK site OK if !pbound(*5) OK global OK OK OK undefined OK OK OK Multicast NG NG NG Anycast same as UC(*6) same as UC(*6) NG Destination Unicast/Anycast unspecified NG NG NG loopback from lo0(*2) meaningless(*3) to lo0(*4) link OK NG OK YAMAMOTO [Page 6]
Internet-Draft The IPv6 communication model September 1996 site OK if !pbound(*5) OK global OK OK OK undefined OK OK OK Multicast node from lo0(*2) meaningless(*3) to lo0(*4) link OK NG OK site OK if !sbound(*7) OK organization OK if !obound(*8) OK global OK OK OK undefined NG NG NG OK -- Put the packet into the forward step. NG -- Discard the packet. *1 -- Need to research to fill this blank *2 -- If the packet comes from the loopback interface, OK. Otherwise, NG. *3 -- It is meaningless to forward this packet. The action is implementation dependent. *4 -- If the packet goes to the loopback interface, OK. Otherwise, NG. *5 -- If the packet is forwarded to the same private Internet, OK. Otherwise, NG. *6 -- Cannot distinguish anycast packets from unicast in input or forward routine. So, follow the same action of unicast. *7 -- If the packet is forwarded to the same site, OK. Otherwise, NG. *8 -- If the packet is forwarded to the same organization OK. Otherwise, NG. Implementation Note: some filter rules can be omitted to optimize performance. Appendix To conform this memo, some application must take an interface as an argument. A typical example is an ICMP ECHO/REPLY application called "ping". Here is a table of an outgoing interface and a source address for a given destination address and a given interface. That is, an action summary of "ping -i <interface> <destination>". Outgoing Interface Source Address <destination> Unicast/Anycast node-local the loopback "::1" link-local <interface> the link-local-use address of <interface> global an interface the primary global resolved from scope-class address of the routing table the interface left Multicast YAMAMOTO [Page 7]
Internet-Draft The IPv6 communication model September 1996 node-local the loopback "::1" link-local <interface> the link-local-use address of <interface> global an open problem an open problem Author's Address Kazuhiko YAMAMOTO Nara Institute of Science and Technology(NAIST) 8916-5 Takayama, Ikoma City 630-01 JAPAN Phone: +81-7437-2-5111 FAX: +81-7437-2-5329 EMail: kazu@is.aist-nara.ac.jp Atsushi ONOE Sony Corporation 3-3-1 Tsujido Shinmachi, Fujisawa City 251 JAPAN Phone: +81-466-30-4033 FAX: +81-466-30-4205 EMail: onoe@sm.sony.co.jp Akira KATO The University of Tokyo 2-11-16 Yayoi Bunkyo 113 JAPAN Phone: +81-3-3812-2111 ext 2726 FAX: +81-3-5684-7775 EMail: kato@wide.ad.jp References [1] R. Hinden, and S. Deering, "IP Version 6 Addressing Architecture", RFC1884, 1995. [2] T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC1970, 1996. [3] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, and E. Lear, "Address Allocation for Private Internets", RFC1918, 1996. [4] R. E. Gilligan, S. Thomson, and J. Bound, "Basic Socket Interface Extensions for IPv6", Internet-Draft, <draft-ietf-ipngwg-bsd-api-05.txt>, 1996. YAMAMOTO [Page 8]