idnits 2.17.1 draft-ietf-ngtrans-dstm-02.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-01', but the file name used is 'draft-ietf-ngtrans-dstm-02' == There are 3 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 19 longer pages, the longest (page 2) being 91 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 19 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. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 497 has weird spacing: '... status zer...' == Line 520 has weird spacing: '... status zer...' == 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 IPv4 Address Extension. == 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 assume it can use the IPv4 Address until it has received a corresponding Reply to the Client Request. == 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 709, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 712, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 727, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 730, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 745, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 751, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 762, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 765, 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-15 -- No information found for draft-ietf-dhc-dhcpv6ext - is the name correct? -- Possible downref: Normative reference to a draft: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Obsolete normative reference: RFC 2065 (ref. '10') (Obsoleted by RFC 2535) ** Obsolete normative reference: RFC 2137 (ref. '11') (Obsoleted by RFC 3007) ** Downref: Normative reference to an Informational RFC: RFC 2185 (ref. '12') == Outdated reference: A later version (-08) exists of draft-ietf-ngtrans-siit-03 -- Possible downref: Non-RFC (?) normative reference: ref. '18' ** Obsolete normative reference: RFC 2462 (ref. '19') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2373 (ref. '20') (Obsoleted by RFC 3513) Summary: 11 errors (**), 0 flaws (~~), 22 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Jim Bound 2 NGTRANS Tools Working Group Compaq 3 Obsoletes draft-ietf-ngtrans-dstm-01.txt Laurent Toutain 4 Expires January 2001 Hossam Afifi 5 Francis Dupont 6 ENST Bretagne 7 Alain Durand 8 Sun Microsystems 10 Dual Stack Transition Mechanism (DSTM) 12 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet- Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 To view the entire list of current Internet-Drafts, please check the 36 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 37 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 38 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 39 ftp.isi.edu (US West Coast). 41 Distribution of this memo is unlimited. 43 Abstract 45 The initial deployment of IPv6 will require a tightly coupled use of 46 IPv4 addresses to support the interoperation of IPv6 and IPv4, within 47 an IPv6 Network. Nodes will be able to be deployed with IPv6 48 addresses, but will still need to communicate with IPv4 nodes that do 49 not have a dual IP layer supporting both IPv4 and IPv6. The Dual 50 Stack Transition Mechanism (DSTM) provides a method to assign 51 temporary Global IPv4 Addresses to IPv6 nodes, use of dynamic tunnels 52 within an IPv6 Network to carry IPv4 traffic, and a defined set of 53 processes and architecture for the supporting infrastructure required 54 for this transition mechanism. 56 Table of Contents: 58 1. Introduction.................................................3 59 2. Terminology..................................................4 60 2.1 IPv6 AIIH Terminology.......................................4 61 2.2 Specification Language......................................4 62 3. DSTM Overview and Assumptions................................5 63 4. DSTM Deployment Example......................................8 64 4.1 DSTM Client/Server Example .................................9 65 5 DTI Architecture..............................................9 66 5.1 Assignment of the IPv4 address to the DTI..................10 67 5.2 DTI Encapsulation of IPv4 packets..........................10 68 5.3 DTI IPv6 destination address...............................11 69 6. DHCPv6 Requirements.........................................12 70 6.1 DHCPv6 IPv4 Address Extension..............................12 71 6.1.1 Client Request of IPv4 Global Address Extension..........12 72 6.1.2 Server Reply of IPv4 Global Address Extension............13 73 6.1.3 Client Processing of IPv4 Address Extension..............14 74 6.2 Server Processing of an IPv4 Address Extension.............14 75 6.3 Client Processing of an IPv4 Address Extension.............14 76 7. Applicability Statement.....................................15 77 8. Security Considerations.....................................16 78 Changes from draft 01 to draft 02..............................16 79 Changes from draft 00 to draft 01..............................16 80 Acknowledgments................................................17 81 References.....................................................17 82 1. Introduction 84 The initial deployment of IPv6 will require a tightly coupled use of 85 IPv4 addresses to support the interoperation of IPv6 and IPv4, within an 86 IPv6 Network. Nodes will be able to be deployed with IPv6 addresses, 87 but will still need to communicate with IPv4 nodes that do not have a 88 dual IP layer supporting both IPv4 and IPv6. The Dual Stack Transition 89 Mechanism (DSTM) provides a method to assign temporary Global IPv4 90 Addresses to IPv6 nodes, use of dynamic tunnels within an IPv6 Network 91 to carry IPv4 traffic, and a defined set of processes and architecture 92 for the supporting infrastructure required for this transition 93 mechanism. 95 The DSTM assigns, when needed an IPv4 address to a dual IP layer host. 96 This will allow either IPv6 hosts to communicate with IPv4-only hosts, 97 or for IPv4-only applications to run without modification on an IPv6 98 host. This allocation mechanism is coupled with the ability to perform 99 dynamic tunneling of an IPv4 packet inside an IPv6 packet, to suppress 100 the exposure of IPv4 native packets within a DSTM domain of an IPv6 101 network. This will simplify the network management of IPv6 deployment, 102 since routers need only IPv6 routing tables to move IPv4 packets across 103 an IPv6 network. This means that network managers do not need to 104 implement a routable IPv4 address plan for DSTM. 106 DSTM is targeted to help the interoperation of IPv6 newly deployed 107 networks with existing IPv4 networks. DSTM assumes that a users 108 objective in deploying an IPv6 network is to reduce the need and 109 reliability on IPv4 within a portion of their network. In addition the 110 IPv4 globally routable address space available to the network is a 111 scarce resource, and the user does not want to deploy DHCPv4[16] to 112 assign temporary IPv4 addresses to IPv6 nodes, and would rather require 113 those nodes to use IPv6 to obtain or be given the IPv4 temporary 114 addresses from DHCPv6. Also, to begin to reduce the IPv4 applications a 115 user has to support to obtain a temporary IPv6 IPv4-Mapped Address (see 116 Section 6), the client only has to run a DHCPv6 client process with the 117 DTI mechanisms in this specification. 119 The DSTM architecture is composed of a DHCPv6 server, that provides for 120 the assignment of IPv4 Global Addresses to IPv6 Hosts. The DHCPv6 121 server will allocate temporary IPv4 Global Addresses to IPv6 hosts. The 122 DHCPv6 server will also be used to maintain the mapping between the 123 allocated IPv4 address and the permanent IPv6 address of the host. Each 124 IPv6 DSTM host will have an IPv4 interface called the Dynamic Tunneling 125 Interface (DTI) designed to encapsulate IPv4 packets into IPv6 packets. 126 Also a DSTM daemon exists working with a DHCPv6 client to resolve the 127 address space mechanics, between IPv4 and IPv6. 129 The specification will begin by defining the terminology (section 2), 130 then section 3 provides a technical overview of the DSTM methodology as 131 a transition mechanism. Then in section 4 we provide a DSTM example. 132 Section 5 describes the DTI Architecture and Section 6 discusses 133 discusses the DHCPv6 extension requirements. Section 7 provides the 134 DSTM Applicability Statement. 136 2. Terminology 138 2.1 IPv6 AIIH Terminology 140 DSTM Domain The network areas on an Intranet where a 141 DHCPv6 Server has access to IPv6 nodes participating 142 in DSTM for that network. 144 DSTM Border Router A border router within a DSTM domain and 145 an IPv4-ONLY domain. 147 IPv6 Protocol Terms: See [3] 149 IPv6 Transition Terms: See [15] 151 DHCPv6 Terms: See [4,5] 153 DTI: Dynamic Tunneling Interface. An interface 154 encapsulating IPv4 packets into IPv6 packets. 156 IPv4 Global Address: An IPv4 address that is globally routable on 157 the Internet. 159 Tunnel End Point (TEP) Destination of the IPv6 packet containing an 160 IPv4 packet. In most cases this will be 161 a dual stack border router. 163 2.2 Specification Language 165 In this document, several words are used to signify the requirements 166 of the specification, in accordance with RFC 2119 [9]. These words 167 are often capitalized. 169 MUST This word, or the adjective "required", means that 170 the definition is an absolute requirement of the 171 specification. 173 MUST NOT This phrase means that the definition is an absolute 174 prohibition of the specification. 176 SHOULD This word, or the adjective "recommended", means 177 that there may exist valid reasons in particular 178 circumstances to ignore this item, but the full 179 implications must be understood and carefully 180 weighed before choosing a different course. 181 Unexpected results may result otherwise. 183 MAY This word, or the adjective "optional", means that 184 this item is one of an allowed set of alternatives. 185 An implementation which does not include this option 186 MUST be prepared to interoperate with another 187 implementation which does include the option. 189 silently discard 190 The implementation discards the packet without 191 further processing, and without indicating an error 192 to the sender. The implementation SHOULD provide 193 the capability of logging the error, including the 194 contents of the discarded packet, and SHOULD record 195 the event in a statistics counter. 197 3. DSTM Overview and Assumptions 199 DSTM as discussed in the introduction is a method which uses existing 200 protocols. DSTM does not specify a protocol. However, DSTM defines a 201 new DHCPv6 Extension for transition. 203 The motivation for DSTM is to provide IPv6 nodes a means to acquire an 204 IPv4 Global Address, for communications with IPv4-only nodes or IPv4 205 applications. 207 The core assumption within this mechanism is that it is totally 208 transparent to applications, which can continue to work with IPv4 209 addresses. It is also transparent to the network which carry only IPv6 210 packets. It is the authors viewpoint that the user in this case, has 211 deployed IPv6 to support end to end computing, without translation. 212 This aspect is fundamental during a transition process to guarantee that 213 every existing application will continue to work (e.g. IPsec, H.323), 214 which embed IPv4 addresses in the payload of a packet. 216 The DSTM model and assumptions are as follows: 218 - The DSTM domain is within an Intranet not on the Internet. 220 - IPv6 nodes do not maintain IPv4 addresses except on a temporary basis, 221 to communicate with IPv4-only and IPv4 Applications. 223 - Standard DHCPv6 is used to support the extension to provide 224 and accept from DHCPv6 Servers Global IPv4 Addresses. 226 - The DSTM domain for the IPv6 nodes will keep IPv4 routing 227 tables to a minimum and use IPv6 routing, hence, reducing 228 the network management required for IPv4 during transition. 230 - Once IPv6 nodes have obtained IPv4 addresses Dynamic Tunneling is 231 used to encapsulate the IPv4 packet within IPv6 and then forward 232 that packet to an IPv6 TEP, where the packet will be decapulated and 233 forwarded using IPv4. DHCPv6 is used to provide TEPs to IPv6 nodes 234 supporting DTI, as part of the new DHCPv6 Extension. 236 - Existing IPv4 Applications or nodes do not have to be modified to 237 communicate with DSTM. 239 - Implementation defined software will have to exist to support DSTM: 241 o Ability within a DHCPv6 Server implementation to maintain 242 configuration information about TEPs for encapsulating IPv4 243 packets between IPv6 nodes that can forward IPv4 packets to an 244 IPv4 routing realm, and to maintain a pool of Global IPv4 245 Addresses. 247 o Software within an IPv6 node to support the dynamic tunneling 248 mechanisms in this specification to encapsulate IPv4 packets 249 within IPv6 to send IPv4 packets on an IPv6 node. In addition 250 a daemon must exist to access a DHCPv6 client for Global IPv4 251 Mapped Addresses and TEPs. How this daemon communicates with 252 a DHCPv6 Client implementation is implementation defined, and 253 left as an exercise for implementors of this transition 254 mechanism. 256 o Software in DSTM Border Routers to recall or be able to cache 257 the association of IPv6 and IPv4 addresses of nodes during 258 decapsulation and encapsulation. 260 A simplistic overview of DSTM is as follows: 262 ----------------------------------------------- 263 | IPv4 Internet or Intranet 264 DSTM Domain Intranet | IPv4 Applications 265 | Domain 266 _____________________ | 267 | | | 268 | DHCPv6 Server | | 269 |_____________________| | 270 ^ | 271 | | 272 __________________ | _|_______ 273 | | | | | 274 | IPv6/IPv4 Node | | | DSTM | 275 |------------------| | | Border | 276 | DSTM Daemon | | | Router | 277 | DHCPv6 client |<------- | IPv6 | 278 |------------------| | & | 279 | DTI/Route |<-------------------->| IPv4 | 280 ------------------- --------- 281 | 282 ---------------------------------------------- 284 For an IPv6 host to participate in DSTM it MUST have a dual IP layer, 285 supporting both an IPv4 and an IPv6 stack. DSTM is not a solution for 286 IPv6 ONLY nodes. 288 4. DSTM Deployment Example 290 In the example below, the following notation will be used: 292 X will designate an IPv6 host with a dual stack, X6 will be the IPv6 293 address of this host and X4 the IPv4 address 294 Y will designate a DSTM border router at the boundary between an 295 IPv6 DSTM domain and an IPv4-only domain. 296 Z will designate an IPv4-only host and Z4 its address. 297 ==> means an IPv6 packet 298 --> means an IPv4 packet 299 ++> means a tunneled IPv4 packet is encapsulated in an IPv6 packet 300 ..> means a DNS query or response. The path taken by this 301 packet does not matter in the examples 302 "a" means the DNS name of a host 304 4.1 DSTM Client/Server Example 306 This example describes the case where an application (either compiled 307 for the IPv6 or IPv4 API) running on an IPv6 host (X6) wants to 308 establish a session with an IPv4 application on an IPv4-only host (Z4). 310 The IPv6 host is configured with the IPv6 address of a TEP, where an 311 IPv4 encapsulated packet will be sent. 313 The IPv4 routing table of node X is configured to send IPv4 packets to 314 the DTI interface. 316 DHCPv6 317 DNS 318 X6 Y6/Y4 Z4 319 | | | 320 |. . . . . . . .> Z | - X6 asks the DNS for an AAAA for "Z" 321 |<. . . . . . . . error | - the DNS answers with an error 322 |. . . . . . . .> Z | - X6 asks for the A RR for "Z" 323 |<. . . . . . . . Z4 | - the answer is Z4 324 | | | 325 | | | - The application sends its first IPv4 326 | | | packet which arrives to the DTI interface 327 | | | (If the application is compiled for IPv6 328 | | | this can be done through an IPv4-mapped 329 | | | address). 330 | | | 331 | | | - X6 needs an IPv4 address (first use) 332 |====> | | - X6 queries the DHCPv6 server for an 333 | | | IPv4 address using DHCPv6 334 |<==== | | - The DHCPv6 server locates the client 335 | | | and provides a temporary IPv4 336 | | | global address. 337 |+++++++++++>| | - The DTI sends the IPv6 packet to the 338 | | | TEP. 339 | |----------->| - Y sends the packet to the destination Z4 340 | | | - Y caches the association between 341 | | | the IPv4 and IPv6 address of X. 343 When Z responds the packet returns back through Y. Y having cached the 344 association between the IPv4 and the IPv6 address of X, is able to send 345 the packet encapsulating the IPv4 packet within IPv6 back to X. 347 5 DTI Architecture 349 The DTI interface is responsible for encapslating IPv4 packets within 350 IPv6 ones. IPv4 trafic can be directed to use this interface by an entry 351 in the host IPv4 routing table. This entry MUST be configured prior to 352 any use of the DSTM mechanism. 354 A conceptual model (not required) is the DTI interface is placed between 355 the IPv4 API and the IPv6 layer, as shown in the following figure, the 356 architectural example assumes a BSD UNIX type platform. 358 +------------||------------+------------||------------+--||--+ 359 | IPv6 API | IPv4 API | PF_ | 360 | | | ROUTE| 361 | +--------------------------+ | 363 | | | 364 +-----------------------------------------------------+------+ 366 On a DSTM IPv6 node a DHCPv6 client is running to manage the allocation 367 of the IPv4 Mapped Address. 369 The following example gives the configuration of an IPv4 routing table 370 with DTI. 372 All IPv4 packets except those to the 192.44.77/24 prefix are sent 373 through the dti0 interface. They will be encapsulated into IPv6 packets. 374 Packet to the 192.44.77/24 prefix will be sent natively on the link. 376 Routing tables 378 Internet: 379 Destination Gateway Flags Refs Use Mtu Netif Expire 380 default link#1 UGSc 3 0 1460 dti0 381 192.44.77.0/24 192.44.77.3 UC 0 0 1500 le0 - 382 192.44.77.3 8:0:2b:1c:af:15 UHLW 4 0 1500 le0 649 383 127.0.0.1 127.0.0.1 UHl 1 102 16384 lo0 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. If the interface is active, but has no IPv4 address. 389 When it has to send the first IPv4 packet, a request is sent to the 390 DHCPv6 client. The DHCPv6 client will send a DHCPv6 request to the 391 DHCPv6 server to get the temporary IPv4 Mapped Address and a TEP. 393 An IPv6 node can know it needs an IPv4 address if the DNS resolver on 394 the node knows that the destination address will be an IPv4 address. 395 Once the resolver knows this then a query to the interface index of the 396 node will inform the IPv6 node if it has an IPv4 interface configured. 397 This is just one example of how an implementation can determine if the 398 DSTM daemon must be called. 400 5.2 DTI Encapsulation of IPv4 packets 402 The protocol value for IPv4 encapsulation is 4 (as for IPv4 tunneling 403 over IPv4). When a tunneled packet arrives to the IPv6 destination, the 404 IPv6 header is removed and the packet is processed by the IPv4 layer. 405 The DSTM Border Router SHOULD cache the association between the IPv4 and 406 IPv6 source address. The IPv4 packet will then be forwarded by the DSTM 407 border router using the IPv4 infrastructure. 409 The IPv6 source address of an encapsulated packet will be the IPv6 410 address of the interface on which the IPv6 packet will be sent. 412 5.3 DTI IPv6 destination address 414 When a DTI has to encapsulate an IPv4 packet into an IPv6 packet. The 415 DTI has to determine the TEP IPv6 address for the destination. The TEP 416 can be the host destination or, if the destination host is IPv4-only, 417 the IPv6 address of an IPv4/IPv6 DSTM Border Router. 419 The TEP can be either statically configured or dynamically acquired when 420 the IPv6 node acquires an IPv4 Compatible Address from a DHCPv6 Server. 422 The TEP SHOULD be provided by the DHCPv6 server when the DSTM node 423 receives an IPv6 Mapped Address (section 6). But, a DSTM node MAY 424 manually configure the TEP during early deployment of IPv6, but this 425 will not scale and is not recommended as a long term transition 426 solution. 428 6. DHCPv6 Requirements 430 The DSTM processes will use the DHCPv6 protocol and extensions to 431 communicate between the DHCPv6 Server and the DHCPv6 Client. A new 432 extension is required for DHCPv6 to support DSTM. But there are some 433 additional requirements placed on the DSTM processes that are not 434 specific to the DHCPv6 protocol as a transition and interoperation set 435 of mechanisms for the IPv6 hosts. 437 6.1 DHCPv6 IPv4 Address Extension 439 The DHCPv6 IPv4 Address Extension informs a DHCPv6 Server or Client that 440 the IPv6 Address Extension [5] following this extension will contain an 441 IPv4 Mapped Address [20], or is a Request for an IPv4 Mapped Address 442 from a client. The extension can also provide an IPv6 address to be 443 used as the TEP to encapsulate an IPv4 packet within IPv6. 445 This extension can be used with the DHCPv6 Request, Reply, Release, and 446 Reconfigure-Init Messages for cases where a DHCPv6 wants to assign 447 clients IPv4 Mapped Addresses. 449 0 1 2 3 450 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 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Type | Length | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Tunnel End Point | 455 | (If Present) | 456 | (16 octets) | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 Type: TBD 460 Length: 0 or 16 461 Tunnel End Point: IPv6 Address if Present 463 An IPv4 Global Address Extension MUST only apply to the extension 464 following and not to any additional extensions in the DHCPv6 465 protocol. 467 6.1.1 Client Request of IPv4 Global Address Extension 469 When the client requests an IPv4 address from the DHCPv6 Server the TEP 470 field MUST not be present, in the IPv4 Address Extension. 472 The IPv6 Address Extension fields as specified in [5] and depicted below 473 for reference MUST be filled in as follows: 475 0 1 2 3 476 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 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Type = 1 | Length | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | status |C|I|L|Q|A|P| reserved |scope| prefix-len | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | (if present) | 483 | IP address (16 octets) | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | (if present) preferred lifetime (4 octets) | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | (if present) valid lifetime (4 octets) | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | (if present) DNS name (variable length) ... 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 Type 1 494 Length (unsigned integer, variable) The length of the Extension 495 in Octets. 497 status zero 499 bits C-P not set 501 scope zero 503 prefix-len zero 505 All other fields are not present. 507 6.1.2 Server Reply of IPv4 Global Address Extension 509 The server will reply to the client with an IPv4 Address Extension, that 510 can contain an IPv6 Address Tunnel End Point. 512 The server will fill in the IPv6 Address Extension depicted in 6.1.1 as 513 follows: 515 Type 1 517 Length (unsigned integer, variable) The length of the Extension 518 in Octets. 520 status zero unless the server could not provide the address 521 then the status will be set as defined in [5]. 523 bits C set 524 I not set 525 L set 526 Q-P not set 528 scope zero 530 prefix-len zero 532 IP Address IPv4 Mapped Address 533 Preferred Lifetime Present 535 Valid Lifetime Present 537 DNS Name Not Present 539 6.1.3 Client Processing of IPv4 Address Extension 541 The processing of the IPv4 Address Extension on the client is 542 implementation defined but here are some guidelines for developers. 544 When processing the IPv6 Address Extension following the IPv4 Address 545 Extension, the IP Address provided will be an IPv4 Mapped Address. A 546 conceptual implementation model would be to add this address to the IPv6 547 mechanisms that maintain timing procedures for IPv6 addresses on the 548 IPv6 stack, and then configure the IPv4 interface for DTI, as a 549 procedure called from the DHCPv6 client. 551 6.2 Server Processing of an IPv4 Address Extension 553 When a DHCPv6 Server receives an IPv4 Address Extension it MUST assume 554 that the next extension is a DHCPv6 Request or Release Message; the 555 Client is either Requesting an IPv4 Global Address or Releasing an IPv4 556 Global Address. If an address is present in either of these messages it 557 will be in the form of an IPv4 Mapped Address. 559 A DHCPv6 Server MAY send a Client a Reconfigure-Init message using the 560 IPv4 Address Extension to ask the Client to request an IPv4 Compatible 561 Address. The Client will recognize this by processing the IPv4 Address 562 Extension, as an Extension Request Extension in the Reconfigure-Init 563 message. 565 The Server will know a priori the IPv6 routable address, when sending a 566 Reconfiguration-Init message, of a Client within the Intranet, and may 567 use that address with its own IPv6 address as the transaction binding 568 cache until the DHCPv6 Client/Server protocol processing has completed, 569 if the server supports this optimization. 571 The Server will look in its implementation defined IPv4 Address 572 configuration to determine if a TEP is available for a specific IPv6 573 Address Prefix. If that is the case the Server will put the address for 574 the TEP in the IPv4 Address Extension. 576 6.3 Client Processing of an IPv4 Address Extension 578 When the Client supplies an IPv4 Global Address as a Request or Release 579 it MUST represent that address as an IPv4 Mapped Address. 581 The Client MUST not assume it can use the IPv4 Address until it has 582 received a corresponding Reply to the Client Request. 584 The Client MUST not update the DNS with this new address. 586 Once the Client is assured it can use the IPv4 Address it can perform 587 the following operations: 589 1. In an implementation defined manner the Client MUST assign the 590 address to an interface, supporting the Client's IPv4 stack 591 implementation. 593 2. In an implementation defined manner the Client MUST create an entry 594 as an IPv4 Mapped Address supporting the processing required 595 for an IPv6 address regarding the valid and preferred lifetimes 596 as specified in IPv6 Addrconf [19]. Once the IPv4 Mapped 597 address valid lifetime expires the IPv4 address MUST be deleted 598 from the respective interface and a DHCPv6 Release Message 599 MUST be sent to the DHCPv6 Server to delete the IPv4 600 Address from the Servers bindings. 602 3. If a TEP address is provided in the IPv4 603 Address Extension, the Client MUST create a configured tunnel 604 to the TEP address, in an implementation defined 605 manner. These encapsulation mechanisms are defined 606 in other IPv6 specifications [13, 15]. 608 7. Applicability Statement 610 DSTM is applicable for use from within the DSTM Domain to IPv4 nodes or 611 applications on a users Intranet or to access services over the 612 Internet. 614 DSTM's motivation is to support dual IP layer DSTM hosts to communicate 615 using global IPv4 addresses across an Intranet or Internet, where global 616 addresses are required. But, DSTM has been defined to also permit the 617 use of Private IPv4 address space to permit the Intranet use of DSTM 618 where users require temporary access to IPv4 services within their 619 Intranet. 621 DSTM requires the use of DHCPv6 to obtain IPv4 addresses and TEPs for a 622 DSTM host. Communications between the DSTM Daemon and the DHCPv6 client 623 is implementation defined. The DTI mechanism is also implementation 624 defined. DSTM does permit optionally for DSTM hosts to manually 625 configure TEPs for DTI for early deployment of DSTM but highly 626 recommends not doing this and configuring DHCPv6 servers with this 627 information is really the way to execute DSTM on an IPv6 Network. 629 DSTM also assumes that all packets returning from an IPv4 node to a DSTM 630 dual IP layer node return through the orginating DSTM Border Router, who 631 has cached the association of the DSTM's IPv4+IPv6 address. At this 632 time it is beyond the scope of DSTM to permit IPv4 packets destined for 633 DSTM hosts to return packets through a non-orginating DSTM border 634 router. 636 DSTM also through the new DHCPv6 extension permits Network Operators to 637 inform DSTM Hosts they will need IPv4 addresses for communications using 638 the DHCPv6 Reconfigure-Init message. 640 DSTM in the future can be extended to support multiple border routers 641 for returning IPv4 packets, and for the discovery of DSTM hosts using 642 IPv4 DNS queries as future work for DSTM. 644 NOTE - Authors will expand this section if required after the IETF 48 645 meeting at the NGTRANS meeting. 647 8. Security Considerations 649 The DSTM mechanism can use all the defined security specifications for 650 each functional part of the operation. For DNS the DNS Security 651 Extensions/Update can be used [10, 11], for DHCPv6 the DHCPv6 652 Authentication Message can be used [5], and for communications between 653 the IPv6 node, once it has an IPv4 address, and the remote IPv4 node, 654 IPSEC [8] can be used as DSTM does not break secure end- to-end 655 communications at any point in the mechanism. 657 Changes from draft 01 to draft 02 659 1. Added futher clarifications to DSTM components. 661 2. Added client/server details for DHCPv6 ngtrans extension. 663 3. Removed optional scenarios to simplify this mechanism. 665 4. Removed AIIH concepts and changed to be DSTM components. 667 5. Add Applicability Statement 669 6. Added acknowledgment section and new coauthors Francis Dupont 670 and Alain Durand. 672 Changes from draft 00 to draft 01 674 1. Added text explaining why the draft does not use DHCPv4 to assign 675 IPv4 compatible addresses to the "Introduction". 677 2. Defined what is mandatory and what is optional and added relative 678 text in various places to clarify this change. And added RFC 679 2119 adjectives to the spec where appropriate. 681 3. Scenario 1 where IPv6 node wants to communicate with IPv4 682 node is mandatory. 684 4. Scenarios 2 and 3 are now optional where an IPv6 node is 685 assigned an IPv4 compatible address because an external 686 IPv4 node is attempting communications with the IPv6 node. 688 5. For scenario 1 DHCPv6 is only needed for DSTM and not the 689 tightly coupled paradigm of a co-existent DHCPv6 and 690 DNS server. Also added mandatory and optional to the 691 DSTM AIIH/NODE/ROUTER Diagram. 693 6. Made Static Tunnel Endpoints mandatory and Dyanmic Tunnel 694 End Points optional. 696 7. Fixed DHCPv6 Reconfigure statements to take into account 697 changes to the Reconfigure message in the DHCPv6 working 698 group, to support AIIH processing. 700 Acknowledgments 702 The authors would like to acknowledge the implementation contributions 703 by Stephane Atheo at ENST Bretagne who has implemented a DSTM prototype 704 on FreeBsd and their input to this specification. We would also like to 705 thank the NGTRANS Working Group for their input. 707 References 709 [1] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 710 13, RFC 1034, USC/Information Sciences Institute, November 1987. 712 [2] Mockapetris, P., "Domain Names - Implementation and Specifica- 713 tion", STD 13, RFC 1035, USC/Information Sciences Institute, 714 November 1987. 716 [3] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) 717 Architecture", RFC 2460, December 1998. 719 [4] J. Bound, M. Carney, and C. Perkins. Dynamic host Configuration 720 Protocol for IPv6. draft-ietf-dhc-dhcpv6-15.txt May 2000 (work 721 in progress). 723 [5] J. Bound, M. Carney, and C Perkins. Extensions for the Dynamic 724 host Configuration Protocol for IPv6. 725 draft-ietf-dhc-dhcpv6ext-12.txt May 2000. (work in progress). 727 [6] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound. Dynamic Updates 728 to the Domain Name System (DNS). RFC 2136, April 1997. 730 [7] William R. Cheswick and Steven Bellovin. Firewalls and Internet 731 Security. Addison-Wesley, Reading, MA 1994 (ISBN: 732 0-201-63357-4). 734 [8] IPSEC - This needs to include the Arch, Auth, and ESP specs. 736 [9] S. Bradner. Key words for use in RFCs to indicate Requirement 737 Levels. RFC 2119, March 1997. 739 [10] D. Eastlake and C. Kaufman. Domain Name System Security 740 Extensions. RFC 2065, January 1997. 742 [11] D. Eastlake. Secure Domain Name System Dynamic Update. 743 RFC 2137, April 1997. 745 [12] R. Callon and D. Haskins. Routing Aspects Of IPv6 Transition 746 RFC 2185, September 1997. 748 [13] A. Conta and S. Deering. Generic Packet Tunneling in IPv6. 749 RFC 2473, December 1998. 751 [14] E. Nordmark. Stateless IP/ICMP Translator (SIIT) 752 draft-ietf-ngtrans-siit-03.txts, November 1998 753 (work in progress) 755 [15] R. Gilligan and E. Nordmark. Transition Mechanisms for IPv6 756 hosts and Routers. draft-ietf-ngtrans-trans-mech-01.txt, 757 August 1998 (work in progress). 759 [16] R. Droms. Dynamic host Configuration Protocol. 760 RFC 2131, March 1997. 762 [17] Rekhter, Moskowitz, Karrenburg, Groot. Address Allocation 763 for Private Networks. RFC 1918. February 1996. 765 [18] This needs to reflect the new DNS work for IPv6. 767 [19] Thomson, Narten. IPv6 Stateless Address Configuration. 768 RFC 2462, December 1998. 770 [20] Hinden, Deering. IP Version 6 Addressing Architecture. 771 RFC 2373, July 1998. 773 Authors' Address 775 Jim Bound 776 Compaq Computer Corporation 777 110 Spitbrook Road, ZKO3-3/W20 778 Nashua, NH 03062 779 Phone: (603) 884-0400 780 Email: bound@zk3.dec.com 782 Laurent Toutain 783 ENST Bretagne 784 BP 78 785 35 512 Cesson S�vign� Cedex 786 Phone : +33 2 99 12 70 26 787 Email : Laurent.Toutain@enst-bretagne.fr 789 Hossam Afifi 790 ENST Bretagne 791 BP 78 792 35 512 Cesson S�vign� Cedex 793 Phone : +33 2 99 12 70 36 794 Email : Hossam.Afifi@enst-bretagne.fr 796 Francis Dupont 797 ENST Bretagne 798 BP 78 799 35 512 Cesson S�vign� Cedex 800 Phone : +33 2 99 12 70 36 801 Email : Francis.Duponti@enst-bretagne.fr 803 Alain Durand 804 Sun Microsystems 805 901 San Antonio Road 806 UMPK 17-202 807 Palo Alto, CA 94303-4900 808 Tel: +1 650 786 7503 809 Fax: +1 650 786 5896 810 Email: Alain.Durand@sun.com