📄 rfc2590.txt
字号:
Network Working Group A. Conta
Request for Comments: 2590 Lucent
Category: Standards Track A. Malis
Ascend
M. Mueller
Lucent
May 1999
Transmission of IPv6 Packets over Frame Relay Networks
Specification
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. 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...................................19
Conta, et al. Standards Track [Page 1]
RFC 2590 IPv6 over Frame Relay Networks May 1999
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
addresses to Frame Relay addresses. It also specifies the content of
the Source/Target link-layer address option used in Neighbor
Discovery [ND] and 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, whether they are point to point or point to multi-
point.
Conta, et al. Standards Track [Page 2]
RFC 2590 IPv6 over Frame Relay Networks May 1999
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 IPv6 minimum MTU is defined in [IPv6].
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 and Frame Relay frame size
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.
Conta, et al. Standards Track [Page 3]
RFC 2590 IPv6 over Frame Relay Networks May 1999
3. IPv6 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:
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
Conta, et al. Standards Track [Page 4]
RFC 2590 IPv6 over Frame Relay Networks May 1999
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 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
Conta, et al. Standards Track [Page 5]
RFC 2590 IPv6 over Frame Relay Networks May 1999
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):
(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.
Conta, et al. Standards Track [Page 6]
RFC 2590 IPv6 over Frame Relay Networks May 1999
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
(Octets) 0 | |"EUI bits" |
+ +-----+-----+
1 | |
+ +
2 | "Mid" |
+ +
3 | |
+ +
4 | |
+-----+-----+-----+-----+-----+-----+-----+-----+
5 | |
+ +
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -