RFC relevance of encapsulation

As per Relevance of the word encapsulation, we have this rfc below:

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

IPv6 over ATM

Status of this

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

Copyright

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

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

1. Introduction

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

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

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

G. Armitage, et. al. Standards Track [Page 1]

RFC 2492 IPv6 over ATM Networks January 1999

2. Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in RFC 2119 [16].

3. PVC

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

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

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

Since ATM PVC links do not use link-layer addresses, the link-
address options SHOULD not be included in any ND message [11]. If
link-layer address option is present in an ND message, then
option SHOULD be ignored

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

3.1 Default Packet

Following the model in RFC 1483 [2], AAL5 SHALL be the
Adaptation Layer service, and (LLC/SNAP) encapsulation SHALL
default encapsulation used by unicast and multicast packets
pt-pt PVC links. As defined in [1], the default IPv6
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

IPv6/ATM drivers MAY also support null encapsulation as
configurable option. When null encapsulation is enabled, the IPv
packet is passed directly to the AAL5 layer. Both ends of the
MUST be configured to use null encapsulation. The PVC will not
available for use by protocols other than IPv6.

3.3 PPP

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

3.4 MTU For PVC

The default IP MTU size for PVC links is 9180 bytes as specified
[7]. Other IP MTU values MAY be used

3.5 Interface Token Formats in PVC

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

4 SVC

4.1 SVC Specific Code

4.1.1 ATM Adaptation Layer encapsulation for SVC

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

4.1.2 Unicast Packet

As defined in [1], the default IPv6 unicast packet
SHALL be

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

G. Armitage, et. al. Standards Track [Page 3]

RFC 2492 IPv6 over ATM Networks January 1999

4.1.3 Multicast packet

As defined in [1], the default IPv6 multicast packet
SHALL be

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

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

4.1.4 Optional null

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

If null encapsulation is enabled, the IPv6 packet is passed
to the AAL5 layer. Both ends of the SVC MUST agree to use
encapsulation during the call SETUP phase. The SVC will not
available for use by 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
with MARS/NHRP/ND as described in [1].

4.1.5 MARS control

The encapsulation of MARS control messages (between MARS and
Clients) remains 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

G. Armitage, et. al. Standards Track [Page 4]

RFC 2492 IPv6 over ATM Networks January 1999

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

The way in which ATM addresses are stored remains the same as
in RFC 2022 [3]

4.1.6 NHRP control

The encapsulation of NHRP control messages remains the same as
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 (
null or non-existent information) or 16 (for the full IPv6
address

The way in which ATM addresses are stored remains the same as
in RFC 2022 [3]

4.1.7 Neigbor Discovery control

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

[NTL] defines the type and length of the ATM number
following the [STL] field. The format is as follows

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

G. Armitage, et. al. Standards Track [Page 5]

RFC 2492 IPv6 over ATM Networks January 1999

The most significant bit is reserved and MUST be set to zero.
second most significant bit (x) is a flag indicating whether
ATM number is in

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

The bottom 6 bits represent an unsigned integer value
the length of the associated ATM address field in octets

The [STL] format is the same as the [NTL] field. Defines the
of the subaddress field, if it exists. If it does not exist
entire octet field MUST be zero. If the subaddress exists it will
in AESA format, so flag x SHALL be zero

[NBMA Number] is a variable length field containing the ATM
of the Link layer target. It is always present

[NBMA Subaddress] is a variable length field containing the
subaddress of the Link layer target. It may or may not be present
When it is not, the option ends after the [NBMA Number] (or
additional padding for 8 byte alignment).

The octet ordering of the [NBMA Number] and [NBMA Subaddress]
SHALL be the same as that 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
follow the procedures in [6] and [7] for signalling UNI 3.0/3.1
[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
IPv4 MTU discovery. Additionally, while IPv6 nodes are not
to implement Path MTU Discovery, IPv6/ATM nodes SHOULD implement it
Also, since IPv6 nodes will negotiate an appropriate MTU for each VC
Path MTU should never be triggered since neither node should
receive a Packet Too Big message to trigger Path MTU Discovery.
nodes are communicating via one or more routers Path MTU
will be used just as it is for legacy networks

5 Interface

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

G. Armitage, et. al. Standards Track [Page 6]

RFC 2492 IPv6 over ATM Networks January 1999

5.1 Interface Tokens Based on ESI

When the underlying ATM interface is identified by an ATM End
Address (AESA, formerly known as an NSAPA), the interface token
be formed from the ESI and SEL values in the AESA as follows

[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
[5] is always reset indicating that this address is not
globally unique IPv6 interface token

[ESI] is a six octet field
This field always contains the six octet ESI value for
AESA used to address the specific instance of the IPv6/
interface

[SEL] is a one octet field
This field always contains the SEL value from the AESA used
address the specific instance of the IPv6/ATM interface

5.2 Interface Tokens Based on 48 Bit MAC

Where the underlying ATM NIC driver has access to a set of one
more 48 bit MAC values unique to the ATM NIC (e.g. MAC
configured into the NIC's ROM), the IPv6/ATM interface MAY use one
these values to create a unique interface token as described in [10].

5.3 Interface Tokens Based on EUI-64

Where the underlying ATM NIC driver has access to a set of one
more 64 bit EUI-64 values unique to the ATM NIC (e.g. EUI-64
addresses configured into the NIC's ROM), the IPv6/ATM
SHOULD use one of these values to create a unique interface token
after inverting the Global/Local identifier bit [10]. (
relationship between these values and the ESI(s) registered with
local ATM switch by the ATM driver are outside the scope of
document.)

When EUI-64 values are used for IPv6 interface tokens the
modification allowed to the octet string read from the NIC
inversion of the Global/Local identifier bit

G. Armitage, et. al. Standards Track [Page 7]

RFC 2492 IPv6 over ATM Networks January 1999

5.4 Interface Tokens Based on Native E.164

When an interface uses Native E.164 addresses then the E.164
MAY be used to generate an interface token as follows

[D14][D13D12][D11D10][D9D8][D9D6][D5D4][D3D2][D1D0]

[D14] A single octet containing the semi-octet representing the
significant E.164 digit shifted left four bits to the
significant four bits of the octet. The lower four bits MUST be
to 0. Note that the EUI-64 Global/Local indicator is set to 0
indicating that this is not a globally unique IPv6 interface token

[D13D12] A single octet containing the semi-octet representing
second most significant E.164 digit [D13] shifted left four places
the most significant bits of the octet, and the third
significant semi-octet in the four least significant bits of
octet

[D11D10] - [D1D0] Octets each containing two E.164 digits, one in
most significant four bits, and one in the least significant
bits as indicated

5.5 Nodes Without Unique

If no MAC, EUI-64, AESA, or E.164 value is available for
an interface token, then the interface token SHALL be generated
described in Appendix A of [10].

5.6 Multiple Logical Links on a Single

A logical ATM interface might be associated with a different
field of a common AESA prefix, or a set of entirely separate
might have been registered with the local ATM switch to create
range of unique AESAs

The minimum information required to uniquely identify each
ATM interface is (within the context of the local switch port)
ESI+SEL combination

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

G. Armitage, et. al. Standards Track [Page 8]

RFC 2492 IPv6 over ATM Networks January 1999

6. Conclusion and Open Issues

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

There are no major open issues. Comments to the ION mailing list
solicited (ion@nexen.com).

7. Security

While this proposal does not introduce any new security
all current IPv6 security mechanisms will work without
for ATM. This includes both authentication and encryption for
Neighbor Discovery protocols as well as the exchange of IPv6
packets

The original IPv6/ATM work by G. Armitage occurred while employed
Bellcore. Elements of section 4 were borrowed from Matt Crawford'
memo on IPv6 over Ethernet

The authors would like to thank Kazuhiko Yamamoto, Kenjiro Cho
Yoshinobu Inoue, Hiroshi Esaki, Yoshifumi Atarashi, and
Hagiwara for their contributions based on actual PVC implementations

G. Armitage, et. al. Standards Track [Page 9]

RFC 2492 IPv6 over ATM Networks January 1999

Authors'

Grenville
Bell Laboratories, Lucent
101 Crawfords Corner
Holmdel, NJ 07733

EMail: gja@lucent.

Peter
BrightTiger
125 Nagog
Acton, MA 01720

EMail: paschulter@acm.

Markus
European Applied Research
Digital Equipment
CEC
Vincenz-Priessnitz-Str. 1
D-76131

EMail: jork@kar.dec.

G. Armitage, et. al. Standards Track [Page 10]

RFC 2492 IPv6 over ATM Networks January 1999

[1] Armitage, G., Schulter, P., Jork, M. and G. Harter, "IPv6
Non-Broadcast Multiple Access (NBMA) networks", RFC 2491,
1999.

[2] Heinanen, J., "Multiprotocol Encapsulation over ATM
Layer 5", RFC 1483, July 1993.

[3] Armitage, G., "Support for Multicast over UNI 3.1 based
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
version 6", RFC 1981, August 1996.

[9] ATM Forum, "ATM User Network Interface (UNI)
Version 3.1", ISBN 0-13-393828-X, Prentice Hall,
Cliffs, NJ, June 1995.

[10] Hinden, B. and S. Deering, "IP Version 6
Architecture", RFC 2373, July 1998.

[11] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery
IP Version 6 (IPv6)", RFC 2461, December 1998.

G. Armitage, et. al. Standards Track [Page 11]

RFC 2492 IPv6 over ATM Networks January 1999

Full Copyright

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

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

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

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

G. Armitage, et. al. Standards Track [Page 12]

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX