idnits 2.17.1 draft-templin-isupdate-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 : ---------------------------------------------------------------------------- == 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 (April 11, 2012) is 4397 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** 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-03 == Outdated reference: A later version (-12) exists of draft-templin-aero-08 == Outdated reference: A later version (-19) exists of draft-templin-v6ops-isops-14 -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) Summary: 2 errors (**), 0 flaws (~~), 5 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 April 11, 2012 5 Expires: October 13, 2012 7 ISATAP Updates 8 draft-templin-isupdate-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 discusses updates to the 22 Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) to better 23 accommodate these needs. 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 October 13, 2012. 42 Copyright Notice 44 Copyright (c) 2012 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. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. ISATAP Updates . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. Advanced IPv6 Services Enabled by Updates . . . . . . . . . . 5 63 4.1. Advertising ISATAP Router Behavior . . . . . . . . . . . . 6 64 4.2. ISATAP Host Behavior . . . . . . . . . . . . . . . . . . . 6 65 4.3. Non-Advertising ISATAP Router Behavior . . . . . . . . . . 6 66 4.4. Reference Operational Scenario . . . . . . . . . . . . . . 7 67 4.5. Site Administration Guidance . . . . . . . . . . . . . . . 10 68 4.6. On-Demand Dynamic Routing . . . . . . . . . . . . . . . . 11 69 4.7. Loop Avoidance . . . . . . . . . . . . . . . . . . . . . . 12 70 5. Manual Configuration . . . . . . . . . . . . . . . . . . . . . 12 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 73 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 76 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 1. Introduction 81 End user sites in the Internet today currently use IPv4 routing and 82 addressing internally for core operating functions such as web 83 browsing, filesharing, network printing, e-mail, teleconferencing and 84 numerous other site-internal networking services. Such sites 85 typically have an abundance of public or private IPv4 addresses for 86 internal networking, and are separated from the public Internet by 87 firewalls, packet filtering gateways, proxies, address translators 88 and other site border demarcation devices. To date, such sites have 89 had little incentive to enable IPv6 services internally [RFC1687]. 91 End-user sites that currently use IPv4 services internally come in 92 endless sizes and varieties. For example, a home network behind a 93 Network Address Translator (NAT) may consist of a single link 94 supporting a few laptops, printers etc. As a larger example, a small 95 business may consist of one or a few offices with several networks 96 connecting considerably larger numbers of computers, routers, 97 handheld devices, printers, faxes, etc. Moving further up the scale, 98 large banks, restaurants, major retailers, large corporations, etc. 99 may consist of hundreds or thousands of branches worldwide that are 100 tied together in a complex global enterprise network. Additional 101 examples include personal-area networks, mobile vehicular networks, 102 disaster relief networks, tactical military networks, and various 103 forms of Mobile Ad-hoc Networks (MANETs). These cases and more are 104 discussed in RANGERS[RFC6139]. 106 With the proliferation of IPv6 devices in the public Internet, 107 however, existing IPv4 sites will increasingly require a means for 108 enabling IPv6 services so that hosts within the site can communicate 109 with IPv6-only correspondents. Such services must be deployable with 110 minimal configuration, and in a fashion that will not cause 111 disruptions to existing IPv4 services. The Intra-Site Automatic 112 Tunnel Addressing Protocol (ISATAP) [RFC5214] provides a simple-to- 113 use service that sites can deploy in the near term to meet these 114 requirements, as discussed in [I-D.templin-v6ops-isops]. However, 115 the ISATAP base specification has several fundamental limitations 116 that restrict its applicability. This document discusses the 117 motivations for new functionality followed by the updates and 118 operational practices necessary to provide a more fully-functioned 119 service. 121 2. Motivation 123 The base ISATAP specification does not support stateful address 124 configuration nor prefix delegation (e.g., via DHCPv6 125 [RFC3315][RFC3633]) on ISATAP interfaces. Instead, the base 126 specification requires a special IPv6 address format in which a 127 node's site-internal IPv4 address is embedded literally within the 128 interface identifier of its public IPv6 address. This exposes the 129 site-internal IPv4 address structure to IPv6 networks and 130 correspondents outside of the site such that (unlike for IPv4 131 networks behind NATs) topology hiding is compromised. Furthermore, 132 static linkage of the node's site-internal IPv4 address to its public 133 IPv6 address limits the node's ability to renumber its IPv4 address 134 without also deprecating the IPv6 address. These limitations may be 135 more of a concern in some ISATAP deployments than others, but can be 136 obviated by address configuration methods that support non-ISATAP 137 interface identifiers. 139 The ISATAP base specification further does not support router-to- 140 router tunneling, i.e., it permits only router-to-host and host-to- 141 host tunneling. This limitation results in an inability for users to 142 deploy recursively-nested "child" sites within a "parent" ISATAP site 143 as articulated in RANGER [RFC5720]. In practical terms, the ISATAP 144 base specification therefore does not allow for deployment of "stub" 145 IPv6-only networks inside of a parent site. Examples include an 146 IPv6-only bluetooth network of embedded devices, a laptop user's 147 personal-area network, an IPv6-only fileshare workgroup, etc. 148 Without updates to the ISATAP base specification, these limitations 149 could only be addressed by a site-wide native IPv6 deployment, which 150 the site may not be prepared to finance or support for the 151 foreseeable future. 153 Finally, the base specification provides no means for address 154 selection preference of IPv4 over ISATAP for communications within 155 the same site. Although this need could be addressed in the future 156 by a DHCP option [I-D.ietf-6man-addr-select-opt], it may be necessary 157 or preferable in some environments for ISATAP clients to discover 158 address selection preferences only from the information advertised by 159 ISATAP routers. This document therefore specifies updates to the 160 base specification to address these needs. 162 3. ISATAP Updates 164 The basic ISATAP model supports two basic node types - namely, 165 advertising ISATAP routers and ISATAP hosts. Advertising ISATAP 166 routers configure their site-facing ISATAP interfaces as advertising 167 router interfaces (see: [RFC4861], Section 6.2.2). ISATAP hosts 168 configure their site-facing ISATAP interfaces as simple host 169 interfaces and also coordinate their autoconfiguration operations 170 with advertising ISATAP routers. 172 This document introduces a third node type known as "non-advertising 173 ISATAP routers". Non-advertising ISATAP routers configure their 174 site-facing ISATAP interfaces as non-advertising router interfaces 175 and obtain IPv6 addresses/prefixes via manual or automatic 176 configuration arrangements with advertising ISATAP routers. Non- 177 advertising ISATAP routers connect IPv6 networks to the ISATAP link, 178 and can therefore support a router-to-router tunneling mode not 179 supported under the base specification. 181 To support this router-to-router tunneling (and also to support the 182 assignment of native IPv6 addresses on ISATAP interfaces) ISATAP 183 nodes add an update to the existing source address verification 184 checks specified in Section 7.3 of [RFC5214]. Namely, the node also 185 considers the outer IPv4 source address correct for the inner IPv6 186 source address if: 188 o a stateful address mapping exists that lists the packet's IPv4 189 source address as the link-layer address corresponding to the 190 inner IPv6 source address via the ISATAP interface. 192 The basic ISATAP model further does not specify any IPv6 multicast 193 mappings. This precludes the use of services such as DHCPv6 which 194 require a link-scoped IPv6 multicasting service. To support DHCPv6 195 services, ISATAP hosts and non-advertising ISATAP routers that 196 observe this specification map the IPv6 197 "All_DHCP_Relay_Agents_and_Servers" link-scoped multicast address to 198 the IPv4 address of an advertising ISATAP router that advertises 199 availability of the DHCPv6 service. The advertising ISATAP router in 200 turn configures a DHCPv6 server or relay function, and accepts DHCPv6 201 messages sent by clients using this mapping. The advertising router 202 also maintains a stateful address mapping that lists the IPv4 address 203 of the client as the link-layer address of any delegated IPv6 204 addresses or prefixes. 206 Finally, this document updates the address selection policies of the 207 base specification as follows. For communications between two nodes 208 whose IPv6 addresses are covered by the same IPv6 prefix advertised 209 in Router Advertisements (RAs) on an ISATAP interface, prefer IPv4 210 over IPv6 if the L bit in the Prefix Information Option (PIO) is set 211 to 0. 213 Using these updates, a much richer ISATAP service model is made 214 possible. The following sections describe the new modes of operation 215 that are enabled by the updates. 217 4. Advanced IPv6 Services Enabled by Updates 219 Whether or not advertising ISATAP routers make stateless IPv6 220 services available using StateLess Address AutoConfiguration (SLAAC), 221 they can also provide advanced IPv6 services to ISATAP clients (i.e., 222 both hosts and non-advertising ISATAP routers) using the updates 223 specified in this document. Any addresses/prefixes obtained via the 224 advanced (stateful) services are distinct from any IPv6 prefixes 225 advertised on the ISATAP interface for SLAAC purposes, however. 227 The following sections discuss operational considerations for 228 enabling ISATAP DHCPv6 services within predominantly IPv4 sites. 230 4.1. Advertising ISATAP Router Behavior 232 Advertising ISATAP routers that support DHCPv6 services send IPv6-in- 233 IPv4 encapsulated RA messages that advertise availability of the 234 service in response to IPv6-in-IPv4 encapsulated Router Solicitation 235 (RS) messages received on an advertising ISATAP interface. They also 236 configure either a DHCPv6 relay or server function to service DHCPv6 237 requests received from ISATAP clients. 239 4.2. ISATAP Host Behavior 241 ISATAP hosts send RS messages to obtain RA messages from an 242 advertising ISATAP router. When the DHCPv6 service is available, the 243 host can acquire IPv6 addresses through the use of DHCPv6 stateful 244 address autoconfiguration [RFC3315] whether or not IPv6 prefixes for 245 SLAAC are advertised. To acquire addresses, the host performs 246 standard DHCPv6 exchanges while mapping the IPv6 247 "All_DHCP_Relay_Agents_and_Servers" link-scoped multicast address to 248 the IPv4 address of an advertising ISATAP router that supports the 249 DHCPv6 service. 251 After the host receives IPv6 addresses, it assigns them to its ISATAP 252 interface and forwards any of its outbound IPv6 packets via the 253 advertising router as a default router. The advertising router in 254 turn maintains stateful address mappings that list the IPv4 address 255 of the host as the link-layer address of the delegated IPv6 256 addresses. Note that IPv6 addresses acquired from DHCPv6 therefore 257 need not be ISATAP addresses, i.e., even though the addresses are 258 assigned to the ISATAP interface. 260 4.3. Non-Advertising ISATAP Router Behavior 262 Non-advertising ISATAP routers send RS messages to obtain RA messages 263 from an advertising ISATAP router, i.e., they act as "hosts" on their 264 non-advertising ISATAP interfaces. Non-advertising ISATAP routers 265 can acquire IPv6 prefixes through the use of DHCPv6 Prefix Delegation 266 [RFC3633] via an advertising router that supports DHCPv6 services in 267 the same fashion as described above for host-based address 268 autoconfiguration. The advertising router in turn maintains stateful 269 address mappings that list the IPv4 address of the non-advertising 270 router as the link-layer address of the next hop toward the delegated 271 IPv6 prefixes. 273 In many use case scenarios (e.g., small enterprise networks, small 274 and stable MANETs, etc.), advertising and non-advertising ISATAP 275 routers can engage in a proactive dynamic IPv6 routing protocol 276 (e.g., OSPFv3, RIPng, etc.) over their ISATAP interfaces so that IPv6 277 routing/forwarding tables can be populated and standard IPv6 278 forwarding between ISATAP routers can be used. In other scenarios 279 (e.g., large enterprise networks, large and dynamic MANETs, etc.), 280 this might be impractical due to scaling issues. 282 After the non-advertising ISATAP router acquires IPv6 prefixes, it 283 can sub-delegate them to routers and links within its attached IPv6 284 edge networks, then can forward any outbound IPv6 packets coming from 285 its edge networks via other nodes on the ISATAP link. 287 4.4. Reference Operational Scenario 289 Figure 1 depicts a reference ISATAP network topology enabled by the 290 updated ISATAP services specified in this document. The scenario 291 shows two advertising ISATAP routers ('A', 'B'), two non-advertising 292 ISATAP routers ('C', 'E'), an ISATAP host ('G'), and three ordinary 293 IPv6 hosts ('D', 'F', 'H') in a typical deployment configuration: 295 .-(::::::::) 2001:db8:3::1 296 .-(::: IPv6 :::)-. +-------------+ 297 (:::: Internet ::::) | IPv6 Host H | 298 `-(::::::::::::)-' +-------------+ 299 `-(::::::)-' 300 ,~~~~~~~~~~~~~~~~~, 301 ,----|companion gateway|--. 302 / '~~~~~~~~~~~~~~~~~' : 303 / |. 304 ,-' `. 305 ; +------------+ +------------+ ) 306 : | Router A | | Router B | / 307 : | (isatap) | | (isatap) | : fe80::*192.0.2.4 308 : | 192.0.2.1 | | 192.0.2.1 | ; 2001:db8:2::1 309 + +------------+ +------------+ \ +--------------+ 310 fe80::*:192.0.2.1 fe80::*:192.0.2.1 | (isatap) | 311 | ; | Host G | 312 : IPv4 Site -+-' +--------------+ 313 `-. (PRL: 192.0.2.1) .) 314 \ _) 315 `-----+--------)----+'----' 316 fe80::*:192.0.2.2 fe80::*:192.0.2.3 .-. 317 +--------------+ +--------------+ ,-( _)-. 318 | (isatap) | | (isatap) | .-(_ IPv6 )-. 319 | Router C | | Router E |--(__Edge Network ) 320 +--------------+ +--------------+ `-(______)-' 321 2001:db8:0::/48 2001:db8:1::/48 | 322 | 2001:db8:1::1 323 .-. +-------------+ 324 ,-( _)-. 2001:db8:0::1 | IPv6 Host F | 325 .-(_ IPv6 )-. +-------------+ +-------------+ 326 (__Edge Network )--| IPv6 Host D | 327 `-(______)-' +-------------+ 329 (* == "5efe") 331 Figure 1: Reference ISATAP Network Topology 333 In Figure 1, advertising ISATAP routers 'A' and 'B' within the IPv4 334 site provide DHCPv6 services and connect to the IPv6 Internet either 335 directly or via a companion gateway. The advertising routers both 336 configure the IPv4 anycast address 192.0.2.1 on a site-interior IPv4 337 interface, and configure an advertising ISATAP interface with link- 338 local ISATAP address fe80::5efe:192.0.2.1. The site administrator 339 then places the single IPv4 address 192.0.2.1 in the Potential Router 340 List (PRL) for the site. 'A' and 'B' then both advertise the anycast 341 address/prefix into the site's IPv4 routing system so that ISATAP 342 clients can locate the router that is topologically closest. (Note: 344 advertising ISATAP routers can instead use individual IPv4 unicast 345 addresses instead of a shared IPv4 anycast address. In that case, 346 the PRL may contain multiple IPv4 addresses of advertising routers.) 348 Non-advertising ISATAP router 'C' connects to one or more IPv6 edge 349 networks and also connects to the site via an IPv4 interface with 350 address 192.0.2.2, but it does not advertise the site's IPv4 anycast 351 address/prefix. 'C' next configures a non-advertising ISATAP router 352 interface with link-local ISATAP address fe80::5efe:192.0.2.2, then 353 discovers router 'A' via an RS/RA exchange. 'C' next receives the 354 IPv6 prefix 2001:db8:0::/48 through a DHCPv6 prefix delegation 355 exchange via 'A', then engages in an IPv6 routing protocol over its 356 ISATAP interface and announces the delegated IPv6 prefix. 'C' 357 finally sub-delegates the prefix to its attached edge networks, where 358 IPv6 host 'D' autoconfigures the address 2001:db8:0::1. 360 Non-advertising ISATAP router 'E' connects to the site, configures 361 its ISATAP interface, performs an RS/RA exchange, receives a DHCPv6 362 prefix delegation, and engages in the IPv6 routing protocol the same 363 as for 'C'. In particular, 'E' configures the IPv4 address 192.0.2.3 364 and the link-local ISATAP address fe80::5efe:192.0.2.3. 'E' then 365 receives the delegated IPv6 prefix 2001:db8:1::/48 and sub-delegates 366 the prefix to its attached edge networks, where IPv6 host 'F' 367 autoconfigures IPv6 address 2001:db8:1::1. 369 ISATAP host 'G' connects to the site via an IPv4 interface with 370 address 192.0.2.4, and also configures an ISATAP host interface with 371 link-local ISATAP address fe80::5efe:192.0.2.4 over the IPv4 372 interface. 'G' next performs an RS/RA exchange to discover 'B" and 373 configures a default IPv6 route with next-hop address fe80::5efe: 374 192.0.2.1. 'G' then receives the IPv6 address 2001:db8:2::1 via a 375 DHCPv6 address configuration exchange via 'B'; it then assigns the 376 address to the ISATAP interface but does not assign a non-link-local 377 IPv6 prefix to the interface. 379 Finally, IPv6 host 'H' connects to an IPv6 network outside of the 380 ISATAP domain. 'H' configures its IPv6 interface in a manner 381 specific to its attached IPv6 link, and autoconfigures the IPv6 382 address 2001:db8:3::1. 384 Following this autoconfiguration, when host 'D' has an IPv6 packet to 385 send to host 'F', it prepares the packet with source address 2001: 386 db8:0::1 and destination address 2001:db8:1::1, then sends the packet 387 into the edge network where IPv6 forwarding will eventually convey it 388 to router 'C'. 'C' then uses IPv6-in-IPv4 encapsulation to forward 389 the packet to router 'E', since it has discovered a route to 2001: 390 db8:1::/48 with next hop 'E' via dynamic routing over the ISATAP 391 interface. Router 'E' finally sends the packet into the edge network 392 where IPv6 forwarding will eventually convey it to host 'F'. 394 In a second scenario, when 'D' has a packet to send to ISATAP host 395 'G', it prepares the packet with source address 2001:db8:0::1 and 396 destination address 2001:db8:2::1, then sends the packet into the 397 edge network where it will eventually be forwarded to router 'C' the 398 same as above. 'C' then uses IPv6-in-IPv4 encapsulation to forward 399 the packet to router 'A' (i.e., 'C's default router), which in turn 400 forwards the packet to 'G'. Note that this operation entails two 401 hops across the ISATAP link (i.e., one from 'C' to 'A', and a second 402 from 'A' to 'G'). If 'G' also participates in the dynamic IPv6 403 routing protocol, however, 'C' could instead forward the packet 404 directly to 'G' without involving 'A'. 406 In a third scenario, when 'D' has a packet to send to host 'H' in the 407 IPv6 Internet, the packet is forwarded to 'C' the same as above. 'C' 408 then forwards the packet to 'A', which forwards the packet into the 409 IPv6 Internet. 411 In a final scenario, when 'G' has a packet to send to host 'H' in the 412 IPv6 Internet, the packet is forwarded directly to 'B', which 413 forwards the packet into the IPv6 Internet. 415 4.5. Site Administration Guidance 417 Site administrators configure advertising ISATAP routers that also 418 support the DHCPv6 relay/server function to send RA messages with the 419 M flag set to 1 as an indication to clients that the stateful DHCPv6 420 address autoconfiguration services area available. If stateless 421 DHCPv6 services are also available, the RA messages also set the O 422 flag to 1. 424 Gateways and packet filtering devices of various forms are often 425 deployed in order to divide the site into separate partitions. 426 Although the purely stateful model does not involve the advertisement 427 of non-link-local IPv6 prefixes on ISATAP interfaces, alignment of 428 IPv6 prefixes used for stateful address assignment with IPv4 site 429 partitions is still recommended so that ISATAP clients can prefer 430 native IPv4 communications over ISATAP IPv6 services for 431 correspondents within their contiguous IPv4 partition. 433 For example, if the site is assigned the aggregate prefix 2001:db8: 434 0::/48, then the site administrators can assign the more-specific 435 prefixes 2001:db8:0:0::/64, 2001:db8:0:1::/64, 2001:db8:0:2::/64, 436 etc. to the different IPv4 partitions within the site. The 437 administrators can then institute a policy that prefers native IPv4 438 addresses for communications between clients covered by the same /64 439 prefix. 441 Site administrators can implement this policy implicitly by 442 configuring advertising ISATAP routers to advertise each /64 prefix 443 with both the A and L flags set to 0 as an indication that IPv4 444 should be preferred over IPv6 destinations that configure addresses 445 from the same prefix. Site administrators can instead (or in 446 addition) implement address selection policy rules [RFC3484] through 447 explicit configurations in each ISATAP client. 449 For example, each ISATAP client associated with the prefix 2001:db8: 450 0:0::/64 can add the prefix to its address selection policy table 451 with a lower precedence than the prefix ::ffff:0:0/96. In this way, 452 IPv4 addresses are preferred over IPv6 addresses from within the same 453 /64 prefix. The prefix could be added to each ISATAP client either 454 manually, or through an automated service such as a DHCP option 455 [I-D.ietf-6man-addr-select-opt]. In this way, clients will use IPv4 456 communications to reach correspondents within the same IPv4 site 457 partition, and will use IPv6 communications to reach correspondents 458 in other partitions and/or outside of the site. 460 When the PRL includes an anycast address, the client may be directed 461 to a first DHCPv6 relay/server in initial message exchanges and to a 462 different relay/server in subsequent exchanges. In order to address 463 this uncertainty, site administrators should configure DHCPv6 servers 464 to include a Server Unicast option so that clients can remain 465 associated with the same server that was reached during the initial 466 exchange. (Alternatively, the administrator could arrange for the 467 site's DHCPv6 servers to maintain a distributed database of client 468 bindings.) 470 Finally, site administrators should configure ISATAP routers to not 471 send ICMPv6 Redirect messages to inform a source client of a better 472 next hop toward the destination unless there is strong assurance that 473 the client and the next hop are within the same IPv4 site partition. 475 4.6. On-Demand Dynamic Routing 477 With respect to the reference operational scenarios depicted in 478 Figure 1, there may be use cases in which a proactive dynamic IPv6 479 routing protocol cannot be used. For example, in large enterprise 480 network deployments it would be impractical for all ISATAP routers to 481 engage in a common routing protocol instance due to scaling 482 considerations. 484 In those cases, an on-demand routing capability can be enabled in 485 which ISATAP nodes send initial packets via an advertising ISATAP 486 router and receive redirection messages back. For example, when a 487 non-advertising ISATAP router 'C' has a packet to send to a host 488 located behind non-advertising ISATAP router 'E', it can send the 489 initial packets via advertising router 'A' which will return 490 redirection messages to inform 'C' that 'E' is a better first hop. 491 Protocol details for this redirection procedure (including a means 492 for detecting whether the direct path is usable) are specified in 493 [I-D.templin-aero]. 495 4.7. Loop Avoidance 497 When no advertising ISATAP routers advertise IPv6 prefixes for SLAAC 498 purposes, no non-link-local IPv6 prefixes are assigned to ISATAP 499 router interfaces. In that case, an ISATAP router cannot mistake 500 another router for an ISATAP host due to an address that matches an 501 on-link prefix. This corresponds to the mitigation documented in 502 Section 3.2.4 of [RFC6324]. 504 Any routing loops introduced in the stateful scenario would therefore 505 be due to a misconfiguration in IPv6 routing the same as for any IPv6 506 router, and hence are out of scope for this document. 508 5. Manual Configuration 510 In addition to any SLAAC and/or DHCPv6 services, when the updates in 511 this document are employed site administrators can use manual 512 configuration to assign non-ISATAP IPv6 addresses to the ISATAP 513 interfaces of client end systems. Site administrators can also use 514 manual configuration to assign IPv6 prefixes to non-advertising 515 ISATAP routers instead of (or in addition to) using DHCPv6 prefix 516 delegation. 518 The IPv6 prefixes used for manual configuration must be distinct from 519 any prefixes used for SLAAC, however they may overlap with the 520 prefixes used for DHCPv6 as long as there is administrative assurance 521 that the same IPv6 addresses/prefixes will not be delegated by both 522 DHCPv6 and manual configuration. The manual configuration scenarios 523 and routing considerations are otherwise the same as discussed in 524 Section 4. 526 When manually configured IPv6 addresses/prefixes are used, the 527 prefixes must be covered by a shorter IPv6 prefix advertised into the 528 IPv6 routing system by one or more advertising ISATAP routers. The 529 advertising routers must further maintain stateful address mappings 530 that associate the addresses/prefixes with the ISATAP clients to 531 which the addresses/prefixes are delegated, i.e., the same as for 532 DHCPv6. 534 6. IANA Considerations 536 This document has no IANA considerations. 538 7. Security Considerations 540 In addition to the security considerations documented in [RFC5214], 541 sites that use ISATAP should take care to ensure that no routing 542 loops are enabled [RFC6324]. Additional security concerns with IP 543 tunneling are documented in [RFC6169]. 545 8. Acknowledgments 547 The following are acknowledged for their insights that helped shape 548 this work: Dmitry Anipko, Fred Baker, Brian Carpenter, Remi Despres, 549 Thomas Henderson, Philip Homburg, Lee Howard, Ray Hunter, Joel 550 Jaeggli, John Mann, Gabi Nakibly, Christoper Palmer, Hemant Singh, 551 Mark Smith, Dave Thaler, Ole Troan, Gunter Van de Velde, ... 553 9. References 555 9.1. Normative References 557 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 558 and M. Carney, "Dynamic Host Configuration Protocol for 559 IPv6 (DHCPv6)", RFC 3315, July 2003. 561 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 562 Host Configuration Protocol (DHCP) version 6", RFC 3633, 563 December 2003. 565 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 566 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 567 September 2007. 569 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 570 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 571 March 2008. 573 9.2. Informative References 575 [I-D.ietf-6man-addr-select-opt] 576 Matsumoto, A., Fujisaki, T., Kato, J., and T. Chown, 577 "Distributing Address Selection Policy using DHCPv6", 578 draft-ietf-6man-addr-select-opt-03 (work in progress), 579 February 2012. 581 [I-D.templin-aero] 582 Templin, F., "Asymmetric Extended Route Optimization 583 (AERO)", draft-templin-aero-08 (work in progress), 584 February 2012. 586 [I-D.templin-v6ops-isops] 587 Templin, F., "Operational Guidance for IPv6 Deployment in 588 IPv4 Sites using ISATAP", draft-templin-v6ops-isops-14 589 (work in progress), October 2011. 591 [RFC1687] Fleischman, E., "A Large Corporate User's View of IPng", 592 RFC 1687, August 1994. 594 [RFC3484] Draves, R., "Default Address Selection for Internet 595 Protocol version 6 (IPv6)", RFC 3484, February 2003. 597 [RFC5720] Templin, F., "Routing and Addressing in Networks with 598 Global Enterprise Recursion (RANGER)", RFC 5720, 599 February 2010. 601 [RFC6139] Russert, S., Fleischman, E., and F. Templin, "Routing and 602 Addressing in Networks with Global Enterprise Recursion 603 (RANGER) Scenarios", RFC 6139, February 2011. 605 [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security 606 Concerns with IP Tunneling", RFC 6169, April 2011. 608 [RFC6324] Nakibly, G. and F. Templin, "Routing Loop Attack Using 609 IPv6 Automatic Tunnels: Problem Statement and Proposed 610 Mitigations", RFC 6324, August 2011. 612 Author's Address 614 Fred L. Templin 615 Boeing Research & Technology 616 P.O. Box 3707 MC 7L-49 617 Seattle, WA 98124 618 USA 620 Email: fltemplin@acm.org