Unintended Consequences of NAT Deployments with Overlapping Address Space
draft-ford-behave-top-07

[Ballot discuss]
I think document is confused about how two different interfaces can have the same IP and how that works. The advice about split VPN goes strongly against what the RAI area generally recommends. The advice about blocking IP that mach the IP of of the access router is really bad and  goes against what pretty much every VPN product I could find to test actually does. I would like to talk on the call about if this draft is harmful for VPN deployments and if it should be DNP.

[Ballot comment]
I'm confused by the example in section 3.2.4.  Does the example discuss hijacking inbound mail, outbound mail or IMAP/POP access? 

Does this sentence from the second paragraph in 3.2.4 refer to NAT-2 in figure 1.1:

  Ideally, ISPs should not use NAT devices to provide connectivity to
  their customers.

LSNs (large scale NATs) seem to be an inevitable example of deployments like NAT-2.  Perhaps section 3.2.4 could be expanded to explain how NAT-2 and NAT-3 would be configured to accommodate inbound mail to a mail server on Host G?

IESG,

This document was submitted to the RFC Editor to be published as an
Informational Independent Submission: draft-ford-behave-top-06.txt.

Please let us know if this document conflicts with the IETF standards
process or other work being done in the IETF community.


Unintended Consequence of two NAT deployments with
Overlapping Address Space

This document identifies two deployment scenarios that have arisen
from the unconventional network topologies formed using Network
Address Translator devices (NATs). First, the simplicity of
administering networks through the combination of NAT and DHCP has
increasingly lead to the deployment of multi-level inter-connected
private networks involving overlapping private IP address spaces.
Second, the proliferation of private networks in enterprises,
hotels and conferences, and the wide spread use of Virtual Private
Networks (VPNs) to access enterprise intranet from remote locations
has increasingly lead to overlapping private IP address space
between remote and corporate networks. The document does not
dismiss these unconventional scenarios as invalid, but recognizes
them as real and offers recommendations to help ensure these
deployments can function without a meltdown.


Four week timeout expires on 5 June 2009.