idnits 2.17.1 draft-soliman-siit-dstm-01.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? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard 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. ** The abstract seems to contain references ([SIIT]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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: For an IPv6 MN to successfully communicate with an IPv4 node via SIIT, the Home Address option MUST not be forwarded in the translated IPv4 packets. Hence an SIIT router has to remove the Home option from all outbound packets during the translation. One way of achieving this is by replacing the source address with the Home address before translating the header. When an inbound packet is received the packet will be encapsulated to the Home address of the MN. If the SIIT router includes a Binding to the MN's COA, the COA will be used as the destination address as per [MIPv6]. == 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: For communication between an IPv6 MN and an IPv4 MN to succeed, an IPv6 MN MUST not place any destination options after the ESP header for all CNs that have an IPv4-mapped address. This should be done to make sure that packets do not get discarded by the IPv4 host due to the inclusion of an unknown (to an IPv4 node) Destination option. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2000) is 8563 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TRANS- MECH' is mentioned on line 159, but not defined == Missing Reference: 'MIPv6' is mentioned on line 433, but not defined == Unused Reference: 'MIPV6' is defined on line 783, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2373 (ref. 'ADDR-ARCH') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2460 (ref. 'IPv6') (Obsoleted by RFC 8200) == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-12 ** Obsolete normative reference: RFC 2765 (ref. 'SIIT') (Obsoleted by RFC 6145) == Outdated reference: A later version (-08) exists of draft-ietf-ngtrans-dstm-03 -- Possible downref: Normative reference to a draft: ref. 'DSTM' Summary: 10 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NGTRANS Working Group Hesham Soliman, 3 INTERNET Draft Ericsson 4 Expires: January 2001 Erik Nordmark 5 Sun Microsystems 6 November 2000 8 Extensions to SIIT and DSTM for enhanced routing of 9 inbound packets 10 12 Status of this memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or cite them other than as "work in progress". 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/lid-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 This document is an individual submission to the IETF. Comments 32 should be directed to the authors. 34 Abstract 36 This document specifies a transition mechanism that combines both 37 [SIIT] and DSTM mechanisms by adding some extensions to allow fast 38 routing of inbound packets. This will result in a more decentralised 39 and flexible tool to allow V6 only hosts to communicate with V4 only 40 hosts. 42 The proposed extensions will provide a way that allows SIIT routers 43 to route packets addressed to a host running a single IPv6 stack with 44 minimum delay which is suited to real time services. 46 TABLE OF CONTENTS 48 1. Introduction.......................................... 3 50 2. Terminology........................................... 4 52 2.1. Addresses..................................... 4 54 2.2. Requirements.................................. 4 56 3. Operation overview.................................... 5 58 3.1 Communication between AIIH and SIIT routers... 6 60 3.2. Support for Mobility.......................... 7 62 3.2.1 Connection intiated by the V4 MN........ 7 64 3.2.2 Connection intiated by the V6 MN........ 8 66 3.2.3 SIIT extensions for mobility support.... 9 68 3.2.4 Considerations for MNs using MIPv6...... 9 70 4. Message formats for AIIH-SIIT router communication ... 10 72 4.1. Discovering an AIIH server ................... 10 74 4.2. Address-mapping cache entry .................. 10 76 4.3. Address-mapping cache Request................. 11 78 4.4. Address-mapping cache Reply................... 12 80 4.5. DELTA updates................................. 14 82 4.6. Address-mapping cache Acknowledgement......... 15 84 4.7. Keepalive message............................. 15 86 5. Security considerations............................... 16 88 6. Acknowledgements...................................... 16 90 7. Authors addresses..................................... 16 92 8. References............................................ 17 94 1. Introduction 96 The expected increase in use of real time services like voice and 97 video over IPv6 places some requirements on packet processing delay 98 within routers. Furthermore, currently voice services have very 99 strong requirements on network reliability and the frequency of 100 network failures. These requirements are expected to maintain the 101 same standard in future or even higher. For the transition between 102 IPv4 and IPv6 to be successful, migration tools need to meet the 103 requirements of real time services for processing speed and 104 reliability. 106 The translation mechanism specified in [SIIT] provides a flexible and 107 decentralised function to allow a host running an IPv6 stack to 108 communicate with a host running an IPv4 stack. The ability to 109 decentralise this function can be very powerful from a reliability 110 point of view. Such distribution allows current connections to 111 survive despite the failure of one SIIT router. 113 However, due to the stateless nature of [SIIT], there is no mechanism 114 defined to allow a router implementing SIIT to route IPv4 packets to 115 IPv6 hosts configured with an IPv4-translated address in a fast 116 manner. 118 In this document an IPv6 host is assumed to acquire an IPv4 address 119 by using the DSTM technology specified in [DSTM]. This document 120 introduces a mechanism that allows an SIIT-enabled router to forward 121 the received IPv4 packets to their final destination (being the IPv6 122 host) with minimum delay. As mentioned earlier, this is an important 123 requirement to real time services. 125 Packets sent from IPv6 node to IPv4-mapped address can be routed to 126 an SIIT router by it injecting a route for ::ffff:0:0/96. If a site 127 has multiple SIIT routers they can all inject the above route into 128 the site's IPv6 routing. This will cause IPv6 nodes, through regular 129 IPv6 routing, to send packets to the closest SIIT router (Note that 130 if there are multiple SIIT routers they can also inject longer IPv4- 131 mapped address prefix routes into the site such as 132 ::ffff:0:0:129.146.0.0/112. The above /96 route is the equivalent of 133 an IPv4 default route). 135 Packets from the SIIT router to the IPv6 node need to be encapsulated 136 (as specified in RFC 2473 - IPv6 in IPv6) since their IPv4- 137 translatable IPv6 address does not contain enough toplogical 138 information to route the packets to the link/node. The goal of the 139 mechanisms in this document is for SIIT routers to be able to do this 140 encapsulation without any manual configuration but also without a 141 single SIIT router being a single point of failure. To accomplish 142 this the SIIT routers need to be able to dynamically determine, for 143 each IPv6-only node in the site, the mapping between the node's IPv4- 144 translatable address and the node's 'regular' (global or site-local) 145 IPv6 address. 147 Some extensions are proposed to an AIIH server and [SIIT] to allow an 148 SIIT router to request information regarding the mapping of 149 temporarily allocated IPv4 addresses and a host's IPv6 address. 150 It should be noted that although this draft focuses on the case where 151 SIIT is used, the protocol proposed between SIIT and an AIIH server 152 is independent of the transition mechanism and can be used between 153 AIIH servers and any other node in the network seeking such mapping 154 between a node's IPv6 address and its IPv4 address allocated by a 155 DHCPv6 server. 157 2. Terminology 159 This documents uses the terminology defined in [IPv6], [TRANS- MECH] 160 and [SIIT] with these clarifications: 162 SIIT router: 164 A router implementing IPv4->IPv6 translation function 165 as outlined in [SIIT] 167 2.1. Addresses 169 In addition to the forms of addresses defined in [ADDR-ARCH] this 170 document uses the IPv4-translated addresses defined in [SIIT]. The 171 address forms are: 173 IPv4-mapped: 175 An address of the form 0::ffff:a.b.c.d which refer to a 176 node that is not IPv6-capable. In addition to its use in 177 the API this protocol uses IPv4-mapped addresses in IPv6 178 packets to refer to an IPv4 node. 180 IPv4-compatible: 182 An address of the form 0::0:a.b.c.d which refers to 183 an IPv6/IPv4 node that supports automatic tunneling. 184 Such addresses are not used in this protocol. 186 IPv4-translated: 188 An address of the form 0::ffff:0:a.b.c.d which 189 Refers to an IPv6-enabled node. Note that the 190 prefix 0::ffff:0:0:0/96 is chosen to checksum to 191 zero to avoid any changes to the transport protocol's 192 pseudo header checksum. 194 2.2. Requirements 196 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, 197 SHOULD,SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear 198 in this document, are to be interpreted as described in [KEYWORDS]. 200 3. Operational overview 202 3.1 Communication betweem AIIH servers and SIIT routers 204 The AIIH server described in [DSTM] allows an IPv6 host to acquire an 205 IPv4 address for the duration of its communication with an IPv4 host. 206 Outbound packets (originating from the V6 host) containing an IPv4- 207 translated source and an IPv4-mapped destination address can then be 208 translated by an SIIT router and forwarded according to the 209 translation rules in [SIIT]. 211 For inbound packets (addressed to a host's temporary IPv4 address) an 212 SIIT router needs to find out the final destination address (IPv6) 213 for the packets after the translation is performed. To have this 214 knowledge, an SIIT router requires a mapping between all the leased 215 IPv4 addresses and their corresponding hosts' IPv6 addresses. This is 216 achieved via communication with an AIIH server as illustrated below. 218 +--------+ 219 | AIIH | Client-Server communication 220 | Server | 221 +--------+----+------------+------------+-------------+ 222 | | | | | 223 | | | | | 224 | +--------+ +--------+ +--------+ +--------+ 225 | | SIIT | | SIIT | | SIIT | | SIIT | 226 | | router | | router | | router | | router | 227 | +--------+ +--------+ +--------+ +--------+ 228 | 229 | Client-server 230 +---------------------+--------+ 231 | IPv6 | 232 | Node | 233 +--------+ 235 Fig.1 Communication between an SIIT router and AIIH 237 In this memo, the AIIH server acts as a central database containing 238 the mapping information between all pooled IPv4 addresses and their 239 corresponding IPv6 addresses. In addition, the server is expected to 240 update all registered SIIT routers whenever the information in the 241 address-mapping cache changes. 243 The communication between the SIIT routers and AIIH server is 244 established over TCP connections. The mechanism described below 245 details the information exchanged between the SIIT router and the 246 AIIH server. In addition, a Keepalive message is introduced on 247 application level to ensure the availability of the connection and 248 avoid confusion between the client and server during connection re- 249 establishment. 251 After starting up, an SIIT router should discover an AIIH server 252 within the same domain. This information can be manually configured 253 in the router or can be found through other mechanisms. An SIIT 254 router can then request the Address-mapping cache in an AIIH server. 255 The address-mapping cache consists of a number of entries, each 256 related to one of the pooled IPv4 addresses. Hence the number of 257 entries must be equal to the number of pooled IPv4 addresses in the 258 AIIH server. 260 The request for address-mapping cache also acts as a registration 261 mechanism to inform the AIIH server that an SIIT router exists and 262 should be informed about further updates to the address-mapping 263 cache. 265 The AIIH server SHOULD reply to the SIIT router's request by sending 266 a message containing all the pooled IPv4 addresses and their 267 corresponding IPv6 address. Each entry in the address-mapping cache 268 should contain the leased IPv4 address, the corresponding IPv6 269 address and the lifetime for which this information is valid. 271 The AIIH server SHOULD send the entire cache to the SIIT router. This 272 includes entries corresponding to unallocated IPv4 addresses. Entries 273 corresponding to unallocated IPv4 addresses MUST have the IPv6 274 address field set to the Unspecified address. 276 The AIIH server MUST record the IP address of the SIIT router 277 requesting the information. This will be needed for future updates of 278 the address-mapping cache. It may be more appropriate to use Site- 279 local addresses (if they are defined) for the communication between 280 the SIIT router and the AIIH server to avoid problems that could 281 arise due to renumbering. However, this is left to the network 282 administrator's discretion. 284 Before allocating an IPv4 address to an IPv6 node, the AIIH server 285 MUST inform all registered SIIT routers by sending an update message 286 containing the new entry. The AIIH server SHOULD wait for the 287 Acknowledgement message from all registered SIIT routers before 288 configuring the information in the IPv6 node. This is to make sure 289 that inbound packets will be forwarded with minimum delay. 291 To avoid long delays for Acknowledgements coming from SIIT routers a 292 timeout period needs to be used by AIIH servers. 294 When a packet having an IPv6-translated source address and an IPv6- 295 mapped destination address reaches an SIIT router, the packet will be 296 translated and forwarded as explained in [SIIT]. Upon reception of an 297 inbound IPv4 packet, the SIIT router MUST search for the destination 298 address in its address-mapping cache that was requested from the AIIH 299 server. If the address is found and it points to a valid IPv6 300 address, the packet should be translated as specified in [SIIT] and 301 tunnelled to that IPv6 address. 303 If a valid IPv6 address corresponding to the IPv6-translated address 304 was not found, an SIIT router SHOULD request that Address-mapping 305 cache entry from the AIIH server. An appropriate timeout period 306 should be applied after which an ICMP error (destination unreachable) 307 should be sent to the IPv4 sender. 309 When tunnelling inbound packets, the outer header MUST contain the 310 SIIT router's address as a source and the IPv6 node's address as a 311 destination. The inner header should contain the IPv6-mapped address 312 as a source address (formed from the source address in the original 313 v4 packet) and the IPv6-translated address in the destination field. 314 The encapsulation should follow the rules mentioned in RFC 2473. 316 3.2 Support for mobility 318 This chapter aims to explain how an IPv4 MN would interact with an 319 IPv6 MN using an IPv4-translated address. Two different scenarios are 320 considered: 322 a) V4 node intiating the connection and 324 b) V6 node intiating the connection 326 It should be noted that no impact on the MIPv6 or MIPv4 protocols is 327 introduced due to the extensions proposed in this memo. 329 3.2.1 Connection initiated by the V4 MN 331 A node running an IPv4 stack may start communication with a node 332 running IPv6. A DNS request is sent to the V6 domain. According to 333 [DSTM], the local V6 domain can assign a V4 address to the IPv6 host 334 and forward the DNS reply to the V4 node. The local AIIH server MUST 335 also update all SIIT routers within the domain. This is done by 336 sending an update message containing the IPv6 node's home address, 337 the assigned IPv4 address and the entry's lifetime in the address- 338 mapping cache. All packets destined to the IPv6 node will be 339 translated by the receiving SIIT router and encapsulated to the 340 node's home address. 342 If the MN is located in a foreign network, the packets should be 343 tunnelled by the HA to its COA according to [MIPv6]. Since the MN 344 will have the SIIT router's address received in the encapsulated 345 packet, this should result in the sending of a BU from the MN to the 346 SIIT router according to [MIPv6]. 348 In this manner, route optimisation can be achieved within the V6 349 network, ie. between the MN and the SIIT router. On the other hand, 350 route optimisation can not be achieved within the MIPv4 domian. Since 351 MIPv4 messages are sent over UDP, an SIIT router will not be able to 352 understand any BU messages sent from the V4 node's HA. Hence all BU 353 messages will be silently discarded by the final destination (IPv6 354 node). This should not cause any problems for the MIPv4 355 implementation as route optimisation is not mandatory in MIPv4. 356 Furthermore, since MIPv4 messages are not piggybacked on data 357 packets, no service interruption is expected due to dropping the 358 MIPv4 BUs. 360 It should be noted that the Address-mapping cache need not be tightly 361 coupled to the Binding Cache implementation. Hence an SIIT router may 362 contain the IPv6 MN's home address in its Address-mapping cache and 363 its COA in the Binding cache. In the case of an SIIT router's 364 failure, packets may be routed to another SIIT router that is not 365 updated with the MN's current location. This will result in 366 triangular routing within the v6 domain until the MN updates the new 367 SIIT router with its current location. This may result in some delays 368 that might be encountered due to the number of extra hops introduced 369 by triangular routing. 371 3.2.2 Connection intiated by the V6 MN 373 In this memo the actions required by an IPv6 MN to communicate with 374 an IPv4 MN depends on its location at the time the communication is 375 initiated and whether its current domain supports an AIIH server. 377 If the MN is located in its home domain, which supports AIIH, the MN 378 can request an IPv4 address as outlined in [DSTM]. The AIIH server 379 should allocate an IPv4 address to the MN and update all known SIIT 380 routers. 382 Upon successful allocation of the IPv4 address, the MN can start 383 communicating with the V4 node in the normal manner. 385 If the MN is located in a foreign domain, it may choose to request an 386 IPv4 address from the local AIIH server, provided one exists within 387 the domain and no local policy stops such request. Upon successful 388 allocation of the address, the AIIH server should update all 389 registered SIIT routers. The MN should then update its home DNS by 390 sending a DNS update message. This would require a pre-existing 391 security association with the Home DNS. 393 Alternatively, the MN may choose to tunnel a request for an IPv4 394 address to the Home AIIH server. The Home AIIH server would then 395 allocate an address and update all the SIIT routers within the Home 396 domain. All IPv4 packets from this point onward will be received 397 within the home network and forwarded to the MN's COA via the HA. 399 It should be noted that by requesting an address from the local AIIH 400 server less delays would be encountered for inbound packets, ie. 401 triangular routing will be achieved (compared to rectangular routing 402 when requesting an address from the Home AIIH server). On the other 403 hand, an IPv4 address from the Home domain would last even when the 404 MN moves to a new domain (another foreign domain) which may not be 405 possible when getting an address from the current domain. 406 For example, some domains with a limited IPv4 address pool may wish 407 to restrict the use of such addresses to nodes that are physically 408 located within their domain. The method of policing the use of IPv4 409 addresses is outside the scope of this memo. 411 Hence the decision as to which method should be used to get an IPv4 412 address (Home vs visited domain) is left to the MN and the local 413 policies within each domain. 415 3.2.3 SIIT extensions for mobility support 417 According to [MIPv6] a MN MUST include a Home Address option in all 418 outbound packets when located in a foreign network. Furthermore, 419 every CN MUST be able to process the Home Address option. When the 420 ESP or the AH headers are used for outbound packets, the Home Address 421 option is added before the IPsec header to enable the CN to process 422 the IPsec header. Hence the Home Address option will always be 423 visible to intermediate nodes. 425 For an IPv6 MN to successfully communicate with an IPv4 node via 426 SIIT, the Home Address option MUST not be forwarded in the translated 427 IPv4 packets. Hence an SIIT router has to remove the Home option from 428 all outbound packets during the translation. One way of achieving 429 this is by replacing the source address with the Home address before 430 translating the header. When an inbound packet is received the packet 431 will be encapsulated to the Home address of the MN. If the SIIT 432 router includes a Binding to the MN's COA, the COA will be used as 433 the destination address as per [MIPv6]. 435 To avoid triangular routing in the IPv6 domain, it is recommended 436 that SIIT routers process BU's and maintain a Binding Cache. 438 3.2.4 Considerations for Mobile Nodes using MIPv6 440 For communication between an IPv6 MN and an IPv4 MN to succeed, an 441 IPv6 MN MUST not place any destination options after the ESP header 442 for all CNs that have an IPv4-mapped address. 443 This should be done to make sure that packets do not get discarded by 444 the IPv4 host due to the inclusion of an unknown (to an IPv4 node) 445 Destination option. 447 4. Message formats for communication between AIIH and SIIT routers 449 4.1. Discovering an AIIH Server 451 Ultimately it is advantageous that an SIIT router discovers an AIIH 452 server without the need for manual configuration. Although manual 453 configuration can also be allowed, the aim of this section is to 454 recommend other dynamic mechanisms. 456 Since AIIH servers are essentially combined DHCP and DNS servers, 457 DHCP server mechanisms can be used to discover the DHCP server's IP 458 address. The next step is to check whether the DHCP server located 459 implements the mechanism proposed in this memo. This can be achieved 460 by sending the address-mapping cache request message shown below. A 461 reception of the address-mapping cache will indicate the support for 462 this mechanism. 464 4.2 Address-mapping cache entry 466 Figure 2 below shows the structure of a single entry in the address- 467 mapping cache. Each address-mapping cache reply message may include a 468 large number of entries. Each entry contains: an IPv6 address, an 469 IPv4 address and the corresponding lifetime. Entries received by SIIT 470 routers are stored in the address-mapping cache. 472 0 1 2 3 473 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 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | IPv4 address | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | | 479 | IPv6 address | 480 | | 481 | | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Lifetime | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 Fig. 2. Address-mapping cache entry 488 IPv4 address IPv4 address in an AIIH server's address pool 490 IPv6 address IPv6 node's address. If the IPv4 address is 491 Not allocated to any IPv6 nodes, this field 492 MUST be set to the Unspecified address. 494 Lifetime A 32-bit unsigned number indicating the 495 expiry time of this entry in seconds. 496 The expiry time for this entry MUST be equal to 497 or less than the lifetime of the IPv4 address. 499 4.3. Address-mapping cache Request 501 The Address-mapping cache request message format is shown below. This 502 message is sent by SIIT routers to request the mapping between IPv4 503 and IPv6 addresses. The details of the message are explained below. 505 0 1 2 506 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 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 |Msg-typ| Length |E| Reserved | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | IPv4 address | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 . 515 . 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | IPv4 address | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 Fig. 3. Address-mapping cache request 523 Msg-type = 1 Indicates address-mapping cache request 524 message. 526 Length The number of 32-bit words after the Reserved 527 field. Ie. the number of IPv4 addresses 528 included. MUST be Set to zero if the E flag is 529 set. 531 E If set, indicates a request for the entire 532 cache. If not set the message MUST include one 533 or more IPv4 addresses. 535 Reserved An 11-bit reserved field. MUST be set to zero. 537 The message can be sent to request mappings for certain IPv4 538 addresses or, alterntively, a client may request the mappings for the 539 entire cache. 540 If the E flag is set, it shows that the client requests a mapping for 541 the entire cache and the length field MUST be set to zero. Otherwise, 542 the client's request is only for certain IPv4 addresses and the 543 length field should be set to the number of IPv4 addresses included 544 in the message. 546 4.4 Address-mapping Cache reply 548 The address-mapping cache reply is sent by the AIIH server and 549 contains the mapping information requested by the client. If the 550 entire cache was requested, the AIIH server MUST return all mappings 551 in the cache. 553 0 1 2 3 554 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 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 |Msg-typ| Length | Code |M| Reserved | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | Transaction ID | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | IPv4 address | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | | 563 | IPv6 address | 564 | | 565 | | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | Lifetime | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 . 571 . 573 . 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | IPv4 address | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | | 578 | IPv6 address | 579 | | 580 | | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | Lifetime | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 Fig. 4. Address-mapping cache reply 587 Msg-type = 2 Indicates a message reply type. 589 Length The number of 32-bit words following the 590 Packet ID field. 592 M If set indicates more messages will be 593 received. This indicates that the reply 594 couldn't be placed in one message. 596 Reserved 7-bit reserved field. MUST be set to zero. 598 Transaction ID A 32-bit unsigned number identifying each 599 transaction (ie. client request). 601 Code Shows the status of the operation. Values of 5 602 and above provide reasons for operation 603 failure. 605 Reserved values : 606 0 Operation successful. 607 5 Operation failed. Reason unspecified. 608 6 Poorly formed message. 610 In the case where the client has requested the entire cache and the 611 length of the cache is larger than the maximum possible length 612 allowed in the packet, the AIIH server should send multiple reply 613 messages. Only the last message should have the M flag set to zero to 614 indicate that the entire cache was sent to the client. 616 The code field shows the result of the processing of the client's 617 request message. If the field includes a value corresponding to any 618 of the error values mentioned above, no more entries should exist in 619 the message. Hence the length field MUST be set to zero. 621 A transaction id field is used to uniquely identify each request. 622 This is needed for the client to be able to inform the server of 623 erroneous packets transferred in a transaction which may result in 624 the server restarting the transaction. 626 4.5 DELTA update messages 628 DELTA update messages are used to send unsolicited address-mapping 629 cache updates due to changes in one or more entries. For example, if 630 a an IPv4 address was allocated to a different IPv6 node, or for 631 invalidation of certain entries. An SIIT router SHOULD acknowledge 632 DELTA update messages. 634 0 1 2 3 635 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 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 |Msg-typ| Length |M| Reserved | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | Transaction ID | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | IPv4 address | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 | | 644 | IPv6 address | 645 | | 646 | | 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 | Lifetime | 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 Msg-type = 3 Indicates a message reply type. 653 Length The number of 32-bit words following the 654 Packet ID field. 656 M If set indicates more messages will be 657 received. This indicates that the reply 658 couldn't be placed in one message. 660 Transaction ID A 32-bit unsigned number identifying each 661 transaction (ie. client request). 662 Reserved 11-bit reserved field. MUST be set to zero. 664 4.6 Address-mapping cache Acknowledgement 666 Acknowldgement messages should be sent by the clients upon reception 667 of an Address-mapping cache reply message from an AIIH server. An 668 Acknowledgement message contains a code field that shows the result 669 of processing the server's last message. Clients may choose not to 670 send an acknowledgement for each received packet. However, an SIIT 671 router MUST send an acknowledgement with the appropriate code value 672 whenever it receives an erroneous message from an AIIH server. 674 0 1 2 3 675 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 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 |Msg-typ| Code | Reserved | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | Transaction ID | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 Msg-type = 4 Indicates acknowledgement type. 684 Reserved 24-bit reserved field. MUST be set to zero. 686 Transaction ID A 32-bit unsigned number identifying each 687 transaction (ie. client request). 689 Code Indicates the status of the operation, whether 690 it succeeded or not. 692 Reserved values : 693 0 Operation successful 694 5 Operation failed. Error unspecified 695 6 Poorly formed message. 697 The transaction id field identifies the transaction for which an 698 acknowledgement is being sent. 700 4.7 Keepalive message 702 Keepalive messages are introduced to ensure the availability of the 703 connection between the SIIT routers and AIIH servers. The messages 704 can be sent by either the clients or the server. 706 It is recommended that the message is sent once per minute by each 707 application. Each application should wait for a random length of time 708 after starting up before sending the first message. 710 0 1 2 3 711 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 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 | Msg-type| Sequence no |R| Rsvd | 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 Msg-type = 5 Indicates a keepalive message type. 718 Sequence number A 16-bit unsigned word that is used to 719 identify the message. 721 R If the R flag is set it indicates that this 722 is a reply message. 724 Rsvd A 12-bit reserved field. MUST be set to zero. 726 The sender of a Keepalive message should generate the sequence number 727 field by using a 16-bit rolling counter. 728 The receiver of a Keepalive message MUST echo that message with the 729 same sequence number and set the R flag in the reply. 731 5. Security considerations 733 The reachability of an IPv6 node from an IPv4 requires that a unique 734 IPv4 address is assigned to the IPv6 node. Since one of the main 735 reasons for migrating to IPv6 is the scarcity of IPv4 addresses, such 736 addresses need to be assigned to hosts in an optimal manner and only 737 when needed (ie. on demand). The assignment of IPv4 addresses to IPv6 738 nodes based on DNS queries by the IPv4 host raises some security 739 concerns and is subject to DoS attacks. A malicious IPv4 node can 740 send frequent DNS requests for some IPv6 to cause the AIIH server to 741 run out of IPv4 addresses and allocating all the pooled addresses to 742 IPv6 nodes that do not need them. This revision of the draft does not 743 address this issue. 745 6. Acknowledgements 747 The authors would like to thank Mattias Pettersson and Conny Larsson 748 for their careful reviews of this draft. 750 7. Author's Addresses 752 Hesham Soliman 753 Ericsson Australia 754 61 Rigall St., Broadmeadows 755 Melbourne, Victoria 3047 756 AUSTRALIA 757 Phone: +61 3 93012049 758 Fax: +61 3 93014280 759 E-mail: Hesham.Soliman@ericsson.com.au 761 Erik Nordmark 762 Sun Microsystems, Inc. 763 901 San Antonio Road 764 Palo Alto, CA 94303 765 USA 767 phone: +1 650 786 5166 768 fax: +1 650 786 5896 769 email: nordmark@sun.com 771 7. References 773 [ADDR-ARCH] Deering, S. and R. Hinden, Editors, "IP Version 6 774 Addressing Architecture", RFC 2373, July 1998. 776 [IPv6] Deering, S. and R. Hinden, Editors, "Internet Protocol, 777 Version 6 (IPv6) Specification", RFC 2460, December 778 1998. 780 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 781 Requirement Levels", BCP 14, RFC 2119, March 1997. 783 [MIPV6] D. Johnson and C. Perkins, "Mobility Support in IPv6", 784 draft-ietf-mobileip-ipv6-12.txt. Work in progress. 786 [SIIT] E. Nordmark, "Stateless IP/ICMP Translation Algorithm", 787 RFC 2765, February 2000. 789 [DSTM] J. Bound et al, _Dual Stack Transition Mechanism_, 790 draft-ietf-ngtrans-dstm-03.txt (work in progress). 792 This Internet-Draft expires in January 2001.