Bump in the Wire IPv4/IPv6 Translator

["Paul C. Moster" <pcmoster@datatekcorp.com>]

I'm posting this draft on bump-in-the-wire proxy for the group to
consider as a working group document. This draft describes a technique
for making an IPv4-only host into a dual-stacked host via a
"bump" in   the "wire" connecting the
IPv4-only host to a dual-stacked network. This technique is appropriate
for legacy IPv4 hosts and applications where IPv6 capabilities are
required, but it is too costly to upgrade the host software/firmware.
This technique is easily extended so that an older application or host
on-link with the proxy can utilize E2E networking, strong IP-layer IPsec,
MIPv6, and other IPv6 features. 

Paul Moster
Datatek Applications, Inc.
pcmoster@datatekcorp.com



INTERNET-DRAFT                                    
P. Moster
draft-ietf-biw-00.txt                               
L. Chin
                                                   
D. Green
Category                                      
Informational
Expires: April
2007                            
October 2006

                
Bump-in-the-Wire IPv4/IPv6 Translator
                       
<draft-ietf-biw-00.txt>


Status of this Memo



   Status of this Memo

      This document is an Internet-Draft and is
subject to all provisions
      of Section 3 of RFC 3667.  By
submitting this Internet-Draft, each
      author represents that any applicable
patent or other IPR claims of
      which he or she is aware have been or will
be disclosed, and any of
      which he or she become aware will be
disclosed, in accordance with
      RFC 3668.

      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 to cite them other than as
"work in progress."

      The list of current Internet-Drafts can be
accessed at
     

http://www.ietf.org/ietf/1id-abstracts.txt.

      The list of Internet-Draft Shadow
Directories can be accessed at
     

http://www.ietf.org/shadow.html.

      This Internet-Draft will expire on August
28, 2005.


   This document is a product of the IPv6 Operations WG.
Comments should be
   addressed to the authors, or the mailing list at
v6ops@ops.ietf.org.



P. Moster, et
al.                                              
[Page 1]


INTERNET-DRAFT            
Expires: April
2007             
October 2006


Copyright Notice

   Copyright (C) The Internet Society (2006). All Rights
Reserved.



Abstract


   This draft describes a technique for making an IPv4-only
host into an
   IPv4/IPv6 host by inserting a translation device in front of
its
   connection to the network.  The translation device
makes a "bump" in
   the "wire" connecting the IPv4-only host to the
IPv4/IPv6 network,
   and serves as an IPv4/IPv6 proxy for the IPv4-only host on
the
   network.  This technique is appropriate for legacy IPv4
hosts and
   applications where IPv6 capabilities are required, but it is
too
   costly to upgrade the host software.


































P. Moster, et
al.                                              
[Page 2]


INTERNET-DRAFT            
Expires: April
2007             
October 2006


Table of Contents


   1. Introduction . . . . . . . . . . . . . . . . . . . . . .
. . .   4
   2. Address and Protocol Translation . . . . . . . . . . . .
. . .   5
   3. IPv4 Pass-through. . . . . . . . . . . . . . . . . . . .
. . .   7
   4. DNS ALG. . . . . . . . . . . . . . . . . . . . . . . . .
. . .   7
   5. Stateless Address Autoconfiguration. . . . . . . . . . .
. . .   9
   6. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . .
. . .  10
   7. Applicability and Limitations. . . . . . . . . . . . . .
. . .  10
   8. Acknowledgments. . . . . . . . . . . . . . . . . . . . .
. . .  13
   9. Security Considerations. . . . . . . . . . . . . . . . .
. . .  13
   10. References. . . . . . . . . . . . . . . . . . . . . . .
. . .  14
    10.1. Normative References . . . . . . . . . . . . . .
. . . . .  14
    10.2. Informative References . . . . . . . . . . . . .
. . . . .  14
   11. Authors' Addresses. . . . . . . . . . . . . . . . . . .
. . .  15



































P. Moster, et
al.                                              
[Page 3]


INTERNET-DRAFT            
Expires: April
2007             
October 2006


1.  Introduction


   Reliable, small, low cost single board computers are
available that
   can run a full suite of networking software and maintain
high packet
   forwarding rates.  This makes it practical to put
