[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 draft-ietf-v6ops-natpt-to-exprmntl

v6ops Working Group                                              C. Aoun
Internet-Draft                                Nortel Networks/ENST Paris
Obsoletes: 2766 (if approved)                                  E. Davies
Expires: March 21, 2005                                  Nortel Networks
                                                      September 20, 2004


                      Reasons to Deprecate NAT-PT
                  draft-aoun-v6ops-natpt-deprecate-00

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 March 21, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).

Abstract

   This document discusses reasons why use of the specific form of
   IPv6-IPv4 protocol translation mechanism implemented by the Network
   Address Translator - Protocol Translator (NAT-PT) defined in RFC 2766
   should be deprecated and RFC2766 moved to historic status.
   Description of an alternative protocol translation mechanism is out
   of scope for this document.



Aoun & Davies            Expires March 21, 2005                 [Page 1]

Internet-Draft        NAT-PT Deprecation Analysis         September 2004


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Issues Unrelated to DNS-ALG  . . . . . . . . . . . . . . . . .  5
     2.1   Issues with Protocols Embedding IP Addresses . . . . . . .  5
     2.2   NAPT-PT Redirection Issues . . . . . . . . . . . . . . . .  6
     2.3   NAT-PT Binding State Decay . . . . . . . . . . . . . . . .  7
     2.4   Loss of Information through Incompatible Semantics . . . .  7
     2.5   NA(P)T-PT and Fragmentation  . . . . . . . . . . . . . . .  8
     2.6   NAT-PT Interaction with SCTP and Multihoming . . . . . . .  9
     2.7   NAT-PT as a Proxy Correspondent Node for MIPv6 . . . . . . 10
     2.8   NAT-PT and Multicast . . . . . . . . . . . . . . . . . . . 10
   3.  Issues exacerbated by the Use of DNS-ALG . . . . . . . . . . . 11
     3.1   Network Topology Constraints Implied by NAT-PT . . . . . . 11
     3.2   Scalability and Single Point of Failure Concerns . . . . . 12
     3.3   Issues with Lack of Address Persistence  . . . . . . . . . 13
     3.4   DOS Attacks on Memory and Address/Port Pools . . . . . . . 14
   4.  Issues Directly Related to use of DNS-ALG  . . . . . . . . . . 14
     4.1   Address Selection Issues when Communicating with Dual
           Stack End-hosts  . . . . . . . . . . . . . . . . . . . . . 14
     4.2   Non-global Validity of Translated RR Records . . . . . . . 16
     4.3   Inappropriate Translation of Responses to A Queries  . . . 16
     4.4   DNS-ALG and Multi-addressed Nodes  . . . . . . . . . . . . 17
     4.5   Limitations on Deployment of DNS Security Capabilities . . 17
   5.  Impact on IPv6 Application Development . . . . . . . . . . . . 17
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
   8.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 19
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 19
   10.   References . . . . . . . . . . . . . . . . . . . . . . . . . 20
   10.1  Normative References . . . . . . . . . . . . . . . . . . . . 20
   10.2  Informative References . . . . . . . . . . . . . . . . . . . 21
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22
       Intellectual Property and Copyright Statements . . . . . . . . 24

















Aoun & Davies            Expires March 21, 2005                 [Page 2]

Internet-Draft        NAT-PT Deprecation Analysis         September 2004


1.  Introduction

   A number of previous documents have raised issues with NAT-PT.  This
   document will summarize these issues, note several other issues
   carried over from traditional IPv4 NATs and identify some additional
   issues which have not been discussed elsewhere.  Where solutions to
   the issues have been proposed these are mentioned and any resulting
   need for changes to the specification identified.

   The v6ops working group has produced a number of transition scenario
   analyses.  NAT-PT has only featured as a possible mechanism in one of
   these, the 3GPP scenarios [I-D.ietf-v6ops-3gpp-analysis].  In the
   light of this limited applicability, for which there are possible
   alternatives, and the issues which would remain even if the
   identified solutions were appplied, this document draws the
   conclusion that the technical and operational difficulties resulting
   from these issues are sufficient to justify the deprecation of the
   usage of NAT-PT as described in [RFC2766] and moving RFC2766 to
   historic status.

   The following documents relating directly to NAT-PT have been
   reviewed while drafting this document:
   o  Network Address Translation - Protocol Translation (NAT-PT)
      [RFC2766]
   o  Stateless IP/ICMP Translation Algorithm (SIIT) [RFC2765]
   o  NAT-PT applicability statement
      [I-D.satapati-v6ops-natpt-applicability]
   o  Issues with NAT-PT DNS ALG in RFC2766
      [I-D.durand-natpt-dns-alg-issues]
   o  NAT-PT DNS ALG solutions [I-D.hallin-natpt-dns-alg-solutions]
   o  NAT-PT Security Considerations [I-D.okazaki-v6ops-natpt-security]
   o  Issues when translating between IPv4 and IPv6
      [I-D.vanderpol-v6ops-translation-issues]
   o  IPv6-IPv4 Translation mechanism for SIP-based services in Third
      Generation Partnership Project (3GPP) Networks
      [I-D.elmalki-sipping-3gpp-translator]
   o  Analysis on IPv6 Transition in 3GPP Networks
      [I-D.ietf-v6ops-3gpp-analysis]
   o  Considerations for Mobile IP Support in NAT-PT
      [I-D.lee-v6ops-natpt-mobility]
   o  An IPv6/IPv4 Multicast Translator based on IGMP/MLD Proxying (mtp)
      [I-D.tsuchiya-mtp]
   o  An IPv4 - IPv6 multicast gateway [I-D.venaas-mboned-v4v6mcastgw]
   o  Scalable mNAT-PT Solution [I-D.park-scalable-multi-natpt]

   Because the majority of the documents containing discussions of the
   issues are Internet Drafts which are unlikely to become RFCs, the
   issues are summarized here to avoid the need for normative



Aoun & Davies            Expires March 21, 2005                 [Page 3]

