Internet Engineering Task Force
Internet Draft                                     Jordi Palet
Document: draft-palet-v6ops-proto41-nat-02.txt     Cesar Olvera
                                                   Consulintel
Category:                                          David Fernandez
                                                   UPM
Expires: April 2004                                October 2003



                    Forwarding Protocol 41 in NAT Boxes

                    draft-palet-v6ops-proto41-nat-02.txt


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [1].

   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.


















draft-palet-v6ops-proto41-nat-02.txt   Expires - April 2004   [Page 1]


Internet Draft   Forwarding Protocol 41 in NAT Boxes     October 2003


Abstract

   Some NAT boxes/routers allow the establishment of IPv6 tunnels from
   systems in the private LAN (using private IPv4 addresses) to routers
   or tunnel servers in the public Internet.

   As far as we know [2] this is not a common way of using IPv6 tunnels;
   the usual way is to finish the tunnel directly in a device with an
   IPv4 public address.

   This behavior provides a big opportunity to rapidly deploy a huge
   number of IPv6 nodes and networks, without the need of new transition
   mechanism. This option is very important to facilitate the IPv6
   deployment when is not possible to offer native IPv6 or 6to4 [3].

   From this point of view, this mechanism should be considered only as
   a temporary solution until native IPv6 routers, or those that support
   6to4, will become widely available.

   Not all the NAT boxes/routers support this mechanism, but this
   document describes this behavior and consequently provides hints that
   should be applied in the NAT boxes and tunnel brokers to facilitate
   it.




























draft-palet-v6ops-proto41-nat-02.txt  Expires - April 2004    [Page 2]


Internet Draft   Forwarding Protocol 41 in NAT Boxes     October 2003


Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [4].














































draft-palet-v6ops-proto41-nat-02.txt  Expires - April 2004    [Page 3]


Internet Draft   Forwarding Protocol 41 in NAT Boxes     October 2003


Table of Contents

   1. Introduction...................................................4

   2. Rationale for this behavior....................................6

   3. Behavior of different NAT types................................6

      3.1 Basic NAT..................................................7

      3.2 NAPT.......................................................7

      3.3 Bidirectional (or two-way) NAT.............................7

      3.4 "Configurable" NAT.........................................7

   4. Applicability..................................................8

   5. NAT design considerations......................................9

   6. Tunnel broker design considerations............................9

   7. Security Considerations........................................9

   8. References....................................................10

   Acknowledgments..................................................10

   Authors' Addresses...............................................10

   Intellectual Property Statement..................................11

   Full Copyright Statement.........................................11

   Acknowledgement..................................................12




1. Introduction

   The ability of some NAT boxes/routers to establish IPv6 tunnels from
   systems inside the private LAN (even using private IPv4 addresses) to
   routers or tunnel servers in the public Internet has been used for
   some time. However, it has not been documented so far.

   The goal of this document is to describe in detail that functionality
   and to show the rationale behind it, as well as to provide some



draft-palet-v6ops-proto41-nat-02.txt  Expires - April 2004    [Page 4]


Internet Draft   Forwarding Protocol 41 in NAT Boxes     October 2003


   recommendations for NAT boxes and tunnel broker implementers in order
   to facilitate its use and deployment.

   The basic scenario of the mechanism presented is shown in the Figure
   below.
                             ____
                            (    )
                           ( IPv6 )
                            (____)
                               |
        +--------+        +--------+
        | Tunnel |________| Tunnel |
        | Broker |        | Server |
        +--------+        +--------+
                  \      /     |
                   \____/      |
                   (    )      |
                  ( IPv4 )     |
                   (____)      | IPv6 Tunnel
                     |         |
         Public IPv4 |         |
                  +-----+      |
                  | NAT |      |
                  | Box |      |
                  +-----+      |
                     |         |
        Private IPv4 |         |
                +--------+     |
                | Tunnel |------
                | Client |------> (possible IPv6 or dual stack network)
                +--------+

   As can be seen, a Tunnel Client (a host or a router), which is
   connected to Internet through a NAT box using a private IPv4 address,
   establishes an IPv6 tunnel to a Tunnel Server with the help of a
   Tunnel Broker. The mechanism can also be used without a tunnel
   broker, ending the tunnel in an IPv6 router, which is configured
   manually.

   Typically, IPv6 routers on the Tunnel Server side support the
   establishment of these tunnels without any additional configuration.
   However, in the case of some clients under certain operating systems,
   the tunnel configuration process or the tunnel broker scripts have to
   be modified to reflect the private/public addressing conversion.

   This fact should be taken into consideration by tunnel broker
   implementations in future versions, in order to properly create the
   script in case the client is located in a private network.