address and
   protocol translation devices at the edge of the network,
between
   individual hosts and the networks to which they
connect.  This draft
   describes such a translator, one that makes an IPv4-only
host appear
   to a dual network as an IPv4/IPv6 host.  We call this a
"bump-in-the-
   wire" (BIW) translator, conjuring up the image of small
device that
   forms a bump in "wire" connecting a host to a
network.  In practice,
   a BIW translator could also connect a host to a network
using a
   wireless interface.
                                         
______________
                                        
|             
|---[IPv6-only Host]
                                        
|             
|
   [IPv4-only Host]---[BIW Translator]---| Dual Network
|---[IPv4/IPv6 Host]
                                        
|             
|
                                        
|______________|---[IPv4-only Host]

   A BIW translator intercepts packets moving between its
host-side and
   the network-side interfaces, translating IPv4 to IPv6 and
vice versa.
   The translator uses the Stateless IP/ICMP Translation
Algorithm
   (SIIT) [RFC2765], with some minor modifications.  The
translator
   filters all DNS queries and replies through an application
layer
   gateway (ALG).  The translator participates in IPv6
Stateless Address
   Autoconfiguration (SLAAC) [RFC2462], and can act as a DHCP
server and
   client.  The detailed operation of each of these
functions is
   described in this draft.

   A BIW translator serves as the IPv4-only host's proxy, and
behaves
   identically to IPv4-only host it replaces, with the
exception of
   added IPv6 capability.  Conversely, a BIW translator
hides the dual
   IPv4/IPv6 network from the IPv4-only host, making it appear
to the
   host as an IPv4-only network.  Inserting a BIW
translator between an
   IPv4-only host and a dual IPv4/IPv6 network does not require
changes
   to the configuration of the network or the hosts that reside
on it.
   The IPv4-only host typically requires minor configuration
changes to
   use the translator as its proxy.

   A BIW translator allows the IPv4-only host to continue to
use IPv4
   for communications with other IPv4-only hosts on the the
network.
   Specifically, it does not make an IPv4-only host into an
IPv6-only
   host.






P. Moster, et
al.                                  
Section 1.  [Page 4]


INTERNET-DRAFT            
Expires: April
2007             
October 2006


2.  Address and Protocol Translation


   SIIT describes how IPv6-only nodes use a translator to
communicate
   with IPv4-only nodes through a predominantly IPv4
network.  For a BIW
   translator, the focus shifts.  A legacy IPv4-only node
uses a BIW
   translator to communicate with IPv4 and IPv6 nodes in a
mixed
   network.

   SIIT makes use of IPv4-mapped and IPv4-translated IPv6
addresses.
   These IPv6 addresses have an IPv4 address embedded within
them, so
   there is an algorithmic translation from an IPv4-mapped
or
   IPv4-translated IPv6 address to an IPv4 address, and vice
versa.
   However, this type of address translation is not appropriate
for a
   BIW translator.  It is unlikely that all IPv6 hosts
with which the
   translator communicates will have IPv6 addresses that
contain
   embedded IPv4 addresses.  Instead, their IPv6 addresses
are more
   likely to be configured with SLAAC, with prefixes chosen
for
   effective route aggregation.  As a result, a BIW
translator maps IPv4
   addresses to IPv6 addresses, and vice versa, using an an
ancillary
   mapping table.  Each entry in the mapping table
associates an IPv4
   address with an IPv6 address.

   A BIW translator needs a large, private pool of IPv4
addresses.  Most
   of the IPv4 addresses in the IPv4/IPv6 address mapping table
are
   drawn from this pool.  In a SIIT translator, IPv6-only
nodes acquire
   a temporary IPv4 address to communicate with IPv4-only
nodes.  For a
   BIW translator, it's reasonable to assume that the IPv4-only
host has
   a permanent IPv4 address assigned to it, and that this
address is
   available to the translator.  However, a BIW translator
needs an IPv4
   address for each IPv6 node that the IPv4-only node
communicates with.
   These addresses are generally drawn from the IPv4 address
pool.

   The IPv4 address pool is filled with private [RFC1918]
addresses.
   Addresses taken from the pool are only visible on the host
side of
   the translator, so they need not be globally unique. 
Each translator
   can reuse the same pool of private IPv4 addresses.  As
such, BIW
   translators do not compete for scarce IPv4 public addresses
to fill
   their pools.

   The address mapping table requires an entry for the
IPv4-only host
   that maps its IPv4 address to an IPv6 address.  The
host's IPv4
   address is typically drawn from the private address
pool.  The host's
   IPv6 address may be configured either by the administrator
or SLAAC,
   and is assigned to the translator's network-side
interface.

   The translator adds entries to the mapping table in response
to the
   following events:



P. Moster, et
al.                                  
Section 2.  [Page 5]


INTERNET-DRAFT            
Expires: April
2007             
October 2006


   - The DNS ALG adds an entry when the name server replies to
an AAAA-
   type query with an IPv6 address that is not already in the
table.
   The DNS ALG gets an IPv4 address from the pool, binds it to
the IPv6
   address of the target, and adds it to the mapping
table.

   - When the translator receives an IPv6 packet from the
network side,
   it checks if the mapping table contains the IPv6 source
address in
   the packet header.  If it does not, the translator gets
an IPv4
   address from the pool, binds it to the IPv6 source address,
and adds
   it to the mapping table.

   The translator's administrator can add entries to the
mapping table.
   This is appropriate, for example, when the legacy IPv4-only
host does
   not use a DNS server, but instead maps host names to IPv4
addresses
   through a local database.

   Once a mapping table entry is created, it persists
indefinitely.  The
   administrator may delete mapping table entries. 
However, the IPv6
   address space is much larger than the IPv4 address space,
and any
   size IPv4 address pool is subject to exhaustion.  When
the translator
   needs an IPv4 address to make a new mapping table entry and
the
   address pool is empty, the translator picks the least
recently used a
   mapping table entry and deletes it.  The IPv4 address
in the deleted
   entry is reclaimed and used in the new entry.  A
mapping table entry
   is said to be "used" when it is referenced during
translation.

   A BIW translator modifies the checksums in TCP and UDP
headers.  In a
   SIIT translator, the IPv4-to-IPv6 address translation
algorithm
   insures that the IPv4 and IPv6 addresses have the same 1's
complement
   sum, so the checksums of the original and translated packets
are the
   same.  The IPv4 and IPv6 addresses in the address
mapping table entry
   usually won't have the same sum, so the checksums will be
different.
   To modify the checksum, the translator computes a checksum
of the
   IPv4 source and destination addresses, and another checksum
for the
   corresponding IPv6 addresses.  In the IPv4 to IPv6
direction, the
   translator subtracts the IPv4 address checksum from the TCP
or UDP
   checksum, then adds the IPv6 address checksum.  The
order is reversed
   in the IPv6 to IPv4 direction.

   The translator performs address and protocol translation on
the
   "invoking packet" contained in an ICMP or ICMPv6
error message.  This
   include checksum modification, when the invoking packet
includes and
   TCP or UDP header.








P. Moster, et
al.                                  
Section 2.  [Page 6]


INTERNET-DRAFT            
Expires: April
2007             
October 2006


3.  IPv4 Pass-through


   A BIW translator provides an IPv4 pass-through capability
that allows
   the IPv4-only host to communicate with other IPv4-only hosts
in the
   network.  When the translator receives a packet from
the host-side
   interface, it checks if IPv4 destination address is bound to
an IPv6
   address.  If it is, the packet is translated to
IPv6.  If the address
   is not in the mapping table, but is part of the private IPv4
address
   pool, the translator discards the packet and responds to the
host
   with an ICMP host unreachable error message. 
Otherwise, the
   translator passes the packet through to the network-side
interface
   without protocol translation.

   When the IPv4-only host is assigned a private address, IPv4
address
   translation is needed to support pass-through.  In a
typical
   configuration, the host's original global IPv4 address is
assigned to
   the translator's network-side interface, and the host is
assigned an
   address from the translator's private pool.  For
packets passing from
   the host to the network, the translator changes the source
address
   from the private to the global address.  For packets
passing from
   from the network to the host, the translator changes the
destination
   address from the global to the private address.  The
translator also
   modifies the TCP and UDP checksums to adjust for the change
in
   addresses.



