Submitted to NAT Working Group C. Zaccone
Y. T'Joens, B. Sales
INTERNET DRAFT Alcatel
<draft-zaccone-nat-transport-00.txt>
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 <draft-rfced-info-risuresh-05.txt>,
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 <draft-
ietf-nat-terminology-02.txt>, April 1999.
[NAT-IMPL]
T. Hain, "Architectural Implications of NAT," Internet Draft
<draft-iab-nat-implications-04.txt>, April 1999.
[NAT-APP-GUIDE]
D. Senie, "NAT Friendly Application Design Guidelines",
Internet Draft <draft-ietf-nat-app-guide-01.txt>, February
1999.
[NAT-PROT-ISSUES]
M. Holdrege, "IP Network Address Translator (NAT) Protocol
Issues, Internet Draft <draft-ietf-nat-protocol-issues-
01.txt>, November 1999.
[NAT-DNS-ALG]
P. Srisuresh, G. Tsirtsis, P. Akkiraju, A. Heffernan, "DNS
extensions to Network Address Translators (DNS_ALG)", Inter-
net Draft <draft-ietf-nat-dns-alg-02.txt>, April 1999.
[NAT-SEC]P. Srisuresh, "Security Model for Network Address Translator
(NAT) Domains", Internet Draft <draft-ietf-nat-security-
01.txt>, February 1999.
[NAR] G. Montenegro, "Negotiated Address Reuse", Internet Draft
<draft-montenegro-aatn-nar-00.txt, May 1998.
[DNAT] M. Borella, D. Grabelsky, "Distribiuted Network Address
Zaccone, et al. Expires November 15, 1999 [Page 16]
Internet Draft draft-zaccone-nat-transport-00.txt June 15, 1999
Translation", Internet Draft <draft-borella-aatn-dnat-
01.txt>, April 1999.
[RSIP-FRAM]
M. Borella, D. Grabelsky, "Realm Specific IP: A Framework",
Internet Draft <draft-ietf-nat-rsip-framework-01.txt>, Mai
1999.
[RSIP-PROT]
J. Lo, K. Tuniguchi, "Realm Specific IP: Protocol Specifica-
tion", Internet Draft <draft-ietf-nat-rsip-protocol-01.txt>,
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 <draft-ietf-idmr-pim-
arch-05.txt>, 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]