As per Relevance of the word standards, we have this rfc below:











Network Working Group M.
Request for Comments: 2467
Obsoletes: 2019 December 1998
Category: Standards


Transmission of IPv6 Packets over FDDI

Status of this

This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited

Copyright

Copyright (C) The Internet Society (1998). All Rights Reserved

1.

This document specifies the frame format for transmission of IPv
packets and the method of forming IPv6 link-local addresses
statelessly autoconfigured addresses on FDDI networks. It
specifies the content of the Source/Target Link-layer Address
used in Router Solicitation, Router Advertisement,
Solicitation, Neighbor Advertisement and Redirect messages when
messages are transmitted on an FDDI network

This document replaces RFC 2019, "Transmission of IPv6 Packets
FDDI", which will become historic

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in [RFC 2119].

2. Maximum Transmission

FDDI permits a frame length of 4500 octets (9000 symbols),
at least 22 octets (44 symbols) of Data Link encapsulation
long-format addresses are used. Subtracting 8 octets of LLC/
header, this would, in principle, allow the IPv6 [IPV6] packet in
Information field to be up to 4470 octets. However, it is
to allow for the variable sizes and possible future extensions of
MAC header and frame status fields. The default MTU size for IPv
packets on an FDDI network is therefore 4352 octets. This size
be reduced by a Router Advertisement [DISC] containing an MTU



Crawford Standards Track [Page 1]

RFC 2467 IPv6 over FDDI December 1998


which specifies a smaller MTU, or by manual configuration of
node. If a Router Advertisement received on an FDDI interface has
MTU option specifying an MTU larger than 4352, or larger than
manually configured value, that MTU option may be logged to
management but must be otherwise ignored

For purposes of this document, information received from DHCP
considered "manually configured" and the term FDDI includes CDDI

3. Frame

FDDI provides both synchronous and asynchronous transmission,
the latter class further subdivided by the use of restricted
unrestricted tokens. Only asynchronous transmission
unrestricted tokens is required for FDDI interoperability
Accordingly, IPv6 packets shall be sent in asynchronous frames
unrestricted tokens. The robustness principle dictates that
should be able to receive synchronous frames and asynchronous
sent using restricted tokens

IPv6 packets are transmitted in LLC/SNAP frames, using long-
(48 bit) addresses. The data field contains the IPv6 header
payload and is followed by the FDDI Frame Check Sequence,
Delimiter, and Frame Status symbols



























Crawford Standards Track [Page 2]

RFC 2467 IPv6 over FDDI December 1998


0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+
| FC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination |
+- -+
| FDDI |
+- -+
| Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source |
+- -+
| FDDI |
+- -+
| Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSAP | SSAP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CTL | OUI ... |
+-+-+-+-+-+-+-+-+ +
| ... OUI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 |
+- -+
| header |
+- -+
| and |
+- -+
/ payload ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

(Each tic mark represents one bit.)

FDDI Header Fields

FC The Frame Code must be in the range 50 to 57
hexadecimal, inclusive, with the three low order
indicating the frame priority

DSAP, SSAP Both the DSAP and SSAP fields shall contain the value
hexadecimal, indicating SNAP encapsulation

CTL The Control field shall be set to 03 hexadecimal
indicating Unnumbered Information




Crawford Standards Track [Page 3]

RFC 2467 IPv6 over FDDI December 1998


OUI The Organizationally Unique Identifier shall be set
000000 hexadecimal

Ethertype The Ethernet protocol type ("ethertype") shall be set
the value 86DD hexadecimal

4. Interaction with

802.1d MAC bridges which connect different media, for
Ethernet and FDDI, have become very widespread. Some of them do IPv
packet fragmentation and/or support IPv4 Path MTU discovery [
1981], many others do not, or do so incorrectly. Use of IPv6 in
bridged mixed-media environment must not depend on support from
bridges, unless those bridges are known to correctly implement IPv
Path MTU Discovery [RFC 1981, ICMPV6].

For correct operation when mixed media are bridged together
bridges which do not support IPv6 Path MTU Discovery, the
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
in each node which is connected to a medium with a default MTU
than the smallest MTU

5. Stateless

The Interface Identifier [AARCH] for an FDDI interface is based
the EUI-64 identifier [EUI64] derived from the interface's built-
48-bit IEEE 802 address. The EUI-64 is formed as follows
(Canonical bit order is assumed throughout. See [CANON] for
caution on bit-order effects in LAN interfaces.)

The OUI of the FDDI MAC address (the first three octets) becomes
company_id of the EUI-64 (the first three octets). The fourth
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
octets of the EUI-64.