4.  DNS ALG


   A BIW translator has a DNS application layer gateway (ALG)
that
   intercepts queries from the IPv4-only host and replies from
the
   server.  The DNS ALG makes changes to queries and
replies and updates
   the IPv4/IPv6 address mapping table.  The DNS ALG only
accepts
   queries from the host-side interface and replies from the
network-
   side interface.

   Address queries from the IPv4-only host may contain names
that refer
   to IPv4-only, IPv4/IPv6, or IPv6-only hosts.  When the
translator's
   DNS ALG receives an A-type query (QTYPE=A in RFC1035
nomenclature)
   from the host, it processes the query as follows:

   - If the translator is connected to an IPv4-only network, it
forwards
   the query to the server unchanged.

   - If the translator is connected to a dual IPv4/IPv6
network, it
   sends two queries to the server, an A-type and an
AAAA-type.



P. Moster, et
al.                                  
Section 4.  [Page 7]


INTERNET-DRAFT            
Expires: April
2007             
October 2006


   - If the translator is connected to an IPv6-only network, it
changes
   the A-type query to an AAAA-type query and sends it to the
server.

   - If the translator has no network-side connection, it
replies to the
   host with an error message.

   The translator infers the IPv4 and IPv6 capabilities of the
network
   by the addresses assigned to its network-side interface
using to the
   following rules:

   - If both IPv4 and IPv6 addresses are configured, the
translator is
   attached to an dual IPv4/IPv6 network.

   - If only an IPv4 address is configured, the translator is
attached
   to an IPv4-only network.

   - If only an IPv6 address is configured, the translator is
attached
   to an IPv6-only network.

   - If no addresses are configured, the translator is not
connected to
   the network.

   IPv4 and IPv6 addresses can be assigned to the translator's
network-
   side interface either by the administrator or through an
automatic
   configuration process like SLAAC or DHCP.

   When the translator is connected to a dual IPv4/IPv6
network, the DNS
   ALG may receive replies to both its A-type and AAAA-type
queries.
   When this happens, the translator discards one of the
replies based
   on a configuration switch.  This switch has the effect
of giving
   preference to IPv4 or IPv6 for nodes that can communicate
using
   either protocol.  When the DNS ALG receives an
AAAA-type reply from
   the server, and either no A-type reply is received, or the
A-type
   reply is discarded, the DNS ALG changes the reply type from
AAAA to A
   before sending it to the host.

   The DNS ALG checks the Answer and Additional sections of all
replies
   for AAAA-type resource records (RRs) and converts them to
A-type RRs.
   The translator examines all replies since AAAA-type RRs
could be
   returned for in response to several query types.  For
each AAAA
   record in the reply, the DNS ALG checks if the IPv6 address
is in the
   IPv4/IPv6 mapping table.  If the IPv6 address is not in
the table,
   the DNS ALG gets an IPv4 address from the translator's pool
and makes
   a new entry.  In either case, the DNS ALG replaces
AAAA-type record
   with an A-type record containing the IPv4 address. 
When all RRs in
   the reply have been processed, the translator forwards the
converted
   reply to the host.




P. Moster, et
al.                                  
Section 4.  [Page 8]


INTERNET-DRAFT            
Expires: April
2007             
October 2006


   The DNS ALG also processes reverse lookup queries from the
host.
   When the DNS ALG receives a PTR-type query and the name ends
in IN-
   ADDR.ARPA, it checks if the IPv4 address is in the
translator's
   IPv4/IPv6 address mapping table.  If it is, the DNS ALG
changes the
   name to the corresponding IPv6 address with the IP6.ARPA
suffix and
   forwards the request to the server.  If the address is
in the
   translator's IPv4 address pool, but not the mapping table,
the the
   DNS ALG replies with a name error.  Otherwise, the
query is forwarded
   to the server unchanged.

   This process is reversed when the DNS ALG receives a reply
to a PTR-
   type query from the server.  If the name ends in
IP6.ARPA, IPv6
   address will be in the translator's IPv4/IPv6 mapping
table.  The DNS
   ALG changes the name to the corresponding IPv4 address and
sends the
   reply on to the host.

   Since the name server may be an IPv4-only host, an IPv4/IPv6
