idnits 2.17.1 draft-templin-v6ops-isops-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 09, 2011) is 4729 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1918' is defined on line 731, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) == Outdated reference: A later version (-12) exists of draft-templin-aero-00 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Templin 3 Internet-Draft Boeing Research & Technology 4 Intended status: Informational May 09, 2011 5 Expires: November 10, 2011 7 Operational Guidance for IPv6 Deployment in IPv4 Sites using ISATAP 8 draft-templin-v6ops-isops-01.txt 10 Abstract 12 Many end user sites in the Internet today still have predominantly 13 IPv4 internal infrastructures. These sites range in size from small 14 home/office networks to large corporate enterprise networks, but 15 share the commonality that IPv4 continues to provide satisfactory 16 internal routing and addressing services for most applications. As 17 more and more IPv6-only services are deployed in the Internet, 18 however, end user devices within such sites will increasingly require 19 at least basic IPv6 functionality for external access. It is also 20 expected that more and more IPv6-only devices will be deployed within 21 the site over time. This document therefore provides operational 22 guidance for deployment of IPv6 within predominantly IPv4 sites using 23 the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP). 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on November 10, 2011. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Enabling IPv6 Services using ISATAP . . . . . . . . . . . . . 3 61 3. SLAAC Services . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3.1. ISATAP Router Behavior . . . . . . . . . . . . . . . . . . 5 63 3.2. ISATAP Host Behavior . . . . . . . . . . . . . . . . . . . 5 64 3.3. Reference Operational Scenario . . . . . . . . . . . . . . 6 65 3.4. Loop Avoidance . . . . . . . . . . . . . . . . . . . . . . 8 66 4. DHCPv6 Services . . . . . . . . . . . . . . . . . . . . . . . 8 67 4.1. ISATAP Router Behavior . . . . . . . . . . . . . . . . . . 9 68 4.2. ISATAP Host Behavior . . . . . . . . . . . . . . . . . . . 10 69 4.3. Reference Operational Scenario . . . . . . . . . . . . . . 10 70 4.4. Loop Avoidance . . . . . . . . . . . . . . . . . . . . . . 13 71 5. Scaling Considerations . . . . . . . . . . . . . . . . . . . . 13 72 6. On-Demand Dynamic Routing . . . . . . . . . . . . . . . . . . 14 73 7. Site Partitioning Considerations . . . . . . . . . . . . . . . 14 74 8. Site Renumbering Considerations . . . . . . . . . . . . . . . 14 75 9. Path MTU Considerations . . . . . . . . . . . . . . . . . . . 15 76 10. Alternative Approaches . . . . . . . . . . . . . . . . . . . . 15 77 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 78 12. Security Considerations . . . . . . . . . . . . . . . . . . . 16 79 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 80 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 81 14.1. Normative References . . . . . . . . . . . . . . . . . . . 16 82 14.2. Informative References . . . . . . . . . . . . . . . . . . 17 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 85 1. Introduction 87 End user sites in the Internet today currently use IPv4 routing and 88 addressing internally for core operating functions such as web 89 browsing, filesharing, network printing, e-mail, teleconferencing and 90 numerous other site-internal networking services. Such sites 91 typically have an abundance of public or private IPv4 addresses for 92 internal networking, and are separated from the public Internet by 93 firewalls, packet filtering gateways, proxies, address translators 94 and other site border demarcation devices. To date, such sites have 95 had little incentive to enable IPv6 services internally [RFC1687]. 97 End-user sites that currently use IPv4 services internally come in 98 endless sizes and varieties. For example, a home network behind a 99 Network Address Translator (NAT) may consist of a single link 100 supporting a few laptops, printers etc. As a larger example, a small 101 business may consist of one or a few offices with several networks 102 connecting considerably larger numbers of computers, routers, 103 handheld devices, printers, faxes, etc. Moving further up the scale, 104 large banks, restaurants, major retailers, large corporations, etc. 105 may consist of hundreds or thousands of branches worldwide that are 106 tied together in a complex global enterprise network. Additional 107 examples include personal-area networks, mobile vehicular networks, 108 disaster relief networks, tactical military networks, and various 109 forms of Mobile Ad-hoc Networks (MANETs). These cases and more are 110 considered in RANGERS[RFC6139]. 112 With the proliferation of IPv6 devices in the public Internet, 113 however, existing IPv4 sites will increasingly require a means for 114 enabling IPv6 services so that hosts within the site can communicate 115 with IPv6-only correspondents. Such services must be deployable with 116 minimal configuration, and in a fashion that will not cause 117 disruptions to existing IPv4 services. The Intra-Site Automatic 118 Tunnel Addressing Protocol (ISATAP) [RFC5214] provides a simple-to- 119 use service that sites can deploy in the near term to meet these 120 requirements. This document therefore provides operational guidance 121 for using ISATAP to enable IPv6 services within predominantly IPv4 122 sites while causing no disruptions to existing IPv4 services. 124 2. Enabling IPv6 Services using ISATAP 126 Many existing sites within the Internet predominantly use IPv4-based 127 services for their internal networking needs, but there is a growing 128 requirement for enabling IPv6 services to support communications with 129 IPv6-only correspondents. Smaller sites that wish to enable IPv6 130 typically arrange to obtain public IPv6 prefixes from an Internet 131 Service Provider (ISP), where the prefixes may be either purely 132 native or the near-native prefixes offered by 6rd [RFC5969]. Larger 133 sites typically obtain provider independent IPv6 prefixes from an 134 Internet registry and advertise the prefixes into the IPv6 routing 135 system on their own behalf, i.e., they act as an ISP unto themselves. 136 In either case, after obtaining IPv6 prefixes the site can 137 automatically enable IPv6 services internally by configuring ISATAP. 139 The ISATAP service uses a Non-Broadcast, Multiple Access (NBMA) 140 tunnel virtual interface model [RFC2491][RFC2529] based on IPv6-in- 141 IPv4 encapsulation [RFC4213]. The encapsulation format can further 142 use Differentiated Service (DS) [RFC2983] and Explicit Congestion 143 Notification (ECN) [RFC3168] mapping between the inner and outer IP 144 headers to ensure expected per-hop behavior within well-managed 145 sites. 147 The ISATAP service is further based on three basic node types known 148 as advertising ISATAP routers, non-advertising ISATAP routers and 149 ISATAP hosts. Advertising ISATAP routers configure their site-facing 150 ISATAP interfaces as advertising router interfaces (see: [RFC4861], 151 Section 6.2.2). Non-advertising ISATAP routers configure their site- 152 facing ISATAP interfaces as non-advertising router interfaces and 153 obtain IPv6 addresses/prefixes via autoconfiguration exchanges with 154 advertising ISATAP routers. Finally, ISATAP hosts configure their 155 site-facing ISATAP interfaces as simple host interfaces and also 156 coordinate their autoconfiguration operations with advertising ISATAP 157 routers. In this sense, advertising ISATAP routers are "servers" 158 while non-advertising ISATAP routers and ISATAP hosts are "clients" 159 in the service model. 161 Advertising ISATAP routers arrange to add their IPv4 addresses to the 162 Potential Router List (PRL) within the site name service. The name 163 service could be either the DNS or some other site-internal name 164 resolution system, but the PRL should be published in such a way that 165 ISATAP clients can resolve the name "isatap.domainname" for the 166 "domainname" suffix associated with their attached link. For 167 example, if the domainname suffix associated with an ISATAP client's 168 attached link is "example.com", then the name of the PRL for that 169 link attachment point is "isatap.example.com". On the other hand, if 170 the site name service is operating without a domainname suffix, then 171 the name of the PRL is simply "isatap". 173 After the PRL is published, ISATAP clients within the site will 174 automatically perform a standard IPv6 Neighbor Discovery Router 175 Solicitation (RS) / Router Advertisement (RA) exchange [RFC4861] with 176 advertising ISATAP routers. The ISATAP client could further test the 177 delays to multiple advertising ISATAP routers and select the one with 178 a favorable delay. Moreover, one or more of the IPv4 addresses in 179 the PRL could in fact be anycast addresses, and could therefore be 180 assigned to the IPv4 interfaces of multiple advertising ISATAP 181 routers. In that case, IPv4 routing within the site would direct the 182 ISATAP client to the nearest advertising ISATAP router. 184 Following router discovery, ISATAP clients initiate Stateless Address 185 AutoConfiguration (SLAAC), the Dynamic Host Configuration Protocol 186 for IPv6 (DHCPv6) or both as directed by the received RAs. The 187 clients can then use SLAAC-provided IPv6 addresses for basic IPv6 188 services and DHCPv6-provided IPv6 addresses/prefixes for fully- 189 qualified IPv6 services. 191 3. SLAAC Services 193 Predominantly IPv4 sites can enable ISATAP SLAAC services for the 194 purpose of providing basic IPv6 services to IPv4 hosts that need to 195 communicate with IPv6-only correspondents. In order to provide a 196 simple service that does not interact poorly with existing site 197 topological arrangements, the site should not publish any ISATAP- 198 provided IPv6 addresses that were configured using SLAAC within the 199 site name service. Hence, ISATAP-provided SLAAC services are 200 typically used primary for client-side operation. The following 201 sections discuss operational considerations for enabling ISATAP SLAAC 202 services within predominantly IPv4 sites. 204 3.1. ISATAP Router Behavior 206 Advertising ISATAP routers that support SLAAC services send RA 207 messages in response to RS messages received on an advertising ISATAP 208 interface. SLAAC services are enabled when advertising ISATAP 209 routers advertise non-link-local IPv6 prefixes. When there are 210 multiple advertising ISATAP routers, the routers can advertise the 211 same IPv6 prefixes or a different set of IPv6 prefixes. For example, 212 a first router may advertise 2001:db8:1::/64, a second may advertise 213 2001:db8:2::/64, etc. 215 The routers can further be configured to advertise different prefixes 216 to different sets of hosts within the site (e.g., as identified by 217 the host's IPv4 prefix) for the purpose of site partitioning. To 218 discourage direct communications between ISATAP hosts using SLAAC- 219 provided addresses, advertising ISATAP routers can send RAs that 220 include Prefix Information Options (PIOs) with the (A, L) flags set 221 to (1,0) [RFC4861]. 223 3.2. ISATAP Host Behavior 225 ISATAP hosts resolve the PRL and send RS messages to obtain RA 226 messages from an advertising ISATAP router. ISATAP routers that 227 advertise prefixes for SLAAC purposes will typically advertise 228 prefixes in PIOs with the (A, L) flags set to (1,0). In that case, 229 the ISATAP host autoconfigures an address from the advertised IPv6 230 prefix and assigns the address to the ISATAP interface, but the host 231 does not assign an IPv6 prefix to the ISATAP interface. Therefore, 232 all IPv6 communications from the hosts will (initially) flow through 233 the advertising ISATAP router. This arrangement prevents 234 communication failure modes in which a pair of ISATAP hosts that use 235 SLAAC are separated by a packet filtering gateway that would prevent 236 direct communications via the tunneled IPv6 service. 238 3.3. Reference Operational Scenario 240 Figure 1 depicts a reference ISATAP network topology for allowing 241 hosts within a predominantly IPv4 site to configure IPv6 services 242 using ISATAP with SLAAC. The scenario shows two advertising ISATAP 243 routers ('A', 'B'), two ISATAP hosts ('C', 'D'), and an ordinary IPv6 244 host ('E') outside of the site in a typical deployment configuration: 245 .-(::::::::) 2001:db8:3::1 246 .-(::: IPv6 :::)-. +-------------+ 247 (:::: Internet ::::) | IPv6 Host E | 248 `-(::::::::::::)-' +-------------+ 249 `-(::::::)-' 250 +------------+ +------------+ 251 | Router A |---.---| Router B |. 252 ,| (isatap) | | (isatap) | `\ 253 / +------------+ +------------+ \ 254 : fe80::*:192.0.1.1 fe80::*:192.0.1.2 : 255 \ 2001:db8:1::/64 2001:db8:2::/64 / 256 : : 257 : : 258 +- IPv4 Site -+ 259 ; (PRL: 192.0.2.1, 192.0.2.2) : 260 | ; 261 : -+-' 262 `-. .) 263 \ _) 264 `-----+--------)----+'----' 265 fe80::*:192.0.2.3 fe80::*:192.0.2.4 266 2001:db8:1::*:192.0.2.3 2001:db8:2::*:192.0.2.4 267 +--------------+ +--------------+ 268 | (isatap) | | (isatap) | 269 | Host C | | Host D | 270 +--------------+ +--------------+ 272 (* == "5efe") 274 Figure 1: Reference ISATAP Network Topology using SLAAC 276 In Figure 1, advertising ISATAP routers 'A' and 'B' within the IPv4 277 site connect to the IPv6 Internet. (Note that the routers may 278 instead connect to the IPv6 Internet via a companion gateway as shown 279 in Figure 2.) Advertising ISATAP router 'A' configures a site- 280 interior IPv4 interface with address 192.0.2.1 and arranges to add 281 the address to the site's PRL. 'A' next configures an advertising 282 ISATAP router interface with link-local IPv6 address fe80::5efe: 283 192.0.2.1 over the IPv4 interface. In the same fashion, 'B' 284 configures the IPv4 interface address 192.0.2.2, adds the address to 285 the PRL, then configures its advertising ISATAP router interface with 286 link-local address fe80::5efe:192.0.2.2. 288 ISATAP host 'C' connects to the site via an IPv4 interface with 289 address 192.0.2.3, and also configures an ISATAP host interface with 290 link-local address fe80::5efe:192.0.2.3 over the IPv4 interface. 'C' 291 next resolves the PRL to discover the address 192.0.2.1 and performs 292 an RS/RA exchange with 'A'. Based on the RA information, 'C' next 293 configures a default IPv6 route with next-hop address fe80::5efe: 294 192.0.2.1 via the ISATAP interface and processes the IPv6 prefix 295 2001:db8:1::/64 advertised in the PIO. When 'C' processes the 296 prefix, it uses SLAAC to automatically configure the address 2001: 297 db8:1::5efe:192.0.2.3. 'C' then assigns the address to the ISATAP 298 interface, but does not assign the prefix itself to the interface if 299 the 'L' bit in the PIO is 0. 301 In the same fashion, ISATAP host 'D' configures its IPv4 interface 302 with address 192.0.2.4 and configures its ISATAP interface with link- 303 local address fe80::5efe:192.0.2.4. 'D' next performs an RS/RA 304 exchange with 'B', then uses SLAAC to autoconfigure the address 2001: 305 db8:2::5efe:192.0.2.4. 307 Finally, IPv6 host 'E' connects to an IPv6 network outside of the 308 site. 'E' configures its IPv6 interface in a manner specific to its 309 attached IPv6 link, and autoconfigures the IPv6 address 310 2001:db8:3::1. 312 Following this autoconfiguration, when host 'C' has an IPv6 packet to 313 send to host 'E', it prepares the packet with source address 2001: 314 db8::5efe:192.0.2.3 and destination address 2001:db8:3::1. 'C' then 315 uses IPv6-in-IPv4 encapsulation to forward the packet to router 'A', 316 which in turn decapsulates the packet and forwards it into the public 317 IPv6 Internet where it will be conveyed to 'E' via normal IPv6 318 routing. (Note that 'A' may "translate" the packet as it is 319 forwarded across the site boundary such that it appears to come from 320 a different source address than the one used by host 'C' within the 321 site.) In the same fashion, host 'D' uses IPv6-in-IPv4 encapsulation 322 via its default router 'B' to send IPv6 packets to IPv6 Internet 323 hosts such as 'E'. 325 When host 'C' has an IPv6 packet to send to host 'D' (i.e., another 326 ISATAP host within the site), it uses IPv6-in-IPv4 encapsulation to 327 forward the packet to advertising ISATAP router 'A'. 'A' in turn 328 conveys the packet to 'D' either directly or via 'B' as an 329 intermediary. However, it is not expected that hosts 'C' and 'D' 330 will normally use ISATAP services when communicating with each other 331 within the site. Instead, they will continue to use legacy IPv4 332 services until a fully-qualified IPv6 intra-site service becomes 333 available. 335 3.4. Loop Avoidance 337 In sites that provide IPv6 services through ISATAP with SLAAC as 338 described in this section, advertising ISATAP routers must take 339 operational precautions to avoid routing loops. For example, with 340 reference to Figure 1 an IPv6 packet that enters the site via 341 advertising ISATAP router 'A' must not be allowed to exit the site 342 via advertising ISATAP router 'B' based on an invalid SLAAC address. 344 As a simple mitigation, each advertising ISATAP router should drop 345 any packets coming from the IPv6 Internet that would be forwarded 346 back to the Internet via another advertising router. Additionally, 347 each advertising ISATAP router should drop any encapsulated packets 348 received from another advertising router that would be forwarded to 349 the IPv6 Internet. (Note that IPv6 packets with link-local addresses 350 are excluded from these checks, since they cannot be forwarded by an 351 IPv6 router and may be necessary for router-to-router coordinations.) 352 This corresponds to the mitigation documented in Section 3.2.3 of 353 [I-D.ietf-v6ops-tunnel-loops], but other mitigations such as the 354 tunnel endpoint verification checks listed in Section 3.1 of that 355 document can also be employed. 357 Again with reference to Figure 1, when 'A' receives a packet coming 358 from the IPv6 Internet with destination address 2001:db8:1::5efe: 359 192.0.2.2, it drops the packet since the IPv4 address 192.0.2.2 360 corresponds to advertising ISATAP router 'B'. Similarly, when 'B' 361 receives a packet coming from the tunnel with an IPv6 destination 362 address that would cause the packet to be forwarded back out to the 363 IPv6 Internet and with an IPv4 source address 192.0.2.1, it drops the 364 packet since 192.0.2.1 corresponds to advertising ISATAP router 'A'. 366 4. DHCPv6 Services 368 Whether or not advertising ISATAP routers make basic IPv6 services 369 available using SLAAC, they can also provide fully-qualified IPv6 370 services to ISATAP clients (i.e., both hosts and non-advertising 371 ISATAP routers) using the Dynamic Host Configuration Protocol for 372 IPv6 (DHCPv6). Any addresses/prefixes obtained via DHCPv6 are 373 distinct from any IPv6 prefixes assigned to the ISATAP interface for 374 SLAAC purposes, however. In this way, DHCPv6 addresses/prefixes are 375 reached by viewing the ISATAP tunnel interface as a "transit" rather 376 than viewing it as an ordinary IPv6 host interface. 378 ISATAP nodes employ the source address verification checks specified 379 in Section 7.3 of [RFC5214] as a prerequisite for decapsulation of 380 packets received on an ISATAP interface. In order to accommodate 381 direct communications with hosts and non-advertising ISATAP routers 382 that use DHCPv6, ISATAP nodes that support route optimization must 383 employ an additional source address verification check. Namely, the 384 node also considers the outer IPv4 source address correct for the 385 inner IPv6 source address if: 387 o a forwarding table entry exists that lists the packet's IPv4 388 source address as the link-layer address corresponding to the 389 inner IPv6 source address via the ISATAP interface. 391 The following sections discuss operational considerations for 392 enabling ISATAP DHCPv6 services within predominantly IPv4 sites. 394 4.1. ISATAP Router Behavior 396 Advertising ISATAP routers that support DHCPv6 services send RA 397 messages in response to RS messages received on an advertising ISATAP 398 interface. Advertising ISATAP routers also configure either a DHCPv6 399 relay or server function to service DHCPv6 requests received from 400 ISATAP clients. 402 In many use case scenarios (e.g., small enterprise networks, MANETs, 403 etc.), advertising and non-advertising ISATAP routers can engage in a 404 proactive dynamic IPv6 routing protocol (e.g., OSPFv3, RIPng, etc.) 405 over their ISATAP interfaces so that IPv6 routing/forwarding tables 406 can be populated and standard IPv6 forwarding between ISATAP routers 407 can be used. In other scenarios (e.g., large enterprise networks, 408 highly mobile MANETs, etc.), this might be impractical dues to 409 scaling issues. When a proactive dynamic routing protocol cannot be 410 used, non-advertising ISATAP routers send RS messages to obtain RA 411 messages from an advertising ISATAP router, i.e., they act as "hosts" 412 on their non-advertising ISATAP interfaces. 414 Non-advertising ISATAP routers can also acquire IPv6 prefixes, e.g., 415 through the use of DHCPv6 Prefix Delegation [RFC3633] via an 416 advertising router in the same fashion as described for host-based 417 DHCPv6 stateful address autoconfiguration in Section 4.2. The 418 advertising router in turn maintains IPv6 forwarding table entries 419 that list the IPv4 address of the non-advertising router as the link- 420 layer address of the next hop toward the delegated IPv6 prefixes. 422 After the non-advertising ISATAP router acquires IPv6 prefixes, it 423 can sub-delegate them to routers and links within its attached IPv6 424 edge networks, then can forward any outbound IPv6 packets coming from 425 its edge networks via other ISATAP nodes on the link. 427 4.2. ISATAP Host Behavior 429 ISATAP hosts resolve the PRL and send RS messages to obtain RA 430 messages from an advertising ISATAP router. Whether or not IPv6 431 prefixes for SLAAC are advertised, the host can acquire IPv6 432 addresses, e.g., through the use of DHCPv6 stateful address 433 autoconfiguration [RFC3315]. To acquire addresses, the host performs 434 standard DHCPv6 exchanges while mapping the IPv6 435 "All_DHCP_Relay_Agents_and_Servers" link-scoped multicast address to 436 the IPv4 address of an advertising ISATAP router. 438 After the host receives IPv6 addresses, it assigns them to its ISATAP 439 interface and forwards any of its outbound IPv6 packets via the 440 advertising router as a default router. The advertising router in 441 turn maintains IPv6 forwarding table entries that list the IPv4 442 address of the host as the link-layer address of the delegated IPv6 443 addresses. 445 4.3. Reference Operational Scenario 447 Figure 2 depicts a reference ISATAP network topology that uses 448 DHCPv6. The scenario shows two advertising ISATAP routers ('A', 449 'B'), two non-advertising ISATAP routers ('C', 'E'), an ISATAP host 450 ('G'), and three ordinary IPv6 hosts ('D', 'F', 'H') in a typical 451 deployment configuration: 453 .-(::::::::) 2001:db8:3::1 454 .-(::: IPv6 :::)-. +-------------+ 455 (:::: Internet ::::) | IPv6 Host H | 456 `-(::::::::::::)-' +-------------+ 457 `-(::::::)-' 458 ,~~~~~~~~~~~~~~~~~, 459 ,----|companion gateway|--. 460 / '~~~~~~~~~~~~~~~~~' : 461 / |. 462 ,-' `. 463 ; +------------+ +------------+ ) 464 : | Router A | | Router B | / fe80::*1:92.0.2.5 465 : | (isatap) | | (isatap) | ; 2001:db8:2::1 466 + +------------+ +------------+ \ +--------------+ 467 fe80::*:192.0.2.1 fe80::*:192.0.2.2 | (isatap) | 468 | ; | Host G | 469 : IPv4 Site -+-' +--------------+ 470 `-. (PRL: 192.0.2.1, 192.0.2.2) .) 471 \ _) 472 `-----+--------)----+'----' 473 fe80::*:192.0.2.3 fe80::*:192.0.2.4 .-. 474 +--------------+ +--------------+ ,-( _)-. 475 | (isatap) | | (isatap) | .-(_ IPv6 )-. 476 | Router C | | Router E |--(__Edge Network ) 477 +--------------+ +--------------+ `-(______)-' 478 2001:db8:0::/48 2001:db8:1::/48 | 479 | 2001:db8:1::1 480 .-. +-------------+ 481 ,-( _)-. 2001:db8::1 | IPv6 Host F | 482 .-(_ IPv6 )-. +-------------+ +-------------+ 483 (__Edge Network )--| IPv6 Host D | 484 `-(______)-' +-------------+ 486 (* == "5efe") 488 Figure 2: Reference ISATAP Network Topology using DHCPv6 490 In Figure 2, advertising ISATAP routers 'A' and 'B' within the IPv4 491 site connect to the IPv6 Internet via a companion gateway. (Note 492 that the routers may instead connect to the IPv6 Internet directly as 493 shown in Figure 1.) Advertising ISATAP router 'A' configures a 494 provider network IPv4 interface with address 192.0.2.1 and arranges 495 to add the address to the provider network PRL. 'A' next configures 496 an advertising ISATAP router interface with link-local IPv6 address 497 fe80::5efe:192.0.2.1 over the IPv4 interface. In the same fashion, 498 advertising ISATAP router 'B' configures the IPv4 interface address 499 192.0.2.2, adds the address to the PRL, then configures the IPv6 500 ISATAP interface link-local address fe80::5efe:192.0.2.2. 502 Non-advertising ISATAP router 'C' connects to one or more IPv6 edge 503 networks and also connects to the site via an IPv4 interface with 504 address 192.0.2.3, but it does not add the IPv4 address to the site's 505 PRL. 'C' next configures a non-advertising ISATAP router interface 506 with link-local address fe80::5efe:192.0.2.3, then receives the IPv6 507 prefix 2001:db8::/48 through a DHCPv6 prefix delegation exchange via 508 one of 'A' or 'B'. 'C' then engages in an IPv6 routing protocol over 509 its ISATAP interface and announces the delegated IPv6 prefix. 'C' 510 finally sub-delegates the prefix to its attached edge networks, where 511 IPv6 host 'D' autoconfigures the address 2001:db8::1. 513 Non-advertising ISATAP router 'E' connects to the site, configures 514 its ISATAP interface, receives a DHCPv6 prefix delegation, and 515 engages in the IPv6 routing protocol the same as for 'C'. In 516 particular, 'E' configures the IPv4 address 192.0.2.4, the ISATAP 517 link-local address fe80::5efe:192.0.2.4, and the delegated IPv6 518 prefix 2001:db8:1::/48. 'E' finally sub-delegates the prefix to its 519 attached edge networks, where IPv6 host 'F' autoconfigures IPv6 520 address 2001:db8:1::1. 522 ISATAP host 'G' connects to the site via an IPv4 interface with 523 address 192.0.2.5, and also configures an ISATAP host interface with 524 link-local address fe80::5efe:192.0.2.5 over the IPv4 interface. 'G' 525 next performs an RS/RA exchange with 'B' to configure default IPv6 526 route with next-hop address fe80::5efe:192.0.2.2, then receives the 527 IPv6 address 2001:db8:2::1 from a DHCPv6 address configuration 528 exchange via 'B'. When 'G' receives the IPv6 address, it assigns the 529 address to the ISATAP interface but does not assign a non-link-local 530 IPv6 prefix to the interface. 532 Finally, IPv6 host 'H' connects to an IPv6 network outside of the 533 ISATAP domain. 'H' configures its IPv6 interface in a manner 534 specific to its attached IPv6 link, and autoconfigures the IPv6 535 address 2001:db8:3::1. 537 Following this autoconfiguration, when host 'D' has an IPv6 packet to 538 send to host 'F', it prepares the packet with source address 2001: 539 db8::1 and destination address 2001:db8:1::1, then sends the packet 540 into the edge network where IPv6 forwarding will eventually convey it 541 to router 'C'. 'C' then uses IPv6-in-IPv4 encapsulation to forward 542 the packet to router 'E', since it has discovered a route to 2001: 543 db8:1::/48 with next hop 'E' via dynamic routing over the ISATAP 544 interface. Router 'E' finally sends the packet into the edge network 545 where IPv6 forwarding will eventually convey it to host 'F'. 547 In a second scenario, when 'D' has a packet to send to ISATAP host 548 'G', it prepares the packet with source address 2001:db8::1 and 549 destination address 2001:db8:2::1, then sends the packet into the 550 edge network where it will eventually be forwarded to router 'C' the 551 same as above. 'C' then uses IPv6-in-IPv4 encapsulation to forward 552 the packet to router 'A' (i.e., a router that advertises "default"), 553 which in turn forwards the packet to 'G'. Note that this operation 554 entails two hops across the ISATAP link (i.e., one from 'C' to 'A', 555 and a second from 'A' to 'G'). If 'G' also participates in the 556 dynamic IPv6 routing protocol, however, 'C' could instead forward the 557 packet directly to 'G' without involving 'A'. 559 In a third scenario, when 'D' has a packet to send to host 'H' in the 560 IPv6 Internet, the packet is forwarded to 'C' the same as above. 'C' 561 then forwards the packet to 'A', which forwards the packet into the 562 IPv6 Internet. 564 In a final scenario, when 'G' has a packet to send to host 'H' in the 565 IPv6 Internet, the packet is forwarded directly to 'B', which 566 forwards the packet into the IPv6 Internet. 568 4.4. Loop Avoidance 570 In a purely DHCPv6-based ISATAP deployment, no non-link-local IPv6 571 prefixes are assigned to ISATAP router interfaces. Therefore, an 572 ISATAP router cannot mistake another router for an ISATAP host due to 573 an address that matches an on-link prefix. This corresponds to the 574 mitigation documented in Section 3.2.4 of 575 [I-D.ietf-v6ops-tunnel-loops]. 577 Any routing loops introduced in the DHCPv6 scenario would therefore 578 be due to a misconfiguration in IPv6 routing the same as for any IPv6 579 router, and hence are out of scope for this document. 581 5. Scaling Considerations 583 Figure 1 and Figure 2 depict ISATAP network topologies with only two 584 advertising ISATAP routers within the site. In order to support 585 larger numbers of ISATAP clients, the site can deploy more 586 advertising ISATAP routers to support load balancing and generally 587 shortest-path routing. 589 Such an arrangement requires that the advertising ISATAP routers 590 participate in an IPv6 routing protocol instance so that IPv6 591 addresses/prefixes can be mapped to the correct ISATAP router. The 592 routing protocol instance can be configured as either a full mesh 593 topology involving all advertising ISATAP routers, or as a partial 594 mesh topology with each advertising ISATAP router associating with 595 one or more companion gateways. Each such companion gateway would in 596 turn participate in a full mesh between all companion gateways. 598 6. On-Demand Dynamic Routing 600 With respect to the reference operational scenarios depicted in 601 Figure 2, there may be use cases in which a proactive dynamic IPv6 602 routing protocol cannot be used. For example, in large enterprise 603 network deployments it would be impractical for all ISATAP routers to 604 engage in a common routing protocol instance due to scaling 605 considerations. 607 In those cases, an on-demand routing capability can be enabled in 608 which ISATAP nodes send initial packets via an advertising ISATAP 609 router and receive redirection messages back. For example, when a 610 non-advertising ISATAP router 'C' has a packet to send to a host 611 located behind non-advertising ISATAP router 'E', it can send the 612 initial packets via advertising router 'A' which will return 613 redirection messages to inform 'C' that 'E' is a better first hop. 614 Protocol details for this redirection procedure (including a means 615 for detecting whether the direct path is usable) are specified in 616 [I-D.templin-aero]. 618 7. Site Partitioning Considerations 620 In common practice, site administrators often deploy packet filtering 621 devices of various forms in order to divide the site into separate 622 partitions. These devices may prevent IPv6-in-IPv4 encapsulated 623 packets from traversing partition boundaries. 625 In order to avoid communication failures that may result from 626 filtering, ISATAP clients (i.e., hosts and non-advertising routers) 627 should only enable the service after an initial reachability exchange 628 with an advertising ISATAP router (e.g., in an initial RS/RA 629 exchange). ISATAP client to client communications should therefore 630 also only be used when the path between the clients is first tested 631 in an initial reachability exchange. 633 8. Site Renumbering Considerations 635 Advertising ISATAP routers distribute IPv6 prefixes to ISATAP clients 636 within the site via DHCPv6 and/or SLAAC. If the site subsequently 637 reconnects to a different ISP, however, the site must renumber to use 638 addresses derived from the new IPv6 prefixes 639 [RFC1900][RFC4192][RFC5887]. 641 For basic IPv6 services provided by SLAAC, site renumbering in the 642 event of a change in an ISP-served IPv6 prefix entails a simple 643 renumbering of IPv6 addresses and/or prefixes that are assigned to 644 the ISATAP interfaces of hosts within the site. In some cases, 645 filtering rules (e.g., within site border firewall filtering tables) 646 may also require renumbering, but this operation can be automated and 647 limited to only one or a few administrative "touch points". In order 648 to renumber the ISATAP interfaces of hosts within the site using 649 SLAAC, advertising ISATAP routers need only schedule the services 650 offered by the old ISP for deprecation while beginning to advertise 651 the IPv6 prefixes provided by the new ISP. ISATAP host interface 652 address lifetimes will eventually expire, and the host will renumber 653 its interfaces with addresses derived from the new prefixes. 655 For fully-qualified IPv6 services provided by DHCPv6, site 656 renumbering in the event of a change in an ISP-served IPv6 prefix 657 further entails locating and rewriting all IPv6 addresses in naming 658 services, databases, configuration files, packet filtering rules, 659 documentation, etc. If the site has published the IPv6 addresses of 660 any site- internal nodes within the public Internet DNS system, then 661 the corresponding resource records will also need to be updated 662 during the renumbering operation. This can be accomplished via 663 secure dynamic updates to the DNS. 665 9. Path MTU Considerations 667 IPv6-in-IPv4 encapsulation overhead effectively reduces the size of 668 IPv6 packets that can traverse the tunnel in relation to the actual 669 Maximum Transmission Unit (MTU) of the underlying IPv4 network path 670 between the encapsulator and decapsulator. Two methods for 671 accommodating IPv6 path MTU discovery over IPv6-in-IPv4 tunnels 672 (i.e., the static and dynamic methods) are documented in Section 3.2 673 of [RFC4213]. 675 The static method places a "safe" upper bound on the size of IPv6 676 packets permitted to enter the tunnel, however the method can be 677 overly conservative when larger IPv4 path MTUs are available. The 678 dynamic method can accommodate much larger IPv6 packet sizes in some 679 cases, but can fail silently if the underlying IPv4 network path does 680 not return the necessary error messages. 682 This document notes that sites that include well-managed IPv4 links, 683 routers and other network middleboxes are candidates for use of the 684 dynamic MTU determination method, which may provide for a better 685 operational IPv6 experience in the presence of IPv6-in-IPv4 tunnels. 687 10. Alternative Approaches 689 [RFC4554] proposes a use of VLANs for IPv4-IPv6 coexistence in 690 enterprise networks. The ISATAP approach provides a more flexible 691 and broadly-applicable alternative, and with fewer administrative 692 touch points. 694 The tunnel broker service [RFC3053] uses point-to-point tunnels that 695 require end users to establish an explicit administrative 696 configuration of the tunnel far end, which may be outside of the 697 administrative boundaries of the site. 699 6to4 [RFC3056] and Teredo [RFC4380] provide "last resort" unmanaged 700 automatic tunneling services when no other means for IPv6 701 connectivity is available. These services are given lower priority 702 when the ISATAP managed service and/or native IPv6 services are 703 enabled. 705 IRON [RFC6179], RANGER [RFC5720], VET [RFC5558] and SEAL [RFC5320] 706 are a tribute to those in all walks of life who serve with dignity 707 and honor for the benefit of others. 709 11. IANA Considerations 711 This document has no IANA considerations. 713 12. Security Considerations 715 In addition to the security considerations documented in [RFC5214], 716 sites that use ISATAP should take care to ensure that no routing 717 loops are enabled [I-D.ietf-v6ops-tunnel-loops]. Additional security 718 concerns with IP tunneling are documented in [RFC6169]. 720 13. Acknowledgments 722 The following are acknowledged for their insights that helped shape 723 this work: Fred Baker, Brian Carpenter, Thomas Henderson, Philip 724 Homburg, Lee Howard, Ray Hunter, Joel Jaeggli, Gabi Nakibly, Hemant 725 Singh, Mark Smith, Ole Troan, Gunter Van de Velde, ... 727 14. References 729 14.1. Normative References 731 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 732 E. Lear, "Address Allocation for Private Internets", 733 BCP 5, RFC 1918, February 1996. 735 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 736 and M. Carney, "Dynamic Host Configuration Protocol for 737 IPv6 (DHCPv6)", RFC 3315, July 2003. 739 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 740 Host Configuration Protocol (DHCP) version 6", RFC 3633, 741 December 2003. 743 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 744 for IPv6 Hosts and Routers", RFC 4213, October 2005. 746 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 747 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 748 September 2007. 750 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 751 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 752 March 2008. 754 14.2. Informative References 756 [I-D.ietf-v6ops-tunnel-loops] 757 Nakibly, G. and F. Templin, "Routing Loop Attack using 758 IPv6 Automatic Tunnels: Problem Statement and Proposed 759 Mitigations", draft-ietf-v6ops-tunnel-loops-07 (work in 760 progress), May 2011. 762 [I-D.templin-aero] 763 Templin, F., "Asymmetric Extended Route Optimization 764 (AERO)", draft-templin-aero-00 (work in progress), 765 March 2011. 767 [RFC1687] Fleischman, E., "A Large Corporate User's View of IPng", 768 RFC 1687, August 1994. 770 [RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", 771 RFC 1900, February 1996. 773 [RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 774 over Non-Broadcast Multiple Access (NBMA) networks", 775 RFC 2491, January 1999. 777 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 778 Domains without Explicit Tunnels", RFC 2529, March 1999. 780 [RFC2983] Black, D., "Differentiated Services and Tunnels", 781 RFC 2983, October 2000. 783 [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 784 Tunnel Broker", RFC 3053, January 2001. 786 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 787 via IPv4 Clouds", RFC 3056, February 2001. 789 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 790 of Explicit Congestion Notification (ECN) to IP", 791 RFC 3168, September 2001. 793 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 794 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 795 September 2005. 797 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 798 Network Address Translations (NATs)", RFC 4380, 799 February 2006. 801 [RFC4554] Chown, T., "Use of VLANs for IPv4-IPv6 Coexistence in 802 Enterprise Networks", RFC 4554, June 2006. 804 [RFC5320] Templin, F., "The Subnetwork Encapsulation and Adaptation 805 Layer (SEAL)", RFC 5320, February 2010. 807 [RFC5558] Templin, F., "Virtual Enterprise Traversal (VET)", 808 RFC 5558, February 2010. 810 [RFC5720] Templin, F., "Routing and Addressing in Networks with 811 Global Enterprise Recursion (RANGER)", RFC 5720, 812 February 2010. 814 [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering 815 Still Needs Work", RFC 5887, May 2010. 817 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 818 Infrastructures (6rd) -- Protocol Specification", 819 RFC 5969, August 2010. 821 [RFC6139] Russert, S., Fleischman, E., and F. Templin, "Routing and 822 Addressing in Networks with Global Enterprise Recursion 823 (RANGER) Scenarios", RFC 6139, February 2011. 825 [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security 826 Concerns with IP Tunneling", RFC 6169, April 2011. 828 [RFC6179] Templin, F., "The Internet Routing Overlay Network 829 (IRON)", RFC 6179, March 2011. 831 Author's Address 833 Fred L. Templin 834 Boeing Research & Technology 835 P.O. Box 3707 MC 7L-49 836 Seattle, WA 98124 837 USA 839 Email: fltemplin@acm.org