IPv6 over ATM Networks
updated by
- rfc-8064 — Recommendation on Stable IPv6 Interface Identifiers
Extracted elements (26)
Since IPv6/ATM nodes negotiate an appropriate MTU for each VC, Path MTU Discovery should never be triggered in direct node-to-node communication because neither node should receive a Packet Too Big message. Path MTU Discovery is only used when communicating via one or more routers.
Use of null encapsulation is not encouraged when IPv6/ATM is used with MARS/NHRP/ND, because the shared control plane (MARS) requires LLC/SNAP framing to distinguish protocol types on the same SVC infrastructure.
In PVC mode, since ATM PVC links do not use link-layer addresses, the link-layer address options SHOULD NOT be included in any ND message. If a link-layer address option is present in an ND message, it SHOULD be ignored.
The MARS and NHRP protocols are NOT necessary in PVC mode because multicast and broadcast operations collapse to ATM-level unicast. Dynamically discovered shortcuts are not supported in PVC mode.
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.
AAL5 SHALL be the default Adaptation Layer service, and LLC/SNAP encapsulation SHALL be the default encapsulation used by unicast and multicast packets across PVC and SVC links.
For SVC null encapsulation, both ends of the SVC MUST agree to use null encapsulation during the call SETUP phase. Null encapsulation SHALL NOT be used on the pt-pt SVC between the IPv6/ATM driver and its local MARS.
For the vhost case, each vhost SHALL select a different interface token from the available 64-bit range and SHALL implement IPv6/ATM interfaces such that no two vhosts advertise the same interface token onto the same logical link.
If no MAC, EUI-64, AESA, or E.164 value is available for generating an interface token, the interface token SHALL be generated as described in Appendix A of RFC 2373 (random interface identifier).
If null encapsulation is enabled on data SVCs between routers, inter-router NHRP traffic SHALL utilize a separate, parallel SVC.
IPv6/ATM nodes SHOULD implement IPv6 Path MTU Discovery (RFC 1981). IPv6 nodes are not required to implement Path MTU Discovery in general, but the ATM-specific profile recommends it.
When null encapsulation is enabled on PVC links, 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.
When placing an SVC call, an IPv6 node SHOULD follow the procedures in RFC 1755 and RFC 1626 for signalling UNI 3.0/3.1 SVCs and negotiating MTU. The default IP MTU on a logical link is 9180 bytes.
Where the ATM NIC has access to EUI-64 values, the IPv6/ATM interface SHOULD use one to create a unique interface token by inverting the Global/Local identifier bit. The only modification allowed to the octet string from the NIC is inversion of that bit.
Interface tokens for IPv6/ATM MAY be derived from AESA ESI+SEL values as an 8-octet field [0x00][ESI(6 octets)][SEL(1 octet)], where the leading 0x00 resets the EUI-64 Global/Local bit, indicating a non-globally-unique token.
The default IP MTU size for PVC links is 9180 bytes as specified in RFC 1626. Other IP MTU values MAY be used.
The ND link-layer address option includes a variable-length [NBMA Number] field (always present) containing the ATM address of the link layer target, and an optional variable-length [NBMA Subaddress] field; octet ordering SHALL match MARS and NHRP control messages.
Where the ATM NIC has access to 48-bit MAC values, the IPv6/ATM interface MAY use one to create a unique interface token per RFC 2373 procedures.
This proposal does not introduce any new security mechanisms. All current IPv6 security mechanisms, including authentication and encryption for both Neighbor Discovery and IPv6 data packet exchange, work without modification over ATM.
Interface tokens derived from Native E.164 addresses pack 15 BCD digits into 8 octets as semi-octets: [D14 << 4 | 0x0][D13D12][D11D10]...[D1D0], with the MSB nibble of the first octet's lower bits set to 0, keeping the Global/Local bit reset.
MARS control messages are encapsulated as [0xAA-AA-03][0x00-00-5E][0x00-03][MARS control message]. The mar$pro field SHALL be 0x86DD (IPv6), mar$afn remains 0x0F (ATM), and mar$spln/mar$tpln are 0 or 16 (full IPv6 address length).
NHRP control messages are encapsulated as [0xAA-AA-03][0x00-00-5E][0x00-03][NHRP control message]. The ar$pro field SHALL be 0x86DD (IPv6), ar$afn remains 0x0F (ATM), and ar$spln/ar$tpln are 0 or 16.
The default IPv6 multicast packet encapsulation over SVC links is: [0xAA-AA-03][0x00-00-5E][0x00-01][pkt$cmi][0x86DD][IPv6 packet], where pkt$cmi is the 2-octet Cluster Member ID of the IPv6/ATM driver.
The default IPv6 packet encapsulation over ATM PVC and SVC unicast links is LLC/SNAP over AAL5: [0xAA-AA-03][0x00-00-00][0x86-DD][IPv6 packet], where the first three fields are LLC, OUI, and PID respectively.
The ND link-layer address option NTL field is one octet: the MSB is reserved (MUST be zero), the second bit (x) flags ATM Forum AESA format (x=0) or Native E.164 format (x=1), and the lower 6 bits encode the ATM address length in octets.
The ND link-layer address option STL field has the same format as NTL and defines the subaddress length. If no subaddress exists, the STL octet MUST be zero. If the subaddress exists it will be in AESA format, so flag x SHALL be zero.