Internet-Draft        NAT-PT Deprecation Analysis         September 2004


   references.

   Some additional issues can be inferred from corresponding issues
   known to exist in 'traditional' IPv4 NATs.  The following documents
   are relevant:
   o  Protocol Complications with the IP Network Address Translator
      [RFC3027]
   o  IP Network Address Translator (NAT) Terminology and Considerations
      [RFC2663]

   There is some ambiguity in [RFC2766] about whether the Application
   Layer Gateway (ALG) for DNS (referred to as DNS-ALG in this document)
   is an integral and mandatory part of the specification.  The
   ambiguity arises mainly from the first section of the applicability
   section (Section 8) which appears to imply that 'simple' use of
   NAT-PT could avoid the use of the DNS-ALG.

   This is important because a number of the major issues arise from the
   interactions between DNS and NAT-PT.  However, detailed inspection of
   [RFC2766] shows that the 'simple' case has not been worked out and it
   is unclear how information about the address translation could be
   passed to the hosts in the absence of the DNS-ALG.  This document
   therefore assumes that the DNS-ALG is an integral part of NAT-PT:
   accordingly issues with the DNS-ALG must be considered as issues for
   the whole specification.

   Issues raised with NAT-PT can be categorized as follows:
   o  Issues which are independent of the use of a DNS-ALG:
      *  Disruption of all protocols which embed IP addresses (and/or
         ports) in packet payloads or which apply integrity mechanisms
         using IP addresses (and ports).
      *  Inability to re-direct traffic for protocols not built on top
         of specific transport layer protocols in situations where one
         NAPT-PT is translating for multiple IPv6 hosts.
      *  Requirement for applications to use keep alive mechanisms to
         workaround connectivity issues caused by premature NAT-PT state
         timeout.
      *  Loss of information due to incompatible semantics between IPv4
         and IPv6 versions of headers and protocols.
      *  Inability to redirect packet fragments after the first with
         NAPT-PT.
      *  Interaction with SCTP and multihoming.
      *  Need for NAT-PT to act as proxy for correspondent node when
         IPv6 node is mobile, with consequent restrictions on mobility.
      *  NAT-PT not being able to handle multicast traffic.
   o  Issues which are exacerbated by the use of a DNS-ALG:
      *  Constraints on network topology.




Aoun & Davies            Expires March 21, 2005                 [Page 4]

Internet-Draft        NAT-PT Deprecation Analysis         September 2004


      *  Scalability concerns together with introduction of single point
         of failure and security attack nexus.
      *  Lack of address mapping persistence: Some applications require
         address retention between sessions.  The user traffic will be
         disrupted if a different mapping is used.  The use of the
         DNS-ALG to create address mappings with limited lifetimes means
         that applications must start using the address shortly after
         the mapping is created, as well as keeping it alive once they
         start using it.
      *  Creation of a DOS threat relating to exhaustion of memory and
         address/port pool resources on the translator.
   o  Issues which result from the use of a DNS-ALG:
      *  Address selection issues when either the internal or external
         hosts implement both IPv4 and IPv6.
      *  Restricted validity of translated DNS records: a translated
         record may be forwarded to an application which cannot use it.
      *  Inappropriate translation of responses to A queries from IPv6
         nodes.
      *  Address selection issues and resource consumption in DNS-ALG
         with multi-addressed nodes.
      *  Limitations on DNS security capabilities when using DNS-ALG.

   Section 2, Section 3 and Section 4 discuss these groups of issues.
   Section 5 examines the consequences of deploying NAT-PT for
   application developers and the long term effects of NAT-PT on the
   further development of IPv6.

   The terminology used in this document is defined in [RFC2663],
   [RFC2766] and [RFC3314].

2.  Issues Unrelated to DNS-ALG

2.1  Issues with Protocols Embedding IP Addresses

   It is well known from work on IPv4 NATs (see Section 8 of [RFC2663]
   and [RFC3027]) that the large class of protocols which embed numeric
   IP addresses in their payloads either cannot work through NATs or
   require specific ALGs as helpers to translate the payloads in line
   with the address and port translations.  The same set of protocols
   cannot pass through NAT-PT.  The problem is exacerbated because the
   IPv6 and IPv4 addresses are of different lengths so that packet
   lengths as well as contents are altered.  [RFC2766] describes the
   consequences as part of the description of the FTP ALG: similar
   workarounds are needed for all protocols with embedded IP addresses
   that run over TCP transports.

   The issues raised in Sections 2 and 3 of [RFC2663] relating to
   authentication and encryption with NAT are also applicable to NAT-PT.



Aoun & Davies            Expires March 21, 2005                 [Page 5]

Internet-Draft        NAT-PT Deprecation Analysis         September 2004


   Implementing a suite of ALGs requires that NAT-PT equipment includes
   the logic for each of the relevant protocols.  Most of these
   protocols are continuously evolving, requiring continual and
   coordinated updates of the ALGs to keep them in step.

   Assuming that the NAT-PT contains a co-located ALG for one of the
   relevant protocols, the ALG could replace the embedded IP addresses
   and ports.  However this replacement can only happen if no
   cryptographic integrity mechanism is used and the protocol messages
   are sent in clear (i.e.  not encrypted).

   A possible workaround relies on the NAT-PT being party to the
   security association used to provide authentication and/or
   encryption.  The NAT-PT should then be aware of the cryptographic
   algorithms and keys used to secure the traffic and could modify and
   re-secure the packets: this would certainly complicate network
   operations and provides additional points of security vulnerability.

   Without terminating the security association on the NAT-PT, traffic
   using IPsec AH (in transport and tunnel mode) and IPsec ESP
   (transport mode) are unable to be carried through NAT-PT due to their
   usage of cryptographic integrity protection.

   A related issue with DNS security is discussed in Section 4.5.

2.2  NAPT-PT Redirection Issues

   Section 4.2 of [RFC3027] discusses problems specific to RSVP and
   NATs, one of which is actually a more generic problem for all port
   translators.  When several end-hosts are using a single NAPT-PT box,
   protocols that do not have a demultiplexing capability similar to
   transport layer port numbers may be unable to work through NAPT-PT
   (and any other port translator) because there is nothing for NAPT-PT
   to use to identify the correct binding.

   This type of issue affects IPsec encrypted packets where the
   transport port is not visible (although it might be possible to use
   the SPI as an alternative demultiplexer) and protocols, such as RSVP,
   which are carried directly in IP datagrams rather than using a
   standard transport layer protocol such as TCP or UDP.  In the case of
   RSVP, packets going from the IPv4 domain to the IPv6 domain do not
   necessarily carry a suitable demultiplexing field, because the port
   fields in the flow identifer and traffic specifications are optional.

   Several ad hoc workarounds could be used to solve the demultiplexing
   issues, however in most cases these solutions are not documented
   anywhere which could lead to non-deterministic, undesirable behavior
   (for example, such workarounds often assume particular network



Aoun & Davies            Expires March 21, 2005                 [Page 6]

Internet-Draft        NAT-PT Deprecation Analysis         September 2004


   topologies etc in order to function correctly; if the assumptions are
   not met in a deployment the workaround may not work as expected).

   This issue is closely related to the fragmentation issue described in
   Section 2.5.

