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)
September, 1997
IPv6 over Point-to-Point ATM Link
<draft-yamamoto-ipv6-over-p2p-atm-00.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 is now 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 September 1997
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 IPv6. 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 desirable to define LLC headers of IPv6 over a point-to-point
ATM link for inter-operability.
3. Standard Keywords
This memo 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 SHOULD be used to exchange IPv6 packets over a
point-to-point ATM link. Null encapsulation SHOULD NOT be used for
IPv6 packets 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[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 September 1997
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 same MTU value is correctly configured for each end of
nodes and if Path MTU Discovery is used for off link communication.
However, it is useful to provide a manual configuration mechanism of
MTU in certain cases. For example, consider 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 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. 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 adddress,
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. Such a node may generate the same interface
identifier for the virtual interfaces, however, it is not a problem
since interface identifier is 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 adddress 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
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
YAMAMOTO [Page 3]
Internet Draft IPv6 over ATM September 1997
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
It is required to implement NDP[NDP] functions on a typical
point-to-point link defined in [NDPP2P].
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). Duplicated Token
Discovery is possible by Duplicated Address Detection.
This memo provides an enough mechanism for current several
well-managed and relatively static ATM environments. IPv6 over PPP
over point-to-point ATM link may be used in the future if
less-managed and/or more dynamic IPv6 on ATM circumstances are
needed and/or 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.
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-02.txt>, 1997.
[ATM-ENCAP] J. Heinanen, "Multiprotocol Encapsulation over ATM
Adaptation Layer 5", RFC1483, 1993.
[ETHER] M. Crawford, "Transmission of IPv6 Packets over Ethernet
Networks", currently draft-ietf-ipngwg-trans-ethernet-02.txt.
[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.
[KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
YAMAMOTO [Page 4]
Internet Draft IPv6 over ATM September 1997
[NDP] T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", Internet-Draft,
<draft-ietf-ipngwg-discovery-v2-00.txt>, 1997.
[NDPP2P] Preparing.
[PPP] Dimitry Haskin and Ed Allen, "IP Version 6 over PPP",
Internet-Draft, <draft-ietf-ipngwg-ipv6-over-ppp-02.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
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.
YAMAMOTO [Page 5]
Internet Draft IPv6 over ATM September 1997
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]
----