Internet Draft ION/IPng Working Group A. Conta INTERNET-DRAFT (Lucent) A. Malis (Ascend) M. Mueller (Lucent) November 1997 Transmission of IPv6 Packets over Frame Relay Networks Specification draft-conta-ion-ipv6-fr-00.txt Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents 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 mechanisms for the transmission of IPv6 packets over Frame Relay networks. 1. Introduction This document specifies the frame format for transmission of IPv6 packets over Frame Relay networks, the method of forming IPv6 link- local addresses on Frame Relay links, and the mapping of the IPv6 conta & malis & mueller Expires in six months [Page 1] INTERNET-DRAFT IPv6 over Frame Relay Networks November 17, 1997 addresses to Frame Relay addresses. It also specifies the content of the Source/Target 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. It is part of a set of specifications that define such IPv6 mechanisms for Non Broadcast Multi Access (NBMA) media [IPV6_NBMA], [IPv6_ATM], and a larger set that defines such mechanisms for specific link layers [IPv6_ETH], [IPv6_FDDI], [IPv6_PPP], [IPv6_ATM], etc... The information in this document applies to Frame Relay devices which serve as end stations (DTEs) on a public or private Frame Relay network (for example, provided by a common carrier or PTT.) Frame Relay end stations can be IPv6 hosts or routers. In this document they are referred to as nodes. In a Frame Relay network, a number of virtual circuits form the connections between the attached stations (nodes). The resulting set of interconnected devices forms a private Frame Relay group which may be either fully interconnected with a complete "mesh" of virtual circuits, or only partially interconnected. In either case, each virtual circuit is uniquely identified at each Frame Relay interface (card) 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 (also referred to as logical-link), with its own link parameters, distinct from the parameters of other virtual circuits 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, incoming/outgoing burst size, incoming/outgoing frame rate. By default a DLCI is 10 bits in length. Frame Relay specifications define also 16, 17, or 23 bit DLCIs. The former is not used, while the latter two are suggested for use with SVCs. Frame Relay virtual circuits can be created administratively as Permanent Virtual Circuits -- PVCs -- or dynamically as Switched Virtual Circuits -- SVCs. The mechanisms defined in this document are intended to apply to both permanent and switched Frame Relay virtual circuits (PVCs, and respectively SVCs), whether they are 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. conta & malis & mueller Expires in six months [Page 2] INTERNET-DRAFT IPv6 over Frame Relay Networks November 17, 1997 2. Maximum Transmission Unit IPv6 requires a minimum MTU size of 576 [TBD] octets. In general, Frame Relay devices are configured to have a maximum frame size of at least 1600 octets. Therefore, the default IPv6 MTU size for a Frame Relay interface is considered to be 1592. A smaller than default frame size can be configured but of course not smaller than the minimum IPv6 MTU. An adequate larger than default IPv6 MTU can be configured to avoid fragmentation. The maximum frame 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 frame size to approximately 4088 bytes. A larger desired frame 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. In general, if upper layers provide adequate error protection/detection mechanisms, implementations may allow configuring a Frame Relay link with a larger than 4080 octets frame size but with a lesser error protection/detection mechanism at link layer. However, because IPv6 relies on the upper and lower layer error detection, configuring the IPv6 MTU to a value larger than 4080 is strongly discouraged. Although a Frame Relay circuit allows the definition of distinct maximum 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 may limit the setting of the Frame Relay maximum frame size to the interface (link, or card) level, which then is 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 will not exceed the configured maximum frame size. 3. Frame format The IPv6 frame encapsulation for Frame Relay (for both PVCs and SVCs) follows [ENCAPS], which allows a VC to carry IPv6 packets along with other protocol packets. The NLPID frame format is used, in which the IPv6 NLPID has a value of 0x8E: conta & malis & mueller Expires in six months [Page 3] INTERNET-DRAFT IPv6 over Frame Relay Networks November 17, 1997 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 / | . | +-----------------------+-----------------------+ "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 - the first bit is stored in the least significant, i.e., the right- most bit of a byte in memory) [CANON]is the following: 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 conta & malis & mueller Expires in six months [Page 4] INTERNET-DRAFT IPv6 over Frame Relay Networks November 17, 1997 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 DLCI The encapsulation of data or control messages exchanged by various protocols that use SNAP encapsulation (with their own PIDs) is not affected, The encoding of the IPv6 protocol identifier in such messages MUST be done according to the specifications of those protocols, and [ASSNUM]. 4. Stateless Autoconfiguration An interface identifier [AARCH] for an IPv6 Frame Relay interface must be unique on a Frame Relay link [AARCH], and must be unique on each of the virtual links represented by the VCs terminated on the interface. The interface identifier for the Frame Relay interface is locally generated by the IPv6 module. Each virtual circuit in a Frame Relay network is uniquely identified on a Frame Relay interface by a DLCI. Furthermore, a DLCI can be seen as an identification of the end point of a virtual circuit on a Frame Relay interface. Since each Frame Relay VC is configured or established separately, and acts like an independent virtual-link from other VCs in the network, or on the interface, link, wire or fiber, it seems beneficial to view each VC's termination point on the Frame Relay interface as a "pseudo-interface" or "logical-interface" overlaid on the Frame Relay interface. Furthermore, it seems beneficial to be able to generate and associate an IPv6 autoconfigured address (including an IPv6 link local address) to each "pseudo-interface", i.e. end-point of a VC, i.e. to each DLCI on a Frame Relay interface. In order to achieve the benefits described above, the mechanisms specified in this document suggest constructing the Frame Relay interface identifier from 3 distinct fields (Fig.1): conta & malis & mueller Expires in six months [Page 5] INTERNET-DRAFT IPv6 over Frame Relay Networks November 17, 1997 (a) The "EUI bits" field. Bits 6 and 7 of the first octet, representing the EUI-64 "universal/local" and respectively "individual/group" bits converted to IPv6 use. The former is set to zero to reflect that the 64 bit interface identifier value has local significance [AARCH]. The latter is set to 0 to reflect the unicast address [AARCH]. (b) The "Mid" field. A 38 bit field which is generated with the purpose of adding uniqueness to the interface identifier. (c) The "DLCI" field. A 24 bit field that MAY hold a 10, 17, or 23 bit DLCI value which MUST be extended with 0's to 24 bits. A DLCI based interface identifier -- which contains a valid DLCI -- SHOULD be generated as a result of successfully establishing a VC -- PVC or SVC. If a DLCI is not known, the field MUST be set to the "unspecified DLCI" value which consists of setting each of the 24 bits to 1. Since DLCIs are local to a Frame Relay node, it is possible to have Frame Relay distinct virtual circuits within a Frame Relay network identified with the same DLCI values. 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 The Duplicate Address Detection specified in [CONF] is used repeatedly during the interface identifier and local-link address conta & malis & mueller Expires in six months [Page 6] INTERNET-DRAFT IPv6 over Frame Relay Networks November 17, 1997 generation process, until the generated identifier and consequently the link-local address on the link -- VC -- are unique. 4.1 Generating the "Mid" field. The "Mid" can be generated in multiple ways. This specification suggests two mechanisms: (b.1) "Use of Local Administrative Numbers" The "Mid" is filled with the result of merging: (b.1.1) A random number of 6 bits in length (Fig.2). (b.1.2) The Frame Relay Node Identifier -- 16 bits -- is a user administered value used to locally identify a Frame Relay node (Fig.2). (b.1.3) The Frame Relay Link Identifier -- 16 bits -- 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 or, conta & malis & mueller Expires in six months [Page 7] INTERNET-DRAFT IPv6 over Frame Relay Networks November 17, 1997 (b.2) "Use of E.164 numbers" If a Frame Relay interface has an E.164 number (address), the "Mid" field MUST be filled in with a number resulted from it as follows: the number represented by the 15 decimal digits of the E.164 number is binary encoded and truncated to 38 bits (Fig.3). Since the Frame Relay interface identifier has a "local" significance, the use of the E.164 based value has no real practical purposes other than adding to the uniqueness of the interface identifier on the link. Therefore the truncation can be performed on the high order or low order bits. If the high order bits truncation does not provide uniqueness on the link -- perhaps the DLCI value is not unique -- this most likely means that the VC spans more than a national and/or international destination area, and therefore the truncation of the low order bits should be performed next, which most likely will provide the desired uniqueness. 7 6 5 4 3 2 1 0 (bit order) +-----+-----+-----+-----+-----+-----+-----+-----+ (Octets) 0 | High Order of E.164 Based Value | MBZ | +- -+-----+-----+ 1 | | + + 2 | Low order of | + E.164 Address Based Value + 3 | | + + 4 | | +-----+-----+-----+-----+-----+-----+-----+-----+ 5 | | + + 6 | "DLCI" | + + 7 | | +-----+-----+-----+-----+-----+-----+-----+-----+ Fig.3 5. Link-Local Addresses The IPv6 link-local address [AARCH] for an IPv6 Frame Relay interface is formed by appending the interface identifier, formed as defined above, to the prefix FE80::/64 [AARCH]. conta & malis & mueller Expires in six months [Page 8] INTERNET-DRAFT IPv6 over Frame Relay Networks November 17, 1997 10 bits 54 bits 64 bits +----------+-----------------------+----------------------------+ |1111111010| (zeros) |Frame Relay Interface Ident.| +----------+-----------------------+----------------------------+ 6. Address Mapping -- Unicast, Multicast The procedure for mapping IPv6 addresses to link-layer addresses is described in [ND]. Additionally, extensions to Neighbor Discovery (ND) that allow the mapping of link-layer addresses to IPv6 addresses are defined as Inverse Neighbor Discovery (IND) in [IND]. This document defines the formats of the link-layer address fields used by ND and IND. The Source/Target Link-layer Address option used in Neighbor Discovery and Inverse Neighbor Discovery messages for a Frame Relay link follows the general rules defined by [ND]. IPv6 addresses can map two type of identifiers equivalent to link-layer addresses: DLCIs, and E.164 numbers. Therefore, for Frame Relay this document defines for the ND and IND messages Link-Layer Address field two distinct formats: (a) DLCI format -- used in ND and/or IND messages on VCs that were established prior to the ND or IND message exchange -- mostly PVCs. The use on SVCs makes sense with Inverse Neighbor Discovery [IND] messages if IND is employed after successful establishing of an SVC to gather information about other IPv6 addresses assigned to the remote node and that SVC. The "O" bit MUST be clear in the Neighbor Discovery Advertisement message containing such a Link-Layer Address format. This ensures that an existing cache entry that maps an IPv6 address to an E.164 address is not overwritten. (b) E.164 format -- used mostly prior to establishing a new SVC, to get the Frame Relay remote node identifier (link-layer address) mapping a certain IPv6 address. The "O" bit in the ND advertisement message MAY be set to 1, in order to allow refreshing a cache entry which maps an IPv6 address to an E.164 address. The "DLCI format" is defined as follows: conta & malis & mueller Expires in six months [Page 9] INTERNET-DRAFT IPv6 over Frame Relay Networks November 17, 1997 7 6 5 4 3 2 1 0 (bit order) +-----+-----+-----+-----+-----+-----+-----+-----+ 0 | Type | +-----+-----+-----+-----+-----+-----+-----+-----+ 1 | Length | +-----+-----+-----+-----+-----+-----+-----+-----+ with a DLCI (Q.922 address) encoded as 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 conta & malis & mueller Expires in six months [Page 10] INTERNET-DRAFT IPv6 over Frame Relay Networks November 17, 1997 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 DLCI Option fields: Type 1 for Source Link-layer address. 2 for Target Link-layer address. Length 1 (in units of 8 octets) Link-Layer Address The DLCI encoded as a Q.922 address. Description The "DLCI format" option value field has two components: (a) Address Type -- 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 the two first octets are not used -- they MUST be set to zero on transmit and MUST be ignored by the receiver. (b) DLCI -- encoded as a Q.922 address padded with zeros to the last octet of the 6 octets available for the entire Link- Layer Address field of this format. The "E.164 format" is defined as follows: conta & malis & mueller Expires in six months [Page 11] INTERNET-DRAFT IPv6 over Frame Relay Networks November 17, 1997 7 6 5 4 3 2 1 0 (bit order) +-----+-----+-----+-----+-----+-----+-----+-----+ 0 | Type | +-----+-----+-----+-----+-----+-----+-----+-----+ 1 | Length | +-----+-----+-----+-----+-----+-----+-----+-----+ with an E.164 address encoded as option value: 7 6 5 4 3 2 1 0 (bit order) +-----+-----+-----+-----+-----+-----+-----+-----+ 2 | size | 1 | 0 | +-----+-----+-----+-----+-----+-----+-----+-----+ 3 | not-used (zeros) | +-----+-----+-----+-----+-----+-----+-----+-----+ 4 | | / BCD encoded E.164 number / / / | | +-----+-----+-----+-----+-----+-----+-----+-----+ 4+size | | + Padding + 16 | (zeros) | +-----+-----+-----+-----+-----+-----+-----+-----+ Option fields: Type 1 for Source Link-layer address. 2 for Target Link-layer address. Length 2 (in units of 8 octets) Link-Layer Address The E.164 address encoded in Binary Coded Decimal (BCD). Description The "E.164 format" option value has three components: (a) Address Type -- encoded in the first two bits of the first two octets. The first bit is set to 0, the second bit is set to 1. (b) Size -- encoded in the last 6 bits of the first two octets. The maximum length is 15. The rest of the bits in the first conta & malis & mueller Expires in six months [Page 12] INTERNET-DRAFT IPv6 over Frame Relay Networks November 17, 1997 two octets are not used -- they MUST be set to zero on transmit and MUST be ignored on receive. (c) E.164 address (number) -- encoded in BCD (two digits per octet). If the E.164 has an even number of digits the encoding will fill all encoding octets -- half the number of digits. If the E.164 number has an odd number of digits, the lowest order digit fills only half of an octet -- it is placed in the first 4 bits of the last octet of the E.164 BCD encoding. The rest of the field up to the last octet of the 14 octets available is padded with zeros. Editor's note: this section will need to also specify the I.121 address format and possibly the NSAP format (work in progress in FRF). 7. Sending Neighbor Discovery Messages Frame Relay networks do not provide link-layer native multicasting mechanisms. For the correct functioning of the Neighbor Discovery mechanisms, link-layer multicasting must be emulated. One simple way of emulating multicasting for Neighbor Discovery (ND) is to send frames carrying ND multicast packets to all VCs on a Frame Relay interface. This applies to ND messages addressed to both all- node and solicited-node multicast addresses. 8. Receiving Neighbor Discovery Messages The Neighbor Discovery Solicitation messages received by a node may need preprocessing before being processed by the ND protocol engine. If such a message carries a DLCI format Source link-layer address option, the DLCI value in the Source link-layer address MUST be replaced with the appropriate format (see previous sections) of the DLCI value from the Frame Relay header of the frame containing the message. This is required for the correct further interpretation of the field during the ND protocol engine processing. 9. Security Considerations The mechanisms defined in this document for generating an IPv6 Frame Relay interface identifier are intended to provide uniqueness at link level -- virtual circuit. The protection against duplication is achieved by way of IPv6 Stateless Autoconfiguration Duplicate Address conta & malis & mueller Expires in six months [Page 13] INTERNET-DRAFT IPv6 over Frame Relay Networks November 17, 1997 Detection mechanisms. Security protection against forgery or accident at the level of the mechanisms described here is provided by the IPv6 security mechanisms applied to Neighbor Discovery [ND] or Inverse Neighbor Discovery [IND] messages. 10.Acknowledgments Thanks to D. Harrington, and M. Merhar for reviewing this document and providing useful suggestions. Also thanks to G. Armitage for his reviewing and suggestions. More [TBD]. 11.References [IPv6] RFC 1883 S. Deering, R. Hinden, "Internet Protocol Version 6 Specification" [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 Autoconfiguration" [IPv6_NBMA] G. Armitage, P. Schulter, M. York, G. Harter, "IPv6 over NBMA networks",[IPv6_ATM] G. Armitage, P. Schulter, M. York, G. Harter, "IPv6 over ATM Networks", [IPv6_ETH] M. Crowford "Transmission of IPv6 packets over Ethernet Networks", [IPv6_FDDI] M. Crowford "Transmission of IPv6 packets over FDDI Networks", [IPv6_TR] T. Narten, M. Crowford, M. Thomas "Transmission of IPv6 packets over Token Ring Networks", conta & malis & mueller Expires in six months [Page 14] INTERNET-DRAFT IPv6 over Frame Relay Networks November 17, 1997 [ENCAPS]C. Brown, A. Malis, "Multiprotocol Interconnect over Frame Relay", <draft-ietf-ion-fr-update-03.txt>. [IND] A. Conta, A. Malis, "Extensions to IPv6 Neighbor Discovery for Inverse Discovery", <draft-conta-ion-ipv6-ind-00.txt> [RFC2119] S. Bradner "Key words for use in RFCs to indicate Requirement Levels", RFC 2119. [RFC2200] J. Postel "Assigned Numbers", RFC 2200. 12.Authors' Addresses Alex Conta Lucent Technologies Inc. 300 Baker Ave, Suite 100 Concord, MA 01742 +1-978-287-2842 email: aconta@lucent.com Andrew Malis Ascend Communications 1 Robbins Rd Westford, MA 01886 +1-978-952-7414 email: malis@ascend.com Martin Mueller Lucent Technologies Inc. 300 Baker Ave, Suite 100 Concord, MA 01742 +1-978-287-2833 email: memueller@lucent.com conta & malis & mueller Expires in six months [Page 15] INTERNET-DRAFT IPv6 over Frame Relay Networks November 17, 1997 conta & malis & mueller Expires in six months [Page 16] 944