2.3  NAT-PT Binding State Decay

   NAT-PT will generally use dynamically created bindings to reduce the
   need for IPv4 addresses both for NAT-PT and NAPT-PT.  NAT-PT uses
   soft state mechanisms to manage the address and port pools used for
   dynamically created address bindings.  This allows the NA(P)T-PT to
   operate autonomously without requiring clients to signal either
   implicitly or explicitly that a binding is no longer required.  In
   any case, without soft state timeouts network and application
   unreliability would inevitably lead to leaks, eventually causing
   address or port pool exhaustion.

   For a dynamic binding to persist for longer than the soft state
   timeout, packets must be sent periodically from one side of the
   NAT-PT to the other (which direction is not specified by the NAT-PT
   specification).  If no packets are sent in the proper direction, the
   NAT-PT binding will not be refreshed and the application connection
   will be broken.  Hence all applications need to maintain their NAT-PT
   bindings during long idle periods by incorporating a keep-alive
   mechanism, which may not be possible for legacy systems.

   Also [RFC2766] does not specify how to choose timeouts for bindings:
   as is discussed in [RFC2663] for traditional NATs, selecting suitable
   values is a matter of heuristics and coordinating with application
   expectations may be impossible.

2.4  Loss of Information through Incompatible Semantics

   NAT-PT reuses the SIIT header and protocol translations defined in
   [RFC2765].  Mismatches in semantics between IPv4 and IPv6 versions
   can lead to loss of information when packets are translated.  Three
   issues arising from this are:
   o  There is no equivalent in IPv4 for the flow label field of the
      IPv6 header.  Hence any special treatment of packets based on flow
      label patterns cannot be propagated into the IPv4 domain.
   o  IPv6 extension headers provide flexibility for improvements in the
      IP protocol suite in future.  New headers may be defined in future
      which do not have equivalents in IPv4.  In practice, some existing
      extensions such as routing headers and mobility extensions are not
      translatable.
   o  As described in section 2.2 of
      [I-D.satapati-v6ops-natpt-applicability] there are no equivalents



Aoun & Davies            Expires March 21, 2005                 [Page 7]

Internet-Draft        NAT-PT Deprecation Analysis         September 2004


      in IPv6 for some ICMP(v4) messages, while for others (notably the
      'Parameter Problem' messages) the semantics are not equivalent.
      Translation of such messages may lead to loss of information.
      However, this issue may not be very severe because the error
      messages relate to packets that have been translated by NAT-PT
      rather than arbitrary packets.  If the NAT-PT is functioning
      correctly, there is, for example, no reason why IPv6 packets with
      unusual extension headers or options should be generated.  This
      case is cited in [I-D.satapati-v6ops-natpt-applicability] as an
      example where the IPv6 error has no equivalent in IPv4 resulting
      in lost information.

   Loss of information in any of these cases could be a constraint to
   certain applications.

   A related matter concerns the propagation of the Differentiated
   Services Code Point (DSCP).  NAT-PT and SIIT simply copy the DSCP
   field when translating packets.  Accordingly the IPv4 and IPv6
   domains must have equivalent Per-Hop Behaviors for the same code
   point or alternative means must be in place to translate the DSCP
   between domains.

2.5  NA(P)T-PT and Fragmentation

   As mentioned in [RFC3027], simple port translators are unable to
   translate packet fragments other than the first from a fragmented
   packet because subsequent fragments do not contain the port number
   information.

   This means that generally fragmentation cannot be allowed for any
   traffic that traverses a NAPT-PT.  One attempted workaround requires
   the NAPT-PT to maintain state about fragmented packets in transit.
   This is not a complete solution because fragment misordering could
   lead to the first fragment appearing at the NAPT-PT after later
   fragments.  The NAPT-PT would then not have the information needed to
   translate the fragments received before the first.

   Although it would not be expected in normal operation, NAPT-PT needs
   to be proofed against receiving short first fragments which don't
   contain the transport port numbers.  Note that such packets are a
   problem for IPv6 stateful packet inspection.  The current
   specifications of IPv6 do not mandate any minimum packet size beyond
   the need to carry the unfragmentable part (which doesn't include the
   transport port numbers) or reassembly rules to minimise the effects
   of overlapping fragments, leaving IPv6 open to the sort of attacks
   described in [RFC1858] and [RFC3128].

   An additional concern arises when a fragmented IPv4 UDP packet, which



Aoun & Davies            Expires March 21, 2005                 [Page 8]

Internet-Draft        NAT-PT Deprecation Analysis         September 2004


   does not have a transport layer checksum, traverses a NAT-PT box.  As
   described in [RFC2766], the NAT-PT has to reconstruct the whole
   packet so that it can calculate the checksum needed for the
   translated IPv6 packet.  This can result in significant delay to the
   packet, especially if it has to be re-fragmented before transmission
   on the IPv6 side.

   If NA(P)T-PT boxes reassembled all incoming fragmented packets (both
   from the IPv4 and IPv6 directions) in the same way as they have to do
   for unchecksummed IPv4 UDP packets, this would be a solution to the
   first problem.  The cost would be considerable: apart from the
   potential delay problem if the outgoing packet has to be fragmented,
   the NA(P)T-PT would consume extra memory and CPU resources, making
   the NAT-PT even less scaleable (see Section 3.2).

   Packet reassembly in NA(P)T-PT also opens up the possibility of
   various fragment-related security attacks.  Some of these are
   analagous to attacks identified for IPv4.  Of particular concern is a
   DOS attack based on sending large numbers of small fragments without
   a terminating last fragment which would potentially overload the
   reconstruction buffers and consume large amounts of CPU resources.

