RE: [Ietf-behave] New draft: Topology Complications

["Francois Audet" <audet@xxxxxxxxxx>]

Title: Message

Bryan,

 

One thing worth mentioning in the VPN section, is that it is common for VPN devices (both "boxes" and PC clients) to NAT inside the tunnel. So you'd get, say, a 192.168.0.X address range at the bottom instead of the 10.1.1.1. From the corporate network however, that would still look like 10.1.1.1.

 

It takes care of some of the issues you mention, but it obviously adds its own issues.

 

 -----Original Message-----
From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Bryan Ford
Sent: Thursday, February 17, 2005 08:48
To: ietf-behave@xxxxxxxxxxxxxxxxxxx
Subject: [Ietf-behave] New draft: Topology Complications

Finally, the following slightly revised and expanded version of the earlier
"Topology complications" document I announced on the list, is now in the
official Internet-Drafts repository.

"Topology complications from Network Address Translator deployments"
http://www.ietf.org/internet-drafts/draft-ford-behave-top-00.txt

    This document identifies and provides recommendations for dealing with
issues that have arisen recently from the ubiquitous deployment of network
address translators (NAT), and the unconventional network topologies that are
often constructed with them. First, the simplicity of administering networks
through the combination of NAT and DHCP is increasingly leading to the
deployment of multi-level hierarchies of inter-connected private networks
involving overlapping private IP address spaces. The creation of these
multi-level hierarchies is often unintentional, since each level of NAT is
typically deployed by a separate administrative entity such as an ISP, a
corporation, or a home user. Second, the popularity of corporate virtual
private networks (VPN) in conjunction with NAT leads to problems in which the
private IP address space of the network through which a remote client is
attached may unintentionally conflict with the private IP address space of
the corporate network into which the remote client is tunneled. This document
specifies best current practice recommendations for addressing the issues
identified.

  Since I've already received a number of positive comments on the original
draft privately by E-mail, I'd like to hear public reactions to the idea of
adopting this draft as a WG document, to be published sometime down the road
relatively independently of the other documents.  The main complication is
that there is currently no corresponding WG milestone or work item for this
document, so one would have to be added.

Thanks!
Bryan
_______________________________________________
Ietf-behave mailing list
Ietf-behave@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/ietf-behave