host, or
   an IPv6-only host, the DNS ALG can use either IPv4 or IPv6
to
   communicate with the server.  The DNS ALG uses only
IPv4 to
   communicate with the host.



5.  Stateless Address Autoconfiguration


   A BIW translator supports IPv6 Stateless Address
Autoconfiguration
   (SLAAC).  A practical translator requires two IPv6
addresses: one
   address represents the IPv4-only host, while the other
represents the
   translator itself.  The latter address allows the
translator to send
   and receive packets that are used for administration and
maintenance.
   These packets aren't translated to IPv4, and are not
forwarded to the
   IPv4-only host.

   To participate in SLAAC, the translator forms IPv6
link-local
   addresses for both itself and the IPv4-only host.  Each
link-local
   address requires a unique interface identifier.  The
translator
   typically forms its own interface identifier from the MAC
address of
   the network-side interface.  For the IPv4-only host,
the translator
   forms the interface identifier from the host's MAC
address.  While a
   BIW translator could, in principle, use the MAC address of
its host-
   side interface to form the host's interface identifier, it's
safer to
   use the host's MAC address.  This is because some
single board
   computers share a single MAC address between all network
interfaces.

   The method used to determine the host's MAC address depends
on the
   configuration.  If the host is a DHCP client, the
translator's DHCP
   server knows the host's MAC address.  If the host is
not a DHCP



P. Moster, et
al.                                  
Section 5.  [Page 9]


INTERNET-DRAFT            
Expires: April
2007             
October 2006


   client, the translator actively probes the host using ARP
to
   determine its MAC address.

   The translator forms global IPv6 addresses by combining
interface
   identifiers with prefixes contained in a router
advertisement
   message.  When the host's IPv6 global address is
formed, the
   translator adds an entry to its IPv4/IPv6 address mapping
table.  The
   entry consists of the host's IPv4 address and the global
IPv6 address
   formed through the SLAAC process.  Note that the
IPv4-only host's
   link-local address is not added to the translator's
IPv4/IPv6 address
   mapping table.  Packets sent to either of the
link-local addresses
   are never translated to IPv4 or sent to the IPv4-only
host.  Instead,
   they are processed locally by the translator.



6.  DHCP


   When the IPv4-only host is a DHCP client, a BIW translator
acts as a
   DHCP server on the host-side interface and a DHCP client on
the
   network-side interface.  As a DCHP server, the host
configuration
   parameters that the translator supplies to the host need not
match
   those that the translator obtains from the network. 
For example, the
   translator typically supplies an IPv4 address from its
private pool,
   and a subnet mask that includes the entire pool.  This
has the effect
   of putting all the IPv4 addresses in the pool, and the IPv6
hosts
   they represent, on the same subnet as the IPv4-only
host.  The
   translator also sets the host's default router and name
server
   addresses to IPv4 address of its host-side
interface.

   On the network-side, the translator obtains IPv4 host
configuration
   parameters from a DHCP server.  The translator uses the
parameters it
   obtains from the the network to configure its network-side
interface.
   The translator uses the same parameters that the host would
have used
   were it directly connected to the network.


7.  Applicability and Limitations


   A BIW translator is appropriate for legacy IPv4-only
systems, where
   it's too costly or time consuming to upgrade the application
and
   operating system software to support IPv6.  A BIW
translator gives
   these hosts access to advanced IPv6 features like
autoconfiguration,
   mobility and security.  While these legacy systems will
inevitably be
   discarded or upgraded to support IPv6, a BIW translator
extends their
   lifetime and reduces dependence on maintaining IPv4
connectivity.



P. Moster, et
al.                                 
Section 7.  [Page 10]


INTERNET-DRAFT            
Expires: April
2007             
October 2006


   Bump-in-the-stack [RFC2767] and Bump-in-the-API [RFC3338]
address the
   problem of host applications that are not aware of IPv6, but
which
   need to communicate using IPv6.  However, these
techniques require
   the development of new networking software for the host's
operating
   system.  This may not be cost effective, particularly
for older
   operating systems that do not support IPv6.  The
software developed
   to make a BIW translator can support any legacy operating
system or
   application.  The BIW software need not be ported to
each legacy
   operating system that it supports, since it runs on its own
