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.