RFC 6964
Operational Guidance for IPv6 Deployment in IPv4 Sites Using the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)
Operational Guidance for IPv6 Deployment in IPv4 Sites Using the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) 🎀✨
okay bestie, so this is RFC 6964 🦋 It's an Independent Submission written by F. Templin at Boeing Research & Technology, dated May 2013. It's labelled Informational (not a Standards Track thing), and its ISSN is 2070-1721 💅 The title block doesn't list anything it obsoletes or updates, so there's no drama there 🙈
Abstract ✨
okay so a lot of end-user sites on the internet are still mostly running on IPv4 inside 💜 They range from tiny home and office networks all the way up to giant corporate enterprise networks, but they all have one thing in common: IPv4 is doing a totally fine job routing and addressing things for most apps 🌸 BUT more and more IPv6-only services are popping up, so end-user devices in these sites are going to need at least basic IPv6 functionality, and fr, that's the whole point of this doc 🫶 It gives operational guidance for deploying IPv6 inside mostly-IPv4 sites using the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) 🔥
Status of This Memo ✨
this one's giving "not a standard" energy 💅 The document is not an Internet Standards Track specification. It's published just for info 🌈
It's a contribution to the RFC Series, separate from any other RFC stream. The RFC Editor picked to publish it at their discretion and makes no statement about how valuable it is for implementing or deploying 🧚 Documents the RFC Editor approves for publication are not a candidate for any level of Internet Standard, see Section 2 of RFC 5741 💖
If you want the current status, any errata, or a way to send feedback, go to http://www.rfc-editor.org/info/rfc6964 🔗
Copyright Notice 🌸
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved 💜
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication. Please read those carefully, bestie, because they describe your rights and restrictions for this document 🎀
Table of Contents 🗂️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Enabling IPv6 Services Using ISATAP . . . . . . . . . . . . . 4
3. SLAAC Services . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Advertising ISATAP Router Behavior . . . . . . . . . . . 5
3.2. ISATAP Host Behavior . . . . . . . . . . . . . . . . . . 6
3.3. Reference Operational Scenario - Shared Prefix Model . . 6
3.4. Reference Operational Scenario - Individual Prefix Model 9
3.5. SLAAC Site Administration Guidance . . . . . . . . . . . 12
3.6. Loop Avoidance . . . . . . . . . . . . . . . . . . . . . 14
3.7. Considerations for Compatibility of Interface Identifiers 14
4. Manual Configuration . . . . . . . . . . . . . . . . . . . . 15
5. Scaling Considerations . . . . . . . . . . . . . . . . . . . 15
6. Site Renumbering Considerations . . . . . . . . . . . . . . . 16
7. Path MTU Considerations . . . . . . . . . . . . . . . . . . . 16
8. Alternative Approaches . . . . . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . 181. Introduction 🦋
okay so end-user sites today run IPv4 internally for the core stuff: web browsing, file sharing, network printing, email, teleconferencing, and a bunch of other site-internal services 💅 These sites usually have loads of public and/or private IPv4 addresses, and they're walled off from the public internet by firewalls, packet filtering gateways, proxies, address translators, and other site-border demarcation devices 🧱 Honestly, these sites haven't had much reason to turn on IPv6 internally [RFC1687] 🙈
The sites running IPv4 internally come in literally endless sizes and vibes ✨ For example, a home network behind a Network Address Translator (NAT) might be a single link with a few laptops, printers, etc. 💻 A small business might be one or a few offices with several networks connecting way more computers, routers, handheld devices, printers, faxes, etc. 🖨️ Going up the scale, big financial institutions, major retailers, large corporations, etc. might have hundreds or thousands of branches worldwide tied together in a complex global enterprise network 🌍 There are also personal-area networks, mobile vehicular networks, disaster relief networks, tactical military networks, various forms of Mobile Ad Hoc Networks (MANETs), etc. 🛰️
With IPv6 services spreading, existing IPv4 sites are going to need a way to turn on IPv6 services so hosts inside the site can talk to IPv6-only correspondents 🫶 This has to be deployable with minimal configuration, and it can't cause disruptions to existing IPv4 services 🥺 ISATAP [RFC5214] is a simple-to-use service that sites can deploy in the near term to meet these needs 💖
ISATAP has also come up a lot for IPv6 deployment in enterprise networks [RFC4057] [RFC4852] [ENT-IPv6] 👑 So ISATAP can be considered as an IPv6 solution alternative based on candidate enterprise network characteristics 🌈
This document gives operational guidance for using ISATAP to turn on IPv6 services inside mostly-IPv4 sites, without causing any disruptions to existing IPv4 services ✨ The terminology of ISATAP (see [RFC5214], Section 3) applies to this document too 📜
2. Enabling IPv6 Services Using ISATAP 🔥
existing sites on the internet are going to need IPv6 services soon 💅 Bigger sites usually get provider-independent IPv6 prefixes from an Internet registry and advertise those prefixes into the IPv6 routing system on their own behalf. In other words, they act as an Internet Service Provider (ISP) unto themselves 👑 Smaller sites that want IPv6 can get public IPv6 prefixes from an ISP, and those prefixes might be purely native, or the near-native prefixes offered by the IPv6 Rapid Deployment on IPv4 (6rd) [RFC5969] 🦋 Or the site can get prefixes independently of an ISP, e.g., via a tunnel broker [RFC3053], by using one of its public IPv4 addresses to form a 6to4 prefix [RFC3056], etc. 🌸 Either way, once the site has IPv6 prefixes, it can automatically turn on IPv6 services internally by configuring ISATAP 🎀
The ISATAP service uses a Non-Broadcast, Multiple Access (NBMA) tunnel virtual interface model [RFC2491] [RFC2529], based on IPv6-in-IPv4 encapsulation [RFC4213] 🧚 The encapsulation format can also use Differentiated Services (DS) [RFC2983] and Explicit Congestion Notification (ECN) [RFC3168] mapping between the inner and outer IP headers, so you get the expected per-hop behavior within well-managed sites 💜
The ISATAP service is built on two node types: advertising ISATAP routers and ISATAP hosts 💖 (A third node type, non-advertising ISATAP routers, is defined in [ISATAP-UPDATE]. It's out of scope for this document, though 🙈) Each node can have multiple ISATAP interfaces (one interface for each site), and it can act as an advertising ISATAP router on some of those interfaces and a simple ISATAP host on others 🫶 So the node type is considered on a per-interface basis 🌈
Advertising ISATAP routers configure their ISATAP interfaces as advertising router interfaces (see [RFC4861], Section 6.2.2) ✨ ISATAP hosts configure their ISATAP interfaces as simple host interfaces, and they also coordinate their autoconfiguration operations with advertising ISATAP routers 🎀 So in this model, advertising ISATAP routers are "servers" and ISATAP hosts are "clients" 💅
Advertising ISATAP routers add their IPv4 addresses to the site's Potential Router List (PRL) so ISATAP clients can find them, as discussed in Sections 8.3.2 and 9 of [RFC5214] 📜 Or, site administrators can include IPv4 anycast addresses in the PRL and assign each one to multiple advertising ISATAP routers 🛰️ In that case, IPv4 routing inside the site sends the ISATAP client to the nearest advertising ISATAP router 🦋
Once the PRL is published, ISATAP clients inside the site can automatically do unicast IPv6 Neighbor Discovery Router Solicitation (RS) / Router Advertisement (RA) exchanges with advertising ISATAP routers, using IPv6-in-IPv4 encapsulation [RFC4861] [RFC5214] 🔥 In that exchange, the IPv4 source address of the RS and the destination address of the RA are an IPv4 address of the client. Meanwhile, the IPv4 destination address of the RS and the source address of the RA are an IPv4 address of a server found in the PRL 🌸 Similarly, the IPv6 source address of the RS is a link-local ISATAP address that embeds the client's IPv4 address, and the source address of the RA is a link-local ISATAP address that embeds the server's IPv4 address 💜 (The destination addresses of the RS and RA may be either the neighbor's link-local ISATAP address or a link-scoped multicast address, depending on the implementation 🙈)
After router discovery, ISATAP clients can configure and assign IPv6 addresses and/or prefixes using Stateless Address AutoConfiguration (SLAAC) [RFC4862] [RFC5214] ✨ Using the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315] is also possible, but it's out of scope for this document and pending future updates (see [ISATAP-UPDATE]) 🧚
3. SLAAC Services 💜
predominantly IPv4 sites can enable SLAAC services for ISATAP clients that need to talk to IPv6 correspondents 🫶 SLAAC services are enabled using either the "shared" or "individual" prefix model 🎀 In the shared prefix model, all advertising ISATAP routers advertise a common prefix (e.g., 2001:db8::/64) to ISATAP clients inside the site 🌸 In the individual prefix model, advertising ISATAP routers advertise individual prefixes (e.g., 2001:db8:0:1::/64, 2001:db8:0:2::/64, 2001:db8:0:3::/64, etc.) to ISATAP clients inside the site 🦋 Note that you can also mix the two: some of the site's ISATAP routers advertise shared prefixes and others advertise individual prefixes 💖
The following sections discuss operational considerations for enabling ISATAP SLAAC services inside predominantly IPv4 sites 📜
3.1. Advertising ISATAP Router Behavior 👑
advertising ISATAP routers that support SLAAC services send RA messages in response to RS messages received on an advertising ISATAP interface 🔥 SLAAC services are enabled when advertising ISATAP routers advertise non-link-local IPv6 prefixes in the Prefix Information Options (PIOs) with the A flag set to 1 [RFC4861] ✨ When there are multiple advertising ISATAP routers, the routers can advertise a shared IPv6 prefix or individual IPv6 prefixes 💅
3.2. ISATAP Host Behavior ✨
okay bestie, so ISATAP hosts resolve the PRL and then send RS messages to get RA messages from an advertising ISATAP router 💌. When the RA messages show up, the host uses SLAAC to configure IPv6 addresses from any advertised prefixes with the A flag set to 1, as specified in [RFC4862] and [RFC5214], and then it assigns those addresses to the ISATAP interface 🎀. The host also assigns any advertised prefixes with the L flag set to 1 to the ISATAP interface 🫶. (ngl, the IPv6 link-local prefix fe80::/64 is always considered on-link on an ISATAP interface, so it's always in the mix no cap 🧚)
3.3. Reference Operational Scenario - Shared Prefix Model 🦋
okay so Figure 1 shows an example ISATAP network topology for letting hosts inside a mostly-IPv4 site set up ISATAP services with SLAAC using the shared prefix model 💖. The example has two advertising ISATAP routers ('A', 'B'), two ISATAP hosts ('C', 'D'), and an ordinary IPv6 host ('E') sitting outside the site in a typical deployment configuration 💅. In this model, routers 'A' and 'B' both advertise the same (shared) IPv6 prefix 2001:db8::/64 into the IPv6 routing system, and they also put that prefix in the RA messages they send to ISATAP clients 🌸.
.-(::::::::) 2001:db8:1::1
.-(::: IPv6 :::)-. +-------------+
(:::: Internet ::::) | IPv6 Host E |
`-(::::::::::::)-' +-------------+
`-(::::::)-'
,~~~~~~~~~~~~~~~~~,
,----|companion gateway|--.
/ '~~~~~~~~~~~~~~~~~' :
/ |.
,-' `.
; +------------+ +------------+ )
: | Router A | | Router B | /
: | (isatap) | | (isatap) | :
: | 192.0.2.1 | | 192.0.2.1 | ;
+ +------------+ +------------+ \
fe80::*:192.0.2.1 fe80::*:192.0.2.1
| 2001:db8::/64 2001:db8::/64 |
| ;
: IPv4 Site -+-'
`-. (PRL: 192.0.2.1) .)
\ _)
`-----+--------)----+'----'
fe80::*:192.0.2.18 fe80::*:192.0.2.34
2001:db8::*:192.0.2.18 2001:db8::*:192.0.2.34
+--------------+ +--------------+
| 192.0.2.18 | | 192.0.2.34 |
| (isatap) | | (isatap) |
| Host C | | Host D |
+--------------+ +--------------+(* == "0000:5efe", i.e., the organizational unique code for ISATAP, per Section 6.1 of [RFC5214])
Figure 1: Example ISATAP Network Topology Using Shared Prefix Model
With reference to Figure 1, advertising ISATAP routers 'A' and 'B' inside the IPv4 site connect to the IPv6 Internet either directly or via a companion gateway 🛣️. The routers advertise the shared prefix 2001:db8::/64 into the IPv6 Internet routing system either as a singleton /64 or as part of a shorter aggregated IPv6 prefix 🌈. For the purpose of this example, we also assume that the IPv4 site is configured within multiple IPv4 subnets -- each with an IPv4 prefix length of /28 🍓.
Advertising ISATAP routers 'A' and 'B' both configure the IPv4 anycast address 192.0.2.1 on a site-interior IPv4 interface, then configure an advertising ISATAP router interface for the site with link-local ISATAP address fe80::5efe:192.0.2.1 👑. The site administrator then places the single IPv4 address 192.0.2.1 in the site's PRL. 'A' and 'B' then both advertise the anycast address/prefix into the site's IPv4 routing system so that ISATAP clients can locate the router that is topologically closest 🎯. (Note: advertising ISATAP routers can also use individual IPv4 unicast addresses instead of, or in addition to, a shared IPv4 anycast address. In that case, the PRL will contain multiple IPv4 addresses of advertising routers -- some of which may be anycast and others unicast.) 🙈
ISATAP host 'C' connects to the site via an IPv4 interface with address 192.0.2.18/28 and also configures an ISATAP host interface with link-local ISATAP address fe80::5efe:192.0.2.18 over the IPv4 interface 💜. 'C' next resolves the PRL and sends an RS message to the IPv4 address 192.0.2.1, where IPv4 routing will direct it to the closest of either 'A' or 'B' 🧭. Assuming 'A' is closest, 'C' receives an RA from 'A', then configures a default IPv6 route with next-hop address fe80::5efe:192.0.2.1 via the ISATAP interface and processes the IPv6 prefix 2001:db8::/64 advertised in the PIO 🔥. If the A flag is set in the PIO, 'C' uses SLAAC to automatically configure the IPv6 address 2001:db8::5efe:192.0.2.18 (i.e., an address with an ISATAP interface identifier) and assigns it to the ISATAP interface ✨. If the L flag is set, 'C' also assigns the prefix 2001:db8::/64 to the ISATAP interface, and the IPv6 address becomes a true ISATAP address 👑.
In the same fashion, ISATAP host 'D' configures its IPv4 interface with address 192.0.2.34/28 and configures its ISATAP interface with link-local ISATAP address fe80::5efe:192.0.2.34 🌸. 'D' next performs an RS/RA exchange that is serviced by 'B', then uses SLAAC to autoconfigure the address 2001:db8::5efe:192.0.2.34 and a default IPv6 route with next-hop address fe80::5efe:192.0.2.1 🦋. Finally, IPv6 host 'E' connects to an IPv6 network outside of the site. 'E' configures its IPv6 interface in a manner specific to its attached IPv6 link and autoconfigures the IPv6 address 2001:db8:1::1 🧚.
Following this autoconfiguration, when host 'C' inside the site has an IPv6 packet to send to host 'E' outside the site, it prepares the packet with source address 2001:db8::5efe:192.0.2.18 and destination address 2001:db8:1::1 💌. 'C' then uses IPv6-in-IPv4 encapsulation to forward the packet to the IPv4 address 192.0.2.1, which will be directed to 'A' based on IPv4 routing. 'A' in turn decapsulates the packet and forwards it into the public IPv6 Internet, where it will be conveyed to 'E' via normal IPv6 routing 🚀. In the same fashion, host 'D' uses IPv6-in-IPv4 encapsulation via its default router 'B' to send IPv6 packets to IPv6 Internet hosts such as 'E' 🫶.
When host 'E' outside the site sends IPv6 packets to ISATAP host 'C' inside the site, the IPv6 routing system may direct the packet to either 'A' or 'B' 🎀. If the site is not partitioned internally, the router that receives the packet can use ISATAP to statelessly forward the packet directly to 'C' ✨. If the site may be partitioned internally, however, the packet must first be forwarded to 'C's serving router based on IPv6 routing information 🥺. This implies that, in a partitioned site, the advertising ISATAP routers must connect within a full or partial mesh of IPv6 links, and they must either run a dynamic IPv6 routing protocol or configure static routes so that incoming IPv6 packets can be forwarded to the correct serving router 🏗️.
In this example, 'A' can configure the IPv6 route 2001:db8::5efe:192.0.2.32/124 with the IPv6 address of the next hop toward 'B' in the mesh network as the next hop, and 'B' can configure the IPv6 route 2001:db8::5efe:192.0.2.16/124 with the IPv6 address of the next hop toward 'A' as the next hop 🧩. (Notice that the /124 prefixes properly cover the /28 prefix of the IPv4 address that is embedded within the IPv6 address 👀.) In that case, when 'A' receives a packet from the IPv6 Internet with destination address 2001:db8::5efe:192.0.2.34, it first forwards the packet toward 'B' over an IPv6 mesh link. 'B' in turn uses ISATAP to forward the packet into the site, where IPv4 routing will direct it to 'D' 💅. In the same fashion, when 'B' receives a packet from the IPv6 Internet with destination address 2001:db8::5efe:192.0.2.18, it first forwards the packet toward 'A' over an IPv6 mesh link. 'A' then uses ISATAP to forward the packet into the site, where IPv4 routing will direct it to 'C' 🌈.
Finally, when host 'C' inside the site connects to host 'D' inside the site, it has the option of using the native IPv4 service or the ISATAP IPv6-in-IPv4 encapsulation service 🍓. When there is operational assurance that IPv4 services between the two hosts are available, the hosts may be better served to continue to use legacy IPv4 services in order to avoid encapsulation overhead and to avoid communication failures due to middleboxes in the path that filter protocol-41 packets [RFC4213] 🙈. If 'C' and 'D' could be in different IPv4 network partitions, however, IPv6-in-IPv4 encapsulation should be used with one or both of routers 'A' and 'B' serving as intermediate gateways 🌟.
3.4. Reference Operational Scenario - Individual Prefix Model 🦋
Okay bestie, Figure 2 is giving us an example ISATAP network where hosts in a mostly-IPv4 site get IPv6 using SLAAC with the individual prefix model 💅. There are two advertising ISATAP routers, 'A' and 'B' ✨, two ISATAP hosts, 'C' and 'D' 🧚, and an ordinary IPv6 host, 'E', chilling outside the site in a typical deployment 🌸. Routers 'A' and 'B' each advertise a different prefix from the aggregated prefix 2001:db8::/48. 'A' takes 2001:db8:0:1::/64 and 'B' takes 2001:db8:0:2::/64 💖.
.-(::::::::) 2001:db8:1::1
.-(::: IPv6 :::)-. +-------------+
(:::: Internet ::::) | IPv6 Host E |
`-(::::::::::::)-' +-------------+
`-(::::::)-'
,~~~~~~~~~~~~~~~~~,
,----|companion gateway|--.
/ '~~~~~~~~~~~~~~~~~' :
/ |.
,-' `.
; +------------+ +------------+ )
: | Router A | | Router B | /
: | (isatap) | | (isatap) | :
: | 192.0.2.17 | | 192.0.2.33 | ;
+ +------------+ +------------+ \
fe80::*:192.0.2.17 fe80::*:192.0.2.33
2001:db8:0:1::/64 2001:db8:0:2::/64
| ;
: IPv4 Site -+-'
`-. (PRL: 192.0.2.1) .)
\ _)
`-----+--------)----+'----'
fe80::*:192.0.2.18 fe80::*:192.0.2.34
2001:db8:0:1::*:192.0.2.18 2001:db8:0:2::*:192.0.2.34
+--------------+ +--------------+
| 192.0.2.18 | | 192.0.2.34 |
| (isatap) | | (isatap) |
| Host C | | Host D |
+--------------+ +--------------+
(* == "0000:5efe")
Figure 2: Example ISATAP Network Topology Using
Individual Prefix ModelSo with Figure 2 in mind, routers 'A' and 'B' sit inside the IPv4 site and hook up to the IPv6 Internet either directly or through a companion gateway 🌈. Router 'A' advertises the individual prefix 2001:db8:0:1::/64 into the IPv6 Internet routing system, and router 'B' advertises 2001:db8:0:2::/64 ⭐. The routers could instead both advertise a shorter shared prefix like 2001:db8::/48. But then they'd need to set up a mesh of IPv6 links between themselves, the same way we described for the shared prefix model in Section 3.3 🔗. For this example, we also assume the IPv4 site is split into multiple IPv4 subnets, each with an IPv4 prefix length of /28 🍓.
Routers 'A' and 'B' each configure their own individual IPv4 unicast addresses, 192.0.2.17/28 and 192.0.2.33/28 (respectively) 🎀. These can be used instead of, or in addition to, a shared IPv4 anycast address. Router 'A' then sets up an advertising ISATAP router interface for the site with the link-local ISATAP address fe80::5efe:192.0.2.17, and router 'B' does the same with fe80::5efe:192.0.2.33 💅. After that, the site administrator puts 192.0.2.17 and 192.0.2.33 into the site's PRL, and both 'A' and 'B' advertise their IPv4 addresses into the site's IPv4 routing system 👑.
ISATAP host 'C' connects to the site over an IPv4 interface with address 192.0.2.18/28. It also configures an ISATAP host interface with the link-local ISATAP address fe80::5efe:192.0.2.18 over that IPv4 interface 🫶. Next, 'C' resolves the PRL and sends an RS message to the IPv4 address 192.0.2.17, and IPv4 routing will steer it straight to 'A' 🧚. Then 'C' gets an RA from 'A' and configures a default IPv6 route with next-hop address fe80::5efe:192.0.2.17 over the ISATAP interface. It also processes the IPv6 prefix 2001:db8:0:1:/64 advertised in the PIO 💖. If the A flag is set in the PIO, 'C' uses SLAAC to automatically configure the IPv6 address 2001:db8:0:1::5efe:192.0.2.18 (an address with an ISATAP interface identifier) and assigns it to the ISATAP interface 🦋. If the L flag is set too, 'C' also assigns the prefix 2001:db8:0:1::/64 to the ISATAP interface, and that IPv6 address becomes a true ISATAP address 🔥.
ISATAP host 'D' does the same thing in its own way. It configures its IPv4 interface with address 192.0.2.34/28 and its ISATAP interface with link-local ISATAP address fe80::5efe:192.0.2.34 🌸. Then 'D' runs an RS/RA exchange that's handled by 'B', and uses SLAAC to autoconfigure the address 2001:db8:0:2::5efe:192.0.2.34 plus a default IPv6 route with next-hop address fe80::5efe:192.0.2.33 🎀. Last but not least, IPv6 host 'E' connects to an IPv6 network outside the site. 'E' configures its IPv6 interface in whatever way is specific to its attached IPv6 link, and it autoconfigures the IPv6 address 2001:db8:1::1 🌈.
Once that's all set up, when host 'C' inside the site has an IPv6 packet for host 'E' outside the site, it builds the packet with source address 2001:db8::5efe:192.0.2.18 and destination address 2001:db8:1::1 ✨. Then 'C' uses IPv6-in-IPv4 encapsulation to forward the packet to IPv4 address 192.0.2.17, which IPv4 routing sends to 'A' 🧚. 'A' decapsulates the packet and forwards it into the public IPv6 Internet, where normal IPv6 routing gets it to 'E' 💅. Host 'D' follows the same pattern, using IPv6-in-IPv4 encapsulation through its default router 'B' to send IPv6 packets to Internet hosts like 'E' 🫶.
Now the reverse direction. When host 'E' outside the site sends IPv6 packets to ISATAP host 'C' inside the site, the IPv6 routing system sends the packet to 'A', since 'A' advertises the individual prefix that matches 'C's destination address 🦋. Then 'A' can use ISATAP to statelessly forward the packet directly to 'C' ⭐. But if 'A' and 'B' both advertise the shared shorter prefix 2001:db8::/48 into the IPv6 routing system, packets coming from 'E' might get directed to either one 😭. In that case, the advertising ISATAP routers have to connect within a full or partial mesh of IPv6 links, just like in the shared prefix model. They also have to either run a dynamic IPv6 routing protocol or configure static routes so incoming IPv6 packets can be forwarded to the correct serving router 🔗.
Here's how that works in this example. 'A' can configure the IPv6 route 2001:db8:0:2::/64 with the IPv6 address of the next hop toward 'B' in the mesh network as its next hop. 'B' can configure the IPv6 route 2001:db8:0.1::/64 with the IPv6 address of the next hop toward 'A' as its next hop 💜. So when 'A' gets a packet from the IPv6 Internet with destination address 2001:db8:0:2::5efe:192.0.2.34, it first forwards the packet toward 'B' over an IPv6 mesh link. Then 'B' uses ISATAP to forward the packet into the site, where IPv4 routing directs it to 'D' 🧚. The same idea works the other way around: when 'B' gets a packet from the IPv6 Internet with destination address 2001:db8:0:1::5efe:192.0.2.18, it first forwards it toward 'A' over an IPv6 mesh link. 'A' then uses ISATAP to forward the packet into the site, where IPv4 routing sends it to 'C' 👑.
Last thing, and it's a big one 👀. When host 'C' inside the site connects to host 'D' inside the site, it can choose between the native IPv4 service and the ISATAP IPv6-in-IPv4 encapsulation service 💖. If you're sure IPv4 services between the two hosts are available, the hosts may be better off sticking with legacy IPv4 services 🍓. That avoids the encapsulation overhead and any IPv4 protocol-41 filtering middleboxes that might be sitting in the path 🙈. But if 'C' and 'D' might be in different IPv4 network partitions, IPv6-in-IPv4 encapsulation should be used, with one or both of routers 'A' and 'B' serving as intermediate gateways 🫶.
3.5. SLAAC Site Administration Guidance 🏠
okay so, in the real world, sites are full of firewalls, gateways, and packet filtering devices 🧱 that chop the network up into separate partitions. In both the shared and individual prefix models we just covered, the whole site can be represented by the aggregate IPv6 prefix assigned to the site ✨, and each partition gets its own "sliver" prefix carved out of that aggregate 🍰. To keep things simple and make sure the service doesn't clash with the site's topology, site administrators should institute an address plan that lines up the IPv6 sliver prefixes with the IPv4 partition boundaries 💅.
Here's what that looks like. In the shared prefix model from Section 3.3, the aggregate is 2001:db8::/64, and the slivers are 2001:db8::5efe:192.0.2.0/124, 2001:db8::5efe:192.0.2.16/124, 2001:db8::5efe:192.0.2.32/124, and so on 🦋. In the individual prefix model from Section 3.4, the aggregate is 2001:db8::/48, and the slivers are 2001:db8:0:0::/64, 2001:db8:0:1::/64, 2001:db8:0:2::/64, and so on 🌸.
When you're using individual prefixes, site administrators can set up advertising ISATAP routers to hand out different individual prefixes to different groups of clients 🎀. A common way to do this is based on each client's IPv4 subnet prefix, so the IPv6 prefixes stay congruent with the IPv4 addressing plan 🗺️. (For example, administrators can configure each advertising ISATAP router to serve only certain groups of ISATAP clients, using inbound IPv6 Access Control List (ACL) entries that match the IPv4 subnet prefix embedded in the ISATAP interface identifier of the IPv6 source address 🔐.) When a shared prefix is in use instead, the site administrators configure the ISATAP routers to advertise that shared prefix to all clients 🌈.
Advertising ISATAP routers can advertise prefixes with the (A, L) flags set to (1,0) ⭐. This lets ISATAP clients use SLAAC to autoconfigure IPv6 addresses with ISATAP interface identifiers from those prefixes and assign them to their receiving ISATAP interface, but the clients won't assign the prefix itself to that interface 🙈. So in that case, the advertising router has to assign the sliver prefix for the site partition to its own advertising ISATAP interface. That way, the advertising router treats the addresses covered by the sliver prefix as true ISATAP addresses, but the ISATAP clients themselves don't 💖. This set-up enables a hub-and-spoke architecture 🧚, which in some cases can be boosted by route optimization based on receiving ICMPv6 Redirects 🚀.
Site administrators can also put address selection policy rules [RFC6724] into each ISATAP client through explicit configurations 🎯. The goal is to make clients prefer IPv4 destination addresses over destination addresses derived from one of the client's IPv6 sliver prefixes 💜. For example, administrators can configure each ISATAP client associated with a sliver prefix such as 2001:db8::5efe:192.0.2.64/124 to add that prefix to its address selection policy table with a lower precedence than the prefix ::ffff:0:0/96 ✨. Then IPv4 addresses are preferred over IPv6 addresses from within the same sliver 🫶. The prefix can be added to each ISATAP client either manually or through an automated service, such as a DHCP option [ADDR-SELECT] that the client discovers, e.g., using Stateless DHCPv6 [RFC3736] 🤖. With all of that in place, clients use IPv4 to reach correspondents inside the same IPv4 site partition, and use IPv6 to reach correspondents in other partitions and/or outside of the site 🌍.
It should be noted that sliver prefixes longer than /64 cannot be advertised for SLAAC purposes 🙅♀️. Also, sliver prefixes longer than /64 don't allow interface identifier rewriting by address translators 😬. These factors may favor the individual prefix model in some deployment scenarios, while the flexibility of the shared prefix model may be more desirable in others 🧩. Additionally, if the network is small, the shared prefix model works well 🍓. If the network is large, though, a better alternative may be to deploy separate ISATAP routers in each partition, with each one advertising its own individual prefix 👑.
Last but not least, site administrators should configure ISATAP routers to not send ICMPv6 Redirect messages that tell a source client about a better next hop toward the destination 🙃, unless there's strong assurance that the client and the next hop are within the same IPv4 site partition 🔒.
3.6. Loop Avoidance 🔁
In sites that provide IPv6 services through ISATAP with SLAAC, as described in this section, site administrators must take operational precautions to avoid routing loops. Routing loops are not a vibe! 💀
For example, each advertising ISATAP router should drop any incoming IPv6 packets that would be forwarded back to itself via another of the site's advertising routers 🗑️. Additionally, each advertising ISATAP router should drop any encapsulated packets received from another advertising router that would be forwarded back to that same advertising router 🙅. This matches the mitigation documented in Section 3.2.3 of [RFC6324], but other mitigations specified in that document can also be employed 🛠️.
Note that IPv6 packets with link-local ISATAP addresses are exempt from these checks 🫧. That's because they cannot be forwarded by an IPv6 router, and they may be necessary for router-to-router coordinations 🤝.
3.7. Considerations for Compatibility of Interface Identifiers 🧪
[RFC5214], Section 6.1 specifies how to set the "u" bit in the Modified EUI-64 interface identifier format that ISATAP uses 🔢. Implementations that comply with the specification set the "u" bit to 1 when the IPv4 address is known to be globally unique 🌟. Some legacy implementations, though, unconditionally set the "u" bit to 0 🕰️.
Implementations only interpret the ISATAP interface identifier within the link that the corresponding ISATAP prefix is assigned to 🔗. So the value of the "u" bit only gets interpreted within the context of an on-link prefix, and not within a global context 🌐. Implementers are responsible for making sure their products are interoperable 🫡, so implementations must make provisions for ensuring "u" bit compatibility for intra-link communications 💞.
Site administrators should set up ACL entries and other literal representations of ISATAP interface identifiers so that both values of the "u" bit are accepted ⚖️. For example, if the site administrator configures an ACL entry that matches the prefix fe80::0000:5efe:192.0.2.0/124, they should also configure a companion list entry that matches the prefix fe80::0200:5efe:192.0.2.0/124 🎀.
4. Manual Configuration ✍️
When no autoconfiguration services are available (e.g., if there are no advertising ISATAP routers present), site administrators can use manual configuration to assign IPv6 addresses with ISATAP interface identifiers to the ISATAP interfaces of clients 🧑💻. Otherwise, site administrators should avoid manual configurations that would in any way invalidate the assumptions of the autoconfiguration service 🙏. For example, manually configured addresses may not be automatically renumbered during a site-wide renumbering event, which could subsequently result in communication failures 💥.
5. Scaling Considerations 📈
Section 3 depicts ISATAP network topologies with only two advertising ISATAP routers within the site 👯. To support larger numbers of ISATAP clients (and/or multiple site partitions), the site can deploy more advertising ISATAP routers to support load balancing and generally shortest-path routing 🏎️.
Such an arrangement requires that the advertising ISATAP routers participate in an IPv6 routing protocol instance, so that IPv6 addresses/prefixes can be mapped to the correct ISATAP router 🗺️. The routing protocol instance can be configured as either a full-mesh topology involving all advertising ISATAP routers, or as a partial-mesh topology, with each advertising ISATAP router associating with one or more companion gateways 🕸️. Each such companion gateway would, in turn, participate in a full mesh between all companion gateways 🫂.
6. Site Renumbering Considerations 🔄
Advertising ISATAP routers distribute IPv6 prefixes to ISATAP clients within the site 📬. If the site later reconnects to a different ISP, though, the site must renumber to use addresses derived from the new IPv6 prefixes [RFC6879] 😮💨.
For IPv6 services provided by SLAAC, site renumbering after a change in an ISP-served IPv6 prefix is pretty simple 🎉. It's a straightforward renumbering of the IPv6 addresses and/or prefixes assigned to the ISATAP interfaces of clients within the site ✨. In some cases, filtering rules (e.g., in filtering tables at site-border firewalls) may also need renumbering, but this can be automated and limited to only one or a few administrative "touch points" 🤖.
To renumber the ISATAP interfaces of clients within the site using SLAAC, advertising ISATAP routers only need to schedule the services offered by the old ISP for deprecation, and begin advertising the IPv6 prefixes provided by the new ISP 📣. Lifetimes of ISATAP client interface addresses will eventually expire, and the host will renumber its interfaces with addresses derived from the new prefixes ⏳. ISATAP clients should also eventually remove any deprecated SLAAC prefixes from their address selection policy tables, but this action is not time-critical 🧹.
Finally, site renumbering after a change in an ISP-served IPv6 prefix also means locating and rewriting all IPv6 addresses in naming services, databases, configuration files, packet filtering rules, documentation, etc. 📚 If the site has published the IPv6 addresses of any site-internal nodes within the public Internet DNS system, the corresponding resource records will also need updating during the renumbering operation 🌐. This can be accomplished via secure dynamic updates to the DNS 🔐.
7. Path MTU Considerations 📦
IPv6-in-IPv4 encapsulation overhead effectively reduces the size of IPv6 packets that can traverse the tunnel, compared to the actual Maximum Transmission Unit (MTU) of the underlying IPv4 network path between the tunnel ingress and egress 📏. Two methods for accommodating IPv6 path MTU discovery over IPv6-in-IPv4 tunnels (i.e., the static and dynamic methods) are documented in Section 3.2 of [RFC4213] 🧐.
The static method places a "safe" upper bound on the size of IPv6 packets permitted to enter the tunnel 🧱. However, that method can be overly conservative when larger IPv4 path MTUs are available 🙄. The dynamic method can accommodate much larger IPv6 packet sizes in some cases, but it can fail silently if the underlying IPv4 network path doesn't return the necessary error messages 👻.
This document notes that sites that include well-managed IPv4 links, routers, and other network middleboxes are candidates for the dynamic MTU determination method 🏆. That may provide a better operational IPv6 experience in the presence of IPv6-in-IPv4 tunnels 💅.
Finally, since all ISATAP tunnels terminate at a host, transport protocols that perform packet-size negotiations will see an IPv6 MTU that accounts for the encapsulation headers 🎀. That means they'll avoid sending encapsulated packets that exceed the IPv4 path MTU 🫶.
8. Alternative Approaches ✨
okay so let's talk about the other options people look at 👀
[RFC4554] proposes using VLANs for IPv4-IPv6 coexistence in enterprise networks. ISATAP is the more flexible and broadly applicable choice, and it needs fewer administrative touch points 💅
The tunnel broker service [RFC3053] uses point-to-point tunnels. End users have to set up an explicit administrative configuration for the far end of the tunnel, and that far end may sit outside the site's administrative boundaries. A bit of a hassle, bestie 🙈
6to4 [RFC3056] and Teredo [RFC4380] are the "last resort" unmanaged automatic tunneling services. They're for when there's no other way to get IPv6 connectivity 🌸 Once the ISATAP managed service and/or native IPv6 services are turned on, these two get bumped to lower priority.
6rd [RFC5969] does stateless prefix delegation based on IPv4-embedded IPv6 prefixes. ISATAP, on the other hand, does stateful prefix delegation based on native IPv6 prefixes. Different vibes, same goal ✨
9. Security Considerations 🔐
okay this part is SERIOUS, so pay attention 😭
Along with the security considerations already written up in [RFC5214], sites that use ISATAP should take care to make sure that no routing loops are enabled [RFC6324]. Extra security concerns with IP tunneling are covered in [RFC6169]. Do not skip these 💀
10. Acknowledgments 🫶
big thank you to everyone who shared insights that helped shape this work 🎀 The following people are acknowledged: Dmitry Anipko, Fred Baker, Ron Bonica, Brian Carpenter, Remi Despres, Thomas Henderson, Philip Homburg, Lee Howard, Ray Hunter, Joel Jaeggli, John Mann, Gabi Nakibly, Christopher Palmer, Hemant Singh, Mark Smith, Ole Troan, and Gunter Van de Velde. Iconic squad 👑
11. References 📚
11.1. Normative References
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
March 2008.11.2. Informative References
[ADDR-SELECT]
Matsumoto, A., Fujisaki, T., and T. Chown, "Distributing
Address Selection Policy using DHCPv6", Work in Progress,
April 2013.
[ENT-IPv6] Chittimaneni, K., Chown, T., Howard, L., Kuarsingh, V.,
Pouffary, Y., and E. Vyncke, "Enterprise IPv6 Deployment
Guidelines", Work in Progress, February 2013.
[ISATAP-UPDATE]
Templin, F., "ISATAP Updates", Work in Progress, May 2012.
[RFC1687] Fleischman, E., "A Large Corporate User's View of IPng",
RFC 1687, August 1994.
[RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6
over Non-Broadcast Multiple Access (NBMA) networks", RFC
2491, January 1999.
[RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4
Domains without Explicit Tunnels", RFC 2529, March 1999.
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC
2983, October 2000.
[RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6
Tunnel Broker", RFC 3053, January 2001.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", RFC
3168, September 2001.
[RFC4057] Bound, J., "IPv6 Enterprise Network Scenarios", RFC 4057,
June 2005.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380, February
2006.
[RFC4554] Chown, T., "Use of VLANs for IPv4-IPv6 Coexistence in
Enterprise Networks", RFC 4554, June 2006.
[RFC4852] Bound, J., Pouffary, Y., Klynsma, S., Chown, T., and D.
Green, "IPv6 Enterprise Network Analysis - IP Layer 3
Focus", RFC 4852, April 2007.
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd) -- Protocol Specification", RFC
5969, August 2010.
[RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security
Concerns with IP Tunneling", RFC 6169, April 2011.
[RFC6324] Nakibly, G. and F. Templin, "Routing Loop Attack Using
IPv6 Automatic Tunnels: Problem Statement and Proposed
Mitigations", RFC 6324, August 2011.
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, September 2012.
[RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise
Network Renumbering Scenarios, Considerations, and
Methods", RFC 6879, February 2013.Author's Address 🖋️
Fred L. Templin
Boeing Research & Technology
P.O. Box 3707 MC 7L-49
Seattle, WA 98124
USA
EMail: fltemplin@acm.org📦 where this page comes from
- ietf: rfc6964 2013-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms