idnits 2.17.1 draft-ietf-ngtrans-isatap-05.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 43 instances of too long lines in the document, the longest one being 11 characters in excess of 72. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 118: '...Pv4 (for ISATAP), and MAY also support...' RFC 2119 keyword, line 131: '...signed to the ISATAP link and MUST NOT...' RFC 2119 keyword, line 215: '... the ISATAP link MAY be configured ove...' RFC 2119 keyword, line 218: '...SATAP interfaces MAY be assigned one p...' RFC 2119 keyword, line 222: '...ess of each ISATAP interface SHOULD be...' (22 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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 (18 October 2002) is 7854 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) == Missing Reference: 'IPv6' is mentioned on line 111, but not defined -- Looks like a reference, but probably isn't: '9' on line 517 == Unused Reference: 'IPV4' is defined on line 615, but no explicit reference was found in the text == Unused Reference: 'IPV6' is defined on line 617, but no explicit reference was found in the text == Unused Reference: 'SIP' is defined on line 630, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2373 (ref. 'ADDR') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2374 (ref. 'AGGR') (Obsoleted by RFC 3587) ** Obsolete normative reference: RFC 2462 (ref. 'AUTO') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2461 (ref. 'DISC') (Obsoleted by RFC 4861) -- Possible downref: Non-RFC (?) normative reference: ref. 'EUI64' ** Obsolete normative reference: RFC 2463 (ref. 'ICMPv6') (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 2460 (ref. 'IPV6') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2893 (ref. 'MECH') (Obsoleted by RFC 4213) ** Obsolete normative reference: RFC 1631 (ref. 'NAT') (Obsoleted by RFC 3022) ** Obsolete normative reference: RFC 2543 (ref. 'SIP') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) -- Obsolete informational reference (is this intentional?): RFC 3041 (ref. 'PRIVACY') (Obsoleted by RFC 4941) Summary: 15 errors (**), 0 flaws (~~), 7 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 T. Gleeson 5 Cisco Systems K.K. 6 M. Talwar 7 D. Thaler 8 Microsoft Corporation 10 Expires 18 April 2003 18 October 2002 12 Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) 14 draft-ietf-ngtrans-isatap-05.txt 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with all 19 provisions of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering Task 22 Force (IETF), its areas, and its working groups. Note that other groups 23 may also distribute working documents as Internet- Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet- Drafts as reference material 28 or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 This document specifies the Intra-Site Automatic Tunnel Addressing 39 Protocol (ISATAP) that connects IPv6 hosts and routers (nodes) within 40 IPv4 sites. ISATAP is a transition mechanism that enables incremental 41 deployment of IPv6 by treating the site's IPv4 infrastructure as a 42 Non-Broadcast Multiple Access (NBMA) link layer for IPv6. ISATAP 43 mechanisms use an IPv6 interface identifier format that embeds an 44 IPv4 address - this enables automatic IPv6-in-IPv4 tunneling within a 45 site, whether the site uses globally assigned or private IPv4 46 addresses. The new interface identifier format can be used with both 47 local and global unicast IPv6 prefixes - this enables IPv6 routing 48 both locally and globally. ISATAP mechanisms introduce no impact on 49 routing table size and require no special IPv4 services (e.g., IPv4 50 multicast). 52 1. Introduction 54 This document presents a simple approach that enables incremental 55 deployment of IPv6 within IPv4-based sites in a manner that is com- 56 patible with inter-domain transition mechanisms, e.g., [6TO4]. We 57 refer to this approach as the Intra-Site Automatic Tunnel Addressing 58 Protocol, or ISATAP (pronounced: "ice-a-tap"). ISATAP allows dual- 59 stack nodes that do not share a common link with an IPv6 router to 60 automatically tunnel packets to the IPv6 next-hop address through 61 IPv4, i.e., the site's IPv4 infrastructure is treated as an NBMA link 62 layer. 64 This document specifies details for the transmission of IPv6 packets 65 over ISATAP links (i.e., automatic IPv6-in-IPv4 tunneling), including 66 a new EUI-64 [EUI64] based interface identifier [ADDR][AGGR] format 67 that embeds an IPv4 address. This format supports configuration of 68 global, site-local and link-local addresses as specified in [AUTO] as 69 well as simple link-layer address mapping. Simple validity checks for 70 received packets are given. Also specified in this document is the 71 operation of IPv6 Neighbor Discovery for ISATAP, as permitted for 72 NBMA links by [DISC]. The document finally presents deployment and 73 security considerations for ISATAP. 75 ******************************************************************** 77 PLEASE NOTE: 79 The current version of this specification embodies several opera- 80 tional issues for anticipated deployment scenarios. These issues are 81 clearly delineated in "starred" blocks such as this in the current 82 document for now. They will be resolved in a new version of the spec- 83 ification to be released in the near future. 85 ******************************************************************** 87 2. Applicability Statement 89 ISATAP provides the following features: 91 - treats site's IPv4 infrastructure as an NBMA link layer using 92 automatic IPv6-in-IPv4 tunneling (i.e., no configured tunnel state) 94 - enables incremental deployment of IPv6 hosts within IPv4 sites with 95 no aggregation scaling issues at border gateways 97 - requires no special IPv4 services within the site (e.g., multicast) 99 - supports both stateless address autoconfiguration and manual 100 configuration 102 - supports networks that use non-globally unique IPv4 addresses (e.g., 103 when private address allocations [PRIVATE] are used), but does not 104 allow the virtual ISATAP link to span a Network Address 105 Translator [NAT] 107 - compatible with other NGTRANS mechanisms (e.g., [6TO4]) 109 3. Terminology 111 The terminology of [IPv6] applies to this document. The following 112 additional terms are defined: 114 link: 115 same definition as [AUTO][DISC]. 117 underlying link: 118 a link layer that supports IPv4 (for ISATAP), and MAY also support 119 IPv6 natively. 121 ISATAP link: 122 one or more underlying links used for IPv4 tunneling. The IPv4 123 network layer addresses of the underlying links are used as 124 link-layer addresses on the ISATAP link. 126 ISATAP interface: 127 a node's attachment to an ISATAP link. 129 ISATAP prefix: 130 a prefix used to configure an address on the ISATAP interface. This 131 prefix is administratively assigned to the ISATAP link and MUST NOT 132 be duplicated on native IPv6 links. 134 ISATAP address: 135 an IPv6 address with an ISATAP prefix and an ISATAP format interface 136 identifier constructed as specified in section 4. 138 ISATAP router: 139 an IPv6 node that has an ISATAP interface over which it forwards 140 packets not explicitly addressed to itself. 142 ISATAP host: 143 any node that has an ISATAP interface and is not an ISATAP router. 145 4. Transmission of IPv6 Packets on ISATAP Links 147 ISATAP links transmit IPv6 packets via automatic tunneling using the 148 site's IPv4 infrastructure as an NBMA link layer. Automatic tunneling 149 for ISATAP uses the same mechanisms specified in [MECH,3.1-3.6], 150 i.e., IPv6 packets are automatically encapsulated in IPv4 using 'ip- 151 protocol-41' as the payload type number. 153 ******************************************************************** 155 Operational Issue #1: 157 The [MECH] document referenced above is currently undergoing a (bis) 158 revision that will likely require future changes to the above text. 160 ******************************************************************** 162 Specific considerations for ISATAP links are given below: 164 4.1. ISATAP Interface Identifier Construction 166 IPv6 unicast addresses [ADDR][AGGR] include a 64-bit interface iden- 167 tifier field in "modified EUI-64 format", based on the IEEE EUI-64 168 [EUI64] specification. (Modified EUI-64 format inverts the sense of 169 the 'u/l' bit from its specification in [EUI64], i.e., 'u/l' = 0 170 indicates local-use.) ISATAP interface identifiers are constructed by 171 prepending the 32-bit string '00-00-5E-FE' with an IPv4 address (see 172 the following section for examples). Appendix B includes text 173 explaining the historical basis for this construction rule. 175 ******************************************************************** 177 Operational Issue #2: 179 The above construction rule unnecessarily wastes bits in the inter- 180 face identifier that may be useful for other purposes. 182 ******************************************************************** 184 4.2. Stateless Autoconfiguration and Link-Local Addresses 186 ISATAP addresses are unicast addresses [ADDR,2.5] that use ISATAP 187 format interface identifiers as follows: 189 | 64 bits | 32 bits | 32 bits | 190 +------------------------------+---------------+----------------+ 191 | link-local, site-local or | 0000:5EFE | IPv4 Address | 192 | global unicast prefix | | of ISATAP link | 193 +------------------------------+---------------+----------------+ 195 Link-local, site-local, and global ISATAP addresses can be created 196 exactly as specified in [ADDR], (e.g., by auto-configuration [AUTO] 197 or manual configuration). For example, the IPv6 address: 199 3FFE:1A05:510:1111:0:5EFE:8CAD:8108 201 has a prefix of '3FFE:1A05:510:1111::/64' and an ISATAP format inter- 202 face identifier with embedded IPv4 address: '140.173.129.8'. The 203 address is alternately written as: 205 3FFE:1A05:510:1111:0:5EFE:140.173.129.8 207 The link-local and site-local variants (respectively) are: 209 FE80::0:5EFE:140.173.129.8 210 FEC0::1111:0:5EFE:140.173.129.8 212 4.3. ISATAP Link/Interface Configuration 214 A node configures an ISATAP link over one or more underlying IPv4 215 links, i.e., the ISATAP link MAY be configured over one or more link- 216 layer (IPv4) addresses. Each link-layer address 'V4ADDR_LINK' is used 217 to configure a link-local address 'FE80::0:5EFE:V4ADDR_LINK' on an 218 ISATAP interface. ISATAP interfaces MAY be assigned one per link- 219 layer address, or as a single interface for multiple link-layer 220 addresses. 222 In the former case, the address of each ISATAP interface SHOULD be 223 added to the Potential Routers List (see section 5.2.1). In the lat- 224 ter case, the interface will accept ISATAP packets addressed to any 225 of the IPv4 link-layer addresses, but will choose one as its primary 226 address, used for sourcing packets. Only this address need be repre- 227 sented in the Potential Routers List. 229 4.4. Sending Rules and Address Mapping 231 The IPv6 next-hop address for packets sent on an ISATAP link MUST be 232 an ISATAP address. Packets that do not satisfy this constraint MUST 233 be discarded and an ICMP destination unreachable indication with code 234 3 (Address Unreachable) [ICMPv6] MUST be returned. No other sending 235 rules are necessary. 237 The procedure for mapping unicast addresses into link-layer addresses 238 is to simply treat the last four octets of the ISATAP address as an 239 IPv4 address (in network byte order). No multicast address mappings 240 are specified. 242 4.5. Validity Checks for Received Packets 244 ISATAP interfaces MUST silently discard any received packets that do 245 not satisfy at least one of the following validity checks: 247 - the network-layer (IPv6) source address has a prefix configured on 248 the ISATAP interface and an ISATAP-format interface identifier that 249 embeds the link-layer (IPv4) source address, i.e., source is on-link 251 - the link-layer (IPv4) source address is in the Potential Routers List 252 (see section 5.2), i.e., previous hop is an on-link ISATAP router 254 ******************************************************************** 256 Operational Issue #3: 258 The Potential Routers List gives no router reachabilty information. 259 The second validity check above can lead to packets being accepted 260 from nodes claiming to be routers, but for which the accepting node 261 has no affiliation. 263 ******************************************************************** 265 5. Neighbor Discovery for ISATAP Links 267 Section 3.2 of [DISC] ("Supported Link Types") provides the following 268 guidelines for non-broadcast multiple access (NBMA) link support: 270 "Redirect, Neighbor Unreachability Detection and next-hop determi- 271 nation should be implemented as described in this document. Address 272 resolution and the mechanism for delivering Router Solicitations 273 and Advertisements on NBMA links is not specified in this docu- 274 ment." 276 ISATAP links SHOULD implement Redirect, Neighbor Unreachability 277 Detection, and next-hop determination exactly as specified in [DISC]. 278 Address resolution and the mechanisms for delivering Router Solicita- 279 tions and Advertisements for ISATAP links are not specified by 280 [DISC]; instead, they are specified in this document. (Note that 281 these mechanisms MAY potentially apply to other types of NBMA links 282 in the future.) 284 5.1. Address Resolution 286 Protocol addresses (IPv6) in ISATAP are resolved to link-layer 287 addresses (IPv4) by a static computation, i.e., the last four octets 288 are treated as an IPv4 address. Thus the functions and conceptual 289 data structures used by [DISC] for the purpose of address resolution 290 are not required. The conceptual "neighbor cache" described in [DISC] 291 is still needed for other functions, such as neighbor unreachability 292 detection, but it is not used for address resolution. 294 ******************************************************************** 296 Operational Issue #4.1: 298 The static computation used for address resolution on ISATAP links 299 does not trigger neighbor reachability detection as specified in 300 [DISC, 7.3.3], leading to possible black holes. 302 ******************************************************************** 304 The link-layer address option used in [DISC] is not needed. Link- 305 layer address options SHOULD NOT be sent in any Neighbor Discovery 306 packets, and MUST be silently ignored in any received Neighbor Dis- 307 covery packets. 309 5.2. Router and Prefix Discovery 311 Since the site's IPv4 infrastructure is treated as an NBMA link 312 layer, unsolicited Router Advertisements do not provide sufficient 313 means for router discovery on ISATAP links. Thus, alternate mecha- 314 nisms are required and specified below: 316 5.2.1. Conceptual Data Structures 318 ISATAP nodes use the conceptual data structures Prefix List and 319 Default Router List exactly as specified in [DISC,5.1]. ISATAP links 320 add a new conceptual data structure "Potential Router List" and the 321 following new configuration variable: 323 ResolveInterval Time between name service resolutions. 324 Default and suggested minimum: 1hr 326 A Potential Router List (PRL) is associated with every ISATAP link. 327 The PRL provides context for router discovery and a trust basis for 328 router validation (see security considerations). Each entry in the 329 PRL has an IPv4 address and an associated timer used for polling. The 330 IPv4 address represents a router's ISATAP interface (likely to be an 331 "advertising interface"), and is used to construct the ISATAP link- 332 local address for that interface. 334 When a node enables an ISATAP link, it initializes the Potential 335 Router List (PRL) for that link. Unless other information is avail- 336 able (e.g., manual address configuration, a vendor-specific DHCP 337 option, etc.) the following method (similar to the [SIP, 1.4.2] pro- 338 cedure) SHOULD be used: 340 1. The site administrator maintains address records for ISATAP 341 router interfaces, and makes these available in the site's 342 name service. Nodes attempt to find one or more addresses 343 for the PRL by querying the name service. 345 2. There are no mandatory rules on the selection of domain name 346 to be used within a site for this purpose, but administrators 347 are encouraged to use the "isatap.domainname" convention 348 (e.g., isatap.example.com), as specified in [RFC2219]. Nodes 349 can construct this domain name by prepending the label "isatap" 350 to their parent domain name, which is established by other 351 means. Nodes then query this domain name for address records 352 (e.g., DNS 'A' resource records), and initialize the PRL with 353 the IPv4 addresses in the replies. 355 3. After initialization, nodes periodically repeat the above 356 procedure every ResolveInterval seconds to update the PRL with 357 any IPv4 addresses added/deleted since the previous iteration. 358 When DNS is used, nodes MUST follow the procedures in [RFC1035] 359 regarding cache invalidation when the DNS time-to-live expires. 361 5.2.2. Validation of Router Advertisement Messages 363 A node MUST silently discard any received Router Advertisement mes- 364 sages that do not satisfy the validity checks in [DISC,6.1.2] as well 365 as the following additional validity check for ISATAP: 367 - the network-layer (IPv6) source address is derived from 368 an IPv4 address in the PRL 370 5.2.3. Router Specification 372 Advertising ISATAP interfaces of routers behave the same as advertis- 373 ing interfaces described in [DISC,6.2]. However, periodic unsolicited 374 multicast Router Advertisements are not required, thus the "interval 375 timer" associated with advertising interfaces is not used for that 376 purpose. 378 When an ISATAP router receives a valid Router Solicitation on an 379 advertising ISATAP interface, it replies with a unicast Router Adver- 380 tisement to the address of the node which sent the Router Solicita- 381 tion. The source address of the Router Advertisement is a link-local 382 unicast address associated with the interface. This MAY be the same 383 as the destination address of the Router Solicitation. ISATAP routers 384 MAY engage in the polling process described under Host Specification 385 below (e.g. if Router Advertisement consistency verification 386 [DISC,6.2.7] is desired), but this is not required. 388 5.2.4. Host Specification 390 Hosts periodically poll each entry in the PRL ("PRL(i)") by sending 391 unicast Router Solicitation messages using the IPv4 address 392 ("V4ADDR_PRL(i)") and associated timer in the entry. Hosts add the 393 following variable to support the polling process: 395 MinRouterSolicitInterval 396 Minimum time between sending Router Solicitations 397 to any router. Default and suggested minimum: 15min 399 When PRL(i) is first added to the list, the host sets its associated 400 timer to MinRouterSolicitInterval. 402 Entries are polled when they are created (following a short delay as 403 for initial solicitations [ND,6.3.7]), and when the associated timer 404 expires. 406 Polling consists of sending Router Solicitations to the ISATAP link- 407 local address constructed from the entry's IPv4 address, i.e., they 408 are sent to 'FE80::0:5EFE:V4ADDR_PRL(i)' instead of 'All-Routers mul- 409 ticast'. They are otherwise sent in the same manner described in 410 [DISC,6.3.7]. 412 When the host receives a valid Router Advertisement (i.e., one that 413 satisfies the validity checks in sections 4.5 and 5.2.2) it processes 414 them in the same manner described in [DISC,6.3.4]. The host addition- 415 ally resets the timer associated with the PRL entry that matches the 416 network-layer source address in the Router Advertisement. The timer 417 is reset to either 0.5 * (the minimum value in the router lifetime or 418 valid lifetime of any on-link prefixes advertised) or MinRouterSolic- 419 itInterval; whichever is longer. 421 ******************************************************************** 423 Operational Issue #4.2: 425 The Router and Host specifications above effectively treat the IPv4 426 path as a single IPv6 hop. The host caches link state information for 427 the hop, but the link is unidirectional (from the host to the router) 428 and subject to change due to network topology fluctuations. The 429 router caches no information, thus has no level of assurance that the 430 host will receive critical ICMPv6 messages, e.g., ICMPv6 Packet Too 431 Big. 433 ******************************************************************** 435 ******************************************************************** 437 Operational Issue #5: 439 Solutions to 4.1 and 4.2 above may impart control message overhead 440 explosion if hosts are to poll all routers in the PRL as currently 441 suggested above. 443 ******************************************************************** 445 6. ISATAP Deployment Considerations 447 6.1. Host And Router Deployment Considerations 449 For hosts, if an underlying link supports both IPv4 (over which ISA- 450 TAP is implemented) and also supports IPv6 natively, then ISATAP MAY 451 be enabled if the native IPv6 layer does not receive Router Adver- 452 tisements (i.e., does not have connection with an IPv6 router). After 453 a non-link-local address has been configured and a default router 454 acquired on the native link, the host SHOULD discontinue the 'Router 455 Polling Process' process specified in section 5.2.4 and allow exist- 456 ing ISATAP address configurations to expire as specified in 457 [DISC,5.3][AUTO,5.5.4]. In this way, ISATAP use will gradually dimin- 458 ish as IPv6 routers are widely deployed throughout the site. 460 Routers MAY configure a native link to simultaneously support both 461 native IPv6, and also ISATAP (over IPv4). Routing will operate as 462 usual between these two domains. Note that the prefixes used on the 463 ISATAP and native IPv6 interfaces will be distinct. The IPv4 464 address(es) configured on a router's ISATAP interface(s) SHOULD be 465 added (either automatically or manually) to the site's address 466 records for ISATAP router interfaces (see section 5.2.1). 468 6.2. Site Administration Considerations 470 The following considerations are noted for sites that deploy ISATAP: 472 - ISATAP links are administratively defined by a set of router 473 interfaces, and set of nodes which have those interface addresses 474 in their potential router lists. Thus, ISATAP links are defined by 475 administrative (not physical) boundaries. 477 - ISATAP hosts and routers can be deployed in an ad-hoc and independent 478 fashion. In particular, ISATAP hosts can be deployed with little/no 479 advanced knowledge of existing ISATAP routers, and ISATAP routers 480 can deployed with no reconfiguration requirements for hosts. 482 - ISATAP nodes periodically send Router Solicitations to all entries 483 in the Potential Router List. Worst-case control traffic is on the 484 order of (M x N), where 'M' is the number of routers in the Potential 485 Router List and 'N' is the total number of nodes on the ISATAP link. 486 The MinRouterSolicitInterval ([5.2.4]) bounds control traffic for 487 large numbers of nodes even in worst-case scenarios. 489 - ISATAP nodes periodically refresh the entries on the PRL, typically 490 by polling the DNS. Responsible site administration can reduce the 491 control traffic. At a minimum, administrators SHOULD ensure that 492 the site's address records for ISATAP router interfaces (see 493 section 5.2.1) are well maintained. 495 ******************************************************************** 497 Operational Issue #6: 499 Sites may enable Network Address Translators (NATs) internally, but 500 most NATs work only for UDP/IPv4 and TCP/IPv4 packets. ISATAP uses 501 IPv6/IPv4 encapsulation, and may encounter operational problems in 502 sites that deploy NATs internally. 504 ******************************************************************** 506 7. IANA considerations 508 Appendix B gives historical considerations for managing the IEEE OUI 509 assigned to IANA for EUI-64 interface identifier construction. These 510 considerations are noted and made freely available to IANA for any 511 purpose they may find useful. 513 8. Security considerations 515 Site administrators are advised that, in addition to possible attacks 516 against IPv6, security attacks against IPv4 MUST also be considered. 517 Many security considerations in [6OVER4,9] apply also to ISATAP. 519 Responsible IPv4 site security management is strongly encouraged. In 520 particular, border gateways SHOULD implement filtering to detect 521 spoofed IPv4 source addresses at a minimum; ip-protocol-41 filtering 522 SHOULD also be implemented. 524 If IPv4 source address filtering is not correctly implemented, the 525 validity checks in section 4.7 will not be effective in preventing 526 IPv6 source address spoofing. 528 If filtering for ip-protocol-41 is not correctly implemented, IPv6 529 source address spoofing is clearly possible, but this can be elimi- 530 nated if both IPv4 source address filtering, and the validity checks 531 in section 4.7 are implemented. 533 [DISC,6.1.2] implies that nodes trust Router Advertisements they 534 receive from on-link routers, as indicated by a value of 255 in the 535 IPv6 'hop-limit' field. Since this field is not decremented when ip- 536 protocol-41 packets traverse multiple IPv4 hops [MECH,3.3], ISATAP 537 links require a different trust model. In particular, ONLY those 538 Router Advertisements received from a member of the Potential Routers 539 List are trusted; all others are silently discarded (see section 540 5.2.2). This trust model is predicated on IPv4 source address filter- 541 ing, as described above. 543 ******************************************************************** 545 Operational Issue #7: 547 The above trust basis specification incurs the same issue identified 548 in "Operational Issue #3. 550 ******************************************************************** 552 The ISATAP address format does not support privacy extensions for 553 stateless address autoconfiguration [PRIVACY]. However, since the 554 ISATAP interface identifier is derived from the node's IPv4 address, 555 ISATAP addresses do not have the same level of privacy concerns as 556 IPv6 addresses that use an interface identifier derived from the MAC 557 address. 559 Acknowledgements 561 Some of the ideas presented in this draft were derived from work at 562 SRI with internal funds and contractual support. Government sponsors 563 who supported the work include Monica Farah-Stapleton and Russell 564 Langan from U.S. Army CECOM ASEO, and Dr. Allen Moshfegh from U.S. 565 Office of Naval Research. Within SRI, Dr. Mike Frankel, J. Peter Mar- 566 cotullio, Lou Rodriguez, and Dr. Ambatipudi Sastry supported the work 567 and helped foster early interest. 569 The following peer reviewers are acknowledged for taking the time to 570 review a pre-release of this document and provide input: Jim Bound, 571 Rich Draves, Cyndi Jung, Ambatipudi Sastry, Aaron Schrader, Ole 572 Troan, Vlad Yasevich. 574 The authors acknowledge members of the NGTRANS community who have 575 made significant contributions to this effort, including Rich Draves, 576 Alain Durand, Nathan Lutchansky, Art Shelest, Margaret Wasserman, and 577 Brian Zill. 579 The authors wish to acknowledge the work of Quang Nguyen [VET] under 580 the guidance of Dr. Lixia Zhang that proposed very similar ideas to 581 those that appear in this document. This work was first brought to 582 the authors' attention on September 20, 2002. 584 Finally, the authors recognize that ideas similar to those in this 585 document may have already been presented by others and wish to 586 acknowledge any other such contributions. 588 Normative References 590 [ADDR] Hinden, R., and S. Deering, "IP Version 6 Addressing 591 Architecture", RFC 2373, July 1998. (Pending approval 592 of "addr-arch-v3"). 594 [AGGR] Hinden., R, O'Dell, M., and Deering, S., "An IPv6 595 Aggregatable Global Unicast Address Format", 596 RFC 2374, July 1998. 598 [AUTO] Thomson, S., and T. Narten, "IPv6 Stateless Address 599 Autoconfiguration", RFC 2462, December 1998. 601 [DISC] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 602 Discovery for IP Version 6 (IPv6)", RFC 2461, 603 December 1998. 605 [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) 606 Registration Authority", 607 http://standards.ieee.org/regauth/oui/tutori- 608 als/EUI64.html, 609 March 1997. 611 [ICMPv6] Conta, A. and S. Deering, "Internet Control Message 612 Protocol (ICMPv6) for the Internet Protocol Version 6 613 (IPv6) Specification", RFC 2463, December 1998. 615 [IPV4] Postel, J., "Internet Protocol", RFC 791. 617 [IPV6] Deering, S., and R. Hinden, "Internet Protocol, Version 6 618 (IPv6) Specification", RFC 2460. 620 [MECH] Gilligan, R., and E. Nordmark, "Transition Mechanisms for 621 IPv6 Hosts and Routers", RFC 2893, August 2000. 623 [NAT] Egevang, K., and P. Francis, "The IP Network Address 624 Translator (NAT)", RFC 1631, May 1994. 626 [PRIVATE] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 627 and E. Lear, "Address Allocation for Private Internets", 628 RFC 1918, February 1996. 630 [SIP] Handley, M., Schulzrinne, H., Schooler, E., and 631 J. Rosenberg, "SIP: Session Initiation Protocol", 632 RFC 2543, March 1999. 634 Informative References 636 [6OVER4] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 637 Domains without Explicit Tunnels", RFC 2529. 639 [6TO4] Carpenter, B., and K. Moore, "Connection of IPv6 Domains 640 via IPv4 Clouds", RFC 3056, February 2001. 642 [IANA] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, 643 USC/Information Sciences Institute, October 1994. 645 [PRIVACY] Narten, T., R. Draves, "Privacy Extensions for Stateless 646 Address Autoconfiguration in IPv6", RFC 3041, 647 January 2001. 649 [RFC1035] Mockapetris, P., "Domain Names - Implementation and 650 Specification", RFC 1035, November 1987. 652 [RFC2219] Hamilton, M., and R. Wright, "Use of DNS Aliases for 653 Network Services", RFC 2219 (BCP), October 1997. 655 [VET] Nguyen, Quang, "Virtual Ethernet: A New Approach to 656 IPv6 Transition", http://irl.cs.ucla.edu/vet/report.ps, 657 MS Project Report, Spring 1998. 659 Authors Addresses 661 Fred L. Templin 662 Nokia 663 313 Fairchild Drive 664 Mountain View, CA, USA 665 Phone: (650)-625-2331 666 Email: ftemplin@iprg.nokia.com 668 Tim Gleeson 669 Cisco Systems K.K. 670 Shinjuku Mitsu Building 671 2-1-1 Nishishinjuku, Shinjuku-ku 672 Tokyo 163-0409, JAPAN 673 email: tgleeson@cisco.com 675 Mohit Talwar 676 Microsoft Corporation 677 One Microsoft Way 678 Redmond, WA 98052-6399 679 Phone: +1 425 705 3131 680 EMail: mohitt@microsoft.com 682 Dave Thaler 683 Microsoft Corporation 684 One Microsoft Way 685 Redmond, WA 98052-6399 686 Phone: +1 425 703 8835 687 EMail: dthaler@microsoft.com 689 APPENDIX A: Major Changes 691 changes from version 04 to version 05: 693 - Moved historical text in section 4.1 to Appendix B in 694 response to comments from Pekka Savola 696 - Identified operational issues for anticipated deployment 697 scenarios 699 - Included SRI IPR statement and contact information 701 - Included reference to Quang Nguyen work 703 changes from version 03 to version 04: 705 - Re-wrote section on Potential Router List initialization to 706 reference existing precedence in other documents 708 - several minor wording changes based on feedback from the 709 community 711 changes from version 02 to version 03: 713 - Added contributing co-authors 715 - RSs are now sent to unicast addresses rather than all-routers-multicast 717 - Brought draft into better alignment with other IPv6 718 standards-track documents 720 - Added applicability statement 722 changes from version 01 to version 02: 724 - Cleaned up text and tightened up terminology. Changed "IPv6 destination 725 address" to "IPv6 next-hop address" under "sending rules". Changed 726 definition of ISATAP prefix to include link and site-local. Changed 727 language in sections 4 and 5 729 changes from version 00 to version 01: 731 - Revised draft to require different /64 prefixes for ISATAP 732 addresses and native IPv6 addresses. Thus, a node's ISATAP 733 interface is assigned a /64 prefix that is distinct from the 734 prefixes assigned to any other interfaces attached to the 735 node - be they physical or logical interfaces. This approach 736 eliminates ISATAP-specific sending rules presented in earlier 737 draft versions. 739 - Changed sense of 'u/l' bit in the ISATAP address interface 740 identifier to indicate "local scope", since ISATAP interface 741 identifiers are unique only within the scope of the ISATAP 742 prefix. (See section 4.) 744 changes from personal draft to version 00: 746 - Title change to provide higher-level description of field of 747 use addressed by this draft. Removed other extraneous text. 749 - Major new section on automatic discovery of off-link IPv6 routers 750 when IPv6-IPv4 compatibility addresses are used. 752 APPENDIX B: Historical Interface Identifier Construction Rules 754 ISATAP specifies an [EUI64]-format address construction for the Orga- 755 nizationally-Unique Identifier (OUI) owned by the Internet Assigned 756 Numbers Authority [IANA]. This format (given below) is used to con- 757 struct both native [EUI64] addresses for general use and modified 758 EUI-64 format interface identifiers for use in IPv6 unicast 759 addresses: 761 |0 2|2 3|3 3|4 6| 762 |0 3|4 1|2 9|0 3| 763 +------------------------+--------+--------+------------------------+ 764 | OUI ("00-00-5E"+u+g) | TYPE | TSE | TSD | 765 +------------------------+--------+--------+------------------------+ 767 Where the fields are: 769 OUI IANA's OUI: 00-00-5E with 'u' and 'g' bits (3 octets) 771 TYPE Type field; specifies interpretation of (TSE, TSD) (1 octet) 773 TSE Type-Specific Extension (1 octet) 775 TSD Type-Specific Data (3 octets) 777 And the following interpretations are specified based on TYPE: 779 TYPE (TSE, TSD) Interpretation 780 ---- ------------------------- 781 0x00-0xFD RESERVED for future IANA use 782 0xFE (TSE, TSD) together contain an embedded IPv4 address 783 0xFF TSD is interpreted based on TSE as follows: 785 TSE TSD Interpretation 786 --- ------------------ 787 0x00-0xFD RESERVED for future IANA use 788 0xFE TSD contains 24-bit EUI-48 intf id 789 0xFF RESERVED by IEEE/RAC 791 Thus, if TYPE=0xFE, TSE is an extension of TSD. If TYPE=0xFF, TSE is 792 an extension of TYPE. Other values for TYPE (hence, other interpreta- 793 tions of TSE, TSD) are reserved for future IANA use. 795 The above specification is compatible with all aspects of [EUI64], 796 including support for encapsulating legacy EUI-48 interface identi- 797 fiers (e.g., an IANA EUI-48 format multicast address such as: 798 '01-00-5E-01-02-03' is encapsulated as: '01-00-5E-FF-FE-01-02-03'). 799 But, the specification also provides a special TYPE (0xFE) to indi- 800 cate an IPv4 address is embedded. Thus, when the first four octets of 801 a [ADDR]-compatible IPv6 interface identifier are: '00-00-5E-FE' 802 (note: the 'u/l' bit MUST be 0) the interface identifier is said to 803 be in "ISATAP format" and the next four octets embed an IPv4 address 804 encoded in network byte order. 806 INTELLECTUAL PROPERTY 808 SRI International has sent the following message to the IETF Execu- 809 tive Director (Steve Coya) regarding intellectual property rights. 810 (An auto-reply from Steve Coya's mailer also appears below.) Please 811 direct all inquiries regarding intellectual property rights pertain- 812 ing to this document to the contact given in the message below: 814 Date: Tue, 15 Oct 2002 15:37:47 -0700 815 To: scoya@ietf.org 816 From: Peter Marcotullio 817 Subject: Revised IPR statement 819 Dear Mr. Coya, 820 Please replace SRI's previous IPR statement for the ISATAP Draft "ISI 821 patent statement pertaining to draft-ietf-ngtrans-isatap" (by the way the 822 previous statement was mislabeled as "ISI" when it should have been "SRI 823 International") with the following: 825 SRI International Patent statement pertaining to draft-ietf-ngtrans-isatap 827 Statement for 'draft-ietf-ngtrans-isatap-04.txt': 828 ***************************************************** 829 Patent Rights Statement. SRI International has filed one or more patent 830 applications pertaining to aspects of this submission. SRI grants 831 royalty-free permission under such applications and resulting patents for 832 both commercial and non-commercial uses, for development of and compliance 833 with IETF standardization purposes. Any aspects or variants of SRI's 834 submission or intellectual property that are not included in IETF 835 standards and/or are not necessary for compliance with IETF standards may 836 require an additional license from SRI under terms to be negotiated by the 837 parties. 839 Please feel free to contact me if you have any questions or comments. 841 Thanks, 842 Peter Marcotullio 844 Please note that this revised IPR statement expands the rights that SRI is 845 granting to the IETF community. 847 ------------------------------------------------------------------------------ 848 Peter Marcotullio 849 Director, Business Development 850 Information, Telecommunications and Automation Division 851 SRI International 852 333 Ravenswood Ave. 853 Menlo Park, CA 94025 854 +1 650.859.5457 855 +1 650.859.4812 fax 856 peter.marcotullio@sri.com 857 www.sri.com 859 Date: Tue, 15 Oct 2002 18:35:46 -0400 (EDT) 860 From: Steve Coya 861 Subject: Gone again 862 X-Spam-Status: No, score=0.7 threshold=6.0 863 X-Spam-Level: x 865 Hi, this is Steve Coya's mail account. 867 Steve is out of the office and will not return until Tuesday, 868 October 22. He will NOT be able to respond to email during that 869 period. 871 I will make Steve read your message regarding "Revised IPR statement" when he 872 returns (though replies may take longer - sigh). 874 Thanks for your patience and understanding.