IPng Working Group                                         Matt Crawford
Internet Draft                                                  Fermilab
                                                           July 3, 18, 1997

              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

    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 ds.internic.net (US East Coast), nic.nordu.net
    (Europe), ftp.isi.edu (US  West  Coast), or munnari.oz.au (Pacific
    Rim).

    Distribution of this memo is unlimited.

1.  Introduction

    This memo specifies the MTU and frame format for transmission of
    IPv6 packets on FDDI networks, including a method for MTU
    determination in the presence of 802.1d bridges to other media.  It
    also specifies the method of forming IPv6 link-local addresses on
    FDDI networks and the content of the Source/Target Link-layer
    Address option used the Router Solicitation, Router Advertisement,
    Neighbor Solicitation, Neighbor Advertisement and Redirect messages
    when those messages are transmitted on an FDDI network.

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

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

2.  Maximum Transmission Unit

    FDDI permits a frame length of 4500 octets (9000 symbols), including
    at least 22 octets (44 symbols) of Data Link encapsulation when
    long-format addresses are used.  Subtracting 8 octets of LLC/SNAP
    header, this would, in principle, allow the IPv6 [IPV6] packet in
    the Information field to be up to 4470 octets.  However, it is
    desirable to allow for the variable sizes and possible future
    extensions of the MAC header and frame status fields.  The default
    MTU size for IPv6 packets on an FDDI network is therefore 4352
    octets.  This size may be reduced by a Router Advertisement [DISC]
    containing an MTU option which specifies a smaller MTU, or by manual
    configuration of a smaller value on each node.  If a Router Advertisement is received with on
    an FDDI interface has an MTU option specifying an MTU larger than the default
    4352, or the larger than a manually configured value, that MTU option
    may be logged to system management but must be otherwise ignored.

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

3.  Frame Format

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

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

                      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 bits
                indicating the frame priority.  The Frame Code should be
                in the range 51 to 57 hexadecimal, inclusive, for
                reasons given in the next section.

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

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

    OUI         The Organizationally Unique Identifier shall be set to
                000000 hexadecimal.

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

4.  Interaction with Bridges

    802.1d MAC bridges which connect different media, for example
    Ethernet and FDDI, have become very widespread.  Some of them do
    IPv4 packet fragmentation and/or support IPv4 Path MTU discovery
    [PMTU], many others do not, or do so incorrectly.  Use of IPv6 in a
    bridged mixed-media environment should not depend on support from
    MAC bridges.

    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 for the parameter 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
    is to aid in per-destination MTU determination.  It would be
    sufficient for that purpose to require only that Router
    Advertisements, Neighbor Advertisements, and Neighbor Solicitations
    sent on FDDI always have non-zero priority.  However, it may be
    simpler or more useful to transmit all IPv6 packets on FDDI with
    non-zero priority.

5.  Stateless Autoconfiguration

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

    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
    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
    octets of the EUI-64.

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

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

                             34-56-78-9A-BC-DE
    would be

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

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

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

6.  Link-Local Addresses

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

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

7.  Address Mapping -- Unicast

    The procedure for mapping IPv6 unicast addresses into FDDI link-layer link-
    layer addresses is described in [DISC].  The Source/Target Link-layer Link-
    layer 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           -+
                     |                               |
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Option fields:

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

    Length      1 (in units of 8 octets).

    FDDI Address
                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 as to derive the address token. Interface Identifier.

8.  Address Mapping -- Multicast

    An IPv6 packet with a multicast destination address DST, consisting
    of the sixteen octets DST[1] through DST[16], is transmitted to the
    FDDI multicast address whose first two octets are the value 3333
    hexadecimal and whose last four octets are the last four octets of
    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.  Security Considerations

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

10.  Acknowledgments

    Erik Nordmark and Matt Thomas contributed to the method for
    interaction with bridges.

11.  References

    [AARCH] R. Hinden, S. Deering "IP Version 6 Addressing
            Architecture", RFC 1884.

    [BRIDGE]ISO/IEC 10038 : 1993 [ANSI/IEEE Std 802.1D] Media access
            control (MAC) bridges.

    [CONF] Currently draft-ietf-ipngwg-addr-arch-v2-
            02.txt.

    [ACONF] S. Thomson, T. Narten, "IPv6 Stateless Address
            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
            for IP Version 6 (IPv6)", RFC 1970.

    [ETHER] M. Crawford, "Transmission of IPv6 Packets over Ethernet
            Networks", currently draft-ietf-ipngwg-trans-ethernet-
            01.txt.

    [EUI64] "64-Bit Global Identifier Format Tutorial",
            http://standards.ieee.org/db/oui/tutorials/EUI64.html.

    [IPV6]  S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6)
            Specification", RFC 1883.

    [KWORD] S. Bradner, "Key words for use in RFCs to Indicate
            Requirement Levels," RFC 2119.

    [PMTU]  J. Mogul, S. Deering "Path MTU Discovery", RFC 1191.

12.  Author's Address

    Matt Crawford
    Fermilab MS 368
    PO Box 500
    Batavia, IL 60510
    USA

    Phone: +1 630 840-3461

    EMail: crawdad@fnal.gov