draft-durand-dual-stack-lite

[james woodyatt <jhw@apple.com>]

everyone--

This draft describes a scenario where the public IPv4 address mapped  
to any particular CPE host is assigned to a carrier-grade NAT device  
located in the service provider network.  To that end, I'd like to see  
more text that talks about port-mapping protocols like UPnP IGD and  
NAT-PMP than simply a naked statement that they "may or may not be  
supported" by the NAT.

If these protocols are to be supported by a NAT located in the service  
provider network, regardless of whether the dual-stack-lite  
architecture is used vs. the multiple-layers of NAT, there is the  
issue that NAT-PMP and/or UPnP needs to be proxied by the local CPE  
gateway on behalf of the NAT.

This is where the dual-stack-lite architecture may be inferior to  
multiple-layers of NAT, but it's not clear from the draft.  Let me  
explain...

In the dual-stack-lite architecture, it's not clear to me that all the  
IPv4 hosts behind the CPE router-- using RFC1918 addresses, which I  
hesitate to call private addresses because they are *not* private in  
this architecture-- will be assigned NAT mappings for the same public  
IPv4 address.  If they do not, then NAT-PMP cannot be proxied by the  
CPE router.  The reason is that the single public IPv4 address used by  
the NAT-PMP server is multicast in the announcement packets to all the  
hosts in the RFC 1918 subnet.

This deficiency in the dual-stack-lite architecture could be addressed  
by making an explicit guarantee that all the nodes behind a single  
IPv6 tunnel to the NAT will be mapped to a single public IPv4 address.

I also have concerns about hairpinning in the dual-stack-lite  
architecture.  Not only must the NAT exhibit proper hairpinning  
behavior, it must hairpin properly between multiple overlapping  
customer address realms.  I see no mention of hairpinning at all in  
this draft.  If it's out of scope, I'd like to see a reference to the  
documents for which it *is* in scope.


--
james woodyatt <jhw@apple.com>
member of technical staff, communications engineering