[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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]