Internet Engineering Task Force Internet Draft Jordi Palet Document: draft-palet-v6ops-proto41-nat-01.txt Cesar Olvera Consulintel Category: David Fernandez UPM Expires: January 2004 July 2003 Forwarding Protocol 41 in NAT Boxes draft-palet-v6ops-proto41-nat-01.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-01.txt Expires - January 2004 [Page 1]
Internet Draft Forwarding Protocol 41 in NAT Boxes July 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 this is not a common way of use 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. 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. This document describes this behavior and provides hints that should be applied in the NAT boxes and tunnel brokers to facilitate it. draft-palet-v6ops-proto41-nat-01.txt Expires - January 2004 [Page 2]
Internet Draft Forwarding Protocol 41 in NAT Boxes July 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 [2]. draft-palet-v6ops-proto41-nat-01.txt Expires - January 2004 [Page 3]
Internet Draft Forwarding Protocol 41 in NAT Boxes July 2003 Table of Contents 1. Introduction...................................................4 2. Rationale for this behavior....................................6 3. Behavior of different NAT types................................6 3.1 Basic NAT..................................................6 3.2 NAPT.......................................................6 3.3 Bidirectional (or two-way) NAT.............................7 3.4 "Configurable" NAT.........................................7 4. Applicability..................................................7 5. NAT design considerations......................................8 6. Tunnel broker design considerations............................9 7. Security Considerations........................................9 8. References.....................................................9 Acknowledgments..................................................10 Author's Addresses....................íError! Marcador no definido. Intellectual Property Statement..................................11 Full Copyright Statement.........................................11 Acknowledgement..................................................12 1. Introduction 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 [3] 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. draft-palet-v6ops-proto41-nat-01.txt Expires - January 2004 [Page 4]
Internet Draft Forwarding Protocol 41 in NAT Boxes July 2003 This behavior provides a big opportunity to rapidly deploy a huge number of IPv6 nodes and networks (in the case the node behind the NAT is an IPv6 router), without the need of new transition mechanism. So exploring this option is very important to facilitate the IPv6 deployment, as a temporary fallback solution if neither native IPv6 nor 6to4 are available. ____ ( ) ( IPv6 ) (____) | +--------+ +--------+ | Tunnel |________| Tunnel | | Broker | | Server | +--------+ +--------+ \ / | \____/ | ( ) | ( IPv4 ) | (____) | IPv6 Tunnel | | Public IPv4 | | +-----+ | | NAT | | | Box | | +-----+ | | | Private IPv4 | | +--------+ | | Tunnel |------ | Client |------> (possible IPv6 or dual stack network) +--------+ This scenario 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 (6Bone, Consulintel, Euro6IX and UPM networks). This can be used also without a tunnel broker, with a manual configuration at the IPv6 router tunnel-end. The IPv6 router side supports the establishment of this tunnel 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 should be modified in future versions of the tunnel brokers, in order to properly create the script considering the public and private addresses. draft-palet-v6ops-proto41-nat-01.txt Expires - January 2004 [Page 5]
Internet Draft Forwarding Protocol 41 in NAT Boxes July 2003 2. Rationale for this behavior As described in RFC 2663 [4]: "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. 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 draft-palet-v6ops-proto41-nat-01.txt Expires - January 2004 [Page 6]
Internet Draft Forwarding Protocol 41 in NAT Boxes July 2003 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. 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. 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. draft-palet-v6ops-proto41-nat-01.txt Expires - January 2004 [Page 7]
Internet Draft Forwarding Protocol 41 in NAT Boxes July 2003 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. This document doesn't describe the local network(s) connected to the tunnel endpoint located behind the NAT box, when, for example, it becomes and IPv6 router. These can behave as any other IPv6 native network, providing for example the router advertisement, DHCPv6, Home Agent, etc. 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. 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. Nevertheless not all support a bidirectional mode. 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. draft-palet-v6ops-proto41-nat-01.txt Expires - January 2004 [Page 8]
Internet Draft Forwarding Protocol 41 in NAT Boxes July 2003 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 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 S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. draft-palet-v6ops-proto41-nat-01.txt Expires - January 2004 [Page 9]
Internet Draft Forwarding Protocol 41 in NAT Boxes July 2003 3 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. 4 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 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 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 draft-palet-v6ops-proto41-nat-01.txt Expires - January 2004 [Page 10]
Internet Draft Forwarding Protocol 41 in NAT Boxes July 2003 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 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 draft-palet-v6ops-proto41-nat-01.txt Expires - January 2004 [Page 11]
Internet Draft Forwarding Protocol 41 in NAT Boxes July 2003 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-01.txt Expires - January 2004 [Page 12]