single
   board computer with its own modern operating system. 
As IPv6
   protocols evolve and new protocols are developed, the BIW
software
   can be upgraded with no impact on the legacy operating
system.

   A BIW translator is similar to the Network Address
Translator -
   Protocol Translator (NAT-PT) described in [RFC2766]. 
The limitations
   of NAT-PT have been thoroughly investigated.  However,
a translator
   at the edge of the network, serving a single host, suffers
from few
   of the problems faced by one in the center of the
network.  For
   example, a NAT-PT introduces network topology constraints
and has
   problems with scalability.  It is also a single point
of failure and
   an inviting target for denial of service attacks. 
These are not
   problems for a BIW translator.

   A BIW translator has a DNS ALG that is similar to the one
described
   in NAT-PT.  The DNS ALG is cited as the source of
several problems
   with NAT-PT.  However, the DNS ALG in a BIW translator
is less
   troublesome, since it only handles queries generated by a
single
   IPv4-only host.  The DNS ALG in a NAT-PT must handle
all queries that
   pass between the IPv4 and IPv6 domains.


   A BIW translator is subject to the same basic limitations
that all
   address and protocol translators face.  These have been
described
   thoroughly in several RFCs and are only summarized
here.

   - A BIW translator disrupts protocols that embed the IP
address in
   the packet payload, like
FTP.  A BIW translator
requires a separate
   ALG for each of these protocols.

   - Information is lost when translating from IPv6 to
IPv4.  For
   example, there is no flow label field in IPv4.  This
may not be a
   significant problem, since the translator is co-located with
the
   IPv4-only host it serves.  Packets translated from IPv6
to IPv4 only
   traverse the private link between the translator and the
legacy host.
   For packets translated from IPv4 to IPv6, the translator can
create
   an appropriate flow label.

   - Packets using IPsec AH (in transport and tunnel mode) and
IPsec ESP



P. Moster, et
al.                                 
Section 7.  [Page 11]


INTERNET-DRAFT            
Expires: April
2007             
October 2006


   (in transport mode) can't be translated.  However, for
legacy
   IPv4-only hosts that don't support IPsec, a BIW translator
is a good
   place to add it.  The BIW translator would terminate
security
   associations.

   - A BIW translator is vulnerable to a DoS attack on its
address pool.
   It is a less inviting target than a NAT-PT, or other
central
   resource, since the attack could only succeed in denying
service to a
   single host.

   - IPv6 extension headers, like those used for IPv6 mobility
support,
   can't be translated to IPv4.  As with IPsec, a BIW
translator is a
   good place to add mobility support to a legacy host that has
none.
   The authors have demonstrated a BIW translator that adds
mobility to
   a legacy IPv4-only host without mobility.  It operates
as either
   mobile or correspondent node, and supports route
optimization and
   signaling security.

   - The translator may break an IPv4/IPv6 address binding to
reclaim an
   IPv4 address.  This can leave the IPv4-only host unable
to
   communicate with the IPv6-only host on the network side of
the broken
   binding.  For example, the DNS resolver on the
IPv4-only host may
   cache a name-to-IPv4-address binding.  If the
translator breaks the
   associated IPv4-to-IPv6 address binding, while the resolver
binding
   persists in host's cache, the translator will discard
packets that
   the host sends to the unbound IPv4 address.  The
binding would be
   recreated by a DNS query from the IPv4-only host or the
receipt of
   packet from the IPv6-only host, but these events may not
happen.

   For a NAT-PT or NAPT-PT at the Internet edge of an
enterprise
   network, binding persistence is a major problem, since it
shares a
   limited pool of global IPv4 addresses among a large group
of
   IPv6-only hosts.  To make the most use of the scarce
global IPv4
   addresses, the NAT-PT maintains the bindings only as long as
they are
   needed.  Unfortunately, it's difficult for the NAT-PT
to accurately
   determine how long the bindings are needed.

   For a BIW translator, the binding persistence problem is
less acute.
   A BIW translator maintains bindings indefinitely, breaking
them only
   when the IPv4 address pool is empty.  Since the pool is
composed of
   private addresses, it can be large.  While
"garbage" bindings will
   eventually accumulate in the address mapping table, they
will be
   reclaimed by the least recently used replacement
