RFC 2492

IPv6 over ATM Networks

📅 published January 1999, from ietf

RFC 2492: IPv6 over ATM Networks 🦋

okay bestie, so this one is RFC 2492, titled IPv6 over ATM Networks 💖 It's a Standards Track doc (so it's an actual standard, not just vibes), published January 1999. The authors are G. Armitage (Lucent Technologies), P. Schulter (BrightTiger Technologies), and M. Jork (Digital Equipment GmbH). The title block doesn't list anything it obsoletes or updates 🌸

Status of this Memo ✨

so this doc specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements. for the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). distribution of this memo is unlimited 🫶

Copyright (C) The Internet Society (1999). All Rights Reserved.

Abstract 🌈

this doc is a companion to the ION working group's architecture doc, "IPv6 over Non Broadcast Multiple Access (NBMA) networks" 🧚 it explains how to apply the IPv6 over NBMA architecture to ATM networks. the architecture keeps conventional host-side operation of the IPv6 Neighbor Discovery protocol, and it also supports setting up 'shortcut' ATM forwarding paths (when using SVCs) ✨ running over administratively configured Point to Point PVCs is supported too.

1. Introduction 💖

this is the ATM-specific companion to the ION working group's "IPv6 over Non Broadcast Multiple Access (NBMA) networks" spec [1] 🎀 the terminology and architecture stuff won't be repeated here, so go read [1] if you need it.

ATM can give you point to point PVC service, or flexible point to point and point to multipoint SVC service, and this document covers both 🦋

a minimally conforming IPv6/ATM driver SHALL support the PVC mode of operation. and an IPv6/ATM driver that supports the full SVC mode SHALL also support PVC mode of operation. no skipping PVC 😭

2. Specification Terminology 🌸

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [16]. this is the decoder ring for every capital word you'll see below 🔥

3. PVC Environments 🧚

when ATM is used in PVC mode, each PVC connects exactly two nodes, so Neighbor Discovery and other IPv6 features are limited. IPv6/ATM interfaces only have one neighbor on each Link 👑 the MARS and NHRP protocols are not necessary here, because multicast and broadcast collapse down to an ATM level unicast operation. dynamically discovered shortcuts are NOT supported in this mode 💀

the actual details of encapsulations, MTU, and link token generation come in the following sections 🍓

using PVC links doesn't require extensions to the Neighbor Discovery protocol, and it doesn't forbid them either. the extensions might be developed for general use or for use in PVC connections (for example, Inverse Neighbor Discovery) ✨

since ATM PVC links don't use link-layer addresses, the link-layer address options SHOULD not be included in any ND message [11]. if a link-layer address option does show up in an ND message anyway, the option SHOULD be ignored 🙈

a minimally conforming IPv6/ATM driver SHALL support the PVC mode of operation. PVC only implementations are not required to support any SVC mode of operation 💜

3.1 Default Packet Encapsulation 🎀

following the model in RFC 1483 [2], AAL5 SHALL be the default Adaptation Layer service, and (LLC/SNAP) encapsulation SHALL be the default encapsulation used by unicast and multicast packets across pt-pt PVC links. as defined in [1], the default IPv6 packet encapsulation SHALL be:

      [0xAA-AA-03][0x00-00-00][0x86-DD][IPv6 packet]
          (LLC)       (OUI)     (PID)

3.2 Optional null encapsulation 🦋

IPv6/ATM drivers MAY also support null encapsulation as a configurable option. when null encapsulation is enabled, the IPv6 packet goes straight to the AAL5 layer. both ends of the PVC MUST be configured to use null encapsulation, and the PVC won't be available for protocols other than IPv6 🫶

3.3 PPP encapsulation 🌈

the concatenation of IPv6 over PPP with PPP over AAL5 PVCs is not covered by this spec 🧚

3.4 MTU For PVC Environments 💖

the default IP MTU size for PVC links is 9180 bytes, as specified in [7]. other IP MTU values MAY be used ✨

3.5 Interface Token Formats in PVC Environments 👑

when ATM is used in PVC mode, interface tokens SHALL be generated using one of the methods described in section 5. interface tokens only need to be unique between the two nodes on the PVC link 🍓

4 SVC environments 💅

4.1 SVC Specific Code Points 🔥

4.1.1 ATM Adaptation Layer encapsulation for SVC environments 🌸

