Unintended Consequences of NAT Deployments with Overlapping Address Space
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: RFC Editor <firstname.lastname@example.org> Cc: The IESG <email@example.com>, <firstname.lastname@example.org>, email@example.com Subject: Re: Informational RFC to be: draft-ford-behave-top-07.txt The IESG has no problem with the publication of 'Unintended Consequence of two NAT deployments with Overlapping Address Space' <draft-ford-behave-top-07.txt> as an Informational RFC. The IESG would also like the IRSG or RFC-Editor to review the comments in the datatracker (https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=12947&rfc_flag=0) related to this document and determine whether or not they merit incorporation into the document. Comments may exist in both the ballot and the comment log. The IESG contact person is Magnus Westerlund. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ford-behave-top-07.txt The process for such documents is described at http://www.rfc-editor.org/indsubs.html. Thank you, The IESG Secretary
Technical Summary 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. Working Group Summary This is an RFC-editor independent submission. Document Quality This is an RFC-editor independent submission. Personnel Magnus Westerlund was the responsible AD for the RFC 3932 recommendations. RFC Editor Note The IESG thinks that this work is related to IETF work done in WG BEHAVE, but this does not prevent publishing. IESG Note This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and notes that the decision to publish is not based on IETF review apart from IESG review for conflict with IETF work. The RFC Editor has chosen to publish this document at its discretion. See RFC 3932 for more information.