RE: draft-durand-v6ops-natv4v6v4

["Dan Wing" <dwing@cisco.com>]

> -----Original Message-----
> From: owner-v6ops@ops.ietf.org 
> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of james woodyatt
> Sent: Tuesday, March 11, 2008 12:49 PM
> To: IPv6 Operations
> Subject: draft-durand-v6ops-natv4v6v4
> 
> everyone--
> 
> I have some comments on the proposed solutions.
> 
> IPv6-Only >> In my wildest flights of fantasy, I cannot imagine this  
> as a serious proposal.  It's only here for the sake of completeness,  
> yes?  There is currently no practical value for IPv6-only service  
> except to sites which don't need access to the public Internet and  
> only need connectivity to an identified set of IPv6-only 
> peers.  These  
> customers can be adequately served by tunneling IPv6 over IPv4, e.g.  
> the way Apple's Back-to-my-Mac works today.
> 
> Double IPv4->IPv4->IPv4 NAT >> This solution has an additional  
> unstated advantage.  It's already deployed in residential 
> settings and  
> known to "work" to the satisfaction of its users.  It has 
> drawbacks.   
> Here's what I think about the ones noted in the draft.
> 
> + We will fix the first drawback, i.e. the hole-punching problem of  
> multiple layers of NAT, by forwarding NAT-PMP requests up the 
> chain to  
> the router with the public IPv4 address.  Obviously UPnP IGD 
> will have  
> to be likewise upgraded, but these router products tend to have a  
> comparatively short product lifespan, and forces unrelated to IPv6  
> deployment will be driving this upgrade.

Such an upgrade is only possible if the upper NAT is controlled by the
user or upgraded (and upgradable) by whoever owns it.  As a concrete
example of where this can't work -- some "DSL modems" provided by ISPs
have built-in NAT functions.  I know Bellsouth does this based on
personal experience when configuring my in-law's ADSL service.

Such an upgrade also cannot occur if the ISP NATs their subscribers,
because none of the ISP-sized NATs from major NAT vendors
(Checkpoint/Juniper/Cisco) support UPnP IGD or NAT-PMP.  Concrete
examples of ISPs NATting their subscribers include the largest MSO in
Germany, non-PTT ISPs in Africa and S. America, and China.


Another approach to avoid the NAT-behind-NAT situation is to have the
deeper NAT function as a bridge.  This deeper NAT is oftentimes the
NAT you just purchased from the store (for its 802.11n support, for
example).  Disabling the NAT function is one of Microsoft's Vista logo
requirements (requirement NETWORK-0076 of "Windows Hardware Logo
Program Requirements - PDF format", November 20, 2007, available from
<http://www.microsoft.com/whdc/winlogo/hwrequirements.mspx>).  There
are several disadvantages to this approach, too.

-d


> + The operational issues of operating several IPv4 routing 
> realms on a  
> large continental-scale network aren't impossible to manage.  
> They're  
> just difficult.  Consider it an opportunity to concentrate on your  
> core competencies.
> 
> + Address conflicts are already a reasonably manageable 
> problem inside  
> residential networks, where users are stacking up NAT behind NAT on  
> their own premises just because configuring boxes requires a 
> level of  
> geeky expertise that normal people generally avoid acquiring.  The  
> same mechanisms we use to mitigate those problems will have 
> to be used  
> to deal with the case where the ISP is providing RFC 1918 addresses  
> that conflict with what the box wants to use in its factory  
> configuration.  (At Apple, this is already a problem in some markets  
> where ISP's are routinely deploying the Double IPv4->IPv4->IPv4 NAT  
> solution.)
> 
> Double IPv4->IPv6->IPv4 >> From the customer perspective, this looks  
> identical to the Double IPv4->IPv4->IPv4 NAT solution above, because  
> the only way this architecture can work is if the CPE that 
> does the v4- 
>  >v6 translation is provider provisioned.  Absent the heavy hand of  
> market regulation by government, vendors of retail consumer IPv4/NAT  
> residential gateway CPE devices have no incentive whatsoever 
> to assist  
> ISP's with the deployment of the Double IPv4->IPv6->IPv4 solution to  
> their operational issues.
> 
> + On the subject of ALG requirements in this alternative: yes, the  
> ALG's at both the v4->v6 NAT and the v6-v4 NAT will be required to  
> translate addresses in the application protocols.
> 
> IPv6 Tunneling + carrier-grade IPv4->IPv4 NAT >> This is a  
> simplification of the Double IPv4->IPv6->IPv4 solution above, 
> and like  
> it, looks identical to Double IPv4->IPv4->IPv4 from the customer  
> perspective.  Whether the provider provisioned CPE does IPv6 
> tunnel to  
> carrier grade IPv4->IPv4 NAT or IPv4->IPv6 NAT is matter for 
> providers  
> to decide.  Most will end up doing both in different parts of their  
> networks.
> 
> + The address sharing consideration described in section 5 is  
> applicable to the Double IPv6->IPv6->IPv4 NAT solution as well.  The  
> problem arises at the translation into the public IPv4 
> routing realm,  
> and it's really a problem for application service providers 
> to solve.   
> If "a well-known application" uses AJAX to open 69 TCP ports per web  
> page served, then the footprint they're taking up on the global IPv4  
> address for each client is 69 ports per web page, regardless of  
> whether those clients are IPv4-only, IPv6-only or dual-stack. 
>  If they  
> want to make their service available to as many customers as 
> possible,  
> then the IPv4 address depletion problem amounts to an 
> effective cap on  
> the growth of the market they can expect to be able to serve 
> over IPv4  
> in the future.
> 
> + The way these applications will respond to that problem, I 
> predict,  
> is to reduce the footprint they require on the IPv4/NAT 
> public address  
> for their clients.  They will only feel safe transitioning to IPv6  
> after a significant fraction of their user base has native IPv6  
> service superior to their existing IPv4 service.  Anything 
> that makes  
> their existing IPv4 service limp along better in the face of address  
> depletion reduces the urgency such application providers feel 
> to make  
> the transition to IPv6.
> 
> Multicast considerations >> The only multicast routing that needs to  
> be considered is SSM originating in the service provider with  
> receivers on their customer networks.  All other multicast  
> applications are, for practical purpose, dead on arrival.  Probably,  
> the best way to do this is to define an IPv6 SSM prefix that 
> subsumes  
> the existing IPv4 SSM addresses, and to define a way to send an IPv6  
> SSM stream that can be easily translated into an equivalent IPv4 SSM  
> stream at the provider provisioned CPE router.
> 
> 
> --
> james woodyatt <jhw@apple.com>
> member of technical staff, communications engineering
> 
> 
>