following the model in RFC 1483 [2], AAL5 SHALL be the default Adaptation Layer service, and (LLC/SNAP) encapsulation SHALL be the default encapsulation used by unicast and multicast packets across SVC links 🎀

4.1.2 Unicast Packet Encapsulation 🦋

as defined in [1], the default IPv6 unicast packet encapsulation SHALL be:

      [0xAA-AA-03][0x00-00-00][0x86-DD][IPv6 packet]
          (LLC)       (OUI)     (PID)

4.1.3 Multicast packet encapsulation 🧚

as defined in [1], the default IPv6 multicast packet encapsulation SHALL be:

      [0xAA-AA-03][0x00-00-5E][0x00-01][pkt$cmi][0x86DD][IPv6
      packet]
          (LLC)       (OUI)     (PID)    (mars encaps)

the IPv6/ATM driver's Cluster Member ID SHALL be copied into the 2 octet pkt$cmi field prior to transmission 💜

4.1.4 Optional null encapsulation 🌈

IPv6/ATM drivers MAY also support null encapsulation as a configurable option. null encapsulation SHALL only be used for passing IPv6 packets from one IPv6/ATM driver to another. null encapsulation SHALL NOT be used on the pt-pt SVC between the IPv6/ATM driver and its local MARS 🚫

if null encapsulation is enabled, the IPv6 packet goes straight to the AAL5 layer. both ends of the SVC MUST agree to use null encapsulation during the call SETUP phase. the SVC won't be available for protocols other than IPv6 😭

if null encapsulation is enabled on data SVCs between routers, inter-router NHRP traffic SHALL utilize a separate, parallel SVC 🫶

use of null encapsulation is not encouraged when IPv6/ATM is used with MARS/NHRP/ND as described in [1] 🙈

4.1.5 MARS control messages 💖

the encapsulation of MARS control messages (between MARS and MARS Clients) stays the same as shown in RFC 2022 [3]:

   [0xAA-AA-03][0x00-00-5E][0x00-03][MARS control message]
      (LLC)       (OUI)     (PID)

the key control field values are:

  • the mar$afn field remains 0x0F (ATM addresses)
  • the mar$pro field SHALL be 0x86DD (IPv6)
  • the mar$op.version field remains 0x00 (MARS)

the mar$spln and mar$tpln fields (where relevant) are either 0 (for null or non-existent information) or 16 (for the full IPv6 protocol address) ✨

the way ATM addresses are stored stays the same as shown in RFC 2022 [3] 🌸

4.1.6 NHRP control messages 🎀

the encapsulation of NHRP control messages stays the same as shown in RFC 2332 [4]:

   [0xAA-AA-03][0x00-00-5E][0x00-03][NHRP control message]
      (LLC)       (OUI)     (PID)

the key control field values are:

  • the ar$afn field remains 0x0F (ATM addresses)
  • the ar$pro field SHALL be 0x86DD (IPv6)
  • the ar$op.version field remains 0x01 (NHRP)

the ar$spln and ar$tpln fields (where relevant) are either 0 (for null or non-existent information) or 16 (for the full IPv6 protocol address) 🦋

the way ATM addresses are stored stays the same as shown in RFC 2022 [3] 🧚

4.1.7 Neighbor Discovery control messages 💜

section 5.2 of [1] describes the ND Link-layer address option. for IPv6/ATM drivers, the subfields SHALL be encoded in the following manner 🌈

the [NTL] field defines the type and length of the ATM number that comes right after the [STL] field. the format looks like this:

      7 6 5 4 3 2 1 0
      +-+-+-+-+-+-+-+-+
      |0|x|  length   |
      +-+-+-+-+-+-+-+-+

the most significant bit is reserved and MUST be set to zero. the second most significant bit (x) is a flag that says whether the ATM number is in:

  • ATM Forum AESA format (x = 0).
  • Native E.164 format (x = 1).

the bottom 6 bits are an unsigned integer that gives the length of the associated ATM address field in octets 💅

the [STL] field uses the same format as the [NTL] field. it defines the length of the subaddress field, if one exists. if it doesn't exist, this entire octet field MUST be zero. if the subaddress exists, it will be in AESA format, so flag x SHALL be zero 🔥

[NBMA Number] is a variable length field with the ATM address of the Link layer target. it's always present 🎀

