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

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

Le 16 avr. 2010 à 20:19, Cameron Byrne a écrit :

> On Fri, Apr 16, 2010 at 10:30 AM, Rémi Després <remi.despres@free.fr> wrote:
>> 
>> ... like 6rd permits to easily offer native IPv6 on IPv4-only infrastructures (see RFC 5569), the same principle reversed permits to offer public IPv4 (with restricted port sets) on IPv6-only infrastructures.
>> 
> 
> As others have pointed out, changes to requirement or technology on
> handsets is highly discouraged.

Solving unsolved problems with incrementally deployable new technologies remains a good way to make progress.

Reversed 6rd (or "4rd", as Satoru Matsushima privately suggested to call it) is something handsets MAY support to get improved service, introducing no restriction to other handsets (or PCs or whatever hosts use LTE access):
- If they don't support 4rd, they depend on DNS64 and NAT64 to reach IPv4-only remote hosts.
- If they do support 4rd, they get public IPv4 addresses (port-restricted), statelessly derived from their IPv6 addresses. They can use them to reach IPv4-only remote hosts with e2e transparency (no dependence on a DNS64 and a NAT64).

If you have read RFC 5569 which shows native IPv6 has been offered in 2007 across an IPv4-only infrastructure, with a trivially simple mechanisms, you may guess how simple in can be to offer public IPv4 addresses (port restricted) across IPv6-only infrastructures, e.g. LTE access networks.

So far, "4rd" is described only in sections 3.2 and 2.6 of draft-despres-softwire-sam-00, but indirectly (and without the name).
I plan to have a specific draft on "4rd" for IETF 78.
Your reactions to it will be most welcome. 


> ... regardless, of how you pay for capacity, 2x the PDP session will
> result in 2x the hardware since you will be doing 2x the signalling
> and 2x the mobility events within the mobility core.

Not with 4rd. 
(IPv4 packets are encapsulated in IPv6 packets, which are transmitted using their PDP session.)  

> ... My point is that for a mobile operator that does NAT44 today,
> IPv6-only with NAT64 is the simplest path forward.  This is because:
> 
> 1.  More and more devices are alway-on.  Before, handsets would only
> have IP address when you go to a web site or actively transfer data.
> Now, handsets are always connected to mobile network and always
> transmitting data on your location, sycn your email and contacts,
> register with SIP / IMS ...  This is a big change for the dimensioning
> of the network.
> 
> 2.  Mobile operators have deployed both BOGON and overlapping IP
> address space, both are bad and substantially limit peer to peer (e2e)
> communication.  In case of BOGON, the operator needs to change IP
> address space periodically as the space they are using is claimed by
> its rightful owner.  That is a risk to be managed.  In the re-using IP
> address space case, any mobile to mobile communication (voice, video,
> p2p) must go through some device that can disambiguate the addresses
> based on location and state, like a SIP B2BUA or Session Border
> Controller.  This is costly and complicated to operate.
> 
> 3.  Users are increasingly communicating end to end  IMS / SIP services.
> 
> 4.  As everyone know, mobile subscribers are growing very quickly

With 4rd, the port-restricted IPv4 address derived from an IPv6 address is as stable as the IPv6 address.

Note that if an operator restricts to 256 ports the assignment each handset gets for its IPv4 connections, this multiplies the number of hosts it supports with a given IPv4 address space by 256. (And 256 ports is much much more than the handset will need for IPv4 when most of the traffic becomes end-to-end IPv6.)

> All of the above make the case that work-arounds with IPv4 are poor
> investments.  

DNS64 and NAT64 ARE "work-araounds".
Their advantage is to be almost completely specified, but their drawback is to have complex and hard to predict consequences. 
By adding 4rd in handsets (a stateless function), they can get during the v4/v6 coexistence period, a cleaner and safer service from operators that support 4rd (border relays that, unlike NAT64s, operate statelessly at the transport layer).

> The smart money is being spent to bring IPv6 primary
> services in quickly since the pay back time on the investment is as
> long as you use IPv6, not the life of a NAT444 CGN or other
> infrastructure.  Any technology that has a lead time of 18 months to
> develop and other 2 years to tune in production cannot meet the
> investments requirements since they will be obsolete too soon.   As we
> agree, IPv6 content will be here very soon.

We also agree that the v4/v6 coexistence period won't be finished in 18 months ;-).
IMHO, offering better service to upgraded handsets for this coexistence period, and this at extremely low cost, still makes sense.

> IPv4-only service won't go away any time soon.  IPv6-only will be
> specific handsets and services that will certainly be regression
> tested to make sure the user experience is acceptable.  For people
> where IPv6-only + NAT64 works, we should encourage them to use it.

It seems to me you plan more to "force" them to use it than to "encourage" them.
Now, if the handset acts as a small router with an integrated NAT44 (as at least some Nokia handset do today), it will have to support a NAT46 which will be cascaded with NAT64s. With 4rd, it the NAT44 needs only to work with restricted port sets.


> For people that it does not work, we can have products / services for
> that too.

Without any upgrade in handsets?


It might be easier to pursue this discussion when a better description of the 4rd proposal is available.

Kind regards,
RD