[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 RFC 2467

IPng Working Group                                         Matt Crawford
Internet Draft                                                  Fermilab
                                                      September 26, 1997

              Transmission of IPv6 Packets over FDDI Networks
                 <draft-ietf-ipngwg-trans-fddi-net-03.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 document specifies the frame format for transmission of IPv6
    packets and the method of forming IPv6 link-local addresses and
    statelessly autoconfigured addresses on FDDI networks.  It also
    specifies the content of the Source/Target Link-layer Address option
    used in 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].




Expires March 26, 1998          Crawford                        [Page 1]


Internet Draft               IPv6 Over FDDI           September 26, 1997


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 each node.  If a Router Advertisement received on
    an FDDI interface has an MTU option specifying an MTU larger than
    4352, or 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" 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.















Expires March 26, 1998          Crawford                        [Page 2]


Internet Draft               IPv6 Over FDDI           September 26, 1997



                      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.




Expires March 26, 1998          Crawford                        [Page 3]


Internet Draft               IPv6 Over FDDI           September 26, 1997


    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 must not depend on support from MAC
    bridges, unless those bridges are known to correctly implement IPv6
    Path MTU Discovery [PMTU, ICMPV6].

    For correct operation when mixed media are bridged together by
    bridges which do not support IPv6 Path MTU Discovery, 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 a
    default MTU larger than the smallest MTU.


5.  Stateless Autoconfiguration

    The Interface Identifier [AARCH] for an FDDI interface is based on
    the EUI-64 identifier [EUI64] derived from the interface's built-in
    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 Identifier is then formed from the EUI-64 by
    complementing the "Universal/Local" (U/L) bit, which is the next-
    to-lowest order bit of the first octet of the EUI-64.  For further
    discussion on this point, see [ETHER] and [AARCH].

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



Expires March 26, 1998          Crawford                        [Page 4]


Internet Draft               IPv6 Over FDDI           September 26, 1997



                             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 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 [ACONF]
    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 Identifier, as defined above, to the
    prefix FE80::/64.

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



7.  Address Mapping -- Unicast

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




Expires March 26, 1998          Crawford                        [Page 5]


Internet Draft               IPv6 Over FDDI           September 26, 1997


    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 to derive the 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 Identifiers from MAC addresses
    is intended to preserve global uniqueness when possible.  However,
    there is no protection from duplication through accident or forgery.


10.  References

    [AARCH] R. Hinden, S. Deering "IP Version 6 Addressing
            Architecture", Currently draft-ietf-ipngwg-addr-arch-v2-
            02.txt.


    [ACONF] S. Thomson, T. Narten, "IPv6 Stateless Address
            Autoconfiguration", currently draft-ietf-ipngwg-addrconf-



Expires March 26, 1998          Crawford                        [Page 6]


Internet Draft               IPv6 Over FDDI           September 26, 1997


            v2-00.txt.


    [DISC]  T. Narten, E. Nordmark, W. A. Simpson, "Neighbor Discovery
            for IP Version 6 (IPv6)", currently draft-ietf-ipngwg-
            discovery-v2-00.txt.


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


    [EUI64] "64-Bit Global Identifier Format Tutorial",
            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)
            Specification", currently draft-ietf-ipngwg-ipv6-spec-v2-
            00.txt.


    [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.


11.  Author's Address

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

    Phone: +1 630 840-3461

    EMail: crawdad@fnal.gov






Expires March 26, 1998          Crawford                        [Page 7]


Html markup produced by rfcmarkup 1.112, available from https://tools.ietf.org/tools/rfcmarkup/