draft-palet-v6ops-proto41-nat-02.txt  Expires - April 2004    [Page 5]


Internet Draft   Forwarding Protocol 41 in NAT Boxes     October 2003


   This document describes the reasons why this scenario works as it is
   using present NAT implementations. We consider that exploring this
   option is very important to facilitate the IPv6 deployment, as it can
   be used as a temporary fallback solution when neither native IPv6 nor
   6to4 mechanisms are available.

   The document does not discuss how the local private network is
   organized, for example, in case the Tunnel Client is an IPv6 router
   providing IPv6 connectivity to other systems. The behavior in this
   case should be the same as any other IPv6 native network (that is
   using stateless or stateful autoconfiguration, or any other typical
   functionalities like Home Agent, etc).

   Although this mechanism is not usable on all existing NAT
   boxes/routers, the large number of them that already support it gives
   an opportunity to rapidly deploy a huge number of IPv6 nodes and
   networks (in case the node behind the NAT is an IPv6 router) without
   the need of using or designing new transition mechanisms.

   The scenario presented has been tested with several NAT boxes that
   have successfully established IPv6 tunnels with tunnel servers from
   three well known Tunnel Broker implementations (BT, Freenet6 and
   TILAB) as well as with other routers from several manufacturers.


2. Rationale for this behavior

   As described in RFC 2663 [5]:

   "Address translations performed by NAT are session based and would
   include translation of incoming as well as outgoing packets belonging
   to that session ... a session is defined as the set of traffic that
   is managed as a unit for translation. TCP/UDP sessions are uniquely
   identified by the tuple of (source IP address, source TCP/UDP port,
   target IP address, target TCP/UDP port). ICMP query sessions are
   identified by the tuple of (source IP address, ICMP query ID, target
   IP address). All other sessions are characterized by the tuple of
   (source IP address, target IP address, IP protocol)."

   Basically, what the router does in this case is a NAT for protocol
   identifier 41 (the one used for IPv6 over IPv4 tunnels). The router
   considers each tuple of the form [source IP address, target IP
   address, IP protocol (41)] a different session.


3. Behavior of different NAT types

   Some NAT boxes don't support creating entries for protocol 41, for
   example, they may be limited to TCP, UDP and ICMP.


draft-palet-v6ops-proto41-nat-02.txt  Expires - April 2004    [Page 6]


Internet Draft   Forwarding Protocol 41 in NAT Boxes     October 2003


   From now on, this NAT boxes will not be considered in this document,
   until section 5.

   In the case the NAT box can create a NAT entry for the protocol 41,
   we can distinguish different behaviors depending on the NAT type.


3.1 Basic NAT

   In Basic NATs the sessions are unidirectional. This means that, as
   IPv6 tunnels are treated as any other NAT dynamic session, the tunnel
   entries are only added to the table whenever an IPv6 packet is sent
   from inside, but not with packets coming from the external tunnel
   endpoint. Usually, an inactivity timer is started when the entry is
   created, so the entry (and consequently the tunnel) is deleted if no
   packets are sent for that time. The tunnel will work again if any new
   packet is sent from inside the private network.


3.2 NAPT

   In this case, the sessions are also unidirectional. A single shared
   external address can be configured to translate different transport
   identifiers (e.g., TCP and UDP port numbers, other protocol
   identifiers). At this way, different internal ports are used to
   receive and forward different traffic flows/sessions (depending on
   the different transport identifiers). This can also be combined with
   Basic NATs.

   The behavior is the same as in the case of Basic NATs.


3.3 Bidirectional (or two-way) NAT

   With a Bidirectional NAT, sessions can be initiated from hosts in the
   public network as well as the private network. Private network
   addresses are bound to globally unique addresses, statically or
   dynamically as connections are established in either direction.

   In this case, the IPv6 tunnel will be working even when no internal
   traffic is generated to the tunnel endpoint.


3.4 "Configurable" NAT

   If the external address or pool of addresses, or different transport
   identifiers, can be configured in a static way (by means of a
   configuration file, http interface, CLI, etc.), then the inactivity
   timer is probably not needed.


draft-palet-v6ops-proto41-nat-02.txt  Expires - April 2004    [Page 7]


Internet Draft   Forwarding Protocol 41 in NAT Boxes     October 2003


   For example, in the case that one of the external addresses can be
   configured to forward all the external traffic to a given internal
   address then, the tunnel will work in a complete bidirectional way,
   even when no internal traffic is generated, i.e. the NAT behaves as a
   bidirectional NAT.

   This will be also possible if the NAT can be configured to forward
   all the protocol-41 packets to a given internal address.


4. Applicability

   In the case of Basic NAT and NAPT, IPv6 tunnels can only be initiated
   by inside-to-outside sessions. So in this case, outside-to-inside
   sessions only work whenever a previous inside-to-outside session has
   created the proto-41 entry in the NAT table and the inactivity
   timeout has not been reached.

   This fact is only a problem when IPv6 servers or services inside the
   private network are needed to be accessible from outside. If the
   traffic is client initiated, the session is created normally as soon
   as the first packet is sent, allowing IPv6 communication.

   The only way to maintain the session permanently is to constantly
   send traffic (for example, with a periodic ping from inside, a router
   solicitation message, or other means). Some tunnel broker
   configuration/communication protocol could be developed to extend
   this support.

   In the case of Bidirectional and Configurable NATs, both provide
   means to support also incoming sessions, even when no outgoing
   sessions had been initiated, but most probably require some type of
   configuration.

   This configuration can be a default one. For example a bidirectional
   NAT that comes factory configured with a private address for both its
   LAN interface and a pre-defined private address for the host where
   all the traffic is forwarded.

   In both cases, the application of this procedure allows the operation
   of private IPv6 networks connected by means of non-IPv6 aware NAT
   boxes to tunnel brokers or manual configured tunnels.

   The most usual scope of application of the behavior described in this
   document seems to be SOHO and home environments, but it is not only
   limited to those scenarios.





draft-palet-v6ops-proto41-nat-02.txt  Expires - April 2004    [Page 8]


Internet Draft   Forwarding Protocol 41 in NAT Boxes     October 2003


5. NAT design considerations

   This document has been written following a survey with users/vendors
   of different NAT boxes, and the conclusion is that most of the
   manufacturers support protocol-41 forwarding (78% in our survey).
   Nevertheless not all support a bidirectional mode (over 22% of the
   surveyed models do not support it).

   NAT boxes should tend to support native IPv6. If this is not
   feasible, 6to4 should be the second option, and as a last resort,
   proto-41 forwarding.

   6to4 and Proto-41 forwarding can coexist in the same NAT box. At this
   way, an IPv6 packet received encapsulated with proto41, will be
   forwarded to the private LAN only if the IPv6 destination doesn't
   belong to the local 6to4 /48 prefix, otherwise decapsulated in the
   NAT box. This allows that mobile users do not create troubles, in the
   visited network (that uses 6to4), in the case they have some
   automatic proto-41 setup.

   New firmware/software versions of the NAT implementations should
   ensure the support of protocol-41 forwarding, as a temporary
   solution, while they aren't supporting native IPv6 or 6to4.

   In addition, considering that the code changes needed to support a
   full bidirectional NAT will be minimum, this option should also be
   considered, at least as a configurable option, in an easy way by the
   user (very simple http interface).


6. Tunnel broker design considerations

   New releases of tunnel brokers should provide means to automatically
   detect, or at least manually allow the user to input, the address of
   the NAT box, if this is present.

   The tunnel broker, according to the existence of the NAT box, must
   properly create the script that will configure the client tunnel
   endpoint.


7. Security Considerations

   Note that, in the case of a tunnel, the restrictions to applications
   due to NAT traversing don't apply, because NAT is made to IPv4
   packets that transport IPv6 ones, not to IPv6 packets.

   Besides, the protection derived from the unidirectional nature of NAT
   disappears for IPv6, so some security mechanism (network or personal


draft-palet-v6ops-proto41-nat-02.txt  Expires - April 2004    [Page 9]


Internet Draft   Forwarding Protocol 41 in NAT Boxes     October 2003


   firewalls) could be necessary to protect IPv6 systems in the private
   network.

   A possible security problem is the one related to the DoS Attack than
   can be created if a host in the local network, behind the NAT sends
   IPv6 packets (using protocol 41) to the tunnel endpoint, simulating
   to be the original "owner" of the tunnel. The behavior of the NAT box
   will define the success or failure of this attack. In any case, it
   seems not reasonable that this happens in small networks (SOHO and
   home environments), where the attacker can be easily identified.


8. References

   1  S. Bradner, "The Internet Standards Process -- Revision 3", BCP 9,
      RFC 2026, October 1996.

   2  J. Palet, C. Olvera, D. Fernandez, "IPv6 Tunnels through Routers
      with NAT", Euro6IX Project,
      http://www.euro6ix.org/documentation/euro6ix_co_upm-
      consulintel_wp4_ipv6_tunnels_nat_v1_6.pdf, April 2003.

   3  B. Carpenter, K. Moore, ”Connection of IPv6 Domains via IPv4
      Clouds”, RFC 3056, February 2001.

   4  S. Bradner, "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997.

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


Acknowledgments

   The authors would also like to acknowledge the inputs from Tim Chown,
   Miguel Angel Diaz, Alain Durand, Jun-ichiro "itojun" Hagino, Keith
   Moore, Rute C. Sofia and the European Commission support in the co-
   funding of the Euro6IX project, where this work is being developed.


Authors' Addresses

   Jordi Palet Martinez
   Consulintel
   San Jose Artesano, 1
   28108 - Alcobendas (Madrid - Spain)
   Phone: +34 91 151 81 99
   Fax:   +34 91 151 81 98



draft-palet-v6ops-proto41-nat-02.txt  Expires - April 2004   [Page 10]


Internet Draft   Forwarding Protocol 41 in NAT Boxes     October 2003


   Email: jordi.palet@consulintel.es

   Cesar Olvera Morales
   Consulintel
   San Jose Artesano, 1
   28108 - Alcobendas (Madrid - Spain)
   Phone: +34 91 151 81 99
   Fax:   +34 91 151 81 98
   Email: cesar.olvera@consulintel.es

   David Fernandez
   Technical University of Madrid (UPM)
   Ciudad Universitaria s/n
   28040 – Madrid (Spain)
   Phone: +34 91 549 57 00
   Fax:   +34 91 336 73 33
   Email: david@dit.upm.es


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication 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 implementors or users of this specification can
   be obtained from the IETF Secretariat.

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


Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published


draft-palet-v6ops-proto41-nat-02.txt  Expires - April 2004   [Page 11]


Internet Draft   Forwarding Protocol 41 in NAT Boxes     October 2003


   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.


Acknowledgement

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

























draft-palet-v6ops-proto41-nat-02.txt  Expires - April 2004   [Page 12]