[NBMA Subaddress] is a variable length field with the ATM subaddress of the Link layer target. it may or may not be present. when it isn't, the option ends after the [NBMA Number] (or after any extra padding for 8 byte alignment) 🌸

the octet ordering of the [NBMA Number] and [NBMA Subaddress] fields SHALL be the same as the one used in MARS and NHRP control messages 🫶

4.2 UNI 3.0/3.1 signaling issues (SVC mode). 👑

when an IPv6 node places a call to another IPv6 node, it SHOULD follow the procedures in [6] and [7] for signalling UNI 3.0/3.1 SVCs [9] and negotiating MTU. the default IP MTU size on a LL is 9180 bytes, as specified in [7] 💖

note that while the procedures in [7] still apply to IPv6 over ATM, IPv6 Path MTU Discovery [8] is used by nodes and routers rather than IPv4 MTU discovery. also, while IPv6 nodes are not required to implement Path MTU Discovery, IPv6/ATM nodes SHOULD implement it 🧚 and since IPv6 nodes negotiate an appropriate MTU for each VC, Path MTU should never be triggered, because neither node should ever receive a Packet Too Big message to set it off. when nodes communicate via one or more routers, Path MTU Discovery gets used just like it is for legacy networks 🌈

5 Interface Tokens 🍓

for both PVC and SVC modes of operation, one of the following methods SHALL be used to generate Interface Tokens, as required by section 5.1 of [1] 🎀

5.1 Interface Tokens Based on ESI values 🦋

when the underlying ATM interface is identified by an ATM End System Address (AESA, formerly known as an NSAPA), the interface token MAY be formed from the ESI and SEL values in the AESA, like this:

      [0x00][ESI][SEL]
  • [0x00] is a one octet field which is always set to 0. note that the bit corresponding to the EUI-64 Global/Local bit [5] is always reset, which indicates that this address is not a globally unique IPv6 interface token 🙈
  • [ESI] is a six octet field. it always contains the six octet ESI value for the AESA used to address the specific instance of the IPv6/ATM interface 💜
  • [SEL] is a one octet field. it always contains the SEL value from the AESA used to address the specific instance of the IPv6/ATM interface ✨

5.2 Interface Tokens Based on 48 Bit MAC Values 🌸

