IPv6 over ATM Networks
RFC 2492
Document | Type |
RFC - Proposed Standard
(January 1999; Errata)
Updated by RFC 8064
|
|
---|---|---|---|
Authors | Markus Jork , Peter Schulter , Grenville Armitage | ||
Last updated | 2013-03-02 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 2492 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
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 EnvironmentsShow full document text