Submitted to NAT Working Group C. Zaccone Y. T'Joens, B. Sales INTERNET DRAFT Alcatel October 15, 1999 Expires April 15, 2000 Mechanisms for end-2end 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 some mechanisms to enable a privately addressed network [PRIV-ADDR-ALLOC] to transport, in the native (non-tunneled) way, IP datagrams issued of communications between Internet hosts and publically addressed private hosts. The methods described in this document are applicable to an address reuse technology working at network layer granularity such as address reuse (Address Translation and not Address and Port Translation). Zaccone, et al. Expires April 15, 2000 [Page 1] Internet Draft draft-zaccone-nat-transport-01.txt October 15, 1999 Table of Contents 1. Introduction 2. Terminology 3. OSPF Minimized Router Deamon 4. Using a multicast protocol 5. Using RSVP 6. Conclusion 7. Security Considerations 8. Acknowledgements 9. References 1. Introduction In an environment where an address reuse technology is used, hosts access the Internet by being allocated, for a certain period of time, a public IP address. This public IP address may be allocated either to a single host (IP address reuse granularity) or to several host at the same time (port reuse granularity). To avoid problems related to modifications by a NAT router, alternatives enabling host to create themselves Internet datagrams are investigated. These schemes have as advantage to restore the end-2-end paradigm in Internet connectivity. Currently, the transport of datagrams pertaining to Internet sessions relies on the use of a tunneling technology. However, tunneling technology is not without any inconveniences as it introduces a single point of failure (the edge router). As described in [TRANSP- FRAM] it is possible (for IP address reuse granulatity) to use native IP operation to transport datagrams in raw format within the private domain. In this document, we will describe and discus several possible mechanisms enabling this later transport scheme. 2. Terminology In the context of this document, the authors assume readers are familiar with the terminology as described in [NAT-TERM] and [TRANSP-FRAM]. 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 Zaccone, et al. Expires April 15, 2000 [Page 2] Internet Draft draft-zaccone-nat-transport-01.txt October 15, 1999 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. OSPF Minimized router deamon (OMRD) Most of the time, the Open Short Path First [OSPF] algorithm is the one running in autonomous domain. In OSPF, a router in the domain constantly informs its neighbour router(s) of its current 'UP' ("OK! I work") status by means of keep alive message called 'Hello message'. Another feature of the protocol is that it allows for autoconfiguration of peer routers in the domain (a router could dynamically, but with authentication, become part of the routing domain and advertise to its neighbour the status of its links). This autoconfiguration capability can be deployed to indicate the position of the host with the global address. In the OMRD mechanism, each host is a kind of 'sleeping router'. The term 'sleeping router' denotes that as soon as the host wishes to have outbound access to the internet, it will participate to the domain's routing. The objective of that participation is to realize the update of the internal routing in order that datagrams having the global IP address of that host as destination address are routed to a router which has direct connectivity with the host. The special case here being that this router is the host itself. Using the previously mentioned dynamicity of OSPF, it is Zaccone, et al. Expires April 15, 2000 [Page 3] Internet Draft draft-zaccone-nat-transport-01.txt October 15, 1999 possible to advertise in the network the host as a new router. The minimized aspect of the router is due to the fact that only a restricted number of OSPF routing functionality are present. Indeed, it do not have to botter about link advertisement issued from other routers. Therefore, it do not have to manage the OSPF links database and associated route calculation. Finally, it does not participate in the 'designated router' election on the LAN segment. In short, this router has only to advertise itself to the neighbour, advertise reachability to a single IP address and flush this information as soon as it is obsolete. The advantage of this mechanism is that the core routers do not need to be modified. As described before, the OSPF flooding procedure started by the host routing daemon has as objective to inform the entire network of the reachability to the (newly assigned) IP addres. However, the propagation of the information and the recomputing of the OSPF algorithm takes time and could let a host which is configured for Internet connectivity to be considered by a router as unreachable just because this one is not synchronized yet. This converging time puts temporary the network in an incomplete state where the way to a destination is not known at the moment. Note that the synchronization time of the network is function of its size, which therefore may impact the deployement of such mechanism. 4. Using a multicast protocol. In a multicast domain, when a host subscribes to a certain multicast group, a multicast tree for that multicast group is first created (for the first subscriber) and then extented (for new subscribers). The multicast tree describes the path the datagrams have to follow from the sender of the multicast traffic towards the receiver. Zaccone, et al. Expires April 15, 2000 [Page 4] Internet Draft draft-zaccone-nat-transport-01.txt October 15, 1999 +---------- | .---. | | | Sender | ----- | / \ | -------** | | * DESTINATION IS A | + * MULTICAST IP ADDRESS Multicast | +--+ \/ ------| | | domain | +--+ | /\ | +--+ +--+ | | | | | | +--+ +--+ | / \ | +--+ .---. | | | | | Receiver | +--+ / \ | | \ ------- | .---. \ |Receiver| | \ | ----- .---. | / \ | |Reiceiver | ------- ----- | / \ | ------- +---------- Multicast tree example In multicast capable domains, the configuration of the tree is subject to the specifics of the multicast protocol. When that multicast protocol would be able to setup trees for a unicast IP addres, it could be used to set up a reverse path to the host with the global IP address. The setup of a reverse path could be seen as the creation of a native multicast tree by the first subscriber. The mechanism to create reverse paths will be the following. Assuming that the host has determined that it needs Internet connectivity, and that it gets the configuration information (the IP stack configuration parameter), it will send a join message to the local multicast capable router. The router runs a multicast protocol (e.g., PIM) and so allows to set up a reverse path to other multicast capable routers, including the border routers. When the host determines to release its public IP address, a leave Zaccone, et al. Expires April 15, 2000 [Page 5] Internet Draft draft-zaccone-nat-transport-01.txt October 15, 1999 message for the corresponding IP address will be send in order to remove the unicast tree and therefore the reverse path which transports the traffic (to that public IP address) in the direction of that host. +---------- | .---. | | | Sender Internet ------| ----- | / \ | -------** +---------- | * DESTINATION IS AN +---------- + * ADDRESS FROM THE POOL | +--+ \/ | Border | | | router +--+ | / | +--+ Private ------| | | | +--+ domain | | | .---. |Host X | | | ----- | / \ | ------- +---------- Unicast tree example The advantage of that mechanism is that it inherits the tree setup and maintenance of multicast protocols. However, it requires that both the host and the network are multicast capable and that the multicast protocol supports the use of non class D IP addresses. 5. Using RSVP Another way to allow the set up of a reverse path is the use of (an extended) RSVP. That is to say, RSVP will be used to update only routers on the path (generally the shortest one) between a host which gets a public IP address and router(s) connected to the ISP which owns that public IP address. In order to create the reverse path, every time a host is configured with a public IP address, the RSVP protocol will be used between the host and edge routers which are connected to the ISP that supplied the public IP address. For those communications, Zaccone, et al. Expires April 15, 2000 [Page 6] Internet Draft draft-zaccone-nat-transport-01.txt October 15, 1999 hosts will use the private IP addresses they are assigned. To be able to contact edge routers, hosts need to obtain their IP addresses. To that aim, hosts may either obtain (e.g. at IP stack configuration time) a list of edge routes unicast IP addresses or either a list of ISP multicast IP addresse (if we consider that the network is multicast capable, one may associate a multicast group address with each different ISP. The edge routers subscribe to the ISP group address to which they are connected, so that they may be also reachable via the ISP multicast group address they have a subscription to) The list of edge routers unicast IP addresses will be used to contact those edge routers one by one whereas the list of ISP multicast IP addresses will be used to contact all those edge routers by a single message addressed to the group address associated with the ISP from which the allocated IP address is issued. In order to setup reverse path(s), a host will send a RSVP PATH message with a to be defined new object. That new object will contain the public IP address the host has been assigned. As the network is already able to route the edge routers unicast IP addresses (or the ISP multicast group address), the RSVP message will reach those routers using the current paths between them and the host. Each time the RSVP message will cross a router (hop by hop), it will be interpreted by the router and the required routing table entry (IP address -> Forwarding Interface) will be added to the table. This routing information will depend on the direction on wich the RSVP message is interpreted. In the direction of the edge routers, the routing information to add is to forward datagrams with the IP address contained in the object towards the interface where the RSVP PATH message arrived. Whereas in the direction of the host, the routing information to add is to forward datagrams with the IP address contained in the object towards the interface where the RSVP RESERVE message has to be forwarded to. The choice of one or the other is open. When RSVP is used for QoS, actions (resources reservation) related to RSVP messages are applied according to the second choice with the RESERVE message. This choice is inherent to QoS (for outgoing traffic) resource reservation. Here, updating the routing table does not have the same impact as reserving resources without using them. The next figure shows an example of the mechanism. As soon as the host has been configured for Internet connectivity (let us say with IP 171.69.89.1 from ISP1 and an edge router unicast list), it Zaccone, et al. Expires April 15, 2000 [Page 7] Internet Draft draft-zaccone-nat-transport-01.txt October 15, 1999 will send a PATH message towards router R3 which is connected to the ISP1. Let us consider the case where RSVP messages are interpreted when going towards router R3. When the PATH message arrives at R1, it analyzes the associated object, discovers the public IP address and creates the entry (171.69.89.1 -> Interface I.1) in its routing table. The PATH message will flow hop by hop until it reachs router R3, with the same use of the object. When the entire path is realized, a reverse path is established. .---. Host X | | R1 | R2 | ----- +--+ I.2| +--+ | R3 : / \ | |+---/ | |+---/ Border router to ISP1 ------- +--+ +--+ +--+ (171.69/16) +-------+ +-------+ +--------+| |+--ISP1 I.1 I.3 +--+ ...............................> | RSVP 'setup reverse path' Message ---/ Use of RSVP to establish the reverse path The RSVP protocol uses 'soft states'. So, in order to maintain the path for the time of the Internet session, the host will continue, at regular time interval, to send RSVP 'path keep alive' messages. As soon as the Internet connectivity is no longer required (the public IP address is released) the host will send and RSVP 'path tear down' in order to remove the reverse path. NB: In the case where the private network has multiple connections to ISP1, the host could setup a reverse path for each of the routers connected to ISP1. Those multiple reverse paths may be useful when more robustness is required. Indeed, as there is redundancy in the way to reach the host (from the ISP network), if the edge router on the current shortest path (from the ISP towards the host) fails, the ISP is still able to forward traffic to the host using an alternative path. The principal advantage of this mechanism compared to OMRD is that only a minimum set of routers have to be informed about the location of the host, enabling fast establishment of the reverse path. Moreover, the mechanism inherits from RSVP the maintenance of the path. The drawbacks of this mechanism is that the network must be RSVP enabled and that both RSVP client and RSVP capable routers must be Zaccone, et al. Expires April 15, 2000 [Page 8] Internet Draft draft-zaccone-nat-transport-01.txt October 15, 1999 able to manage the new Object. 6. Conclusions Delivering Internet traffic to host on a private network may be realized like any other traffic as soon as routers have the required routing information available. Some mechanisms described here may be deployed independently of other technologies. Whereas some take as consideration the deployment of other technologies, such as multicast and RSVP, to argue for scalability and fast deployment by the inheritance of their characteristics. By using a native transport scheme, an address reuse technology is not required anymore to split the route, between an Internet host and a private host, in two and therefore braking the end-to-end principle. 7. Security Considerations Security considerations will be added in later versions of this draft. 8. Acknowledgements The authors would like to thank Peter de Schrijver, Paloma de la vallee for discussions related to this document. 9. References [PRIV-ADDR-ALLOC] Rekhter Y., Moskowitz B., Karrenberg D., G. de Groot, and Lear E., "Address Allocation for Private Internets", RFC 1918. [TRANSP-FRAM] C. Zaccone, Y. T'Joens, B. Sales, "Framework for end-2-end native transport", Internet Draft , September 1999. [NAT-TERM] P. Srisuresh, M.Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations, Internet Draft , April 1999. Zaccone, et al. Expires April 15, 2000 [Page 9] Internet Draft draft-zaccone-nat-transport-01.txt October 15, 1999 [OSPF] J. Moy, "OSPF version 2", Internet RFC 2328, April 1998. [PIM] S. Deering, D. Estrin, D. Farinacci, M. Handley, A. Helmy, Van Jacobson, C.. Liu, P. Sharma, D. Thaler and L. Wei, " Protocol Independent Multicast-Sparse Mode (PIM-SM): Motivation and Architecture", Internet Draft , August 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 April 15, 2000 [Page 10]