2.6  NAT-PT Interaction with SCTP and Multihoming

   The Stream Control Transmission Protocol (SCTP) [RFC2960] is a
   transport protocol which has been standardized since SIIT was
   specified.  SIIT does not explicitly cover translation of SCTP, but
   SCTP uses transport port numbers in the same way as UDP and TCP so
   that similar techniques could be used.

   However, SCTP also supports multihoming.  During connection setup
   SCTP control packets carry embedded addresses which would have to be
   translated.  This would also require that the types of the options
   fields in the SCTP control packets were changed with consequent
   changes to packet length: the transport checksum would also have to
   be recalculated.  The ramifications of multihoming as it might
   interact with NAT-PT have not been fully explored.  Because of the
   'chunked' nature of data transfer it does not appear that state would
   have to be maintained to relate packets transmitted using the
   different IP addresses associated with the connection.  [Author's
   Note: This needs to be considered by an SCTP expert].

   Even if these technical issues can be overcome, using SCTP in a
   NAT-PT environment may effectively nullify the multihoming advantages
   of SCTP if all the connections run through the same NAT-PT.  The
   consequences of running a multihomed network with separate NAT-PT
   boxes associated with each of the 'homes' have not been fully
   explored, but one issue that will arise is described in Section 4.4.



Aoun & Davies            Expires March 21, 2005                 [Page 9]

Internet-Draft        NAT-PT Deprecation Analysis         September 2004


   SCTP will need an associated 'ALG' - actually a Transport Layer
   Gateway - to handle the packet payload modifications.  If it turns
   out that state is required, the state would have to distributed and
   synchronized across several NAT-PT boxes in a multihomed environment.

   SCTP running through NAT-PT in a multihomed environment is also
   incompatible with IPsec as described in Section 2.1.

2.7  NAT-PT as a Proxy Correspondent Node for MIPv6

   As discussed in [I-D.lee-v6ops-natpt-mobility], it is not possible to
   propagate Mobile IPv6 control messages into the IPv4 domain.
   According to the IPv6 Node Requirements
   [I-D.ietf-ipv6-node-requirements], IPv6 nodes should normally be
   prepared to support the route optimization mechanisms needed in a
   correspondent node.  If communications from an IPv6 mobile node is
   traversing a NAT-PT, the destination IPv4 node is not going to
   support the correspondent node features needed for route
   optimization.

   This can be resolved in two ways:
   o  The NAT-PT can discard messages and headers relating to changes of
      care-of addresses including reverse routing checks.
      Communications with the mobile node will continue through the home
      agent without route optimization.  This is clearly sub-optimal but
      communication should remain possible.
   o  Additional functionality could be implemented in the NAT-PT to
      allow it to function as a proxy correspondent node for all IPv4
      nodes for which it has bindings.  This scheme adds considerably to
      the complexity of NAT-PT.  Depending on the routability of the
      IPv6 PREFIX used for translated IPv4 addresses, it may also limit
      the extent of mobility of the mobile node: all communications to
      the IPv4 destination have to go through the same NAT-PT even if
      the mobile node moves to a network which does not have direct IPv6
      connectivity with the NAT-PT.

   In both cases the existing NAT-PT specification would need to be
   extended to deal with IPv6 mobile nodes and neither is a fully
   satisfactory solution.

2.8  NAT-PT and Multicast

   SIIT [RFC2765] cannot handle translation of multicast packets and
   NAT-PT does not discuss a way to map multicast addresses between IPv4
   and IPv6.  Some separate work has been done to provide an alternative
   mechanism to handle multicast.  This uses a separate gateway which
   understands some or all of the relevant multicast control and routing
   protocols in each domain.  This work has not been carried through



Aoun & Davies            Expires March 21, 2005                [Page 10]

Internet-Draft        NAT-PT Deprecation Analysis         September 2004


   into standards as yet.

   A basic mechanism which involves only IGMP on the IPv4 side and MLD
   on the IPv6 side is described in 'An IPv6/IPv4 Multicast Translator
   based on IGMP/MLD Proxying (mtp)' [I-D.tsuchiya-mtp].  A more
   comprehensive approach which includes proxying of the multicast
   routing protocols is described in 'An IPv4 - IPv6 multicast gateway'
   [I-D.venaas-mboned-v4v6mcastgw].  Both approaches have several of the
   issues described in this section, notably issues with embedded
   addresses.

   [I-D.okazaki-v6ops-natpt-security] identifies the possibility of a
   multiplicative reflection attack if the NAT-PT can be spoofed into
   creating a binding for a multicast address.  This attack would be
   very hard to mount because routers should not forward packets with
   muticast addresses in the source address field.  However, it points
   up that a naively implemented DNS-ALG could create such bindings from
   spoofed DNS responses since [RFC2766] does not mention the need for
   checks on the types of addresses in these responses.

   The issues for NAT-PT and multicast reflect the fact that NAT-PT is
   at best a partial solution.  Completing the translation solution to
   cater for multicast traffic is likely to carry a similar set of
   issues to the current unicast NAT-PT and may open up significant
   additional security risks.

3.  Issues exacerbated by the Use of DNS-ALG

3.1  Network Topology Constraints Implied by NAT-PT

   Traffic flow initiators in a NAT-PT environment are dependent on the
   DNS-ALG in the NAT-PT to provide the mapped address needed to
   communicate with the flow destination on the other side of the
   NAT-PT.  Whether used for flows initiated in the IPv4 domain or the
   IPv6 domain, the NAT-PT has to be on the path taken by the DNS query
   sent by the flow initiator to the relevant DNS server; otherwise the
   DNS query will not be modified and the response type would not be
   appropriate.

   The implication is that the NAT-PT box also has to be the default
   IPv6 router for the site in order that the DNS-ALG is able to examine
   all DNS requests made over IPv6.  On sites with both IPv6 and
   dual-stack nodes, this will result in all traffic flowing through the
   NAT-PT with consequent scalability concerns.

   These constraints are described in more detail in
   [I-D.durand-natpt-dns-alg-issues].




Aoun & Davies            Expires March 21, 2005                [Page 11]

