idnits 2.17.1 draft-ietf-ngtrans-siit-dstm-01.txt: -(64): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(385): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 Internet-Drafts being working documents. ** 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. == There are 6 instances of lines with non-ascii characters in the document. == 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 ([DSTM], [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. This is achieved 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 2001) is 8191 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 161, but not defined == Missing Reference: 'MIPv6' is mentioned on line 451, but not defined == Unused Reference: 'MIPV6' is defined on line 807, 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-13 ** Obsolete normative reference: RFC 2765 (ref. 'SIIT') (Obsoleted by RFC 6145) == Outdated reference: A later version (-08) exists of draft-ietf-ngtrans-dstm-04 -- Possible downref: Normative reference to a draft: ref. 'DSTM' Summary: 11 errors (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF - NGTRANS Working Group Hesham Soliman, 3 INTERNET Draft Ericsson 4 Expires: August 2001 Erik Nordmark 5 Sun Microsystems 6 November 2001 8 Extensions to SIIT and DSTM for enhanced routing of 9 inbound packets 10 12 Status of this memo 14 This document is a submission by the NGTRANS Working Group of the 15 Internet Engineering Task Force (IETF). Comments should be submitted 16 to the ngtrans@sunroof.eng.sun.com mailing list. 18 This document is an Internet-Draft and is in full conformance 19 with all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that other 22 groups may also distribute working documents as Internet-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 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/lid-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 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 IPv6-only nodes to communicate with IPv4- 40 only nodes. 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. It should be 45 noted that the proposed protocol between SIIT routers and AIIH 46 servers is generic and is not limited to its use between these two 47 nodes. This protocol can be used for mapping any IPv4 address to an 48 IPv6 address for a given lifetime. 50 TABLE OF CONTENTS 52 1. Introduction.......................................... 3 54 2. Terminology........................................... 4 56 2.1. Addresses..................................... 4 58 2.2. Requirements.................................. 4 60 3. Operation overview.................................... 5 62 3.1 Communication between AIIH and SIIT routers... 6 64 3.2. Support for Mobility.............��........... 7 66 3.2.1 Connection intiated by an IPv4 MN....... 7 68 3.2.2 Connection intiated by an IPv6 MN....... 8 70 3.2.3 SIIT extensions for mobility support.... 9 72 3.2.4 Considerations for MNs using MIPv6...... 9 74 4. Message formats for AIIH-SIIT router communication ... 9 76 4.1. Discovering an AIIH server ................... 9 78 4.2. Address-mapping cache entry .................. 10 80 4.3. Address-mapping cache Request................. 10 82 4.4. Address-mapping cache Reply................... 11 84 4.5. DELTA updates................................. 13 86 4.6. Address-mapping cache Acknowledgement......... 14 88 4.7. Keepalive message............................. 15 90 5. Acknowledgements...................................... 16 92 6. Authors addresses..................................... 16 94 7. References............................................ 16 96 1. Introduction 98 The expected increase in use of real time services like voice and 99 video over IPv6 places some requirements on packet processing delay 100 within routers. Furthermore, currently voice services have very 101 strong requirements on network reliability and the frequency of 102 network failures. These requirements are expected to maintain the 103 same standard in future or even higher. For the transition between 104 IPv4 and IPv6 to be successful, migration tools need to meet the 105 requirements of real time services for processing speed and 106 reliability. 108 The translation mechanism specified in [SIIT] provides a flexible and 109 decentralised function to allow a host running an IPv6 stack to 110 communicate with a host running an IPv4 stack. The ability to 111 decentralise this function can be very powerful from a reliability 112 point of view. Such distribution allows current connections to 113 survive despite the failure of one SIIT router. 115 However, due to the stateless nature of [SIIT], there is no mechanism 116 defined to allow a router implementing SIIT to route IPv4 packets to 117 IPv6 hosts configured with an IPv4-translated address in a fast 118 manner. 120 In this document an IPv6 host is assumed to acquire an IPv4 address 121 by using the DSTM technology specified in [DSTM]. This document 122 introduces a mechanism that allows an SIIT-enabled router to forward 123 the received IPv4 packets to their final destination (being the IPv6 124 host) with minimum delay. As mentioned earlier, this is an important 125 requirement to real time services. 127 Packets sent from IPv6 node to IPv4-mapped address can be routed to 128 an SIIT router by it injecting a route for ::ffff:0:0/96. If a site 129 has multiple SIIT routers they can all inject the above route into 130 the site's IPv6 routing. This will cause IPv6 nodes, through regular 131 IPv6 routing, to send packets to the closest SIIT router (Note that 132 if there are multiple SIIT routers they can also inject longer IPv4- 133 mapped address prefix routes into the site such as 134 ::ffff:0:0:129.146.0.0/112. The above /96 route is the equivalent of 135 an IPv4 default route). 137 Packets from the SIIT router to the IPv6 node need to be encapsulated 138 (as specified in RFC 2473 - IPv6 in IPv6) since their IPv4- 139 translatable IPv6 address does not contain enough toplogical 140 information to route the packets to the link/node. The goal of the 141 mechanisms in this document is for SIIT routers to be able to do this 142 encapsulation without any manual configuration and also without a 143 single SIIT router being a single point of failure. To accomplish 144 this the SIIT routers need to be able to dynamically determine, for 145 each IPv6-only node in the site, the mapping between the node's IPv4- 146 translatable address and the node's 'regular' (global or site-local) 147 IPv6 address. 149 Some extensions are proposed to an AIIH server and [SIIT] to allow an 150 SIIT router to request information regarding the mapping of 151 temporarily allocated IPv4 addresses and a host's IPv6 address. 152 It should be noted that although this draft focuses on the case where 153 SIIT is used, the protocol proposed between SIIT and an AIIH server 154 is independent of the transition mechanism and can be used between 155 AIIH servers and any other node in the network seeking such mapping 156 between a node�s IPv6 address and its IPv4 address allocated by a 157 DHCPv6 server. 159 2. Terminology 161 This documents uses the terminology defined in [IPv6], [TRANS- MECH] 162 and [SIIT] with this addition: 164 SIIT router: 166 A router implementing IPv4->IPv6 translation function 167 as outlined in [SIIT] 169 2.1. Addresses 171 In addition to the forms of addresses defined in [ADDR-ARCH] this 172 document uses the IPv4-translated addresses defined in [SIIT]. The 173 address forms are: 175 IPv4-mapped: 177 An address of the form 0::ffff:a.b.c.d which refer to a 178 node that is not IPv6-capable. In addition to its use in 179 the API this protocol uses IPv4-mapped addresses in IPv6 180 packets to refer to an IPv4 node. 182 IPv4-compatible: 184 An address of the form 0::0:a.b.c.d which refers to 185 an IPv6/IPv4 node that supports automatic tunneling. 186 Such addresses are not used in this protocol. 188 IPv4-translated: 190 An address of the form 0::ffff:0:a.b.c.d which 191 Refers to an IPv6-enabled node. Note that the 192 prefix 0::ffff:0:0:0/96 is chosen to checksum to 193 zero to avoid any changes to the transport protocol's 194 pseudo header checksum. 196 2.2. Requirements 198 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, 199 SHOULD,SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear 200 in this document, are to be interpreted as described in [KEYWORDS]. 202 3. Operational overview 204 3.1 Communication betweem AIIH servers and SIIT routers 206 The AIIH server described in [DSTM] allows an IPv6 host to acquire an 207 IPv4 address for the duration of its communication with an IPv4 host. 208 Outbound packets (originating from the V6 host) containing an IPv4- 209 translated source and an IPv4-mapped destination address can then be 210 translated by an SIIT router and forwarded according to the 211 translation rules in [SIIT]. 213 For inbound packets (addressed to a host's temporary IPv4 address) an 214 SIIT router needs to find out the final destination address (IPv6) 215 for the packets after the translation is performed. To have this 216 knowledge, an SIIT router requires a mapping between all the leased 217 IPv4 addresses and their corresponding hosts' IPv6 addresses. This is 218 achieved via communication with an AIIH server as illustrated below. 220 +--------+ 221 | AIIH | Client-Server communication 222 | Server | 223 +--------+----+------------+------------+-------------+ 224 | | | | | 225 | V V V V 226 | +--------+ +--------+ +--------+ +--------+ 227 | | SIIT | | SIIT | | SIIT | | SIIT | 228 | | router | | router | | router | | router | 229 | +--------+ +--------+ +--------+ +--------+ 230 | 231 | Client-server 232 +-------------------->+--------+ 233 | IPv6 | 234 | Node | 235 +--------+ 237 Fig.1 Communication between an SIIT router and AIIH 239 In this memo, the AIIH server acts as a central database containing 240 the mapping information between all pooled IPv4 addresses and their 241 corresponding IPv6 addresses. In addition, the server is expected to 242 update all registered SIIT routers whenever the information in the 243 address-mapping cache changes. 245 The communication between the SIIT routers and AIIH server is 246 established over TCP connections. The mechanism described below 247 details the information exchanged between the SIIT router and the 248 AIIH server. In addition, a Keepalive message is introduced on 249 application level to ensure the availability of the connection and 250 avoid confusion between the client and server during connection re- 251 establishment. 253 After starting up, an SIIT router should discover an AIIH server 254 within the same domain. This information can be manually configured 255 in the router or can be found through other mechanisms. An SIIT 256 router can then request the Address-mapping cache in an AIIH server. 257 The address-mapping cache consists of a number of entries, each 258 related to one of the pooled IPv4 addresses. Hence the number of 259 entries must be equal to the number of pooled IPv4 addresses in the 260 AIIH server. 262 The request for address-mapping cache also acts as a registration 263 mechanism to inform the AIIH server that an SIIT router exists and 264 should be informed about further updates to the address-mapping 265 cache. 267 The AIIH server MUST reply to the SIIT router's request by sending 268 a message containing all the pooled IPv4 addresses and their 269 corresponding IPv6 address. Each entry in the address-mapping cache 270 should contain the leased IPv4 address, the corresponding IPv6 271 address and the lifetime for which this information is valid. 273 The AIIH server SHOULD send the entire cache to the SIIT router. This 274 includes entries corresponding to unallocated IPv4 addresses. Entries 275 corresponding to unallocated IPv4 addresses MUST have the IPv6 276 address field set to the Unspecified address. 278 The AIIH server MUST record the IP address of the SIIT router 279 requesting the information. This will be needed for future updates of 280 the address-mapping cache. It may be more appropriate to use Site- 281 local addresses (if they are defined) for the communication between 282 the SIIT router and the AIIH server to avoid problems that could 283 arise due to renumbering. However, this is left to the network 284 administrator's discretion. 286 Before allocating an IPv4 address to an IPv6 node, the AIIH server 287 MUST inform all registered SIIT routers by sending an update message 288 containing the new entry. The AIIH server SHOULD wait for the 289 Acknowledgement message from all registered SIIT routers before 290 configuring the information in the IPv6 node. This is to make sure 291 that inbound packets will be forwarded with minimum delay. 293 To avoid long delays for Acknowledgements coming from SIIT routers a 294 timeout period needs to be used by AIIH servers. 296 When a packet having an IPv6-translated source address and an IPv6- 297 mapped destination address reaches an SIIT router, the packet will be 298 translated and forwarded as explained in [SIIT]. Upon reception of an 299 inbound IPv4 packet, the SIIT router MUST search for the destination 300 address in its address-mapping cache that was requested from the AIIH 301 server. If the address is found and it points to a valid IPv6 302 address, the packet should be translated as specified in [SIIT] and 303 tunnelled to that IPv6 address. 305 If a valid IPv6 address corresponding to the IPv6-translated address 306 was not found, an SIIT router SHOULD request that Address-mapping 307 cache entry from the AIIH server. An appropriate timeout period 308 should be applied after which an ICMP error (destination unreachable) 309 should be sent to the IPv4 sender. 311 When tunnelling inbound packets, the outer header MUST contain the 312 SIIT router's address as a source and the IPv6 node's address as a 313 destination. The inner header should contain the IPv6-mapped address 314 as a source address (formed from the source address in the original 315 v4 packet) and the IPv6-translated address in the destination field. 316 The encapsulation should follow the rules mentioned in RFC 2473. 318 3.2 Support for mobility 320 This chapter aims to explain how an IPv4 MN would interact with an 321 IPv6 MN using an IPv4-translated address. Two different scenarios are 322 considered: 324 a) An IPv4-only node intiating the connection and 326 b) An IPv6-only node intiating the connection 328 It should be noted that no impact on the MIPv6 or MIPv4 protocols is 329 introduced due to the extensions proposed in this memo. 331 3.2.1 Connection initiated by an IPv4-only MN 333 An IPv4-only node stack may start communication with an IPv6-only 334 node by performing a DNS request on the IPv6 node. A DNS request is 335 sent to the IPv6 domain. According to [DSTM], the local V6 domain can 336 assign a V4 address to the IPv6 host and forward the DNS reply to the 337 V4 node. The local AIIH server MUST also update all SIIT routers 338 within the domain. This is done by sending an update message 339 containing the IPv6 node's home address, the assigned IPv4 address 340 and the entry's lifetime in the address-mapping cache. All packets 341 destined to the IPv6 node will be translated by the receiving SIIT 342 router and encapsulated to the node's home address. 344 If the IPv6 MN is located in a foreign network, the packets should be 345 tunnelled by the HA to its COA according to [MIPv6]. Since the MN 346 will have the SIIT router's address received in the encapsulated 347 packet, this should result in the sending of a BU from the MN to the 348 SIIT router according to [MIPv6]. 350 In this manner, route optimisation can be achieved within the IPv6 351 network, i.e. between the MN and the SIIT router. On the other hand, 352 route optimisation can not be achieved within the MIPv4 domain. Since 353 MIPv4 messages are sent over UDP, an SIIT router will not be able to 354 understand any BU messages sent from the IPv4 node's HA. Hence all BU 355 messages will be silently discarded by the final destination (IPv6 356 node). This should not cause any problems for the MIPv4 357 implementation as route optimisation is not mandatory in MIPv4. 358 Furthermore, since MIPv4 messages are not piggybacked on data 359 packets, no service interruption is expected due to discarding the 360 MIPv4 BUs. 362 It should be noted that the Address-mapping cache need not be tightly 363 coupled to the Binding Cache implementation. Hence an SIIT router may 364 contain the IPv6 MN's home address in its Address-mapping cache and 365 its COA in the Binding cache. In the case of an SIIT router's 366 failure, packets may be routed to another SIIT router that is not 367 updated with the MN's current location. This will result in 368 triangular routing within the IPv6 domain until the MN updates the 369 new SIIT router with its current location. This may result in some 370 delays that might be encountered due to the number of extra hops 371 introduced by triangular routing. 373 3.2.2 Connection initiated by an IPv6-only MN 375 In this memo the actions required by an IPv6-only MN to communicate 376 with an IPv4 MN depends on its location at the time the communication 377 is initiated and whether its current domain supports an AIIH server. 378 In the following sections, two scenarios are considered depending on 379 whether the MN is located at a home or foreign domain when 380 communication is initiated. 382 3.2.2.1 An IPv6-only MN initiating connection from its Home domain 384 A MN�s home domain is the administrative domain containing its home 385 network. The MN�s ability to distinguish between a home and a foreign 386 domain is outside the scope of the document. 388 If the MN is located in its home domain, which supports AIIH, the MN 389 can request an IPv4 address as outlined in [DSTM]. The AIIH server 390 should allocate an IPv4 address to the MN and update all known SIIT 391 routers. 393 Upon successful allocation of the IPv4 address, the MN can start 394 communicating with the IPv4-only node in the normal manner. 396 3.2.2.1 An IPv6-only MN initiating connection from a foreign domain 398 If the MN is located in a foreign domain, it may choose to request an 399 IPv4 address from the local AIIH server, provided one exists within 400 the domain and no local policy stops such request. Upon successful 401 allocation of the address, the AIIH server should update all 402 registered SIIT routers. The MN MAY then update its home DNS by 403 sending a DNS update message. This would require a pre-existing 404 security association with the Home DNS. 406 Alternatively, the MN may choose to tunnel a request for an IPv4 407 address to the Home AIIH server. The Home AIIH server would then 408 allocate an address and update all the SIIT routers within the Home 409 domain. All IPv4 packets from this point onward will be received 410 within the home network and forwarded to the MN's COA via the HA. 411 In this scenario, The MN SHOULD reverse tunnel its packets through 412 its HA in the Home domain. This may be needed in cases where the 413 visited domain applies some ingress filtering policies that would 414 stop the MN from sending its traffic using its Home domain�s IPv4- 415 translated IPv6 address as a source address. 417 It should be noted that by requesting an address from the local AIIH 418 server less delays would be encountered for inbound packets, i.e. 419 triangular routing will be achieved (compared to rectangular routing 420 when requesting an address from the Home AIIH server). On the other 421 hand, an IPv4 address from the Home domain would last even when the 422 MN moves to a new domain (another foreign domain) which may not be 423 possible when getting an address from the current domain. 424 For example, some domains with a limited IPv4 address pool may wish 425 to restrict the use of such addresses to nodes that are physically 426 located within their domain. The method of policing the use of IPv4 427 addresses is outside the scope of this memo. 429 Hence the decision as to which method should be used to get an IPv4 430 address (Home vs visited domain) is left to the MN and the local 431 policies within each domain. 433 3.2.3 SIIT extensions for mobility support 435 According to [MIPv6] a MN MUST include a Home Address option in all 436 outbound packets when located in a foreign network. Furthermore, 437 every CN MUST be able to process the Home Address option. When the 438 ESP or the AH headers are used for outbound packets, the Home Address 439 option is added before the IPsec header to enable the CN to process 440 the IPsec header. Hence the Home Address option will always be 441 visible to intermediate nodes. 443 For an IPv6 MN to successfully communicate with an IPv4 node via 444 SIIT, the Home Address option MUST not be forwarded in the translated 445 IPv4 packets. Hence an SIIT router has to remove the Home option from 446 all outbound packets during the translation. This is achieved by 447 replacing the source address with the Home address before 448 translating the header. When an inbound packet is received the packet 449 will be encapsulated to the Home address of the MN. If the SIIT 450 router includes a Binding to the MN's COA, the COA will be used as 451 the destination address as per [MIPv6]. 453 To avoid triangular routing in the IPv6 domain, SIIT routers SHOULD 454 process BUs and maintain a Binding Cache. 456 3.2.4 Considerations for Mobile Nodes using MIPv6 458 For communication between an IPv6 MN and an IPv4 MN to succeed, an 459 IPv6 MN MUST not place any destination options after the ESP header 460 for all CNs that have an IPv4-mapped address. 461 This should be done to make sure that packets do not get discarded by 462 the IPv4 host due to the inclusion of an unknown (to an IPv4 node) 463 Destination option. 465 4. Message formats for communication between AIIH and SIIT routers 467 4.1. Discovering an AIIH Server 469 Ultimately it is advantageous that an SIIT router discovers an AIIH 470 server without the need for manual configuration. Although manual 471 configuration can also be allowed, the aim of this section is to 472 recommend other dynamic mechanisms. 474 Since AIIH servers are essentially combined DHCP and DNS servers, 475 DHCP server mechanisms can be used to discover the DHCP server's IP 476 address. The next step is to check whether the DHCP server located 477 implements the mechanism proposed in this memo. This can be achieved 478 by sending the address-mapping cache request message shown below. A 479 reception of the address-mapping cache will indicate the support for 480 this mechanism. 482 4.2 Address-mapping cache entry 484 Figure 2 below shows the structure of a single entry in the address- 485 mapping cache. Each address-mapping cache reply message may include a 486 large number of entries. Each entry contains: an IPv6 address, an 487 IPv4 address and the corresponding lifetime. Entries received by SIIT 488 routers are stored in the address-mapping cache. 490 0 1 2 3 491 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 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | IPv4 address | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | | 497 | IPv6 address | 498 | | 499 | | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | Lifetime | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 Fig. 2. Address-mapping cache entry 506 IPv4 address IPv4 address in an AIIH server's address pool 508 IPv6 address IPv6 node's address. If the IPv4 address is 509 Not allocated to any IPv6 nodes, this field 510 MUST be set to the Unspecified address. 512 Lifetime A 32-bit unsigned number indicating the 513 expiry time of this entry in seconds. 514 The expiry time for this entry MUST be equal to 515 or less than the lifetime of the IPv4 address. 517 4.3. Address-mapping cache Request 519 The Address-mapping cache request message format is shown below. This 520 message is sent by SIIT routers to request the mapping between IPv4 521 and IPv6 addresses. The details of the message are explained below. 523 0 1 2 524 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 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 |Msg-typ| Length |E| Reserved | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | IPv4 address | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 . 533 . 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | IPv4 address | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 Fig. 3. Address-mapping cache request 539 Msg-type = 1 Indicates address-mapping cache request 540 message. 542 Length The number of 32-bit words after the Reserved 543 field. Ie. the number of IPv4 addresses 544 included. MUST be Set to zero if the E flag is 545 set. 547 E If set, indicates a request for the entire 548 cache. If not set the message MUST include one 549 or more IPv4 addresses. 551 Reserved An 11-bit reserved field. MUST be set to zero. 553 The message can be sent to request mappings for certain IPv4 554 addresses or, alternatively, a client may request the mappings for 555 the entire cache. 556 If the E flag is set, it shows that the client requests a mapping for 557 the entire cache and the length field MUST be set to zero. Otherwise, 558 the client's request is only for certain IPv4 addresses and the 559 length field should be set to the number of IPv4 addresses included 560 in the message. 562 4.4 Address-mapping Cache reply 564 The address-mapping cache reply is sent by the AIIH server and 565 contains the mapping information requested by the client. If the 566 entire cache was requested, the AIIH server MUST return all mappings 567 in the cache. 569 0 1 2 3 570 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 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 |Msg-typ| Length | Code |M| Reserved | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | Transaction ID | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | IPv4 address | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | | 579 | IPv6 address | 580 | | 581 | | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 | Lifetime | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 . 587 . 589 . 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | IPv4 address | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | | 594 | IPv6 address | 595 | | 596 | | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | Lifetime | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 Fig. 4. Address-mapping cache reply 603 Msg-type = 2 Indicates a message reply type. 605 Length The number of 32-bit words following the 606 Packet ID field. 608 M If set indicates more messages will be 609 received. This indicates that the reply 610 couldn't be placed in one message. 612 Reserved 7-bit reserved field. MUST be set to zero. 614 Transaction ID A 32-bit unsigned number identifying each 615 transaction (ie. client request). 617 Code Shows the status of the operation. Values of 5 618 and above provide reasons for operation 619 failure. 621 Reserved values : 622 0 Operation successful. 623 5 Operation failed. Reason unspecified. 624 6 Poorly formed message. 625 7 Requested addresses unknown. 627 In the case where the client has requested the entire cache and the 628 length of the cache is larger than the maximum possible length 629 allowed in the packet, the AIIH server should send multiple reply 630 messages. Only the last message should have the M flag set to zero to 631 indicate that the entire cache was sent to the client. 633 The code field shows the result of the processing of the client's 634 request message. If the field includes a value corresponding to any 635 of the error values mentioned above, no more entries should exist in 636 the message. Hence the length field MUST be set to zero. 638 A transaction id field is used to uniquely identify each request. 639 This is needed for the client to be able to inform the server of 640 erroneous packets transferred in a transaction which may result in 641 the server restarting the transaction. 643 If the reply was sent based on a request for some entries in the 644 address-mapping cache (not the entire cache), and these addresses 645 were not found, the reply MUST include the requested entries 646 containing the unspecified IPv6 address and a lifetime field of Zero. 647 The Code field MUSt be set to 7. 649 4.5 DELTA update messages 651 DELTA update messages are used to send unsolicited address-mapping 652 cache updates due to changes in one or more entries. For example, if 653 a an IPv4 address was allocated to a different IPv6 node, or for 654 invalidation of certain entries. An SIIT router SHOULD acknowledge 655 DELTA update messages. 657 0 1 2 3 658 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 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 |Msg-typ| Length |M| Reserved | 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 | Transaction ID | 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 | IPv4 address | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 | | 667 | IPv6 address | 668 | | 669 | | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | Lifetime | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 Msg-type = 3 Indicates a message reply type. 676 Length The number of 32-bit words following the 677 Packet ID field. 679 M If set indicates more messages will be 680 received. This indicates that the reply 681 couldn't be placed in one message. 683 Transaction ID A 32-bit unsigned number identifying each 684 transaction (ie. client request). 686 Reserved 11-bit reserved field. MUST be set to zero. 688 4.6 Address-mapping cache Acknowledgement 690 Acknowldgement messages should be sent by the clients upon reception 691 of an Address-mapping cache reply message from an AIIH server. An 692 Acknowledgement message contains a code field that shows the result 693 of processing the server's last message. Clients may choose not to 694 send an acknowledgement for each received packet. However, an SIIT 695 router MUST send an acknowledgement with the appropriate code value 696 whenever it receives an erroneous message from an AIIH server. 698 0 1 2 3 699 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 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 |Msg-typ| Code | Reserved | 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | Transaction ID | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 Msg-type = 4 Indicates acknowledgement type. 708 Reserved 24-bit reserved field. MUST be set to zero. 710 Transaction ID A 32-bit unsigned number identifying each 711 transaction (ie. client request). 713 Code Indicates the status of the operation, whether 714 it succeeded or not. 716 Reserved values : 717 0 Operation successful 718 5 Operation failed. Error unspecified 719 6 Poorly formed message. 721 The transaction id field identifies the transaction for which an 722 acknowledgement is being sent. 724 4.7 Keepalive message 726 Keepalive messages are introduced to ensure the availability of the 727 connection between the SIIT routers and AIIH servers. The messages 728 can be sent by either the clients or the server. 730 It is recommended that the message is sent once per minute by each 731 application. Each application should wait for a random length of time 732 after starting up before sending the first message. 734 0 1 2 3 735 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 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | Msg-type| Sequence no |R| Rsvd | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 Msg-type = 5 Indicates a keepalive message type. 742 Sequence number A 16-bit unsigned word that is used to 743 identify the message. 745 R If the R flag is set it indicates that this 746 is a reply message. 748 Rsvd A 12-bit reserved field. MUST be set to zero. 750 The sender of a Keepalive message should generate the sequence number 751 field by using a 16-bit rolling counter. 752 The receiver of a Keepalive message MUST echo that message with the 753 same sequence number and set the R flag in the reply. 755 5. Security considerations 757 The reachability of an IPv6 node from an IPv4 requires that a unique 758 IPv4 address is assigned to the IPv6 node. Since one of the main 759 reasons for migrating to IPv6 is the scarcity of IPv4 addresses, such 760 addresses need to be assigned to hosts in an optimal manner and only 761 when needed (i.e. on demand). The assignment of IPv4 addresses to 762 IPv6 nodes based on DNS queries by the IPv4 host raises some security 763 concerns and may be subject to DoS attacks. A malicious IPv4 node can 764 send frequent DNS requests for some IPv6 to cause the AIIH server to 765 run out of IPv4 addresses and allocating all the pooled addresses to 766 IPv6 nodes that do not need them. 768 6. Acknowledgements 770 The authors would like to thank Mattias Pettersson and Conny Larsson 771 for their careful reviews of this draft. 773 7. Author's Addresses 775 Hesham Soliman 776 Ericsson Radio Systems, AB. 777 Torshamnsgatan 23, 778 Kista, Stockholm, 779 SWEDEN 781 Phone: +46 8 4046619 782 Fax: +46 8 4047020 783 E-mail: Hesham.Soliman@era.ericsson.se 785 Erik Nordmark 786 Sun Microsystems Laboratories 787 29, Chemin du Vieux Chene 788 38240 Meylan, 789 France 791 phone: +33 (0)4 76 18 88 03 792 fax: +33 (0)4 76 18 88 88 793 email: nordmark@sun.com 795 7. References 797 [ADDR-ARCH] Deering, S. and R. Hinden, Editors, "IP Version 6 798 Addressing Architecture", RFC 2373, July 1998. 800 [IPv6] Deering, S. and R. Hinden, Editors, "Internet Protocol, 801 Version 6 (IPv6) Specification", RFC 2460, December 802 1998. 804 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 805 Requirement Levels", BCP 14, RFC 2119, March 1997. 807 [MIPV6] D. Johnson and C. Perkins, "Mobility Support in IPv6", 808 draft-ietf-mobileip-ipv6-13.txt. Work in progress. 810 [SIIT] E. Nordmark, "Stateless IP/ICMP Translation Algorithm", 811 RFC 2765, February 2000. 813 [DSTM] J. Bound et al, �Dual Stack Transition Mechanism�, 814 draft-ietf-ngtrans-dstm-04.txt (work in progress). 816 This Internet-Draft expires in MAY 2002.