ION/IPng Working Group A. Conta
INTERNET-DRAFT (Lucent)
A. Malis
(Ascend)
M. Mueller
(Lucent)
December 1997
Transmission of IPv6 Packets over Frame Relay Networks
Specification
draft-ietf-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 December 18, 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 December 18, 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 December 18, 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 /
| . |
+-----------------------+-----------------------+
| |
+ 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 - 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 December 18, 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 December 18, 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 December 18, 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 December 18, 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 December 18, 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 December 18, 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 December 18, 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 December 18, 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 December 18, 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 December 18, 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", <draft-ietf-ion-ipv6-00.txt>
[IPv6_ATM] G. Armitage, P. Schulter, M. York, G. Harter, "IPv6 over
ATM Networks", <draft-ietf-ion-ipv6-atm-00.txt>
[IPv6_ETH] M. Crowford "Transmission of IPv6 packets over Ethernet
Networks", <draft-ietf-ipngwg-trans-ethernet-03.txt>
[IPv6_FDDI] M. Crowford "Transmission of IPv6 packets over FDDI
Networks", <draft-ietf-ipngwg-trans-fddi-net-03.txt>
[IPv6_TR] T. Narten, M. Crowford, M. Thomas "Transmission of IPv6
packets over Token Ring Networks", <draft-ietf-ipngwg-trans-
tokenring-04.txt>
conta & malis & mueller Expires in six months [Page 14]
INTERNET-DRAFT IPv6 over Frame Relay Networks December 18, 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 December 18, 1997
conta & malis & mueller Expires in six months [Page 16]
