idnits 2.17.1 draft-ietf-ngtrans-dstm-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 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-04', but the file name used is 'draft-ietf-ngtrans-dstm-05' == 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 21 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.) ** There are 95 instances of too long lines in the document, the longest one being 8 characters in excess of 72. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 258 has weird spacing: '...provide the T...' == 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. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '10' is mentioned on line 503, but not defined == Missing Reference: '16' is mentioned on line 544, but not defined ** Obsolete normative reference: RFC 2460 (ref. '1') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2406 (ref. '3') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2893 (ref. '6') (Obsoleted by RFC 4213) ** Obsolete normative reference: RFC 2462 (ref. '8') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2373 (ref. '9') (Obsoleted by RFC 3513) == Outdated reference: A later version (-28) exists of draft-ietf-dhc-dhcpv6-16 Summary: 9 errors (**), 0 flaws (~~), 12 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 Compaq 3 Obsoletes draft-ietf-ngtrans-dstm-04.txt Laurent Toutain 4 Expires May 2002 Francis Dupont 5 Octavio Medina 6 ENST Bretagne 7 Hossam Afifi 8 INT 9 Alain Durand 10 Sun Microsystems 12 Dual Stack Transition Mechanism (DSTM) 14 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet- Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 To view the entire list of current Internet-Drafts, please check the 38 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 39 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 40 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 41 ftp.isi.edu (US West Coast). 43 Distribution of this memo is unlimited. 45 Abstract 47 The initial deployment of IPv6 will require a tightly coupled use of 48 IPv4 addresses to support the interoperation of IPv6 and IPv4, within 49 an IPv6 Network. Nodes will still need to communicate with IPv4 50 nodes that do not have a dual IP layer supporting both IPv4 and IPv6. 51 The Dual Stack Transition Mechanism (DSTM) provides a method to 52 assign temporary IPv4 Addresses to IPv6/IPv4 nodes over a native IPv6 53 Network. DSTM uses dynamic tunnels within an IPv6 Network to carry 54 IPv4 traffic and a defined set of processes and architecture for the 55 supporting infrastructure required for this transition mechanism. 57 Table of Contents: 59 1. Introduction ........................................ 3 60 2. Terminology ......................................... 4 61 2.1 IPv6 DSTM Terminology .............................. 4 62 2.2 Specification Language ............................. 5 63 3. DSTM Overview and Assumptions ....................... 5 64 4. DSTM Deployment Example ............................. 7 65 4.1 DSTM Client/Server Example ......................... 8 66 5 DTI Architecture ..................................... 9 67 5.1 Assignment of the IPv4 address to the DTI .......... 10 68 5.2 DTI proceeding of IPv4 packets ..................... 10 69 5.3 DTI IPv6 packet .................................... 10 70 6. DSTM Server Requirements ............................ 11 71 7. Applicability Statement ............................. 11 72 8. Security Considerations ............................. 12 73 Annexe A: Static Configuration ......................... 12 74 Annexe B: RPC .......................................... 13 75 Annexe C: DHCPv6 ....................................... 13 76 C.1 DHCPv6 Global IPv4 Address Option .................. 14 77 C.1.1 Client Request of IPv4 Global Address ............ 15 78 C.1.2 Server Reply of IPv4 Global Address Option ....... 15 79 C.1.3 Client Processing of IPv4 Address Option ......... 17 80 C.2 Server Processing of an IPv4 Address Option ........ 17 81 C.3 Client Processing of an IPv4 Address Option ........ 18 82 Acknowledgments ........................................ 19 83 Normative References ................................... 20 84 Informative References ................................. 20 85 Authors' Address ....................................... 20 87 1. Introduction 89 The initial deployment of IPv6 will require a tightly coupled use of 90 IPv4 addresses to support the interoperation of IPv6 and IPv4, within 91 an IPv6 Network. Nodes will still need to communicate with IPv4 92 nodes that do not have a dual IP layer supporting both IPv4 and IPv6. 93 The Dual Stack Transition Mechanism (DSTM) provides a method to 94 assign temporary IPv4 Addresses to IPv6/IPv4 nodes over a native IPv6 95 Network. DSTM uses of dynamic tunnels within an IPv6 Network to carry 96 IPv4 traffic, and a defined set of processes and architecture for the 97 supporting infrastructure required for this transition mechanism. 99 The DSTM assigns, when needed an IPv4 address to a dual IP layer 100 node. This will allow either IPv6 nodes to communicate with IPv4- 101 only nodes, or for IPv4-only applications to run without modification 102 on an IPv6 node. This allocation mechanism is coupled with the 103 ability to perform dynamic tunneling of an IPv4 packet inside an IPv6 104 packet, to hide IPv4 packets in the native IPv6 domain. This will 105 simplify the network management of IPv6 deployment, since routers 106 need only IPv6 routing tables to move IPv4 packets across an IPv6 107 network. This means that only the IPv6 routing plan is managed 108 inside the network. 110 DSTM is targeted to help the interoperation of IPv6 newly deployed 111 networks with existing IPv4 networks. DSTM assumes that a user will 112 deploy an IPv6 network to reduce the need and reliability on IPv4 113 within a portion of his network. In addition the IPv4 globally 114 routable address space available to the network is a scarce resource, 115 and DHCPv4[7] may not be directly used to assign temporary IPv4 116 addresses to IPv6 nodes, since no IPv4 connectivity is maintained 117 into the network. Also, to reduce the IPv4 applications a user has 118 to support and to obtain a temporary IPv4 Address (see Section 6), 119 the client only has to run a client process with the DTI mechanisms 120 in this specification. 122 The DSTM architecture is composed of an addresses server, that can 123 provides the assignment of IPv4 addresses to IPv6 Nodes. The server 124 will also be used to maintain the mapping between the allocated IPv4 125 address and the permanent IPv6 address of the node. Each IPv6 DSTM 126 will have an IPv4 interface called the Dynamic Tunneling Interface 127 (DTI) designed to encapsulate IPv4 packets into IPv6 packets. A DSTM 128 client on the node SHOULD be used for IPv4 address allocation and MAY 129 be used to solve the mapping between IPv4 and IPv6 addresses. 131 The specification will begin by defining the terminology (section 2), 132 then section 3 provides a technical overview of the DSTM methodology 133 as a transition mechanism. Then in section 4 we provide a DSTM 134 example. Section 5 describes the DTI Architecture and Section 6 135 discusses the properties of the IPv4 allocation mechanisms that can 136 be used. Section 7 provides the DSTM Applicability Statement. 138 Annexes give ways to use this specification in different situations. 139 Annexe A gives a simple user configuration. This simplifies a lot the 140 DTI interface but require more IPv4 addresses. Annexe B documents the 141 use of RPCv6 to allocate addresses. This is a simple but limited 142 protocol. Annexe C describes the DHCPv6 mechanism for DSTM. This is 143 the most appropriate and generic mechanism, but due to some 144 standardisation delay, it could not be deployed as fast as RPCv6. 146 2. Terminology 148 2.1 IPv6 DSTM Terminology 150 DSTM Domain The network areas on an Intranet where a 151 temporary IPv4 allocation Server has access 152 to IPv6 nodes participating 153 in DSTM for that network, and IPv4 routing access 154 is not necessary within a DSTM domain. 156 DSTM Node A Node that supports a dual IP layer IPv4 157 and IPv6 stack, DTI, and an IPv4 allocation 158 Client. The DSTM node generate only IPv6 159 packets on the network. 161 DSTM Border Router A border router within a DSTM domain and 162 access to an external IPv4-ONLY domain. 164 DSTM client A process on the DSTM Node that managed 165 the temporary IPv4 address assigned by the 166 DSTM Server. 168 DSTM Server A process in charge of managing the IPv4 address 169 space that will be allocated to DSTM Nodes. 171 IPv6 Protocol Terms: See [1] 173 IPv6 Transition Terms: See [6] 175 DHCPv6 Terms: See [2] 177 DTI Dynamic Tunneling Interface. An interface 178 encapsulating IPv4 packets into IPv6 packets. 180 Tunnel End Point (TEP) Destination of the IPv6 packet containing an 181 IPv4 packet. In most cases this will be 182 a DSTM border router. 184 2.2 Specification Language 186 In this document, several words are used to signify the requirements 187 of the specification, in accordance with RFC 2119 [4]. These words 188 are often capitalized. 190 MUST This word, or the adjective "required", means that 191 the definition is an absolute requirement of the 192 specification. 194 MUST NOT This phrase means that the definition is an absolute 195 prohibition of the specification. 197 SHOULD This word, or the adjective "recommended", means 198 that there may exist valid reasons in particular 199 circumstances to ignore this item, but the full 200 implications must be understood and carefully 201 weighed before choosing a different course. 202 Unexpected results may result otherwise. 204 MAY This word, or the adjective "optional", means that 205 this item is one of an allowed set of alternatives. 206 An implementation which does not include this option 207 MUST be prepared to interoperate with another 208 implementation which does include the option. 210 silently discard 211 The implementation discards the packet without 212 further processing, and without indicating an error 213 to the sender. The implementation SHOULD provide 214 the capability of logging the error, including the 215 contents of the discarded packet, and SHOULD record 216 the event in a statistics counter. 218 3. DSTM Overview and Assumptions 220 DSTM as discussed in the introduction is a method that uses existing 221 protocols. DSTM does not specify a protocol. However, DSTM defines 222 client, server and TEP behaviour and the properties of the temporary 223 addresses allocation mechanisms. 225 The motivation for DSTM is to provide IPv6 nodes a means to acquire 226 an IPv4 address, for communications with IPv4-only nodes or IPv4 227 applications. 229 The core assumption within this mechanism is that it is totally 230 transparent to applications, which can continue to work with IPv4 231 addresses. It is also transparent to the network carring only IPv6 232 packets. It is the authors' viewpoint that the user in this case, 233 has deployed IPv6 to support end to end computing, without 234 translation. This aspect is fundamental during a transition process 235 to guarantee that every existing application will continue to work 236 (e.g. IPsec, H.323), with embed IPv4 addresses in the payload of a 237 packet. 239 The DSTM model and assumptions are as follows: 241 - The DSTM domain is within an Intranet not on the Internet. 243 - IPv6 nodes do not maintain IPv4 addresses except on a temporary basis, 244 to communicate with IPv4-only and IPv4 Applications. 246 - The temporary IPv4 address allocation is done by the DSTM server, 247 different protocols such as DHCPv6 or RPCv6 can be used to assign the 248 IPv4 address. 250 - The DSTM domain for the IPv6 nodes will keep IPv4 routing 251 tables to a minimum and use IPv6 routing, hence, reducing 252 the network management required for IPv4 during transition. 254 - Once IPv6 nodes have obtained IPv4 addresses Dynamic Tunneling is 255 used to encapsulate the IPv4 packet within IPv6 and then forward 256 that packet to an IPv6 TEP, where the packet will be decapulated and 257 forwarded using IPv4. The IPv4 allocation mechanism may also 258 provide the TEP IPv6 address. 260 - Existing IPv4 applications or nodes do not have to be modified to 261 communicate with DSTM. 263 - Implementation defined software will have to exist to support DSTM: 265 o Ability within a DSTM Server implementation to maintain 266 configuration information about TEPs for encapsulating IPv4 267 packets between IPv6 nodes that can forward IPv4 packets to an 268 IPv4 routing realm, and to maintain a pool of IPv4 269 Addresses. 271 o an IPv6 node MUST support the dynamic tunneling 272 mechanisms in this specification to encapsulate IPv4 packets 273 within IPv6 on an IPv6 node. In addition 274 a DSTM client SHOULD be present on the node for IPv4 275 Mapped Addresses and TEPs management. 277 o DSTM Border Routers MAY recall or be able to cache 278 the association of IPv6 and IPv4 addresses of nodes during 279 the forwarding process. 281 A schematic overview of DSTM is as follows: 283 ----------------------------------------------- 284 | IPv4 Internet or Intranet 285 DSTM Domain Intranet | IPv4 Applications 286 | Domain 287 _____________________ | 288 | | | 289 | DSTM Server | | 290 |_____________________| | 291 ^ | 292 | | 293 __________________ | _|_______ 294 | | | | | 295 | IPv6/IPv4 Node | | | DSTM | 296 |------------------| | | Border | 297 | DSTM client | | | Router | 298 | |<------- | IPv6 | 299 |------------------| | & | 300 | DTI/Route |<-------------------->| IPv4 | 301 ------------------- --------- 302 | 303 ---------------------------------------------- 305 For an IPv6 node to participate in DSTM it MUST have a dual IP layer, 306 supporting both an IPv4 and an IPv6 stack. DSTM is not a solution 307 for IPv6 ONLY nodes. 309 4. DSTM Deployment Example 311 In the example below, the following notation will be used: 313 X will designate an IPv6 node with a dual stack, X6 will be the IPv6 314 address of this node and X4 the IPv4 address 315 Y will designate a DSTM border router at the boundary between an 316 IPv6 DSTM domain and an IPv4-only domain. 317 Z will designate an IPv4-only node and Z4 its address. 318 ==> means an IPv6 packet 319 --> means an IPv4 packet 320 ++> means a tunneled IPv4 packet is encapsulated in an IPv6 packet 321 ..> means a DNS query or response. The path taken by this 322 packet does not matter in the examples 323 "a" means the DNS name of a node 325 4.1 DSTM Client/Server Example 327 This example describes the case where an application (either compiled 328 for the IPv6 or IPv4 API) running on an IPv6 node (X6) wants to 329 establish a session with an IPv4 application on an IPv4-only node 330 (Z4). 332 The IPv4 routing table of node X is configured to send IPv4 packets 333 to the DTI interface. 335 DSTM 336 Server DNS 337 X6 Y6/Y4 Z4 338 | | | 339 |. . . . . . . .> Z | - X6 asks the DNS for the A RR for "Z" 340 |<. . . . . . . . Z4 | - the answer is Z4 341 | | | 342 | | | - The application sends its first IPv4 343 | | | packet which arrives to the DTI 344 | | | interface. 345 | | | (If the application is compiled for IPv6 346 | | | this can be done through an IPv4-mapped 347 | | | address). 348 | | | 349 | | | - X6 needs an IPv4 address (first use) 350 |====> | | - X6 queries the DSTM server for an 351 | | | IPv4 address 352 |<==== | | - The DSTM server locates the client 353 | | | and provides a temporary IPv4 354 | | | global address and the IPv6 TEP address. 355 |+++++++++++>| | - The DTI sends the IPv6 packet to the 356 | | | TEP. 357 | |----------->| - Y sends the packet to the destination Z4 358 | | | - Y caches the association between 359 | |<-----------| - Z4 answers. 360 | | | 361 |<+++++++++++| | - Y uses the mapping between X4 and X6 362 | | | to tunnel the packet to the destination 363 | | | 365 When Z responds the packet returns back through Y. Y having cached 366 the association between the IPv4 and the IPv6 address of X, is able 367 to send the packet encapsulating the IPv4 packet within IPv6 back to 368 X. 370 5 DTI Architecture 372 In the absence of an IPv4 routing infrastructure, a DSTM node can not 373 directly send IPv4 packets on the network. It has to encapsulate them 374 into IPv6 packets and send them to a tunnel end point (TEP), which is 375 a particular DSTM node, that will decapsulate the packet and forward 376 them in the IPv4 network. 378 On a DSTM node, this encapsulation is done by the DTI interface. An 379 IPv4 packet can be directed to that interface by an IPv4 routing 380 table entry. 382 The exact details of the DTI interface and the associated routing 383 table entries are implementation dependant. 385 5.1 Assignment of the IPv4 address to the DTI 387 When the DTI interface is activated, an IPv4 address is not given to 388 that interface. When the first IPv4 packet has to be sent by the DTI 389 interface, a request is sent to the DSTM serveur to get the temporary 390 IPv4 address and the TEP IPv6 address. 392 An IPv6 node can know it needs an IPv4 address if the DNS resolver on 393 the node knows that the destination address will be an IPv4 address. 394 This can also be trigged by the DTI interface if no IPv4 addresss is 395 associated to that interface (see next paragraph). 397 5.2 DTI proceeding of IPv4 packets 399 The DSTM server allocates the source address of the IPv4 packet. If 400 the DTI interface does not have an IPv4 address, the process using 401 this interface SHOULD be blocked and the request mechanism for a 402 temporary IPv4 address SHOULD be started. 404 The other fields of the IPv4 packet are normally filled. 406 5.3 DTI IPv6 packet 408 When a DTI has to encapsulate an IPv4 packet into an IPv6 packet, the 409 DTI has to determine the TEP IPv6 address for the destination. The 410 TEP can be the node destination or, if the destination node is IPv4- 411 only, the IPv6 address of an IPv4/IPv6 DSTM Border Router. 413 The TEP IPv6 address can be either statically configured or 414 dynamically acquired when the IPv6 node acquires an IPv4 address from 415 a DSTM Server. 417 The TEP IPv6 address SHOULD be provided by the DSTM server when the 418 DSTM node receives an temporary IPv4 Address (section 6). But, a 419 DSTM node MAY manually configure the TEP during early deployment of 420 DSTM, this will not scale and is not recommended as a long term 421 transition solution. 423 The next header type for IPv4 encapsulation is 4 (as for IPv4 424 tunneling over IPv4). When a tunneled packet arrives to the IPv6 425 destination, the IPv6 header is removed and the packet is processed 426 by the IPv4 layer. The DSTM Border Router SHOULD cache the 427 association between the IPv4 and IPv6 source addresses. The IPv4 428 packet will then be forwarded by the DSTM border router using the 429 IPv4 infrastructure. 431 The IPv6 source address of an encapsulated packet will be the IPv6 432 address of the interface on which the IPv6 packet will be sent. 434 6. DSTM Server Requirements 436 The DSTM server is mostly in charge of the temporary IPv4 address 437 allocation. This allocation is very simple since there is no 438 localisation purpose in this address. The DSTM server has just to 439 guaranty the uniqueness of the IPv4 address for a period of time. The 440 DTSM server MUST also memorize the mapping between the IPv6 address 441 of the node requesting a temporary address and the allocated IPv4 442 address. 444 The temporary IPv4 address is allocated by the server for a fixed 445 among of time. This duration MUST be included in the response. If the 446 client needs the IPv4 address for a longer period of time, the client 447 MUST renew the lease. 449 The pool of IPv4 global addresses MUST be routed to one or more TEP 450 in the DSTM domain. 452 The response SHOULD include the TEP IPv6 address in charge of the 453 temporary IPv4 address. 455 The communication between the DSTM client and the server MUST be in 456 IPv6. 458 The DSTM server MAY allocate a temporary IPv4 address without a 459 request from he client. 461 The DSTM server SHOULD be able to authenticate the DSTM client. 463 7. Applicability Statement 465 DSTM is applicable for use from within the DSTM Domain to IPv4 nodes 466 or applications on a user Intranet or over the Internet. 468 DSTM's motivation is to support dual IP layer DSTM node to 469 communicate using global IPv4 addresses across an Intranet or 470 Internet, where global addresses are required. But, DSTM has been 471 defined to also permit the use of Private IPv4 address space to 472 permit the Intranet use of DSTM where users require temporary access 473 to IPv4 services within their Intranet. 475 if DSTM requires the use of DHCPv6 to obtain IPv4 addresses and TEPs 476 for a DSTM node, the Communications between the DSTM Daemon and the 477 DHCPv6 client is implementation defined. The DTI mechanism is also 478 implementation defined. DSTM does permit optionally for DSTM node to 479 manually configure TEPs for DTI for early deployment of DSTM but 480 highly recommends not doing this and configuring DHCPv6 servers with 481 this information is really the way to execute DSTM on an IPv6 482 Network. 484 DSTM also assumes that all packets returning from an IPv4 node to a 485 DSTM dual IP layer node return through the orginating DSTM Border 486 Router which has cached the association of the DSTM's IPv4+IPv6 487 addresses. At this time it is beyond the scope of DSTM to permit 488 IPv4 packets destined for DSTM node to return packets through a non- 489 orginating DSTM border router. 491 DSTM also through the new DHCPv6 extension permits Network Operators 492 to inform DSTM Nodes they will need IPv4 addresses for communications 493 using the DHCPv6 Reconfigure-Init message. 495 DSTM as future work can be extended to support multiple border 496 routers for returning IPv4 packets, and for the discovery of DSTM 497 node using IPv4 DNS queries as future work for DSTM. 499 8. Security Considerations 501 The DSTM mechanism can use all the defined security specifications 502 for each functional part of the operation. For DNS the DNS Security 503 Extensions/Update can be used [9, 10], for DHCPv6 the DHCPv6 504 Authentication Message can be used [2], and for communications 505 between the IPv6 node, once it has an IPv4 address, and the remote 506 IPv4 node, 508 IPsec [3] can be used as DSTM does not break secure end-to-end 509 communications at any point in the mechanism. 511 Annexe A: Static Configuration 513 The DTI interface in a DSTM client can be a static tunnel such as a 514 gif interface in the KAME stack. An IPv4 address can be manually 515 assigned to the interface. In that case, no DSTM server is needed, 516 the TEP will maintain the mapping between the v4 and the v6 addresses 517 of the DSTM client. 519 The following listing gives a configuration example for the KAME 520 stack: 522 gifconfig gif0 inet6 3ffe:ffe:1002:1::1 3ffe:3ffe:1002:1:260:caff:fe85:abcd 523 ifconfig gif0 inet 193.109.121.195 193.109.121.199 netmask 255.255.255.255 up 524 route change default 193.109.121.199 526 Annexe B: RPC 528 RPC is a simple method that can be used for communication between the 529 DSTM client and the DSTM server. This method is efficient when the 530 address request is triggered by the DSTM client. The following 531 listing gives the structure used by RPC in this case: 533 const REQUEST_REQ = 1; 534 const REQUEST_REP = 2; 535 const RELEASE_REQ = 3; 536 const RELEASE_REP = 4; 538 struct packet { 539 int type; /* Message opcode/type */ 540 opaque local[16]; /* Link-local address */ 541 opaque mask[4]; /* Netmask */ 542 opaque i4addr[4]; /* IPv4 address */ 543 opaque tep4[4]; /* TEP IPv4 address */ 544 opaque tep6[16]; /* TEP IPv6 address */ 545 unsigned long ends; /* When the lease ends */ 546 unsigned long starts; /* When the lease starts */ 547 unsigned long extend; /* How long to extend */ 548 unsigned long keep; /* How long to keep */ 549 }; 551 program RPC { 552 version RPC_ONE { 553 struct packet REQUEST(struct packet) = 1; 554 struct packet RELEASE(struct packet) = 2; 555 } = 1; 556 } = [to be assigned]; 558 Annexe C: DHCPv6 560 The DSTM processes will use the DHCPv6 services [2] to communicate 561 between the DHCPv6 Server and the DHCPv6 Client. A new option is 562 required for DHCPv6 to support DSTM. But there are some additional 563 requirements placed on the DSTM processes that are not specific to 564 the DHCPv6 protocol as a transition and interoperation set of 565 mechanisms for the IPv6 node. 567 DHCPv6 clients solicit servers, and servers advertise their 568 availability. Then DHCPv6 clients request configuration parameters, 569 and a server sends those parameters back in a reply message. The 570 client requests parameters by specifying options with the DHCPv6 571 request messaqge. This new DSTM option will request that the server 572 return an IPv4-Mapped IPv6 address to the client. 574 DHCPv6 servers also support a Reconfigure message sent to clients to 575 ask clients to initiate a request message for a specific option. 576 This permits DHCPv6 servers to offer clients IPv4-Mapped IPv6 577 addresses. 579 C.1 DHCPv6 Global IPv4 Address Option 581 The DHCPv6 IPv4 Address Option informs a DHCPv6 Client or Server that 582 the Identity Association Option (IA) [2] following this option will 583 contain an IPv4-Mapped IPv6 Address [9] in the case of a DHCPv6 584 Client receiving the option, or is a Request for an IPv4-Mapped IPv6 585 Address from a client in the case of a DHCPv6 Server receiving the 586 option. The option can also provide an IPv6 address to be used as 587 the TEP to encapsulate an IPv4 packet within IPv6. 589 This option can be used with the DHCPv6 Request, Reply, and 590 Reconfigure- Init Messages for cases where a DHCPv6 Server wants to 591 assign to clients IPv4-Mapped IPv6 Addresses, thru the Option Request 592 Option (ORO) in DHCPv6. 594 0 1 2 3 595 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 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | option-code | option-length | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | Tunnel End Point (TEP) | 600 | (If Present) | 601 | (16 octets) | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 option-code: TBD 605 option-length: Variable: 0 or 16 606 Tunnel End Point: IPv6 Address if Present 608 An IPv4 Global Address Option MUST only apply to the IA 609 following it this option. 611 C.1.1 Client Request of IPv4 Global Address 613 When the client requests an IPv4 address from the DHCPv6 Server the 614 TEP field MUST not be present in the Global IPv4 Address Option. 616 C.1.2 Server Reply of IPv4 Global Address Option 618 The server will reply to the client with a Global IPv4 Address 619 Option, that can contain an IPv6 Address Tunnel End Point, and an IA 620 Option which MUST include an IPv4 IPv6-Mapped Address. The IA Option 621 is provided as a reference in this document [2]. 623 The format of the IA option is: 625 The identity association option is used to carry an identity 626 association, the parameters associated with the IA and the addresses 627 assigned to the IA. 629 The format of the IA option is: 631 0 1 2 3 632 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 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 | OPTION IA | option-len | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 | IAID (4 octets) | 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | T1 | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 | T2 | 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 | IA status | num-addrs |T| addr status | prefix length | 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 | | 645 | IPv6 address | 646 | (16 octets) | 647 | | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | preferred lifetime | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | valid lifetime | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 |T| addr status | prefix length | | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 655 | IPv6 address | 656 | (16 octets) | 657 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 | | preferred lifetime | 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 | pref. lifetime (cont.) | valid lifetime | 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 | valid lifetime (cont.) |T| addr status | prefix length | 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 | | 665 | IPv6 address | 666 | (16 octets) | 667 | | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | ... | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 option-code OPTION_IA (TBD) 674 option-len Variable; equal to 24 + num-addrs*26 676 IA ID The unique identifier for this IA; chosen by 677 the client 679 T1 The time at which the client contacts the 680 server from which the addresses in the IA 681 were obtained to extend the lifetimes of the 682 addresses assigned to the IA. 684 T2 The time at which the client contacts any 685 available server to extend the lifetimes of 686 the addresses assigned to the IA. 688 T When set to 1, indicates that this address is 689 a "temporary address" [7]; when set to 0, 690 the address is not a temporary address. 692 IA status Status of the IA in this option. 694 num-addrs An unsigned integer giving the number of 695 addresses carried in this IA option (MAY be 696 zero). 698 addr status Status of the addresses in this IA. 700 prefix length Prefix length for this address. 702 IPv6 address An IPv6 address assigned to this IA. 704 preferred lifetime The preferred lifetime for the associated 705 IPv6 address. 707 valid lifetime The valid lifetime for the associated IPv6 708 address. 710 The ``IPv6 address'', ``preferred lifetime'' and ``valid lifetime'' 711 fields are repeated for each address in the IA option (as determined 712 by the ``num-addrs'' field). 714 C.1.3 Client Processing of IPv4 Address Option 716 The processing of the IPv4 Global Address Option on the client is 717 implementation defined but here are some guidelines for developers. 719 When processing the IA Option following the IPv4 Global Address 720 Option, an IP Address provided will be an IPv4-Mapped IPv6 Address. 721 A conceptual implementation model would be to add this address to the 722 nodes IPv6 mechanisms that maintain timing procedures for IPv6 723 addresses on the IPv6 stack, and then configure the IPv4 interface 724 for DTI, as a procedure called from the DHCPv6 client. 726 As the IPv4 IPv6-Mapped Address is an IPv6 address all other 727 processing for DHCPv6 is as specified in that document, the IPv4 728 Global Address Option just informs the client that an address within 729 the IA option will be an IPv4 IPv6-Mapped Address. 731 C.2 Server Processing of an IPv4 Address Option 733 When a DHCPv6 Server receives an IPv4 Global Address Option in a 734 DHCPv6 Request message, the client is requesting an IPv4 IPv6-Mapped 735 Address. 737 A DHCPv6 Server can send a Client a Reconfigure-Init message using 738 the IPv4 Global Address Option to ask the Client to request an IPv4 739 Global Address thru an ORO. The Client will then send a request to 740 the server for an IPv4 IPv6-Mapped Address. 742 The Server will know a priori the Clients IPv6 routable address, when 743 sending a Reconfiguration-Init message. 745 The Server will look in its implementation defined IPv4 Address 746 configuration to determine if a TEP is available for a specific IPv6 747 Address Prefix. If that is the case the Server will put the address 748 for the TEP in the Global IPv4 Address Option. 750 C.3 Client Processing of an IPv4 Address Option 752 When the Server supplies an IPv4 Global Address in a Reply. 754 The Client MUST not update the DNS with this new address. 756 A conceptual model to configure an IPv4 IPv6-Mapped address on a 757 client is as follows: 759 1. In an implementation defined manner the Client MUST assign the 760 address to an interface, supporting the Client's IPv4 stack 761 implementation. 763 2. In an implementation defined manner the Client MUST create an entry 764 as an IPv4-Mapped IPv6 Address supporting the processing required 765 for an IPv6 address regarding the valid and preferred lifetimes 766 as specified in IPv6 Addrconf [8]. Once the IPv4-Mapped IPv6 767 Address valid lifetime expires the IPv4 address MUST be deleted 768 from the respective interface and a DHCPv6 Release Message 769 MUST be sent to the DHCPv6 Server to delete the IPv4 IPv6-Mapped 770 Address from the Servers bindings. 772 3. If a TEP address is provided in the Global IPv4 773 Address Option, the Client MUST create a configured tunnel 774 to the TEP address, in an implementation defined 775 manner. These encapsulation mechanisms are defined 776 in other IPv6 specifications [5, 6]. 778 Changes from draft 04 to draft 05 780 1. Give in the normative part only DSTM server requierments 782 2. Create 3 annexes for different way to configure DTSM client 784 Changes from draft 03 to draft 04 786 1. Changed DHCPv6 options and processing to comply with 787 draft-ietf-dhc-dhcpv6-16.txt 789 Changes from draft 02 to draft 03 791 1. Working Group Edits 793 Changes from draft 01 to draft 02 795 1. Added futher clarifications to DSTM components. 797 2. Added client/server details for DHCPv6 ngtrans extension. 799 3. Removed optional scenarios to simplify this mechanism. 801 4. Removed AIIH concepts and changed to be DSTM components. 803 5. Add Applicability Statement 805 6. Added acknowledgment section and new coauthors Francis Dupont 806 and Alain Durand. 808 Changes from draft 00 to draft 01 810 1. Added text explaining why the draft does not use DHCPv4 to assign 811 IPv4 compatible addresses to the "Introduction". 813 2. Defined what is mandatory and what is optional and added relative 814 text in various places to clarify this change. And added RFC 815 2119 adjectives to the spec where appropriate. 817 3. Scenario 1 where IPv6 node wants to communicate with IPv4 818 node is mandatory. 820 4. Scenarios 2 and 3 are now optional where an IPv6 node is 821 assigned an IPv4 compatible address because an external 822 IPv4 node is attempting communications with the IPv6 node. 824 5. For scenario 1 DHCPv6 is only needed for DSTM and not the 825 tightly coupled paradigm of a co-existent DHCPv6 and 826 DNS server. Also added mandatory and optional to the 827 DSTM AIIH/NODE/ROUTER Diagram. 829 6. Made Static Tunnel Endpoints mandatory and Dyanmic Tunnel 830 End Points optional. 832 7. Fixed DHCPv6 Reconfigure statements to take into account 833 changes to the Reconfigure message in the DHCPv6 working 834 group, to support AIIH processing. 836 Acknowledgments 838 The authors would like to acknowledge the implementation 839 contributions by Stephane Atheo at ENST Bretagne who has implemented 840 a DSTM prototype on FreeBSD and input to this specification. We 841 would also like to thank the NGTRANS Working Group for their input. 843 Normative References 845 [1] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) 846 Architecture", RFC 2460, December 1998. 848 [3] IPSEC - 849 S. Kent, R. Atkinson. Security Architecture for the Internet 850 Protocol. RFC 2401, November 1998. 851 S. Kent, R. Atkinson. IP Authentication Header. 852 RFC 2402, November 1998. 853 S. Kent, R. Atkinson. IP Encapsulating Security Payload 854 RFC 2406, November 1998. 856 [4] S. Bradner. Key words for use in RFCs to indicate Requirement 857 Levels. RFC 2119, March 1997. 859 [5] A. Conta and S. Deering. Generic Packet Tunneling in IPv6. 860 RFC 2473, December 1998. 862 [6] R. Gilligan and E. Nordmark. Transition Mechanisms for IPv6 863 Hosts and Routers. RFC 2893, August 2000. 865 [7] R. Droms. Dynamic Host Configuration Protocol. 866 RFC 2131, March 1997. 868 [8] Thomson, Narten. IPv6 Stateless Address Configuration. 869 RFC 2462, December 1998. 871 [9] Hinden, Deering. IP Version 6 Addressing Architecture. 872 RFC 2373, July 1998. 874 Informative References 876 [2] J. Bound, M. Carney, C. Perkins, and R. Droms. Dynamic Host 877 Configuration Protocol for IPv6. draft-ietf-dhc-dhcpv6-16.txt 878 October 2001 (work in progress). 880 Authors' Address 882 Jim Bound 883 Compaq Computer Corporation 884 110 Spitbrook Road 885 Nashua, NH 003062 886 USA 888 Laurent Toutain 889 ENST Bretagne 890 BP 78 891 35512 Cesson Sevigne Cedex 892 Phone : +33 2 99 12 70 26 893 Email : Laurent.Toutain@enst-bretagne.fr 895 Octavio Medina 896 ENST Bretagne 897 BP 78 898 35512 Cesson Sevigne Cedex 899 Phone : +33 2 99 12 70 23 900 Email / Octavio.Medina@enst-bretagne.fr 902 Hossam Afifi 903 INT 904 91011 Evry 905 Phone : +33 1 60 76 40 40 906 Email : Hossam.Afifi@int-evry.fr 908 Francis Dupont 909 ENST Bretagne 910 BP 78 911 35 512 Cesson Sevigne Cedex 912 Phone : +33 2 99 12 70 33 913 Email : Francis.Dupont@enst-bretagne.fr 915 Alain Durand 916 Sun Microsystems 917 901 San Antonio Road 918 UMPK 17-202 919 Palo Alto, CA 94303-4900 920 Tel: +1 650 786 7503 921 Fax: +1 650 786 5896 922 Email: Alain.Durand@sun.com