RFC 2590
Transmission of IPv6 Packets over Frame Relay Networks Specification
RFC 2590: Transmission of IPv6 Packets over Frame Relay Networks Specification 🎀
Part 1 of 4, more coming bestie 💖
Okay so this is RFC 2590 ✨ It's called "Transmission of IPv6 Packets over Frame Relay Networks Specification" and it dropped in May 1999. The category is Standards Track 🌸 The authors are A. Conta (Lucent), A. Malis (Ascend), and M. Mueller (Lucent). The title block doesn't list anything it obsoletes or updates, so it isn't replacing or patching an earlier RFC 💅
Status of this Memo 📜
This document specifies an Internet standards track protocol for the Internet community, and it asks for discussion and suggestions for improvements. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🫶
Copyright Notice ©️
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract 🌙
This memo describes mechanisms for the transmission of IPv6 packets over Frame Relay networks.
Table of Contents 🗂️
1. Introduction.................................................2
2. Maximum Transmission Unit....................................3
3. Frame Format.................................................4
4. Stateless Autoconfiguration..................................5
4.1 Generating the MID field.................................7
5. Link-Local Address...........................................9
6. Address Mapping -- Unicast, Multicast........................9
7. Sending Neighbor Discovery Messages.........................14
8. Receiving Neighbor Discovery Messages.......................15
9. Security Considerations.....................................15
10. Acknowledgments............................................16
11. References.................................................16
12. Authors' Addresses.........................................18
13. Full Copyright Statement...................................191. Introduction ✨
Okay so Section 1 is the intro, bestie 💖 This doc spells out the frame format for sending IPv6 packets over Frame Relay networks. It also covers how IPv6 link-local addresses get formed on Frame Relay links, and how IPv6 addresses get mapped to Frame Relay addresses. On top of that, it defines what goes in the Source/Target link-layer address option when Neighbor Discovery [ND] and Inverse Neighbor Discovery [IND] messages travel over a Frame Relay link 🦋 This is one piece of a bigger family of specs for IPv6 on Non Broadcast Multi Access (NBMA) media [IPv6-NBMA], [IPv6-ATM], and a whole lineup for specific link layers [IPv6-ETH], [IPv6-FDDI], [IPv6-PPP], [IPv6-ATM], etc... 🌈
This info is for Frame Relay devices that act as end stations (DTEs) on a public or private Frame Relay network. Think a network provided by a common carrier or PTT 🧚 Frame Relay end stations can be IPv6 hosts or routers, and this doc calls them nodes.
On a Frame Relay network, a bunch of virtual circuits form the connections between the attached stations (nodes) 💜 The resulting group of interconnected devices is a private Frame Relay group. It can be fully interconnected with a complete "mesh" of virtual circuits, or only partially interconnected. Either way, each virtual circuit gets uniquely identified at each Frame Relay interface (card) by a Data Link Connection Identifier (DLCI). In most circumstances, DLCIs only have strictly local significance at each Frame Relay interface 🙈
A Frame Relay virtual circuit acts like a virtual-link (also called a logical-link), and it has its own link parameters. Those parameters are separate from the ones on other virtual circuits sitting on the same wire or fiber 🍓 The parameters include the input/output maximum frame size, incoming/outgoing requested/agreed throughput, incoming/outgoing acceptable throughput, incoming/outgoing burst size, and incoming/outgoing frame rate.
By default a DLCI is 10 bits long. Frame Relay specs also define 16, 17, or 23 bit DLCIs. The 16 bit one is not used, while the 17 and 23 bit ones are suggested for use with SVCs 🌸
Frame Relay virtual circuits can be set up administratively as Permanent Virtual Circuits (PVCs), or dynamically as Switched Virtual Circuits (SVCs). The mechanisms in this document are meant to apply to both permanent and switched Frame Relay virtual circuits, whether they're point to point or point to multi-point 👑
The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED, SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as defined in [RFC 2119]. That's the official rulebook for the capital-letter words, so it's the one to check when a word is in caps 📜🔥
2. Maximum Transmission Unit 📏
The IPv6 minimum MTU is defined in [IPv6].
In general, Frame Relay devices are configured with a maximum frame size of at least 1600 octets. So the default IPv6 MTU size for a Frame Relay interface is considered to be 1592 🌷
You can configure a frame size that's smaller than the default, but of course it can't be smaller than the minimum IPv6 MTU 🫧
You can also configure an adequately larger-than-default IPv6 MTU and Frame Relay frame size, which helps avoid fragmentation ✨ The maximum frame size is controlled by the CRC generation mechanisms used at the HDLC level. CRC16 protects frames up to 4096 bytes in length, which brings the effective maximum frame size down to approximately 4088 bytes. A bigger frame size (like the ones FDDI or Token Ring use) would need the CRC32 mechanism. That one isn't widely used yet, and it isn't mandatory for frame relay systems that conform to Frame Relay Forum and ITU-T standards 💅
In general, if upper layers provide adequate error protection/detection mechanisms, implementations may allow a Frame Relay link to be configured with a frame size larger than 4080 octets, but with weaker error protection/detection at the link layer. However, IPv6 relies on upper and lower layer error detection, so configuring the IPv6 MTU to a value larger than 4080 is strongly discouraged 🥺
Although a Frame Relay circuit lets you define different maximum frame sizes for input and output, this specification keeps things simple and assumes symmetry. That means the same MTU for both input and output 🎀
Also, implementations may limit the Frame Relay maximum frame size setting to the interface (link, or card) level. That setting then gets enforced on all of the PVCs or SVCs on that interface (on that link, or card). For an SVC, the maximum frame size parameter negotiated during circuit setup won't exceed the configured maximum frame size 🦋
3. IPv6 Frame Format 🧩
The IPv6 frame encapsulation for Frame Relay (for both PVCs and SVCs) follows [ENCAPS], which lets a VC carry IPv6 packets alongside other protocol packets. The NLPID frame format is used, and the IPv6 NLPID has a value of 0x8E 💖 Here's how the frame is laid out:
0 1 (Octets)
+-----------------------+-----------------------+
(Octets)0 | |
/ Q.922 Address /
/ (length 'n' equals 2 or 4) /
| |
+-----------------------+-----------------------+
n | Control (UI) 0x03 | NLPID 0x8E | NLPID
+-----------------------+-----------------------+ indicating
n+2 | . | IPv6
/ . /
/ IPv6 packet /
| . |
+-----------------------+-----------------------+
| |
+ FCS +
| |
+-----------------------+-----------------------+"n" is the length of the Q.922 address, which can be 2 or 4 octets 🌸
The Q.922 representation of a DLCI (in canonical order, where the first bit is stored in the least significant, i.e., the right-most bit of a byte in memory) [CANON] looks like this:
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
(octet) 0 | DLCI(high order) | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
1 | DLCI(low order) | 0 | 0 | 0 | 1 |
+-----+-----+-----+-----+-----+-----+-----+-----+
10 bits DLCI
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
(octet) 0 | DLCI(high order) | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
1 | DLCI | 0 | 0 | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
2 | DLCI(low order) | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
3 | unused (set to 0) | 1 | 1 |
+-----+-----+-----+-----+-----+-----+-----+-----+
17 bits DLCI
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
(octet) 0 | DLCI(high order) | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----
1 | DLCI | 0 | 0 | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
2 | DLCI | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
3 | DLCI (low order) | 0 | 1 |
+-----+-----+-----+-----+-----+-----+-----+-----+
23 bits DLCIThe encapsulation of data or control messages exchanged by various protocols that use SNAP encapsulation (with their own PIDs) isn't affected by any of this 🫶 The encoding of the IPv6 protocol identifier in those messages MUST be done according to the specifications of those protocols, and [ASSNUM] 🥹
4. Stateless Autoconfiguration ✨
okay so bestie, every IPv6 Frame Relay interface needs an interface identifier [AARCH] that's unique on the Frame Relay link [AARCH]. It also has to be unique across every virtual link represented by the VCs that end on that interface 🦋. And the IPv6 module generates the interface identifier for the Frame Relay interface locally 💅
Now here's the tea 🍵. Every virtual circuit gets its own unique DLCI on a Frame Relay interface, and a DLCI basically tells you where a VC ends on that interface. Each VC is set up separately and acts like its own independent virtual link, even though they all share the same physical link, wire, or fiber. So it makes total sense to treat each VC's endpoint as a "pseudo-interface" or "logical-interface" sitting on top of the Frame Relay interface 🌸. And it's also useful to generate an IPv6 autoconfigured address for each pseudo-interface, including an IPv6 link-local address. In other words, one for each DLCI on the interface 💜
To get all of that, this document suggests building the Frame Relay interface identifier out of 3 separate fields (Fig.1) 🎀
- (a) The "EUI bits" field. These are bits 6 and 7 of the first octet. They're the EUI-64 "universal/local" bit and the "individual/group" bit, converted for IPv6 use. The universal/local bit is set to zero, which shows the 64 bit interface identifier value has local significance [AARCH]. The individual/group bit is set to 0 to show it's a unicast address [AARCH] 🧚
- (b) The "Mid" field. This is a 38 bit field, generated to add uniqueness to the interface identifier 🍓
- (c) The "DLCI" field. This is a 24 bit field that MAY hold a 10, 17, or 23 bit DLCI value, and that value MUST be extended with 0's to reach 24 bits. A DLCI based interface identifier, meaning one that contains a valid DLCI, SHOULD be generated when a VC is successfully established, whether it's a PVC or an SVC 🔥
If the DLCI isn't known, this field MUST be set to the "unspecified DLCI" value, which is all 24 bits set to 1 🙈
Something to keep in mind 💀: DLCIs are only local to a Frame Relay node. That means two distinct Frame Relay virtual circuits in the same Frame Relay network can end up with the same DLCI values. Totally valid, just don't assume DLCIs are globally unique.
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
(Octets) 0 | |"EUI bits" |
+ +-----+-----+
1 | |
+ +
2 | "Mid" |
+ +
3 | |
+ +
4 | |
+-----+-----+-----+-----+-----+-----+-----+-----+
5 | |
+ +
6 | "DLCI" |
+ +
7 | |
+-----+-----+-----+-----+-----+-----+-----+-----+Fig.1 Frame Relay Pseudo-Interface Identifier
The Duplicate Address Detection from [AUTOCONF] gets used over and over during the interface identifier and local-link address generation process. It keeps going until the generated identifier, and therefore the link-local address on the link (aka the VC), is unique 🫶
4.1. Generating the "Mid" field. 🌈
The "Mid" can be generated in several ways, but this specification suggests two mechanisms 👑
- (b.1) "Use of Local Administrative Numbers"
The "Mid" is filled in by merging these:
- (b.1.1) A random number that's 6 bits long (Fig.2) 🎲
- (b.1.2) The Frame Relay Node Identifier, which is 16 bits. This is a user administered value used to locally identify a Frame Relay node (Fig.2) 🏷️
- (b.1.3) The Frame Relay Link Identifier, which is 16 bits. This is a numerical representation of the Frame Relay interface or link (Fig.2) 🔢
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
(Octets) 0 | Random Number | MBZ |
+-----------------------------------+-----+-----+
1 | |
+ Frame Relay Node Identifier +
2 | |
+-----+-----+-----+-----+-----+-----+-----+-----+
3 | |
+ Frame Relay Link Identifier +
4 | |
+-----+-----+-----+-----+-----+-----+-----+-----+
5 | |
+ +
6 | "DLCI" |
+ +
7 | |
+-----+-----+-----+-----+-----+-----+-----+-----+Fig.2 Frame Relay Pseudo-Interface Identifier
or,
- (b.2) "Use of The Frame Relay address - E.164 [E164], X.121 [X25] numbers, or NSAP [NSAP] address"
If a Frame Relay interface has an E.164 or X.121 number, or an NSAP address, the "Mid" field MUST be filled in with a number derived from it 🫧. Here's how: the number from the BCD encoding of the E.164 or X.121 number, or the binary encoding of the NSAP address, gets truncated to 38 bits (Fig.3) ✂️.
Since the Frame Relay interface identifier only has "local" significance, using this value doesn't have any real practical purpose except adding to the uniqueness of the interface identifier on the link. That means the truncation can be done on the high order bits or the low order bits 💅. If truncating the high order bits doesn't give uniqueness on the link (maybe the DLCI value isn't unique), that most likely means the VC spans more than a national and/or international destination area for an E.164 number. In that case, the low order bits should be truncated next, which will most likely give the uniqueness you want 🦋
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
(Octets) 0 | | MBZ |
+ +-----+-----+
1 | |
+ E.164, X.121 (BCD encoding) +
2 | or NSAP Address |
+ +
3 | (truncated to 38 bits) |
+ +
4 | |
+-----+-----+-----+-----+-----+-----+-----+-----+
5 | |
+ +
6 | "DLCI" |
+ +
7 | |
+-----+-----+-----+-----+-----+-----+-----+-----+Fig.3 Frame Relay (Pseudo) Interface Identifier
5. Link-Local Addresses 🌙
The IPv6 link-local address [AARCH] for an IPv6 Frame Relay interface is made by appending the interface identifier (built the way we just talked about) to the prefix FE80::/64 [AARCH]. Iconic 👑
10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+
|1111111010| (zeros) |Frame Relay Interface Ident.|
+----------+-----------------------+----------------------------+6. Address Mapping -- Unicast, Multicast ✨
Okay so, mapping IPv6 addresses to link-layer addresses is covered in [IPv6-ND] 💖 Then there's Inverse Neighbor Discovery (IND) in [IND], which goes the other way, mapping link-layer addresses back to IPv6 addresses 🦋 This doc is the one that defines the formats of the link-layer address fields that ND and IND use. It does not define an algorithmic mapping of IPv6 multicast addresses to Frame Relay link-layer addresses, so don't go looking for one here 🙈
For a Frame Relay link, the Source/Target Link-layer Address option in ND and IND messages just follows the general rules in [IPv6-ND]. IPv6 addresses can map to two types of identifiers that act like link-layer addresses: DLCIs and Frame Relay Addresses 🎀 So for Frame Relay, this doc defines two different formats for the Link-Layer Address field in ND and IND messages:
(a) DLCI Format 🌸 This one is used in ND and/or IND messages on VCs that were set up before the ND or IND exchange, which means mostly PVCs. It can also show up on SVCs if Inverse Neighbor Discovery [IND] is used after an SVC is successfully set up, to gather info about the other IPv6 addresses the remote node has on that SVC.
(b) Frame Relay Address Format 🧚 This one is mostly used before a new SVC is set up, to get the Frame Relay remote node identifier (link-layer address) that maps to a certain IPv6 address.
Note: An implementation can hold both types of link-layer identifiers in its Neighbor Discovery cache 💅 Also, if there are multiple VCs between two nodes, one node's Neighbor Discovery cache can hold a mapping from one of the remote node's IPv6 addresses to each and every DLCI that identifies those VCs. Lots of mappings, very organized.
How an implementation tells apart a Neighbor Discovery cache entry that maps an IPv6 address to a "Frame Relay Address Format" link-layer address and one that maps to a "DLCI Format" address (or several "DLCI Format" entries) is out of scope for this spec. That's the implementation's job, not ours 🫶
The use of the override "O" bit in the advertisement messages that contain the above Link-Layer Address formats SHOULD be consistent with the [ND] specifications 🔥 And there should be consistency about the type of Link-Layer Address format too: an implementation should override one address format in its Neighbor Discovery cache with the same type of address format. Keep your cache tidy, bestie 🧹
The "DLCI Format" is laid out like this:
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
0 | Type |
+-----+-----+-----+-----+-----+-----+-----+-----+
1 | Length |
+-----+-----+-----+-----+-----+-----+-----+-----+with a DLCI (Q.922 address) encoded as the option value:
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
2 | | 1 | 1 |
+ unused +-----+-----+
3 | |
+-----+-----+-----+-----+-----+-----+-----+-----+
4 | DLCI(high order) | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
5 | DLCI(low order) | 0 | 0 | 0 | 1 |
+-----+-----+-----+-----+-----+-----+-----+-----+
6 | |
+ Padding +
7 | (zeros) |
+-----+-----+-----+-----+-----+-----+-----+-----+
10 bits DLCI
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
2 | | 1 | 1 |
+ unused +-----+-----+
3 | |
+-----+-----+-----+-----+-----+-----+-----+-----+
4 | DLCI(high order) | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
5 | DLCI | 0 | 0 | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
6 | DLCI(low order) | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
7 | unused (set to 0) | 1 | 1 |
+-----+-----+-----+-----+-----+-----+-----+-----+
17 bits DLCI
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
2 | | 1 | 1 |
+ unused +-----+-----+
3 | |
+-----+-----+-----+-----+-----+-----+-----+-----+
4 | DLCI(high order) | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----
5 | DLCI | 0 | 0 | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
6 | DLCI | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
7 | DLCI (low order) | 0 | 1 |
+-----+-----+-----+-----+-----+-----+-----+-----+
23 bits DLCIOption fields 🍓
- Type: 1 for Source Link-layer address. 2 for Target Link-layer address.
- Length: The Length of the Option (including the Type and Length fields) in units of 8 octets. It has the value 1.
- Link-Layer Address: The DLCI encoded as a Q.922 address.
Description 💜
The "DLCI Format" option value field has two components:
(a) Address Type 👑 This is encoded in the first two bits of the first two octets. Both bits are set to 1 to indicate the DLCI format. The rest of the bits in those first two octets are not used. They MUST be set to zero on transmit and MUST be ignored by the receiver. Bit-level discipline, iconic 😭
(b) DLCI 💖 This is encoded as a Q.922 address, padded with zeros out to the last octet of the 6 octets available for the entire Link-Layer Address field of this format.
The "Frame Relay Address Format" is laid out like this:
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
0 | Type |
+-----+-----+-----+-----+-----+-----+-----+-----+
1 | Length |
+-----+-----+-----+-----+-----+-----+-----+-----+with an E.164, X.121, number or NSAP address encoded as the option value:
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
2 | size | 1 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
3 | E.164 or X.121, or NSAP |
+--- Address Family Number ---+
4 | (Assigned Number) |
+-----+-----+-----+-----+-----+-----+-----+-----+
5 | |
/ E.164, or X.121 number (BCD encoded) /
/ or NSAP address /
4+size | |
+-----+-----+-----+-----+-----+-----+-----+-----+
5+size | |
/ Padding /
/ (zeros) /
8*Length-1| |
+-----+-----+-----+-----+-----+-----+-----+-----+Option fields 🌈
- Type: 1 for Source Link-layer address. 2 for Target Link-layer address.
- Length: The length of the Option (including the Type and Length fields) in units of 8 octet. It may have the value:
- 2 -- for E.164, or X.121 numbers or NSAP addresses not longer than 11 octets [E164], [X25], [NSAP].
- 3 -- for NSAP addresses longer than 11 but not longer than 19 octets.
- 4 -- for NSAP addresses longer than 19 octets (not longer than the maximum NSAP address length) [NSAP].
- Link-Layer Address: The E.164, X.121, number encoded in Binary Coded Decimal (BCD), or the NSAP address.
Description 🦋
The "Frame Relay Address" option value has three components:
(a) Address Type 🫶 This is encoded in the first two bits of the first octet. The first bit is set to 0, and the second bit is set to 1.
(b) Size 🌸 This is encoded in the last (high order) 6 bits of the first octet. The maximum value of the field is the maximum size of the E.164, X.121, or NSAP addresses.
(c) Address Family Number 🧚 This is the number assigned for the E.164, X.121, or NSAP address family [ASSNUM].
(d) E.164, X.121, number 🔥 This is encoded in BCD, two digits per octet. If the E.164 or X.121 number has an even number of digits, the encoding fills all the encoding octets, which is half the number of digits. If it has an odd number of digits, the lowest order digit fills only half of an octet: it goes in the first 4 bits of the last octet of the E.164 or X.121 BCD encoding. The rest of the field, up to the last octet of the 11 octets available, is padded with zeros.
NSAP address 💅 This is the NSAP address itself. It is padded with zeros if the NSAP address doesn't fit in a number of octets that makes the option length an even number of 8 octets.
7. Sending Neighbor Discovery Messages 🚀
Okay, real talk: Frame Relay networks don't provide native link-layer multicasting 😭 For Neighbor Discovery to work properly, link-layer multicasting has to be emulated.
So to emulate multicasting for Neighbor Discovery (ND), the node MUST send frames carrying ND multicast packets to all VCs on a Frame Relay interface. This applies to ND messages addressed to both the all-node and solicited-node multicast addresses. This method works really well with PVCs 💖 A mesh of PVCs MAY be configured and dedicated to multicast traffic only. Another option instead of a mesh of PVCs is a set of point-to-multipoint PVCs ✨
8. Receiving Neighbor Discovery Messages ✨
okay so bestie, here's the big one 💅 If a Neighbor Discovery Solicitation message lands on a node and its Source link-layer address option carries a DLCI, that message MUST go through Frame Relay specific preprocessing first, so the field gets read correctly by the ND protocol engine 🎀 This prep happens before the ND engine even looks at the message.
Why do we need this? 🤔 DLCI fields only mean something locally. The sender's DLCI and the receiver's DLCI for the same virtual circuit can be totally different numbers 🙈 The sender might not even know what number the receiver is using. So the preprocessing takes the Solicitation and rewrites its Source link-layer address option to hold the DLCI of the virtual circuit the frame came in on, as the receiver knows it 🦋 That stored value needs to be in the right format (check the earlier sections for that). How the DLCI gets passed from the Frame Relay module to the ND preprocessing step is up to the implementation, so you get to pick your own vibe there 🌈
9. Security Considerations 🔐
okay this section is serious, so listen up 👑 The mechanisms in this document for generating an IPv6 Frame Relay interface identifier are meant to keep things unique at the link level, meaning per virtual circuit 🧚 Duplicates get caught by the Duplicate Address Detection mechanisms that come with IPv6 Stateless Autoconfiguration 💖 Protection against forgery or accidents, at the level of what's described here, comes from the IPv6 security mechanisms [IPSEC], [IPSEC-Auth], and [IPSEC-ESP], applied to Neighbor Discovery [IPv6-ND] or Inverse Neighbor Discovery [IND] messages 🔥
⚠️ Here's the part you cannot skip: to avoid an IPsec Authentication verification failure, the Frame Relay specific preprocessing of a Neighbor Discovery Solicitation message that contains a DLCI format Source link-layer address option MUST be done by the receiver node after it completed IP Security processing. Order matters, bestie 💀
10. Acknowledgments 🫶
huge thanks to D. Harrington and M. Merhar for reviewing this doc and dropping useful suggestions 💜 Also big thanks to G. Armitage for his reviews and ideas, and to Thomas Narten for suggestions on making the doc better 🌸
11. References 📚
Here's the full reference list, kept exactly as written 🍓
[AARCH] Hinden, R. and S. Deering, "IPv6 Addressing
Architecture", RFC 2373, July 1998.
[ASSNUM] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
RFC 1700, October 1994. See also:
http://www.iana.org/numbers.html
[AUTOCONF] Thomson, S. and T. Narten, "IPv6 Stateless
Autoconfiguration", RFC 2462, December 1998.
[CANON] Narten, T. and C. Burton, "A Caution on the Canonical
Ordering of Link-Layer Addresses", RFC 2469, December
1998.
[ENCAPS] Brown, C. and A. Malis, "Multiprotocol Interconnect over
Frame Relay", STD 55, RFC 2427, November 1998.
[IND] Conta, A., "Extensions to IPv6 Neighbor Discovery for
Inverse Discovery", Work in Progress, December 1998.
[IPv6] Deering, S. and R. Hinden, "Internet Protocol Version 6
Specification", RFC 2460, December 1998.
[IPv6-ATM] Armitage, G., Schulter, P. and M. Jork, "IPv6 over ATM
Networks", RFC 2492, January 1999.
[IPv6-ETH] Crawford, M., "Transmission of IPv6 packets over
Ethernet Networks", RFC 2464, December 1998.
[IPv6-FDDI] Crawford, M., "Transmission of IPv6 packets over FDDI
Networks", RFC 2467, December 1998.
[IPv6-NBMA] Armitage, G., Schulter, P., Jork, M. and G. Harter,
"IPv6 over Non-Broadcast Multiple Access (NBMA)
networks", RFC 2491, January 1999.
[IPv6-ND] Narten, T., Nordmark, E. and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December
1998.
[IPv6-PPP] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC
2472, December 1998.
[IPv6-TR] Narten, T., Crawford, M. and M. Thomas, "Transmission
of IPv6 packets over Token Ring Networks", RFC 2470,
December 1998.
[IPSEC] Atkinson, R. and S. Kent, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[IPSEC-Auth] Atkinson, R. and S. Kent, "IP Authentication Header",
RFC 2402, December 1998.
[IPSEC-ESP] Atkinson, R. and S. Kent, "IP Encapsulating Security
Protocol (ESP)", RFC 2406, November 1998.
[RFC2119] Bradner, S., "Key words for use in RFCs to indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[E164] International Telecommunication Union - "Telephone
Network and ISDN Operation, Numbering, Routing, amd
Mobile Service", ITU-T Recommendation E.164, 1991.
[NSAP] ISO/IEC, "Information Processing Systems -- Data
Communications -- Network Service Definition Addendum 2:
Network Layer Addressing". International Standard
8348/Addendum 2, ISO/IEC JTC 1, Switzerland 1988.
[X25] "Information Technology -- Data Communications -- X.25
Packet Layer Protocol for Data Terminal Equipment",
International Standard 8208, March 1988.12. Authors' Addresses 💌
the brains behind this doc 🧠✨
Alex Conta
Lucent Technologies Inc.
300 Baker Ave, Suite 100
Concord, MA 01742
Phone: +1-978-287-2842
EMail: aconta@lucent.com
Andrew Malis
Ascend Communications
1 Robbins Rd
Westford, MA 01886
Phone: +1-978-952-7414
EMail: malis@ascend.com
Martin Mueller
Lucent Technologies Inc.
300 Baker Ave, Suite 100
Concord, MA 01742
PHone: +1-978-287-2833
EMail: memueller@lucent.com13. Full Copyright Statement ⚖️
the legal bit, kept word for word so nothing gets lost 🎀
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Acknowledgement 🌈
funding for the RFC Editor function is currently provided by the Internet Society 💜
📦 where this page comes from
- ietf: rfc2590 1999-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms