IPv6 over ATM Networks
RFC 2492

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 03

Network Working Group                                       G. Armitage
Request for Comments: 2492                          Lucent Technologies
Category: Standards Track                                   P. Schulter
                                               BrightTiger Technologies
                                                                M. Jork
                                                 Digital Equipment GmbH
                                                           January 1999

                         IPv6 over ATM Networks

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

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

Abstract

   This document is a companion to the ION working group's architecture
   document, "IPv6 over Non Broadcast Multiple Access (NBMA) networks".
   It provides specific details on how to apply the IPv6 over NBMA
   architecture to ATM networks. This architecture allows conventional
   host-side operation of the IPv6 Neighbor Discovery protocol, while
   also supporting the establishment of 'shortcut' ATM forwarding paths
   (when using SVCs).  Operation over administratively configured Point
   to Point PVCs is also supported.

1. Introduction.

   This document is an ATM-specific companion document to the ION
   working group's, "IPv6 over Non Broadcast Multiple Access (NBMA)
   networks" specification [1].  Terminology and architectural
   descriptions will not be repeated here.

   The use of ATM to provide point to point PVC service, or flexible
   point to point and point to multipoint SVC service, is covered by
   this document.

   A minimally conforming IPv6/ATM driver SHALL support the PVC mode of
   operation. An IPv6/ATM driver that supports the full SVC mode SHALL
   also support PVC mode of operation.

G. Armitage, et. al.        Standards Track                     [Page 1]
RFC 2492                 IPv6 over ATM Networks             January 1999

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].

3. PVC Environments

   When the ATM network is used in PVC mode, each PVC will connect
   exactly two nodes and the use of Neighbor Discovery and other IPv6
   features is limited.  IPv6/ATM interfaces have only one neighbor on
   each Link. The MARS and NHRP protocols are NOT necessary, since
   multicast and broadcast operations collapse down to an ATM level
   unicast operation. Dynamically discovered shortcuts are not
   supported.

   The actual details of encapsulations, MTU, and link token generation
   are provided in the following sections.

   This use of PVC links does not mandate, nor does it prohibit the use
   of extensions to the Neighbor Discovery protocol which may be
   developed for either general use of for use in PVC connections (for
   example, Inverse Neighbor Discovery).

   Since ATM PVC links do not use link-layer addresses, the link-layer
   address options SHOULD not be included in any ND message [11].  If a
   link-layer address option is present in an ND message, then 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
   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)

G. Armitage, et. al.        Standards Track                     [Page 2]
RFC 2492                 IPv6 over ATM Networks             January 1999

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 is passed directly to the AAL5 layer. Both ends of the PVC
   MUST be configured to use null encapsulation. The PVC will not be
   available for use by protocols other than IPv6.

3.3 PPP encapsulation

   The concatentation of IPv6 over PPP with PPP over AAL5 PVCs is not
   covered by this specification.

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