policy.

   - The current BIW translator implementation does not
support
   translation of multicast packets.  The authors plan
further research
   in this area.




P. Moster, et
al.                                 
Section 7.  [Page 12]


INTERNET-DRAFT            
Expires: April
2007             
October 2006


8.  Acknowledgments


   The authors wish to thank Larry Levine of the US Army CERDEC
for his
   support.  Ed Jankiewicz of SRI led the early
development effort.



9.  Security Considerations


   A BIW translator is vulnerable to denial-of-service
attacks.
   Specifically, the IPv4 address pool could be depleted by a
malicious
   sender of IPv6 packets.  When the translator receives
and IPv6 packet
   from the network side, it checks if there is an IPv4 address
bound to
   the IPv6 source address in the packet header.  If there
not, the
   translator gets a new IPv4 address from the pool and binds
it to the
   IPv6 source address.  The malicious sender could
deplete the pool by
   sending a sequence of packets to the translator, each with
a
   difference source address.  In practice, the IPv4
address pool is
   segmented, with separate regions reserved for bindings
created by the
   administrator, the DNS ALG, and arriving packets.  The
attack would
   only deplete this last segment of the pool, leaving IPv6
hosts unable
   to initiate communications with the IPv4-only host served by
the
   translator.  The IPv4-only host could still initiate
communications
   with IPv6 hosts.

























P. Moster, et
al.                                 
Section 9.  [Page 13]


INTERNET-DRAFT            
Expires: April
2007             
October 2006


10.  References

10.1.  Normative References

   [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., and G.
de Groot,
            
"Address Allocation for Private Internets", RFC 1597,
            
March 1994.

   [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless
Address
            
Autoconfiguration", RFC 2462, December 1998.

   [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation
Algorithm
            
(SIIT)", RFC 2765, February 2000.


10.2.  Informative References

   [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network
Address
            
Translation - Protocol Translation (NAT-PT)", RFC 2766,
            
February 2000.

   [RFC2767] Tsuchiya, K., Higuchi, H., and Y. Atarashi,
            
"Dual Stack Hosts using the "Bump-In-the-Stack"
Technique
            
(BIS)", RFC 2767, February 2000.

   [RFC3338] Lee, S., Shin, M-K., Kim, Y-J., Nordmark, E., and
A. Durand,
            
"Dual Stack Hosts Using "Bump-in-the-API" (BIA)", RFC
3338,
            
October 2002.























P. Moster, et
al.                              
Section 10.2.  [Page 14]


INTERNET-DRAFT            
Expires: April
2007             
October 2006


11.  Authors' Addresses


   Paul Moster
   Datatek Applications, Inc.
   Somerset, NJ

   Phone: 732 667 1080
   EMail: pcmoster@datatekcorp.com


   Lorraine Chin
   Datatek Applications, Inc.
   Somerset, NJ

   Phone: 732 667 1080
   EMail: lchin@datatekcorp.com


   Dave Green
   Command Information
   Herndon, VA

   EMail: green@commandinformation.com


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope
of any
   Intellectual Property Rights or other rights that might be
claimed to
   pertain to the implementation or use of the technology
described in
   this document or the extent to which any license under such
rights
   might or might not be available; nor does it represent that
it has
   made any independent effort to identify any such
rights.  Information
   on the procedures with respect to rights in RFC documents
can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and
any
   assurances of licenses to be made available, or the result
of an
   attempt made to obtain a general license or permission for
the use of
   such proprietary rights by implementers or users of
this
   specification can be obtained from the IETF on-line IPR
repository at
  

http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its
attention any
   copyrights, patents or patent applications, or other
proprietary
   rights that may cover technology that may be required to
implement
   this standard.  Please address the information to the
IETF at



P. Moster, et
al.                                
Section 11.  [Page 15]


INTERNET-DRAFT            
Expires: April
2007             
October 2006


   ietf-ipr@ietf.org.

Disclaimer of Validity

   This document and the information contained herein are
provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE
ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This
document is subject
   to the rights, licenses and restrictions contained in BCP
78, and
   except as set forth therein, the authors retain all their
rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by
the
   Internet Society.



























P. Moster, et
al.                                
Section 11.  [Page 16]