draft-ietf-ipngwg-trans-fddi-net-02.txt   draft-ietf-ipngwg-trans-fddi-net-03.txt 
IPng Working Group Matt Crawford IPng Working Group Matt Crawford
Internet Draft Fermilab Internet Draft Fermilab
July 18, 1997 September 26, 1997
Transmission of IPv6 Packets over FDDI Networks Transmission of IPv6 Packets over FDDI Networks
<draft-ietf-ipngwg-trans-fddi-net-02.txt> <draft-ietf-ipngwg-trans-fddi-net-03.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 1, line 33 skipping to change at page 1, line 33
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet Drafts Shadow "1id-abstracts.txt" listing contained in the Internet Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim). Rim).
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
1. Introduction 1. Introduction
This memo specifies the MTU and frame format for transmission of This document specifies the frame format for transmission of IPv6
IPv6 packets on FDDI networks, including a method for MTU packets and the method of forming IPv6 link-local addresses and
determination in the presence of 802.1d bridges to other media. It statelessly autoconfigured addresses on FDDI networks. It also
also specifies the method of forming IPv6 link-local addresses on specifies the content of the Source/Target Link-layer Address option
FDDI networks and the content of the Source/Target Link-layer used in Router Solicitation, Router Advertisement, Neighbor
Address option used the Router Solicitation, Router Advertisement, Solicitation, Neighbor Advertisement and Redirect messages when
Neighbor Solicitation, Neighbor Advertisement and Redirect messages those messages are transmitted on an FDDI network.
when those messages are transmitted on an FDDI network.
This document replaces RFC 2019, "Transmission of IPv6 Packets Over This document replaces RFC 2019, 'Transmission of IPv6 Packets Over
FDDI", which will become historic. FDDI', which will become historic.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [KWORD]. document are to be interpreted as described in [KWORD].
2. Maximum Transmission Unit 2. Maximum Transmission Unit
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
skipping to change at page 4, line 11 skipping to change at page 4, line 11
DSAP, SSAP Both the DSAP and SSAP fields shall contain the value AA DSAP, SSAP Both the DSAP and SSAP fields shall contain the value AA
hexadecimal, indicating SNAP encapsulation. hexadecimal, indicating SNAP encapsulation.
CTL The Control field shall be set to 03 hexadecimal, CTL The Control field shall be set to 03 hexadecimal,
indicating Unnumbered Information. indicating Unnumbered Information.
OUI The Organizationally Unique Identifier shall be set to OUI The Organizationally Unique Identifier shall be set to
000000 hexadecimal. 000000 hexadecimal.
Ethertype The ethernet protocol type ("ethertype") shall be set to Ethertype The Ethernet protocol type ("ethertype") shall be set to
the value 86DD hexadecimal. the value 86DD hexadecimal.
4. Interaction with Bridges 4. Interaction with Bridges
802.1d MAC bridges which connect different media, for example 802.1d MAC bridges which connect different media, for example
Ethernet and FDDI, have become very widespread. Some of them do Ethernet and FDDI, have become very widespread. Some of them do
IPv4 packet fragmentation and/or support IPv4 Path MTU discovery IPv4 packet fragmentation and/or support IPv4 Path MTU discovery
[PMTU], many others do not, or do so incorrectly. Use of IPv6 in a [PMTU], many others do not, or do so incorrectly. Use of IPv6 in a
bridged mixed-media environment should not depend on support from bridged mixed-media environment must not depend on support from MAC
MAC bridges. bridges, unless those bridges are known to correctly implement IPv6
Path MTU Discovery [PMTU, ICMPV6].
For correct operation when mixed media are bridged together, the
smallest MTU of all the media must be advertised by routers in an
MTU option. If there are no routers present, this MTU must be
manually configured in each node which is connected to a medium with
larger default MTU. Multicast packets on such a bridged network
must not be larger than the smallest MTU of any of the bridged
media. Often, the subnetwork topology will support larger unicast
packets to be exchanged between certain pairs of nodes. To take
advantage of high-MTU paths when possible, nodes transmitting IPv6
on FDDI should implement the following simple mechanism for "FDDI
adjacency detection".
A node which implements FDDI adjacency detection and has it enabled
on an FDDI interface must set a non-zero LLC priority in all
Neighbor Advertisement, Neighbor Solicitation and, if applicable,
Router Advertisement frames transmitted on that interface. (In IEEE
802 language, the user_priority parameter of the M_UNITDATA.request
primitive must not be zero.) If FDDI adjacency detection has been
disabled on an FDDI interface, the priority field of those frames
must be zero.
Note that an IPv6 frame which originated on an Ethernet, or
traversed an Ethernet, before being translated by an 802.1d bridge
and delivered to a node's FDDI interface will have zero in the
priority field, as required by [BRIDGE]. (There's a fine point
here: a conforming bridge may provide a management-settable Outbound
User Priority parameter for each port. However, the author is
unaware of any product that provides this optional capability and,
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
priority, a valid Router Advertisement, Neighbor Advertisement, or
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
octets), regardless of any smaller MTU configured manually or
received in a Router Advertisement MTU option. N2 may be the IPv6
destination or the next hop router to the destination.
Nodes implementing FDDI adjacency detection must provide a
configuration option to disable the mechanism. This option may be
used when a smaller MTU is desired for reasons other than mixed-
media bridging. By default, FDDI adjacency detection should be
enabled.
The only contemplated use of the LLC priority field of the FC octet For correct operation when mixed media are bridged together by
is to aid in per-destination MTU determination. It would be bridges which do not support IPv6 Path MTU Discovery, the smallest
sufficient for that purpose to require only that Router MTU of all the media must be advertised by routers in an MTU option.
Advertisements, Neighbor Advertisements, and Neighbor Solicitations If there are no routers present, this MTU must be manually
sent on FDDI always have non-zero priority. However, it may be configured in each node which is connected to a medium with a
simpler or more useful to transmit all IPv6 packets on FDDI with default MTU larger than the smallest MTU.
non-zero priority.
5. Stateless Autoconfiguration 5. Stateless Autoconfiguration
The Interface Identifier [AARCH] for an FDDI interface is based on The Interface Identifier [AARCH] for an FDDI interface is based on
the EUI-64 identifier [EUI64] derived from the interface's built-in the EUI-64 identifier [EUI64] derived from the interface's built-in
48-bit IEEE 802 address. The EUI-64 is formed as follows. 48-bit IEEE 802 address. The EUI-64 is formed as follows.
(Canonical 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 Identifier is then formed from the EUI-64 by The Interface Identifier is then formed from the EUI-64 by
complementing the "Universal/Local" (U/L) bit, which is the next- complementing the "Universal/Local" (U/L) bit, which is the next-
to-lowest order bit of the first octet of the EUI-64. For futher to-lowest order bit of the first octet of the EUI-64. For further
discussion on this point, see [ETHER] and [AARCH]. discussion on this point, see [ETHER] and [AARCH].
For example, the Interface Identifier for an FDDI interface whose For example, the Interface Identifier for an FDDI interface whose
built-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 Identifier. If such a MAC address must used to derive the Interface Identifier. If such a MAC address must
be 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 [AARCH] An IPv6 address prefix used for stateless autoconfiguration [ACONF]
of an 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 Identifier, as defined above, to the by appending the Interface Identifier, as defined above, to the
prefix FE80::/64. prefix FE80::/64.
10 bits 54 bits 64 bits 10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+ +----------+-----------------------+----------------------------+
skipping to change at page 7, line 38 skipping to change at page 6, line 39
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DST[15] | DST[16] | | DST[15] | DST[16] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9. Security Considerations 9. Security Considerations
The method of derivation of Interface Identifiers from MAC addresses The method of derivation of Interface Identifiers from MAC addresses
is 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. References
Erik Nordmark and Matt Thomas contributed to the method for
interaction with bridges.
11. References
[AARCH] R. Hinden, S. Deering "IP Version 6 Addressing [AARCH] R. Hinden, S. Deering "IP Version 6 Addressing
Architecture", Currently draft-ietf-ipngwg-addr-arch-v2- Architecture", Currently draft-ietf-ipngwg-addr-arch-v2-
02.txt. 02.txt.
[ACONF] S. Thomson, T. Narten, "IPv6 Stateless Address [ACONF] S. Thomson, T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 1971. Autoconfiguration", currently draft-ietf-ipngwg-addrconf-
v2-00.txt.
[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)", currently draft-ietf-ipngwg-
discovery-v2-00.txt.
[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. 02.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.
[ICMPV6]A. Conta, S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6)", RFC
1885
[IPV6] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) [IPV6] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 1883. Specification", currently draft-ietf-ipngwg-ipv6-spec-v2-
00.txt.
[KWORD] S. Bradner, "Key words for use in RFCs to Indicate [KWORD] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119. Requirement Levels," RFC 2119.
[PMTU] J. Mogul, S. Deering "Path MTU Discovery", RFC 1191. [PMTU] J. Mogul, S. Deering "Path MTU Discovery", RFC 1191.
12. Author's Address 11. Author's Address
Matt Crawford Matt Crawford
Fermilab MS 368 Fermilab MS 368
PO Box 500 PO Box 500
Batavia, IL 60510 Batavia, IL 60510
USA USA
Phone: +1 630 840-3461 Phone: +1 630 840-3461
EMail: crawdad@fnal.gov EMail: crawdad@fnal.gov
 End of changes. 18 change blocks. 
84 lines changed or deleted 37 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/