home *** CD-ROM | disk | FTP | other *** search
/ Internet Core Protocols / Oreilly-InternetCoreProtocols.iso / RFCs / rfc2497.txt < prev    next >
Encoding:
Text File  |  1999-10-14  |  10.4 KB  |  340 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                       I. Souvatzis
  8. Request for Comments: 2497                            The NetBSD Project
  9. See Also: 1201                                              January 1999
  10. Category: Standards Track
  11.  
  12.  
  13.            Transmission of IPv6 Packets over ARCnet Networks
  14.  
  15. Status of this Memo
  16.  
  17.    This document specifies an Internet standards track protocol for the
  18.    Internet community, and requests discussion and suggestions for
  19.    improvements.  Please refer to the current edition of the "Internet
  20.    Official Protocol Standards" (STD 1) for the standardization state
  21.    and status of this protocol.  Distribution of this memo is unlimited.
  22.  
  23. Copyright Notice
  24.  
  25.    Copyright (C) The Internet Society (1999).  All Rights Reserved.
  26.  
  27. 1. Introduction
  28.  
  29.    This memo specifies a frame format for transmission of IPv6 [IPV6]
  30.    packets and the method of forming IPv6 link-local and statelessly
  31.    autoconfigured addresses on ARCnet networks. It also specifies the
  32.    content of the Source/Target Link-layer Address option used by the
  33.    Router Solicitation, Router Advertisement, Neighbor Solicitation,
  34.    Neighbor Advertisement and Redirect messages described in [DISC],
  35.    when those messages are transmitted on an ARCnet.
  36.  
  37.       The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
  38.       NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
  39.       in this document are to be interpreted as described in RFC 2119
  40.       [KWORD].
  41.  
  42. 2. Frame Format
  43.  
  44.    IPv6 packets are link layer fragmented and reassembled according to
  45.    [PHDS]. A brief but sufficient discussion of this fragmentation
  46.    method can be found in [ARCIPV4].
  47.  
  48.    The protocol ID (System Code in ARCnet terminology) assigned to IPv6
  49.    is C4 hexadecimal.
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Souvatzis                   Standards Track                     [Page 1]
  59.  
  60. RFC 2497                IPv6 Datagrams on ARCnet            January 1999
  61.  
  62.  
  63. 3. Maximum Transmission Unit
  64.  
  65.    The maximum IPv6 packet length possible using this encapsulation
  66.    method is 60480 octets. Since this length is impractical because of
  67.    its worst case transmission time of several seconds, all ARCnet
  68.    implementations on a given ARCnet network should agree on a smaller
  69.    value.
  70.  
  71.    The default MTU for IPv6 [IPV6] packets on an ARCnet is 9072 octets.
  72.  
  73.    In the presence of a router, this size MAY be changed by a Router
  74.    Advertisement [DISC] containing an MTU option. If a Router
  75.    Advertisement is received with an MTU option specifying an MTU larger
  76.    than 60480, or larger than a manually configured value less than
  77.    60480, that MTU option may be logged to system management but MUST be
  78.    otherwise ignored.
  79.  
  80.    If no router is available, the local MTU MUST be left at 9072 or MUST
  81.    be manually configured to the same different value on all connected
  82.    stations.
  83.  
  84.    Implementations MAY accept arriving IPv6 datagrams which are larger
  85.    than their configured maximum transmission unit.  They are not
  86.    required to discard such datagrams. If they can not handle larger
  87.    datagrams, they MAY log the event to the system administration, but
  88.    MUST otherwise silently discard them.
  89.  
  90. 4. Stateless Auto-configuration
  91.  
  92.    If a node has an EUI-64 which is not used to form the Interface
  93.    Identifier for any other interface, it SHOULD use that EUI-64 to form
  94.    the Interface Identifier for its ARCnet interface.  If that EUI-64 is
  95.    in use for another interface attached to a different link, it MAY be
  96.    used for the ARCnet interface as well.
  97.  
  98.    The Interface Identifier is then formed from the EUI-64 by
  99.    complementing the "Universal/Local" (U/L) bit, which is the next-
  100.    to-lowest order bit of the first octet of the EUI-64.
  101.  
  102.    When a node has no EUI-64 available for forming its ARCnet Interface
  103.    Identifer, it MUST form that identifier as specified in [AARCH],
  104.    Appendix A, section "Links with Non-Global Identifier".  That is, the
  105.    8 bit manually configured ARCnet address is appended to the 56 zero
  106.    bits.
  107.  
  108.    For example, for an ARCnet interface with the configured address of
  109.    49 hexadecimal this results in the following identifier:
  110.  
  111.  
  112.  
  113.  
  114. Souvatzis                   Standards Track                     [Page 2]
  115.  
  116. RFC 2497                IPv6 Datagrams on ARCnet            January 1999
  117.  
  118.  
  119.    |0              1|1              3|3              4|4              6|
  120.    |0              5|6              1|2              7|8              3|
  121.    +----------------+----------------+----------------+----------------+
  122.    |0000000000000000|0000000000000000|0000000000000000|0000000001001001|
  123.    +----------------+----------------+----------------+----------------+
  124.  
  125.    Note that this results in the universal/local bit set to "0" to
  126.    indicate local scope.
  127.  
  128.    An IPv6 address prefix used for stateless auto-configuration [ACONF]
  129.    of an ARCnet interface MUST have a length of 64 bits.
  130.  
  131. 5. Link-Local Addresses
  132.  
  133.    The IPv6 link-local address [AARCH] for an ARCnet interface is formed
  134.    by appending the Interface Identifier, as defined above, to the
  135.    prefix FE80::/64.
  136.  
  137.     10 bits            54 bits                  64 bits
  138.    +----------+-----------------------+----------------------------+
  139.    |1111111010|         (zeros)       |    Interface Identifier    |
  140.    +----------+-----------------------+----------------------------+
  141.  
  142. 6. Address Mapping -- Unicast
  143.  
  144.    The procedure for mapping IPv6 addresses into ARCnet link-layer
  145.    addresses is described in [DISC]. The Source/Target link layer
  146.    Address option has the following form when the link layer is ARCnet.
  147.  
  148.              0                   1
  149.              0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
  150.             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  151.             |     Type      |    Length     |
  152.             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  153.             |ARCnet address |               |
  154.             +---------------+              -+
  155.             |                               |
  156.             +-    5 octets of padding      -+
  157.             |                               |
  158.             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  159.  
  160.       Option fields:
  161.  
  162.       Type      1 for Source Link-layer address.
  163.                 2 for Target Link-layer address.
  164.       Length         1 (in units of 8 octets).
  165.  
  166.       ARCnet address The 8 bit ARCnet address, in canonical bit order.
  167.  
  168.  
  169.  
  170. Souvatzis                   Standards Track                     [Page 3]
  171.  
  172. RFC 2497                IPv6 Datagrams on ARCnet            January 1999
  173.  
  174.  
  175. 7. Address Mapping -- Multicast
  176.  
  177.    As ARCnet only provides 1 multicast address (00 hexadecimal), all
  178.    IPv6 multicast addresses MUST be mapped to this address.
  179.  
  180. 8. Security Considerations
  181.  
  182.    The method of derivation of Interface Identifiers from ARCnet
  183.    addresses is intended to preserve local uniqueness when possible.
  184.    However, there is no protection from duplication through accident or
  185.    forgery.
  186.  
  187. 9. Acknowledgements
  188.  
  189.    Big parts of the new version of this memo are either based on
  190.    [ETHIPV6] or on Matt Crawford's review of an earlier version.
  191.  
  192. 10. References
  193.  
  194.    [AARCH]   Hinden, R. and S. Deering, "IP Version 6 Addressing
  195.              Architecture", RFC 2373, July 1998.
  196.  
  197.    [ACONF]   Thomson, S. and T. Narten, "IPv6 Stateless Address
  198.              Autoconfiguration", RFC 2462, December 1998.
  199.  
  200.    [ARCIPV4] Provan, D., "Transmitting IP Traffic over ARCNET Networks",
  201.              RFC1201, Novell, Inc., February 1991.
  202.  
  203.    [DISC]    Narten, T., Nordmark, E. and W. Simpson, "Neighbor
  204.              Discovery for IP Version 6 (IPv6)", RFC 2461, December
  205.              1998.
  206.  
  207.    [ETHIPV6] Crawford, M., "Transmission of IPv6 Packets over Ethernet
  208.              Networks", RFC 2464, December 1998.
  209.  
  210.    [EUI64]   "64-Bit Global Identifier Format Tutorial", http://stan¡
  211.              dards.ieee.org/db/oui/tutorials/EUI64.html.
  212.  
  213.    [IPV6]    Deering, S. and R. Hinden, "Internet Protocol, Version 6
  214.              (IPv6) Specification", RFC 2460, December 1998.
  215.  
  216.    [KWORD]   Bradner, S., "Key words for use in RFCs to Indicate
  217.              Requirement Levels", BCP 14, RFC 2119, March 1997.
  218.  
  219.    [PHDS]    Novell, Inc., "ARCNET Packet Header Definition Standard",
  220.              Novell Part Number 100-00721-001, November 1989.
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Souvatzis                   Standards Track                     [Page 4]
  227.  
  228. RFC 2497                IPv6 Datagrams on ARCnet            January 1999
  229.  
  230.  
  231. 11. Author's Address
  232.  
  233.    Ignatios Souvatzis
  234.    The NetBSD Project
  235.    Stationenweg 29
  236.    D-53332 Bornheim
  237.    Germany
  238.  
  239.    Phone (work): +49 (228) 734316
  240.    EMail: is@netbsd.org
  241.  
  242.  
  243.  
  244.  
  245.  
  246.  
  247.  
  248.  
  249.  
  250.  
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Souvatzis                   Standards Track                     [Page 5]
  283.  
  284. RFC 2497                IPv6 Datagrams on ARCnet            January 1999
  285.  
  286.  
  287. 12.  Full Copyright Statement
  288.  
  289.    Copyright (C) The Internet Society (1999).  All Rights Reserved.
  290.  
  291.    This document and translations of it may be copied and furnished to
  292.    others, and derivative works that comment on or otherwise explain it
  293.    or assist in its implementation may be prepared, copied, published
  294.    and distributed, in whole or in part, without restriction of any
  295.    kind, provided that the above copyright notice and this paragraph are
  296.    included on all such copies and derivative works.  However, this
  297.    document itself may not be modified in any way, such as by removing
  298.    the copyright notice or references to the Internet Society or other
  299.    Internet organizations, except as needed for the purpose of
  300.    developing Internet standards in which case the procedures for
  301.    copyrights defined in the Internet Standards process must be
  302.    followed, or as required to translate it into languages other than
  303.    English.
  304.  
  305.    The limited permissions granted above are perpetual and will not be
  306.    revoked by the Internet Society or its successors or assigns.
  307.  
  308.    This document and the information contained herein is provided on an
  309.    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  310.    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
  311.    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
  312.    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  313.    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Souvatzis                   Standards Track                     [Page 6]
  339.  
  340.