idnits 2.17.1 draft-ietf-ngtrans-dstm-04.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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == Mismatching filename: the document gives the document name as 'draft-ietf-ngtrans-dstm-03', but the file name used is 'draft-ietf-ngtrans-dstm-04' == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 20 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 15 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == 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). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: When the client requests an IPv4 address from the DHCPv6 Server the TEP field MUST not be present in the Global IPv4 Address Option. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The Client MUST not update the DNS with this new address. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: '1' is defined on line 697, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 700, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 711, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 714, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 736, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 742, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 751, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 754, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (ref. '3') (Obsoleted by RFC 8200) == Outdated reference: A later version (-28) exists of draft-ietf-dhc-dhcpv6-16 -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 2406 (ref. '7') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2065 (ref. '9') (Obsoleted by RFC 2535) ** Obsolete normative reference: RFC 2137 (ref. '10') (Obsoleted by RFC 3007) ** Downref: Normative reference to an Informational RFC: RFC 2185 (ref. '11') ** Obsolete normative reference: RFC 2765 (ref. '13') (Obsoleted by RFC 6145) ** Obsolete normative reference: RFC 2893 (ref. '14') (Obsoleted by RFC 4213) ** Downref: Normative reference to an Historic RFC: RFC 2874 (ref. '17') ** Obsolete normative reference: RFC 2462 (ref. '18') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2373 (ref. '19') (Obsoleted by RFC 3513) Summary: 15 errors (**), 0 flaws (~~), 15 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Jim Bound 2 NGTRANS Working Group Nokia Networks 3 Obsoletes draft-ietf-ngtrans-dstm-03.txt Laurent Toutain 4 Expires July 2001 Francis Dupont 5 ENST Bretagne 6 Hossam Afifi 7 INT 8 Alain Durand 9 Sun Microsystems 11 Dual Stack Transition Mechanism (DSTM) 13 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 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 28 material 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 To view the entire list of current Internet-Drafts, please check the 37 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 38 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 39 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 40 ftp.isi.edu (US West Coast). 42 Distribution of this memo is unlimited. 44 Abstract 46 The initial deployment of IPv6 will require a tightly coupled use of 47 IPv4 addresses to support the interoperation of IPv6 and IPv4, within 48 an IPv6 Network. Nodes will still need to communicate with IPv4 49 nodes that do not have a dual IP layer supporting both IPv4 and IPv6. 50 The Dual Stack Transition Mechanism (DSTM) provides a method to 51 assign temporary Global IPv4 Addresses to IPv6/IPv4 nodes over a 52 native IPv6 Network, use of dynamic tunnels within an IPv6 Network to 53 carry IPv4 traffic, and a defined set of processes and architecture 54 for the supporting infrastructure required for this transition 55 mechanism. 57 Table of Contents: 59 1. Introduction.................................................4 60 2. Terminology..................................................5 61 2.1 IPv6 DSTM Terminology.......................................5 62 2.2 Specification Language......................................5 63 3. DSTM Overview and Assumptions................................6 64 4. DSTM Deployment Example......................................9 65 4.1 DSTM Client/Server Example ................................10 66 5 DTI Architecture.............................................10 67 5.1 Assignment of the IPv4 address to the DTI..................11 68 5.2 DTI Encapsulation of IPv4 packets..........................11 69 5.3 DTI IPv6 destination address...............................11 70 6. DHCPv6 Requirements.........................................12 71 6.1 DHCPv6 Global IPv4 Address Option..........................12 72 6.1.1 Client Request of IPv4 Global Address.....................13 73 6.1.2 Server Reply of IPv4 Global Address Option...............13 74 6.1.3 Client Processing of IPv4 Address Option.................14 75 6.2 Server Processing of an IPv4 Address Option................15 76 6.3 Client Processing of an IPv4 Address Option................15 77 7. Applicability Statement.....................................16 78 8. Security Considerations.....................................16 79 Changes from draft 03 to draft 04..............................17 80 Changes from draft 02 to draft 03..............................17 81 Changes from draft 01 to draft 02..............................17 82 Changes from draft 00 to draft 01..............................17 83 Acknowledgments................................................18 84 References.....................................................18 85 Authors' Address...............................................20 86 1. Introduction 88 The initial deployment of IPv6 will require a tightly coupled use of 89 IPv4 addresses to support the interoperation of IPv6 and IPv4, within an 90 IPv6 Network. Nodes will still need to communicate with IPv4 nodes that 91 do not have a dual IP layer supporting both IPv4 and IPv6. The Dual 92 Stack Transition Mechanism (DSTM) provides a method to assign temporary 93 Global IPv4 Addresses to IPv6/IPv4 nodes over a native IPv6 Network, use 94 of dynamic tunnels within an IPv6 Network to carry IPv4 traffic, and a 95 defined set of processes and architecture for the supporting 96 infrastructure required for this transition mechanism. 98 The DSTM assigns, when needed an IPv4 address to a dual IP layer node. 99 This will allow either IPv6 nodes to communicate with IPv4-only nodes, 100 or for IPv4-only applications to run without modification on an IPv6 101 node. This allocation mechanism is coupled with the ability to perform 102 dynamic tunneling of an IPv4 packet inside an IPv6 packet, to hide IPv4 103 packets in the native IPv6 domain. This will simplify the network 104 management of IPv6 deployment, since routers need only IPv6 routing 105 tables to move IPv4 packets across an IPv6 network. This means that we 106 manage one routing plan for IPv6 only. 108 DSTM is targeted to help the interoperation of IPv6 newly deployed 109 networks with existing IPv4 networks. DSTM assumes that a user will 110 deploy an IPv6 network to reduce the need and reliability on IPv4 within 111 a portion of their network. In addition the IPv4 globally routable 112 address space available to the network is a scarce resource, and the 113 user may not want to deploy DHCPv4[15] to assign temporary IPv4 114 addresses to IPv6 nodes, and would rather require those nodes to use 115 IPv6 to obtain or be given the IPv4 temporary addresses from DHCPv6. 116 Also, to reduce the IPv4 applications a user has to support and to 117 obtain a temporary IPv6 IPv4-Mapped Address (see Section 6), the client 118 only has to run a DHCPv6 client process with the DTI mechanisms in this 119 specification. 121 The DSTM architecture is composed of a DHCPv6 server, that provides for 122 the assignment of IPv4 Global Addresses to IPv6 Hosts. The DHCPv6 123 server will allocate temporary IPv4 Global Addresses to IPv6 nodes. The 124 DHCPv6 server will also be used to maintain the mapping between the 125 allocated IPv4 address and the permanent IPv6 address of the node. Each 126 IPv6 DSTM will have an IPv4 interface called the Dynamic Tunneling 127 Interface (DTI) designed to encapsulate IPv4 packets into IPv6 packets. 128 Also a DSTM daemon exists working with a DHCPv6 client to resolve the 129 address space mechanics, between IPv4 and IPv6. 131 The specification will begin by defining the terminology (section 2), 132 then section 3 provides a technical overview of the DSTM methodology as 133 a transition mechanism. Then in section 4 we provide a DSTM example. 134 Section 5 describes the DTI Architecture and Section 6 discusses the 135 DHCPv6 option requirements. Section 7 provides the DSTM Applicability 136 Statement. 138 2. Terminology 140 2.1 IPv6 DSTM Terminology 142 DSTM Domain The network areas on an Intranet where a 143 DHCPv6 Server has access to IPv6 nodes participating 144 in DSTM for that network, and IPv4 routing access 145 is not necessary within a DSTM domain. 147 DSTM Border Router A border router within a DSTM domain and 148 access to an external IPv4-ONLY domain. 150 DSTM Host A Host that supports a dual IP layer IPv4 151 and IPv6 stack, DTI, and a DHCPv6 Client 152 process. 154 IPv6 Protocol Terms: See [3] 156 IPv6 Transition Terms: See [14] 158 DHCPv6 Terms: See [4] 160 DTI: Dynamic Tunneling Interface. An interface 161 encapsulating IPv4 packets into IPv6 packets. 163 IPv4 Global Address: An IPv4 address that is globally routable on 164 the Internet. 166 Tunnel End Point (TEP) Destination of the IPv6 packet containing an 167 IPv4 packet. In most cases this will be 168 a dual stack border router. 170 2.2 Specification Language 172 In this document, several words are used to signify the requirements 173 of the specification, in accordance with RFC 2119 [8]. These words 174 are often capitalized. 176 MUST This word, or the adjective "required", means that 177 the definition is an absolute requirement of the 178 specification. 180 MUST NOT This phrase means that the definition is an absolute 181 prohibition of the specification. 183 SHOULD This word, or the adjective "recommended", means 184 that there may exist valid reasons in particular 185 circumstances to ignore this item, but the full 186 implications must be understood and carefully 187 weighed before choosing a different course. 188 Unexpected results may result otherwise. 190 MAY This word, or the adjective "optional", means that 191 this item is one of an allowed set of alternatives. 192 An implementation which does not include this option 193 MUST be prepared to interoperate with another 194 implementation which does include the option. 196 silently discard 197 The implementation discards the packet without 198 further processing, and without indicating an error 199 to the sender. The implementation SHOULD provide 200 the capability of logging the error, including the 201 contents of the discarded packet, and SHOULD record 202 the event in a statistics counter. 204 3. DSTM Overview and Assumptions 206 DSTM as discussed in the introduction is a method which uses existing 207 protocols. DSTM does not specify a protocol. However, DSTM defines a 208 new DHCPv6 Option for transition. 210 The motivation for DSTM is to provide IPv6 nodes a means to acquire an 211 IPv4 Global Address, for communications with IPv4-only nodes or IPv4 212 applications. 214 The core assumption within this mechanism is that it is totally 215 transparent to applications, which can continue to work with IPv4 216 addresses. It is also transparent to the network which carry only IPv6 217 packets. It is the authors viewpoint that the user in this case, has 218 deployed IPv6 to support end to end computing, without translation. 219 This aspect is fundamental during a transition process to guarantee that 220 every existing application will continue to work (e.g. IPsec, H.323), 221 which embed IPv4 addresses in the payload of a packet. 223 The DSTM model and assumptions are as follows: 225 - The DSTM domain is within an Intranet not on the Internet. 227 - IPv6 nodes do not maintain IPv4 addresses except on a temporary basis, 228 to communicate with IPv4-only and IPv4 Applications. 230 - Standard DHCPv6 is used to support the extension to provide 231 and accept from DHCPv6 Servers Global IPv4 Addresses. 233 - The DSTM domain for the IPv6 nodes will keep IPv4 routing 234 tables to a minimum and use IPv6 routing, hence, reducing 235 the network management required for IPv4 during transition. 237 - Once IPv6 nodes have obtained IPv4 addresses Dynamic Tunneling is 238 used to encapsulate the IPv4 packet within IPv6 and then forward 239 that packet to an IPv6 TEP, where the packet will be decapulated and 240 forwarded using IPv4. DHCPv6 is used to provide TEPs to IPv6 nodes 241 supporting DTI, as part of the new DHCPv6 Option. 243 - Existing IPv4 applications or nodes do not have to be modified to 244 communicate with DSTM. 246 - Implementation defined software will have to exist to support DSTM: 248 o Ability within a DHCPv6 Server implementation to maintain 249 configuration information about TEPs for encapsulating IPv4 250 packets between IPv6 nodes that can forward IPv4 packets to an 251 IPv4 routing realm, and to maintain a pool of Global IPv4 252 Addresses. 254 o Software within an IPv6 node to support the dynamic tunneling 255 mechanisms in this specification to encapsulate IPv4 packets 256 within IPv6 on an IPv6 node. In addition 257 a daemon must exist to access a DHCPv6 client for Global IPv4 258 Mapped Addresses and TEPs. How this daemon communicates with 259 a DHCPv6 Client implementation is implementation defined, and 260 left as an exercise for implementors of this transition 261 mechanism. 263 o Software in DSTM Border Routers to recall or be able to cache 264 the association of IPv6 and IPv4 addresses of nodes during 265 decapsulation and encapsulation. 267 A simplistic overview of DSTM is as follows: 269 ----------------------------------------------- 270 | IPv4 Internet or Intranet 271 DSTM Domain Intranet | IPv4 Applications 272 | Domain 273 _____________________ | 274 | | | 275 | DHCPv6 Server | | 276 |_____________________| | 277 ^ | 278 | | 279 __________________ | _|_______ 280 | | | | | 281 | IPv6/IPv4 Node | | | DSTM | 282 |------------------| | | Border | 283 | DSTM Daemon | | | Router | 284 | DHCPv6 client |<------- | IPv6 | 285 |------------------| | & | 286 | DTI/Route |<-------------------->| IPv4 | 287 ------------------- --------- 288 | 289 ---------------------------------------------- 291 For an IPv6 node to participate in DSTM it MUST have a dual IP layer, 292 supporting both an IPv4 and an IPv6 stack. DSTM is not a solution for 293 IPv6 ONLY nodes. 295 4. DSTM Deployment Example 297 In the example below, the following notation will be used: 299 X will designate an IPv6 node with a dual stack, X6 will be the IPv6 300 address of this node and X4 the IPv4 address 301 Y will designate a DSTM border router at the boundary between an 302 IPv6 DSTM domain and an IPv4-only domain. 303 Z will designate an IPv4-only node and Z4 its address. 304 ==> means an IPv6 packet 305 --> means an IPv4 packet 306 ++> means a tunneled IPv4 packet is encapsulated in an IPv6 packet 307 ..> means a DNS query or response. The path taken by this 308 packet does not matter in the examples 309 "a" means the DNS name of a node 311 4.1 DSTM Client/Server Example 313 This example describes the case where an application (either compiled 314 for the IPv6 or IPv4 API) running on an IPv6 node (X6) wants to 315 establish a session with an IPv4 application on an IPv4-only node (Z4). 317 The IPv6 node is configured with the IPv6 address of a TEP, where an 318 IPv4 encapsulated packet will be sent. 320 The IPv4 routing table of node X is configured to send IPv4 packets to 321 the DTI interface. 323 DHCPv6 324 DNS 325 X6 Y6/Y4 Z4 326 | | | 327 |. . . . . . . .> Z | - X6 asks the DNS for the A RR for "Z" 328 |<. . . . . . . . Z4 | - the answer is Z4 329 | | | 330 | | | - The application sends its first IPv4 331 | | | packet which arrives to the DTI interface 332 | | | (If the application is compiled for IPv6 333 | | | this can be done through an IPv4-mapped 334 | | | address). 335 | | | 336 | | | - X6 needs an IPv4 address (first use) 337 |====> | | - X6 queries the DHCPv6 server for an 338 | | | IPv4 address using DHCPv6 339 |<==== | | - The DHCPv6 server locates the client 340 | | | and provides a temporary IPv4 341 | | | global address. 342 |+++++++++++>| | - The DTI sends the IPv6 packet to the 343 | | | TEP. 344 | |----------->| - Y sends the packet to the destination Z4 345 | | | - Y caches the association between 346 | | | the IPv4 and IPv6 addresses of X. 348 When Z responds the packet returns back through Y. Y having cached the 349 association between the IPv4 and the IPv6 address of X, is able to send 350 the packet encapsulating the IPv4 packet within IPv6 back to X. 352 5 DTI Architecture 354 In the absence of an IPv4 routing infrastructure, a DSTM node can not 355 directly send IPv4 packets on the network. It has to encapsulate them 356 into IPv6 packets and send them to a tunnel end point (TEP) that will 357 decapsulate them and inject them in the IPv4 network. 359 On a DSTM node, this encapsulation is done by the DTI interface. An 360 IPv4 packet can be directed to that interface by an IPv4 routing table 361 entry. 363 The exact details of the DTI interface and the associated routing table 364 entries are implementation dependant. 366 5.1 Assignment of the IPv4 address to the DTI 368 When the DTI interface is activated, an IPv4 address is not given to 369 that interface. When it has to send the first IPv4 packet, a request is 370 sent to the DHCPv6 client. The DHCPv6 client will send a DHCPv6 request 371 to the DHCPv6 server to get the temporary IPv4 Global Address and a TEP. 373 An IPv6 node can know it needs an IPv4 address if the DNS resolver on 374 the node knows that the destination address will be an IPv4 address. 376 5.2 DTI Encapsulation of IPv4 packets 378 The next header type for IPv4 encapsulation is 4 (as for IPv4 tunneling 379 over IPv4). When a tunneled packet arrives to the IPv6 destination, the 380 IPv6 header is removed and the packet is processed by the IPv4 layer. 381 The DSTM Border Router SHOULD cache the association between the IPv4 and 382 IPv6 source addresses. The IPv4 packet will then be forwarded by the 383 DSTM border router using the IPv4 infrastructure. 385 The IPv6 source address of an encapsulated packet will be the IPv6 386 address of the interface on which the IPv6 packet will be sent. 388 5.3 DTI IPv6 destination address 390 When a DTI has to encapsulate an IPv4 packet into an IPv6 packet, the 391 DTI has to determine the TEP IPv6 address for the destination. The TEP 392 can be the node destination or, if the destination node is IPv4-only, 393 the IPv6 address of an IPv4/IPv6 DSTM Border Router. 395 The TEP can be either statically configured or dynamically acquired when 396 the IPv6 node acquires an IPv4 Compatible Address from a DHCPv6 Server. 398 The TEP SHOULD be provided by the DHCPv6 server when the DSTM node 399 receives an IPv4-Mapped IPv6 Address (section 6). But, a DSTM node MAY 400 manually configure the TEP during early deployment of IPv6, this will 401 not scale and is not recommended as a long term transition solution. 403 6. DHCPv6 Requirements 405 The DSTM processes will use the DHCPv6 services [4] to communicate 406 between the DHCPv6 Server and the DHCPv6 Client. A new option is 407 required for DHCPv6 to support DSTM. But there are some additional 408 requirements placed on the DSTM processes that are not specific to the 409 DHCPv6 protocol as a transition and interoperation set of mechanisms for 410 the IPv6 node. 412 DHCPv6 clients solicit servers, and servers advertise their 413 availability. Then DHCPv6 clients request configuration parameters, and 414 a server sends those parameters back in a reply message. The client 415 requests parameters by specifying options with the DHCPv6 request 416 messaqge. This new DSTM option will request that the server return an 417 IPv4-Mapped IPv6 address to the client. 419 DHCPv6 servers also support a Reconfigure message sent to clients to ask 420 clients to initiate a request message for a specific option. This 421 permits DHCPv6 servers to offer clients IPv4-Mapped IPv6 addresses. 423 6.1 DHCPv6 Global IPv4 Address Option 425 The DHCPv6 IPv4 Address Option informs a DHCPv6 Client or Server that 426 the Identity Association Option (IA) [4] following this option will 427 contain an IPv4-Mapped IPv6 Address [19] in the case of a DHCPv6 Client 428 receiving the option, or is a Request for an IPv4-Mapped IPv6 Address 429 from a client in the case of a DHCPv6 Server receiving the option. The 430 option can also provide an IPv6 address to be used as the TEP to 431 encapsulate an IPv4 packet within IPv6. 433 This option can be used with the DHCPv6 Request, Reply, and 434 Reconfigure-Init Messages for cases where a DHCPv6 Server wants to 435 assign to clients IPv4-Mapped IPv6 Addresses, thru the Option Request 436 Option (ORO) in DHCPv6. 438 0 1 2 3 439 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | option-code | option-length | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Tunnel End Point (TEP) | 444 | (If Present) | 445 | (16 octets) | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 option-code: TBD 449 option-length: Variable: 0 or 16 450 Tunnel End Point: IPv6 Address if Present 451 An IPv4 Global Address Option MUST only apply to the IA 452 following it this option. 454 6.1.1 Client Request of IPv4 Global Address 456 When the client requests an IPv4 address from the DHCPv6 Server the TEP 457 field MUST not be present in the Global IPv4 Address Option. 459 6.1.2 Server Reply of IPv4 Global Address Option 461 The server will reply to the client with a Global IPv4 Address Option, 462 that can contain an IPv6 Address Tunnel End Point, and an IA Option 463 which MUST include an IPv4 IPv6-Mapped Address. The IA Option is 464 provided as a reference in this document [4]. 466 The format of the IA option is: 468 0 1 2 3 469 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | TBD | variable | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | IA UUID | 474 | (8 octets) | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | T1 | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | T2 | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | num-addrs | IPv6 address | 481 +-+-+-+-+-+-+-+-+ (16 octets) | 482 | | 483 | | 484 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | | pref. len | preferred lifetime | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | pref. lifetime (cont.) | valid lifetime | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | valid lifetime (cont.) | IPv6 address | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 491 | ... | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 option-code 495 TBD 497 option-len 498 Variable; equal to 17 + num-addrs*25 500 IA UUID 501 The unique identifier for this IA; chosen by the client 503 T1 The time at which the client contacts the server from 504 which the addresses in the IA were obtained to extend 505 the lifetimes of the addresses assigned to the IA. 507 T2 The time at which the client contacts any available 508 server to extend the lifetimes of the addresses assigned 509 to the IA. 511 num-addrs 512 An unsigned integer giving the number of addresses 513 carried in this IA option (MAY be zero). 515 IPv6 address 516 An IPv6 address assigned to this IA. 518 preferred lifetime 519 The preferred lifetime for the associated IPv6 address. 521 valid lifetime 522 The valid lifetime for the associated IPv6 address. 524 The ``IPv6 address'', ``preferred lifetime'' and ``valid lifetime'' 525 fields are repeated for each address in the IA option (as determined 526 by the ``num-addrs'' field). 528 6.1.3 Client Processing of IPv4 Address Option 530 The processing of the IPv4 Global Address Option on the client is 531 implementation defined but here are some guidelines for developers. 533 When processing the IA Option following the IPv4 Global Address Option, 534 an IP Address provided will be an IPv4-Mapped IPv6 Address. A 535 conceptual implementation model would be to add this address to the 536 nodes IPv6 mechanisms that maintain timing procedures for IPv6 addresses 537 on the IPv6 stack, and then configure the IPv4 interface for DTI, as a 538 procedure called from the DHCPv6 client. 540 As the IPv4 IPv6-Mapped Address is an IPv6 address all other processing 541 for DHCPv6 is as specified in that document, the IPv4 Global Address 542 Option just informs the client that an address within the IA option will 543 be an IPv4 IPv6-Mapped Address. 545 6.2 Server Processing of an IPv4 Address Option 547 When a DHCPv6 Server receives an IPv4 Global Address Option in a DHCPv6 548 Request message, the client is requesting an IPv4 IPv6-Mapped Address. 550 A DHCPv6 Server can send a Client a Reconfigure-Init message using the 551 IPv4 Global Address Option to ask the Client to request an IPv4 Global 552 Address thru an ORO. The Client will then send a request to the server 553 for an IPv4 IPv6-Mapped Address. 555 The Server will know a priori the Clients IPv6 routable address, when 556 sending a Reconfiguration-Init message. 558 The Server will look in its implementation defined IPv4 Address 559 configuration to determine if a TEP is available for a specific IPv6 560 Address Prefix. If that is the case the Server will put the address for 561 the TEP in the Global IPv4 Address Option. 563 6.3 Client Processing of an IPv4 Address Option 565 When the Server supplies an IPv4 Global Address in a Reply. 567 The Client MUST not update the DNS with this new address. 569 A conceptual model to configure an IPv4 IPv6-Mapped address on a client 570 is as follows: 572 1. In an implementation defined manner the Client MUST assign the 573 address to an interface, supporting the Client's IPv4 stack 574 implementation. 576 2. In an implementation defined manner the Client MUST create an entry 577 as an IPv4-Mapped IPv6 Address supporting the processing required 578 for an IPv6 address regarding the valid and preferred lifetimes 579 as specified in IPv6 Addrconf [18]. Once the IPv4-Mapped IPv6 580 Address valid lifetime expires the IPv4 address MUST be deleted 581 from the respective interface and a DHCPv6 Release Message 582 MUST be sent to the DHCPv6 Server to delete the IPv4 IPv6-Mapped 583 Address from the Servers bindings. 585 3. If a TEP address is provided in the Global IPv4 586 Address Option, the Client MUST create a configured tunnel 587 to the TEP address, in an implementation defined 588 manner. These encapsulation mechanisms are defined 589 in other IPv6 specifications [12, 14]. 591 7. Applicability Statement 593 DSTM is applicable for use from within the DSTM Domain to IPv4 nodes or 594 applications on a user Intranet or over the Internet. 596 DSTM's motivation is to support dual IP layer DSTM node to communicate 597 using global IPv4 addresses across an Intranet or Internet, where global 598 addresses are required. But, DSTM has been defined to also permit the 599 use of Private IPv4 address space to permit the Intranet use of DSTM 600 where users require temporary access to IPv4 services within their 601 Intranet. 603 DSTM requires the use of DHCPv6 to obtain IPv4 addresses and TEPs for a 604 DSTM node. Communications between the DSTM Daemon and the DHCPv6 client 605 is implementation defined. The DTI mechanism is also implementation 606 defined. DSTM does permit optionally for DSTM node to manually 607 configure TEPs for DTI for early deployment of DSTM but highly 608 recommends not doing this and configuring DHCPv6 servers with this 609 information is really the way to execute DSTM on an IPv6 Network. 611 DSTM also assumes that all packets returning from an IPv4 node to a DSTM 612 dual IP layer node return through the orginating DSTM Border Router 613 which has cached the association of the DSTM's IPv4+IPv6 addresses. At 614 this time it is beyond the scope of DSTM to permit IPv4 packets destined 615 for DSTM node to return packets through a non-orginating DSTM border 616 router. 618 DSTM also through the new DHCPv6 extension permits Network Operators to 619 inform DSTM Hosts they will need IPv4 addresses for communications using 620 the DHCPv6 Reconfigure-Init message. 622 DSTM as future work can be extended to support multiple border routers 623 for returning IPv4 packets, and for the discovery of DSTM node using 624 IPv4 DNS queries as future work for DSTM. 626 8. Security Considerations 628 The DSTM mechanism can use all the defined security specifications for 629 each functional part of the operation. For DNS the DNS Security 630 Extensions/Update can be used [9, 10], for DHCPv6 the DHCPv6 631 Authentication Message can be used [4], and for communications between 632 the IPv6 node, once it has an IPv4 address, and the remote IPv4 node, 633 IPsec [7] can be used as DSTM does not break secure end-to-end 634 communications at any point in the mechanism. 636 Changes from draft 03 to draft 04 638 1. Changed DHCPv6 options and processing to comply with 639 draft-ietf-dhc-dhcpv6-16.txt 641 Changes from draft 02 to draft 03 643 1. Working Group Edits 645 Changes from draft 01 to draft 02 647 1. Added futher clarifications to DSTM components. 649 2. Added client/server details for DHCPv6 ngtrans extension. 651 3. Removed optional scenarios to simplify this mechanism. 653 4. Removed AIIH concepts and changed to be DSTM components. 655 5. Add Applicability Statement 657 6. Added acknowledgment section and new coauthors Francis Dupont 658 and Alain Durand. 660 Changes from draft 00 to draft 01 662 1. Added text explaining why the draft does not use DHCPv4 to assign 663 IPv4 compatible addresses to the "Introduction". 665 2. Defined what is mandatory and what is optional and added relative 666 text in various places to clarify this change. And added RFC 667 2119 adjectives to the spec where appropriate. 669 3. Scenario 1 where IPv6 node wants to communicate with IPv4 670 node is mandatory. 672 4. Scenarios 2 and 3 are now optional where an IPv6 node is 673 assigned an IPv4 compatible address because an external 674 IPv4 node is attempting communications with the IPv6 node. 676 5. For scenario 1 DHCPv6 is only needed for DSTM and not the 677 tightly coupled paradigm of a co-existent DHCPv6 and 678 DNS server. Also added mandatory and optional to the 679 DSTM AIIH/NODE/ROUTER Diagram. 681 6. Made Static Tunnel Endpoints mandatory and Dyanmic Tunnel 682 End Points optional. 684 7. Fixed DHCPv6 Reconfigure statements to take into account 685 changes to the Reconfigure message in the DHCPv6 working 686 group, to support AIIH processing. 688 Acknowledgments 690 The authors would like to acknowledge the implementation contributions 691 by Stephane Atheo at ENST Bretagne who has implemented a DSTM prototype 692 on FreeBSD and input to this specification. We would also like to thank 693 the NGTRANS Working Group for their input. 695 References 697 [1] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 698 13, RFC 1034, USC/Information Sciences Institute, November 1987. 700 [2] Mockapetris, P., "Domain Names - Implementation and Specifica- 701 tion", STD 13, RFC 1035, USC/Information Sciences Institute, 702 November 1987. 704 [3] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) 705 Architecture", RFC 2460, December 1998. 707 [4] J. Bound, M. Carney, C. Perkins, and R. Droms. Dynamic Host 708 Configuration Protocol for IPv6. draft-ietf-dhc-dhcpv6-16.txt 709 November 2000 (work in progress). 711 [5] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound. Dynamic Updates 712 to the Domain Name System (DNS). RFC 2136, April 1997. 714 [6] William R. Cheswick and Steven Bellovin. Firewalls and Internet 715 Security. Addison-Wesley, Reading, MA 1994 (ISBN: 717 0-201-63357-4). 719 [7] IPSEC - 720 S. Kent, R. Atkinson. Security Architecture for the Internet 721 Protocol. RFC 2401, November 1998. 722 S. Kent, R. Atkinson. IP Authentication Header. 723 RFC 2402, November 1998. 724 S. Kent, R. Atkinson. IP Encapsulating Security Payload 725 RFC 2406, November 1998. 727 [8] S. Bradner. Key words for use in RFCs to indicate Requirement 728 Levels. RFC 2119, March 1997. 730 [9] D. Eastlake and C. Kaufman. Domain Name System Security 731 Extensions. RFC 2065, January 1997. 733 [10] D. Eastlake. Secure Domain Name System Dynamic Update. 734 RFC 2137, April 1997. 736 [11] R. Callon and D. Haskins. Routing Aspects Of IPv6 Transition 737 RFC 2185, September 1997. 739 [12] A. Conta and S. Deering. Generic Packet Tunneling in IPv6. 740 RFC 2473, December 1998. 742 [13] E. Nordmark. Stateless IP/ICMP Translator (SIIT) 743 RFC 2765, February 2000. 745 [14] R. Gilligan and E. Nordmark. Transition Mechanisms for IPv6 746 Hosts and Routers. RFC 2893, August 2000. 748 [15] R. Droms. Dynamic Host Configuration Protocol. 749 RFC 2131, March 1997. 751 [16] Rekhter, Moskowitz, Karrenburg, Groot. Address Allocation 752 for Private Networks. RFC 1918. February 1996. 754 [17] M. Crawford, C. Huitema. DNS Extensions to Support IPv6 Address 755 Aggregation and Renumbering. RFC 2874, July 2000. 757 [18] Thomson, Narten. IPv6 Stateless Address Configuration. 758 RFC 2462, December 1998. 760 [19] Hinden, Deering. IP Version 6 Addressing Architecture. 761 RFC 2373, July 1998. 763 Authors' Address 765 Jim Bound 766 Nokia Networks 767 5 Wayside Road 768 Burlington, MA 01803 769 Phone: +1 781 492 0613 770 Email: Jim.Bound@nokia.com 772 Laurent Toutain 773 ENST Bretagne 774 BP 78 775 35 512 Cesson 776 Phone : +33 2 99 12 70 26 777 Email : Laurent.Toutain@enst-bretagne.fr 779 Hossam Afifi 780 INT 781 91 011 M-Ivry 782 Phone : +33 1 60 76 40 40 783 Email : Hossam.Afifi@int-evry.fr 785 Francis Dupont 786 ENST Bretagne 787 BP 78 788 35 512 Cesson 789 Phone : +33 2 99 12 70 36 790 Email : Francis.Dupont@enst-bretagne.fr 792 Alain Durand 793 Sun Microsystems 794 901 San Antonio Road 795 UMPK 17-202 796 Palo Alto, CA 94303-4900 797 Tel: +1 650 786 7503 798 Fax: +1 650 786 5896 799 Email: Alain.Durand@sun.com