Internet-Draft                                       K. Yamamoto (NAIST)
                                                       K. Cho (Sony CSL)
Expires in six months                                 Y. Inoue (Fujitsu)
                                                      H. Esaki (Toshiba)
                                                   Y. Atarashi (Hitachi)
                                              A. Hagiwara (Bay Networks)

                                                          February, 1998

                  IPv6 over Point-to-Point ATM Link
              <draft-yamamoto-ipv6-over-p2p-atm-01.txt>

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 ds.internic.net (US East Coast), nic.nordu.net
    (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
    Rim).

Abstract

    This memo defines a communication mechanism to exchange both IPv6
    unicast and multicast packets over an ATM network used as a
    point-to-point link.

1. Introduction

    ATM has become one of the most popular link-layer technologies in
    the Internet.  Typical usage of ATM is categorized as follows:

        (1) Broadcast network such as LAN emulation(LANE)
        (2) Non-Broadcast Multiple Access(NBMA) networks
        (3) Point-to-point networks

    This memo discusses a communication mechanism for an IPv6[IPV6] over
    a point-to-point ATM link(3).  One of applications of ATM is a fat
    pipe typically found in backbone networks.

    This memo defines IEEE 802.2 logical link control(LLC) headers for
    IPv6 over a point-to-point ATM link.  The default of MTU size of
    point-to-point ATM and a mechanism to generate an interface
    identifier are also specified.


Yamamoto                                                        [Page 1]


Internet Draft                IPv6 over ATM                February 1998

2. Scope of This Memo

    Throughout this memo, the term "point-to-point ATM link" means that
    one virtual circuit(VC) is established between two nodes and the VC
    can be accessible through one logical network interface.  This link
    is abstracted as a serial link to the IPv6 layer.  It is not our
    intention to recommend that ATM be used exclusively for
    point-to-point networks.

    In this memo, ATM Adaptation Layer 5(AAL5)[ATM-ENCAP] is assumed to
    carry IPv6 packets over ATM.  Both IPv6 unicast and multicast
    packets are delivered only to the opposite end of the point-to-point
    ATM link.

    Please note that point-to-point ATM link here is not a special case
    of NBMA(2).  While NBMA requires a special mechanism for multicast,
    a point-to-point ATM link here does not require it.

    There is strong demand to implement an IPv6 network over a
    point-to-point ATM link without such a special mechanism.  So, it is
    highly desired to define LLC headers of IPv6 over a point-to-point
    ATM link for inter-operability.

3. Standard Keywords

    This memo occasionally uses terms which are in capital letters.
    When the terms "MUST", "SHOULD", "MUST NOT", "SHOULD NOT", and "MAY"
    appear capitalized, they are being used to indicate particular
    requirements, whose definitions are found in [KEYWORDS].

4. IPv6 packet encapsulation

    LLC encapsulation is adopted to exchange IPv6 packets over a
    point-to-point ATM link in this memo.  Null encapsulation is not
    adapted since it is very likely that both IPv6 and IPv4 are used on
    a point-to-point ATM link at the same time.

    0x86DD is assigned for the EtherType of IPv6[IPV6-ETHER], so this
    memo chooses 0x86DD as the Protocol Identifier(PID) according to
    [ATM-ENCAP].  The encapsulation for both IPv6 unicast and multicast
    on a point-to-point ATM link is defined as follows:

               +-------------------------------+
               |       LLC 0xAA-AA-03          |
               +-------------------------------+
               |       OUI 0x00-00-00          |
               +-------------------------------+
               |       PID 0x86-DD             |
               +-------------------------------+
               |             .                 |
               |       IPv6 packet             |
               |             .                 |
               +-------------------------------+


Yamamoto                                                        [Page 2]


Internet Draft                IPv6 over ATM                February 1998

