IETF - NGTRANS Working Group Hesham Soliman, INTERNET Draft Ericsson Expires: August 2001 Erik Nordmark Sun Microsystems February 2001 Extensions to SIIT and DSTM for enhanced routing of inbound packets Status of this memo This document is a submission by the NGTRANS Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ngtrans@sunroof.eng.sun.com mailing list. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This document specifies a transition mechanism that combines both [SIIT] and [DSTM] mechanisms by adding some extensions to allow fast routing of inbound packets. This will result in a more decentralised and flexible tool to allow IPv6-only nodes to communicate with IPv4- only nodes. The proposed extensions will provide a way that allows SIIT routers to route packets addressed to a host running a single IPv6 stack with minimum delay which is suited to real time services. It should be noted that the proposed protocol between SIIT routers and AIIH servers is generic and is not limited to its use between these two nodes. This protocol can be used for mapping any IPv4 address to an IPv6 address for a given lifetime. H. Soliman and Erik Nordmark SIIT-DSTM extensions [Page 1] INTERNET-DRAFT February 2001 TABLE OF CONTENTS 1. Introduction.......................................... 3 2. Terminology........................................... 4 2.1. Addresses..................................... 4 2.2. Requirements.................................. 4 3. Operation overview.................................... 5 3.1 Communication between AIIH and SIIT routers... 6 3.2. Support for Mobility.............__........... 7 3.2.1 Connection intiated by an IPv4 MN....... 7 3.2.2 Connection intiated by an IPv6 MN....... 8 3.2.3 SIIT extensions for mobility support.... 9 3.2.4 Considerations for MNs using MIPv6...... 9 4. Message formats for AIIH-SIIT router communication ... 9 4.1. Discovering an AIIH server ................... 9 4.2. Address-mapping cache entry .................. 10 4.3. Address-mapping cache Request................. 10 4.4. Address-mapping cache Reply................... 11 4.5. DELTA updates................................. 13 4.6. Address-mapping cache Acknowledgement......... 14 4.7. Keepalive message............................. 15 5. Acknowledgements...................................... 16 6. Authors addresses..................................... 16 7. References............................................ 16 H. Soliman and Erik Nordmark SIIT-DSTM extensions [Page 2] INTERNET-DRAFT February 2001 1. Introduction The expected increase in use of real time services like voice and video over IPv6 places some requirements on packet processing delay within routers. Furthermore, currently voice services have very strong requirements on network reliability and the frequency of network failures. These requirements are expected to maintain the same standard in future or even higher. For the transition between IPv4 and IPv6 to be successful, migration tools need to meet the requirements of real time services for processing speed and reliability. The translation mechanism specified in [SIIT] provides a flexible and decentralised function to allow a host running an IPv6 stack to communicate with a host running an IPv4 stack. The ability to decentralise this function can be very powerful from a reliability point of view. Such distribution allows current connections to survive despite the failure of one SIIT router. However, due to the stateless nature of [SIIT], there is no mechanism defined to allow a router implementing SIIT to route IPv4 packets to IPv6 hosts configured with an IPv4-translated address in a fast manner. In this document an IPv6 host is assumed to acquire an IPv4 address by using the DSTM technology specified in [DSTM]. This document introduces a mechanism that allows an SIIT-enabled router to forward the received IPv4 packets to their final destination (being the IPv6 host) with minimum delay. As mentioned earlier, this is an important requirement to real time services. Packets sent from IPv6 node to IPv4-mapped address can be routed to an SIIT router by it injecting a route for ::ffff:0:0/96. If a site has multiple SIIT routers they can all inject the above route into the site's IPv6 routing. This will cause IPv6 nodes, through regular IPv6 routing, to send packets to the closest SIIT router (Note that if there are multiple SIIT routers they can also inject longer IPv4- mapped address prefix routes into the site such as ::ffff:0:0:129.146.0.0/112. The above /96 route is the equivalent of an IPv4 default route). Packets from the SIIT router to the IPv6 node need to be encapsulated (as specified in RFC 2473 - IPv6 in IPv6) since their IPv4- translatable IPv6 address does not contain enough toplogical information to route the packets to the link/node. The goal of the mechanisms in this document is for SIIT routers to be able to do this encapsulation without any manual configuration but also without a single SIIT router being a single point of failure. To accomplish this the SIIT routers need to be able to dynamically determine, for each IPv6-only node in the site, the mapping between the node's IPv4- H. Soliman and Erik Nordmark SIIT-DSTM extensions [Page 3] INTERNET-DRAFT February 2001 translatable address and the node's 'regular' (global or site-local) IPv6 address. Some extensions are proposed to an AIIH server and [SIIT] to allow an SIIT router to request information regarding the mapping of temporarily allocated IPv4 addresses and a host's IPv6 address. It should be noted that although this draft focuses on the case where SIIT is used, the protocol proposed between SIIT and an AIIH server is independent of the transition mechanism and can be used between AIIH servers and any other node in the network seeking such mapping between a node's IPv6 address and its IPv4 address allocated by a DHCPv6 server. 2. Terminology This documents uses the terminology defined in [IPv6], [TRANS- MECH] and [SIIT] with this addition: SIIT router: A router implementing IPv4->IPv6 translation function as outlined in [SIIT] 2.1. Addresses In addition to the forms of addresses defined in [ADDR-ARCH] this document uses the IPv4-translated addresses defined in [SIIT]. The address forms are: IPv4-mapped: An address of the form 0::ffff:a.b.c.d which refer to a node that is not IPv6-capable. In addition to its use in the API this protocol uses IPv4-mapped addresses in IPv6 packets to refer to an IPv4 node. IPv4-compatible: An address of the form 0::0:a.b.c.d which refers to an IPv6/IPv4 node that supports automatic tunneling. Such addresses are not used in this protocol. IPv4-translated: An address of the form 0::ffff:0:a.b.c.d which Refers to an IPv6-enabled node. Note that the prefix 0::ffff:0:0:0/96 is chosen to checksum to zero to avoid any changes to the transport protocol's pseudo header checksum. H. Soliman and Erik Nordmark SIIT-DSTM extensions [Page 4] INTERNET-DRAFT February 2001 2.2. Requirements The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [KEYWORDS]. 3. Operational overview 3.1 Communication betweem AIIH servers and SIIT routers The AIIH server described in [DSTM] allows an IPv6 host to acquire an IPv4 address for the duration of its communication with an IPv4 host. Outbound packets (originating from the V6 host) containing an IPv4- translated source and an IPv4-mapped destination address can then be translated by an SIIT router and forwarded according to the translation rules in [SIIT]. For inbound packets (addressed to a host's temporary IPv4 address) an SIIT router needs to find out the final destination address (IPv6) for the packets after the translation is performed. To have this knowledge, an SIIT router requires a mapping between all the leased IPv4 addresses and their corresponding hosts' IPv6 addresses. This is achieved via communication with an AIIH server as illustrated below. +--------+ | AIIH | Client-Server communication | Server | +--------+----+------------+------------+-------------+ | | | | | | | | | | | +--------+ +--------+ +--------+ +--------+ | | SIIT | | SIIT | | SIIT | | SIIT | | | router | | router | | router | | router | | +--------+ +--------+ +--------+ +--------+ | | Client-server +---------------------+--------+ | IPv6 | | Node | +--------+ Fig.1 Communication between an SIIT router and AIIH In this memo, the AIIH server acts as a central database containing the mapping information between all pooled IPv4 addresses and their corresponding IPv6 addresses. In addition, the server is expected to update all registered SIIT routers whenever the information in the address-mapping cache changes. H. Soliman and Erik Nordmark SIIT-DSTM extensions [Page 5] INTERNET-DRAFT February 2001 The communication between the SIIT routers and AIIH server is established over TCP connections. The mechanism described below details the information exchanged between the SIIT router and the AIIH server. In addition, a Keepalive message is introduced on application level to ensure the availability of the connection and avoid confusion between the client and server during connection re- establishment. After starting up, an SIIT router should discover an AIIH server within the same domain. This information can be manually configured in the router or can be found through other mechanisms. An SIIT router can then request the Address-mapping cache in an AIIH server. The address-mapping cache consists of a number of entries, each related to one of the pooled IPv4 addresses. Hence the number of entries must be equal to the number of pooled IPv4 addresses in the AIIH server. The request for address-mapping cache also acts as a registration mechanism to inform the AIIH server that an SIIT router exists and should be informed about further updates to the address-mapping cache. The AIIH server SHOULD reply to the SIIT router's request by sending a message containing all the pooled IPv4 addresses and their corresponding IPv6 address. Each entry in the address-mapping cache should contain the leased IPv4 address, the corresponding IPv6 address and the lifetime for which this information is valid. The AIIH server SHOULD send the entire cache to the SIIT router. This includes entries corresponding to unallocated IPv4 addresses. Entries corresponding to unallocated IPv4 addresses MUST have the IPv6 address field set to the Unspecified address. The AIIH server MUST record the IP address of the SIIT router requesting the information. This will be needed for future updates of the address-mapping cache. It may be more appropriate to use Site- local addresses (if they are defined) for the communication between the SIIT router and the AIIH server to avoid problems that could arise due to renumbering. However, this is left to the network administrator's discretion. Before allocating an IPv4 address to an IPv6 node, the AIIH server MUST inform all registered SIIT routers by sending an update message containing the new entry. The AIIH server SHOULD wait for the Acknowledgement message from all registered SIIT routers before configuring the information in the IPv6 node. This is to make sure that inbound packets will be forwarded with minimum delay. To avoid long delays for Acknowledgements coming from SIIT routers a timeout period needs to be used by AIIH servers. H. Soliman and Erik Nordmark SIIT-DSTM extensions [Page 6] INTERNET-DRAFT February 2001 When a packet having an IPv6-translated source address and an IPv6- mapped destination address reaches an SIIT router, the packet will be translated and forwarded as explained in [SIIT]. Upon reception of an inbound IPv4 packet, the SIIT router MUST search for the destination address in its address-mapping cache that was requested from the AIIH server. If the address is found and it points to a valid IPv6 address, the packet should be translated as specified in [SIIT] and tunnelled to that IPv6 address. If a valid IPv6 address corresponding to the IPv6-translated address was not found, an SIIT router SHOULD request that Address-mapping cache entry from the AIIH server. An appropriate timeout period should be applied after which an ICMP error (destination unreachable) should be sent to the IPv4 sender. When tunnelling inbound packets, the outer header MUST contain the SIIT router's address as a source and the IPv6 node's address as a destination. The inner header should contain the IPv6-mapped address as a source address (formed from the source address in the original v4 packet) and the IPv6-translated address in the destination field. The encapsulation should follow the rules mentioned in RFC 2473. 3.2 Support for mobility This chapter aims to explain how an IPv4 MN would interact with an IPv6 MN using an IPv4-translated address. Two different scenarios are considered: a) An IPv4-only node intiating the connection and b) An IPv6-only node intiating the connection It should be noted that no impact on the MIPv6 or MIPv4 protocols is introduced due to the extensions proposed in this memo. 3.2.1 Connection initiated by an IPv4-only MN An IPv4-only node stack may start communication with an IPv6-only node by performing a DNS request on the IPv6 node. A DNS request is sent to the IPv6 domain. According to [DSTM], the local V6 domain can assign a V4 address to the IPv6 host and forward the DNS reply to the V4 node. The local AIIH server MUST also update all SIIT routers within the domain. This is done by sending an update message containing the IPv6 node's home address, the assigned IPv4 address and the entry's lifetime in the address-mapping cache. All packets destined to the IPv6 node will be translated by the receiving SIIT router and encapsulated to the node's home address. If the IPv6 MN is located in a foreign network, the packets should be H. Soliman and Erik Nordmark SIIT-DSTM extensions [Page 7] INTERNET-DRAFT February 2001 tunnelled by the HA to its COA according to [MIPv6]. Since the MN will have the SIIT router's address received in the encapsulated packet, this should result in the sending of a BU from the MN to the SIIT router according to [MIPv6]. In this manner, route optimisation can be achieved within the IPv6 network, ie. between the MN and the SIIT router. On the other hand, route optimisation can not be achieved within the MIPv4 domian. Since MIPv4 messages are sent over UDP, an SIIT router will not be able to understand any BU messages sent from the IPv4 node's HA. Hence all BU messages will be silently discarded by the final destination (IPv6 node). This should not cause any problems for the MIPv4 implementation as route optimisation is not mandatory in MIPv4. Furthermore, since MIPv4 messages are not piggybacked on data packets, no service interruption is expected due to discarding the MIPv4 BUs. It should be noted that the Address-mapping cache need not be tightly coupled to the Binding Cache implementation. Hence an SIIT router may contain the IPv6 MN's home address in its Address-mapping cache and its COA in the Binding cache. In the case of an SIIT router's failure, packets may be routed to another SIIT router that is not updated with the MN's current location. This will result in triangular routing within the IPv6 domain until the MN updates the new SIIT router with its current location. This may result in some delays that might be encountered due to the number of extra hops introduced by triangular routing. 3.2.2 Connection intiated by an IPv6-only MN In this memo the actions required by an IPv6-only MN to communicate with an IPv4 MN depends on its location at the time the communication is initiated and whether its current domain supports an AIIH server. In the following sections, two scenarios are considered depending on whether the MN is located at a home or foreign domain when communication is initiated. 3.2.2.1 An IPv6-only MN initiating connection from its Home domain A MN's home domain is the administrative domain containing its home network. The MN's ability to distinguish between a home and a foreign domain is outside the scope of the document. If the MN is located in its home domain, which supports AIIH, the MN can request an IPv4 address as outlined in [DSTM]. The AIIH server should allocate an IPv4 address to the MN and update all known SIIT routers. Upon successful allocation of the IPv4 address, the MN can start communicating with the IPv4-only node in the normal manner. H. Soliman and Erik Nordmark SIIT-DSTM extensions [Page 8] INTERNET-DRAFT February 2001 3.2.2.1 An IPv6-only MN initiating connection from a foreign domain If the MN is located in a foreign domain, it may choose to request an IPv4 address from the local AIIH server, provided one exists within the domain and no local policy stops such request. Upon successful allocation of the address, the AIIH server should update all registered SIIT routers. The MN MAY then update its home DNS by sending a DNS update message. This would require a pre-existing security association with the Home DNS. Alternatively, the MN may choose to tunnel a request for an IPv4 address to the Home AIIH server. The Home AIIH server would then allocate an address and update all the SIIT routers within the Home domain. All IPv4 packets from this point onward will be received within the home network and forwarded to the MN's COA via the HA. In this scenario, The MN SHOULD reverse tunnel its packets through its HA ithe Home domain. This may be needed in cases where the visited domain applies some ingress filtering policies that would stop the MN from sending its traffic using its Home domain's IPv4- translated IPv6 address as a source address. It should be noted that by requesting an address from the local AIIH server less delays would be encountered for inbound packets, ie. triangular routing will be achieved (compared to rectangular routing when requesting an address from the Home AIIH server). On the other hand, an IPv4 address from the Home domain would last even when the MN moves to a new domain (another foreign domain) which may not be possible when getting an address from the current domain. For example, some domains with a limited IPv4 address pool may wish to restrict the use of such addresses to nodes that are physically located within their domain. The method of policing the use of IPv4 addresses is outside the scope of this memo. Hence the decision as to which method should be used to get an IPv4 address (Home vs visited domain) is left to the MN and the local policies within each domain. 3.2.3 SIIT extensions for mobility support According to [MIPv6] a MN MUST include a Home Address option in all outbound packets when located in a foreign network. Furthermore, every CN MUST be able to process the Home Address option. When the ESP or the AH headers are used for outbound packets, the Home Address option is added before the IPsec header to enable the CN to process the IPsec header. Hence the Home Address option will always be visible to intermediate nodes. For an IPv6 MN to successfully communicate with an IPv4 node via SIIT, the Home Address option MUST not be forwarded in the translated H. Soliman and Erik Nordmark SIIT-DSTM extensions [Page 9] INTERNET-DRAFT February 2001 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]. To avoid triangular routing in the IPv6 domain, it is recommended that SIIT routers process BU's and maintain a Binding Cache. 3.2.4 Considerations for Mobile Nodes using MIPv6 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. 4. Message formats for communication between AIIH and SIIT routers 4.1. Discovering an AIIH Server Ultimately it is advantageous that an SIIT router discovers an AIIH server without the need for manual configuration. Although manual configuration can also be allowed, the aim of this section is to recommend other dynamic mechanisms. Since AIIH servers are essentially combined DHCP and DNS servers, DHCP server mechanisms can be used to discover the DHCP server's IP address. The next step is to check whether the DHCP server located implements the mechanism proposed in this memo. This can be achieved by sending the address-mapping cache request message shown below. A reception of the address-mapping cache will indicate the support for this mechanism. 4.2 Address-mapping cache entry Figure 2 below shows the structure of a single entry in the address- mapping cache. Each address-mapping cache reply message may include a large number of entries. Each entry contains: an IPv6 address, an IPv4 address and the corresponding lifetime. Entries received by SIIT routers are stored in the address-mapping cache. 0 1 2 3 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 H. Soliman and Erik Nordmark SIIT-DSTM extensions [Page 10] INTERNET-DRAFT February 2001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IPv6 address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fig. 2. Address-mapping cache entry IPv4 address IPv4 address in an AIIH server's address pool IPv6 address IPv6 node's address. If the IPv4 address is Not allocated to any IPv6 nodes, this field MUST be set to the Unspecified address. Lifetime A 32-bit unsigned number indicating the expiry time of this entry in seconds. The expiry time for this entry MUST be equal to or less than the lifetime of the IPv4 address. 4.3. Address-mapping cache Request The Address-mapping cache request message format is shown below. This message is sent by SIIT routers to request the mapping between IPv4 and IPv6 addresses. The details of the message are explained below. 0 1 2 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Msg-typ| Length |E| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fig. 3. Address-mapping cache request H. Soliman and Erik Nordmark SIIT-DSTM extensions [Page 11] INTERNET-DRAFT February 2001 Msg-type = 1 Indicates address-mapping cache request message. Length The number of 32-bit words after the Reserved field. Ie. the number of IPv4 addresses included. MUST be Set to zero if the E flag is set. E If set, indicates a request for the entire cache. If not set the message MUST include one or more IPv4 addresses. Reserved An 11-bit reserved field. MUST be set to zero. The message can be sent to request mappings for certain IPv4 addresses or, alterntively, a client may request the mappings for the entire cache. If the E flag is set, it shows that the client requests a mapping for the entire cache and the length field MUST be set to zero. Otherwise, the client's request is only for certain IPv4 addresses and the length field should be set to the number of IPv4 addresses included in the message. 4.4 Address-mapping Cache reply The address-mapping cache reply is sent by the AIIH server and contains the mapping information requested by the client. If the entire cache was requested, the AIIH server MUST return all mappings in the cache. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Msg-typ| Length | Code |M| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transaction ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IPv6 address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . H. Soliman and Erik Nordmark SIIT-DSTM extensions [Page 12] INTERNET-DRAFT February 2001 . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IPv6 address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fig. 4. Address-mapping cache reply Msg-type = 2 Indicates a message reply type. Length The number of 32-bit words following the Packet ID field. M If set indicates more messages will be received. This indicates that the reply couldn't be placed in one message. Reserved 7-bit reserved field. MUST be set to zero. Transaction ID A 32-bit unsigned number identifying each transaction (ie. client request). Code Shows the status of the operation. Values of 5 and above provide reasons for operation failure. Reserved values : 0 Operation successful. 5 Operation failed. Reason unspecified. 6 Poorly formed message. In the case where the client has requested the entire cache and the length of the cache is larger than the maximum possible length allowed in the packet, the AIIH server should send multiple reply messages. Only the last message should have the M flag set to zero to indicate that the entire cache was sent to the client. The code field shows the result of the processing of the client's request message. If the field includes a value corresponding to any H. Soliman and Erik Nordmark SIIT-DSTM extensions [Page 13] INTERNET-DRAFT February 2001 of the error values mentioned above, no more entries should exist in the message. Hence the length field MUST be set to zero. A transaction id field is used to uniquely identify each request. This is needed for the client to be able to inform the server of erroneous packets transferred in a transaction which may result in the server restarting the transaction. 4.5 DELTA update messages DELTA update messages are used to send unsolicited address-mapping cache updates due to changes in one or more entries. For example, if a an IPv4 address was allocated to a different IPv6 node, or for invalidation of certain entries. An SIIT router SHOULD acknowledge DELTA update messages. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Msg-typ| Length |M| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transaction ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IPv6 address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Msg-type = 3 Indicates a message reply type. Length The number of 32-bit words following the Packet ID field. M If set indicates more messages will be received. This indicates that the reply couldn't be placed in one message. Transaction ID A 32-bit unsigned number identifying each transaction (ie. client request). Reserved 11-bit reserved field. MUST be set to zero. 4.6 Address-mapping cache Acknowledgement H. Soliman and Erik Nordmark SIIT-DSTM extensions [Page 14] INTERNET-DRAFT February 2001 Acknowldgement messages should be sent by the clients upon reception of an Address-mapping cache reply message from an AIIH server. An Acknowledgement message contains a code field that shows the result of processing the server's last message. Clients may choose not to send an acknowledgement for each received packet. However, an SIIT router MUST send an acknowledgement with the appropriate code value whenever it receives an erroneous message from an AIIH server. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Msg-typ| Code | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transaction ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Msg-type = 4 Indicates acknowledgement type. Reserved 24-bit reserved field. MUST be set to zero. Transaction ID A 32-bit unsigned number identifying each transaction (ie. client request). Code Indicates the status of the operation, whether it succeeded or not. Reserved values : 0 Operation successful 5 Operation failed. Error unspecified 6 Poorly formed message. The transaction id field identifies the transaction for which an acknowledgement is being sent. 4.7 Keepalive message Keepalive messages are introduced to ensure the availability of the connection between the SIIT routers and AIIH servers. The messages can be sent by either the clients or the server. It is recommended that the message is sent once per minute by each application. Each application should wait for a random length of time after starting up before sending the first message. H. Soliman and Erik Nordmark SIIT-DSTM extensions [Page 15] INTERNET-DRAFT February 2001 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg-type| Sequence no |R| Rsvd | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Msg-type = 5 Indicates a keepalive message type. Sequence number A 16-bit unsigned word that is used to identify the message. R If the R flag is set it indicates that this is a reply message. Rsvd A 12-bit reserved field. MUST be set to zero. The sender of a Keepalive message should generate the sequence number field by using a 16-bit rolling counter. The receiver of a Keepalive message MUST echo that message with the same sequence number and set the R flag in the reply. 5. Security considerations The reachability of an IPv6 node from an IPv4 requires that a unique IPv4 address is assigned to the IPv6 node. Since one of the main reasons for migrating to IPv6 is the scarcity of IPv4 addresses, such addresses need to be assigned to hosts in an optimal manner and only when needed (ie. on demand). The assignment of IPv4 addresses to IPv6 nodes based on DNS queries by the IPv4 host raises some security concerns and may be subject to DoS attacks. A malicious IPv4 node can send frequent DNS requests for some IPv6 to cause the AIIH server to run out of IPv4 addresses and allocating all the pooled addresses to IPv6 nodes that do not need them. This revision of the draft does not address this issue. 6. Acknowledgements The authors would like to thank Mattias Pettersson and Conny Larsson for their careful reviews of this draft. 7. Author's Addresses Hesham Soliman Ericsson Australia 61 Rigall St., Broadmeadows Melbourne, Victoria 3047 AUSTRALIA H. Soliman and Erik Nordmark SIIT-DSTM extensions [Page 16] INTERNET-DRAFT February 2001 Phone: +61 3 93012049 Fax: +61 3 93014280 E-mail: Hesham.Soliman@ericsson.com.au Erik Nordmark Sun Microsystems Laboratories 29, Chemin du Vieux Chene 38240 Meylan, France phone: +33 (0)4 76 18 88 03 fax: +33 (0)4 76 18 88 88 email: nordmark@sun.com 7. References [ADDR-ARCH] Deering, S. and R. Hinden, Editors, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [IPv6] Deering, S. and R. Hinden, Editors, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [MIPV6] D. Johnson and C. Perkins, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-12.txt. Work in progress. [SIIT] E. Nordmark, "Stateless IP/ICMP Translation Algorithm", RFC 2765, February 2000. [DSTM] J. Bound et al, _Dual Stack Transition Mechanism_, draft-ietf-ngtrans-dstm-04.txt (work in progress). This Internet-Draft expires in August 2001. H. Soliman and Erik Nordmark SIIT-DSTM extensions [Page 17]