RFC 2529

Transmission of IPv6 over IPv4 Domains without Explicit Tunnels

📅 published March 1999, from ietf

RFC 2529: Transmission of IPv6 over IPv4 Domains without Explicit Tunnels 💖

okay bestie, the title block is giving standards track 👑. It's from the Network Working Group, dated March 1999, and written by B. Carpenter (IBM) and C. Jung (3Com). It's RFC 2529. The title block doesn't list anything this doc obsoletes or updates, so no drama there 🌸.

Status of This Memo ✨

ok so this is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶. For where it sits in the official standardization state, check the current edition of "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈.

Copyright (C) The Internet Society (1999). All Rights Reserved.

Abstract 🦋

this memo is about the frame format for sending IPv6 [IPV6] packets over IPv4 domains, plus how IPv6 link-local addresses get formed there 🧚. It also defines 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 go over an IPv4 multicast network 💜.

The whole point is letting isolated IPv6 hosts that sit on a link with no directly connected IPv6 router still become fully functional IPv6 hosts. They do it by using an IPv4 domain that supports IPv4 multicast as their virtual local link. Basically, IPv4 multicast acts as a "virtual Ethernet" 🍓.

Table of Contents 🎀

   1. Introduction....................................................2
   2. Maximum Transmission Unit.......................................2
   3. Frame Format....................................................3
   4. Stateless Autoconfiguration and Link-Local Addresses............3
   5. Address Mapping -- Unicast......................................4
   6. Address Mapping -- Multicast....................................4
   7. Scaling and Transition Isues....................................5
   8. IANA Considerations.............................................6
   9. Security Considerations.........................................6
   Acknowledgements...................................................7
   References.........................................................7
   APPENDIX A: IPv4 Multicast Addresses for Neighbor Discovery........8
   Authors' Addresses.................................................9
   Full Copyright Notice.............................................10

1. Introduction ✨

again, this memo is about the frame format for IPv6 [IPV6] packets and forming IPv6 link-local addresses, but this time over IPv4 multicast "domains" 🦋. For this doc, an IPv4 domain is a fully interconnected set of IPv4 subnets, within the same local multicast scope, with at least two IPv6 nodes that follow this spec 💖. That domain can be part of the globally-unique IPv4 address space, or part of a private IPv4 network [RFC 1918] 🌸.

This memo also defines the content of the Source/Target Link-layer Address option used in Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement, and Redirect messages described in [DISC], when those messages go over an IPv4 multicast domain 🧚.

The motivation is the same as before: isolated IPv6 hosts on a physical link with no directly connected IPv6 router can become fully functional IPv6 hosts by using an IPv4 multicast domain as their virtual local link 🍓. So if IPv6 routing to other links is needed, at least one IPv6 router using the same method must be connected to the same IPv4 domain 🫶.

IPv6 hosts using this method don't need IPv4-compatible addresses or configured tunnels, which is so iconic 👑. IPv6 gets real independence from the underlying links and can step over many hops of IPv4 subnets 🌈. The mechanism is formally called "IPv6 over IPv4" or "6over4", and colloquially "virtual Ethernet" 💅.

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 [RFC2119] 📚.

2. Maximum Transmission Unit 🎀

the default MTU size for IPv6 packets on an IPv4 domain is 1480 octets 💖. It can be changed by a Router Advertisement [DISC] that has an MTU option specifying a different MTU, or by manual configuration of each node 🦋.

⚠️ if the IPv6 MTU turns out to be too large for some intermediate IPv4 subnet, IPv4 fragmentation will kick in 😭. It's undesirable, but not disastrous. Still, the IPv4 "do not fragment" bit MUST NOT be set in the encapsulating IPv4 header 🙈.

3. Frame Format 🧚

IPv6 packets get carried in IPv4 packets [RFC 791] with an IPv4 protocol type of 41. That's the same number assigned in [RFC 1933] for IPv6 packets tunneled inside IPv4 frames 💜. The IPv4 header holds the Destination and Source IPv4 addresses. The IPv4 packet body holds the IPv6 header, followed right away by the payload ✨.

     0                   1                   2                   3
     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Version|  IHL  |Type of Service|          Total Length         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Identification        |Flags|      Fragment Offset    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Time to Live | Protocol 41   |         Header Checksum       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Source Address                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Destination Address                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Options                    |    Padding    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            IPv6 header and payload ...              /
    +-------+-------+-------+-------+-------+------+------+

if there are IPv4 options, then padding SHOULD be added to the IPv4 header so the IPv6 header starts on a boundary that's a 32-bit offset from the end of the datalink header 🫶.

the Time to Live field SHOULD be set to a low value, so these packets don't accidentally leak out of the IPv4 domain 🔥. This MUST be a configurable parameter, with a recommended default of 8 🍓.