5. MTU size

    The default MTU size for IPv6 over point-to-point ATM SHOULD be 9180
    octets according to [AAL5-MTU].  Values other than the default MAY
    be used.

    An automatic negotiation mechanism for the MTU is not defined in
    this memo.  It is not usually necessary on ATM point-to-point links
    as long as the same MTU value is correctly configured at each end
    of nodes.

    However, it is useful to provide a configuration mechanism of MTU in
    certain cases.  For example, suppose that a host and a router are
    connected with a point-to-point ATM link and the router is also
    attached to a LAN whose MTU is smaller than 9180.  To prevent
    overhead of Path MTU Discovery triggered by the host, an
    administrator may wish to configure the MTU of the ATM interface to
    the smaller one in the router.  This value will be announced to the
    host via Router Advertisements(RA) through the point-to-point ATM
    link then the host will adjust its MTU for the link.

6. Interface Identifier

    An interface for a point-to-point ATM link MUST have a 64 bit
    interface token for IPv6.  It MUST be unique within the link.  That
    is, for the point-to-point ATM link, it MUST be different from the
    peer's token.

    The interface token SHOULD be generated according to the following
    steps:

    (A) If the ATM interface has an EUI 64 bit MAC address, generate an
        interface identifier with it according to "Links or Nodes with
        EUI-64 Identifiers" in Appendix A of [AARCH].

    (B) If the ATM interface has an IEEE 802 48 bit MAC address,
        generate an interface identifier with it according to "Links or
        Nodes with IEEE 802 48 bit MAC's" in Appendix A of [AARCH].

    Note: A node may have multiple virtual interfaces on a single
    physical ATM interface.  Though such a node may generate the same
    interface identifier for the virtual interfaces, it is not a problem
    since interface identifiers are not necessarily unique on the node.

    (C) If an EUI 64 bit MAC address is available anywhere on the node,
        generate an interface identifier with it according to "Links or
        Nodes with EUI-64 Identifiers" in Appendix A of [AARCH].

    (D) If an IEEE 802 48 bit MAC address is available anywhere on the
        node, generate an interface identifier with it according to
        "Links or Nodes with IEEE 802 48 bit MAC's" in Appendix A of
        [AARCH].

    (E) If an IEEE global identifier is not available, a different

Yamamoto                                                        [Page 3]


Internet Draft                IPv6 over ATM                February 1998

        source of uniqueness should be used.  For example, a suggested
        source of uniqueness is machine serial numbers.  If such a source
        is available, generate an interface identifier with it according
        to "Links with Non-Global Identifiers" in Appendix A of [AARCH].

    (F) If a good source of uniqueness cannot be found, generate an
        interface identifier with a random number according to "Links
        with Non-Global Identifiers" in Appendix A of [AARCH].

7. Neighbor Discovery

    As of this writing, NDP[IPV6-ND] over point-to-point links is being
    discussed in IPng working group.  If an RFC on this topic will
    appear in the future, NDP over point-to-point ATM links is required
    to implement according to the RFC.

    Until such an RFC becomes available, this memo specifies the
    following requirements.  If a node receives a Neighbor Solicitation
    message from its peer through the point-to-point ATM link, the node
    MUST send a Neighbor Advertisement message in response.  A node MUST
    NOT discard a Neighbor Solicitation message nor a Neighbor
    Advertisement message even if a link layer address option is not
    included in the message or if a link layer address option with an
    unknown format to the node is included in the message.  This is
    because link layer address resolution is not necessary on
    point-to-point ATM links.  Moreover, in all cases, any link layer
    address options SHOULD be ignored since they do not provide any
    useful information.

8. Relationship with PPP

    This memo is one of the current simple solutions.  PPP[PPP] is a
    more advanced solution with more features and subsequently needs
    more resources.  Currently, the only feature provided by PPP which
    is not covered by this memo is Maximum Receive Unit (MRU)
    negotiation.  Duplicated Token Discovery is possible by Duplicated
    Address Detection defined in [IPV6-AUTO].

    This memo provides an enough mechanism for current several
    well-managed and relatively static ATM environments.  IPv6 over PPP
    over a point-to-point ATM link combined with [PPP] and [PPPATM] may
    be used in the future if less-managed and more dynamic IPv6 on ATM
    circumstances are needed or if more useful configuration options are
    defined for it.

9. Security Consideration

    It is believed that this memo does not introduce new security
    problems to IPv6.

Acknowledgements

    The authors thank Katsushi KOBAYASHI, Noritoshi DEMIZU, and Tetsuya
    JINMEI for their feedback for early versions of this draft.

