home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_i / draft-ietf-ipngwg-trans-fddi-net-00.txt < prev    next >
Text File  |  1997-03-24  |  16KB  |  451 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. IPng Working Group                                         Matt Crawford
  8. Internet Draft                                                  Fermilab
  9.                                                           March 21, 1997
  10.  
  11.               Transmission of IPv6 Packets over FDDI Networks
  12.                   <draft-ietf-ipngwg-trans-fddi-net-00.txt>
  13.  
  14. Status of this Memo
  15.  
  16.     This document is an Internet Draft.  Internet Drafts are working
  17.     documents of the Internet Engineering Task Force (IETF), its Areas,
  18.     and its Working Groups.  Note that other groups may also distribute
  19.     working documents as Internet Drafts.
  20.  
  21.     Internet Drafts are draft documents valid for a maximum of six
  22.     months.  Internet Drafts may be updated, replaced, or obsoleted by
  23.     other documents at any time.  It is not appropriate to use Internet
  24.     Drafts as reference material or to cite them other than as a
  25.     "working draft" or "work in progress."
  26.  
  27.     To learn the current status of any Internet-Draft, please check the
  28.     "1id-abstracts.txt" listing contained in the Internet Drafts Shadow
  29.     Directories on ds.internic.net (US East Coast), nic.nordu.net
  30.     (Europe), ftp.isi.edu (US  West  Coast), or munnari.oz.au (Pacific
  31.     Rim).
  32.  
  33.     Distribution of this memo is unlimited.
  34.  
  35.  
  36.  
  37. 1.  Introduction
  38.  
  39.     This memo specifies the MTU and frame format for transmission of
  40.     IPv6 packets on FDDI networks, including a method for MTU
  41.     determination in the presence of 802.1d bridges to other media.  It
  42.     also specifies the method of forming IPv6 link-local addresses on
  43.     FDDI networks and the content of the Source/Target Link-layer
  44.     Address option used the Router Solicitation, Router Advertisement,
  45.     Neighbor Solicitation and Neighbor Advertisement messages when those
  46.     messages are transmitted on an FDDI network.
  47.  
  48.  
  49. 2.  Maximum Transmission Unit
  50.  
  51.     FDDI permits a frame length of 4500 octets (9000 symbols), including
  52.     at least 22 octets (44 symbols) of Data Link encapsulation when
  53.     long-format addresses are used.  Subtracting 8 octets of LLC/SNAP
  54.  
  55.  
  56.  
  57. Expires September 21, 1997      Crawford                        [Page 1]
  58.  
  59. Internet Draft               IPv6 Over FDDI               March 21, 1997
  60.  
  61.  
  62.     header, this would, in principle, allow the IPv6 [IPV6] packet in
  63.     the Information field to be up to 4470 octets.  However, it is
  64.     desirable to allow for the variable sizes and possible future
  65.     extensions of the MAC header and frame status fields.  The default
  66.     MTU size for IPv6 packets on an FDDI network is therefore 4352
  67.     octets.  This size may be reduced by a Router Advertisement [DISC]
  68.     containing an MTU option which specifies a smaller MTU, or by manual
  69.     configuration of a smaller value on each node.  If a Router
  70.     Advertisement is received with an MTU option specifying an MTU
  71.     larger than the default or the manually configured value, that MTU
  72.     option may be logged to system management but must be otherwise
  73.     ignored.
  74.  
  75.     For purposes of this document, information received from DHCP is
  76.     considered "manually configured".
  77.  
  78.  
  79. 3.  Frame Format
  80.  
  81.     FDDI provides both synchronous and asynchronous transmission, with
  82.     the latter class further subdivided by the use of restricted and
  83.     unrestricted tokens.  Only asynchronous transmission with
  84.     unrestricted tokens is required for FDDI interoperability.
  85.     Accordingly, IPv6 packets shall be sent in asynchronous frames using
  86.     unrestricted tokens.  The robustness principle dictates that nodes
  87.     should be able to receive synchronous frames and asynchronous frames
  88.     sent using restricted tokens.
  89.  
  90.     IPv6 packets are transmitted in LLC/SNAP frames, using long-format
  91.     (48 bit) addresses.  The data field contains the IPv6 header and
  92.     payload and is followed by the FDDI Frame Check Sequence, Ending
  93.     Delimiter, and Frame Status symbols.
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113. Expires September 21, 1997      Crawford                        [Page 2]
  114.  
  115. Internet Draft               IPv6 Over FDDI               March 21, 1997
  116.  
  117.  
  118.  
  119.                       0                   1
  120.                       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
  121.                                      +-+-+-+-+-+-+-+-+
  122.                                      |      FC       |
  123.                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  124.                      |          Destination          |
  125.                      +-                             -+
  126.                      |             FDDI              |
  127.                      +-                             -+
  128.                      |            Address            |
  129.                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  130.                      |            Source             |
  131.                      +-                             -+
  132.                      |             FDDI              |
  133.                      +-                             -+
  134.                      |            Address            |
  135.                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  136.                      |     DSAP      |     SSAP      |
  137.                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  138.                      |      CTL      |      OUI ...  |
  139.                      +-+-+-+-+-+-+-+-+               +
  140.                      |          ... OUI              |
  141.                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  142.                      |           Ethertype           |
  143.                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  144.                      |             IPv6              |
  145.                      +-                             -+
  146.                      |            header             |
  147.                      +-                             -+
  148.                      |             and               |
  149.                      +-                             -+
  150.                      /            payload ...        /
  151.                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  152.  
  153.     (Each tic mark represents one bit.)
  154.  
  155.     FDDI Header Fields:
  156.  
  157.     FC          The Frame Code must be in the range 50 to 57
  158.                 hexadecimal, inclusive, with the three low order bits
  159.                 indicating the frame priority.  The Frame Code should be
  160.                 in the range 51 to 57 hexadecimal, inclusive, for
  161.                 reasons given in the next section.
  162.  
  163.     DSAP, SSAP  Both the DSAP and SSAP fields shall contain the value AA
  164.                 hexadecimal, indicating SNAP encapsulation.
  165.  
  166.  
  167.  
  168.  
  169. Expires September 21, 1997      Crawford                        [Page 3]
  170.  
  171. Internet Draft               IPv6 Over FDDI               March 21, 1997
  172.  
  173.  
  174.     CTL         The Control field shall be set to 03 hexadecimal,
  175.                 indicating Unnumbered Information.
  176.  
  177.     OUI         The Organizationally Unique Identifier shall be set to
  178.                 000000 hexadecimal.
  179.  
  180.     Ethertype   The ethernet protocol type ("ethertype") shall be set to
  181.                 the value 86DD hexadecimal.
  182.  
  183.  
  184. 4.  Interaction with Bridges
  185.  
  186.     802.1d MAC bridges which connect different media, for example
  187.     Ethernet and FDDI, have become very widespread.  Some of them do
  188.     IPv4 packet fragmentation and/or support IPv4 Path MTU discovery
  189.     [PMTU], many others do not, or do so incorrectly.  Use of IPv6 in a
  190.     bridged mixed-media environment should not depend on support from
  191.     MAC bridges.
  192.  
  193.     For correct operation when mixed media are bridged together, the
  194.     smallest MTU of all the media must be advertised by routers in an
  195.     MTU option.  If there are no routers present, this MTU must be
  196.     manually configured in each node which is connected to a medium with
  197.     larger default MTU.  Multicast packets on such a bridged network
  198.     must not be larger than the smallest MTU of any of the bridged
  199.     media.  Often, the subnetwork topology will support larger unicast
  200.     packets to be exchanged between certain pairs of nodes.  To take
  201.     advantage of high-MTU paths when possible, nodes transmitting IPv6
  202.     on FDDI should implement the following simple mechanism for "FDDI
  203.     adjacency detection".
  204.  
  205.     A node which implements FDDI adjacency detection and has it enabled
  206.     on an FDDI interface must set a non-zero LLC priority in all
  207.     Neighbor Advertisement, Neighbor Solicitation and, if applicable,
  208.     Router Advertisement frames transmitted on that interface.  (In IEEE
  209.     802 language, the user_priority parameter of the M_UNITDATA.request
  210.     primitive must not be zero.)  If FDDI adjacency detection has been
  211.     disabled on an FDDI interface, the priority field of those frames
  212.     must be zero.
  213.  
  214.     Note that an IPv6 frame which originated on an Ethernet, or
  215.     traversed an Ethernet, before being translated by an 802.1d bridge
  216.     and delivered to a node's FDDI interface will have zero in the
  217.     priority field, as required by [BRIDGE].  (There's a fine point
  218.     here: a conforming bridge may provide a management-settable Outbound
  219.     User Priority parameter for each port.  However, the author is
  220.     unaware of any product that provides this optional capability and,
  221.     in any case, the default value for the parameter is zero.)
  222.  
  223.  
  224.  
  225. Expires September 21, 1997      Crawford                        [Page 4]
  226.  
  227. Internet Draft               IPv6 Over FDDI               March 21, 1997
  228.  
  229.  
  230.     If a node N1 receives, in an FDDI frame with a non-zero LLC
  231.     priority, a valid Router Advertisement, Neighbor Advertisement, or
  232.     Neighbor Solicitation from a node N2, then N1 may send unicast IPv6
  233.     packets to N2 with sizes up to the default IPv6 FDDI MTU (4352
  234.     octets), regardless of any smaller MTU configured manually or
  235.     received in a Router Advertisement MTU option.  N2 may be the IPv6
  236.     destination or the next hop router to the destination.
  237.  
  238.     Nodes implementing FDDI adjacency detection must provide a
  239.     configuration option to disable the mechanism.  This option may be
  240.     used when a smaller MTU is desired for reasons other than mixed-
  241.     media bridging.  By default, FDDI adjacency detection should be
  242.     enabled.
  243.  
  244.     The only contemplated use of the LLC priority field of the FC octet
  245.     is to aid in per-destination MTU determination.  It would be
  246.     sufficient for that purpose to require only that Router
  247.     Advertisements, Neighbor Advertisements, and Neighbor Solicitations
  248.     sent on FDDI always have non-zero priority.  However, it may be
  249.     simpler or more useful to transmit all IPv6 packets on FDDI with
  250.     non-zero priority.
  251.  
  252.  
  253. 5.  Stateless Autoconfiguration
  254.  
  255.     The interface token [CONF] for an FDDI interface is the EUI-64
  256.     identifier [EUI64] derived from the interface's built-in 48-bit IEEE
  257.     802 address.  The OUI of the Ethernet address (the first three
  258.     octets) becomes the company_id of the EUI-64 (the first three
  259.     octets).  The fourth and fifth octets of the EUI are set to the
  260.     fixed value FFFE hexadecimal.  The last three octets of the Ethernet
  261.     address become the last three octets of the EUI-64.
  262.  
  263.     For example, the interface token for an Ethernet interface whose
  264.     built-in address is, in hexadecimal and in canonical bit order,
  265.  
  266.                              34-56-78-9A-BC-DE
  267.  
  268.     would be
  269.  
  270.                           34-56-78-FF-FE-9A-BC-DE.
  271.  
  272.     A different MAC address set manually or by software should not be
  273.     used to derive the interface token.
  274.  
  275.     An IPv6 address prefix used for stateless autoconfiguration of an
  276.     FDDI interface must have a length of 64 bits.
  277.  
  278.  
  279.  
  280.  
  281. Expires September 21, 1997      Crawford                        [Page 5]
  282.  
  283. Internet Draft               IPv6 Over FDDI               March 21, 1997
  284.  
  285.  
  286. 6.  Link-Local Addresses
  287.  
  288.     The IPv6 link-local address [AARCH] for an FDDI interface is formed
  289.     by appending the interface token, as defined above, to the prefix
  290.     FE80::/64.
  291.  
  292.        10 bits            54 bits                  64 bits
  293.      +----------+-----------------------+----------------------------+
  294.      |1111111010|         (zeros)       |      Interface Token       |
  295.      +----------+-----------------------+----------------------------+
  296.  
  297.  
  298.  
  299. 7.  Address Mapping -- Unicast
  300.  
  301.     The procedure for mapping IPv6 addresses into FDDI link-layer
  302.     addresses is described in [DISC].  The Source/Target Link-layer
  303.     Address option has the following form when the link layer is FDDI.
  304.  
  305.                       0                   1
  306.                       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
  307.                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  308.                      |     Type      |    Length     |
  309.                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  310.                      |                               |
  311.                      +-            FDDI             -+
  312.                      |                               |
  313.                      +-           Address           -+
  314.                      |                               |
  315.                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  316.  
  317.  
  318.     Option fields:
  319.  
  320.     Type        1 for Source Link-layer address.
  321.                 2 for Target Link-layer address.
  322.  
  323.     Length      1 (in units of 8 octets).
  324.  
  325.     FDDI Address
  326.                 The 48 bit FDDI IEEE 802 address, in canonical bit
  327.                 order.  This is the address the interface currently
  328.                 responds to, and may be different from the built-in
  329.                 address used as the address token.
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337. Expires September 21, 1997      Crawford                        [Page 6]
  338.  
  339. Internet Draft               IPv6 Over FDDI               March 21, 1997
  340.  
  341.  
  342. 8.  Address Mapping -- Multicast
  343.  
  344.     An IPv6 packet with a multicast destination address DST, consisting
  345.     of the sixteen octets DST[1] through DST[16], is transmitted to the
  346.     FDDI multicast address whose first two octets are the value 3333
  347.     hexadecimal and whose last four octets are the last four octets of
  348.     DST.
  349.  
  350.                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  351.                      |0 0 1 1 0 0 1 1|0 0 1 1 0 0 1 1|
  352.                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  353.                      |   DST[13]     |   DST[14]     |
  354.                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  355.                      |   DST[15]     |   DST[16]     |
  356.                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  357.  
  358.  
  359.  
  360. 9.  Security Considerations
  361.  
  362.     Security considerations are not addressed in this memo.
  363.  
  364.  
  365. 10.  Acknowledgments
  366.  
  367.     Erik Nordmark and Matt Thomas contributed to the method for
  368.     interaction with bridges.
  369.  
  370.  
  371. 11.  References
  372.  
  373.     [AARCH] R. Hinden, S. Deering "IP Version 6 Addressing
  374.             Architecture", RFC 1884.
  375.  
  376.  
  377.     [BRIDGE]ISO/IEC 10038 : 1993 [ANSI/IEEE Std 802.1D] Media access
  378.             control (MAC) bridges.
  379.  
  380.  
  381.     [CONF]  S. Thomson, T. Narten, "IPv6 Stateless Address
  382.             Autoconfiguration", RFC 1971.
  383.  
  384.  
  385.     [DISC]  T. Narten, E. Nordmark, W. A. Simpson, "Neighbor Discovery
  386.             for IP Version 6 (IPv6)", RFC 1970.
  387.  
  388.  
  389.     [EUI64] "64-Bit Global Identifier Format Tutorial",
  390.  
  391.  
  392.  
  393. Expires September 21, 1997      Crawford                        [Page 7]
  394.  
  395. Internet Draft               IPv6 Over FDDI               March 21, 1997
  396.  
  397.  
  398.             http://standards.ieee.org/db/oui/tutorials/EUI64.html.
  399.  
  400.  
  401.     [IPV6]  S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6)
  402.             Specification", RFC 1883.
  403.  
  404.  
  405.     [PMTU]  J. Mogul, S. Deering "Path MTU Discovery", RFC 1191.
  406.  
  407.  
  408. 12.  Author's Address
  409.  
  410.     Matt Crawford
  411.     Fermilab MS 368
  412.     PO Box 500
  413.     Batavia, IL 60510
  414.     USA
  415.  
  416.     Phone: +1 630 840-3461
  417.  
  418.     EMail: crawdad@fnal.gov
  419.  
  420.  
  421.  
  422.  
  423.  
  424.  
  425.  
  426.  
  427.  
  428.  
  429.  
  430.  
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449. Expires September 21, 1997      Crawford                        [Page 8]
  450.  
  451.