Re: New Version Notification for draft-koodli-ipv6-in-mobile-networks-02

[Rémi Després <remi.despres@free.fr>]

Le 16 avr. 2010 à 18:45, Koodli, Rajeev a écrit :

> The ID states that the IETF dual-stack model is readily applicable in mobile networks, and that's the likely deployment model for a majority of mobile providers today. 

"Likely", yes, but not "recommended" as IPv6-only in the text as is. 
> 
> Towards the end of Section 3.1:
> 
> " In other words, the IETF's dual-stack model
>   of separate IPv6 and IPv4 networks is readily applicable to mobile
>   networks with the support for distinct APNs and the ability to carry
>   IPv6 traffic on PDP/PDN connections."
> 
> And in Section 4:
> 
> "The IETF dual-stack model [RFC4213] can be applied to the mobile networks readily."
> 
> Your input on dual-stack applies here (specifically Section 3.1).
> 
> Separately, IPv6-only deployments may be relatively few, but need to be looked into.

"Looked into", I do agree, but not prematurely "recommended".

Among problems I see, one is IMHO very important:
- E2E transparency is a key feature that IPv6 restores.
- If DNS64-NAT64 synthesizes IPv6 addresses that hosts don't distinguish today from real IPv6 addresses, this destroys the IPv6 guarantee of e2e transparency.

In my understanding, until all concerned applications do recognize IPv4-embeded IPv6 addresses from real ones, DNS64-NAT64 will be harmful to IPv6, and should be advised against.

Dual-stack deployments (with NAT44 CGNs and guaranteed IPv6 e2e transparency), offer on the other hand a clean IPv6 service that IPv6-only deployments with DNS64-NAT64 can't offer.


> In IPv6-only deployments, there can be no IPv4 connectivity (PDN/PDP) at all.  Please see more below.

In sec 3.3, you have (asterisks added):
   " Hence a service provider may
   choose to enforce IPv6-only PDN and address assignment for their own
   subscribers in their Home Networks, see Figure 1.  This is feasible
   for the newer MNs when the provider's network is "IPv6-ready", which
   means the network is able to provide IPv6-only PDN support *and
  IPv6 - IPv4 interworking*  for Internet access."

I therefore understood the considered "IPv6-only" networks as having DNS64-NAT64s (not as having no IPv4 connectivity at all). 

> ...
> I could reword the last sentence to: "For instance, if an LTE deployment is IPv6-only, a roamed 3G UMTS network may not offer IPv6 connectivity"

Isn't it true that the lack of IPv6 connectivity of some 3G UMTS networks is independent from whether LTE networks are dual-standard or not?


> ...
>>> In summary, that is *dual-stack deployments* that must be "encouraged" today.
> 
> Sure, dual-stack is not only encouraged but the *recommended* model. This is captured in the ID (as I mentioned above):
> 
> " In other words, the IETF's dual-stack model
>   of separate IPv6 and IPv4 networks is readily applicable to mobile
>   networks with the support for distinct APNs and the ability to carry
>   IPv6 traffic on PDP/PDN connections."
> 
>>> In my understanding, this is the current IETF stand, and should remain so until more experience is gained.
> 
> Dual-stack is the recommended model.

Making it very clear will then be an improvement (IMHO). 

> "In summary, IPv6-only deployments should be encouraged while considering the roaming and applications issues"

I still can't agree on this because:
- The market of real IPv6-ony is too limited.
- IPv6-only + DNS64-NAT64 is harmful to IPv6 e2e transparency.
- With simple additions in LTE MNs port-restricted public IPv4 addresses can be made available across IPv6-only access networks, which reconciles IPv6 e2e transparency and IPv4 connectivity with an IPv6-only routing plan in LTE access networks. (About this, see also what I answered to Cameron Byrne in http://ops.ietf.org/lists/v6ops/v6ops.2010/msg00609.html).

IMHO, if your draft can be a great informational document if relieved of general "encouragements" to deploy IPv6-only (at least as long as it implicitly goes with DNS64-NAT64), and if noting the conflict between IPv6 e2e transparency and DNS64-NAT64.

Best Regards,
RD