the Interface Identifier [AARCH] of an IPv4 interface is the 32-bit IPv4 address of that interface 💖. The octets go in the same order they'd appear in an IPv4 packet header, left-padded with zeros to a total of 64 bits 🦋. Heads up: the "Universal/Local" bit is zero, which means the Interface Identifier is not globally unique 😭. If the host has more than one IPv4 address in use on that physical interface, an administrative choice of one of them gets made 🌸.

an IPv6 address prefix used for stateless autoconfiguration [CONF] of an IPv4 interface MUST have a length of 64 bits, except for a special case mentioned in Section 7 🧚.

the IPv6 Link-local address [AARCH] for an IPv4 virtual interface is formed by appending the Interface Identifier, as defined above, to the prefix FE80::/64 💜.

    +-------+-------+-------+-------+-------+-------+------+------+
    |  FE      80      00      00      00      00      00     00  |
    +-------+-------+-------+-------+-------+-------+------+------+
    |  00      00   |  00   |  00   |   IPv4 Address              |
    +-------+-------+-------+-------+-------+-------+------+------+

5. Address Mapping -- Unicast 🌈

the procedure for mapping IPv6 addresses into IPv4 virtual link-layer addresses is described in [DISC] ✨. When the link layer is IPv4, the Source/Target Link-layer Address option looks like this. The length field is in units of 8 bytes, so the value below is 1 🦋.

    +-------+-------+-------+-------+-------+-------+-------+-------+
    | Type  |Length | must be zero  |        IPv4 Address           |
    +-------+-------+-------+-------+-------+-------+-------+-------+

Type:

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

Length:

  • 1 (in units of 8 octets).

IPv4 Address:

this is the 32-bit IPv4 address, in network byte order 💅. It's the address the interface currently responds to, and it may be different from the Interface Identifier for stateless autoconfiguration 🫶.

6. Address Mapping -- Multicast 🧚

IPv4 multicast MUST be available 🔥. An IPv6 packet with a multicast destination address DST MUST be transmitted to the IPv4 multicast address of Organization-Local Scope, using the mapping below 💖. Those IPv4 multicast addresses SHOULD be taken from the block 239.192.0.0/16, which is a sub-block of the Organization-Local Scope address block. If all of those aren't available, they come from the expansion blocks defined in [ADMIN]. When they're formed from the expansion blocks, they only use a /16 sized block 🌸.

        +-------+-------+-------+-------+
        |  239  |  OLS  | DST14 | DST15 |
        +-------+-------+-------+-------+

        DST14, DST15        last two bytes of IPv6 multicast address.

        OLS                 from the configured Organization-Local
                            Scope address block.  SHOULD be 192,
                            see [ADMIN] for details.
  • DST14, DST15: the last two bytes of the IPv6 multicast address 🍓.
  • OLS: comes from the configured Organization-Local Scope address block. It SHOULD be 192, see [ADMIN] for details ✨.

No new IANA registration procedures are required for the above 🌈. See Appendix A for the list of all the multicast groups that must be joined to support Neighbor Discovery 👑.

Part 2 picks up with Section 7 🦋💖

7. Scaling and Transition Issues ✨

Okay so the multicast trick from Section 6 scales basically the same as native IPv6 over most media 🫶. The only catch is that the MTU gets a tiny bit smaller, which slightly dings bulk throughput 😭. On ATM, where IPv4 multicast uses pretty complicated machinery, you'd expect IPv6 over IPv4 over ATM to perform worse than native IPv6 over ATM 💀. Not a shocker tbh.

"IPv6 over IPv4" is meant to be one of the transition options 🦋. A site can run IPv4 and IPv6 side by side without giving IPv6 hosts IPv4-compatible addresses or setting up tunnels 💅. The IPv6 router and hosts just need to be enabled in "6over4" mode, obvi.

A site can start its IPv6 transition by having one IPv6 router run "6over4" on the interface facing its IPv4 domain, and another IPv6 format on the interface facing the IPv6 Internet 🌈. Then any enabled "6over4" hosts in the IPv4 domain can talk to the router and to the IPv6 Internet. No manual tunnel, no IPv4-compatible IPv6 address needed. Either stateless or stateful address configuration can hand the IPv6 address to the host ✨.

During transition, routers may need to advertise at least two IPv6 prefixes: one for the native LAN (like Ethernet) and one for "6over4" 🎀. Like any IPv6 prefix assigned to an IPv6 subnet, the "6over4" one MUST be unique within its scope, whether site-local or global addressing is used 🔥.

Heads up 👀: if a router is handling both the native LAN and "6over4" on the same physical interface, stateless autoconfiguration has a stretch where IPv6 link-local addresses are in use. In both cases the prefix is FE80::/64. So the prefix-length for these link-local addresses MUST be 128, so the two cases can be told apart 🙈.

As the site adds more IPv6 routers, "6over4" hosts that end up physically next to an IPv6 router can switch to running as native IPv6 hosts ✨. The only impact on IPv6 applications is a slight increase in MTU size. Partway through, it might be convenient to dual home hosts on both the native LAN and "6over4" mode, but that is not required 💜.

8. IANA Considerations 🌸

No assignments by the IANA are required beyond those in [ADMIN]. Easy peasy 🍓.

9. Security Considerations 🚨

Implementors, listen up 👑. You need to think about security attacks against IPv4 too, not just the ones against IPv6. Use of IP security at both the IPv4 and IPv6 levels should be avoided, though, for efficiency reasons 😤. For example, if IPv6 is running encrypted, encrypting IPv4 as well is redundant, unless traffic analysis is felt to be a threat. If IPv6 is running authenticated, then authenticating IPv4 adds little. Also, IPv4 security won't protect IPv6 traffic once it leaves the IPv6-over-IPv4 domain. So implementing IPv6 security is required even when IPv4 security is available 💀.

There is a possible spoofing attack where spurious 6over4 packets get injected into a 6over4 domain from outside 😱. So boundary routers MUST discard multicast IPv4 packets whose source or destination multicast addresses have organisation local scope (as defined in Section 6 above), if those packets arrive on physical interfaces outside that scope. To defend against spurious unicast 6over4 packets, boundary routers MUST discard incoming IPv4 packets with protocol type 41 from unknown sources. In other words, IPv6-in-IPv4 tunnels must only be accepted from trusted sources 🛡️. Unless IPSEC authentication is available, the RECOMMENDED technique for this is to configure the boundary router to accept protocol type 41 packets only from source addresses within a trusted range or ranges 🔐.

Acknowledgements 🫶

The basic idea presented above is not original, and we got invaluable comments from Matt Crawford, Steve Deering, Dan Harrington, Rich Draves, Erik Nordmark, Quang Nguyen, Thomas Narten, and other members of the IPNG and NGTRANS working groups 🙌.

This document is seriously ripped off from RFC 1972 written by Matt Crawford 😂. Brian Carpenter was at CERN when the work was started.

References 📚

[AARCH]    Hinden, R., and S. Deering, "IP Version 6 Addressing
           Architecture", RFC 2373, July 1998.

[ADMIN]    Meyer, D., "Administratively Scoped IP Multicast", BCP 23,
           RFC 2365, July 1998.

[CONF]     Thomson, S. and T. Narten, "IPv6 Stateless Address
           Autoconfiguration", RFC 2462, December 1998.

[DISC]     Narten, T., Nordmark, E. and W. Simpson, "Neighbor
           Discovery for IP Version 6 (IPv6)", RFC 2461, December
           1998.

[IPV6]     Deering, S. and R. Hinden, "Internet Protocol, Version 6
           (IPv6) Specification", RFC 2460, December 1998.

[RFC 791]  Postel, J., "Internet Protocol", STD 5, RFC 791, September
           1981.

[RFC 1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G.
           and E. Lear, "Address Allocation for Private Internets",
           RFC 1918, February 1996.

[RFC 1933] Gilligan, R. and E. Nordmark, "Transition Mechanisms for
           IPv6 Hosts and Routers", RFC 1933, April 1996.

[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC 1972] Crawford, M., "A Method for the Transmission of IPv6
           Packets over Ethernet Networks", RFC 1972, August 1996.

APPENDIX A: IPv4 Multicast Addresses for Neighbor Discovery 🧚

The following IPv4 multicast groups are used to support Neighbor Discovery with this specification. The IPv4 addresses listed in this section were worked out by looking at the IPv6 multicast addresses that Neighbor Discovery uses, then deriving the resulting IPv4 "virtual link-layer" addresses generated from them using the algorithm given in Section 6 💖.

  • all-nodes multicast address
    • the administratively-scoped IPv4 multicast address used to reach all nodes in the local IPv4 domain supporting this specification. 239.OLS.0.1
  • all-routers multicast address
    • the administratively-scoped IPv4 multicast address to reach all routers in the local IPv4 domain supporting this specification. 239.OLS.0.2
  • solicited-node multicast address
    • an administratively scoped multicast address computed as a function of the solicited target's address. You take the low-order 24 bits of the IPv4 address used to form the IPv6 address, and prepend the prefix FF02:0:0:0:0:1:FF00::/104 [AARCH]. This is then mapped to the IPv4 multicast address by the method described in this document. For example, if the IPv4 address used to form the IPv6 address is W.X.Y.Z, then the IPv6 solicited-node multicast address is FF02::1:255.X.Y.Z and the corresponding IPv4 multicast address is 239.OLS.Y.Z 🎀

Authors' Addresses 📮

Brian E. Carpenter
Internet Division
IBM United Kingdom Laboratories
MP 185, Hursley Park
Winchester, Hampshire S021 2JN, UK

EMail: brian@hursley.ibm.com


Cyndi Jung
3Com Corporation
5400 Bayfront Plaza, Mailstop 3219
Santa Clara, California  95052-8145

EMail: cmj@3Com.com

Copyright (C) The Internet Society (1999). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards, in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💅

📦 where this page comes from