Internet Draft IPng Working Group A. Conta INTERNET-DRAFT M. Mueller (Lucent) July 1997 Transmission of IPv6 Packets over Frame Relay. Specification draft-conta-ipv6-trans-fr-00.txt Status of this Memo This document is an Internet-Draft. Internet-Drafts are working doc uments of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this memo is unlimited. Abstract This memo describes the transmission of IPv6 packets over Frame Relay, the IPv6 Frame Relay interface token, the IPv6 Frame Relay link local addresses, the IPv6 Frame Relay link layer Information formatting for Neighbor Discovery. 1. Introduction This document specifies the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses on Frame Relay links. It also specifies the content of the Source/Target Conta Expires in six months [Page 1] INTERNET-DRAFT IPv6 over Frame Relay 30 July 1997 Link-layer Address option used in Neighbor Discovery [ND] or Inverse Neighbor Discovery [IND] messages when those messages are transmitted over a Frame Relay link. The information in this document applies to Frame Relay devices which serve as end stations (DTEs) on a public or private Frame Relay net- work (for example, provided by a common carrier or PTT.) In a Frame Relay network, a number of virtual circuits form the con- nections between the attached stations. The resulting set of inter- connected devices forms a private Frame Relay group which may be either fully interconnected with a complete "mesh" of virtual cir- cuits, or only partially interconnected. In either case, each vir- tual circuit is uniquely identified at each Frame Relay interface by a Data Link Connection Identifier (DLCI). In most circumstances, DLCIs have strictly local significance at each Frame Relay interface. A Frame Relay virtual circuit acts like a virtual-link, with its own link parameters, distinct from the parameters of other virtual cir- cuits established on the same wire or fiber. Such parameters are the input/output maximum frame size, incoming/outgoing requested/agreed throughput, incoming/outgoing acceptable throughput, incom- ing/outgoing burst size, incoming/outgoing frame rate. A DLCI can be of 10, 17, or 24 bits in length, spanning a 2, 3, respectively 4 octet Frame Relay header. This document is intended to apply to both switched and permanent Frame Relay virtual circuits. The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED, SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as defined in RFC 2119. 2. Maximum Transmission Unit The minimum frame size for a Frame Relay link is 5, 6, or 7 octets, depending on the size of the DLCI (10, 17, or 24 bits). A Frame Relay network must support at least a maximum size of 262 octets. IPv6 requires a minimum MTU size of 576 octets. In general, Frame Relay devices are configured to have an MTU of at least 1600 octets. Therefore, the default MTU size for a Frame Relay is considered to be 1600. A smaller than default MTU can be configured but of course not smaller than the minimum MTU of 576 octets. Conta Expires in six months [Page 2] INTERNET-DRAFT IPv6 over Frame Relay 30 July 1997 An adequate larger than default MTU can be configured to avoid frag- mentation. The maximum MTU size is controlled by the CRC generation mechanisms employed at the HDLC level. CRC16 will protect frames up to 4096 bytes in length, which reduces the effective maximum MTU size to approximately 4080 bytes. A larger desired MTU size (such as that used by FDDI or Token Ring), would require the CRC32 mechanism, which is not yet widely used and is not mandatory for frame relay systems conforming to Frame Relay Forum and ITU-T standards. Implementations may allow, if upper layers provide adequate error protection/detection mechanisms, configuring a Frame Relay link with a larger than 4080 octets MTU but with a lesser error protec- tion/detection mechanism at link layer. Although a Frame Relay circuit allows the definition of distinct max- imum frame sizes for input and output, for simplification purposes, this specification assumes symmetry, i.e. the same MTU for both input and output. Furthermore, implementations limit the setting of the Frame Relay to the link level, which is enforced on all of the VCs that use the link, i.e. MTU can NOT be set for each VC using a link. 3. Frame format IPv6 packets are transmitted in standard [ENCAPS] SNAP frame encapsu- lation format: 0 1 (Octets) +-----------------------+-----------------------+ (Octets)0 | Q.922 Address | +-----------------------+-----------------------+ 2 | Control (UI) 0x03 | pad 0x00 | +-----------------------+-----------------------+ 4 | NLPID 0x80 (SNAP) | | SNAP Header +-----------------------+ OUI =3D 0x00-00-00 + Indicating 6 | | IPv6 +-----------------------+-----------------------+ 8 | IPv6 PID 0x86DD | +-----------------------+-----------------------+ 10 | IPv6 packet | | . | | . | +-----------------------+-----------------------+ The IPv6 does not have an NLPID defined at this time, therefore at this point only the SNAP encapsulation is used. Conta Expires in six months [Page 3] INTERNET-DRAFT IPv6 over Frame Relay 30 July 1997 4. Stateless Autoconfiguration The interface token [CONF] for an IPv6 Frame Relay interface must be unique on the virtual link represented by the virtual circuit i.e., the circuit's end-point nodes must have distinct interface tokens. This applies regardless the virtual circuit is a point-to-point, point-to-multipoint, or multipoint-to-multipoint circuit, and regard- less the timing of the node joining a multi-point ended circuit. The interface token is locally generated by the Frame Relay device, and it can have as seed any combination of 64 bits, as long as the result is a unique token on the link. A method to construct the Frame Relay Interface Token is as follows: 0 1 2 3 4 5 6 7 (Bits) +-----+-----+-----+-----+-----+-----+-----+-----+ (Ootets) 0 | | MBZ | + Any value +-----+-----+ 1 | | +-----+-----+-----+-----+-----+-----+-----+-----+ 2 | Frame Relay Node Identifier | +-----+-----+-----+-----+-----+-----+-----+-----+ 3 | | +- Frame Relay Link Identifier -+ 4 | | +-----+-----+-----+-----+-----+-----+-----+-----+ 5 | | +- -+ 6 | Frame Relay DLCI | +- -+ 7 | | +-----+-----+-----+-----+-----+-----+-----+-----+ The EUI-64 "universal/local" bit is set to zero to reflect that the 64 bit interface identifier value has local significance. The "indi- vidual/group" bit is set to 0 to reflect the unicast address. There- fore bits 6, and 7 of the first octet Must Be Zero (MBZ). The rest of the first two octets can be any combination of bit val- ues. The Frame Relay Node Identifier is a user administered value used to Locally identify this Frame Relay Switching Node. The Frame Relay link identifier is a numerical representation of the link over which the Frame Relay VC is configured. Conta Expires in six months [Page 4] INTERNET-DRAFT IPv6 over Frame Relay 30 July 1997 The DLCI value is normalized to a 24 bit representation. This handles all combinations of 10, 17, and 24 bit DLCIs. Note that other mechanisms to generate the interface token can be used, such as random number generators, etc... In either case, in conformance to {AARCH] the bit 6 and 7 MUST be 0 to reflect the EUI-64 local significance, respectively the unicast address. Addi- tionally, octet 5, 6, and 7, MUST be the normalized value of the DLCI. This ensures that the Frame Relay "solicited-node multicast address" derived from the IPv6 address built with this interface token contains the DLCI. It also allows building a valid IPv6 "solicited-node multicast" address knowing a DLCI of an interface. 0 1 2 3 4 5 6 7 (Bits) +-----+-----+-----+-----+-----+-----+-----+-----+ 0 | | MBZ | + +-----+-----+ 1 | | +- -+ 2 | Random Generated Number | +- -+ 3 | | +- -+ 4 | | +-----+-----+-----+-----+-----+-----+-----+-----+ 5 | | +- -+ 6 | Frame Relay DLCI | +- -+ 7 | | +-----+-----+-----+-----+-----+-----+-----+-----+ The Duplicate Address Detection specified in [CONF] is used repeatedly during the interface token and local-link address gen- eration process, until the generated token and the link-local address on the link is unique. Since DLCI values are local to a Frame Relay node, it is possible to have Frame Relay nodes within a Frame Relay network with the same interface token and link-local address on distinct virtual circuits (links). 5. Link-Local Addresses The IPv6 link-local address [AARCH] for an IPv6 Frame Relay interface is formed by appending the interface token, as defined above, to the prefix FE80::/64. Conta Expires in six months [Page 5] INTERNET-DRAFT IPv6 over Frame Relay 30 July 1997 10 bits 54 bits 64 bits +----------+-----------------------+----------------------------+ |1111111010| (zeros) |Frame Relay Interface Token | +----------+-----------------------+----------------------------+ 6. Address Mapping - Unicast The procedure for mapping IPv6 addresses to Frame Relay link-layer addresses is described in [ND] and [IND]. The Source/Target Link-layer Address option used in Neighbor Discov- ery and Inverse Neighbor Discovery messages has the following format for a Frame Relay link: 0 1 2 3 4 5 6 7 +----+----+----+----+----+----+----+----+ 0 | Type | +----+----+----+----+----+----+----+----+ 1 | Length | +----+----+----+----+----+----+----+----+ with the following option values: +----+----+----+----+----+----+----+----+ 2 |EA=3D0| C/R| DLCI(high order) | +----+----+----+----+----+----+----+----+ 3 |EA=3D1| DE |BECN|FECN| DLCI(low order) | +----+----+----+----+----+----+----+----+ 4 | | + + 5 | | + Padding + 6 | (zeros) | + + 7 | | +----+----+----+----+----+----+----+----+ Conta Expires in six months [Page 6] INTERNET-DRAFT IPv6 over Frame Relay 30 July 1997 0 1 2 3 4 5 6 7 +----+----+----+----+----+----+----+----+ 2 |EA=3D0| C/R| DLCI (high order) | +----+----+----+----+----+----+----+----+ 3 |EA=3D0| DLCI | +----+----+----+----+----+----+----+----+ 4 |EA=3D1| DE |BECN|FECN| DLCI(low order) | +----+----+----+----+----+----+----+----+ 5 | | + + 6 | Padding | + + 7 | | +----+----+----+----+----+----+----+----+ 0 1 2 3 4 5 6 7 +----+----+----+----+----+----+----+----+ 2 |EA=3D0| C/R| DLCI (high order) | +----+----+----+----+----+----+----+----+ 3 |EA=3D0| DLCI | +----+----+----+----+----+----+----+----+ 4 |EA=3D0| DLCI | +----+----+----+----+----+----+----+----+ 5 |EA=3D1| DE |BECN|FECN| DLCI(low order) | +----+----+----+----+----+----+----+----+ 6 | | + Padding + 7 | | +----+----+----+----+----+----+----+----+ Option fields: Type 1 for Source Link-layer address. 2 for Target Link-layer address. Length 1 (in units of 8 octets) for a 10, 17, or 24 bit DLCI DLCI The 10, 17, or 24 bit DLCI. The C/R, DE, BECN, FECN bits have no addressing significance. The EA bit signals the end of a DLCI. 6. Address Mapping - Solicited-Node Multicast Address A Frame Relay interface token contains the 24 bit normalized value of the DLCI. An IPv6 packet with an IPv6 Solicited-Node Multicast des- tination address consisting of the sixteen octets DST[1] through DST[16], is transmitted to the Frame Relay DLCI derived from DST[14], Conta Expires in six months [Page 7] INTERNET-DRAFT IPv6 over Frame Relay 30 July 1997 DST[15], and DST[16] - 24 bit normalized 10, 17, or 24 bit DLCI value. Conversely, an IPv6 "solicited-node multicast" address built based on an interface's known DLCI is a valid multicast address for that interface. 0 1 2 3 4 5 6 7 +----+----+----+----+----+----+----+----+ 0 |EA=3D0| C/R| DLCI(high order) | +----+----+----+----+----+----+----+----+ 1 |EA=3D1| DE |BECN|FECN| DLCI(low order) | +----+----+----+----+----+----+----+----+ 0 1 2 3 4 5 6 7 +----+----+----+----+----+----+----+----+ 0 |EA=3D0| C/R| DLCI (high order) | +----+----+----+----+----+----+----+----+ 1 |EA=3D0| DLCI | +----+----+----+----+----+----+----+----+ 2 |EA=3D1| DE |BECN|FECN| DLCI(low order) | +----+----+----+----+----+----+----+----+ 0 1 2 3 4 5 6 7 +----+----+----+----+----+----+----+----+ 0 |EA=3D0| C/R| DLCI (high order) | +----+----+----+----+----+----+----+----+ 1 |EA=3D0| DLCI | +----+----+----+----+----+----+----+----+ 2 |EA=3D0| DLCI | +----+----+----+----+----+----+----+----+ 3 |EA=3D1| DE |BECN|FECN| DLCI(low order) | +----+----+----+----+----+----+----+----+ 7. Security Considerations The mechanisms defined in this document for generating IPv6 Frame Relay address tokens are intended to provide local link uniqueness. There is no security protection from duplication through forgery or accident. 8. Acknowledgments Thanks to Dan Harrington and Milan Merhar for reviewing this document and providing useful suggestions. Conta Expires in six months [Page 8] INTERNET-DRAFT IPv6 over Frame Relay 30 July 1997 9. References [RFC-1883] S. Deering, R. Hinden, "Internet Protocol Version 6 Speci- fication" [AARCH]R. Hinden, S. Deering "IPv6 Addressing Architecture" [ND] RFC 1970, T. Narten, E. Nordmark, W.Simpson "Neighbor Discovery for IP Version 6 (IPv6)" [CONF] RFC 1971, S. Thomson, T. Narten "IPv6 Stateless Autoconfigura- tion" [ENCAPS]RFC 1490, T. Bradley, C. Brown, A. Malis, "Multiprotocol Interconnect over Frame Relay". [IND] A. Conta "IPv6 ND Extensions for Inverse Neighbor Discovery". Authors' Addresses Alex Conta Lucent Technologies Inc. 300 Baker Ave, Suite 100 Concord, MA 01742 +1-508-287-2842 email: aconta@lucent.com Martin Mueller Lucent Technologies Inc. 300 Baker Ave, Suite 100 Concord, MA 01742 +1-508-287-2833 email: memueller@lucent.com Conta Expires in six months [Page 9] INTERNET-DRAFT IPv6 over Frame Relay 30 July 1997 Conta Expires in six months [Page 10]