Internet-Draft        NAT-PT Deprecation Analysis         September 2004


   [I-D.hallin-natpt-dns-alg-solutions] proposes a solution for flows
   initiated from the IPv6 domain but it appears that this solution
   still has issues.

   For IPv6-only clients the solution requires the use of a DNS server
   in the IPv4 domain accessed via an IPv6 address which uses the NAT-PT
   PREFIX (see [RFC2766]).  Queries to this server would necessarily
   pass through the NAT-PT.  Dual-stack hosts would use a separate DNS
   server accessed through a normal IPv6 address.  This removes the need
   for the NAT-PT box to be the default IPv6 gateway for the domain.

   The primary proposal suggests that the IPv6-only clients should use
   this DNS server for all queries.  This is expensive on NAT-PT
   resources because requests relating to hosts with native IPv6
   addresses would also use the NAT-PT DNS-ALG.

   The alternate suggestion to reduce this burden appears to be flawed:
   if IPv6-only clients are provided with a list of DNS servers
   including both the server accessed via NAT-PT and server(s) accessed
   natively via IPv6, the proposal suggests that the client could avoid
   using NAT-PT for hosts that have native IPv6 addresses.

   Unfortunately for the alternate suggestion, there is no a priori way
   in which the initiator can decide which DNS server to use for a
   particular query.  In the event that the initiator makes the wrong
   choice, the DNS query will return an empty list rather than failing
   to respond.  With standard DNS logic, the initiator will not try
   alternative DNS servers because it has received a response.  This
   means that the solution would consist of always using DNS servers
   having the NAT-PT prefix.  This imposes the burden of always
   requiring DNS RR [RFC1035] translation.

   For flows initiated from the IPv4 network, the proposal recommends
   that the advertised DNS servers for the IPv6 network would have the
   IPv4 address of the NAT-PT.  Again there is no deterministic way to
   choose the correct DNS server for each query resulting in the same
   issues as were raised for flows initiated from the IPv6 domain.

   Although the engineering workaround, just described, provides a
   partial solution to the topology constraints issue it mandates that
   DNS queries and responses should still go through a NAT-PT even if
   there would normally be no reason to do so.  This mandatory passage
   through the NAT-PT for all DNS requests will exacerbate the other DNS
   related issues discussed in Section 3.4 and Section 4.1.

3.2  Scalability and Single Point of Failure Concerns

   As with traditional NAT, NAT-PT is a bottleneck in the network with



Aoun & Davies            Expires March 21, 2005                [Page 12]

Internet-Draft        NAT-PT Deprecation Analysis         September 2004


   significant scalability concerns and the anchoring of flows to a
   particular NAT-PT makes the NAT-PT a potential single point of
   failure in the network.  The addition of the DNS-ALG in NAT-PT
   further increases the scalability concerns.

   Solutions to both problems have been envisaged using collections of
   cooperating NAT-PT boxes, but such solutions require coordination and
   state synchronization which has not yet been standardized and again
   adds to the functional and operational complexity of NAT-PT.  One
   such solution is described in [I-D.park-scalable-multi-natpt].

   As with traditional NAT, the concentration of flows through NAT-PT
   and the legitimate modification of packets in the NAT-PT make NAT-PTs
   enticing targets for security attacks.

