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

From: "Francois Audet" <[email-masked]>
Date: Thu, 17 Feb 2005 18:07:48 -0800 (PST)

<FONT face=Arial color=#800000 
size=2>Bryan,
<FONT face=Arial color=#800000 
size=2> 
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.
<FONT face=Arial color=#800000 
size=2> 
It 
takes care of some of the issues you mention, but it obviously adds its own 
issues.

<FONT 
face=Arial color=#800000> 
<SPAN 
class=341240002-18022005> -----Original Message-----From: 
ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
[mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Bryan 
FordSent: Thursday, February 17, 2005 08:48To: 
ietf-behave@xxxxxxxxxxxxxxxxxxxSubject: [Ietf-behave] New draft: 
Topology Complications
<BLOCKQUOTE 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #800000 2px solid; MARGIN-RIGHT: 0px">
  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" <A 
  href="http://www.ietf.org/internet-drafts/draft-ford-behave-top-00.txt" 
  target=_blank>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 <FONT 
  size=2>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 <FONT 
  size=2>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 <FONT 
  size=2>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 <FONT 
  size=2>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 <FONT 
  size=2>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 <FONT 
  size=2>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 <FONT 
  size=2>_______________________________________________ <FONT 
  size=2>Ietf-behave mailing list <FONT 
  size=2>Ietf-behave@xxxxxxxxxxxxxxxxxxx <A 
  href="https://list.sipfoundry.org/mailman/listinfo/ietf-behave" 
  target=_blank>https://list.sipfoundry.org/mailman/listinfo/ietf-behave

---

From: Pyda Srisuresh <[email-masked]>
Date: Sun, 20 Feb 2005 12:22:51 -0800 (PST)

Francois,

Thanks for your comments. Please see my responses inline.

cheers,
suresh

--- Francois Audet <audet@xxxxxxxxxx> wrote:

> 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. 

[suresh] You are right. Doing NAT (instead of VA) inside the remote access
client is an option offered by some vendors. The NAT option will obviate
mucking with routes on the client-PC. It is worth mentioning for this reason. 

However, this scenario carries the same caveats (as with VA) w.r.t. overlapping
networks on the corporate and remote access end.

>                                                                  So you'd
> get, say, a 192.168.0.X address range at the bottom instead of the 10.1.1.1.
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[suresh] What did you mean by this? Are you saying the address pool used by the
VPN server is 192.168.0/24, when the corporate uses 10.1 network? I must be
missing something here.

> 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.
> 

[suresh] Sorry, I dont follow what you are saying. But, I do agree the NAT
option takes care of some caveats, but adds caveats of ots own. That was
principally why we didnt specify this in the first rev. We will specify this in
the next rev.

cheers,
suresh
  
>  -----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
> <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 
> Thanks! 
> Bryan 
> _______________________________________________ 
> Ietf-behave mailing list 
> Ietf-behave@xxxxxxxxxxxxxxxxxxx 
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
> <https://list.sipfoundry.org/mailman/listinfo/ietf-behave>  
> 
> 
> > _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
> 

=====