[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New Version Notification for draft-koodli-ipv6-in-mobile-networks-02
Le 20 avr. 2010 à 16:11, Cameron Byrne a écrit :
> With all due respect, I don't think you and I will come to an
> agreement, we simply have different priorities and values. A major
> network that I work at will take this "step backwards" with IPv6-only
> and NAT64, it is already deployed in a trial, the trial is going VERY
> well. The customer experience on IPv4 + NAT44 and IPv6 + NAT64 are
> identical for the target handsets and users.
User experience may be the same so far but, to take an example, the impossibility to translate UDP datagrams with null checksum exists in NAT64s and doesn't exist in NAT44s.
(With all due respect, the fact that a decision has been made doesn't forbid to look at its foreseeable consequences, without any taboo.)
> IMHO, your arguments
> are not strong enough to justify yet another solution and will not
> appeal to mobile operators. Mobile has IPv6 solutions, they were
> described in full at the San Francisco 3GPP-IETF meeting, and I
> believe operators are moving forward with those solution, the timeline
> requires movement now.
"Moving forward" with dual-stack routing IS possible (no need for another solution for a deployment today).
Depending on interpretation, it remains the ONLY recommended model, or just one of them.
(As you have understood, dual stack should be IMHO remain so far the ONLY recommended model.)
One can choose to deploy NAT64, taking then the responsibility for all known and foreseeable consequences.
> A major outcome from that San Francisco
> meeting that you need to be very aware of is that there is a very
> large resistance to adding new features to the mobile handset.
I certainly didn't wait for this meeting to notice it.
That's why dual-stack is the safest way to avoid urgent fixes in mobile handsets when problems that were never experienced before but are foreseeable start to appear.
> As
> soon as you bring that up, the mobile operator will dismiss 4RD just
> as they moved away from PNAT and DS-Lite.
You may be right.
LTE could however have been a nice opportunity to include in the specification a simple complement to IPv6 drivers, to the effect that:
- port-restricted IPv4 would be statelessly available across IPv6-only LTE infrastructures
- LTE access networks could have been deployed with IPv6 only in routers and without any DNS64-NAT64 to be supported (an important saving in operational costs)
Note that 4rd is also a solution for DSL operators, applicable between ISP border routers and home gateways (like 6rd), which may be sufficient for its future.
> I don't believe you are communicating with IPv6 hosts at NetFlix and
> Google, right? Your e2e is between a host and a stateful load
> balancer doing protocol translations. Like many thing, if it works
> today and is inexpensive, it gets deployed.
I don't use NetFlix.
I never doubted that when using Google, or the IETF site, servers were directly accessible in IPv6.
(IPv6 load balancers would no longer be load balancers if they would have to do, in addition to their essential function, IPv6-IPv4 translations.)
In my understanding, that's solutions without NAT64s that so far ARE deployed, and work, and are inexpensive (with 6rd being a particular tool for this in ISP environments).
> In any technology decision, trade-offs must be made. IMHO, NAT64
> trades off some E2E (IPv4 is NAT44 anyways today) to expedite the
> deployment of IPv6 where all flows will have E2E (aside from content
> load balancers). Given that IPv4 is NAT44 today, going to NAT64 is
> steady state, no new downsides and I get the upside of direct e2e for
> ipv6.
NAT64 is NOT steady state from NAT44, for various reasons (UDP null checksum, being one of them).
Dual-stack is much more steady state.
Regards,
RD