The Interface Identifier is then formed from the EUI-64
complementing the "Universal/Local" (U/L) bit, which is the next-to
lowest order bit of the first octet of the EUI-64. For
discussion on this point, see [ETHER] and [AARCH].










Crawford Standards Track [Page 4]

RFC 2467 IPv6 over FDDI December 1998


For example, the Interface Identifier for an FDDI interface
built-in address is, in hexadecimal

34-56-78-9A-BC-

would

36-56-78-FF-FE-9A-BC-DE

A different MAC address set manually or by software should not
used to derive the Interface Identifier. If such a MAC address
be used, its global uniqueness property should be reflected in
value of the U/L bit

An IPv6 address prefix used for stateless autoconfiguration [ACONF
of an FDDI interface must have a length of 64 bits

6. Link-Local

The IPv6 link-local address [AARCH] for an FDDI interface is
by appending the Interface Identifier, as defined above, to
prefix FE80::/64.

10 bits 54 bits 64
+----------+-----------------------+----------------------------+
|1111111010| (zeros) | Interface Identifier |
+----------+-----------------------+----------------------------+

7. Address Mapping --

The procedure for mapping IPv6 unicast addresses into FDDI link-
addresses is described in [DISC]. The Source/Target Link-
Address option has the following form when the link layer is FDDI

0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- FDDI -+
| |
+- Address -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+






Crawford Standards Track [Page 5]

RFC 2467 IPv6 over FDDI December 1998


Option fields

Type 1 for Source Link-layer address
2 for Target Link-layer address

Length 1 (in units of 8 octets).

FDDI
The 48 bit FDDI IEEE 802 address, in canonical bit order
This is the address the interface currently responds to
and may be different from the built-in address used
derive the Interface Identifier

8. Address Mapping --

An IPv6 packet with a multicast destination address DST,
of the sixteen octets DST[1] through DST[16], is transmitted to
FDDI multicast address whose first two octets are the value 3333
hexadecimal and whose last four octets are the last four octets
DST

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 1 0 0 1 1|0 0 1 1 0 0 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DST[13] | DST[14] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DST[15] | DST[16] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

9. Differences From RFC 2019

The following are the functional differences between
specification and RFC 2019.

"FDDI adjacency detection" has been removed, due to recent
in IEEE 802.1p

The Address Token, which was a node's 48-bit MAC address,
replaced with the Interface Identifier, which is 64 bits
length and based on the EUI-64 format [EUI64]. An IEEE-
mapping exists from 48-bit MAC addresses to EUI-64 form

A prefix used for stateless autoconfiguration must now be 64
long rather than 80. The link-local prefix is also shortened
64 bits






Crawford Standards Track [Page 6]

RFC 2467 IPv6 over FDDI December 1998


10. Security

The method of derivation of Interface Identifiers from MAC
is intended to preserve global uniqueness when possible. However
there is no protection from duplication through accident or forgery

11.

[AARCH] Hinden, R. and S. Deering "IP Version 6
Architecture", RFC 2373, July 1998.

[ACONF] Thomson, S. and T. Narten, "IPv6 Stateless
Autoconfiguration", RFC 2462, December 1998.

[CANON] Narten, T. and C. Burton, "A Caution On The
Ordering Of Link-Layer Addresses", RFC 2469, December 1998.

[DISC] Narten, T., Nordmark, E. and W. Simpson, "Neighbor
for IP Version 6 (IPv6)", RFC 2461, December 1998.

[ETHER] Crawford, M., "Transmission of IPv6 Packets over
Networks", RFC 2464, December 1998.

[EUI64] "Guidelines For 64-bit Global Identifier (EUI-64)",
http://standards.ieee.org/db/oui/tutorials/EUI64.html

[ICMPV6] Conta, A. and S. Deering, "Internet Control
Protocol (ICMPv6) for the Internet Protocol Version 6
(IPv6) Specification", RFC 2463, December 1998.

[IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.

[RFC 1981] McCann, J., Deering, S. and J. Mogul, "Path MTU
for IP version 6", RFC 1981, August 1996.

[RFC 2119] Bradner, S., "Key words for use in RFCs to
Requirement Levels", BCP 14, RFC 2119, March 1997.













Crawford Standards Track [Page 7]

RFC 2467 IPv6 over FDDI December 1998


12. Author's

Matt
Fermilab MS 368
PO Box 500
Batavia, IL 60510


Phone: +1 630 840-3461
EMail: crawdad@fnal.









































Crawford Standards Track [Page 8]

RFC 2467 IPv6 over FDDI December 1998


13. Full Copyright

Copyright (C) The Internet Society (1998). All Rights Reserved

This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English

The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns

This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
























Crawford Standards Track [Page 9]








if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.




RFC documents can be found at I.E.T.F.



Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX







Spectrum