3.3  Issues with Lack of Address Persistence

   Using the DNS-ALG to create address bindings requires that the
   application uses the translated address returned by the DNS query
   before the NAT-PT binding state is timed out (see Section 2.3).
   Applications will not normally be aware of this constraint, which may
   be different from the existing lifetime of DNS query responses.  This
   could lead to difficult to diagnose problems with applications.

   Additionally, the DNS-ALG needs to determine the initial lifetime of
   bindings which it creates.  As noted in Section 2.3, this may need to
   be determined heuristically.  The DNS-ALG does not know which
   protocol the mapping is to be used for, and so needs another way to
   determine the initial lifetime.  This could be tied to the DNS
   response lifetime but this might open up additional DOS attack
   possibilities if very long validities are allowed.  Also the lifetime
   should be adjusted once the NAT-PT determines which protocol is being
   used with the binding.

   As with traditional NATs (see Section 2.5 of [RFC3027], NAT-PT will
   most likely break applications that require address mapping to be
   retained across contiguous sessions.  These applications require the
   IPv4 to IPv6 address mapping to be retained between sessions so the
   same mapped address may be reused for subsequent session
   interactions.  NAT-PT cannot know this requirement and may reassign
   the previously used mapped address to different hosts between
   sessions.

   Trying to keep NAT-PT from discarding an address mapping would
   require either a NAT-PT extension protocol that would allow the
   application to request the NAT-PT device to retain the mappings, or
   an extended ALG (which has all the issues discussed in Section 2.1)
   that can interact with NAT-PT to keep the address mapping from being



Aoun & Davies            Expires March 21, 2005                [Page 13]

Internet-Draft        NAT-PT Deprecation Analysis         September 2004


   discarded after a session.

3.4  DOS Attacks on Memory and Address/Port Pools

   As discussed in Section 2.3 a NAT-PT may create dynamic NAT bindings
   each of which consumes memory resources as well as an address (or
   port if NAPT-PT is used) from an address (or port) pool.  A number of
   documents, including [RFC2766] and [I-D.okazaki-v6ops-natpt-security]
   discuss possible denial of service (DOS) attacks on NA(P)T-PT which
   result in resource depletion associated with address and port pools.
   NAT-PT does not specify any authentication mechanisms so that an
   attacker may be able to create spurious binds by spoofing addresses
   in packets sent through NAT-PT.  The attack is more damaging if the
   attacker is able to spoof protocols with long binding timeouts
   (typically used for TCP).

   The use of the DNS-ALG in NAT-PT introduces another vulnerability
   which can result in resource depletion.  The attack identified in
   [I-D.durand-natpt-dns-alg-issues] exploits the use of DNS queries
   traversing NAT-PT to create dynamic bindings.  Every time a DNS query
   is sent through the NAT-PT the NAT-PT may create a new NA(P)T-PT bind
   without any end-host authentication or authorization mechanisms.
   This behavior could lead to a serious DOS attack on both memory and
   address or port pools.  Address spoofing is not required.

   [I-D.hallin-natpt-dns-alg-solutions] proposes to mitigate the DOS
   attack by using ACLs and static binds which increases the operational
   cost and may not always be practical.

   The ideal mitigation solution would be to disallow dynamically
   created binds until authentication and authorization of the end-host
   needing the protocol translation has been carried out.  This would
   require that the proper security infrastructure be in place to
   support the authentication and authorization, which increases the
   network operational complexity.

4.  Issues Directly Related to use of DNS-ALG

4.1  Address Selection Issues when Communicating with Dual Stack
    End-hosts

   [I-D.durand-natpt-dns-alg-issues] discusses NAT-PT DNS-ALG issues
   with regard to address selection.  As specified in [RFC2766], the
   DNS-ALG returns AAAA RRs from two possible sources to the IPv6 host
   which has made an AAAA DNS query AAAA.

   If the query relates to a dual-stack host, the query will return both
   the native IPv6 address(es) and the translated IPv4 address(es) in



Aoun & Davies            Expires March 21, 2005                [Page 14]

Internet-Draft        NAT-PT Deprecation Analysis         September 2004


   AAAA RRs.  Without additional information, the IPv6 host address
   selection may pick a translated IPv4 address instead of selecting the
   more appropriate native IPv6 address.  Under some circumstances, the
   address selection algorithms will always prefer the translated
   address over the native IPv6 address which is obviously undesirable.

   [I-D.hallin-natpt-dns-alg-solutions] proposes a solution which
   involves modification to the NAT-PT specification intended to return
   only the most appropriate address(es) to an IPv6 capable host:
   o  When a DNS AAAA query traverses the NAT-PT DNS-ALG, the NAT-PT
      will forward the query to the DNS server in the IPv4 domain
      unchanged but using IPv4 transport:
      *  If the authoratative DNS server has one or more AAAA records,
         it returns them.  The DNS-ALG then forwards this response to
         the IPv6 host and does not send an A query as the standard
         NAT-PT would do.
      *  Otherwise, if the the DNS server does not understand the AAAA
         query or has no AAAA entry for the host, it will return an
         error.  The NAT-PT DNS-ALG will intercept the error or empty
         return and send an A query for the same host.  If this query
         returns an IPv4 address, the ALG creates a binding and
         synthesizes a corresponding AAAA record which it sends back to
         the IPv6 host.
   o  The NAT-PT thus forwards the result of the first successful DNS
      response back to the end-host or an error if neither succeeeds.
      Consequently only AAAA RRs from one source will be provided
      instead of two as specified in [RFC2766] and it will contain the
      most appropriate address for a dual-stack or IPv6-only querier.

   There is, however, still an issue with the proposed solution:
   o  The DNS client may timeout the query ifit doesn't receive a
      response in time.  This is more likely because the NAT-PT may have
      to make two separate queries sequentially which the client is not
      aware of.  It may be possible to reduce the response time by
      sending the two queries in parallel and ignoring the result of the
      A query if the AAAA returns one or more addresses.  However it is
      still necessary to delay after receiving the first response to
      determine if a second is coming, which may still trigger the DNS
      client timeout.

   Unfortunately, the two queries cannot be combined in a single DNS
   request (all known DNS servers only process a single DNS query per
   request message because of difficulties expressing authoritativeness
   for arbitrary combinations of requests).

   An alternative solution would be to allow the IPv6 host to have
   within its address selection policies the NAT-PT PREFIX [RFC2766]
   used and assign to it a low selection priority.  This solution



Aoun & Davies            Expires March 21, 2005                [Page 15]

Internet-Draft        NAT-PT Deprecation Analysis         September 2004


   requires a automatic configuration of the NAT-PT PREFIX as well as
   its integration within the address selection policies.  The simplest
   way to integrate this automatic configuration would be through
   configuration file download (in case the host or DHCPv6 server did
   not support vendor options - to avoid standardization effort on the
   NAT-PT PREFIX option).  This solution does not require any
   modification to the NAT-PT specification.

   Neither of these solutions resolves a second issue related to address
   selection identified in [I-D.durand-natpt-dns-alg-issues].
   Applications have no way of knowing that the IPv6 address returned
   from the DNS-ALG is not a 'real' IPv6 address, but a translated IPv4
   address.  The application may therefore be led to believe that it has
   end-to-end IPv6 connectivity with the destination.  As a result, the
   application may use IPv6 specific options that are not supported by
   NAT-PT.  This issue is closely related to the issue described in
   Section 4.2 and the discussion in Section 5.

4.2  Non-global Validity of Translated RR Records

   Some applications propagate information records retrieved from DNS to
   other applications.  The published semantics of DNS imply that the
   results will be consistent to any user for the duration of the
   attached lifetime.  RR records translated by NAT-PT violate these
   semantics because the retrieved addresses are only usable for
   communications through the translating NAT-PT.

   Applications which pass on retrieved DNS records to other
   applications will generally assume that they can rely on the passed
   on addresses to be usable by the receiving application.  This may not
   be the case if the receiving application is on another node
   especially if it is not in the domain served by the NAT-PT which
   generated the translation.

4.3  Inappropriate Translation of Responses to A Queries

   Some applications running on dual-stack nodes may wish to query the
   IPv4 address of a destination.  If the resulting A query passes
   through the NAT-PT DNS-ALG, the DNS-ALG will translate the response
   inappropriately into a AAAA record using a translated address.  This
   happens because the DNS-ALG specified in [RFC2766] operates
   statelessly and hence has no memory of the IPv6 query which induced
   the A request on IPv4 side.  The default action is to translate the
   response.

   The specification of NAT-PT could be modified to maintain minimal
   state about queries passed through the DNS-ALG, and hence to respond
   correctly to A queries as well as AAAA queries.



Aoun & Davies            Expires March 21, 2005                [Page 16]

Internet-Draft        NAT-PT Deprecation Analysis         September 2004


4.4  DNS-ALG and Multi-addressed Nodes

   Many IPv6 nodes, especially in multihomed situations but also in
   single homed deployments, can expect to have multiple global
   addresses.  The same may be true for multihomed IPv4 nodes.
   Responses to DNS queries for these nodes will normally contain all
   these addresses.  Since the DNS-ALG in the NAT-PT has no knowledge
   which of the addresses can or will be used by the application issuing
   the query, it is obliged to translate all of them.

   This could be a significant drain on resources in both NAT-PT and
   NAPT-PT, as bindings will have to be created for each address.

   When using SCTP in a multihomed network, the problem is exacerbated
   if multiple NAT-PTs translate mutiple addresses:  Also it is not
   clear that SCTP will actually look up all the destination IP
   addresses via DNS so that bindings may not be in place when packets
   arrive.

4.5  Limitations on Deployment of DNS Security Capabilities

   Secure DNS (DNSSEC) [I-D.ietf-dnsext-dnssec-intro] uses public key
   cryptographic signing to authenticate DNS responses.  The DNS-ALG
   modifies DNS query responses traversing the NAT-PT in both directions
   which would invalidate the signatures as (partially) described in
   Section 7.5 of [RFC2766].

   Workarounds have been proposed, such as making the DNS-ALG behave
   like a secure DNS server.  This would need to be done separately for
   both the IPv6 and IPv4 domains.  This is operationally very complex
   and there is a risk that the server could be accessed in mistake for
   a conventional DNS server.  The NAT-PT specification would have to be
   altered to implement any such workaround.

   Hence DNSSEC is not deployable in domains that use NAT-PT as
   currently specified.  Widespread deployment of NAT-PT would become a
   serious obstacle to the large scale deployment of DNSSEC.

5.  Impact on IPv6 Application Development

   One of the major design goals for IPv6 is to restore the end-to-end
   transparency of the Internet.  Because IPv6 may be expected to remove
   the need for NATs and similar impediments to transparency, developers
   creating applications to work with IPv6 may be tempted to assume that
   the complex and (development) time-consuming expedients that might
   have been needed to make the application work in an 'NATted' IPv4
   environment are not required.




Aoun & Davies            Expires March 21, 2005                [Page 17]

Internet-Draft        NAT-PT Deprecation Analysis         September 2004


   Consequently some classes of applications (e.g., peer-to-peer) that
   would need special measures to manage NAT traversal, including
   special encapsulations, attention to binding lifetime and provision
   of keepalives, may build in assumptions on whether IPv6 is being used
   or not.  Developers would also like to exploit additional
   capabilities of IPv6 not available in IPv4.

   NAT-PT as specified in [RFC2766] is intended to work autonomously and
   be transparent to applications.  There is therefore no way for
   application developers to discover that a path contains a NAT-PT.

   If NAT-PT is deployed, applications that have assumed a NAT-free IPv6
   environment may break when the traffic passes through a NAT-PT.  This
   is bad enough, but requiring developers to include special
   capabilities to workaround what is supposed to be a temporary
   transition 'aid' is even worse.  Finally, deployment of NAT-PT is
   likely to inhibit the development and use of additional IPv6
   capabilities enabled by the flexible extension header system in IPv6
   packets.

   Some of these deleterious effects could possibly be alleviated if
   applications could discover the presence of NAT-PT boxes on paths in
   use, allowing them to take steps to workaround the problems.  However
   requiring applications to incorporate extra code to workaround
   problems with a transition aid still seems to be a very bad idea:
   the behavior of the application in native IPv6 and NAT-PT
   environments would be likely to be significantly different.

6.  Security Considerations

   This document summarizes security issues related to the NAT-PT
   [RFC2766] specification.  Security issues are discussed in various
   sections:
   o  Section 2.1 discusses how IPsec AH (transport and tunnel mode) and
      IPsec ESP transport mode are broken by NAT-PT; and authentication
      and encryption are generally incompatible with NAT-PT.
   o  Section 2.5 discusses possible fragmentation related security
      attacks on NAT-PT.
   o  Section 2.8 discusses security issues related to multicast
      addresses and NAT-PT.
   o  Section 3.3 highlights that NAT-PT is an enticing nexus for
      security attacks.
   o  Section 3.4 discusses possible NAT-PT DOS attacks on both memory
      and address/port pools.
   o  Section 4.5 discusses why NAT-PT is incompatible with DNSSEC
      [RFC2535] and how deployment of NAT-PT may inhibit deployment of
      DNSSEC.




Aoun & Davies            Expires March 21, 2005                [Page 18]

Internet-Draft        NAT-PT Deprecation Analysis         September 2004


7.  IANA Considerations

   There are no IANA considerations defined in this document.

8.  Conclusion

   This document has discussed a number of significant issues with
   NAT-PT.  Even where solutions have been conceived, the solutions
   still have significant drawbacks.  From a deployment perspective 3GPP
   networks are currently the only realistic scenario where an IPv6 only
   host communicates with an IPv4 only host.  However there is a point
   which has maybe not been emphasized sufficiently within the 3GPP IPv6
   transition analysis [I-D.ietf-v6ops-3gpp-analysis]: although one PDP
   context [RFC3314] is active on one radio channel for a specific IP
   protocol, the other IP protocol could be tunneled over the active
   one.  Hence simultaneous IPv4 and IPv6 connectivity would be provided
   without the need of a gateway between IPv4-only and IPv6-only
   end-hosts.

   Arguments against the usage of tunneling, especially in cellular
   wireless applications can be refuted in this particular case:
   o  Over low bandwidth links, the tunneling overhead should be
      significantly reduced when mechanisms such as Robust Header
      Compression (ROHC, [RFC3095]) are used.  It is possible that ROHC
      needs to be optimized to support tunneling, the next version of
      this draft will investigate that matter.
   o  Tunnel configuration will certainly be an issue if it is not
      automatic and transparent to users particularly for wireless
      handsets.  The simplest way to handle configuration in a 3GPP
      environment would be to have the GGSN be the tunnel endpoint and
      assign the tunneled protocol address.

   In case tunneling may not be possible, due to the existing deployed
   base of 3GPP hosts, application proxies would be an alternative.

   Although some of issues identified with NAT-PT appear to have
   solutions, many of the solutions required significant alterations to
   the existing specification and would be likely to increase
   operational complexity.  Even if these solutions were applied, we
   have shown that NAT-PT still has significant irresolvable issues, has
   limited applicability and that alternatives exist.  Accordingly we
   invite the IETF to deprecate its usage within the Internet, move
   RFC2766 to historic status and recommend, instead, the alternatives
   discussed above.

9.  Acknowledgments

   This work builds on a large body of existing work examining the



Aoun & Davies            Expires March 21, 2005                [Page 19]

Internet-Draft        NAT-PT Deprecation Analysis         September 2004


   issues and applicability of NAT-PT: the work of the authors of the
   documents referred in Section 1 has been extremely useful in creating
   this document.  Particular thanks are due to Pekka Savola for rapid
   and thorough review of the document.

10.  References

10.1  Normative References

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

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

   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
              RFC 2535, March 1999.

   [RFC2663]  Srisuresh, P. and M. Holdrege, "IP Network Address
              Translator (NAT) Terminology and Considerations", RFC
              2663, August 1999.

   [RFC3027]  Holdrege, M. and P. Srisuresh, "Protocol Complications
              with the IP Network Address Translator", RFC 3027, January
              2001.

   [RFC3095]  Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
              Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le,
              K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K.,
              Wiebke, T., Yoshimura, T. and H. Zheng, "RObust Header
              Compression (ROHC): Framework and four profiles: RTP, UDP,
              ESP, and uncompressed", RFC 3095, July 2001.

   [RFC3314]  Wasserman, M., "Recommendations for IPv6 in Third
              Generation Partnership Project (3GPP) Standards", RFC
              3314, September 2002.

   [RFC3484]  Draves, R., "Default Address Selection for Internet
              Protocol version 6 (IPv6)", RFC 3484, February 2003.

   [RFC3574]  Soininen, J., "Transition Scenarios for 3GPP Networks",
              RFC 3574, August 2003.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [I-D.ietf-ipv6-node-requirements]



Aoun & Davies            Expires March 21, 2005                [Page 20]

Internet-Draft        NAT-PT Deprecation Analysis         September 2004


              Loughney, J., "IPv6 Node Requirements",
              draft-ietf-ipv6-node-requirements-11 (work in progress),
              August 2004.

   [I-D.ietf-v6ops-3gpp-analysis]
              Wiljakka, J., "Analysis on IPv6 Transition in 3GPP
              Networks", draft-ietf-v6ops-3gpp-analysis-10 (work in
              progress), May 2004.

   [I-D.ietf-dnsext-dnssec-intro]
              Arends, R., Austein, R., Massey, D., Larson, M. and S.
              Rose, "DNS Security Introduction and Requirements",
              draft-ietf-dnsext-dnssec-intro-11 (work in progress), July
              2004.

