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