Submitted to NAT Working Group C. Zaccone Y. T'Joens, B. Sales INTERNET DRAFT Alcatel October 15, 1999 Expires April 15, 2000 Framework for end-2-end native transport Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract This document describes a framework for the transport of the Internet traffic inside a privately addressed network in the context of a private network using an address reuse technology to offer Internet connectivity by a restricted number of IP addresses. Till now, the focus was on the use of a tunneling technology between host and border router. This document will introduce another method for the transport of the Internet traffic within the private network, which is applicable with an address reuse technology working at network layer granularity address reuse (Address Translation and not Address and Port Translation). Zaccone, et al. Expires April 15, 2000 [Page 1] Internet Draft draft-zaccone-nat-transp-fram-00.txt October 15, 1999 Table of Contents 1. Introduction 2. Terminology 3. Transport of Internet datagrams 3.1. Tunneled approach 3.2. Non-tunneled approach 4. "Why did we botter writing this down ?" 5. Security Considerations 6. Acknowledgements 7. References 1. Introduction IPv4 addresses are 32 bit which enable up to 4 billions IP addresses to be assigned to hosts. However due to past address allocation schemes, we are now in a situation of address depletetion. Therefore restricting the number of hosts which can be connected to the Internet. As a huge number of hosts use their legally registered IP addresses for sole internal use inside their private network, the Internet Assigned Number Authority (IANA) decided to define a private addressing scheme of which the addresses are deemed non-routable throughout the Internet [PRIV-ADDR-ALLOC]. The use of these addressing schemes reduces the address waste but restricts hosts in their communication with the global Internet community. To offer Internet connectivity in privately addressed networks, several techniques based on the mechanism of sharing IP addresses amongst a number of hosts have been designed. The most popular, due to its transparency to the host, is called Network Address Translation (NAT) [NAT-RFC]. However, NAT suffers from a couple of problems. Due to the principle of examining and changing the network and potentially the transport header of Internet datagrams, the technique breaks the end to end principle of Internet connectivity and therefore creates a couple of problems related to applications (e.g. FTP, DNS) and protocols (e.g. IPSec) that rely explicitly on this principle [NAT-PROT-ISSUES]. In order to solve these problems, several documents [NAT-DNS-ALG], [NAT-SEC] respectively for the problems related to DNS and IPSec have been proposed. On the other hand, to restore the end-to-end principle along with address reuse, alternative approaches have been proposed. The main of those is Realm Specific IP [RSIP-FRAM]. This document is related to this approach and gives a focus on different possible ways to the transport of datagrams issued from Zaccone, et al. Expires April 15, 2000 [Page 2] Internet Draft draft-zaccone-nat-transp-fram-00.txt October 15, 1999 Internet sessions. 2. Terminology In the context of this document, the authors assume readers are familiar with the terminology as described in [NAT-TERM]. Reverse path. The reverse path towards a host is the path, within the private network, that inbound Internet traffic will follow to reach the host. In other words, if a host A is assigned a public IP address which belongs to an Internet service provider ISP1, a reverse path towards that host is a path between a border router which is connected to the network of ISP1 and host A. In the following figure, a reverse path could be: -route R3-R2-R1-HostA -route R3-R5-R2-R1-HostA -route R3-R5-R4-R1-HostA .---. Host X | | R1 | R2 | ----- +--+ | +--+ | R3 : / \ | |+---/ | |+---/ Border router to ISP1 ------- +--+ +--+ +--+ (171.69/16) +-------+ +---+---+ +---+----+| |+--ISP1 | | +--+ | | + +R4 +R5 | +--+ +--+ | --+| |+-------+| |+---/ +--+ +--+ +---- +---- Reverse path example 3. Transport of Internet datagrams The alternative approaches to address (and port reuse) all operate according to four generic steps. In step 1, the host determines whether the destination is local (to its private domain) or not. For inbound sessions, the host can also be triggered to require its global communication parameters by an external stimulus (e.g. a DNS Zaccone, et al. Expires April 15, 2000 [Page 3] Internet Draft draft-zaccone-nat-transp-fram-00.txt October 15, 1999 query for the host). In step 2, the host obtains a public IP address (and range). During step 3, a transport path inside the private realm is established. This step allows for either tunneled or non-tunneled appoaches. Those appoaches will be discussed later on this document. The fourth and last step is the determination of when the Internet connectivity is no longer required and therefore determines the moment of the release of the IP parameters for reuse. Note that these steps can be interchanged, or can occur together; they are just ordered here for educational purposes. The third step is the focus of this document. Here, two different approaches exist: - Tunneled approach. - Non-tunneled approach. 3.1 Tunneled approach In the tunneled approach, the raw IP datagram containing global routable source and destination address are encapsulated within an IP datagram indicating the private source address of the host, and the private destination address of the border router. Tunneling of datagrams requires tunnel management functionality at both endpoints (host and border router), while it remains transparent for intermediate routers. Tunneling however experiences some drawbacks. The first drawback is inherent to the technology. Indeed, in a tunneled approach, tunnel state information needs to be available at both endpoints. If the border router fails all the required information to keep the Internet sessions up are lost, unless some failover mechanism to alternative border routers has been defined. A second drawback of this approach is the reduced capability of load balancing. Indeed, when a tunnel is establised, all the Internet traffic, both outbound and inbound traffic by default go through the same end points even if multiple Internet connections are available. e.g.: The host A got an IP address from ISP 1 network. Even if the network has more than one Internet connection, the Internet traffic originated by the host will always go through router R1 even if router R2 was able to forward the traffic to the Internet. Zaccone, et al. Expires April 15, 2000 [Page 4] Internet Draft draft-zaccone-nat-transp-fram-00.txt October 15, 1999 A ------> R1 .---.Outbound | ....* +--+ | | Internet| . ---+| |+-- ISP 1 ----- Traffic| . | +--+ / \ -------| . | ------- TUNNEL . | + *........... | |---------------+ LAN | | R2 | +--+ +--+| |+-- ISP 2 +--+ No load balancing of the outbound traffic. A further problem with tunneled approaches may occur when the private domain is multi attached to the same ISP. In this case, inbound traffic may arrive over multiple boundary routers, so that the host needs to have established a tunnel with each individual boundary router to the specific ISP. Other potential problems with this approach concern: - ICMP: Tunneling encapsulation puts extra overhead into the traffic. The inclusion of the overhead could have some consequences as those extra bytes could lead to a lack of usefull information concerning the embedded datagram. e.g.: If during the transfer of tunneled datagrams between host A (private IP: 10.0.0.2) and border router BR (private IP: 10.0.0.1) there is a failure, let say at intermetiate core router CR, this core router will send back an ICMP message towards host A. This ICMP message will contain the full header of the datagram and the first 8 bytes of its data. The copied header will be the outer header and the first 8 bytes will be the first 8 bytes of the header of the encapsulated datagram. During the process, information is lost related to the embedded original datagram, which might be needed to give feedback to the correct application. - host: The host is aware of the use of the tunnel technology. Regardless of the drawbacks, the tunneled technology introduces a restricted set of updates in the network as it only involves edge routers and hosts. Therefore, enabling a fast deployment without any further assumptions. 3.2 Non-tunneled approach Zaccone, et al. Expires April 15, 2000 [Page 5] Internet Draft draft-zaccone-nat-transp-fram-00.txt October 15, 1999 In the non-tunneled approach, IP datagrams are send in raw format, that is to say, the header contains both global source and destination addresses. Obviously, the routers internal to the private domain must be capable of forwarding both privately addressed datagrams (for internal communications) as well as publically addressed datagrams (for global communication). In this approach, the public IP addresses that private routers see could be of two distinct classes: - A public IP address which is currently assigned to a private host (inbound traffic). - A public IP address which is assigned to a host outside the private network (outbound traffic). According to these classes and the direction of the traffic (outbound or inbound traffic [NAT-TERM]), we can point out the asymmetric characteristic of the forwarding process. Indeed, outbound traffic can be directed to any border router that links with the Internet (Note that in multihoming situations, where more than one ISP is involved, a further restriction may be that the traffic should be forwarded towards these border routers that link with the specific ISP domain to which the host is temporarily bound. This occurs when the other ISPs would filter on the source address of the datagrams arriving from the private network). The inbound traffic has to be forwarded to the host which is currently assigned the public IP address. The handling of the outbound traffic may be solved by introducing Internet reachability routing information into the internal routing protocol either dynamically using BGP information either by defining default routes. This introduction of routing information will anable outbound traffic to be normally delivered like any other traffic. Therefore enables the network to forward that traffic to whatever Internet connection according to the local routing and policy. e.g.: The host A got an IP address from ISP 1 network. When the network has more than one Internet connection, the Internet traffic originated by the host may go through router R1 or R2 to the Internet. Zaccone, et al. Expires April 15, 2000 [Page 6] Internet Draft draft-zaccone-nat-transp-fram-00.txt October 15, 1999 A ------> R1 .---.Outbound | +--+ | | Internet | ---+| |+-- ISP 1 ----- Traffic | | +--+ / \ --------| | ------- | | + | | |------------)--+ LAN | | | | R2 | | +--+ | +--+| |+-- ISP 2 ----> +--+ Possible load balancing of the outbound traffic. In this approach, the correct delivery of the inbound traffic relies on the existence of a reverse path between the border routers and the host which is currently assigned the public IP address. Indeed, the inbound traffic's datagrams always enter the network via a connection to the ISP which owns the IP address specified in the destination field, so if there exists at least one reverse path to reach those IP addresses the traffic may be delivered to the hosts. In these cases where multiple routers connect to the same ISP, such a reverse path may exist from every border router, increasing therefore the robustness. e.g.: Host A got an IP address from ISP 1. The inbound traffic may enter the network via path X or path Y. And as a reverse path exist from both router R1 and router R2, the traffic may be delivered to host A. Zaccone, et al. Expires April 15, 2000 [Page 7] Internet Draft draft-zaccone-nat-transp-fram-00.txt October 15, 1999 A R1 Path X .---. -----* +--+ <------ | | | ---+| |+-----------------------+\ ----- | | +--+ \ / \ | | ------ISP 1 ------- <-------| | R2 Path Y ------ + + <-------------^-* +--+ <------ / | |---------------| | |+-----------------------+/ Internet LAN | +--+ | R3 | +--+ |--+| |+-- ISP 2 +---Internet +--+ Reverse paths towards host A In order to enable the private network to deliver inbound traffic to the correct host, network routers must be able to decide to which interface an Internet datagram has to be forwarded. To be able to make that decision, as soon as a host is configured for Internet connectivity, the routers in the private network should learn the reverse path. To that end, various approaches may be defined. Some are detailed in [TRANSP-MECH]. 4. "Why did we botter writing this down ?" In the process of upgrading stub networks to provide RSIP functional at the address reuse level, we have explored the possibility to make the parallel use of two routing realms inherent to the routing and forwarding framework, rather than building upon the usage of overlay networks as we deem such approach to be theoretically superior to tunneled approaches This document and its companions document [TRANS-MECH] are the result of this theoretical exercise. 5. Security Considerations Security considerations will be added in later versions of this draft. 6. Acknowledgements The authors would like to thank Peter de Schrijver, Paloma de la vallee for discussions related to this document. 7. References Zaccone, et al. Expires April 15, 2000 [Page 8] Internet Draft draft-zaccone-nat-transp-fram-00.txt October 15, 1999 [PRIV-ADDR-ALLOC] Rekhter Y., Moskowitz B., Karrenberg D., G. de Groot, and Lear E., "Address Allocation for Private Internets", RFC 1918. [NAT-RFC]K. Egevang and P. Francis, "The IP Network Address Transla- tor (NAT)," Internet RFC 1631, May 1994. [NAT-TERM] P. Srisuresh, M.Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations, Internet Draft , April 1999. [NAT-PROT-ISSUES] M. Holdrege, "IP Network Address Translator (NAT) Protocol Issues, Internet Draft , November 1999. [NAT-DNS-ALG] P. Srisuresh, G. Tsirtsis, P. Akkiraju, A. Heffernan, "DNS extensions to Network Address Translators (DNS_ALG)", Inter- net Draft , April 1999. [NAT-SEC]P. Srisuresh, "Security Model for Network Address Translator (NAT) Domains", Internet Draft , February 1999. [RSIP-FRAM] M. Borella, D. Grabelsky, "Realm Specific IP: A Framework", Internet Draft , Mai 1999. [TRANSP-MECH] C. Zaccone, Y. T'Joens, B. Sales, "Mechanisms for end-2end native transport", Internet Draft , September 1999, Zaccone, et al. Expires April 15, 2000 [Page 9] Internet Draft draft-zaccone-nat-transp-fram-00.txt October 15, 1999 Authors Addresses Carmelo Zaccone Alcatel Corporate Research Center Fr. Wellesplein 1, 2018 Antwerpen, Belgium. Phone : 32-3-240-8344 Fax : 32-3-240-9932 E-mail: Carmelo.Zaccone@Alcatel.be Yves T'Joens Alcatel Corporate Research Center Fr. Wellesplein 1, 2018 Antwerpen, Belgium. Phone : 32-3-240-7890 Fax : 32-3-240-9932 E-mail: Yves.Tjoens@Alcatel.be Bernard Sales Alcatel Corporate Research Center Fr. Wellesplein 1, 2018 Antwerpen, Belgium. Phone : 32-3-240-9574 Fax : 32-3-240-9932 E-mail: Bernard.Sales@Alcatel.be Zaccone, et al. Expires April 15, 2000 [Page 10]