10.2  Informative References

   [RFC1858]  Ziemba, G., Reed, D. and P. Traina, "Security
              Considerations for IP Fragment Filtering", RFC 1858,
              October 1995.

   [RFC3128]  Miller, I., "Protection Against a Variant of the Tiny
              Fragment Attack (RFC 1858)", RFC 3128, June 2001.

   [RFC2960]  Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
              Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
              Zhang, L. and V. Paxson, "Stream Control Transmission
              Protocol", RFC 2960, October 2000.

   [I-D.satapati-v6ops-natpt-applicability]
              Satapati, S., "NAT-PT Applicability",
              draft-satapati-v6ops-natpt-applicability-00 (work in
              progress), October 2003.

   [I-D.durand-natpt-dns-alg-issues]
              Durand, A., "Issues with NAT-PT DNS ALG in RFC2766",
              draft-durand-natpt-dns-alg-issues-00 (work in progress),
              February 2002.

   [I-D.hallin-natpt-dns-alg-solutions]
              Hallingby, P. and S. Satapati, "NAT-PT DNS ALG solutions",
              draft-hallin-natpt-dns-alg-solutions-01 (work in
              progress), July 2002.

   [I-D.durand-v6ops-dualstack-vs-natpt]
              Durand, A., "Dual stack vs NAT-PT",
              draft-durand-v6ops-dualstack-vs-natpt-00 (work in
              progress), February 2003.



