idnits 2.17.1 draft-ietf-ngtrans-isatap-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 31, 2002) is 7781 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2460 (ref. '1') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 1631 (ref. '4') (Obsoleted by RFC 3022) ** Obsolete normative reference: RFC 2461 (ref. '6') (Obsoleted by RFC 4861) -- Unexpected draft version: The latest known version of draft-ietf-ipngwg-addr-arch-v3 is -10, but you're referring to -11. -- Possible downref: Normative reference to a draft: ref. '9' ** Obsolete normative reference: RFC 2463 (ref. '10') (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 1981 (ref. '11') (Obsoleted by RFC 8201) ** Obsolete normative reference: RFC 2462 (ref. '12') (Obsoleted by RFC 4862) -- Obsolete informational reference (is this intentional?): RFC 3041 (ref. '21') (Obsoleted by RFC 4941) Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NGTRANS Working Group F. Templin 3 Internet-Draft Nokia 4 Expires: July 1, 2003 T. Gleeson 5 Cisco Systems K.K. 6 M. Talwar 7 D. Thaler 8 Microsoft Corporation 9 December 31, 2002 11 Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) 12 draft-ietf-ngtrans-isatap-09.txt 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at http:// 30 www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on July 1, 2003. 37 Copyright Notice 39 Copyright (C) The Internet Society (2002). All Rights Reserved. 41 Abstract 43 This document specifies an Intra-Site Automatic Tunnel Addressing 44 Protocol (ISATAP) that connects IPv6 hosts and routers within IPv4 45 sites. ISATAP treats the site's IPv4 infrastructure as a link layer 46 for IPv6 with no requirement for IPv4 multicast. ISATAP enables 47 intra-site automatic IPv6-in-IPv4 tunneling whether globally assigned 48 or private IPv4 addresses are used. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Applicability Statement . . . . . . . . . . . . . . . . . . 3 54 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 55 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 56 5. Basic IPv6 Operation on ISATAP Links . . . . . . . . . . . . 5 57 5.1 Interface Identifiers and Address Construction . . . . . . . 5 58 5.2 ISATAP Link/Interface Configuration . . . . . . . . . . . . 5 59 5.3 Dual Stack Operation and Address Configuration . . . . . . . 6 60 5.4 Tunneling Mechanisms . . . . . . . . . . . . . . . . . . . . 6 61 5.4.1 Encapsulation . . . . . . . . . . . . . . . . . . . . . . . 6 62 5.4.2 Tunnel MTU and Fragmentation . . . . . . . . . . . . . . . . 6 63 5.4.3 Handling IPv4 ICMP Errors . . . . . . . . . . . . . . . . . 7 64 5.4.4 Decapsulation . . . . . . . . . . . . . . . . . . . . . . . 7 65 5.4.5 Link-Local Addresses . . . . . . . . . . . . . . . . . . . . 7 66 5.4.6 Ingress Filtering . . . . . . . . . . . . . . . . . . . . . 7 67 6. Neighbor Discovery and Address Autoconfiguration . . . . . . 8 68 6.1 Address Resolution . . . . . . . . . . . . . . . . . . . . . 8 69 6.2 Address Autoconfiguration and Router Discovery . . . . . . . 9 70 6.2.1 Conceptual Data Structures . . . . . . . . . . . . . . . . . 9 71 6.2.2 Validity Checks for Router Advertisements . . . . . . . . . 10 72 6.2.3 Router Specification . . . . . . . . . . . . . . . . . . . . 10 73 6.2.4 Host Specification . . . . . . . . . . . . . . . . . . . . . 11 74 7. ISATAP Deployment Considerations . . . . . . . . . . . . . . 12 75 7.1 Host And Router Deployment Considerations . . . . . . . . . 12 76 7.2 Site Administration Considerations . . . . . . . . . . . . . 12 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 13 78 9. Security considerations . . . . . . . . . . . . . . . . . . 13 79 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 80 Normative References . . . . . . . . . . . . . . . . . . . . 14 81 Informative References . . . . . . . . . . . . . . . . . . . 15 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16 83 A. Major Changes . . . . . . . . . . . . . . . . . . . . . . . 17 84 B. Rationale for Interface Identifier Construction . . . . . . 18 85 C. Dynamic Per-neighbor MTU Discovery . . . . . . . . . . . . . 19 86 Intellectual Property and Copyright Statements . . . . . . . 21 88 1. Introduction 90 This document presents a simple approach that enables incremental 91 deployment of IPv6 [1] within IPv4-based [2] sites in a manner that 92 is compatible with inter-domain tunneling mechanisms, e.g., RFC 3056 93 (6to4) [18]. We refer to this approach as the Intra-Site Automatic 94 Tunnel Addressing Protocol (ISATAP). ISATAP allows dual-stack nodes 95 that do not share a physical link with an IPv6 router to 96 automatically tunnel packets to the IPv6 next-hop address through 97 IPv4, i.e., the site's IPv4 infrastructure is treated as an link 98 layer for IPv6. 100 This document specifies details for the transmission of IPv6 packets 101 over ISATAP links (i.e., automatic IPv6-in-IPv4 tunneling), including 102 an interface identifier format that embeds an IPv4 address. This 103 format supports IPv6 protocol mechanisms for address configuration as 104 well as simple link-layer address mapping. Simple validity checks 105 for received packets are given. Also specified in this document is 106 the operation of IPv6 Neighbor Discovery for ISATAP. The document 107 finally presents deployment and security considerations for ISATAP. 109 2. Applicability Statement 111 ISATAP provides the following features: 113 o treats site's IPv4 infrastructure as link layer for IPv6 using 114 automatic IPv6-in-IPv4 tunneling (i.e., no configured tunnel 115 state) 117 o enables incremental deployment of IPv6 hosts within IPv4 sites 118 with no aggregation scaling issues at border gateways 120 o requires no special IPv4 services within the site (e.g., 121 multicast) 123 o supports both stateless address autoconfiguration and manual 124 configuration 126 o supports networks that use non-globally unique IPv4 addresses 127 (e.g., when private address allocations [3] are used), but does 128 not allow the virtual ISATAP link to span a Network Address 129 Translator [4] 131 o compatible with other NGTRANS mechanisms (e.g., 6to4 [18]) 133 3. Requirements 135 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 136 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 137 document, are to be interpreted as described in [5]. 139 This document also makes use of internal conceptual variables to 140 describe protocol behavior and external variables that an 141 implementation must allow system administrators to change. The 142 specific variable names, how their values change, and how their 143 settings influence protocol behavior are provided to demonstrate 144 protocol behavior. An implementation is not required to have them in 145 the exact form described here, so long as its external behavior is 146 consistent with that described in this document. 148 4. Terminology 150 The terminology of RFC 2460 [1] applies to this document. The 151 following additional terms are defined: 153 link; on-link: 154 same definitions as ([6], section 2.1). 156 underlying link: 157 a link layer that supports IPv4 (for ISATAP), and MAY also support 158 IPv6 natively. 160 ISATAP link: 161 one or more underlying links used for tunneling. The IPv4 network 162 layer addresses of the underlying links are used as link-layer 163 addresses on the ISATAP link. 165 ISATAP interface: 166 a node's attachment to an ISATAP link. 168 ISATAP address: 169 an on-link address on an ISATAP interface and with an interface 170 identifier constructed as specified in Section 5.1 172 ISATAP router: 173 an IPv6 node that has an ISATAP interface over which it forwards 174 packets not explicitly addressed to itself. 176 ISATAP host: 177 any node that has an ISATAP interface and is not an ISATAP router. 179 5. Basic IPv6 Operation on ISATAP Links 181 ISATAP links transmit IPv6 packets via automatic tunnels using the 182 site's IPv4 infrastructure as a link layer for IPv6, i.e., the site's 183 IPv4 infrastructure is treated as a Non-Broadcast, Multiple Access 184 (NBMA) link layer. The following subsections outline basic 185 operational details for IPv6 on ISATAP links: 187 5.1 Interface Identifiers and Address Construction 189 (RFC2491 [7], section 5.1) requires companion documents to specify 190 the exact mechanism for generating interface tokens (i.e., 191 identifiers). Interface identifiers for ISATAP are compatible with 192 the EUI-64 identifier format ([8], section 2.5.1), and are 193 constructed by appending an IPv4 address on the ISATAP link to the 194 32-bit string '00-00-5E-FE'. (Appendix B includes non-normative text 195 explaining the rationale for this construction rule.) 197 Global and Local-use ISATAP addresses are constructed as follows: 199 | 64 bits | 32 bits | 32 bits | 200 +------------------------------+---------------+----------------+ 201 | global or local-use unicast | 0000:5EFE | IPv4 Address | 202 | prefix | | of ISATAP link | 203 +------------------------------+---------------+----------------+ 205 Figure 1 207 For example, the global unicast address: 209 3FFE:1A05:510:1111:0:5EFE:8CAD:8108 211 has a prefix of '3FFE:1A05:510:1111::/64' and an ISATAP interface 212 identifier with embedded IPv4 address: '140.173.129.8'. The address 213 is alternately written as: 215 3FFE:1A05:510:1111:0:5EFE:140.173.129.8 217 (Similar examples for local-use addresses are made obvious by the 218 above and with reference to the IPv6 addressing architecture 219 document.) 221 5.2 ISATAP Link/Interface Configuration 223 ISATAP Link/Interface configuration is consistent with (RFC2491 [7], 224 sections 5.1.1 and 5.1.2). 226 Using the terminology of Section 4, an ISATAP link consists of one or 227 more underlying links that support IPv4 for tunneling within a site. 228 ISATAP interfaces are configured over ISATAP links; each IPv4 address 229 assigned to an underlying link is seen as a link-layer address for 230 ISATAP. 232 5.3 Dual Stack Operation and Address Configuration 234 ISATAP uses the same specification found in ([9], section 2). That 235 is, ISATAP nodes implement "IPv6/IPv4" or "dual-stack" configurations 236 and operate with both stacks enabled. Address configuration and DNS 237 considerations are the same as for ([9], sections 2.1 and 2.2) 239 5.4 Tunneling Mechanisms 241 The common tunneling mechanisms specified in ([9], sections 3.1 242 through 3.7) are used, with the following noted specific 243 considerations: 245 5.4.1 Encapsulation 247 The specification in ([9], section 3.1) is used. Additionally, the 248 IPv6 next-hop address for packets sent on an ISATAP link MUST be an 249 ISATAP address; other packets are discarded (i.e., not encapsulated) 250 and an ICMPv6 destination unreachable indication with code 3 (Address 251 Unreachable) [10] is returned to the source. 253 5.4.2 Tunnel MTU and Fragmentation 255 The specification in ([9], section 3.2) is NOT used; the 256 specification in this section is used instead. 258 ISATAP uses automatic tunnel interfaces that may be configured over 259 multiple underlying links with diverse maximum transmission units 260 (MTUs). The minimum MTU for IPv6 interfaces is 1280 bytes ([1], 261 Section 5), but the following considerations apply when IPv4 is used 262 as a link layer for IPv6: 264 o nearly all IPv4 nodes accept unfragmented packets up to 1500 bytes 266 o sub-IPv4 layer encapsulations (e.g., VPN) may occur on some paths 268 o commonly-deployed VPNs use an MTU of 1400 bytes 270 Thus, ISATAP interfaces SHOULD use an MTU (ISATAP_MTU) of 1380 bytes 271 (1400 minus 20 bytes for IPv4 encapsulation) to maximize efficiency 272 and minimize IPv4 fragmentation. 274 ISATAP_MTU MAY be set to larger values when the encapsulator uses 275 dynamic per-neighbor MTU discovery. When larger values are used, 276 ISATAP_MTU SHOULD NOT exceed the maximum MTU of all underlying links 277 minus 20 bytes for link layer encapsulation. (Appendix C provides 278 non-normative considerations for dynamic per-neighbor MTU discovery.) 280 As with ordinary IPv6 interfaces, the network layer (IPv6) forwards 281 packets of size ISATAP_MTU or smaller to the ISATAP interface. All 282 other packets are dropped, and an ICMPv6 "packet too big" message 283 with MTU = ISATAP_MTU is returned to the source [11]. 285 ISATAP interfaces send all packets of size 1380 bytes or smaller with 286 the Don't Fragment (DF) bit NOT set in the encapsualting IPv4 header. 288 5.4.3 Handling IPv4 ICMP Errors 290 The specification in ([9], section 3.4) MAY be used. IPv4 ICMP 291 errors and ARP failures are otherwise processed as link error 292 notifications. 294 5.4.4 Decapsulation 296 The specification in ([9], section 3.6) is used. 298 5.4.5 Link-Local Addresses 300 The specification in ([9], section 3.7) is NOT used. Instead, 301 link-local addresses are formed by appending an interface identifier, 302 as defined in Section 5.1, to the prefix FE80::/64. 304 5.4.6 Ingress Filtering 306 The network layer (IPv6) destination address of a packet received on 307 an ISATAP interface is either local (i.e., matches an address 308 configured on the local IPv6 stack) or foreign. The decapsulator 309 MUST be configured with a list of IPv4 address prefixes that are 310 acceptable, i.e., an ingress filter list (default deny all). For 311 packets with foreign network layer (IPv6) destination addresses, the 312 link layer (IPv4) source address MUST be explicitly allowed by 313 ingress filtering. Packets that do not satisfy this condition are 314 silently discarded. 316 Additionally, all packets (whether foreign or local) MUST satisfy at 317 least one (i.e., one or both) of the following validity checks: 319 o the network-layer (IPv6) source address is an on-link ISATAP 320 address with an interface identifier that embeds the link-layer 321 (IPv4) source address 323 o the link-layer (IPv4) source address is in the Potential Routers 324 List (see Section 6.2.1) 326 Packets that do not satisfy the above conditions are silently 327 discarded. 329 6. Neighbor Discovery and Address Autoconfiguration 331 RFC 2491 [7] provides a general architecture for IPv6 over NBMA 332 networks, including multicast mechanisms to support host-side 333 operation of the IPv6 neighbor discovery protocol. ISATAP links most 334 closely meet the description for connectionless service found in the 335 last paragraph of ([7], section 1), i.e., ISATAP addresses provide 336 the sender with an NBMA destination address to which it can transmit 337 packets whenever it desires. Thus, the RFC 2491 multicast mechanisms 338 are not required for address resolution and not otherwise implemented 339 on ISATAP links due to traffic scaling considerations (i.e., ISATAP 340 links are unicast-only). 342 RFC 2461 [6] provides the following guidelines for non-broadcast 343 multiple access (NBMA) link support: 345 "Redirect, Neighbor Unreachability Detection and next-hop 346 determination should be implemented as described in this document. 347 Address resolution and the mechanism for delivering Router 348 Solicitations and Advertisements on NBMA links is not specified in 349 this document." 351 ISATAP links SHOULD implement Redirect, Neighbor Unreachability 352 Detection, and next-hop determination exactly as specified in [6]. 353 Address resolution and the mechanisms for delivering Router 354 Solicitations and Advertisements on ISATAP links use the 355 specifications found in this document. 357 6.1 Address Resolution 359 ISATAP addresses are resolved to link-layer addresses (IPv4) by a 360 static computation, i.e., the last four octets are treated as an IPv4 361 address. ([7], section 5.2) requires companion documents to specify 362 the format for link layer address options, however, link layer 363 address options are not needed for address resolution in ISATAP. 364 Thus, no format is specified and the following specification from 365 ([9], section 3.8) applies: 367 "This means that a sender of Neighbor Discovery packets 369 * SHOULD NOT include Source Link Layer Address options or Target 370 Link Layer Address options on the tunnel link. 372 * MUST silently ignore any received SLLA or TLLA options on the 373 tunnel link." 375 Following static address resolution, ISATAP hosts SHOULD implement 376 the reachability confirmation specifications in [6], sections 377 7.2.2-7.2.8 that apply when unicast Neighbor Solicitations (NS) are 378 used. ISATAP hosts SHOULD additionally perform Neighbor 379 Unreachability Detection (NUD) as specified in (RFC 2461 [6], section 380 7.3). ISATAP routers MAY perform the above-specified reachability 381 detection and NUD procedures, but this might not scale in all 382 environments. 384 All ISATAP nodes MUST send solicited neighbor advertisements ([6], 385 section 7.2.4). 387 ISATAP links disable Duplicate Address Detection, as permitted by 388 ([12], section 4). 390 6.2 Address Autoconfiguration and Router Discovery 392 Since NBMA multicast emulation mechanisms are not used on ISATAP 393 links, nodes will not receive unsolicited multicast Router 394 Advertisements. (RFC 2462 [12], section 5.5.2) requires that hosts 395 use stateful autoconfiguration (i.e., DHCPv6 [13]) in the absence of 396 Router Advertisements. When statelful autoconfiguration is not 397 available, nodes use alternate mechanisms (described below) for 398 router and prefix discovery. 400 6.2.1 Conceptual Data Structures 402 ISATAP nodes use the conceptual data structures Prefix List and 403 Default Router List exactly as in ([6], section 5.1). ISATAP links 404 add two new conceptual data structures "Potential Router List" and 405 "Stateful Autoconfiguration Server List". 407 A Potential Router List (PRL) and Stateful Autoconfiguration Server 408 List (SASL) is associated with every ISATAP link. The PRL provides a 409 trust basis for router validation (see security considerations). 410 Each entry in the PRL has an IPv4 address and an associated timer. 411 The IPv4 address represents a router's ISATAP interface (likely to be 412 an "advertising interface"), and is used to construct the ISATAP 413 link-local address for that interface. Similarly, each entry in the 414 SASL has an IPv4 address and associated timer. The IPv4 address 415 represents a DHCPv6 server attached to the ISATAP link, and is used 416 to construct the ISATAP link-local address for that DHCPv6 server. 418 When a node enables an ISATAP link, it first discovers IPv4 addresses 419 for the PRL and SASL. The addresses MAY be established by a DHCPv4 421 [14] option for ISATAP (option code TBD), by manual configuration, or 422 by an unspecified alternative method (e.g., DHCPv4 vendor-specific 423 option; DNS ([19]) fully-qualified domain names). 425 When DNS fully-qualified domain names are used, IPv4 addresses for 426 the PRL and SASL are discovered through a static host file or by 427 querying an IPv4-based DNS server to resolve the domain names into 428 address records (e.g., DNS 'A' resource records) containing IPv4 429 addresses. Unspecified alternative methods for domain name 430 resolution may also be used. The following notes apply when DNS 431 fully-qualified domain names are used: 433 1. Site administrators maintain domain names and IPv4 addresses for 434 the PRL and SASL for the site's ISATAP service, e.g., as address 435 records in the site's name service. Administrators may also 436 advertise the domain names in a DHCPv4 option for ISATAP. 438 2. There are no mandatory rules for the selection of domain names, 439 but administrators are encouraged to use the convention 440 "(list_name).isatap.domainname" (e.g., prl.isatap.example.com). 442 3. After initialization, nodes periodically re-initialize the PRL 443 and SASL, e.g., once per hour. When DNS is used, client DNS 444 resolvers use the IPv4 transport to resolve the names and follow 445 the cache invalidation procedures in [19] when the DNS 446 time-to-live expires. 448 6.2.2 Validity Checks for Router Advertisements 450 A node MUST silently discard any Router Advertisement messages it 451 receives that do not satisfy both the validity checks in ([6], 452 section 6.1.2) and the following additional validity check for 453 ISATAP: 455 o the network-layer (IPv6) source address is an ISATAP address and 456 embeds an IPv4 address from the PRL 458 6.2.3 Router Specification 460 Advertising ISATAP interfaces of routers behave the same as 461 advertising interfaces described in ([6], section 6.2). However, 462 periodic unsolicited multicast Router Advertisements are not used, 463 thus the "interval timer" associated with advertising interfaces is 464 not used for that purpose. 466 When an ISATAP router receives a valid Router Solicitation on an 467 advertising ISATAP interface, it replies with a unicast Router 468 Advertisement to the address of the node which sent the Router 469 Solicitation. The source address of the Router Advertisement is a 470 link-local unicast address associated with the interface. This MAY 471 be the same as the destination address of the Router Solicitation. 472 ISATAP routers MAY engage in the solicitation process described under 473 Host Specification below, e.g., if Router Advertisement consistency 474 verification ([6], section 6.2.7) is desired. 476 6.2.4 Host Specification 478 All entries in the PRL are assumed to represent active ISATAP routers 479 within the site, i.e., the PRL provides trust basis only; not 480 reachability detection. When stateful autoconfiguration is available 481 (i.e., when the SASL is non-null and at least one DHCPv6 server is 482 reachable), hosts may send unicast messages directly to the DHCPv6 483 server as specified in ([13], section 1.1). Hosts SHOULD attempt 484 stateful autoconfiguration for each entry in the SASL (i.e., until an 485 attempt succeeds) before concluding that stateful autoconfiguration 486 is unavailable. 488 When stateful autoconfiguration is unavailable, hosts MAY 489 periodically solicit information from one or more entries in the PRL 490 ("PRL(i)") by sending unicast Router Solicitation messages using the 491 IPv4 address ("V4ADDR_PRL(i)") and associated timer in the entry. 492 Hosts add the following variable to support the solicitation process: 494 MinRouterSolicitInterval 495 Minimum time between sending Router Solicitations to any router. 496 Default and suggested minimum 800,000 milliseconds (15min). 498 When a PRL(i) is selected, the host sets its associated timer to 499 MinRouterSolicitInterval and initiates solicitation following a short 500 delay as in ([6], section 6.3.7). The manner of choosing particular 501 routers in the PRL for solicitation is outside the scope of this 502 specification. The solicitation process repeats when the associated 503 timer expires. 505 Solicitation consists of sending Router Solicitations to the ISATAP 506 link-local address constructed from the entry's IPv4 address, i.e., 507 they are sent to 'FE80::0:5EFE:V4ADDR_PRL(i)' instead of 'All-Routers 508 multicast'. They are otherwise sent exactly as in ([6], section 509 6.3.7). 511 Hosts process received Router Advertisements exactly as in ([6], 512 section 6.3.4). Hosts additionally reset the timer associated with 513 the V4ADDR_PRL(i) embedded in the network-layer source address in 514 each solicited Router Advertisement received. The timer is reset to 515 either 0.5 * (the minimum value in the router lifetime or valid 516 lifetime of any on-link prefixes received in the advertisement) or 517 MinRouterSolicitInterval; whichever is longer. 519 7. ISATAP Deployment Considerations 521 7.1 Host And Router Deployment Considerations 523 For hosts, if an underlying link supports both IPv4 (over which 524 ISATAP is implemented) and also supports IPv6 natively, then ISATAP 525 MAY be enabled if the native IPv6 layer does not receive Router 526 Advertisements (i.e., does not have connection with an IPv6 router). 527 After a non-link-local address has been configured and a default 528 router acquired on the native link, the host SHOULD discontinue the 529 router solicitation process described in the host specification and 530 allow existing ISATAP address configurations to expire as specified 531 in ([6], section 5.3) and ([12], section 5.5.4). Any ISATAP 532 addresses added to the DNS for this host should also be removed. In 533 this way, ISATAP use will gradually diminish as IPv6 routers are 534 widely deployed throughout the site. 536 Routers MAY configure an interface to simultaneously support both 537 native IPv6, and also ISATAP (over IPv4). Routing will operate as 538 usual between these two domains. Note that the prefixes used on the 539 ISATAP and native IPv6 interfaces will be distinct. The IPv4 540 address(es) configured on a router's ISATAP interface(s) SHOULD be 541 added (either automatically or manually) to the site's address 542 records for ISATAP router interfaces. 544 7.2 Site Administration Considerations 546 The following considerations are noted for sites that deploy ISATAP: 548 o ISATAP links are administratively defined by a set of router 549 interfaces, a set of stateful autoconfiguration servers, and set 550 of nodes which discover those interface and server addresses Thus, 551 ISATAP links are defined by administrative (not physical) 552 boundaries. 554 o ISATAP hosts and routers can be deployed in an ad-hoc and 555 independent fashion. In particular, ISATAP hosts can be deployed 556 with little/no advanced knowledge of existing ISATAP routers, and 557 ISATAP routers can deployed with no reconfiguration requirements 558 for hosts. 560 o When stateful autoconfiguration is not available, ISATAP nodes MAY 561 periodically send unicast Router Solicitations to and receive 562 unicast Router Advertisements from to one or more members of the 563 potential router list. A well-deployed stateful autoconfiguration 564 service within the site can minimize and/or eliminate the need for 565 periodic solicitation. 567 o ISATAP nodes periodically refresh the entries on the PRL and SASL. 568 Responsible site administration can reduce the control traffic. 569 At a minimum, administrators SHOULD ensure that dynamically 570 advertised information for the site's PRL and SASL are well 571 maintained. 573 8. IANA Considerations 575 A DHCPv4 option code for ISATAP (TBD) [20] is requested in the event 576 that the IESG recommends this document for standards track. 578 9. Security considerations 580 Site administrators are advised that, in addition to possible attacks 581 against IPv6, security attacks against IPv4 MUST also be considered. 583 Responsible IPv4 site security management is strongly encouraged. In 584 particular, border gateways SHOULD implement filtering to detect 585 spoofed IPv4 source addresses at a minimum; ip-protocol-41 filtering 586 SHOULD also be implemented. 588 If IPv4 source address filtering is not correctly implemented, the 589 ISATAP validity checks will not be effective in preventing IPv6 590 source address spoofing. 592 If filtering for ip-protocol-41 is not correctly implemented, IPv6 593 source address spoofing is clearly possible, but this can be 594 eliminated if both IPv4 source address filtering, and the ISATAP 595 validity checks are implemented. 597 (RFC 2461 [6]), section 6.1.2 implies that nodes trust Router 598 Advertisements they receive from on-link routers, as indicated by a 599 value of 255 in the IPv6 'hop-limit' field. Since this field is not 600 decremented when ip-protocol-41 packets traverse multiple IPv4 hops 601 ([9], section 3), ISATAP links require a different trust model. In 602 particular, ONLY those Router Advertisements received from a member 603 of the Potential Routers List are trusted; all others are silently 604 discarded. This trust model is predicated on IPv4 source address 605 filtering, as described above. 607 The ISATAP address format does not support privacy extensions for 608 stateless address autoconfiguration [21]. However, since the ISATAP 609 interface identifier is derived from the node's IPv4 address, ISATAP 610 addresses do not have the same level of privacy concerns as IPv6 611 addresses that use an interface identifier derived from the MAC 612 address. (This issue is the same for NAT'd addresses.) 614 10. Acknowledgements 616 Some of the ideas presented in this draft were derived from work at 617 SRI with internal funds and contractual support. Government sponsors 618 who supported the work include Monica Farah-Stapleton and Russell 619 Langan from U.S. Army CECOM ASEO, and Dr. Allen Moshfegh from U.S. 620 Office of Naval Research. Within SRI, Dr. Mike Frankel, J. Peter 621 Marcotullio, Lou Rodriguez, and Dr. Ambatipudi Sastry supported the 622 work and helped foster early interest. 624 The following peer reviewers are acknowledged for taking the time to 625 review a pre-release of this document and provide input: Jim Bound, 626 Rich Draves, Cyndi Jung, Ambatipudi Sastry, Aaron Schrader, Ole 627 Troan, Vlad Yasevich. 629 The authors acknowledge members of the NGTRANS community who have 630 made significant contributions to this effort, including Rich Draves, 631 Alain Durand, Nathan Lutchansky, Karen Nielsen, Art Shelest, Margaret 632 Wasserman, and Brian Zill. 634 The authors also wish to acknowledge the work of Quang Nguyen [22] 635 under the guidance of Dr. Lixia Zhang that proposed very similar 636 ideas to those that appear in this document. This work was first 637 brought to the authors' attention on September 20, 2002. 639 Normative References 641 [1] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 642 Specification", RFC 2460, December 1998. 644 [2] Postel, J., "Internet Protocol", STD 5, RFC 791, September 645 1981. 647 [3] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and E. 648 Lear, "Address Allocation for Private Internets", BCP 5, RFC 649 1918, February 1996. 651 [4] Egevang, K. and P. Francis, "The IP Network Address Translator 652 (NAT)", RFC 1631, May 1994. 654 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 655 Levels", BCP 14, RFC 2119, March 1997. 657 [6] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 658 for IP Version 6 (IPv6)", RFC 2461, December 1998. 660 [7] Armitage, G., Schulter, P., Jork, M. and G. Harter, "IPv6 over 661 Non-Broadcast Multiple Access (NBMA) networks", RFC 2491, 662 January 1999. 664 [8] Hinden, R. and S. Deering, "IP Version 6 Addressing 665 Architecture", draft-ietf-ipngwg-addr-arch-v3-11 (work in 666 progress), October 2002. 668 [9] Gilligan, R. and E. Nordmark, "Basic Transition Mechanisms for 669 IPv6 Hosts and Routers", draft-ietf-ngtrans-mech-v2-01 (work in 670 progress), November 2002. 672 [10] Conta, A. and S. Deering, "Internet Control Message Protocol 673 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 674 Specification", RFC 2463, December 1998. 676 [11] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for 677 IP version 6", RFC 1981, August 1996. 679 [12] Thomson, S. and T. Narten, "IPv6 Stateless Address 680 Autoconfiguration", RFC 2462, December 1998. 682 [13] Droms, R., "Dynamic Host Configuration Protocol for IPv6 683 (DHCPv6)", draft-ietf-dhc-dhcpv6-28 (work in progress), 684 November 2002. 686 [14] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 687 March 1997. 689 [15] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 690 November 1990. 692 [16] Postel, J., "Internet Control Message Protocol", STD 5, RFC 693 792, September 1981. 695 [17] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, 696 June 1995. 698 Informative References 700 [18] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via 701 IPv4 Clouds", RFC 3056, February 2001. 703 [19] Mockapetris, P., "Domain names - implementation and 704 specification", STD 13, RFC 1035, November 1987. 706 [20] Droms, R., "Procedures and IANA Guidelines for Definition of 707 New DHCP Options and Message Types", BCP 43, RFC 2939, 708 September 2000. 710 [21] Narten, T. and R. Draves, "Privacy Extensions for Stateless 711 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 713 [22] Nguyen, Q., "http://irl.cs.ucla.edu/vet/report.ps", spring 714 1998. 716 [23] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, 717 September 2000. 719 Authors' Addresses 721 Fred L. Templin 722 Nokia 723 313 Fairchild Drive 724 Mountain View, CA 94110 725 US 727 Phone: +1 650 625 2331 728 EMail: ftemplin@iprg.nokia.com 730 Tim Gleeson 731 Cisco Systems K.K. 732 Shinjuku Mitsu Building 733 2-1-1 Nishishinjuku, Shinjuku-ku 734 Tokyo 163-0409 735 Japan 737 EMail: tgleeson@cisco.com 739 Mohit Talwar 740 Microsoft Corporation 741 One Microsoft Way 742 Redmond, WA> 98052-6399 743 US 745 Phone: +1 425 705 3131 746 EMail: mohitt@microsoft.com 747 Dave Thaler 748 Microsoft Corporation 749 One Microsoft Way 750 Redmond, WA 98052-6399 751 US 753 Phone: +1 425 703 8835 754 EMail: dthaler@microsoft.com 756 Appendix A. Major Changes 758 changes from version 08 to version 09: 760 o Added stateful autoconfiguration mechanism 762 o Normative references to RFC 2491, RFC 2462 764 o Moved non-normative MTU text to appendix C 766 changes from version 07 to version 08: 768 o updated MTU section 770 changes from version 06 to version 07: 772 o clarified address resolution, Neighbor Unreachability Detection 774 o specified MTU/MRU requirements 776 changes from earlier versions to version 06: 778 o Addressed operational issues identified in 05 based on discussion 779 between co-authors 781 o Clarified ambiguous text per comments from Hannu Flinck; Jason 782 Goldschmidt 784 o Moved historical text in section 4.1 to Appendix B in response to 785 comments from Pekka Savola 787 o Identified operational issues for anticipated deployment scenarios 789 o Included reference to Quang Nguyen work 791 Appendix B. Rationale for Interface Identifier Construction 793 ISATAP specifies an EUI64-format address construction for the 794 Organizationally-Unique Identifier (OUI) owned by the Internet 795 Assigned Numbers Authority (IANA). This format (given below) is used 796 to construct both native EUI64 addresses for general use and modified 797 EUI-64 format interface identifiers for IPv6 unicast addresses: 799 |0 2|2 3|3 3|4 6| 800 |0 3|4 1|2 9|0 3| 801 +------------------------+--------+--------+------------------------+ 802 | OUI ("00-00-5E"+u+g) | TYPE | TSE | TSD | 803 +------------------------+--------+--------+------------------------+ 805 Where the fields are: 807 OUI IANA's OUI: 00-00-5E with 'u' and 'g' bits (3 octets) 809 TYPE Type field; specifies use of (TSE, TSD) (1 octet) 811 TSE Type-Specific Extension (1 octet) 813 TSD Type-Specific Data (3 octets) 815 And the following interpretations are specified based on TYPE: 817 TYPE (TSE, TSD) Interpretation 818 ---- ------------------------- 819 0x00-0xFD RESERVED for future IANA use 820 0xFE (TSE, TSD) together contain an embedded IPv4 address 821 0xFF TSD is interpreted based on TSE as follows: 823 TSE TSD Interpretation 824 --- ------------------ 825 0x00-0xFD RESERVED for future IANA use 826 0xFE TSD contains 24-bit EUI-48 intf id 827 0xFF RESERVED by IEEE/RAC 829 Figure 2 831 Thus, if TYPE=0xFE, TSE is an extension of TSD. If TYPE=0xFF, TSE is 832 an extension of TYPE. Other values for TYPE (thus, other 833 interpretations of TSE, TSD) are reserved for future IANA use. 835 The above specification is compatible with all aspects of EUI64, 836 including support for encapsulating legacy EUI-48 interface 837 identifiers (e.g., an IANA EUI-48 format multicast address such as: 838 '01-00-5E-01-02-03' is encapsulated as: '01-00-5E-FF-FE-01-02-03'). 840 But, the specification also provides a special TYPE (0xFE) to 841 indicate an IPv4 address is embedded. Thus, when the first four 842 octets of an IPv6 interface identifier are: '00-00-5E-FE' (note: the 843 'u/l' bit MUST be 0) the interface identifier is said to be in 844 "ISATAP format" and the next four octets embed an IPv4 address 845 encoded in network byte order. 847 Appendix C. Dynamic Per-neighbor MTU Discovery 849 ISATAP encapsulators and decapsulators are IPv6 neighbors that may be 850 separated by multiple link layer (IPv4) forwarding hops. When 851 ISATAP_MTU is larger than 1380 bytes, the encapsulator must implement 852 a dynamic link layer mechanism to discover per-neighbor MTUs. 854 IPv4 path MTU discovery [15] relies on ICMPv4 "fragmentation needed" 855 messages, but these do not provide enough information for stateless 856 translation into ICMPv6 "packet too big" messages (see: RFC 792 [16] 857 and RFC 1812 [17], section 4.3.2.3). Additionally, ICMPv4 858 "fragmentation needed" messages can be spoofed, filtered, or not sent 859 at all by some forwarding nodes. Thus, IPv4 Path MTU discovery used 860 alone is inadequate and can result in black holes that are difficult 861 to diagnose [23]. 863 The ISATAP encapsulator may implement an alternate per-neighbor MTU 864 discovery mechanism, e.g., periodic and/or on-demand probing of the 865 IPv4 path to the decapsulator. Probing consists of sending packets 866 larger than 1380 bytes with the DF bit set in the IPv4 header. 867 Neighbor Solicitation (NS) packets with padding bytes added should be 868 used for this purpose, since successful delivery results in a 869 positive acknowledgement that the probe succeeded, i.e., in the form 870 of a Neighbor Advertisement (NA) from the decapsulator. (NB: Setting 871 the DF bit prevents decapsulators from receiving probe packets that 872 would overrun the receive buffer on an underlying link, thus no 873 maximum receive unit (MRU) is required.) 875 Implementations may choose to couple the probing process with 876 neighbor cache management procedures ([6], section 7), e.g. to 877 maintain timers, state variables and/or a queue of packets waiting 878 for probes to complete. Packets retained on the queue are forwarded 879 when probes succeed, and provide state for sending ICMPv6 "packet too 880 big" messages to the source when probes fail. Implementations may 881 choose to store per-neighbor MTU information in the IPv4 path MTU 882 discovery cache, in the ISATAP link layer's private data structures, 883 etc. 885 ICMPv4 "fragmentation needed" messages may result when a link 886 restriction is encountered but may also come from denial of service 887 attacks. Implementations should treat ICMPv4 "fragmentation needed" 888 messages as "tentative" negative acknowledgments and apply heuristics 889 to determine when to suspect an actual link restriction and when to 890 ignore the messages. IPv6 packets lost due actual link restrictions 891 are perceived as lost due to congestion by the original source, but 892 robust implementations minimize instances of such packet loss without 893 ICMPv6 "packet too big" messages returned to the sender. 895 Intellectual Property Statement 897 The IETF takes no position regarding the validity or scope of any 898 intellectual property or other rights that might be claimed to 899 pertain to the implementation or use of the technology described in 900 this document or the extent to which any license under such rights 901 might or might not be available; neither does it represent that it 902 has made any effort to identify any such rights. Information on the 903 IETF's procedures with respect to rights in standards-track and 904 standards-related documentation can be found in BCP-11. Copies of 905 claims of rights made available for publication and any assurances of 906 licenses to be made available, or the result of an attempt made to 907 obtain a general license or permission for the use of such 908 proprietary rights by implementors or users of this specification can 909 be obtained from the IETF Secretariat. 911 The IETF invites any interested party to bring to its attention any 912 copyrights, patents or patent applications, or other proprietary 913 rights which may cover technology that may be required to practice 914 this standard. Please address the information to the IETF Executive 915 Director. 917 The IETF has been notified of intellectual property rights claimed in 918 regard to some or all of the specification contained in this 919 document. For more information consult the online list of claimed 920 rights. 922 Full Copyright Statement 924 Copyright (C) The Internet Society (2002). All Rights Reserved. 926 This document and translations of it may be copied and furnished to 927 others, and derivative works that comment on or otherwise explain it 928 or assist in its implementation may be prepared, copied, published 929 and distributed, in whole or in part, without restriction of any 930 kind, provided that the above copyright notice and this paragraph are 931 included on all such copies and derivative works. However, this 932 document itself may not be modified in any way, such as by removing 933 the copyright notice or references to the Internet Society or other 934 Internet organizations, except as needed for the purpose of 935 developing Internet standards in which case the procedures for 936 copyrights defined in the Internet Standards process must be 937 followed, or as required to translate it into languages other than 938 English. 940 The limited permissions granted above are perpetual and will not be 941 revoked by the Internet Society or its successors or assignees. 943 This document and the information contained herein is provided on an 944 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 945 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 946 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 947 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 948 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 950 Acknowledgement 952 Funding for the RFC Editor function is currently provided by the 953 Internet Society.