One document matched: draft-zheng-host-initiated-nat-01.txt

Differences from draft-zheng-host-initiated-nat-00.txt

 



INTERNET-DRAFT                                        Linfeng John Zheng
Intended Status: Proposed Standard                                      
Expires: October 1, 2011                                  March 30, 2011


                          Host-initiated NAT  
                 draft-zheng-host-initiated-nat-01.txt



Abstract

      This document presents a new method to implement the NAT function,
   which requires the cooperating of the hosts and the NAT gateway. The
   proposed NAT mechanism is called Host-initiated NAT, or HI-NAT for
   short. Traditional NAT function is performed in the gateway, while
   the hosts are not aware of the address translation at all. One
   drawback of such mechanism is that all translation works need to be
   done in one device, the NAT gateway, which may bring performance
   bottleneck. The presented HI-NAT mechanism shows another possible
   solution to improve network performance by the cooperating of the
   hosts and the Gateway. In more details, the hosts will initiate the
   NAT procedure with its local IP address. After getting the translated
   IP address, the hosts will use it in every packet sending out to ease
   the translating workload of the NAT gateway.  


Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   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/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

 


Linfeng John Zheng       Expires October 1,2011                 [Page 1]

INTERNET DRAFT             Host-initiated NAT             March 30, 2011


Copyright and License Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.



Table of Contents

   1  Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
      1.1  Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Problem Statement and Purpose of HI-NAT . . . . . . . . . . . . 3
   3  Specification  . . . . . . . . . . . . . . . . . . . . . . . . . 5
   4  Security Considerations  . . . . . . . . . . . . . . . . . . . . 6
   5  References . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
      5.1  Normative References  . . . . . . . . . . . . . . . . . . . 6
      5.2  Informative References  . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7




















 


Linfeng John Zheng       Expires October 1,2011                 [Page 2]

INTERNET DRAFT             Host-initiated NAT             March 30, 2011


1  Introduction

   This document presents a new method to implement the NAT function,
   which requires the cooperating of the hosts and the NAT gateway. The
   proposed NAT mechanism is called host-initiated NAT, or HI-NAT for
   short. Traditional NAT function is performed in the gateway, while
   the hosts are not aware of the address translation at all. One
   drawback of such mechanism is that all translation works need to be
   done in one device, the NAT gateway, which may bring performance
   bottleneck. The presented HI-NAT mechanism shows another possible
   solution to improving network performance by the cooperating of the
   hosts and the gateway. In more details, the hosts will initiate the
   NAT procedure with its local IP address. After getting the translated
   IP address, the hosts will use it in every packet sending out to ease
   the translating workload of the NAT gateway.   


1.1  Terminology

   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 [RFC2119].


2.  Problem Statement and Purpose of HI-NAT


   Traditional NAT function is implemented in NAT gateway, which is on
   the border of two different networks. For most cases, they could be
   IPv4 network with private IPv4 address space and IPv4 Internet, or
   IPv4 network/Internet and IPv6 network/Internet. When user's first
   data packet arrives the NAT gateway, the NAT gateway examines the
   data packet, and extract its address information to build the binding
   table. When the later packets come, the NAT gateway will make use of
   the binding table established, to translate the packet header, and
   pass the new data packet to the other network.

   The benefit of traditional NAT is that the user does not need to be
   aware of the NAT function at all. In other words, The NAT function is
   totally transparent to user. However, there is one drawback of such
   NAT procedure, which is the performance bottleneck of the big NAT
   gateway. According to one comparison of such carrier grade NAT
   devices, in the worst cases the actual performance downgrade is about
   10 to 15 times lower than that of a normal transport router.

   The newly proposed HI-NAT will improve the NAT gateway's transporting
   performance compared with the traditional NAT by using the host-
   initiated NAT procedure and the cooperating between the hosts and the
 


Linfeng John Zheng       Expires October 1,2011                 [Page 3]

INTERNET DRAFT             Host-initiated NAT             March 30, 2011


   NAT gateway. The basic idea of HI-NAT is that instead of putting all
   translating burden onto the NAT gateway, the host will also take some
   responsibility in the translation procedure. By doing that the NAT
   gateway will only need to do partial translating workload compared
   with traditional NAT mechanism.











































 


Linfeng John Zheng       Expires October 1,2011                 [Page 4]

INTERNET DRAFT             Host-initiated NAT             March 30, 2011


3  Specification

   A HI-NAT network at least consists of five components. Network A,
   Network B, the hosts, the servers, and the HI-NAT gateway. The
   Network A and the Network B could be two IPv4 networks, or one IPv4
   network and one IPv6 network. The HI-NAT gateway is on the border of
   the Network A and the Network B, while the hosts are on the Network A
   and the servers sit on the Network B. The Network A and Network B
   have different addresses spaces, saying the Network A with IPv4
   private addresses and the Network B with public IPv4 addresses, or
   Network A with IPv6 addresses and Network B with IPv4 addresses, or
   any other possible combinations.

   Following is the setup procedure of a HI-NAT communication. We take
   an example of Network A with IPv6 addresses and Network B with IPv4
   addresses.

   Step 1: The host in Network A initiates the communication. Before
   sending out the first data packet with source address X, and
   destination address Y, which could be a synthesized IPv6 address
   using DNS64 function, the host send out a NAT configuration packet
   instead; In the NAT configuration packet, at least the source address
   X and the destination address Y information is included.

   Step 2: The NAT configuration packet is routed to the HI-NAT   
   gateway;

   Step 3: When the HI-NAT gateway received the NAT configuration
   packet, it will allocate one IPv4 x' address from its local address
   pool, and also extract the IPv4 destination address y' from the IPv6
   synthesized address Y. Then, the HI-NAT gateway will build the
   binding table (X, Y, x', y') using above information. 

   Step 4: The HI-NAT gateway sends back the NAT configuration reply
   packet with the translated addresses, x' and y' back to the host who
   initiates the communication.

   Step 5: When the host gets the NAT configuration reply packets, it
   makes use of the address information provided to form packet header
   of its outgoing data packet. Two different types of technologies may
   be used, one is IP-in-IP encapsulation, another is header IPv6
   address mapping.

   Step 6: If the IP-in-IP mechanism is used, the original data will
   first be encapsulated in a IPv4 header with source address x' and
   destination address y'; then the IPv4 packet will be encapsulated
   into IPv6 packet with the source destination address X and
   destination address Y. The packet will be sent to HI-NAT gateway.
 


Linfeng John Zheng       Expires October 1,2011                 [Page 5]

INTERNET DRAFT             Host-initiated NAT             March 30, 2011


   Step 7: When the packet arrive the HI-NAT gateway, instead of looking
   up the binding table, the HI-NAT gateway can simply de encapsulate
   the IPv6 header and extract the IPv4 data packet and forward it
   directly. Binding table searching and matching is not required, but a
   optional action for monitoring and checking purpose.

   Step 8: If the header IPv6 address mapping mechanism is used, the
   original data will be encapsulated in a IPv6 header directly.
   However, instead of using original IPv6 address X, it will use a
   address X' which will include information of the IPv4 address x' with
   some address mapping mechanism. 

   Step 9: When such packet arrive the HI-NAT gateway, instead of
   looking up the binding table, the HI-NAT gateway can simply extract
   the IPv4 source address x' in the IPv6 source address X using the
   address mapping mechanism, and then form the IPv4 data packet and
   forward it. Same with step 7, the binding table searching and
   matching is not required, but a optional action for monitoring and
   checking purpose.

   Step 10: The Host-initiated NAT procedure completes.



4  Security Considerations

   Considering the Internet is a stateless network, it is inevitable
   that some malicious packets may be generated and sent to the central
   network devices, such as NAT gateways, or HI-NAT gateway described in
   this document. How to differentiate normal data packets and malicious
   attacking packets and then stop the attacks is a real challenge. 

   In a distributed system like HI-NAT network presented, how to avoid
   possible network attack is an important issue cannot be neglected.

   One possible solution could be dynamically monitoring abnormal
   traffic, and consequently dropping such flows if detected. However,
   completely solving the security issues that exist in a NATed or HI-
   NATed network remains a open topic and asks for more attentions and
   efforts.

5  References

5.1  Normative References

   [RFC3022]   Srisuresh, P. and K. Egevang, "Traditional IP Network
              Address Translator (Traditional NAT)", RFC3022, January
              2001.
 


Linfeng John Zheng       Expires October 1,2011                 [Page 6]

INTERNET DRAFT             Host-initiated NAT             March 30, 2011


   [I-D.ietf-behave-v6v4-xlate-stateful]   Bagnulo, M., Matthews, P.,
              and I. Beijnum, "Stateful NAT64: Network Address and   
              Protocol Translation from Ipv6 Clients to IPv4 Servers",
              draft-ietf-behave-v6v4-xlate-stateful-12 (work in
              progress), July 2010.

5.2  Informative References

   [RFC5382]   Guha, S., Biswas, K., Ford, B.,Sivakumar, S., and P.
              Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
              RFC5382, October 2008.

   [I-D.ietf-behave-v6v4-xlate]   Li,X.,Bao, C., and F. Baker, "IP/ICMP
              Translation Algorithm", draft-ietf-behave-v6v4-xlate-23
              (work in progress), September 2010.

   [I-D.ietf-behave-dns64]   Bagnulo, M., Sullivan, A., Matthews, P. and
              I. Beijnum, "DNS64: DNS extensions for Network Address
              Translation from Ipv6 Clients to IPv4 Servers", draft-
              ietf-behave-dns64-11 (work in progress), October 2010.


Authors' Addresses


              Linfeng John Zheng
              Bld 30 APT#503, Chunjian Garden, Yuhuatai District,
              Nanjing P.R.China

              EMail: linfeng.john.zheng@gmail.com





















Linfeng John Zheng       Expires October 1,2011                 [Page 7]