Submitted to NAT Working Group C. Zaccone Y. T'Joens, B. Sales INTERNET DRAFT Alcatel June 15, 1999 Expires November 15, 1999 Framework for the transport of the Internet traffic in a privately addressed network. 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 where the private network uses an address reuse technology to offer Internet connectivity using a restricted number of IP addresses. Till now, all alternatives to the Network Address Translation technology use tunneling between hosts and a border router. This document will introduce other mechanisms for the transport of the Internet traffic inside the private network. This document will further introduce an alternative to NAT that deploys the described transport mechanisms instead of doing translation or tunnel management on routers. Zaccone, et al. Expires November 15, 1999 [Page 1] Internet Draft draft-zaccone-nat-transport-00.txt June 15, 1999 Table of Contents 1. Introduction 2. Terminology 3. Address reuse 3.1. Tunneled approach 3.2. Non-tunneled approach 3.2.1. OSPF Minimized Router Deamon 3.2.2. Using a multicast protocol 3.2.3. Using RSVP 4. Non-tunneled address reuse technology example 5. Security Considerations 6. Acknowledgements 1. Introduction IPv4 addresses are 32 bit quantities. However due to past address allocation schemes, a lot of addresses cannot be assigned to hosts. This restricts 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. 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, inside the private network, the 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. 3. Address reuse 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], [INFO-RISURESH]. However, NAT suffers Zaccone, et al. Expires November 15, 1999 [Page 2] Internet Draft draft-zaccone-nat-transport-00.txt June 15, 1999 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], [NATB], [NAT-SEC] respectively for the problems related to DNS, end to end sensitive applications and IPSec have been proposed. On the other hand, to restore the end-to-end principle along with address reuse, some alternative approaches like Negotiate Address Reuse [NAR] and Distributed Network Address Translation [DNAT] have been proposed. The latter two merged today into Realm Specific IP [RSIP-FRAM]. The alternative approaches all operate according to four generic steps to address reuse. Note that these steps may be : - The private host determines when Internet connectivity is required - The private host obtains the IP configuration parameters (IP address or IP address and port range and potential other useful information) to enable public communication - A transport path is established inside the private network - The private host determines end of communication and releases the IP configuration parameters for reuse by another host For the first two steps, several mechanisms can be imagined. In the RSIP proposal, two different techniques are proposed [RSIP-FRAM]. The first mechanism is a simple 'query-response' mechanism where hosts query the RSIP server when the destination IP address to be reached is not on the local subnet. The second approach is that hosts do not perform a local check, but are informed by the RSIP server that their traffic is outbound the private network, and it should obtain local configuration information. This last approach is simple, however it may require some modification to the TCP/IP stack at the host since the TCP half-open connection must be discarded. In section 4, this document describes an alternative (Virtual Internet Connection, VIC), where the resolution process may be realized by the Operating System kernel and therefore be transparent to TCP sessions and the corresponding applications. For the second and fourth step, [RSIP-PROT] describes a new protocol Zaccone, et al. Expires November 15, 1999 [Page 3] Internet Draft draft-zaccone-nat-transport-00.txt June 15, 1999 to negotiate, determine and release the required parameters. However, that negotiation may also be realized via extensions to current host configuration or policy protocols such DHCP, COPS, RADIUS, DIAMETER [RSIP-FRAM] or SOCKS [NAR]. The alternative in section 4 describes the use of DHCP to obtain the necessary configuration information. For the third step, two different approaches exist: - Tunneled approach. - Non-tunneled approach. The first approach is dominating because it is used by the main currently designed alternative, RSIP. The non-tunneled approach is investigated by the VIC alternative. 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 tunneling. 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 set up, all the Internet traffic, both outbound and inbound traffic must always go through the same end points even if multiple Internet connections are available. e.g.: The host A got an IP address out of 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 November 15, 1999 [Page 4] Internet Draft draft-zaccone-nat-transport-00.txt June 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 which each individual boundary router to the specific ISP. Other potential problems with this approach concern: - ICMP: Tunneling encapsulation puts extra overhead into the traffic. This 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 transfert of tunneled datagrams between host A (private IP: 10.0.0.2) tunnels toward a 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 needs to be modified so that it supports tunnel management. Moreover, as described in [RSIP-FRAM], TCP half-open connections must be discarded therefore having an impact on the related applications. 3.2 Non-tunneled approach In the non-tunneled approach, IP datagrams are send in raw format, that is to say, the header contains both global source and Zaccone, et al. Expires November 15, 1999 [Page 5] Internet Draft draft-zaccone-nat-transport-00.txt June 15, 1999 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 is easily solved by enabling border routers to inject Internet reachability information into the network. Indeed, if the border routers advertise Internet reachability to the core routers, the outbound traffic may be normally delivered like every other traffic therefore enabling the network to forward that traffic to whatever Internet connection according to the routing and the local policy. e.g.: The host A got an IP address out of 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 November 15, 1999 [Page 6] Internet Draft draft-zaccone-nat-transport-00.txt June 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 needs to exist from every border router. e.g.: Host A got an IP address out of 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 November 15, 1999 [Page 7] Internet Draft draft-zaccone-nat-transport-00.txt June 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 below. 3.2.1 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 mechanims, each host is a kind of 'sleeping router'. The term 'sleeping router' means that while the host requires only communication in the private domain, it does not play the role of a router. But as soon as the host wishes to have outbound access to the internet, it participates 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 Zaccone, et al. Expires November 15, 1999 [Page 8] Internet Draft draft-zaccone-nat-transport-00.txt June 15, 1999 of OSPF, it becomes easy to advertise in the network the host as a new router. Assuming that the host has determined that it needs Internet connectivity, and that it gets the configuration information (the IP stack configuration parameters and also the configuration parameters (router ID, ...) of the router), the router daemon wakes up and by injecting a 'hello message' on the local segment, routers which are on that segment become aware of its presence. For the time of the use of the global IP address, the router daemon running on the host will advertise to its neighbors, by means of a new link advertisement, reachability to the host global IP address. Finally, assuming that the host has determined when to release its public IP address and router ID, the router daemon running on the host will flush the link advertisement concerning that IP address, stop sending hello messages to the neighboring router and return to the sleeping mode. Example: Let us say that host X with private IP address 10.10.0.2 has requested a global IP address. As soon as host X receive the IP address it is assigned, let us say 171.69.89.1, it wakes up it router daemon which will now inform the network of its presence (hello message) and networks (here a single IP address: 171.69.89.1) it could reach. The information is propagated through the network by the OSPF flooding procedure. When datagrams originating from the Internet with destination IP address 171.69.89.1 enter the private network, the internal routing will be able to route it to the router daemon running on host X and therefore to host X. When host X releases its global IP address (and router ID), the router daemon running on host X flushes the information concerning the network it could reach (here IP address: 171.69.89.1) and returns to its sleeping mode by stopping the emission of hello messages. The advantage of this mechanism is that the core routers do not need to be modified. The disadvantage to such scheme is the following. As described before, the OSPF flooding procedure started by the host routing daemon has as objective to inform the entire network of the reachability the hast has to the (newly assigned) IP addres. However, the propagation of the information and the recomputing of the OSPF algorithm takes time and could cause an issue: a host which is configured for Internet connectivity could be considered by a router Zaccone, et al. Expires November 15, 1999 [Page 9] Internet Draft draft-zaccone-nat-transport-00.txt June 15, 1999 as unreachable just because that router 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, and therefore the above described mechanism may only be applicable to small domains. 3.2.2 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. +---------- | .---. | | | 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 Zaccone, et al. Expires November 15, 1999 [Page 10] Internet Draft draft-zaccone-nat-transport-00.txt June 15, 1999 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 has 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 message for the corresponding IP address will be send in order to remove the unicast tree and therefore the reverse path which transport the traffic (to that public IP address) in the direction of that host. +---------- | .---. | | | Sender Internet ------| ----- | / \ | -------** +---------- | * DESTINATION IS AN +---------- + * ADDRESS OUT OF THE POOL | +--+ \/ | Border | | | router +--+ | / | +--+ Private ------| | | | +--+ domain | | | .---. |Host X | | | ----- | / \ | ------- +---------- Unicast tree example The advantage of that mechanims is that it inherits the tree setup and maintenance of multicast protocols. The drawbacks of this mechanism are that both the host and the Zaccone, et al. Expires November 15, 1999 [Page 11] Internet Draft draft-zaccone-nat-transport-00.txt June 15, 1999 network must be multicast enabled and that the multicast protocol supports the use of non class D IP addresses. 2.3 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 the routers on the path (generally the shortest one) between a host which gets a public IP address and router(s) connected to the ISP from 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 one (or more) router(s) that is connected to the ISP that supplied the public IP address. The communication will be realized using the private IP addresses of both host and router(s). The IP address(es) of the border router(s) is provided to the host together with the global IP address. Considering that the host knows the private IP addresses of the border router(s), the host will send an RSVP 'path setup' 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 private IP addresses, the RSVP 'path setup' message will be able to reach the edge router(s) using the current shortest path between him 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 in the table. This routing information will depend on the direction on wich the RSVP message is interpreated: - For RSVP path messages in the direction of the egress border router, the routing information to add is [public IP address -> Interface where the RSVP message arrived] - If the message is interpreted in the way towards the host (e.g.: in an ACK message), the routing information to add is [public IP address -> Interface where the RSVP message has to be forwarded to] The next figure shows an example of the mechanism. As soon as the host has been configured for Internet connectivity (let us say an IP address out of ISP1), it will send and RSVP 'path setup' message towards the router (R3) which is connected to the ISP (ISP1) to which the global IP address belongs to. Let us consider the case where RSVP messages are interpreted when Zaccone, et al. Expires November 15, 1999 [Page 12] Internet Draft draft-zaccone-nat-transport-00.txt June 15, 1999 going towards the border router. When the RSVP message arrive to R1, R1 analyzes the associated Object, discovers the public IP address and create the entry (171.69.89.1 -> Forwarding Interface I.1) on its routing table. The RSVP message will go hop by hop until it reach the destination router (R3), with the same use of the Object. When the entire path is realized, a reverse path towards the physical location where is used the newly assigned public IP address 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' message. As soon as the Internet connectivity is not required anymore (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 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 and therefore its robustness. The drawbacks of this mechanism is that the network must be RSVP enabled and that both RSVP client and RSVP capable routers must be able to manage the new Object. 4. Non-tunneled address reuse technology example (Virtual Internet Zaccone, et al. Expires November 15, 1999 [Page 13] Internet Draft draft-zaccone-nat-transport-00.txt June 15, 1999 Connection) This section briefly introduces an address reuse technique that is based on the non-tunneled approach described above. Virtual Internet Connection (VIC) is a technique, which enables private hosts to get full Internet connectivity by being globally addressed with an IP address out of a subnet that the private network got from its ISP(s). The mechanism used in VIC is derived from the current dial-in model. In the current dial-in model, hosts using PSTN or ISDN as dial-in network, have an unconfigured IP interface to their Internet Service provider(ISP). This interface will be configured as soon as the host needs Internet connectivity. This host could be a personal computer at home (attached by direct PSTN or ISDN dial in lines) as well as a host that belongs to a private network (e.g., corporate or home LAN). In the latter case, the hosts that have this dial-in connection would have two or more IP interfaces. One of these interfaces is the private LAN/network interface configured with a private IP address (by e.g., DHCP), another interface is the dial-in interface configured with legally registered IP address assigned by the ISP (by e.g., IPCP). The dial in interface is unconfigured when no Internet connectivity is needed but as soon as the host needs to access the global Internet, it will be auto- configured after dialing the ISP phone number and being authenticated. In the dial-in model, hosts having such configuration use their network connection for internal connectivity and the dial- in interface for Internet connectivity. VIC takes as starting point that dial-in model. In the VIC model, hosts also possess such a virtual interface but instead of having a dedicated hardware the interface is attached to one of the current LAN Network Interface Cards (NIC). Two major differences exist between the dial-in model and the VIC model: - The first one is that when the interface is activated, the IP traffic destined to the Internet will not be send to an Internet dedicated link-line as the telephone line used in the dial-in model, but instead the IP datagram will be forwarded on the private LAN/network through the associated NIC. - The second difference, the most important, resides in the proximity the station has with the Internet. In the dial-in model the traffic is directly exchanged between stations to an Internet Zaccone, et al. Expires November 15, 1999 [Page 14] Internet Draft draft-zaccone-nat-transport-00.txt June 15, 1999 router (the ISP Network Access Server (NAS)), whereas in the VIC model the traffic has to go through several private routers before to reach an Internet router. In other words, in the VIC model, when the traffic has to be exchanged with the Internet, internal routing has to route in the direction of a border router for outgoing Internet traffic and in the direction of the station for incoming Internet traffic. In the VIC model, the main steps to offer end to end Internet connectivity are realized as follows: - The determination of the locality or the externality of an IP address is given to the OS kernel. Indeed, all hosts's interfaces are configured so that the TCP/IP kernel knows which destination are reachable via those interface and therefore which interface to use (and potentially configure). - The assigment and release of that configuration information is realized via the use of e.g., DHCP. - To install the necessary state in the private domain routers, one of the previously proposed mechanisms will be used (section 3.2). 5. Security Considerations Security considerations will be added in later versions of this draft. 6. Acknowledgements The authors would like to thank Maria Fernanda Ramalho, Peter de Schrijver, Paloma de la vallee for the fruitful discussions and/or their thorough revision of this document. References [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. [INFO-RISURESH] Zaccone, et al. Expires November 15, 1999 [Page 15] Internet Draft draft-zaccone-nat-transport-00.txt June 15, 1999 P. Srisuresh and K. Egevang, "The IP Network AddressTransla- tor (NAT), Internet Draft , Feb. 1998. [NATB] G. Tsirtsis, A. O'Neill, "NAT Bypass for End 2 End 'sensi- tive' applications", January 1998. [NAT-TERM] P. Srisuresh, M.Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations, Internet Draft , April 1999. [NAT-IMPL] T. Hain, "Architectural Implications of NAT," Internet Draft , April 1999. [NAT-APP-GUIDE] D. Senie, "NAT Friendly Application Design Guidelines", Internet Draft , February 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. [NAR] G. Montenegro, "Negotiated Address Reuse", Internet Draft , April 1999. [RSIP-FRAM] M. Borella, D. Grabelsky, "Realm Specific IP: A Framework", Internet Draft , Mai 1999. [RSIP-PROT] J. Lo, K. Tuniguchi, "Realm Specific IP: Protocol Specifica- tion", Internet Draft , April 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): Motiva- tion 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 November 15, 1999 [Page 17]