[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

IETF - NGTRANS Working Group                            Hesham Soliman,
INTERNET Draft                                          Ericsson
Expires: August 2001                                    Erik Nordmark
                                                        Sun Microsystems
                                                        November 2001



            Extensions to SIIT and DSTM for enhanced routing of
                              inbound packets
                   <draft-ietf-ngtrans-siit-dstm-01.txt>


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                                             November 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                                             November 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 and 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                                             November 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                                             November 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 |
           +--------+----+------------+------------+-------------+
              |          |            |            |             |
              |          V            V            V             V
              |      +--------+   +--------+   +--------+   +--------+
              |      | 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                                             November 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 MUST 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                                             November 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                                             November 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, i.e. between the MN and the SIIT router. On the other hand,
   route optimisation can not be achieved within the MIPv4 domain. 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 initiated 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                                             November 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 in the 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, i.e.
   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                                             November 2001


   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].

   To avoid triangular routing in the IPv6 domain, SIIT routers SHOULD
   process BUs 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.









H. Soliman and Erik Nordmark     SIIT-DSTM extensions          [Page 10]


INTERNET-DRAFT                                             November 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

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   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                                             November 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, alternatively, 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                                             November 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.
            7 Requested addresses unknown.

   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.



H. Soliman and Erik Nordmark     SIIT-DSTM extensions          [Page 13]


INTERNET-DRAFT                                             November 2001



   The code field shows the result of the processing of the client's
   request message. If the field includes a value corresponding to any
   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.

   If the reply was sent based on a request for some entries in the
   address-mapping cache (not the entire cache), and these addresses
   were not found, the reply MUST include the requested entries
   containing the unspecified IPv6 address and a lifetime field of Zero.
   The Code field MUSt be set to 7.

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



H. Soliman and Erik Nordmark     SIIT-DSTM extensions          [Page 14]


INTERNET-DRAFT                                             November 2001


                          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

   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.



H. Soliman and Erik Nordmark     SIIT-DSTM extensions          [Page 15]


INTERNET-DRAFT                                             November 2001



   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.

     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 (i.e. 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.

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 Radio Systems, AB.
   Torshamnsgatan 23,



H. Soliman and Erik Nordmark     SIIT-DSTM extensions          [Page 16]


INTERNET-DRAFT                                             November 2001


   Kista, Stockholm,
   SWEDEN

   Phone:  +46 8 4046619
   Fax:    +46 8 4047020
   E-mail: Hesham.Soliman@era.ericsson.se


   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-13.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 MAY 2002.










H. Soliman and Erik Nordmark     SIIT-DSTM extensions          [Page 17]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/