Subject: Bump in the Wire IPv4/IPv6 Translator

From: "Paul C. Moster" <[email-masked]>
Date: Mon, 09 Oct 2006 15:04:41 -0400

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.
[email-masked]

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 [email-masked].

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: [email-masked]

    Lorraine Chin
    Datatek Applications, Inc.
    Somerset, NJ

    Phone: 732 667 1080
    EMail: [email-masked]

    Dave Green
    Command Information
    Herndon, VA

    EMail: [email-masked]

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

    [email-masked].

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]