home *** CD-ROM | disk | FTP | other *** search
/ Internet Core Protocols / Oreilly-InternetCoreProtocols.iso / RFCs / rfc2529.txt < prev    next >
Encoding:
Text File  |  1999-10-14  |  21.1 KB  |  564 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                       B. Carpenter
  8. Request for Comments: 2529                                           IBM
  9. Category: Standards Track                                        C. Jung
  10.                                                                     3Com
  11.                                                               March 1999
  12.  
  13.  
  14.     Transmission of IPv6 over IPv4 Domains without Explicit Tunnels
  15.  
  16. Status of this Memo
  17.  
  18.    This document specifies an Internet standards track protocol for the
  19.    Internet community, and requests discussion and suggestions for
  20.    improvements.  Please refer to the current edition of the "Internet
  21.    Official Protocol Standards" (STD 1) for the standardization state
  22.    and status of this protocol.  Distribution of this memo is unlimited.
  23.  
  24. Copyright Notice
  25.  
  26.    Copyright (C) The Internet Society (1999).  All Rights Reserved.
  27.  
  28. Abstract
  29.  
  30.    This memo specifies the frame format for transmission of IPv6 [IPV6]
  31.    packets and the method of forming IPv6 link-local addresses over IPv4
  32.    domains.  It also specifies the content of the Source/Target Link-
  33.    layer Address option used in the Router Solicitation, Router
  34.    Advertisement, Neighbor Solicitation, and Neighbor Advertisement and
  35.    Redirect messages, when those messages are transmitted on an IPv4
  36.    multicast network.
  37.  
  38.    The motivation for this method is to allow isolated IPv6 hosts,
  39.    located on a physical link which has no directly connected IPv6
  40.    router, to become fully functional IPv6 hosts by using an IPv4 domain
  41.    that supports IPv4 multicast as their virtual local link. It uses
  42.    IPv4 multicast as a "virtual Ethernet".
  43.  
  44. Table of Contents
  45.  
  46.    1. Introduction....................................................2
  47.    2. Maximum Transmission Unit.......................................2
  48.    3. Frame Format....................................................3
  49.    4. Stateless Autoconfiguration and Link-Local Addresses............3
  50.    5. Address Mapping -- Unicast......................................4
  51.    6. Address Mapping -- Multicast....................................4
  52.    7. Scaling and Transition Isues....................................5
  53.    8. IANA Considerations.............................................6
  54.    9. Security Considerations.........................................6
  55.  
  56.  
  57.  
  58. Carpenter & Jung            Standards Track                     [Page 1]
  59.  
  60. RFC 2529         Transmission of IPv6 Packets over IPv4       March 1999
  61.  
  62.  
  63.    Acknowledgements...................................................7
  64.    References.........................................................7
  65.    APPENDIX A: IPv4 Multicast Addresses for Neighbor Discovery........8
  66.    Authors' Addresses.................................................9
  67.    Full Copyright Notice.............................................10
  68.  
  69. 1. Introduction
  70.  
  71.    This memo specifies the frame format for transmission of IPv6 [IPV6]
  72.    packets and the method of forming IPv6 link-local addresses over IPv4
  73.    multicast "domains".  For the purposes of this document, an IPv4
  74.    domain is a fully interconnected set of IPv4 subnets, within the same
  75.    local multicast scope, on which there are at least two IPv6 nodes
  76.    conforming to this specification.  This IPv4 domain could form part
  77.    of the globally-unique IPv4 address space, or could form part of a
  78.    private IPv4 network [RFC 1918].
  79.  
  80.    This memo also specifies the content of the Source/Target Link-layer
  81.    Address option used in the Router Solicitation, Router Advertisement,
  82.    Neighbor Solicitation, Neighbor Advertisement and Redirect messages
  83.    described in [DISC], when those messages are transmitted on an IPv4
  84.    multicast domain.
  85.  
  86.    The motivation for this method is to allow isolated IPv6 hosts,
  87.    located on a physical link which has no directly connected IPv6
  88.    router, to become fully functional IPv6 hosts by using an IPv4
  89.    multicast domain as their virtual local link.  Thus, at least one
  90.    IPv6 router using the same method must be connected to the same IPv4
  91.    domain if IPv6 routing to other links is required.
  92.  
  93.    IPv6 hosts connected using this method do not require IPv4-compatible
  94.    addresses or configured tunnels.  In this way IPv6 gains considerable
  95.    independence of the underlying links and can step over many hops of
  96.    IPv4 subnets. The mechanism is known formally as "IPv6 over IPv4" or
  97.    "6over4" and colloquially as "virtual Ethernet".
  98.  
  99.    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  100.    "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
  101.    document are to be interpreted as described in [RFC2119].
  102.  
  103. 2. Maximum Transmission Unit
  104.  
  105.    The default MTU size for IPv6 packets on an IPv4 domain is 1480
  106.    octets.  This size may be varied by a Router Advertisement [DISC]
  107.    containing an MTU option which specifies a different MTU, or by
  108.    manual configuration of each node.
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Carpenter & Jung            Standards Track                     [Page 2]
  115.  
  116. RFC 2529         Transmission of IPv6 Packets over IPv4       March 1999
  117.  
  118.  
  119.    Note that if by chance the IPv6 MTU size proves to be too large for
  120.    some intermediate IPv4 subnet, IPv4 fragmentation will ensue.  While
  121.    undesirable, this is not disastrous. However, the IPv4 "do not
  122.    fragment" bit MUST NOT be set in the encapsulating IPv4 header.
  123.  
  124. 3. Frame Format
  125.  
  126.    IPv6 packets are transmitted in IPv4 packets [RFC 791] with an IPv4
  127.    protocol type of 41, the same as has been assigned in [RFC 1933] for
  128.    IPv6 packets that are tunneled inside of IPv4 frames.  The IPv4
  129.    header contains the Destination and Source IPv4 addresses.  The IPv4
  130.    packet body contains the IPv6 header followed immediately by the
  131.    payload.
  132.  
  133.      0                   1                   2                   3
  134.      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  135.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  136.     |Version|  IHL  |Type of Service|          Total Length         |
  137.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  138.     |         Identification        |Flags|      Fragment Offset    |
  139.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  140.     |  Time to Live | Protocol 41   |         Header Checksum       |
  141.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  142.     |                       Source Address                          |
  143.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  144.     |                    Destination Address                        |
  145.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  146.     |                    Options                    |    Padding    |
  147.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  148.     |            IPv6 header and payload ...              /
  149.     +-------+-------+-------+-------+-------+------+------+
  150.  
  151.    If there are IPv4 options, then padding SHOULD be added to the IPv4
  152.    header such that the IPv6 header starts on a boundary that is a 32-
  153.    bit offset from the end of the datalink header.
  154.  
  155.    The Time to Live field SHOULD be set to a low value, to prevent such
  156.    packets accidentally leaking from the IPv4 domain.  This MUST be a
  157.    configurable parameter, with a recommended default of 8.
  158.  
  159. 4. Stateless Autoconfiguration and Link-Local Addresses
  160.  
  161.    The Interface Identifier [AARCH] of an IPv4 interface is the 32-bit
  162.    IPv4 address of that interface, with the octets in the same order in
  163.    which they would appear in the header of an IPv4 packet, padded at
  164.    the left with zeros to a total of 64 bits.  Note that the "Universal/
  165.    Local" bit is zero, indicating that the Interface Identifer is not
  166.    globally unique.  When the host has more than one IPv4 address in use
  167.  
  168.  
  169.  
  170. Carpenter & Jung            Standards Track                     [Page 3]
  171.  
  172. RFC 2529         Transmission of IPv6 Packets over IPv4       March 1999
  173.  
  174.  
  175.    on the physical interface concerned, an administrative choice of one
  176.    of these IPv4 addresses is made.
  177.  
  178.    An IPv6 address prefix used for stateless autoconfiguration [CONF] of
  179.    an IPv4 interface MUST have a length of 64 bits except for a special
  180.    case mentioned in Section 7.
  181.  
  182.    The IPv6 Link-local address [AARCH] for an IPv4 virtual interface is
  183.    formed by appending the Interface Identifier, as defined above, to
  184.    the prefix FE80::/64.
  185.  
  186.     +-------+-------+-------+-------+-------+-------+------+------+
  187.     |  FE      80      00      00      00      00      00     00  |
  188.     +-------+-------+-------+-------+-------+-------+------+------+
  189.     |  00      00   |  00   |  00   |   IPv4 Address              |
  190.     +-------+-------+-------+-------+-------+-------+------+------+
  191.  
  192. 5. Address Mapping -- Unicast
  193.  
  194.    The procedure for mapping IPv6 addresses into IPv4 virtual link-layer
  195.    addresses is described in [DISC].  The Source/Target Link-layer
  196.    Address option has the following form when the link layer is IPv4.
  197.    Since the length field is in units of 8 bytes, the value below is 1.
  198.  
  199.     +-------+-------+-------+-------+-------+-------+-------+-------+
  200.     | Type  |Length | must be zero  |        IPv4 Address           |
  201.     +-------+-------+-------+-------+-------+-------+-------+-------+
  202.  
  203.  
  204.    Type:
  205.     1 for Source Link-layer address.
  206.     2 for Target Link-layer address.
  207.  
  208.    Length:
  209.     1 (in units of 8 octets).
  210.  
  211.    IPv4 Address:
  212.  
  213.    The 32 bit IPv4 address, in network byte order.  This is the address
  214.    the interface currently responds to, and may be different from the
  215.    Interface Identifier for stateless autoconfiguration.
  216.  
  217. 6. Address Mapping -- Multicast
  218.  
  219.    IPv4 multicast MUST be available. An IPv6 packet with a multicast
  220.    destination address DST MUST be transmitted to the IPv4 multicast
  221.    address of Organization-Local Scope using the mapping below.  These
  222.    IPv4 multicast addresses SHOULD be taken from the block
  223.  
  224.  
  225.  
  226. Carpenter & Jung            Standards Track                     [Page 4]
  227.  
  228. RFC 2529         Transmission of IPv6 Packets over IPv4       March 1999
  229.  
  230.  
  231.    239.192.0.0/16, a sub-block of the Organization-Local Scope address
  232.    block, or, if all of those are not available, from the expansion
  233.    blocks defined in [ADMIN].  Note that when they are formed using the
  234.    expansion blocks, they use only a /16 sized block.
  235.  
  236.         +-------+-------+-------+-------+
  237.         |  239  |  OLS  | DST14 | DST15 |
  238.         +-------+-------+-------+-------+
  239.  
  240.         DST14, DST15        last two bytes of IPv6 multicast address.
  241.  
  242.         OLS                 from the configured Organization-Local
  243.                             Scope address block.  SHOULD be 192,
  244.                             see [ADMIN] for details.
  245.  
  246.    No new IANA registration procedures are required for the above.  See
  247.    appendix A. for a list of all the multicast groups that must be
  248.    joined to support Neighbor Discovery.
  249.  
  250. 7. Scaling and Transition Issues
  251.  
  252.    The multicast mechanism described in Section 6 above appears to have
  253.    essentially the same scaling properties as native IPv6 over most
  254.    media, except for the slight reduction in MTU size which will
  255.    slightly reduce bulk throughput.  On an ATM network, where IPv4
  256.    multicast relies on relatively complex mechanisms, it is to be
  257.    expected that IPv6 over IPv4 over ATM will perform less well than
  258.    native IPv6 over ATM.
  259.  
  260.    The "IPv6 over IPv4" mechanism is intended to take its place in the
  261.    range of options available for transition from IPv4 to IPv6.  In
  262.    particular it allows a site to run both IPv4 and IPv6 in coexistence,
  263.    without having to configure IPv6 hosts either with IPv4-compatible
  264.    addresses or with tunnels.  Interfaces of the IPv6 router and hosts
  265.    will of course need to be enabled in "6over4" mode.
  266.  
  267.    A site may choose to start its IPv6 transition by configuring one
  268.    IPv6 router to support "6over4" on an interface connected to the
  269.    site's IPv4 domain, and another IPv6 format on an interface connected
  270.    to the IPv6 Internet.  Any enabled "6over4" hosts in the IPv4 domain
  271.    will then be able to communicate both with the router and with the
  272.    IPv6 Internet, without manual configuration of a tunnel and without
  273.    the need for an IPv4-compatible IPv6 address, either stateless or
  274.    stateful address configuration providing the IPv6 address to the IPv6
  275.    host.
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Carpenter & Jung            Standards Track                     [Page 5]
  283.  
  284. RFC 2529         Transmission of IPv6 Packets over IPv4       March 1999
  285.  
  286.  
  287.    During transition, routers may need to advertise at least two IPv6
  288.    prefixes, one for the native LAN (e.g. Ethernet) and one for
  289.    "6over4".  As with any IPv6 prefix assigned to an IPv6 subnet, the
  290.    latter MUST be unique within its scope, whether site-local or global
  291.    addressing is used.
  292.  
  293.    Also note that when a router is handling both native LAN and "6over4"
  294.    on the same physical interface,  during stateless autoconfiguration,
  295.    there is a period when IPv6 link-local addresses are used, in both
  296.    cases with the prefix FE80::/64. Note that the prefix-length for
  297.    these link-local adddress MUST then be 128 so that the two cases can
  298.    be distinguished.
  299.  
  300.    As the site installs additional IPv6 routers, "6over4" hosts which
  301.    become physically adjacent to IPv6 routers can be changed to run as
  302.    native IPv6 hosts, with the the only impact on IPv6 applications
  303.    being a slight increase in MTU size. At some stage during transition,
  304.    it might be convenient to dual home hosts in both native LAN and
  305.    "6over4" mode, but this is not required.
  306.  
  307. 8. IANA Considerations
  308.  
  309.    No assignments by the IANA are required beyond those in [ADMIN].
  310.  
  311. 9. Security Considerations
  312.  
  313.    Implementors should be aware that, in addition to posssible attacks
  314.    against IPv6, security attacks against IPv4 must also be considered.
  315.    Use of IP security at both IPv4 and IPv6 levels should nevertheless
  316.    be avoided, for efficiency reasons.  For example, if IPv6 is running
  317.    encrypted, encryption of IPv4 would be redundant except if traffic
  318.    analysis is felt to be a threat.  If IPv6 is running authenticated,
  319.    then authentication of IPv4 will add little.  Conversely, IPv4
  320.    security will not protect IPv6 traffic once it leaves the IPv6-over-
  321.    IPv4 domain.  Therefore, implementing IPv6 security is required even
  322.    if IPv4 security is available.
  323.  
  324.    There is a possible spoofing attack in which spurious 6over4 packets
  325.    are injected into a 6over4 domain from outside. Thus, boundary
  326.    routers MUST discard multicast IPv4 packets with source or
  327.    destination multicast addresses of organisation local scope as
  328.    defined in section 6 above, if they arrive on physical interfaces
  329.    outside that scope. To defend against spurious unicast 6over4
  330.    packets, boundary routers MUST discard incoming IPv4 packets with
  331.    protocol type 41 from unknown sources, i.e.  IPv6-in-IPv4 tunnels
  332.    must only be accepted from trusted sources.  Unless IPSEC
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Carpenter & Jung            Standards Track                     [Page 6]
  339.  
  340. RFC 2529         Transmission of IPv6 Packets over IPv4       March 1999
  341.  
  342.  
  343.    authentication is available, the RECOMMENDED technique for this is to
  344.    configure the boundary router only to accept protocol type 41 packets
  345.    from source addresses within a trusted range or ranges.
  346.  
  347. Acknowledgements
  348.  
  349.    The basic idea presented above is not original, and we have had
  350.    invaluable comments from Matt Crawford, Steve Deering, Dan
  351.    Harrington, Rich Draves, Erik Nordmark, Quang Nguyen, Thomas Narten,
  352.    and other members of the IPNG and NGTRANS working groups.
  353.  
  354.    This document is seriously ripped off from RFC 1972 written by Matt
  355.    Crawford. Brian Carpenter was at CERN when the work was started.
  356.  
  357. References
  358.  
  359.    [AARCH]    Hinden, R., and S. Deering, "IP Version 6 Addressing
  360.               Architecture", RFC 2373, July 1998.
  361.  
  362.    [ADMIN]    Meyer, D., "Administratively Scoped IP Multicast", BCP 23,
  363.               RFC 2365, July 1998.
  364.  
  365.    [CONF]     Thomson, S. and T. Narten, "IPv6 Stateless Address
  366.               Autoconfiguration", RFC 2462, December 1998.
  367.  
  368.    [DISC]     Narten, T., Nordmark, E. and W. Simpson, "Neighbor
  369.               Discovery for IP Version 6 (IPv6)", RFC 2461, December
  370.               1998.
  371.  
  372.    [IPV6]     Deering, S. and R. Hinden, "Internet Protocol, Version 6
  373.               (IPv6) Specification", RFC 2460, December 1998.
  374.  
  375.    [RFC 791]  Postel, J., "Internet Protocol", STD 5, RFC 791, September
  376.               1981.
  377.  
  378.    [RFC 1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G.
  379.               and E. Lear, "Address Allocation for Private Internets",
  380.               RFC 1918, February 1996.
  381.  
  382.    [RFC 1933] Gilligan, R. and E. Nordmark, "Transition Mechanisms for
  383.               IPv6 Hosts and Routers", RFC 1933, April 1996.
  384.  
  385.    [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
  386.               Requirement Levels", BCP 14, RFC 2119, March 1997.
  387.  
  388.    [RFC 1972] Crawford, M., "A Method for the Transmission of IPv6
  389.               Packets over Ethernet Networks", RFC 1972, August 1996.
  390.  
  391.  
  392.  
  393.  
  394. Carpenter & Jung            Standards Track                     [Page 7]
  395.  
  396. RFC 2529         Transmission of IPv6 Packets over IPv4       March 1999
  397.  
  398.  
  399. APPENDIX A:  IPv4 Multicast Addresses for Neighbor Discovery
  400.  
  401.    The following IPv4 multicast groups are used to support Neighbor
  402.    Discovery with this specification. The IPv4 addresses listed in this
  403.    section were obtained by looking at the IPv6 multicast addresses that
  404.    Neigbour Discovery uses, and deriving the resulting IPv4 "virtual
  405.    link-layer" addresses that are generated from them using the
  406.    algorithm given in Section 6.
  407.  
  408.    all-nodes multicast address
  409.          - the administratively-scoped IPv4 multicast address used to
  410.            reach all nodes in the local IPv4 domain supporting this
  411.            specification.  239.OLS.0.1
  412.  
  413.    all-routers multicast address
  414.          - the administratively-scoped IPv4 multicast address to reach
  415.            all routers in the local IPv4 domain supporting this
  416.            specification.  239.OLS.0.2
  417.  
  418.    solicited-node multicast address
  419.          - an administratively scoped multicast address that is computed
  420.            as a function of the solicited target's address by taking the
  421.            low-order 24 bits of the IPv4 address used to form the IPv6
  422.            address, and prepending the prefix FF02:0:0:0:0:1:FF00::/104
  423.            [AARCH]. This is then mapped to the IPv4 multicast address by
  424.            the method described in this document. For example, if the
  425.            IPv4 address used to form the IPv6 address is W.X.Y.Z, then
  426.            the IPv6 solicited node multicast address is
  427.            FF02::1:255.X.Y.Z and the corresponding IPv4 multicast
  428.            address is 239.OLS.Y.Z
  429.  
  430.  
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Carpenter & Jung            Standards Track                     [Page 8]
  451.  
  452. RFC 2529         Transmission of IPv6 Packets over IPv4       March 1999
  453.  
  454.  
  455. Authors' Addresses
  456.  
  457.    Brian E. Carpenter
  458.    Internet Division
  459.    IBM United Kingdom Laboratories
  460.    MP 185, Hursley Park
  461.    Winchester, Hampshire S021 2JN, UK
  462.  
  463.    EMail: brian@hursley.ibm.com
  464.  
  465.  
  466.    Cyndi Jung
  467.    3Com Corporation
  468.    5400 Bayfront Plaza, Mailstop 3219
  469.    Santa Clara, California  95052-8145
  470.  
  471.    EMail: cmj@3Com.com
  472.  
  473.  
  474.  
  475.  
  476.  
  477.  
  478.  
  479.  
  480.  
  481.  
  482.  
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Carpenter & Jung            Standards Track                     [Page 9]
  507.  
  508. RFC 2529         Transmission of IPv6 Packets over IPv4       March 1999
  509.  
  510.  
  511. Full Copyright Statement
  512.  
  513.    Copyright (C) The Internet Society (1999).  All Rights Reserved.
  514.  
  515.    This document and translations of it may be copied and furnished to
  516.    others, and derivative works that comment on or otherwise explain it
  517.    or assist in its implementation may be prepared, copied, published
  518.    and distributed, in whole or in part, without restriction of any
  519.    kind, provided that the above copyright notice and this paragraph are
  520.    included on all such copies and derivative works.  However, this
  521.    document itself may not be modified in any way, such as by removing
  522.    the copyright notice or references to the Internet Society or other
  523.    Internet organizations, except as needed for the purpose of
  524.    developing Internet standards in which case the procedures for
  525.    copyrights defined in the Internet Standards process must be
  526.    followed, or as required to translate it into languages other than
  527.    English.
  528.  
  529.    The limited permissions granted above are perpetual and will not be
  530.    revoked by the Internet Society or its successors or assigns.
  531.  
  532.    This document and the information contained herein is provided on an
  533.    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  534.    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
  535.    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
  536.    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  537.    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
  538.  
  539.  
  540.  
  541.  
  542.  
  543.  
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Carpenter & Jung            Standards Track                    [Page 10]
  563.  
  564.