Re: [Int-area] Revving draft-intarea-shared-addressing-issues

["Dan Wing" <[e-mail]>]

 

> -----Original Message-----
> From: Matthew Ford [mailto:[e-mail]] 
> Sent: Monday, June 14, 2010 2:19 AM
> To: Dan Wing
> Cc: 'Brian E Carpenter'; [e-mail]; 
> [e-mail]; 'Lorenzo Colitti'
> Subject: Re: Revving draft-intarea-shared-addressing-issues
> 
> Hi Dan,
> 
> On 12 Jun 2010, at 17:27, Dan Wing wrote:
> 
> > 
> > 
> >> -----Original Message-----
> >> From: Brian E Carpenter [mailto:[e-mail]] 
> >> Sent: Friday, June 11, 2010 12:54 AM
> >> To: Dan Wing
> >> Cc: 'Matthew Ford'; [e-mail]; 
> >> [e-mail]; 
> 'Lorenzo Colitti'
> >> Subject: Re: Revving draft-intarea-shared-addressing-issues
> >> 
> >> On 2010-06-11 10:30, Dan Wing wrote:
> >> ...
> >>>> o Add some text to clarify that whether we're talking about 
> >>>> DS-LITE, NAT64 or NAT444 isn't especially important - it's 
> >>>> the view from the outside that matters, and given that, most 
> >>>> of the issues apply regardless of the specific address 
> >>>> sharing scenario in question.
> >>> 
> >>> That would be good.  Should be NAT44 (not "444"), though.  The
> >>> problem of IP address sharing is orthogonal to the subscriber
> >>> operating their own NAT in their house (which is one of the
> >>> 4's of NAT444).
> >> 
> >> Really, in every single case? I thought there were cases
> >> where single-NAT traversal works and double-NAT traversal doesn't.
> > 
> > Yes, there are such cases.  And those cases should be called 
> > out.
> > 
> 
> Care to offer (or point me to) some text on this point?

Here is a shot at some text:


"There are several commonly-deployed mechanisms that support
operating servers behind a NAT by forwarding a specific TCP 
or UDP ports to a specific internal host ([UPnP-IGD], 
[I-D.cheshire-nat-pmp], and manual HTML configuration).  All
of these mechanisms assume the NAT's WAN address is a 
publicly-routable IP address, and fail to work normally
when that assumption is wrong.  There have been attempts to
avoid that problem by disabling the NAT function and merely
bridging traffic (is is required for [Windows-Logo] 
certification), but this only works if the WAN address is
a specific address, and bridging (rather than NATting) has
other side effects (DHCP requests are served by an upstream
DHCP server which can increase complexity of in-home 
networking).

Some routers enable 6to4 [RFC3056] on their WAN link.  6to4
requires a publicly-routable IPv4 address.  Enabling 6to4
behind a NAT causes a disconnected IPv6 island."



references in XML:


&I-D.cheshire-nat-pmp;


      <reference anchor="UPnP-IGD"
                 target="http://www.upnp.org/standardizeddcps/igd.asp">
        <front>
          <title>Universal Plug and Play (UPnP) Internet Gateway Device
          (IGD)</title>

          <author fullname="UPnP Forum" surname="UPnP Forum">
            <organization></organization>
          </author>

          <date month="November" year="2001" />
        </front>
      </reference>


      <reference anchor="Windows-Logo"
target="http://www.microsoft.com/whdc/winlogo/hwrequirements/default.mspx">
        <front>
          <title>Windows Logo Program Device Requirements</title>
          <author fullname="Microsoft" surname="Microsoft">
            <organization></organization>
          </author>
          <date year="2006" />
        </front>
      </reference>


-d