IPv6 over ATM Networks
RFC 2492
| Document | Type |
RFC - Proposed Standard
(January 1999; Errata)
Updated by RFC 8064
|
|
|---|---|---|---|
| Last updated | 2013-03-02 | ||
| Stream | IETF | ||
| Formats | plain text pdf html 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 Environments
Show full document text