where the underlying ATM NIC driver can access one or more 48 bit MAC values unique to the ATM NIC (for example, MAC addresses configured into the NIC's ROM), the IPv6/ATM interface MAY use one of these values to create a unique interface token, as described in [10] 🫶

part 2 is next, and it's where the good stuff lives 💅🔥

5.3. Interface Tokens Based on EUI-64 Values 🎀

okay bestie, so if the ATM NIC driver can see one or more 64 bit EUI-64 values that belong to the ATM NIC (like the ones burned into the NIC's ROM), the IPv6/ATM interface SHOULD use one of those values to make a unique interface token. after inverting the Global/Local identifier bit [10]. (Any relationship between these values and the ESI(s) the ATM driver registered with the local ATM switch is outside the scope of this document. not our problem here 💅)

When EUI-64 values are used for IPv6 interface tokens, the only modification allowed to the octet string read from the NIC is inversion of the Global/Local identifier bit. no other edits, periodt 🫶

5.4. Interface Tokens Based on Native E.164 Addresses 🌸

When an interface uses Native E.164 addresses, the E.164 values MAY be used to generate an interface token, and it's giving very bit-packing vibes:

       [D14][D13D12][D11D10][D9D8][D9D6][D5D4][D3D2][D1D0]
  • [D14] is a single octet holding the semi-octet for the most significant E.164 digit, shifted left four bits into the top four bits of the octet. The lower four bits MUST be set to 0. Lowkey important: the EUI-64 Global/Local indicator is set to 0, which means this is NOT a globally unique IPv6 interface token. 🙈
  • [D13D12] is a single octet with the semi-octet for the second most significant E.164 digit ([D13]) shifted left four places into the top bits of the octet, and the third most significant semi-octet in the four least significant bits of the octet.
  • [D11D10] through [D1D0] are octets that each hold two E.164 digits, one in the most significant four bits and one in the least significant four bits, as shown.

5.5. Nodes Without Unique Identifiers 🦋

If no MAC, EUI-64, AESA, or E.164 value is available for generating an interface token, then the interface token SHALL be generated as described in Appendix A of [10]. no unique ID? no problem, the spec has a backup plan for you ✨

A logical ATM interface might be tied to a different SEL field of a common AESA prefix, or a set of totally separate ESIs might have been registered with the local ATM switch to create a range of unique AESAs. it's giving multiverse energy 🌈

The minimum information required to uniquely identify each logical ATM interface is (within the context of the local switch port) their ESI+SEL combination. so the ESI+SEL combo is the main character here 💖

For the vhost case described in section 5.1.2 of [1], vhost SHALL select a different interface token from the range of 64 bit values available to the ATM NIC (as described in 4.1). Each vhost SHALL implement IPv6/ATM interfaces in such a way that no two or more vhosts end up advertising the same interface token onto the same LL. (Conformance with this requirement may be achieved by choosing different SEL values, ESI values, or both.) so no two vhosts should ever be giving the same token on the same link, that would be a whole mess 😭

6. Conclusion and Open Issues. ✨

This document is an ATM-specific companion document to the ION working group's "IPv6 over Non Broadcast Multiple Access (NBMA) networks" specification [1]. It specifies codepoints for the administratively configured PVC, and dynamically established SVC, modes of operation. so basically it's the ATM sidekick for the main NBMA spec 🧚

There are no major open issues. Comments to the ION mailing list are solicited (ion@nexen.com). bring your thoughts, the group wants them 💜

7. Security Considerations 🔥

While this proposal does not introduce any new security mechanisms, all current IPv6 security mechanisms will work without modification for ATM. This includes both authentication and encryption for both Neighbor Discovery protocols as well as the exchange of IPv6 data packets. no new security tools needed, the existing ones already slay across ATM, which is seriously iconic 👑🔐

Acknowledgments 🍓

The original IPv6/ATM work by G. Armitage occurred while employed at Bellcore. Elements of section 4 were borrowed from Matt Crawford's memo on IPv6 over Ethernet. big thanks to the original builders 🫶

The authors would like to thank Kazuhiko Yamamoto, Kenjiro Cho, Yoshinobu Inoue, Hiroshi Esaki, Yoshifumi Atarashi, and Atsushi Hagiwara for their contributions based on actual PVC implementations. the people who actually got the PVC implementations working deserve the flowers 💐✨

Authors' Addresses 💌

Grenville Armitage
Bell Laboratories, Lucent Technologies
101 Crawfords Corner Road
Holmdel, NJ 07733
USA

EMail: gja@lucent.com


Peter Schulter
BrightTiger Technologies
125 Nagog Park
Acton, MA 01720

EMail: paschulter@acm.org


Markus Jork
European Applied Research Center
Digital Equipment GmbH
CEC Karlsruhe
Vincenz-Priessnitz-Str. 1
D-76131 Karlsruhe
Germany

EMail: jork@kar.dec.com

References 📚

  • [1] Armitage, G., Schulter, P., Jork, M. and G. Harter, "IPv6 over Non-Broadcast Multiple Access (NBMA) networks", RFC 2491, January 1999.
  • [2] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaption Layer 5", RFC 1483, July 1993.
  • [3] Armitage, G., "Support for Multicast over UNI 3.1 based ATM Networks", RFC 2022, November 1996.
  • [4] Luciani, J., Katz, D., Piscitello, D., Cole, B. and N. Doraswamy, "NBMA Next Hop Resolution Protocol (NHRP)", RFC 2332, April 1998.
  • [5] "64-Bit Global Identifier Format Tutorial", http://standards.ieee.org/db/oui/tutorials/EUI64.html.
  • [6] Perez, M., Liaw, F., Mankin, A., Hoffman, E., Grossman, D. and A. Malis, "ATM Signalling Support for IP over ATM", RFC 1755, February 1995.
  • [7] Atkinson, R., "Default IP MTU for use over ATM AAL5", RFC 1626, May 1994.
  • [8] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
  • [9] ATM Forum, "ATM User Network Interface (UNI) Specification Version 3.1", ISBN 0-13-393828-X, Prentice Hall, Englewood Cliffs, NJ, June 1995.
  • [10] Hinden, B. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
  • [11] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.

okay the legal part, but still needs to be complete, so here it is exactly as written:

Copyright (C) The Internet Society (1999).  All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works.  However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
📦 where this page comes from