idnits 2.17.1 draft-templin-v6ops-isops-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 18, 2011) is 4721 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1918' is defined on line 798, 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 (-13) exists of draft-ietf-6man-addr-select-opt-00 == Outdated reference: A later version (-12) exists of draft-templin-aero-00 -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). 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 18, 2011 5 Expires: November 19, 2011 7 Operational Guidance for IPv6 Deployment in IPv4 Sites using ISATAP 8 draft-templin-v6ops-isops-02.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 19, 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. Advertising ISATAP Router Behavior . . . . . . . . . . . . 5 63 3.2. Non-Advertising ISATAP Router Behavior . . . . . . . . . . 5 64 3.3. ISATAP Host Behavior . . . . . . . . . . . . . . . . . . . 5 65 3.4. Reference Operational Scenario . . . . . . . . . . . . . . 6 66 3.5. Loop Avoidance . . . . . . . . . . . . . . . . . . . . . . 8 67 4. DHCPv6 Services . . . . . . . . . . . . . . . . . . . . . . . 8 68 4.1. Advertising ISATAP Router Behavior . . . . . . . . . . . . 9 69 4.2. Non-Advertising ISATAP Router Behavior . . . . . . . . . . 9 70 4.3. ISATAP Host Behavior . . . . . . . . . . . . . . . . . . . 10 71 4.4. Reference Operational Scenario . . . . . . . . . . . . . . 10 72 4.5. Loop Avoidance . . . . . . . . . . . . . . . . . . . . . . 13 73 5. Scaling Considerations . . . . . . . . . . . . . . . . . . . . 13 74 6. On-Demand Dynamic Routing . . . . . . . . . . . . . . . . . . 14 75 7. Site Administration Considerations . . . . . . . . . . . . . . 14 76 7.1. A Simple Example . . . . . . . . . . . . . . . . . . . . . 15 77 8. Site Renumbering Considerations . . . . . . . . . . . . . . . 15 78 9. Path MTU Considerations . . . . . . . . . . . . . . . . . . . 16 79 10. Alternative Approaches . . . . . . . . . . . . . . . . . . . . 17 80 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 81 12. Security Considerations . . . . . . . . . . . . . . . . . . . 17 82 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 83 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 84 14.1. Normative References . . . . . . . . . . . . . . . . . . . 18 85 14.2. Informative References . . . . . . . . . . . . . . . . . . 18 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 88 1. Introduction 90 End user sites in the Internet today currently use IPv4 routing and 91 addressing internally for core operating functions such as web 92 browsing, filesharing, network printing, e-mail, teleconferencing and 93 numerous other site-internal networking services. Such sites 94 typically have an abundance of public or private IPv4 addresses for 95 internal networking, and are separated from the public Internet by 96 firewalls, packet filtering gateways, proxies, address translators 97 and other site border demarcation devices. To date, such sites have 98 had little incentive to enable IPv6 services internally [RFC1687]. 100 End-user sites that currently use IPv4 services internally come in 101 endless sizes and varieties. For example, a home network behind a 102 Network Address Translator (NAT) may consist of a single link 103 supporting a few laptops, printers etc. As a larger example, a small 104 business may consist of one or a few offices with several networks 105 connecting considerably larger numbers of computers, routers, 106 handheld devices, printers, faxes, etc. Moving further up the scale, 107 large banks, restaurants, major retailers, large corporations, etc. 108 may consist of hundreds or thousands of branches worldwide that are 109 tied together in a complex global enterprise network. Additional 110 examples include personal-area networks, mobile vehicular networks, 111 disaster relief networks, tactical military networks, and various 112 forms of Mobile Ad-hoc Networks (MANETs). These cases and more are 113 discussed in RANGERS[RFC6139]. 115 With the proliferation of IPv6 devices in the public Internet, 116 however, existing IPv4 sites will increasingly require a means for 117 enabling IPv6 services so that hosts within the site can communicate 118 with IPv6-only correspondents. Such services must be deployable with 119 minimal configuration, and in a fashion that will not cause 120 disruptions to existing IPv4 services. The Intra-Site Automatic 121 Tunnel Addressing Protocol (ISATAP) [RFC5214] provides a simple-to- 122 use service that sites can deploy in the near term to meet these 123 requirements. This document therefore provides operational guidance 124 for using ISATAP to enable IPv6 services within predominantly IPv4 125 sites while causing no disruptions to existing IPv4 services. 127 2. Enabling IPv6 Services using ISATAP 129 Many existing sites within the Internet predominantly use IPv4-based 130 services for their internal networking needs, but there is a growing 131 requirement for enabling IPv6 services to support communications with 132 IPv6-only correspondents. Smaller sites that wish to enable IPv6 133 typically arrange to obtain public IPv6 prefixes from an Internet 134 Service Provider (ISP), where the prefixes may be either purely 135 native or the near-native prefixes offered by 6rd [RFC5969]. Larger 136 sites typically obtain provider independent IPv6 prefixes from an 137 Internet registry and advertise the prefixes into the IPv6 routing 138 system on their own behalf, i.e., they act as an ISP unto themselves. 139 In either case, after obtaining IPv6 prefixes the site can 140 automatically enable IPv6 services internally by configuring ISATAP. 142 The ISATAP service uses a Non-Broadcast, Multiple Access (NBMA) 143 tunnel virtual interface model [RFC2491][RFC2529] based on IPv6-in- 144 IPv4 encapsulation [RFC4213]. The encapsulation format can further 145 use Differentiated Service (DS) [RFC2983] and Explicit Congestion 146 Notification (ECN) [RFC3168] mapping between the inner and outer IP 147 headers to ensure expected per-hop behavior within well-managed 148 sites. 150 The ISATAP service is based on three basic node types known as 151 advertising ISATAP routers, non-advertising ISATAP routers and ISATAP 152 hosts. Advertising ISATAP routers configure their site-facing ISATAP 153 interfaces as advertising router interfaces (see: [RFC4861], Section 154 6.2.2). Non-advertising ISATAP routers configure their site-facing 155 ISATAP interfaces as non-advertising router interfaces and obtain 156 IPv6 addresses/prefixes via autoconfiguration exchanges with 157 advertising ISATAP routers. Finally, ISATAP hosts configure their 158 site-facing ISATAP interfaces as simple host interfaces and also 159 coordinate their autoconfiguration operations with advertising ISATAP 160 routers. In this sense, advertising ISATAP routers are "servers" 161 while non-advertising ISATAP routers and ISATAP hosts are "clients" 162 in the service model. 164 Advertising ISATAP routers arrange to add their IPv4 addresses to the 165 Potential Router List (PRL) within the site name service. The name 166 service could be either the DNS or some other site-internal name 167 resolution system, but the PRL should be published in such a way that 168 ISATAP clients can resolve the name "isatap.domainname" for the 169 "domainname" suffix associated with their attached link. For 170 example, if the domainname suffix associated with an ISATAP client's 171 attached link is "example.com", then the name of the PRL for that 172 link attachment point is "isatap.example.com". Alternatively, if the 173 site name service is operating without a domainname suffix, then the 174 name of the PRL is simply "isatap". (In either case, however, site 175 administrators should ensure that the name resolution returns IPv4 176 addresses of advertising ISATAP routers that are topologically close 177 to each ISATAP client depending on their locations.) 179 After the PRL is published, ISATAP clients within the site will 180 automatically perform a standard IPv6 Neighbor Discovery Router 181 Solicitation (RS) / Router Advertisement (RA) exchange with 182 advertising ISATAP routers [RFC4861][RFC5214]. Each ISATAP client 183 can also test the round-trip delays to multiple advertising ISATAP 184 routers during an initial exchange, and select those routers with the 185 smallest delays. Site administrators could further include an IPv4 186 anycast address in the PRL, and assign the address to multiple 187 advertising ISATAP routers. In that case, IPv4 routing within the 188 site would direct the ISATAP client to the nearest advertising ISATAP 189 router. 191 Following router discovery, ISATAP clients initiate Stateless Address 192 AutoConfiguration (SLAAC) [RFC4862][RFC5214], the Dynamic Host 193 Configuration Protocol for IPv6 (DHCPv6) [RFC3315] or both. 195 3. SLAAC Services 197 Predominantly IPv4 sites can enable ISATAP SLAAC services for ISATAP 198 clients that need to communicate with IPv6 correspondents. The 199 following sections discuss operational considerations for enabling 200 ISATAP SLAAC services within predominantly IPv4 sites. 202 3.1. Advertising ISATAP Router Behavior 204 Advertising ISATAP routers that support SLAAC services send RA 205 messages in response to RS messages received on an advertising ISATAP 206 interface. SLAAC services are enabled when advertising ISATAP 207 routers advertise non-link-local IPv6 prefixes in Prefix Information 208 Options (PIOs) with the A flag set to 1[RFC4861]. When there are 209 multiple advertising ISATAP routers, the routers can advertise the 210 same IPv6 prefixes or a different set of IPv6 prefixes. For example, 211 a first router may advertise 2001:db8:1::/64, a second may advertise 212 2001:db8:2::/64, etc. 214 3.2. Non-Advertising ISATAP Router Behavior 216 Non-advertising ISATAP routers that engage in SLAAC behave the same 217 as for hosts (see below). 219 3.3. ISATAP Host Behavior 221 ISATAP hosts resolve the PRL and send RS messages to obtain RA 222 messages from an advertising ISATAP router. When the host receives 223 RA messages, it uses SLAAC to configure IPv6 addresses from any 224 advertised prefixes with the A flag set to 1 as specified in 225 [RFC4862][RFC5214] then assigns the addresses to the ISATAP 226 interface. The host also assigns any of the advertised prefixes with 227 the L flag set to 1 to the ISATAP interface. 229 Any IPv6 addresses configured in this fashion and assigned to an 230 ISATAP interface are known as ISATAP addresses. Similarly, any IPv6 231 prefixes in PIOs received on an ISATAP interface with the L flag set 232 to 1 are known as ISATAP prefixes. 234 3.4. Reference Operational Scenario 236 Figure 1 depicts a reference ISATAP network topology for allowing 237 hosts within a predominantly IPv4 site to configure IPv6 services 238 using ISATAP with SLAAC. The scenario shows two advertising ISATAP 239 routers ('A', 'B'), two ISATAP hosts ('C', 'D'), and an ordinary IPv6 240 host ('E') outside of the site in a typical deployment configuration: 241 .-(::::::::) 2001:db8:3::1 242 .-(::: IPv6 :::)-. +-------------+ 243 (:::: Internet ::::) | IPv6 Host E | 244 `-(::::::::::::)-' +-------------+ 245 `-(::::::)-' 246 +------------+ +------------+ 247 | Router A |---.---| Router B |. 248 ,| (isatap) | | (isatap) | `\ 249 / +------------+ +------------+ \ 250 : fe80::*:192.0.1.1 fe80::*:192.0.1.2 : 251 \ 2001:db8:1::/64 2001:db8:1::/64 / 252 : : 253 : : 254 +- IPv4 Site -+ 255 ; (PRL: 192.0.2.1, 192.0.2.2) : 256 | ; 257 : -+-' 258 `-. .) 259 \ _) 260 `-----+--------)----+'----' 261 fe80::*:192.0.2.3 fe80::*:192.0.2.4 262 2001:db8:1::*:192.0.2.3 2001:db8:1::*:192.0.2.4 263 +--------------+ +--------------+ 264 | (isatap) | | (isatap) | 265 | Host C | | Host D | 266 +--------------+ +--------------+ 268 (* == "5efe") 270 Figure 1: Reference ISATAP Network Topology using SLAAC 272 In Figure 1, advertising ISATAP routers 'A' and 'B' within the IPv4 273 site connect to the IPv6 Internet. (Note that the routers may 274 instead connect to the IPv6 Internet via a companion gateway as shown 275 in Figure 2.) Advertising ISATAP router 'A' configures a site- 276 interior IPv4 interface with address 192.0.2.1 and arranges to add 277 the address to the site's PRL. 'A' next configures an advertising 278 ISATAP router interface with link-local ISATAP address fe80::5efe: 279 192.0.2.1 over the IPv4 interface. In the same fashion, 'B' 280 configures the IPv4 interface address 192.0.2.2, adds the address to 281 the PRL, then configures its advertising ISATAP router interface with 282 link-local ISATAP address fe80::5efe:192.0.2.2. 284 ISATAP host 'C' connects to the site via an IPv4 interface with 285 address 192.0.2.3, and also configures an ISATAP host interface with 286 link-local ISATAP address fe80::5efe:192.0.2.3 over the IPv4 287 interface. 'C' next resolves the PRL to discover the address 288 192.0.2.1 and performs an RS/RA exchange with 'A'. Based on the RA 289 information, 'C' next configures a default IPv6 route with next-hop 290 address fe80::5efe:192.0.2.1 via the ISATAP interface and processes 291 the IPv6 prefix 2001:db8:1::/64 advertised in the PIO. When 'C' 292 processes the prefix, it uses SLAAC to automatically configure the 293 ISATAP address 2001:db8:1::5efe:192.0.2.3. 'C' then assigns the 294 address to the ISATAP interface. 296 In the same fashion, ISATAP host 'D' configures its IPv4 interface 297 with address 192.0.2.4 and configures its ISATAP interface with link- 298 local ISATAP address fe80::5efe:192.0.2.4. 'D' next performs an 299 RS/RA exchange with 'B', then uses SLAAC to autoconfigure the ISATAP 300 address 2001:db8:1::5efe:192.0.2.4. 302 Finally, IPv6 host 'E' connects to an IPv6 network outside of the 303 site. 'E' configures its IPv6 interface in a manner specific to its 304 attached IPv6 link, and autoconfigures the IPv6 address 305 2001:db8:3::1. 307 Following this autoconfiguration, when host 'C' has an IPv6 packet to 308 send to host 'E', it prepares the packet with source address 2001: 309 db8::5efe:192.0.2.3 and destination address 2001:db8:3::1. 'C' then 310 uses IPv6-in-IPv4 encapsulation to forward the packet to router 'A', 311 which in turn decapsulates the packet and forwards it into the public 312 IPv6 Internet where it will be conveyed to 'E' via normal IPv6 313 routing. (Note that 'A' may "translate" the packet as it is 314 forwarded across the site boundary such that it appears to come from 315 a different source address than the one used by host 'C' within the 316 site.) In the same fashion, host 'D' uses IPv6-in-IPv4 encapsulation 317 via its default router 'B' to send IPv6 packets to IPv6 Internet 318 hosts such as 'E'. 320 When host 'C' connects to host 'D', it has the option of using the 321 native IPv4 service or the ISATAP IPv6-in-IPv4 encapsulation service 322 since the two hosts configure ISATAP addresses from the same ISATAP 323 prefix which implies that they are within the same contiguous IPv4 324 routing region (see Section 7). In that case, the hosts would be 325 better served to continue to use legacy IPv4 services in order to 326 avoid encapsulation overhead and to avoid any IPv4 protocol-41 327 filtering middleboxes that may be in the path. If the hosts instead 328 configured ISATAP addresses from different prefixes, however, 'C' 329 would instead need to use IPv6 since there is no guarantee that the 330 two hosts are within the same contiguous IPv4 routing region. In 331 that case, 'C' uses IPv6-in-IPv4 encapsulation to forward its IPv6 332 packets to advertising ISATAP router 'A', which in turn conveys the 333 packets to 'D' either directly or via another advertising ISATAP 334 router 'B' that services the prefix used by 'D'.. 336 3.5. Loop Avoidance 338 In sites that provide IPv6 services through ISATAP with SLAAC as 339 described in this section, advertising ISATAP routers must take 340 operational precautions to avoid routing loops. For example, with 341 reference to Figure 1 an IPv6 packet that enters the site via 342 advertising ISATAP router 'A' must not be allowed to exit the site 343 via advertising ISATAP router 'B' based on an invalid SLAAC address. 345 As a simple mitigation, each advertising ISATAP router should drop 346 any packets coming from the IPv6 Internet that would be forwarded 347 back to the Internet via another advertising router. Additionally, 348 each advertising ISATAP router should drop any encapsulated packets 349 received from another advertising router that would be forwarded to 350 the IPv6 Internet. (Note that IPv6 packets with link-local ISATAP 351 addresses are excluded from these checks, since they cannot be 352 forwarded by an IPv6 router and may be necessary for router-to-router 353 coordinations.) This corresponds to the mitigation documented in 354 Section 3.2.3 of [I-D.ietf-v6ops-tunnel-loops], but other mitigations 355 specified in that 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 stateless IPv6 369 services available using SLAAC, they can also provide managed 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. Advertising 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 4.2. Non-Advertising ISATAP Router Behavior 404 Non-advertising ISATAP routers can acquire IPv6 prefixes, e.g., 405 through the use of DHCPv6 Prefix Delegation [RFC3633] via an 406 advertising router in the same fashion as described for host-based 407 DHCPv6 stateful address autoconfiguration in Section 4.3. The 408 advertising router in turn maintains IPv6 forwarding table entries 409 that list the IPv4 address of the non-advertising router as the link- 410 layer address of the next hop toward the delegated IPv6 prefixes. 412 In many use case scenarios (e.g., small enterprise networks, MANETs, 413 etc.), advertising and non-advertising ISATAP routers can engage in a 414 proactive dynamic IPv6 routing protocol (e.g., OSPFv3, RIPng, etc.) 415 over their ISATAP interfaces so that IPv6 routing/forwarding tables 416 can be populated and standard IPv6 forwarding between ISATAP routers 417 can be used. In other scenarios (e.g., large enterprise networks, 418 highly mobile MANETs, etc.), this might be impractical dues to 419 scaling issues. When a proactive dynamic routing protocol cannot be 420 used, non-advertising ISATAP routers send RS messages to obtain RA 421 messages from an advertising ISATAP router, i.e., they act as "hosts" 422 on their non-advertising ISATAP interfaces. 424 After the non-advertising ISATAP router acquires IPv6 prefixes, it 425 can sub-delegate them to routers and links within its attached IPv6 426 edge networks, then can forward any outbound IPv6 packets coming from 427 its edge networks via other ISATAP nodes on the link. 429 4.3. ISATAP Host Behavior 431 ISATAP hosts resolve the PRL and send RS messages to obtain RA 432 messages from an advertising ISATAP router. Whether or not IPv6 433 prefixes for SLAAC are advertised, the host can acquire IPv6 434 addresses, e.g., through the use of DHCPv6 stateful address 435 autoconfiguration [RFC3315]. To acquire addresses, the host performs 436 standard DHCPv6 exchanges while mapping the IPv6 437 "All_DHCP_Relay_Agents_and_Servers" link-scoped multicast address to 438 the IPv4 address of an advertising ISATAP router. 440 After the host receives IPv6 addresses, it assigns them to its ISATAP 441 interface and forwards any of its outbound IPv6 packets via the 442 advertising router as a default router. The advertising router in 443 turn maintains IPv6 forwarding table entries that list the IPv4 444 address of the host as the link-layer address of the delegated IPv6 445 addresses. Note that IPv6 addresses acquired from DHCPv6 therefore 446 need not be ISATAP addresses, i.e., even though the addresses are 447 assigned to the ISATAP interface. 449 4.4. Reference Operational Scenario 451 Figure 2 depicts a reference ISATAP network topology that uses 452 DHCPv6. The scenario shows two advertising ISATAP routers ('A', 453 'B'), two non-advertising ISATAP routers ('C', 'E'), an ISATAP host 454 ('G'), and three ordinary IPv6 hosts ('D', 'F', 'H') in a typical 455 deployment configuration: 457 .-(::::::::) 2001:db8:3::1 458 .-(::: IPv6 :::)-. +-------------+ 459 (:::: Internet ::::) | IPv6 Host H | 460 `-(::::::::::::)-' +-------------+ 461 `-(::::::)-' 462 ,~~~~~~~~~~~~~~~~~, 463 ,----|companion gateway|--. 464 / '~~~~~~~~~~~~~~~~~' : 465 / |. 466 ,-' `. 467 ; +------------+ +------------+ ) 468 : | Router A | | Router B | / fe80::*1:92.0.2.5 469 : | (isatap) | | (isatap) | ; 2001:db8:2::1 470 + +------------+ +------------+ \ +--------------+ 471 fe80::*:192.0.2.1 fe80::*:192.0.2.2 | (isatap) | 472 | ; | Host G | 473 : IPv4 Site -+-' +--------------+ 474 `-. (PRL: 192.0.2.1, 192.0.2.2) .) 475 \ _) 476 `-----+--------)----+'----' 477 fe80::*:192.0.2.3 fe80::*:192.0.2.4 .-. 478 +--------------+ +--------------+ ,-( _)-. 479 | (isatap) | | (isatap) | .-(_ IPv6 )-. 480 | Router C | | Router E |--(__Edge Network ) 481 +--------------+ +--------------+ `-(______)-' 482 2001:db8:0::/48 2001:db8:1::/48 | 483 | 2001:db8:1::1 484 .-. +-------------+ 485 ,-( _)-. 2001:db8::1 | IPv6 Host F | 486 .-(_ IPv6 )-. +-------------+ +-------------+ 487 (__Edge Network )--| IPv6 Host D | 488 `-(______)-' +-------------+ 490 (* == "5efe") 492 Figure 2: Reference ISATAP Network Topology using DHCPv6 494 In Figure 2, advertising ISATAP routers 'A' and 'B' within the IPv4 495 site connect to the IPv6 Internet via a companion gateway. (Note 496 that the routers may instead connect to the IPv6 Internet directly as 497 shown in Figure 1.) Advertising ISATAP router 'A' configures a 498 provider network IPv4 interface with address 192.0.2.1 and arranges 499 to add the address to the provider network PRL. 'A' next configures 500 an advertising ISATAP router interface with link-local ISATAP address 501 fe80::5efe:192.0.2.1 over the IPv4 interface. In the same fashion, 502 advertising ISATAP router 'B' configures the IPv4 interface address 503 192.0.2.2, adds the address to the PRL, then configures the ISATAP 504 interface link-local address fe80::5efe:192.0.2.2. 506 Non-advertising ISATAP router 'C' connects to one or more IPv6 edge 507 networks and also connects to the site via an IPv4 interface with 508 address 192.0.2.3, but it does not add the IPv4 address to the site's 509 PRL. 'C' next configures a non-advertising ISATAP router interface 510 with link-local ISATAP address fe80::5efe:192.0.2.3, then receives 511 the IPv6 prefix 2001:db8::/48 through a DHCPv6 prefix delegation 512 exchange via one of 'A' or 'B'. 'C' then engages in an IPv6 routing 513 protocol over its ISATAP interface and announces the delegated IPv6 514 prefix. 'C' finally sub-delegates the prefix to its attached edge 515 networks, where IPv6 host 'D' autoconfigures the address 2001:db8::1. 517 Non-advertising ISATAP router 'E' connects to the site, configures 518 its ISATAP interface, receives a DHCPv6 prefix delegation, and 519 engages in the IPv6 routing protocol the same as for 'C'. In 520 particular, 'E' configures the IPv4 address 192.0.2.4, the link-local 521 ISATAP address fe80::5efe:192.0.2.4, and the delegated IPv6 prefix 522 2001:db8:1::/48. 'E' finally sub-delegates the prefix to its 523 attached edge networks, where IPv6 host 'F' autoconfigures IPv6 524 address 2001:db8:1::1. 526 ISATAP host 'G' connects to the site via an IPv4 interface with 527 address 192.0.2.5, and also configures an ISATAP host interface with 528 link-local ISATAP address fe80::5efe:192.0.2.5 over the IPv4 529 interface. 'G' next performs an RS/RA exchange with 'B' to configure 530 default IPv6 route with next-hop address fe80::5efe:192.0.2.2, then 531 receives the IPv6 address 2001:db8:2::1 from a DHCPv6 address 532 configuration exchange via 'B'. When 'G' receives the IPv6 address, 533 it assigns the address to the ISATAP interface but does not assign a 534 non-link-local IPv6 prefix to the interface. 536 Finally, IPv6 host 'H' connects to an IPv6 network outside of the 537 ISATAP domain. 'H' configures its IPv6 interface in a manner 538 specific to its attached IPv6 link, and autoconfigures the IPv6 539 address 2001:db8:3::1. 541 Following this autoconfiguration, when host 'D' has an IPv6 packet to 542 send to host 'F', it prepares the packet with source address 2001: 543 db8::1 and destination address 2001:db8:1::1, then sends the packet 544 into the edge network where IPv6 forwarding will eventually convey it 545 to router 'C'. 'C' then uses IPv6-in-IPv4 encapsulation to forward 546 the packet to router 'E', since it has discovered a route to 2001: 547 db8:1::/48 with next hop 'E' via dynamic routing over the ISATAP 548 interface. Router 'E' finally sends the packet into the edge network 549 where IPv6 forwarding will eventually convey it to host 'F'. 551 In a second scenario, when 'D' has a packet to send to ISATAP host 552 'G', it prepares the packet with source address 2001:db8::1 and 553 destination address 2001:db8:2::1, then sends the packet into the 554 edge network where it will eventually be forwarded to router 'C' the 555 same as above. 'C' then uses IPv6-in-IPv4 encapsulation to forward 556 the packet to router 'A' (i.e., a router that advertises "default"), 557 which in turn forwards the packet to 'G'. Note that this operation 558 entails two hops across the ISATAP link (i.e., one from 'C' to 'A', 559 and a second from 'A' to 'G'). If 'G' also participates in the 560 dynamic IPv6 routing protocol, however, 'C' could instead forward the 561 packet directly to 'G' without involving 'A'. 563 In a third scenario, when 'D' has a packet to send to host 'H' in the 564 IPv6 Internet, the packet is forwarded to 'C' the same as above. 'C' 565 then forwards the packet to 'A', which forwards the packet into the 566 IPv6 Internet. 568 In a final scenario, when 'G' has a packet to send to host 'H' in the 569 IPv6 Internet, the packet is forwarded directly to 'B', which 570 forwards the packet into the IPv6 Internet. 572 4.5. Loop Avoidance 574 In a purely DHCPv6-based ISATAP deployment, no non-link-local IPv6 575 prefixes are assigned to ISATAP router interfaces. Therefore, an 576 ISATAP router cannot mistake another router for an ISATAP host due to 577 an address that matches an on-link prefix. This corresponds to the 578 mitigation documented in Section 3.2.4 of 579 [I-D.ietf-v6ops-tunnel-loops]. 581 Any routing loops introduced in the DHCPv6 scenario would therefore 582 be due to a misconfiguration in IPv6 routing the same as for any IPv6 583 router, and hence are out of scope for this document. 585 5. Scaling Considerations 587 Figure 1 and Figure 2 depict ISATAP network topologies with only two 588 advertising ISATAP routers within the site. In order to support 589 larger numbers of ISATAP clients, the site can deploy more 590 advertising ISATAP routers to support load balancing and generally 591 shortest-path routing. 593 Such an arrangement requires that the advertising ISATAP routers 594 participate in an IPv6 routing protocol instance so that IPv6 595 addresses/prefixes can be mapped to the correct ISATAP router. The 596 routing protocol instance can be configured as either a full mesh 597 topology involving all advertising ISATAP routers, or as a partial 598 mesh topology with each advertising ISATAP router associating with 599 one or more companion gateways. Each such companion gateway would in 600 turn participate in a full mesh between all companion gateways. 602 6. On-Demand Dynamic Routing 604 With respect to the reference operational scenarios depicted in 605 Figure 2, there may be use cases in which a proactive dynamic IPv6 606 routing protocol cannot be used. For example, in large enterprise 607 network deployments it would be impractical for all ISATAP routers to 608 engage in a common routing protocol instance due to scaling 609 considerations. 611 In those cases, an on-demand routing capability can be enabled in 612 which ISATAP nodes send initial packets via an advertising ISATAP 613 router and receive redirection messages back. For example, when a 614 non-advertising ISATAP router 'C' has a packet to send to a host 615 located behind non-advertising ISATAP router 'E', it can send the 616 initial packets via advertising router 'A' which will return 617 redirection messages to inform 'C' that 'E' is a better first hop. 618 Protocol details for this redirection procedure (including a means 619 for detecting whether the direct path is usable) are specified in 620 [I-D.templin-aero]. 622 7. Site Administration Considerations 624 In common practice, site administrators often deploy packet filtering 625 devices of various forms in order to divide the site into separate 626 partitions. Such devices may prevent IPv4 protocol-41 packets from 627 traversing a partition boundary even when other IPv4 protocol packets 628 are permitted to traverse the boundary. In order to avoid 629 communication failures that may result from filtering, ISATAP clients 630 should only enable the service after an initial reachability exchange 631 with an advertising ISATAP router. Communications between ISATAP 632 clients that configure addresses from the same ISATAP prefix should 633 therefore also only be used when the path between the clients is 634 first tested in an initial reachability exchange. 636 In order to provide a simple service that does not interact poorly 637 with existing site topological arrangements, site administrators can 638 configure advertising ISATAP routers to align their advertised ISATAP 639 prefixes with the site's underlying IPv4 network partitions by 640 advertising different prefixes to different sets of clients (e.g., as 641 identified by the client's IPv4 prefix). Site administrators can 642 further institute a policy that prefers native IPv4 addresses over 643 ISATAP addresses for intra-site communications when possible. 645 Site administrators can implement this policy by configuring address 646 selection policy rules in each ISATAP client that prefer IPv4 647 destination addresses over destination addresses derived from their 648 ISATAP prefixes [RFC3484]. For example, if the site has reserved the 649 prefix 2001:db8::/64 for ISATAP SLAAC services, each ISATAP client 650 could add the prefix 2001:db8::/64 to its address selection policy 651 table with a lower precedence than the prefix ::ffff:0:0/96. The 652 prefix could be added to each ISATAP client either manually, or 653 through an automated service such as a DHCP option 654 [I-D.ietf-6man-addr-select-opt]. 656 7.1. A Simple Example 658 Consider a large, multinational enterprise network that wishes to 659 enable IPv6 services without significant alterations to its long- 660 established IPv4 network operations and policies. The enterprise 661 network has a mature IPv4 routing and addressing system; possibly 662 including firewalling and filtering policies which divide the 663 enterprise into multiple partitions. 665 The enterprise network administrators obtain a single IPv6 prefix 666 such as 2001:db8::/64 and arrange to advertise the prefix into the 667 global IPv6 routing system. The administrators further configure 668 sufficient advertising ISATAP routers throughout the enterprise 669 network so that there will be at least one advertising ISATAP router 670 within close topological and/or geographic proximity with all 671 potential ISATAP clients. Each advertising ISATAP router is 672 configured to advertise the IPv6 prefix 2001:db8::/64 on its 673 advertising ISATAP interface. Each advertising ISATAP router 674 configures an IPv4 anycast address such as 192.0.2.1 (e.g., by 675 assigning the address to a loopback interface) and advertises the 676 address within the enterprise-interior IPv4 routing system. 678 Finally, the administrators configure all prospective ISATAP clients 679 to prefer IPv4 addresses over IPv6 addresses derived from the prefix 680 2001:db8::/64 so that clients will continue to use IPv4 services for 681 communications within the enterprise network as they have always 682 done. When the prospective clients have been configured with the 683 correct address selection policies, the enterprise network 684 administrators finally add the IPv4 anycast address 192.0.2.1 to the 685 PRL for the enterprise, e.g., by adding the address to the resource 686 records for the name "isatap" within the enterprise network name 687 service. This action automatically enables the ISATAP service for 688 all prospective clients, which can then use SLAAC to configure an 689 ISATAP address from the prefix 2001:db8::/64 and use the address to 690 communicate with IPv6 correspondents outside of the enterprise 691 network. 693 8. Site Renumbering Considerations 695 Advertising ISATAP routers distribute IPv6 prefixes to ISATAP clients 696 within the site via DHCPv6 and/or SLAAC. If the site subsequently 697 reconnects to a different ISP, however, the site must renumber to use 698 addresses derived from the new IPv6 prefixes 699 [RFC1900][RFC4192][RFC5887]. 701 For basic IPv6 services provided by SLAAC, site renumbering in the 702 event of a change in an ISP-served IPv6 prefix entails a simple 703 renumbering of IPv6 addresses and/or prefixes that are assigned to 704 the ISATAP interfaces of clients within the site. In some cases, 705 filtering rules (e.g., within site border firewall filtering tables) 706 may also require renumbering, but this operation can be automated and 707 limited to only one or a few administrative "touch points". 709 In order to renumber the ISATAP interfaces of clients within the site 710 using SLAAC, advertising ISATAP routers need only schedule the 711 services offered by the old ISP for deprecation and begin to 712 advertise the IPv6 prefixes provided by the new ISP. ISATAP client 713 interface address lifetimes will eventually expire, and the host will 714 renumber its interfaces with addresses derived from the new prefixes. 715 ISATAP clients should also eventually remove the deprecated SLAAC 716 prefixes from their address selection policy tables, but this action 717 is not time-critical. 719 Finally, site renumbering in the event of a change in an ISP-served 720 IPv6 prefix further entails locating and rewriting all IPv6 addresses 721 in naming services, databases, configuration files, packet filtering 722 rules, documentation, etc. If the site has published the IPv6 723 addresses of any site-internal nodes within the public Internet DNS 724 system, then the corresponding resource records will also need to be 725 updated during the renumbering operation. This can be accomplished 726 via secure dynamic updates to the DNS. 728 9. Path MTU Considerations 730 IPv6-in-IPv4 encapsulation overhead effectively reduces the size of 731 IPv6 packets that can traverse the tunnel in relation to the actual 732 Maximum Transmission Unit (MTU) of the underlying IPv4 network path 733 between the encapsulator and decapsulator. Two methods for 734 accommodating IPv6 path MTU discovery over IPv6-in-IPv4 tunnels 735 (i.e., the static and dynamic methods) are documented in Section 3.2 736 of [RFC4213]. 738 The static method places a "safe" upper bound on the size of IPv6 739 packets permitted to enter the tunnel, however the method can be 740 overly conservative when larger IPv4 path MTUs are available. The 741 dynamic method can accommodate much larger IPv6 packet sizes in some 742 cases, but can fail silently if the underlying IPv4 network path does 743 not return the necessary error messages. 745 This document notes that sites that include well-managed IPv4 links, 746 routers and other network middleboxes are candidates for use of the 747 dynamic MTU determination method, which may provide for a better 748 operational IPv6 experience in the presence of IPv6-in-IPv4 tunnels. 749 The dynamic MTU determination method can potentially also present a 750 larger MTU to IPv6 correspondents outside of the site, since IPv6 751 path MTU discovery is considered robust even over the wide area in 752 the public IPv6 Internet. 754 10. Alternative Approaches 756 [RFC4554] proposes a use of VLANs for IPv4-IPv6 coexistence in 757 enterprise networks. The ISATAP approach provides a more flexible 758 and broadly-applicable alternative, and with fewer administrative 759 touch points. 761 The tunnel broker service [RFC3053] uses point-to-point tunnels that 762 require end users to establish an explicit administrative 763 configuration of the tunnel far end, which may be outside of the 764 administrative boundaries of the site. 766 6to4 [RFC3056] and Teredo [RFC4380] provide "last resort" unmanaged 767 automatic tunneling services when no other means for IPv6 768 connectivity is available. These services are given lower priority 769 when the ISATAP managed service and/or native IPv6 services are 770 enabled. 772 IRON [RFC6179], RANGER [RFC5720], VET [RFC5558] and SEAL [RFC5320] 773 are a tribute to those in all walks of life who serve with dignity 774 and honor for the benefit of others. 776 11. IANA Considerations 778 This document has no IANA considerations. 780 12. Security Considerations 782 In addition to the security considerations documented in [RFC5214], 783 sites that use ISATAP should take care to ensure that no routing 784 loops are enabled [I-D.ietf-v6ops-tunnel-loops]. Additional security 785 concerns with IP tunneling are documented in [RFC6169]. 787 13. Acknowledgments 789 The following are acknowledged for their insights that helped shape 790 this work: Fred Baker, Brian Carpenter, Thomas Henderson, Philip 791 Homburg, Lee Howard, Ray Hunter, Joel Jaeggli, Gabi Nakibly, Hemant 792 Singh, Mark Smith, Ole Troan, Gunter Van de Velde, ... 794 14. References 796 14.1. Normative References 798 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 799 E. Lear, "Address Allocation for Private Internets", 800 BCP 5, RFC 1918, February 1996. 802 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 803 and M. Carney, "Dynamic Host Configuration Protocol for 804 IPv6 (DHCPv6)", RFC 3315, July 2003. 806 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 807 Host Configuration Protocol (DHCP) version 6", RFC 3633, 808 December 2003. 810 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 811 for IPv6 Hosts and Routers", RFC 4213, October 2005. 813 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 814 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 815 September 2007. 817 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 818 Address Autoconfiguration", RFC 4862, September 2007. 820 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 821 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 822 March 2008. 824 14.2. Informative References 826 [I-D.ietf-6man-addr-select-opt] 827 Matsumoto, A., Fujisaki, T., and J. Kato, "Distributing 828 Address Selection Policy using DHCPv6", 829 draft-ietf-6man-addr-select-opt-00 (work in progress), 830 December 2010. 832 [I-D.ietf-v6ops-tunnel-loops] 833 Nakibly, G. and F. Templin, "Routing Loop Attack using 834 IPv6 Automatic Tunnels: Problem Statement and Proposed 835 Mitigations", draft-ietf-v6ops-tunnel-loops-07 (work in 836 progress), May 2011. 838 [I-D.templin-aero] 839 Templin, F., "Asymmetric Extended Route Optimization 840 (AERO)", draft-templin-aero-00 (work in progress), 841 March 2011. 843 [RFC1687] Fleischman, E., "A Large Corporate User's View of IPng", 844 RFC 1687, August 1994. 846 [RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", 847 RFC 1900, February 1996. 849 [RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 850 over Non-Broadcast Multiple Access (NBMA) networks", 851 RFC 2491, January 1999. 853 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 854 Domains without Explicit Tunnels", RFC 2529, March 1999. 856 [RFC2983] Black, D., "Differentiated Services and Tunnels", 857 RFC 2983, October 2000. 859 [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 860 Tunnel Broker", RFC 3053, January 2001. 862 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 863 via IPv4 Clouds", RFC 3056, February 2001. 865 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 866 of Explicit Congestion Notification (ECN) to IP", 867 RFC 3168, September 2001. 869 [RFC3484] Draves, R., "Default Address Selection for Internet 870 Protocol version 6 (IPv6)", RFC 3484, February 2003. 872 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 873 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 874 September 2005. 876 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 877 Network Address Translations (NATs)", RFC 4380, 878 February 2006. 880 [RFC4554] Chown, T., "Use of VLANs for IPv4-IPv6 Coexistence in 881 Enterprise Networks", RFC 4554, June 2006. 883 [RFC5320] Templin, F., "The Subnetwork Encapsulation and Adaptation 884 Layer (SEAL)", RFC 5320, February 2010. 886 [RFC5558] Templin, F., "Virtual Enterprise Traversal (VET)", 887 RFC 5558, February 2010. 889 [RFC5720] Templin, F., "Routing and Addressing in Networks with 890 Global Enterprise Recursion (RANGER)", RFC 5720, 891 February 2010. 893 [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering 894 Still Needs Work", RFC 5887, May 2010. 896 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 897 Infrastructures (6rd) -- Protocol Specification", 898 RFC 5969, August 2010. 900 [RFC6139] Russert, S., Fleischman, E., and F. Templin, "Routing and 901 Addressing in Networks with Global Enterprise Recursion 902 (RANGER) Scenarios", RFC 6139, February 2011. 904 [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security 905 Concerns with IP Tunneling", RFC 6169, April 2011. 907 [RFC6179] Templin, F., "The Internet Routing Overlay Network 908 (IRON)", RFC 6179, March 2011. 910 Author's Address 912 Fred L. Templin 913 Boeing Research & Technology 914 P.O. Box 3707 MC 7L-49 915 Seattle, WA 98124 916 USA 918 Email: fltemplin@acm.org