Submitted to NAT Working Group C. Zaccone Y. T'Joens, B. Sales INTERNET DRAFT Alcatel March 3, 2000 Expires September 3, 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 IP traffic from different routing realms inside a single network. In other words, this document describes a framework enabling a network operator to enable the parallel use of different IP routing realms within a single operated network. This framework may, for instance, be applied in the context of IPv4 private networks using an address reuse technology to offer internet connectivity or in the context of IPv4 and IPv6 interworking/migration. Till now, operating multiple realms within a single physical network was realised by the use of tunneling technologies. This document will introduce a non-tunnel based scheme for multiple realms interworking. Zaccone, et al. Expires September 3, 2000 [Page 1] Internet Draft draft-zaccone-nat-transp-fram-01.txt March 3, 2000 Table of Contents 1. Introduction 2. Terminology 3. Transport of datagrams 3.1. Tunneled approach 3.2. Non-tunneled approach 4. Examples of applicability 4.1. RSIP 4.2. IPv4, IPv6 interworking/migration 5. "Why did we botter writing this down ?" 6. Security Considerations 7. Acknowledgements 8. References 1. Introduction Nowadays, network operator have more and more the necessity to connect customer's equipment to more than one IP realms. Meaning that those equipments have to be reachable from whatever realm they have to be connected to. In this context, two main configurations are possible . Either the operator provides a direct link to each of the desired realms, either he operates an intermediate network between the equipment and the desired realms. This document focuses on the second configuration and furthermore consider the intermediate network as an IP network. .--. .--. /------ IP Realm 2 | | | | + ---- ---- ---------- / \ / \ / \ ------ ------ / Operator \ + + + +------+ Network +--- IP Realm 3 | | \ ------ IP Realm 1 \ IP Realm 1 / | \--------- IP Realm 2 \ / \----------- IP Realm 3 ---------- Dedicated links IP Network in between Connection schemes to multiple IP realms In the second scheme, to offer connectivity to the other realms, the operator has to use a technology which may enable the tranfer of information (datagrams) between the customer's equipment and the desired realms. Currently, to that purpose, tunneling technology are applied such as to mimic, through the network, direct links towards those external realms. Zaccone, et al. Expires September 3, 2000 [Page 2] Internet Draft draft-zaccone-nat-transp-fram-01.txt March 3, 2000 Different contexts where the second scheme may apply may be: -a private IPv4 host desiring a connection to a foreign IPv4 realm (e.g. the Internet). -an IPv4 host desiring a connection to an IPv6 realm. -an IPv6 host desiring a connection to an IPv4 realm. The objective of this document is to offer an alternative to tunneling technologies. The basic idea behind this alternative is to provide to the operator a mechanism to enable the parallel use of different realm addressings inside its network. 2. Terminology In the context of this document, the authors assume readers are familiar with the terminology as described in [NAT-TERM]. Local realm. The local realm is the realm of the network to which the host physically belongs to. Foreign realm. A foreign realm is an IP realms which is not the local realm. Local IP address. A local address is an IP address out of the local realm. Foreign IP address. A foreign address is an IP address which is not a local IP address. Local datagram. A local datagram is a datagram addressed with local IP addresses. Foreign datagram. A foreign datagram is a datagram addressed with foreign addresses. Reverse path. The reverse path towards a host is the path, within the operator network, that inbound traffic from a certain foreign realm will follow to reach the host. In other words, if a host A desire a connection to Realm2, it is assigned an IP address out of Realm2's addressing space, a reverse path towards host A is a path between a border router which is connected to Realm2 and host A. In the following figure, a reverse path could be: - R3.R2.R1.HostA Zaccone, et al. Expires September 3, 2000 [Page 3] Internet Draft draft-zaccone-nat-transp-fram-01.txt March 3, 2000 - R3.R5.R2.R1.HostA - R3.R5.R4.R1.HostA Operator network: Realm1 .---. Host X | | R1 | R2 | R3: ----- +--+ | +--+ | Border router / \ | |+---/ | |+---/ ------- +--+ +--+ +--+ +-------+ +---+---+ +---+----+| |+-- Realm2 | | +--+ (e.g. ISP2) | | + +R4 +R5 | +--+ +--+ | --+| |+-------+| |+---/ +--+ +--+ +---- +---- Reverse path example 3. Transport of datagrams In order to enable a host to be part of another realm that the one it is physically connected to, a network operator must use a transport scheme which enable local and foreign datagrams to be delivered. To achieve this two differents approaches are possible: - Tunneled approach. - Non-tunneled approach. 3.1 Tunneled approach In this approach, the foreign datagrams are encapsulated within local datagrams which are exchanged between the host and border routers connected to the considered foreign realms. As the peers involved in the tunnel are only the host and the border routers, the technique is therefore transparent for intermediate routers. This is of interest but however experiences some drawbacks. First drawbacks are inherent to the technology. Indeed, this approach requires that both end points (host and border routers) keep tunnel state informations and support tunnel management functionality. This implies that if a border router fails all the required information to enable the connection of the host to the foreign realm this border router offer connectivity are lost, unless some failover mechanism to alternative border routers (or to information recovery) has been defined. Zaccone, et al. Expires September 3, 2000 [Page 4] Internet Draft draft-zaccone-nat-transp-fram-01.txt March 3, 2000 Another drawback of this approach is the reduced capability of load balancing. Indeed, when a tunnel is establised, all the traffic, both outbound and inbound, (of related hosts) of a foreign realm by default go through the same end points even if multiple connections to that foreign realm are available. e.g.: The host A got an foreign IP address from Realm2. Even if the network has more than one connection to Realm2, the foreign traffic originated by the host will always go through router R1 even if router R2 also provides a connection to Realm2. A ------> R1 .---.Foreign | ....* +--+ | | Traffic | . ---+| |+-- Realm2 ----- of Realm2 | .| +--+ / \ ----------|. | ------- TUNNEL . | + *............. | |-----------------+ LAN | Realm1 | R2 | +--+ +--+| |+-- Realm2 +--+ No load balancing of the outbound foreign traffic A further problem with this approaches may occur when multiple connections towards the same foreign realm are available. In this case, inbound foreign traffic may arrive over multiple boundary routers, therefore implying the host to have established a tunnel with each individual boundary router to the specific foreign realm. 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 foreign datagrams between host A and border router BR there is a failure, let say at intermetiate core router CR, this core router will send back an ICMP message towards host A or border router BR. 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 in the case host A is the receiver of the ICMP message Zaccone, et al. Expires September 3, 2000 [Page 5] Internet Draft draft-zaccone-nat-transp-fram-01.txt March 3, 2000 or to the tunnel management module in the router BR for the other direction. - DiffServ marking: When DiffServ [DIFFSERV-ARCH] prioritisation is used in a foreign realm, appropriate prioritisation of encapsulating datagrams may have to be realised. - MTU Datagram fragmentation need to be carrefully managed. Indeed, the border router will have to reassemble the fragment before to forward the involved datagram. 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 In this approach, datagrams are send in raw format, that is to say, the header contains both foreign source and destination addresses. Obviously, the routers of the operated network must be capable of forwarding both locally addressed datagrams (for internal communications) as well as foreignly addressed datagrams (for extern communications). In this approach, the foreign IP addresses that routers of the operated network see could be of two distinct classes: - A foreign IP address which is currently assigned to a host of the operated network (inbound traffic). - A foreign IP address which is assigned to a host outside the operated network (outbound traffic). According to these classes and the direction of the traffic, we can point out the asymmetric characteristic of the forwarding process. Indeed, outbound traffic can be directed to any border router that links with foreign realm (Note that in multihoming situations, where more than one foreign realm is involved, a further restriction may be that the traffic should be forwarded towards these border routers that link with the specific foreign realm to which the host is temporarily bound. This occurs when the other operator of that foreign realm would filter on the source address of the datagrams arriving to its network). The inbound traffic has to be forwarded to the host which is currently assigned the foreign IP address. The handling of the outbound traffic may be solved by introducing foreign realms reachability routing information into the routing protocol on the operated local realm either dynamically using BGP information either by defining default routes. This introduction of routing information will anable outbound traffic to be normally Zaccone, et al. Expires September 3, 2000 [Page 6] Internet Draft draft-zaccone-nat-transp-fram-01.txt March 3, 2000 delivered like any other traffic. Therefore enables the network to forward that traffic to whatever connection to the outside according to the local routing and policy. e.g.: The host A got a foreign IP address from Realm2. When the network has more than on external connection, the foreign traffic originated by the host may go through router R1 or R2 if both advertise reachability to the traffic's destination. A ------> R1 .---.Foreign | +--+ | | Traffic | ---+| |+-- Realm2 ----- of Realm2| | +--+ / \ --------| | ------- | | + | | |------------)--+ LAN | | Realm1 | | R2 | | +--+ | +--+| |+-- Realm3 ----> +--+ 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 some border routers and the host which is currently assigned a foreign IP address. Indeed, the inbound traffic always enter the network via a connection to the related foreign realm, so if there exists at least one reverse path to reach this IP address the traffic may be delivered to the hosts. In cases where multiple routers are connected to the related foreign realm, such a reverse path may exist from every border router, increasing therefore the robustness. e.g.: Host A got a foreing IP address from Realm2. The inbound traffic may enter the network via path X or path Y. And as a reverse path exist from both router R1 and R2, the traffic may be delivered to host A. Zaccone, et al. Expires September 3, 2000 [Page 7] Internet Draft draft-zaccone-nat-transp-fram-01.txt March 3, 2000 A R1 Path X .---. -----* +--+ <------ | | | ---+| |+-----------------------+\ ----- | | +--+ \ / \ | | ------Realm2 ------- <-------| | R2 Path Y ------ + <-------------^-* +--+ <------ / |---------------| | |+-----------------------+/ LAN | +--+ Realm1 | R3 | +--+ |--+| |+-- Realm3 +--+ Reverse paths towards host A In order to enable the operated network to deliver inbound traffic to the correct host, network routers must be able to decide to which interface a datagram has to be forwarded. To be able to make that decision, as soon as a host is configured for the connectivity to a foreign realm, the routers in the operated network should learn the reverse path. To that end, various approaches may be defined. Some are detailed in [TRANSP-MECH]. 4. Examples of applicability. 4.1 RSIP In the context of RSIP [RSIP-FRAM], the local realm is an IPv4 private network whereas foreign realms are all the realms that RSIP interconnect with the private network. Appplied within this context, the transport scheme, introduced in this document, would imply that internal routers of the operate network have to manage both private and global IP addresses. 4.2 IPv4, IPv6 interworking/migration Within this context of [TRANS-MECH] and [ROUT-ASP-V6-TRANS], two different environments are possible: -either the local realm is an IPv4 network and the foreign realm is an IPv6 network. -either the local realm is an IPv6 network and the foreign realm is an IPv4 network. The former environment may describe the situation of an interworking/migration towards IPv6 where the operated network offer Zaccone, et al. Expires September 3, 2000 [Page 8] Internet Draft draft-zaccone-nat-transp-fram-01.txt March 3, 2000 a connection towards the 6BONE. The latter environment may describe the situation where a new operator has decided to directly design its network using IPv6 (to avoid deploying IPv4 only for a couple of years) but which however has the necessity to interconnect its customers to IPv4 networks (e.g. the Internet). In both environment, with the transport scheme introduced in this document, the operated network would be required to both support IPv4 and IPv6 routing. 5. "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. 6. Security Considerations Security considerations will be added in later versions of this draft. 7. Acknowledgements The authors would like to thank Peter de Schrijver, Paloma de la vallee for discussions related to this document. 8. References [NAT-TERM] P. Srisuresh, M.Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations, RFC 2663, August 1999. [TRANS-MECH] R. Gilligan, E. Nordmark, "Transition Mechanims for IPv6 Hosts and Routers", RFC 1933, April 1996. [ROUT-ASP-V6-TRANS] Zaccone, et al. Expires September 3, 2000 [Page 9] Internet Draft draft-zaccone-nat-transp-fram-01.txt March 3, 2000 R. Callon, D. Haskin, " Routing Aspect Of V6 Transition", RFC2185, September 1997. [TRANSP-MECH] C. Zaccone, Y. T'Joens, B. Sales, "Mechanisms for end-2end native transport", Internet Draft , February 2000. [RSIP-FRAM] M. Borella, D. Grabelsky, "Realm Specific IP: A Framework", Internet Draft , December 1999. [DIFFSERV-ARCH] S. Blake, D. Black, M. Carlson, E. Davis, Z. Wang, W. Weiss, "An architecture dor Differentiated Services", RFC 2475, December 1998. 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 September 3, 2000 [Page 10]