draft-ietf-ipngwg-trans-fddi-net-01.txt   draft-ietf-ipngwg-trans-fddi-net-02.txt 
IPng Working Group Matt Crawford IPng Working Group Matt Crawford
Internet Draft Fermilab Internet Draft Fermilab
July 3, 1997 July 18, 1997
Transmission of IPv6 Packets over FDDI Networks Transmission of IPv6 Packets over FDDI Networks
<draft-ietf-ipngwg-trans-fddi-net-01.txt> <draft-ietf-ipngwg-trans-fddi-net-02.txt>
Status of this Memo Status of this Memo
This document is an Internet Draft. Internet Drafts are working This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts. working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by months. Internet Drafts may be updated, replaced, or obsoleted by
skipping to change at page 2, line 17 skipping to change at page 2, line 17
FDDI permits a frame length of 4500 octets (9000 symbols), including FDDI permits a frame length of 4500 octets (9000 symbols), including
at least 22 octets (44 symbols) of Data Link encapsulation when at least 22 octets (44 symbols) of Data Link encapsulation when
long-format addresses are used. Subtracting 8 octets of LLC/SNAP long-format addresses are used. Subtracting 8 octets of LLC/SNAP
header, this would, in principle, allow the IPv6 [IPV6] packet in header, this would, in principle, allow the IPv6 [IPV6] packet in
the Information field to be up to 4470 octets. However, it is the Information field to be up to 4470 octets. However, it is
desirable to allow for the variable sizes and possible future desirable to allow for the variable sizes and possible future
extensions of the MAC header and frame status fields. The default extensions of the MAC header and frame status fields. The default
MTU size for IPv6 packets on an FDDI network is therefore 4352 MTU size for IPv6 packets on an FDDI network is therefore 4352
octets. This size may be reduced by a Router Advertisement [DISC] octets. This size may be reduced by a Router Advertisement [DISC]
containing an MTU option which specifies a smaller MTU, or by manual containing an MTU option which specifies a smaller MTU, or by manual
configuration of a smaller value on each node. If a Router configuration of each node. If a Router Advertisement received on
Advertisement is received with an MTU option specifying an MTU an FDDI interface has an MTU option specifying an MTU larger than
larger than the default or the manually configured value, that MTU 4352, or larger than a manually configured value, that MTU option
option may be logged to system management but must be otherwise may be logged to system management but must be otherwise ignored.
ignored.
For purposes of this document, information received from DHCP is For purposes of this document, information received from DHCP is
considered "manually configured". considered "manually configured" and the term FDDI includes CDDI.
3. Frame Format 3. Frame Format
FDDI provides both synchronous and asynchronous transmission, with FDDI provides both synchronous and asynchronous transmission, with
the latter class further subdivided by the use of restricted and the latter class further subdivided by the use of restricted and
unrestricted tokens. Only asynchronous transmission with unrestricted tokens. Only asynchronous transmission with
unrestricted tokens is required for FDDI interoperability. unrestricted tokens is required for FDDI interoperability.
Accordingly, IPv6 packets shall be sent in asynchronous frames using Accordingly, IPv6 packets shall be sent in asynchronous frames using
unrestricted tokens. The robustness principle dictates that nodes unrestricted tokens. The robustness principle dictates that nodes
should be able to receive synchronous frames and asynchronous frames should be able to receive synchronous frames and asynchronous frames
skipping to change at page 4, line 51 skipping to change at page 4, line 51
disabled on an FDDI interface, the priority field of those frames disabled on an FDDI interface, the priority field of those frames
must be zero. must be zero.
Note that an IPv6 frame which originated on an Ethernet, or Note that an IPv6 frame which originated on an Ethernet, or
traversed an Ethernet, before being translated by an 802.1d bridge traversed an Ethernet, before being translated by an 802.1d bridge
and delivered to a node's FDDI interface will have zero in the and delivered to a node's FDDI interface will have zero in the
priority field, as required by [BRIDGE]. (There's a fine point priority field, as required by [BRIDGE]. (There's a fine point
here: a conforming bridge may provide a management-settable Outbound here: a conforming bridge may provide a management-settable Outbound
User Priority parameter for each port. However, the author is User Priority parameter for each port. However, the author is
unaware of any product that provides this optional capability and, unaware of any product that provides this optional capability and,
in any case, the default value for the parameter is zero.) in any case, when the parameter is available its default value is
zero.)
If a node N1 receives, in an FDDI frame with a non-zero LLC If a node N1 receives, in an FDDI frame with a non-zero LLC
priority, a valid Router Advertisement, Neighbor Advertisement, or priority, a valid Router Advertisement, Neighbor Advertisement, or
Neighbor Solicitation from a node N2, then N1 may send unicast IPv6 Neighbor Solicitation from a node N2, then N1 may send unicast IPv6
packets to N2 with sizes up to the default IPv6 FDDI MTU (4352 packets to N2 with sizes up to the default IPv6 FDDI MTU (4352
octets), regardless of any smaller MTU configured manually or octets), regardless of any smaller MTU configured manually or
received in a Router Advertisement MTU option. N2 may be the IPv6 received in a Router Advertisement MTU option. N2 may be the IPv6
destination or the next hop router to the destination. destination or the next hop router to the destination.
Nodes implementing FDDI adjacency detection must provide a Nodes implementing FDDI adjacency detection must provide a
configuration option to disable the mechanism. This option may be configuration option to disable the mechanism. This option may be
skipping to change at page 5, line 28 skipping to change at page 5, line 30
The only contemplated use of the LLC priority field of the FC octet The only contemplated use of the LLC priority field of the FC octet
is to aid in per-destination MTU determination. It would be is to aid in per-destination MTU determination. It would be
sufficient for that purpose to require only that Router sufficient for that purpose to require only that Router
Advertisements, Neighbor Advertisements, and Neighbor Solicitations Advertisements, Neighbor Advertisements, and Neighbor Solicitations
sent on FDDI always have non-zero priority. However, it may be sent on FDDI always have non-zero priority. However, it may be
simpler or more useful to transmit all IPv6 packets on FDDI with simpler or more useful to transmit all IPv6 packets on FDDI with
non-zero priority. non-zero priority.
5. Stateless Autoconfiguration 5. Stateless Autoconfiguration
The interface token [CONF] for an FDDI interface is based on the The Interface Identifier [AARCH] for an FDDI interface is based on
EUI-64 identifier [EUI64] derived from the interface's built-in 48- the EUI-64 identifier [EUI64] derived from the interface's built-in
bit IEEE 802 address. The EUI-64 is formed as follows. (Canonical 48-bit IEEE 802 address. The EUI-64 is formed as follows.
bit order is assumed throughout.) (Canonical bit order is assumed throughout.)
The OUI of the FDDI MAC address (the first three octets) becomes the The OUI of the FDDI MAC address (the first three octets) becomes the
company_id of the EUI-64 (the first three octets). The fourth and company_id of the EUI-64 (the first three octets). The fourth and
fifth octets of the EUI are set to the fixed value FFFE hexadecimal. fifth octets of the EUI are set to the fixed value FFFE hexadecimal.
The last three octets of the FDDI MAC address become the last three The last three octets of the FDDI MAC address become the last three
octets of the EUI-64. octets of the EUI-64.
The interface token is then formed from the EUI-64 by complementing The Interface Identifier is then formed from the EUI-64 by
the "Universal/Local" (U/L) bit, which is the next-to-lowest order complementing the "Universal/Local" (U/L) bit, which is the next-
bit of the first octet of the EUI-64. For futher discussion on this to-lowest order bit of the first octet of the EUI-64. For futher
point, see [ETHER]. discussion on this point, see [ETHER] and [AARCH].
For example, the interface token for an FDDI interface whose built- For example, the Interface Identifier for an FDDI interface whose
in address is, in hexadecimal, built-in address is, in hexadecimal,
34-56-78-9A-BC-DE 34-56-78-9A-BC-DE
would be would be
36-56-78-FF-FE-9A-BC-DE. 36-56-78-FF-FE-9A-BC-DE.
A different MAC address set manually or by software should not be A different MAC address set manually or by software should not be
used to derive the interface token. If such a MAC address must be used to derive the Interface Identifier. If such a MAC address must
used, its global uniqueness property should be reflected in the be used, its global uniqueness property should be reflected in the
value of the U/L bit. value of the U/L bit.
An IPv6 address prefix used for stateless autoconfiguration of an An IPv6 address prefix used for stateless autoconfiguration [AARCH]
FDDI interface must have a length of 64 bits. of an FDDI interface must have a length of 64 bits.
6. Link-Local Addresses 6. Link-Local Addresses
The IPv6 link-local address [AARCH] for an FDDI interface is formed The IPv6 link-local address [AARCH] for an FDDI interface is formed
by appending the interface token, as defined above, to the prefix by appending the Interface Identifier, as defined above, to the
FE80::/64. prefix FE80::/64.
10 bits 54 bits 64 bits 10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+ +----------+-----------------------+----------------------------+
|1111111010| (zeros) | Interface Token | |1111111010| (zeros) | Interface Identifier |
+----------+-----------------------+----------------------------+ +----------+-----------------------+----------------------------+
7. Address Mapping -- Unicast 7. Address Mapping -- Unicast
The procedure for mapping IPv6 addresses into FDDI link-layer The procedure for mapping IPv6 unicast addresses into FDDI link-
addresses is described in [DISC]. The Source/Target Link-layer layer addresses is described in [DISC]. The Source/Target Link-
Address option has the following form when the link layer is FDDI. layer Address option has the following form when the link layer is
FDDI.
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+- FDDI -+ +- FDDI -+
| | | |
+- Address -+ +- Address -+
skipping to change at page 7, line 11 skipping to change at page 7, line 14
Type 1 for Source Link-layer address. Type 1 for Source Link-layer address.
2 for Target Link-layer address. 2 for Target Link-layer address.
Length 1 (in units of 8 octets). Length 1 (in units of 8 octets).
FDDI Address FDDI Address
The 48 bit FDDI IEEE 802 address, in canonical bit The 48 bit FDDI IEEE 802 address, in canonical bit
order. This is the address the interface currently order. This is the address the interface currently
responds to, and may be different from the built-in responds to, and may be different from the built-in
address used as the address token. address used to derive the Interface Identifier.
8. Address Mapping -- Multicast 8. Address Mapping -- Multicast
An IPv6 packet with a multicast destination address DST, consisting An IPv6 packet with a multicast destination address DST, consisting
of the sixteen octets DST[1] through DST[16], is transmitted to the of the sixteen octets DST[1] through DST[16], is transmitted to the
FDDI multicast address whose first two octets are the value 3333 FDDI multicast address whose first two octets are the value 3333
hexadecimal and whose last four octets are the last four octets of hexadecimal and whose last four octets are the last four octets of
DST. DST.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 1 0 0 1 1|0 0 1 1 0 0 1 1| |0 0 1 1 0 0 1 1|0 0 1 1 0 0 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DST[13] | DST[14] | | DST[13] | DST[14] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DST[15] | DST[16] | | DST[15] | DST[16] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9. Security Considerations 9. Security Considerations
The method of derivation of interface tokens from MAC addresses is The method of derivation of Interface Identifiers from MAC addresses
intended to preserve global uniqueness when possible. However, is intended to preserve global uniqueness when possible. However,
there is no protection from duplication through accident or forgery. there is no protection from duplication through accident or forgery.
10. Acknowledgments 10. Acknowledgments
Erik Nordmark and Matt Thomas contributed to the method for Erik Nordmark and Matt Thomas contributed to the method for
interaction with bridges. interaction with bridges.
11. References 11. References
[AARCH] R. Hinden, S. Deering "IP Version 6 Addressing [AARCH] R. Hinden, S. Deering "IP Version 6 Addressing
Architecture", RFC 1884. Architecture", Currently draft-ietf-ipngwg-addr-arch-v2-
02.txt.
[BRIDGE]ISO/IEC 10038 : 1993 [ANSI/IEEE Std 802.1D] Media access
control (MAC) bridges.
[CONF] S. Thomson, T. Narten, "IPv6 Stateless Address [ACONF] S. Thomson, T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 1971. Autoconfiguration", RFC 1971.
[BRIDGE]ISO/IEC 10038 : 1993 [ANSI/IEEE Std 802.1D, 1993 Edition]
"Media access control (MAC) bridges."
[DISC] T. Narten, E. Nordmark, W. A. Simpson, "Neighbor Discovery [DISC] T. Narten, E. Nordmark, W. A. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 1970. for IP Version 6 (IPv6)", RFC 1970.
[ETHER] M. Crawford, "Transmission of IPv6 Packets over Ethernet [ETHER] M. Crawford, "Transmission of IPv6 Packets over Ethernet
Networks", currently draft-ietf-ipngwg-trans-ethernet- Networks", currently draft-ietf-ipngwg-trans-ethernet-
01.txt. 01.txt.
[EUI64] "64-Bit Global Identifier Format Tutorial", [EUI64] "64-Bit Global Identifier Format Tutorial",
http://standards.ieee.org/db/oui/tutorials/EUI64.html. http://standards.ieee.org/db/oui/tutorials/EUI64.html.
 End of changes. 20 change blocks. 
38 lines changed or deleted 41 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/