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

[<teemu.savolainen@nokia.com>]

> have now.  Overlapping spacing introduces several challenges,
> especially in an IMS environment.  Dual-stack also cost 2x the price
> in pre-release 8 networks (per PDP pricing...)

Shouldn't applications that have issues with overlapping addresses go directly to IPv6? Especially IMS?

Then, should the possible vendor pricing models really affect technology selections in SDOs? After the discussions in 3GPP last winter I got the impression that cost of PDP contexts is not a factor when choosing transition mechanisms. In fact, I was told by several people that GTP tunnels are so cheap that we should not look for anything more complex than that - and I thought that was the case until these discussions started again:)

Now, if the cost of PDP contexts really would be an issue and rather significant host changes in LTE timeframe would be allowed (as seems to be the case here..) then why not go for single hop IPv4-in-IPv6 tunnel from UE to PDN-GW - maybe flavored with DSTM kind of dynamic IPv4 address allocation (deferred address allocation) or maybe even with AFTR at the PDN GW. 

IPv4v6 bearer type would not be needed, IPv6 type would suffice.

Traffic filtering & QoS & DPI thingies could happen before IPv4 is encapsulated to IPv6 and right after IPv4 has been decapsulated.

MTU is not really an issue, 1500 has been difficult to have anyway due network fragmentation avoidance (i.e. at least some hosts have been using less-than-1500 MTU to avoid fragmentation of GTP tunnels).

Extra header overhead for bulk traffic is relatively small and RoHC can squeeze away also the tunnel headers of VoIP traffic.

But all-in all, I think the discussions concluded that native dual-stack, with moving as many apps to IPv6 as possible, and network providing (possibly overlapping) IPv4 addresses to hosts, was seen as the best way forward.

I think the draft, now that it is WG draft, should reflect the conclusions that have been already achieved and not restart transition mechanism selection discussions... 

Best regards,

Teemu