idnits 2.17.1 draft-ietf-ngtrans-isatap-17.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 : ---------------------------------------------------------------------------- No issues found here. 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 (January 20, 2004) is 7402 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) == Unused Reference: 'RFC2434' is defined on line 973, but no explicit reference was found in the text == Unused Reference: 'RFC2486' is defined on line 1041, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-ietf-ipv6-addr-arch-v4-00 -- Possible downref: Normative reference to a draft: ref. 'ICMPV6' ** Downref: Normative reference to an Informational draft: draft-ietf-dnsext-mdns (ref. 'LLMNR') == Outdated reference: A later version (-07) exists of draft-ietf-v6ops-mech-v2-00 ** Downref: Normative reference to an Experimental draft: draft-ietf-ipngwg-icmp-name-lookups (ref. 'NIQUERY') ** Downref: Normative reference to an Informational draft: draft-ietf-ipv6-node-requirements (ref. 'NODEREQ') ** Obsolete normative reference: RFC 1981 (Obsoleted by RFC 8201) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Downref: Normative reference to an Informational RFC: RFC 3542 -- Obsolete informational reference (is this intentional?): RFC 2309 (Obsoleted by RFC 7567) -- Obsolete informational reference (is this intentional?): RFC 2402 (Obsoleted by RFC 4302, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2406 (Obsoleted by RFC 4303, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2486 (Obsoleted by RFC 4282) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Templin 3 Internet-Draft Nokia 4 Expires: July 20, 2004 T. Gleeson 5 Cisco Systems K.K. 6 M. Talwar 7 D. Thaler 8 Microsoft Corporation 9 January 20, 2004 11 Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) 12 draft-ietf-ngtrans-isatap-17.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 other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at http:// 29 www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on July 20, 2004. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). All Rights Reserved. 40 Abstract 42 The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) connects 43 IPv6 neighbors/routers over IPv4 networks. ISATAP views the IPv4 44 network as a Non-Broadcast, Multiple Access (NBMA) link layer for 45 IPv6 and views other nodes on the network as potential IPv6 46 neighbors/routers. ISATAP interfaces support automatic tunneling 47 whether globally assigned or private IPv4 addresses are used. ISATAP 48 supports an abstraction for tunnel interface management similar to 49 the ATM Permanent/Switched Virtual Circuit (PVC/SVC) model. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Model of Operation . . . . . . . . . . . . . . . . . . . . . . 4 57 5. Node Requirements . . . . . . . . . . . . . . . . . . . . . . 4 58 6. Addressing Requirements . . . . . . . . . . . . . . . . . . . 4 59 7. Configuration and Management Requirements . . . . . . . . . . 6 60 8. Automatic Tunneling . . . . . . . . . . . . . . . . . . . . . 12 61 9. Neighbor Discovery . . . . . . . . . . . . . . . . . . . . . . 17 62 10. Other Requirements for Control Plane Signalling . . . . . . . 19 63 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 64 12. Security considerations . . . . . . . . . . . . . . . . . . . 20 65 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 66 Normative References . . . . . . . . . . . . . . . . . . . . . 21 67 Informative References . . . . . . . . . . . . . . . . . . . . 22 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24 69 A. Major Changes . . . . . . . . . . . . . . . . . . . . . . . . 25 70 B. Interface Identifier Construction . . . . . . . . . . . . . . 26 71 Intellectual Property and Copyright Statements . . . . . . . . 28 73 1. Introduction 75 This document specifies a simple mechanism called the Intra-Site 76 Automatic Tunnel Addressing Protocol (ISATAP) that connects IPv6 77 [RFC2460] neighbors/routers over IPv4 [RFC0791] networks. ISATAP 78 allows dual-stack (IPv6/IPv4) nodes to automatically tunnel packets 79 to the IPv6 next-hop address through IPv4, i.e., ISATAP sees the IPv4 80 network as a link layer for IPv6 and views other nodes on the network 81 as potential IPv6 neighbors/routers. ISATAP supports an abstraction 82 for tunnel interface management similar to the Non-Broadcast, 83 Multiple Access (NBMA) [RFC2491] and ATM Permanent/Switched Virtual 84 Circuit (PVC/SVC) [RFC2492] paradigms. 86 The main objectives of this document are to: 1) describe the 87 operational model for ISATAP, 2) specify addressing requirements, 3) 88 discuss configuration and management requirements, 4) specify 89 automatic tunneling using ISATAP, 5) specify operational aspects of 90 IPv6 Neighbor Discovery, and 6) discuss IANA; Security 91 considerations. 93 2. Requirements 95 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 96 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 97 document, are to be interpreted as described in [RFC2119]. 99 3. Terminology 101 The terminology of [RFC1122][RFC2460][RFC2461][RFC3582] applies to 102 this document. The following additional terms are defined: 104 ISATAP node: 105 a dual-stack (IPv6/IPv4) node that implements this specification. 107 ISATAP driver: 108 an ISATAP node's network driver module that provides an engine for 109 encapsulation, decapsulation and forwarding of packets between 110 tunnel interfaces and the IPv4 stack; it also implements an API 111 for tunnel interface management. 113 ISATAP server daemon: 114 an ISATAP node's process that sends/receives tunnel configuration 115 control plane messages, and configures/manages tunnel interfaces 116 via the ISATAP driver API; often will be the same server daemon 117 used for IPv6 neighbor/router discovery. 119 ISATAP interface: 120 an ISATAP node's point-to-multipoint IPv6 interface used for 121 IPv6-in-IPv4 tunneling of control plane traffic; may also be used 122 to carry data plane traffic in some deployments scenarios, e.g., 123 certain enterprise networks. 125 ISATAP interface identifier: 126 an IPv6 interface identifier with an embedded IPv4 address 127 constructed as specified in Section 6.1. 129 ISATAP address: 130 an IPv6 unicast address assigned to an ISATAP interface with an 131 on-link prefix and an ISATAP interface identifier. 133 4. Model of Operation 135 ISATAP interfaces provide a point-to-multipoint abstraction for 136 IPv6-in-IPv4 tunneling. They are commonly used as a nexus for 137 automatic configuration of point-to-point tunnels via tunnel 138 configuration control plane messages (e.g., IPv6 Neighbor Discovery 139 and other ICMPv6 messages). For each tunneled packet received, the 140 node's ISATAP driver examines a local forwarding table to determine 141 the correct interface to receive the packet after decapsulation. It 142 forwards tunnel configuration control plane messages via an ISATAP 143 interface to the node's ISATAP server daemon, and forwards data 144 messages to applications via configured tunnel interfaces based on a 145 specific match for the encapsulating IPv4 source address. 147 The ISATAP server daemon sends and receives control plane messages, 148 and configures/manages tunnels via the ISATAP driver API. Each such 149 configured tunnel provides a nexus for multiplexing one or more 150 applications between the remote and local tunnel endpoints using IPv6 151 addresses as application identifiers. Each such application 152 identifier provides a nexus for multiplexing one or more sessions. In 153 summary, each configured tunnel provides a single point-to-point 154 connection between peers that can be used to carry multiple 155 applications and multiple instances of each application. 157 5. Node Requirements 159 Nodes that use this specification implement the common functionality 160 required by [NODEREQ] as well as the additional features specified in 161 this document. 163 6. Addressing Requirements 164 6.1 ISATAP Interface Identifiers 166 ISATAP interface identifiers are constructed in Modified EUI-64 167 format as specified in ([ADDR-ARCH], section 2.5.1). They are formed 168 by appending a 32-bit IPv4 address to the 32-bit leading token 169 '0000:5EFE', then setting the universal/local ("u") bit as follows: 171 When the IPv4 address is known to be globally unique, the "u" bit is 172 set to 1 and the leading token becomes '0200:5EFE'. When the IPv4 173 address is from a private allocation or not otherwise known to be 174 globally unique, the "u" bit is set to 0 and the leading token 175 remains as '0000:5EFE'. See: Appendix B for additional non-normative 176 details. 178 6.2 ISATAP Addresses 180 Any IPv6 unicast address ([ADDR-ARCH], section 2.5) that has an 181 ISATAP interface identifier and an on-link prefix on an ISATAP 182 interface is considered an ISATAP address. ISATAP addresses are 183 constructed as follows: 185 | 64 bits | 32 bits | 32 bits | 186 +------------------------------+---------------+----------------+ 187 | prefix | 000[0/2]:5EFE | IPv4 Address | 188 +------------------------------+---------------+----------------+ 190 6.3 Multicast/Anycast 192 ISATAP interfaces recognize a node's required IPv6 multicast/anycast 193 addresses ([ADDR-ARCH], section 2.8). 195 Section 8.2 discusses encapsulation for multicast/anycast packets. 197 6.4 Source/Target Link Layer Address Options 199 Source/Target Link Layer Address Options ([RFC2461], section 4.6.1) 200 for ISATAP have the following format: 202 +-------+-------+-------+-------+-------+-------+-------+--------+ 203 | Type |Length | 0 | 0 | IPv4 Address | 204 +-------+-------+-------+-------+-------+-------+-------+--------+ 206 Type: 207 1 for Source Link-layer address. 208 2 for Target Link-layer address. 210 Length: 211 1 (in units of 8 octets). 213 IPv4 Address: 214 A 32 bit IPv4 address, in network byte order ([RFC2223bis], 215 section 3.4). 217 7. Configuration and Management Requirements 219 7.1 Network Management 221 ISATAP nodes MAY support network management; ISATAP nodes that 222 support network management SHOULD support the following MIBs: 223 [FTMIB][IPMIB][TUNNELMIB]. The configuration objects cited throughout 224 the remainder of this document were selected to match the names of 225 MIB objects. ISATAP nodes that do not support network management MAY 226 choose their own local representation of these objects. 228 7.2 ISATAP Driver API 230 The ISATAP driver provides an API for tunnel interface configuration 231 and management that may be accessed by processes running on the 232 ISATAP node, e.g., startup scripts, manual command line entry, kernel 233 processes, ISATAP server daemons, etc. Access MUST be restricted to 234 privileged users and applications. The API provides the following 235 primitives; operational details are given in the subsections that 236 follow: 238 'TUNNEL_CREATE': 239 creates a tunnel interface. Takes as parameters a tunnel 240 encapsulation method, parameters for setting read-write objects 241 for the tunnel, and a list of receive addresses to initialize a 242 forwarding entry in the system's ifRcvAddressTable. Returns an 243 index for the new tunnel interface, or a failure code. 245 'TUNNEL_DELETE': 246 deletes an existing tunnel interface. Takes as parameter an 247 index of the tunnel interface to be deleted. Returns success 248 or a failure code. 250 'TUNNEL_MODIFY': 251 adds or deletes attributes for an existing tunnel interface, and 252 its corresponding forwarding entry in the ifRcvAddressTable. Takes 253 the same list of parameters as for TUNNEL_CREATE, plus a flag that 254 denotes the operation (i.e., "add" or "delete"). Returns success 255 or a failure code. 257 'TUNNEL_DUP': 258 duplicates an existing tunnel interface. Takes as parameter the 259 index of the tunnel interface to be duplicated. Returns an index 260 for the newly-created tunnel interface, or a failure code. 262 'TUNNEL_GET': 263 copies configuration attributes from system table entries 264 associated with the specified tunnel interface into a user's 265 buffer. Takes as parameter an index of a tunnel interface. 266 Returns the number of system table entry data bytes written 267 into the application's buffer or a failure code. 269 7.2.1 TUNNEL_CREATE 271 ISATAP drivers implement a 'TUNNEL_CREATE' primitive that provides a 272 means for configuring the 'tunnelIfEncapsMethod', all read-write 273 objects associated with the 'tunnelIfEntry', and a list of receive 274 addresses for the tunnel which consist of an IPv4 address and an 275 index for the interface to which the address is assigned (i.e,. an 276 IPv4 address-to-interface mapping). 278 When a process on the ISATAP node issues 'TUNNEL_CREATE' primitive, 279 it includes a parameter for configuring the 'tunnelIfEncapsMethod' 280 object, and MAY include parameters for configuring other read-write 281 objects in the 'tunnelIfEntry'. It MAY also include one or more 282 receive address parameters. (Any required configuration parameters 283 not included in the 'TUNNEL_CREATE' primitive are to be issued in a 284 subsequent 'TUNNEL_MODIFY' primitive.) 285 When the ISATAP driver processes a 'TUNNEL_CREATE' primitive, it 286 creates an entry in the 'tunnelInetConfigTable', which results in the 287 simultaneous creation of a 'tunnelIfEntry' in the 'tunnelIfTable' and 288 an 'ifEntry' in the appropriate 'ifTable'. Next, it sets the 289 'tunnelIfEncapsMetod' object to the 'IANAtunnelType' specified by the 290 primitive, and sets any other "read-write" objects in the 291 'tunnelIfEntry' based on parameters included. 293 After configuring the 'tunnelIfEntry', the driver uses each receive 294 address parameter included to locate a preferred 'ipAddressEntry' in 295 the system's 'ipAddressTable'. It then creates an entry for the new 296 tunnel interface in the 'ifRcvAddressTable' that includes the list of 297 selected 'ipAddressEntry's, 'tunnelLocalInetAddress', 298 'tunnelRemoteInetAddress', 'tunnelIfEncapsMethod', and the 'ifIndex' 299 for the tunnel interface. 301 After performing the above actions, the ISATAP driver returns either 302 an interface index for the newly-created tunnel interface or a 303 failure code. 305 7.2.2 TUNNEL_DELETE 307 ISATAP drivers implement a 'TUNNEL_DELETE' primitive that provides a 308 means for deleting all table entries associated with a tunnel 309 interface. 311 When an ISATAP node's process issues a 'TUNNEL_DELETE' primitive, it 312 includes an index for the tunnel interface returned via a previous 313 'TUNNEL_CREATE' or 'TUNNEL_DUP' primitive. 315 When the ISATAP driver processes a 'TUNNEL_DELETE' primitive, it 316 locates the 'tunnelInetConfigEntry' for the tunnel interface based on 317 the interface index parameter and deletes the entry from the 318 'tunnelInetConfigTable'. This has the result of simultaneously 319 deleting the 'tunnelIfEntry' and 'ifEntry' from their respective 320 tables. The driver also removes the corresponding forwarding table 321 entry for the tunnel interface from the 'ifRcvAddressTable'. 323 After performing the above actions, the ISATAP driver returns either 324 success or a failure code. 326 7.2.3 TUNNEL_MODIFY 328 ISATAP drivers implement a 'TUNNEL_MODIFY' primitive that provides a 329 means for modifying all read-write objects associated with the 330 'tunnelIfEntry' and for adding or deleting entries from the list of 331 receive addresses for the tunnel. The primitive also provides a flag 332 for specifying whether the desired operation is "add" or "delete". 334 (For vector objects, the "add"/"delete" operations have the meaning 335 intended by their names; for scalar objects, the ISATAP driver 336 interprets an "add" operation as: "change to new value" and a 337 "delete" operation as: "reset to default".) 339 When an ISATAP node's process issues a 'TUNNEL_MODIFY' primitive, it 340 includes an index for the tunnel interface returned via a previous 341 'TUNNEL_CREATE' or 'TUNNEL_DUP' primitive, and also includes a flag 342 that specifies "add" or delete". It MAY include one or more parameter 343 for configuring read-write objects in the 'tunnelIfEntry' and MAY 344 also include one or more receive address (formatted as for 345 'TUNNEL_CREATE'). 347 When the ISATAP driver processes a 'TUNNEL_MODIFY' primitive, it 348 locates the correct 'tunnelIfEntry' for the interface index parameter 349 and modifies objects for the entry based on any included parameters. 350 If one or more receive address parameters are included, the driver 351 also adds or deletes receive addresses from the forwarding table 352 entry in the 'ifRcvAddressTable' corresponding to the 353 'tunnelIfEntry'. If no parameters are included, the result is a 354 NO-OP. 356 After performing the above actions, the ISATAP driver returns either 357 success or a failure code. 359 7.2.4 TUNNEL_DUP 361 ISATAP drivers implement a 'TUNNEL_DUP' primitive that creates a new 362 tunnel interface by duplicating a set of system table entries from an 363 existing tunnel interface. 365 When a user application or a system process issues a 'TUNNEL_MODIFY' 366 primitive, it includes an index for the tunnel interface to be 367 duplicated from a previous 'TUNNEL_CREATE' or 'TUNNEL_DUP' primitive. 369 When the ISATAP driver processes a 'TUNNEL_DUP' primitive, it creates 370 a new entry in the 'tunnelInetConfigTable' exactly as for 371 'TUNNEL_CREATE' (see: Section 7.2.1). Next, it locates the 372 'tunnelIfEntry' and 'ifEntry' for the tunnel interface to be 373 duplicated and copies all attributes from those objects into the 374 newly-created 'tunnelIfEntry' and 'ifEntry'. The driver also creates 375 a duplicate forwarding table entry in the 'ifRcvAddressTable' using 376 the existing entry identified by the interface index parameter as a 377 prototype, then sets the newly-created forwarding entry's index to 378 the 'ifIndex' for the newly-created tunnel interface. 380 After performing the above actions, the ISATAP driver returns either 381 an interface index for the newly-created tunnel interface or a 382 failure code. 384 7.2.5 TUNNEL_GET 386 To aid network administrators, ISATAP drivers SHOULD implement a 387 'TUNNEL_GET' primitive that returns the current configuration of all 388 tables in the system associated with the specified tunnel interface. 390 When a user application issues a 'TUNNEL_GET' primitive, it includes 391 an index for a tunnel interface from a previous 'TUNNEL_CREATE' or 392 'TUNNEL_DUP' primitive, a pointer to a character buffer to receive 393 the configuration information, and an integer indicating the 394 available space in the buffer. 396 When the ISATAP driver processes a 'TUNNEL_GET' primitive, it 397 prepares a character string that includes the concatenation of the 398 'tunnelIfEntry' and the 'ifRcvAddressTable' entry for the tunnel 399 interface identified by the index parameter. (The 'ifEntry' is not 400 concatenated, since its contents may be examined via primitives from 401 other APIs.) Next, the driver copies the character string to the 402 server daemon's character buffer up to the specified available buffer 403 space. 405 After performing the above actions, the ISATAP driver returns either 406 the number of bytes copied or a failure code (to include a code that 407 indicates "operation not supported"). 409 7.3 ISATAP Interface Configuration 411 ISATAP interfaces are normally configured by an ISATAP node's system 412 startup scripts or via manual configuration, but may also be created 413 by a dynamic process. When a node creates (or later modifies) an 414 ISATAP interface, it assigns to the interface one or more receive 415 address that consists of an IPv4 address and an index for the 416 interface to which the address is assigned (i.e,. an IPv4 417 address-to-interface mapping). Each receive address assigned MUST 418 represent a mapping for the same site (or, MUST represent a mapping 419 that is routable on the global Internet), i.e., the receive addresses 420 assigned to a single tunnel interface MUST NOT span multiple sites. 422 ISATAP nodes issue 'TUNNEL_CREATE' and 'TUNNEL_MODIFY' primitives for 423 ISATAP interfaces the same as for any tunnel interface; 424 'TUNNEL_CREATE' primitives include a parameter to set 425 'tunnelIfEncapsMethod' to an 'IANATunnelType' code for "isatap". A 426 'TUNNEL_CREATE' or 'TUNNEL_MODIFY' primitive that includes parameters 427 to set 'tunnelIfLocalInetAddress' to an IPv4 address that will be 428 used as one of the interface's receive addresses, and 429 'tunnelIfRemoteInetAddress' to 0.0.0.0 to denote wildcard match for 430 remote tunnel endpoints SHOULD be issued before the IPv6 interface 431 associated with the tunnel interface is enabled (see below). 433 When an ISATAP interface is created, the ISATAP driver also creates 434 an 'ipv6InterfaceEntry' as the companion 'ifEntry' to the 435 'tunnelIfEntry'. After setting the required objects in the 436 'tunnelIfEntry' (see above), the ISATAP node configures objects in 437 the 'ipv6InterfaceEntry' for an ISATAP interface the same as for any 438 IPv6 interface. For ISATAP interfaces (and other tunnel interfaces 439 that use IPv4 as a link layer for IPv6 ), the node sets the 440 'ipv6InterfaceType' object to "tunnel". Next, the node sets the 441 'ipv6InterfacePhysicalAddress' object to an IPv4 address that will be 442 used as one of the tunnel interface's receive addresses; this object 443 MUST be formatted as a 4-octet entity containing an IPv4 address in 444 network byte order ([RFC2223bis], section 3.4). The node next sets 445 the 'ipv6ScopeZoneIndexLinkLocal' object to a zone index identifier 446 that denotes the site for which the tunnel interface's receive 447 addresses are valid. Finally, the node configures all other required 448 read-write parameters in the 'ipv6InterfaceEntry' as for any IPv6 449 interface, and sets 'ipv6InterfaceAdminStatus' to "up". 451 After configuring the ISATAP interface, the node sets the interface's 452 'ipv6InterfaceForwarding' object (and, if necessary, the node's 453 'ip6Forwarding' object) to "forwarding". The node also creates an 454 'ipv6RouterAdvertEntry' in the 'ipv6RouterAdvertTable' and sets the 455 'ipv6RouterAdvertIfIndex' object to the same value as 456 'ipv6InterfaceIfIndex'. Objects in the 'ipv6RouterAdvertEntry' for an 457 ISATAP interface are configured as for any IPv6 router, however 458 'ipv6RouterAdvertLinkMTU' SHOULD NOT be set to a value other than 0 459 unless the ISATAP driver will monitor the IPv4 reassembly cache and 460 report fragmentation of tunneled packets to the source by sending 461 IPv6 Router Advertisements with MTU options (see: Section 8.3). 462 Configuration of objects relating to IPv6 forwarding is normally 463 managed by the ISATAP server daemon. 465 7.4 Dynamic Creation of Configured Tunnels 467 Configured tunnels are normally created through ISATAP driver API 468 calls issued by an ISATAP server daemon in dynamic response to a 469 tunnel creation request. Configured tunnel interfaces are created as 470 for ISATAP interfaces (see: Section 7.3), except that the 471 'tunnelIfRemoteInetAddress' for the new entry is normally set to a 472 specific IPv4 address for a remote node at the far end of the tunnel, 473 i.e., configured tunnels are normally configured as point-to-point. 474 As for ISATAP interfaces, configured tunnels MUST NOT select a list 475 of receive address mappings that span multiple sites. 477 Processes that create configured tunnels may find the 'TUNNEL_DUP' 478 primitive useful (and, in some cases essential) for reducing 479 administrative complexity. An ISATAP interface may be used as the 480 prototype for the 'TUNNEL_DUP' primitive; the configured tunnel 481 interface inherits the attributes of the ISATAP interface, including 482 the forwarding table entry in the system's 'ifRecvAddressTable'. 483 After creating a configured tunnel via the 'TUNNEL_DUP' primitive, 484 the process uses the 'TUNNEL_MODIFY' primitive to modify specific 485 attributes. 487 7.5 Reconfigurations Due to IPv4 Address Changes 489 When an 'ipAddressEntry' becomes deprecated (e.g., when an IPv4 490 address is removed from an IPv4 interface) the 'ipAddressEntry' MUST 491 be removed from all forwarding entries in the 'ifRcvAddressTable' 492 that referenced it. Also, all 'tunnelIfEntry's that used 493 'ipAddressAddr' as 'tunnelIfLocalInetAddress' and 494 'ipv6InterfaceEntry's that used 'ipAddressAddr' as 495 'ipv6InterfacePhysicalAddress' MUST select a different IPv4 address 496 for those objects from their remaining list of receive addresses. 497 Methods for triggering the mandatory changes are implementor's 498 choice. 500 When a new IPv4 address is added to an IPv4 interface, the node MAY 501 add the new 'ipAddressEntry' to the list of receive addresses for 502 forwarding entries in 'ifRcvAddressTable', and MAY set 503 'tunnelIfLocalInetAddress' and/or 'ipv6InterfacePhysicalAddress' for 504 interfaces referenced by the updated forwarding entries to the new 505 address. 507 8. Automatic Tunneling 509 ISATAP nodes use the basic tunneling mechanisms specified in [MECH]. 510 The following additional specifications are used for ISATAP: 512 8.1 Encapsulation 514 The ISATAP driver is responsible for inserting the outermost IPv4 515 encapsulating header for all tunneled packets. Tunnel interfaces that 516 use various encapsulation methods (e.g., 6over4 [RFC2529], 6to4 517 [RFC3056], teredo, IP encapsulation within IP [RFC2003], minimal 518 encapsulation within IP [RFC2004], basic IPv6-in-IPv4 encapsulation 519 [MECH], ISATAP encapsulation itself, etc.) can all be configured as 520 encapsulation clients of the ISATAP driver. 522 The ISATAP driver performs AH [RFC2402] and ESP [RFC2406] processing 523 for tunnels that use IPsec, and may also perform header compression 524 prior to encapsulation. 526 8.2 Multicast/Anycast 528 ISATAP interfaces tunnel only those packets with IPv6 multicast/ 529 anycast destinations to include a node's required multicast/anycast 530 addresses, the 'All_DHCP_Relay_Agents_and_Servers' and 531 'All_DHCP_Servers' multicast addresses [RFC3315] and multicast 532 addresses discovered via MLD [RFC2710]. Packets with unrecognized 533 IPv6 multicast/anycast destinations are silently dropped. 535 ISATAP interfaces automatically tunnel IPv6 multicast packets with 536 the 'All_DHCP_Relay_Agents_and_Servers' and 'All_DHCP_Servers' using 537 the IPv4 'all hosts' broadcast address (i.e., 0xffffffff broadcast 538 address) as the destination address in the encapsulating IPv4 header 539 under the assumption that DHCPv6 servers will be co-located with 540 DHCPv4 servers. 542 For other IPv6 multicast destinations, ISATAP interfaces 543 automatically tunnel packets using a mapped Organization-Local Scope 544 IPv4 multicast address ([RFC2529], section 6) as the destination 545 address in the encapsulating IPv4 header. ISATAP nodes join the 546 Organization-Local Scope IPv4 multicast groups required to support 547 IPv6 Neighbor Discovery ([RFC2529], Appendix A) on interfaces that 548 may receive IPv4 packets to be forwarded to an ISATAP interface. 550 NOTE: When the ISATAP node enables one or more 6over4 interfaces 551 [RFC2529], the 6over4 interfaces MAY be used (i.e., instead of ISATAP 552 interfaces) for sending and receiving multicast packets. 554 8.3 Tunnel MTU and Fragmentation 556 The specification in ([MECH], section 3.2) is not used; the 557 specification in this section is used instead: 559 ISATAP interfaces set a static MTU of 1280 bytes, i.e., the minimum 560 MTU for IPv6 interfaces ([RFC2460], section 5) and do not set the 561 Don't Fragment bit in the encapsulating IPv4 headers of tunneled 562 packets. ISATAP interfaces MAY provide a configuration knob for 563 setting a larger MTU, but larger MTUs MUST NOT be configured other 564 than for certain constrained deployments, e.g., in some enterprise 565 networks). Interfaces that may receive IPv4 packets to be forwarded 566 to an ISATAP interface SHOULD configure an Effective MTU to Receive 567 (EMTU_R) [RFC1122], section 3.3.2) of at least 1500 bytes, i.e., they 568 SHOULD be able to reassemble IPv4 packets of 1500 bytes or larger. 570 1280 bytes was chosen as the IPv6 interface minimum MTU [DEERING97] 571 to allow extra room for link layer encapsulations without exceeding 572 the Ethernet MTU of 1500 bytes, i.e., the practical physical cell 573 size of the Internet. The 1280 byte MTU provides a fixed upper bound 574 for the size of IPv6 packets/fragments with a maximum 575 store-and-forward delay budget of ~1 second assuming worst-case link 576 speeds of ~10Kbps [RFC3150], thus allowing a convenient value for use 577 in reassembly buffer timer settings. Finally, the 1280 byte MTU 578 allows transport connections (e.g., TCP) to configure a large-enough 579 maximum segment size for improved performance even if the IPv4 580 interface that will send the tunneled packets uses a smaller MTU. 582 When the size of the IPv6 destination's receive buffer is known, 583 applications MAY send IPv6 packets up to that size using IPv6 584 fragmentation (or, fragmentation via an alternate form of 585 encapsulation) with a maximum fragment size that is no larger than 586 the minimum of the MTU of the IPv4 interface used for tunneling and 587 1280 bytes. Even so, IPv4 fragmentation MAY still occur along some 588 paths; in particular, since the minimum IPv4 fragment size is only 8 589 bytes ([RFC0791], section 2), middleboxes with unusual 590 implementations of IPv4 fragmentation could shatter the tunneled 591 packets into as many as 187 IPv4 fragments to accommodate a 1500 byte 592 IPv4 packet. Such sustained bursts of small packets could result in 593 poor performance due to increased loss probability on paths with 594 non-negligible packet loss due to, e.g., link errors, congested 595 router queues, etc. 597 Therefore, ISATAP nodes that anticipate or experience poor 598 performance along some paths MAY choose to adaptively vary the 599 maximum size for the packets/fragments they send. For example, 600 implementations may choose to employ a "fragment size slow start" 601 scheme that begins with as little as 8 bytes (i.e., the minimum IPv4 602 fragment size) and varies the size of the fragments using, e.g., an 603 additive-increase, multiplicative-decrease strategy to determine the 604 size that yields the best performance. The process can be made to 605 converge more quickly when next-hop IPv6 routers are configured to 606 send Router Advertisements with MTU options when they experience IPv4 607 fragmentation, since the sender is made aware that fragmentation is 608 occurring, and the MTU option can be used to return the size of the 609 largest IPv4 fragment observed which may help the sender determine 610 the optimal fragment size. 612 Since many nodes are expected to implement this specification, an 613 overall increase in small packets in the Internet may occur as more 614 nodes with tunnel interfaces implement schemes such as the one 615 described above to avoid IPv4 fragmentation-related performance 616 issues. For this reason, network equipment manufacturers and network 617 administrators are encouraged to observe the Recommendations on Queue 618 Management and Congestion Avoidance in the Internet [RFC2309]. In 619 particular, byte mode queue averaging for RED is encouraged. 621 With reference to the above, it is RECOMMENDED that ISATAP nodes use 622 adaptive techniques to minimize IPv4 fragmentation and use IPv6 623 fragmentation/reassembly (or, fragmentation/reassembly via an 624 alternate form of encapsulation) to manage the size of the tunneled 625 packets they send. It is also RECOMMENDED that ISATAP nodes monitor 626 the IPv4 reassembly cache in order to give early indications of IPv4 627 network fragmentation by sending Router Advertisements with MTU 628 options to the source of the IPv4 fragments. The MTU options should 629 include a value to indicate the size of the largest packet that can 630 be expected to arrive without incurring IPv4 fragmentation. Finally, 631 it is RECOMMENDED that ISATAP nodes set small timeout values, e.g. 1 632 second, for IPv4 reassembly of tunneled packets. 634 8.4 Handling IPv4 ICMP Errors 636 ISATAP interfaces SHOULD process ARP failures and persistent ICMPv4 637 errors as link-specific information indicating that a path to a 638 neighbor may have failed ([RFC2461], section 7.3.3). 640 8.5 Link-Local Addresses 642 The specification in ([MECH], section 3.7) is not used; the 643 specification in Section 6.1 of this document is used instead. 645 8.6 Neighbor Discovery over Tunnels 647 The specification in ([MECH], section 3.8) is not used; the 648 specification in Section 9 of this document is used instead. 650 8.7 Decapsulation/Filtering 652 ISATAP nodes arrange for the ISATAP driver to received all tunneled 653 packets that use an IPv4 header as the outermost layer of 654 encapsulation. Examples include ip-protocol-41 (6to4, 6over4, isatap, 655 etc.), ip-protocol-4 (IP encapsulation within IP, minimal 656 encapsulation within IP, etc.), UDP port 3544 (teredo, etc.) and 657 others. The ISATAP driver determines the correct tunnel interface to 658 receive each packet via a lookup in the 'ifRcvAdddressTable' for the 659 packet's IPv4 source address, destination address, an index for the 660 receiving IPv4 interface and the type of encapsulation. Packets for 661 which the correct tunnel interface cannot be determined are silently 662 discarded. 664 After determining the correct tunnel interface, the ISATAP driver 665 verifies that the packet's link-layer (IPv4) source address is 666 correct for the network-layer (IPv6) source address. For configured 667 tunnels, the IPv4 and IPv6 source addresses can be checked directly 668 against the configured tunnel's addresses. For ISATAP interfaces, the 669 packet's link-layer source address is correct if one (or more) of the 670 following are true: 672 o the network-layer source address is an ISATAP address that embeds 673 the link-layer source address in its interface identifier. 675 o the network-layer source address is an IPv6 neighbor on an 676 interface that has the same 'ipv6ScopeZoneIndexLinkLocal' as the 677 receiving ISATAP interface. 679 o the link-layer source address is a member of the Potential Router 680 List (see: Section 9.1). 682 Packets for which the link-layer source address is incorrect are 683 discarded and, if permitted by the current status of ICMPv6 message 684 rate limiting parameters [ICMPV6], section 2.4, paragraph f), an 685 ICMPv6 Destination Unreachable message SHOULD be generated and sent 686 to the IPv6 source in the inner header of the encapsulated packet. 687 The error message SHOULD include only enough bytes from the invoking 688 packet to convey the IPv6 header information, i.e., it SHOULD NOT 689 include up to the minimum IPv6 MTU. 691 After determining the correct tunnel interface to receive the packet, 692 the ISATAP driver examines the IPv6 and IPv4 source addresses to 693 determine whether a rewrite is required. If the IPv6 source address 694 is an ISATAP address with the 'u/l' and 'g' bits set to 0 (see: 695 Section 6.1), and the IPv4 source address does not match the IPv4 696 address encoded in the ISATAP interface identifier, the ISATAP driver 697 copies the IPv4 source address over the IPv4 address embedded in the 698 IPv6 address and sets the 'u/l' bit to 1. Other forms of rewrites 699 (e.g., rewrites for multicast rendezvous points based on the 'u' and 700 'g' bit) MAY be specified in other documents. 702 Next, the ISATAP driver discards the encapsulating IPv4 header and 703 locates any existing host-pair information, e.g., via the IPv6 Flow 704 Label [FLOW]. Then: 706 o If header compression is indicated, the packet's inner header(s) 707 are reconstituted. 709 o If a security association is indicated, AH [RFC2402] or ESP 710 [RFC2406] processing is applied. 712 o If the packet is a fragment, it is placed in a buffer for 713 reassembly. The buffer may be, e.g., the IPv6 reassembly cache, an 714 application's own data buffer [RFC3542], etc. 716 Finally, when a whole packet has been received, it is delivered to 717 the correct tunnel interface. If there is clear evidence that 718 reassembly of a fragmented packet has stalled, an ICMPv6 "packet too 719 big" message [RFC1981] is sent to the packet's source address 720 (subject to ICMPv6 rate-limiting) with an MTU value indicating a size 721 that is likely to incur successful reassembly. 723 9. Neighbor Discovery 725 ISATAP nodes use the neighbor discovery mechanisms specified in 726 [RFC2461] along with securing mechanisms such as [SEND] to create/ 727 change neighbor cache entries and to provide control plane signalling 728 for automatic tunnel configuration. ISATAP interfaces also implement 729 the following specifications: 731 9.1 Conceptual Model Of A Host 733 To the list of Conceptual Data Structures ([RFC2461], section 5.1), 734 ISATAP interfaces add: 736 Potential Router List 737 A set of entries about potential routers; used to support the 738 mechanisms specified in Section 9.2.2.1. Each entry ("PRL(i)") 739 has an associated timer ("TIMER(i)"), and an IPv4 address 740 ("V4ADDR(i)") that represents a router's advertising ISATAP 741 interface. 743 9.2 Router and Prefix Discovery 745 9.2.1 Router Specification 747 As permitted by ([RFC2461], section 6.2.6), the ISATAP server daemon 748 SHOULD send unicast Router Advertisement messages to the soliciting 749 node's address when the solicitation's source address is not the 750 unspecified address. 752 9.2.2 Host Specification 754 9.2.2.1 Host Variables 756 To the list of host variables ([RFC2461], section 6.3.2), ISATAP 757 interfaces add: 759 PrlRefreshInterval 760 Time in seconds between successive refreshments of the PRL after 761 initialization. It SHOULD be no less than 3600 seconds. The 762 designated value of all 1's (0xffffffff) represents infinity. 764 Default: 3600 seconds 766 MinRouterSolicitInterval 767 Minimum time in seconds between successive solicitations of the 768 same advertising ISATAP interface. It SHOULD be no less than 900 769 seconds. The designated value of alll 1's (0xffffffff) represents 770 infinity. 772 Default: 900 seconds 774 9.2.2.2 Interface Initialization 776 The ISATAP node joins the all-nodes multicast address on ISATAP 777 interfaces, as for multicast-capable interfaces ([RFC2461], section 778 6.3.3) and MAY also join other multicast groups, e.g., see: Section 779 8.2 781 Additionally, the node provisions the ISATAP interface's PRL with 782 IPv4 addresses it discovers via manual configuration, a DNS 783 fully-qualified domain name (FQDN) [RFC1035], a DHCPv4 option, a 784 DHCPv4 vendor-specific option, or an unspecified alternate method. 786 ISATAP nodes establish FQDNs via manual configuration or an 787 unspecified alternate method. Nodes resolves FQDNs into IPv4 788 addresses through lookup in a static host file, querying the DNS 789 service, or an unspecified alternate method. When DNS is used, client 790 resolvers use the IPv4 transport. 792 After the node provisions the ISATAP interface's PRL with IPv4 793 addresses, it sets PrlRefreshIntervalTimer to PrlRefreshInterval 794 seconds. The node re-initializes the PRL (i.e., as specified above) 795 when PrlRefreshIntervalTimer expires, or when an asynchronous 796 re-initialization event occurs. When the node re-initializes the PRL, 797 it resets PrlRefreshIntervalTimer to PrlRefreshInterval seconds. 799 9.2.2.3 Processing Received Router Advertisements 801 The ISATAP server daemon processes Router Advertisements (RAs) 802 exactly as specified in ([RFC2461], section 6.3.4). Router 803 Advertisement messages received on a point-to-point tunnel interface 804 that contain an MTU option with a value less than 1280 bytes cause 805 the interface to reduce its MTU to the lesser value, but Router 806 Advertisements received on an ISATAP interface MUST NOT cause the 807 ISATAP interface to reduce its MTU to a value less than 1280 bytes. 809 For Router Advertisement messages received on an ISATAP interface 810 that include prefix options and/or non-zero values in the Router 811 Lifetime, the server daemon reset TIMER(i) to schedule the next 812 solicitation event (see: Section 9.2.2.4). Let "MIN_LIFETIME" be the 813 minimum value in the Router Lifetime or the lifetime(s) encoded in 814 options included in the RA message. Then, TIMER(i) is reset as 815 follows: 817 TIMER(i) = MAX((0.5 * MIN_LIFETIME), MinRouterSolicitInterval) 819 9.2.2.4 Sending Router Solicitations 821 To the list of events after which RSs may be sent ([RFC2461], section 822 6.3.2), ISATAP interfaces add: 824 o TIMER(i) for some PRL(i) expires. 826 Additionally, the ISATAP server daemon MAY send Router Solicitations 827 to an ISATAP link-local address that embeds V4ADDR(i) for some PRL(i) 828 instead of the All-Routers multicast address. 830 9.3 Address Resolution and Neighbor Unreachability Detection 832 9.3.1 Address Resolution 834 The specification in ([RFC2461], section 7.2) is used. ISATAP 835 addresses for which the neighbor/router's link-layer address cannot 836 otherwise be determined (e.g., from a neighbor cache entry) are 837 resolved to link-layer addresses by a static computation, i.e., the 838 last four octets are treated as an IPv4 address. 840 Hosts SHOULD perform an initial reachability confirmation by sending 841 Neighbor Solicitation message(s) and receiving a Neighbor 842 Advertisement message (NS messages are sent to the target's unicast 843 address). Routers MAY perform this initial reachability confirmation, 844 but this might not scale in all environments. 846 As specified in ([RFC2461], section 7.2.4), all nodes MUST send 847 solicited Neighbor Advertisements on ISATAP interfaces. 849 9.3.2 Neighbor Unreachability Detection 851 Hosts SHOULD perform Neighbor Unreachability Detection ([RFC2461], 852 section 7.3). Routers MAY perform neighbor unreachability detection, 853 but this might not scale in all environments. 855 10. Other Requirements for Control Plane Signalling 857 10.1 Node Information Queries 859 ISATAP nodes SHOULD implement Node Information Queries as specified 860 in [NIQUERY]. 862 Node Information Queries/Responses provide the following advantages: 864 o the querier receives unambiguous confirmation that the responder 865 supports the protocol. 867 o the querier receives assurance that responses are coming from the 868 correct responder. 870 o the querier discovers some subset of the responder's addresses. 872 10.2 Linklocal Multicast Name Resolution (LLMNR) 874 ISATAP nodes SHOULD implement Link Local Multicast Name Resolution 875 [LLMNR], since they will commonly be deployed in environments (e.g., 876 home networks, ad-hoc networks, etc.) with no access to a Domain Name 877 System (DNS) server. 879 11. IANA Considerations 881 The IANA is advised to specify construction rules for IEEE EUI-64 882 addresses formed from the Organizationally Unique Identifier (OUI) 883 "00-00-5E" in the IANA "ethernet-numbers" registry. The non-normative 884 text in Appendix B is offered as an example specification. 886 12. Security considerations 888 The security considerations in the normative references apply. 890 Additionally, administrators MUST ensure that lists of IPv4 addresses 891 representing the advertising ISATAP interfaces of PRL members are 892 well maintained. 894 13. Acknowledgments 896 Most of the basic ideas in this document are not original; the 897 authors acknowledge the original architects of those ideas. Portions 898 of this work were sponsored through SRI International internal 899 projects and government contracts. Government sponsors include Monica 900 Farah-Stapleton and Russell Langan (U.S. Army CECOM ASEO), and Dr. 901 Allen Moshfegh (U.S. Office of Naval Research). SRI International 902 sponsors include Dr. Mike Frankel, J. Peter Marcotullio, Lou 903 Rodriguez, and Dr. Ambatipudi Sastry. 905 The following are acknowledged for providing peer review input: Jim 906 Bound, Rich Draves, Cyndi Jung, Ambatipudi Sastry, Aaron Schrader, 907 Ole Troan, Vlad Yasevich. 909 The following are acknowledged for their significant contributions: 910 Alain Durand, Hannu Flinck, Jason Goldschmidt, Nathan Lutchansky, 911 Karen Nielsen, Mohan Parthasarathy, Chirayu Patel, Art Shelest, Pekka 912 Savola, Margaret Wasserman, Brian Zill. 914 The authors acknowledge the work of Quang Nguyen [VET] under the 915 guidance of Dr. Lixia Zhang that proposed very similar ideas to those 916 that appear in this document. This work was first brought to the 917 authors' attention on September 20, 2002. 919 The following individuals are acknowledged for their helpful insights 920 on path MTU discovery: Jari Arkko, Iljitsch van Beijnum, Jim Bound, 921 Ralph Droms, Alain Durand, Jun-ichiro itojun Hagino, Brian Haberman, 922 Bob Hinden, Christian Huitema, Kevin Lahey, Hakgoo Lee, Matt Mathis, 923 Jeff Mogul, Erik Nordmark, Soohong Daniel Park, Chirayu Patel, 924 Michael Richardson, Pekka Savola, Hesham Soliman, Mark Smith, Dave 925 Thaler, Michael Welzl, Lixia Zhang and the members of the Nokia NRC/ 926 COM Mountain View team. 928 "...and I'm one step ahead of the shoe shine, 929 Two steps away from the county line, 930 Just trying to keep my customers satisfied, 931 Satisfi-i-ied!" - Simon and Garfunkel 933 Normative References 935 [ADDR-ARCH] 936 Hinden, R. and S. Deering, "IP Version 6 Addressing 937 Architecture", draft-ietf-ipv6-addr-arch-v4-00 (work in 938 progress), October 2003. 940 [ICMPV6] Conta, A. and S. Deering, "Internet Control Message 941 Protocol (ICMPv6) for the Internet Protocol Version 6 942 (IPv6) Specification", draft-ietf-ipngwg-icmp-v3 (work in 943 progress), November 2001. 945 [LLMNR] Esibov, L., Aboba, B. and D. Thaler, "Linklocal Multicast 946 Name Resolution", draft-ietf-dnsext-mdns (work in 947 progress), January 2004. 949 [MECH] Gilligan, R. and E. Nordmark, "Basic Transition Mechanisms 950 for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-00 951 (work in progress), February 2003. 953 [NIQUERY] Crawford, M., "IPv6 Node Information Queries", 954 draft-ietf-ipngwg-icmp-name-lookups (work in progress), 955 June 2003. 957 [NODEREQ] Loughney, J., "IPv6 Node Requirements", 958 draft-ietf-ipv6-node-requirements (work in progress), 959 October 2003. 961 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 962 1981. 964 [RFC1122] Braden, R., "Requirements for Internet Hosts - 965 Communication Layers", STD 3, RFC 1122, October 1989. 967 [RFC1981] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery 968 for IP version 6", RFC 1981, August 1996. 970 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 971 Requirement Levels", BCP 14, RFC 2119, March 1997. 973 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 974 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 975 October 1998. 977 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 978 (IPv6) Specification", RFC 2460, December 1998. 980 [RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor 981 Discovery for IP Version 6 (IPv6)", RFC 2461, December 982 1998. 984 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 985 Domains without Explicit Tunnels", RFC 2529, March 1999. 987 [RFC3150] Dawkins, S., Montenegro, G., Kojo, M. and V. Magret, 988 "End-to-end Performance Implications of Slow Links", BCP 989 48, RFC 3150, July 2001. 991 [RFC3542] Stevens, W., Thomas, M., Nordmark, E. and T. Jinmei, 992 "Advanced Sockets Application Program Interface (API) for 993 IPv6", RFC 3542, May 2003. 995 Informative References 997 [DEERING97] 998 Deering, S., "http://www.cs-ipv6.lancs.ac.uk/ipv6/ 999 mail-archive/IPng/1997-12/0052.html", November 1997. 1001 [FLOW] Rajahalme, J., Conta, A., Carpenter, B. and S. Deering, 1002 "IPv6 Flow Label Specification", 1003 draft-ietf-ipv6-flow-label (work in progress), December 1004 2003. 1006 [FTMIB] Haberman, B. and M. Wasserman, "IP Forwarding Table MIB", 1007 draft-ietf-ipv6-rfc2096-update (work in progress), August 1008 2003. 1010 [IPMIB] Routhier, S., "Management Information Base for the 1011 Internet Protocol (IP)", draft-ietf-ipv6-rfc2011-update 1012 (work in progress), September 2003. 1014 [RFC1035] Mockapetris, P., "Domain names - implementation and 1015 specification", STD 13, RFC 1035, November 1987. 1017 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 1018 October 1996. 1020 [RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, 1021 October 1996. 1023 [RFC2223bis] 1024 Reynolds, J. and R. Braden, "Instructions to Request for 1025 Comments (RFC) Authors", draft-rfc-editor-rfc2223bis (work 1026 in progress), August 2003. 1028 [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, 1029 S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., 1030 Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, 1031 S., Wroclawski, J. and L. Zhang, "Recommendations on Queue 1032 Management and Congestion Avoidance in the Internet", RFC 1033 2309, April 1998. 1035 [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 1036 2402, November 1998. 1038 [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security 1039 Payload (ESP)", RFC 2406, November 1998. 1041 [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", 1042 RFC 2486, January 1999. 1044 [RFC2491] Armitage, G., Schulter, P., Jork, M. and G. Harter, "IPv6 1045 over Non-Broadcast Multiple Access (NBMA) networks", RFC 1046 2491, January 1999. 1048 [RFC2492] Armitage, G., Schulter, P. and M. Jork, "IPv6 over ATM 1049 Networks", RFC 2492, January 1999. 1051 [RFC2710] Deering, S., Fenner, W. and B. Haberman, "Multicast 1052 Listener Discovery (MLD) for IPv6", RFC 2710, October 1053 1999. 1055 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1056 via IPv4 Clouds", RFC 3056, February 2001. 1058 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and 1059 M. Carney, "Dynamic Host Configuration Protocol for IPv6 1060 (DHCPv6)", RFC 3315, July 2003. 1062 [RFC3582] Abley, J., Black, B. and V. Gill, "Goals for IPv6 1063 Site-Multihoming Architectures", RFC 3582, August 2003. 1065 [SEND] Arkko, J., Kempf, J., Sommerfield, B., Zill, B. and P. 1066 Nikander, "Secure Neighbor Discovery (SEND)", 1067 draft-ietf-send-ndopt (work in progress), October 2003. 1069 [TUNNELMIB] 1070 Thaler, D., "IP Tunnel MIB", 1071 draft-ietf-ipv6-inet-tunnel-mib (work in progress), 1072 January 2004. 1074 [VET] Nguyen, Q., "http://irl.cs.ucla.edu/vet/report.ps", spring 1075 1998. 1077 Authors' Addresses 1079 Fred L. Templin 1080 Nokia 1081 313 Fairchild Drive 1082 Mountain View, CA 94110 1083 US 1085 Phone: +1 650 625 2331 1086 EMail: ftemplin@iprg.nokia.com 1088 Tim Gleeson 1089 Cisco Systems K.K. 1090 Shinjuku Mitsu Building 1091 2-1-1 Nishishinjuku, Shinjuku-ku 1092 Tokyo 163-0409 1093 Japan 1095 EMail: tgleeson@cisco.com 1096 Mohit Talwar 1097 Microsoft Corporation 1098 One Microsoft Way 1099 Redmond, WA> 98052-6399 1100 US 1102 Phone: +1 425 705 3131 1103 EMail: mohitt@microsoft.com 1105 Dave Thaler 1106 Microsoft Corporation 1107 One Microsoft Way 1108 Redmond, WA 98052-6399 1109 US 1111 Phone: +1 425 703 8835 1112 EMail: dthaler@microsoft.com 1114 Appendix A. Major Changes 1116 Major changes from earlier versions to version 17: 1118 o added tunnel driver API 1120 o expanded section on MTU and fragmentation 1122 o expanded sections on encapsulation/decapsulation 1124 o specified relation to IPv6 Node Requirements 1126 o specified use of additional control plane signalling 1128 o specified multicast mappings. 1130 o specified link layer address option format. 1132 o specified setting of "u" bit in interface id's. 1134 o removed obsoleted appendix sections. 1136 o re-organized major sections to match normative references. 1138 o revised neighbor discovery, address autoconfiguration, security 1139 considerations sections. Added new subsections on interface 1140 management, decapsulation/filtering, address lifetime expiry. 1142 Appendix B. Interface Identifier Construction 1144 This section provides an example specification for constructing EUI64 1145 addresses from the Organizationally-Unique Identifier (OUI) owned by 1146 the Internet Assigned Numbers Authority (IANA). It can be used to 1147 construct both modified EUI-64 format interface identifiers for IPv6 1148 unicast addresses ([ADDR-ARCH], section 2.5.1) and "native" EUI64 1149 addresses for future use: 1151 |0 2|2 3|3 3|4 6| 1152 |0 3|4 1|2 9|0 3| 1153 +------------------------+--------+--------+------------------------+ 1154 | OUI ("00-00-5E"+u+g) | TYPE | TSE | TSD | 1155 +------------------------+--------+--------+------------------------+ 1157 Where the fields are: 1159 OUI IANA's OUI: 00-00-5E with "u" and "g" bits (3 octets) 1161 TYPE Type field; specifies use of (TSE, TSD) (1 octet) 1163 TSE Type-Specific Extension (1 octet) 1165 TSD Type-Specific Data (3 octets) 1167 And the following interpretations are specified based on TYPE: 1169 TYPE (TSE, TSD) Interpretation 1170 ---- ------------------------- 1171 0x00-0xFD RESERVED for future IANA use 1172 0xFE (TSE, TSD) together contain an IPv4 address 1173 0xFF TSD is interpreted based on TSE as follows: 1175 TSE TSD Interpretation 1176 --- ------------------ 1177 0x00-0xFD RESERVED for future IANA use 1178 0xFE TSD contains 24-bit EUI-48 intf id 1179 0xFF RESERVED by IEEE/RAC 1181 Using this example specification, if TYPE=0xFE, then TSE is an 1182 extension of TSD. If TYPE=0xFF, then TSE is an extension of TYPE. 1183 (Other values for TYPE, and other interpretations of TSE, TSD are 1184 reserved for future IANA use.) When TYPE='0xFE' the EUI64 address 1185 embeds an IPv4 address, encoded in network byte order. 1187 For Modified EUI64 format interface identifiers in IPv6 unicast 1188 addresses ([ADDR-ARCH], Appendix A) using IANA's OUI, when TYPE=0xFE 1189 and the IPv4 address is a globally unique (i.e., provider-assigned) 1190 unicast address, the "u" bit is set to 1 to indicate universal scope. 1191 When TYPE=0xFE and the IPv4 address is from a private allocation, the 1192 "u" bit is set to 0 to indicate local scope. Thus, when the first 1193 four octets of the interface identifier in an IPv6 unicast address 1194 are either: '02-00-5E-FE' or: '00-00-5E-FE', the next four octets 1195 embed an IPv4 address and the interface identifier is said to be in 1196 "ISATAP format". 1198 Intellectual Property Statement 1200 The IETF takes no position regarding the validity or scope of any 1201 intellectual property or other rights that might be claimed to 1202 pertain to the implementation or use of the technology described in 1203 this document or the extent to which any license under such rights 1204 might or might not be available; neither does it represent that it 1205 has made any effort to identify any such rights. Information on the 1206 IETF's procedures with respect to rights in standards-track and 1207 standards-related documentation can be found in BCP-11. Copies of 1208 claims of rights made available for publication and any assurances of 1209 licenses to be made available, or the result of an attempt made to 1210 obtain a general license or permission for the use of such 1211 proprietary rights by implementors or users of this specification can 1212 be obtained from the IETF Secretariat. 1214 The IETF invites any interested party to bring to its attention any 1215 copyrights, patents or patent applications, or other proprietary 1216 rights which may cover technology that may be required to practice 1217 this standard. Please address the information to the IETF Executive 1218 Director. 1220 The IETF has been notified of intellectual property rights claimed in 1221 regard to some or all of the specification contained in this 1222 document. For more information consult the online list of claimed 1223 rights. 1225 Full Copyright Statement 1227 Copyright (C) The Internet Society (2004). All Rights Reserved. 1229 This document and translations of it may be copied and furnished to 1230 others, and derivative works that comment on or otherwise explain it 1231 or assist in its implementation may be prepared, copied, published 1232 and distributed, in whole or in part, without restriction of any 1233 kind, provided that the above copyright notice and this paragraph are 1234 included on all such copies and derivative works. However, this 1235 document itself may not be modified in any way, such as by removing 1236 the copyright notice or references to the Internet Society or other 1237 Internet organizations, except as needed for the purpose of 1238 developing Internet standards in which case the procedures for 1239 copyrights defined in the Internet Standards process must be 1240 followed, or as required to translate it into languages other than 1241 English. 1243 The limited permissions granted above are perpetual and will not be 1244 revoked by the Internet Society or its successors or assignees. 1246 This document and the information contained herein is provided on an 1247 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1248 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1249 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1250 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1251 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1253 Acknowledgment 1255 Funding for the RFC Editor function is currently provided by the 1256 Internet Society.