Subject: draft-durand-v6ops-natv4v6v4

From: james woodyatt <[email-masked]>
Date: Tue, 11 Mar 2008 12:49:18 -0400

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.

+ 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 <[email-masked]>
member of technical staff, communications engineering

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 11 Mar 2008 14:21:13 -0400

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of james woodyatt
> Sent: Tuesday, March 11, 2008 12:49 PM
> To: IPv6 Operations
> Subject: draft-durand-v6ops-natv4v6v4
> 
> everyone--
> 

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

---

From: james woodyatt <[email-masked]>
Date: Tue, 11 Mar 2008 14:38:13 -0400

On Mar 11, 2008, at 14:21, Dan Wing wrote:
> deeper NAT function as a bridge.

I am interpreting the "Double IPv4->IPv4->IPv4 NAT" scenario as one  
where the ISP assigns only one RFC1918 IPv4 address to each customer  
site, which are then expected to use IPv4/NAT to share that address  
for more than host on the customer network.

If ISP's are willing to assign a sufficiently large number of RFC1918  
IPv4 addresses to each customer site that all the nodes can be  
addressed within the ISP's routing realm and protected from the WAN by  
stateful filtering IPv4 firewalls instead of NAT, then this *isn't*  
the "Double IPv4->IPv4->IPv4 NAT" scenario described in the draft, but  
rather another one that doesn't seem covered in the current text.

---

From: <[email-masked]>
Date: Tue, 11 Mar 2008 20:55:01 +0200

Everyone,

I have been (mostly) lurking on this list, but now I feel it's about
time to contribute some thoughts. So please don't take this as direct
reply to James. 

I am surfing Internet very strongly from the cellular phone perspective.

IPv6-only: while a host could theoretically be capable of IPv6-only on
time of purchase, in addition to IPv4-only services, there are likely
going to be (installable) legacy IPv4-only applications around for some
time to come. Thus IPv6-only will just not be possible on environments
where legacy applications need to be supported. 

Double IPv4-IPv6-IPv4 NAT: The NAT46 part of this system could also be
implemented in the end host, e.g. this could be one way for cellular
devices to provide dual-stack interface for the internal applications
and for the LAN behind, while still having only IPv6 connection towards
the cellular operator. It is technically no problem for phones to
implement NAT, DHCP server, and/or IPv6 bridge functionalities etc.

Some thoughts on IPv6 transition in general: There is a pretty large
number of (~)IPv4-only cellular phones out there (and increasing while
we speak), which will never be upgraded to support IPv6. Upgrading to
IPv6 in cellular world can only happen via the usual device replacement
cycle (there are some devices that perhaps could be software upgraded
cost effectively, but those are just small minority). Thus a cellular
operator wishing to move to IPv6 will need to do the transition in a way
that all of those IPv4-phones keep on working while having the new
phones implement the chosen transition mechanism(s). And as said, these
IPv6-capable phones are likely required to be able to run those
IPv4-only applications as well. 

The transition solution, which eventually will be chosen, should be
scalable enough to support rather large number of simultaneously
connected hosts (theoretically number of subscribers an operator has, if
those subscribers are using e.g. always-on email/IM/VoIP + doing
occasional IPv4 surfing & occasional execution of legacy IPv4-only
applications. Total number of hosts can theoretically be even larger, if
subscribers are sharing the cellular connection with other devices like
laptops).

>ALG's at both the v4->v6 NAT and the v6-v4 NAT will be 
>required to translate addresses in the application protocols.

Could you clarify why the v4->v6 NAT would require ALG, i.e. why it
would not be enough to have that just in the v6-v4 NAT?

Best regards,

	Teemu

>[mailto:[email-masked]] On Behalf Of ext james woodyatt
>Sent: 11 March, 2008 18:49
>To: IPv6 Operations
>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.  
>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.
>
>large continental-scale network aren't impossible to manage.  
>They're just difficult.  Consider it an opportunity to 
>concentrate on your core competencies.
>
>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.
>
>ALG's at both the v4->v6 NAT and the v6-v4 NAT will be 
>required to translate addresses in the application protocols.
>
>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.
>
>applicable to the Double IPv6->IPv6->IPv4 NAT solution as 
>well.  The problem arises at the translation into the public 
>IPv4 routing realm,  
>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.
>
>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.
>
>
>--

---

From: james woodyatt <[email-masked]>
Date: Tue, 11 Mar 2008 15:58:09 -0400

On Mar 11, 2008, at 14:55, [email-masked] wrote:
> [I wrote:]

It's complicated.  At the very least, it needs "transparency helpers"  
which are only distinguishable from ALG's in that they doesn't  
actually need to rewrite the application stream.  Let's consider the  
case of, say, RTSP with RTCP/RTP where the media player is being the  
v4v6v4-NAT chain and the media server is on the public IPv4 network.

The v4->v6 NAT needs to rewrite the client_ip parameter in the  
Transport header of the SETUP method.  Even without that function,  
which isn't widely used, there needs to be a transparency helper that  
notices the use of client_port parameters and ensures that a v4-v6  
translation state entry is opened for the RTCP and RTP media streams  
it references.

Active mode FTP is a similar case.  IPsec VPN without NAT-traversal in  
UDP encapsulation is another one.