Yamamoto                                                        [Page 4]


Internet Draft                IPv6 over ATM                February 1998


References

    [AAL5-MTU] R. Atkinson, "Default IP MTU for use over ATM AAL5", RFC
        1626, 1994.

    [AARCH] R. Hinden and S. Deering "IP Version 6 Addressing
        Architecture", Internet-Draft,
        <draft-ietf-ipngwg-addr-arch-v2-06.txt>, 1997.

    [ATM-ENCAP] J. Heinanen, "Multiprotocol Encapsulation over ATM
        Adaptation Layer 5", RFC1483, 1993.

    [EUI64] "64-Bit Global Identifier Format Tutorial",
            http://standards.ieee.org/db/oui/tutorials/EUI64.html.

    [IPV6] S. Deering and R. Hinden, "Internet Protocol, Version 6
        (IPv6) Specification", RFC 1883, 1996.

    [IPV6-AUTO] S. Thomson and T. Narten, "IPv6 Stateless Address
        Autoconfiguration", Internet-Draft,
        <draft-ietf-ipngwg-addrconf-v2-01.txt>, 1997

    [IPV6-ETHER] M. Crawford, "Transmission of IPv6 Packets over
        Ethernet Networks", Internet-Draft,
        <draft-ietf-ipngwg-trans-ethernet-04.txt>, 1997.

    [IPV6-ND] T. Narten, E. Nordmark, and W. Simpson, "Neighbor
        Discovery for IP Version 6 (IPv6)", Internet-Draft,
        <draft-ietf-ipngwg-discovery-v2-01.txt>, 1997.

    [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate
        Requirement Levels", RFC 2119, March 1997.

    [PPP] D. Haskin and E. Allen, "IP Version 6 over PPP",
        Internet-Draft, <draft-ietf-ipngwg-ipv6-over-ppp-05.txt>, 1997.

    [PPPATM] G. Gross, M. Kaycee, A. Lin, A. Mails, and J. Stephens,
        "PPP Over AAL5", Internet-Draft,
        <draft-ietf-pppext-aal5-04.txt>, 1997.


Author's Address

    Kazuhiko YAMAMOTO
    Graduate School of Information Science
    Nara Institute of Science and Technology(NAIST)
    8916-5 Takayama, Ikoma 630-01 JAPAN

    Phone: +81-743-72-5111
    FAX:   +81-743-72-5329
    EMail: Kazu@Mew.org



Yamamoto                                                        [Page 5]


Internet Draft                IPv6 over ATM                February 1998

    Kenjiro CHO
    Sony Computer Science Laboratory Inc.
    3-14-13 Higashi-Gotanda, Shinagawa-ku 141 JAPAN

    Phone: +81-3-5448-4380
    FAX:   +81-3-5448-4273
    EMail: kjc@csl.sony.co.jp

    Yoshinobu INOUE
    Fujitsu Limited
    4-1-1 Kamikodanaka, Nakahara-ku, Kawasaki 211-88 JAPAN

    Phone: +81-44-754-3263
    FAX:   +81-44-754-3864
    EMail: shin@nd.net.fujitsu.co.jp

    Hiroshi ESAKI
    Computer and Network Product Division, Toshiba Corporation
    Suite 19A, 1-1-1 Shibaura, Minato-ku 105-01 JAPAN

    Phone: +81-3-3457-2563
    FAX:   +81-3-5444-9331
    EMail: hiroshi@isl.rdc.toshiba.co.jp

    Yoshifumi ATARASHI
    Office Systems Division, Hitachi, Ltd.
    810 Shimoimaizumi, Ebina-shi 243-04 JAPAN

    Phone: +81-462-35-2111
    FAX:   +81-462-35-8325
    EMail: atarashi@ebina.hitachi.co.jp

    Atsushi HAGIWARA
    Bay Networks K.K.
    28th Shiroyama JT Mori bldg.
    4-3-1, Torano-mon, Minato-ku 105 JAPAN

    Phone: +81-3-5402-7001
    FAX:   +81-3-5402-0179
    EMail: ahagiwar@baynetworks.co.jp















Yamamoto                                                        [Page 6]