Aoun & Davies            Expires March 21, 2005                [Page 21]

Internet-Draft        NAT-PT Deprecation Analysis         September 2004


   [I-D.lee-v6ops-natpt-mobility]
              Shin, M. and J. Lee, "Considerations for Mobility Support
              in NAT-PT", draft-lee-v6ops-natpt-mobility-00 (work in
              progress), June 2003.

   [I-D.okazaki-v6ops-natpt-security]
              Okazaki, S. and A. Desai, "NAT-PT Security
              Considerations", draft-okazaki-v6ops-natpt-security-00
              (work in progress), June 2003.

   [I-D.vanderpol-v6ops-translation-issues]
              Pol, R., Satapati, S. and S. Sivakumar, "Issues when
              translating between IPv4 and IPv6",
              draft-vanderpol-v6ops-translation-issues-00 (work in
              progress), January 2003.

   [I-D.elmalki-sipping-3gpp-translator]
              Malki, K., "IPv6-IPv4 Translation mechanism for SIP-based
              services in Third Generation  Partnership Project (3GPP)
              Networks", draft-elmalki-sipping-3gpp-translator-00 (work
              in progress), December 2003.

   [I-D.tsuchiya-mtp]
              Tsuchiya, K., Higuchi, H., Sawada, S. and S. Nozaki, "An
              IPv6/IPv4 Multicast Translator based on IGMP/MLD Proxying
              (mtp)", draft-tsuchiya-mtp-01 (work in progress), February
              2003.

   [I-D.venaas-mboned-v4v6mcastgw]
              Venaas, S., "An IPv4 - IPv6 multicast gateway",
              draft-venaas-mboned-v4v6mcastgw-00 (work in progress),
              February 2003.

   [I-D.park-scalable-multi-natpt]
              Park, S., "Scalable mNAT-PT Solution",
              draft-park-scalable-multi-natpt-00 (work in progress), May
              2003.


Authors' Addresses

   Cedric Aoun
   Nortel Networks/ENST Paris
   France

   EMail: cedric.aoun@nortelnetworks.com





Aoun & Davies            Expires March 21, 2005                [Page 22]

Internet-Draft        NAT-PT Deprecation Analysis         September 2004


   Elwyn B. Davies
   Nortel Networks
   Harlow Laboratories
   London Road
   Harlow, Essex  CM17 9NA
   UK

   Phone: +44 1279 405 498
   EMail: elwynd@nortelnetworks.com










































Aoun & Davies            Expires March 21, 2005                [Page 23]

Internet-Draft        NAT-PT Deprecation Analysis         September 2004


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
   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 (2004).  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.




Aoun & Davies            Expires March 21, 2005                [Page 24]


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