RE: I-D Action:draft-ietf-v6ops-nat64-pb-statement-req-00.txt

[<teemu.savolainen@nokia.com>]

>If you are still thinking of a mobile device that is acting as 
>an interworking unit between a local IPv4 network and an IPv6 
>world, it seems to me you are loading it up with CPU and 
>memory and battery power needs that are unreasonable. I agree 

On mobile the resource needs for NATting/translating are not very
significant when compared to resources needed to transmit data (e.g.
video) on WLAN/HSPA/EVDO/LTE/WiMAX speeds at the first place (or having
a VPN for encryption for those speeds, which is a supported feature on
some products). There are already cellular phones on market that come
with DHCP server and NAT for IPv4->IPv4 case (Bluetooth PAN->cellular).

There are also companies implementing software for cellular WLAN
hot-spot kind of features, see e.g.:
- JoikuSpot http://www.joikuspot.com/ (free)
- Walkinghotspot http://www.walkinghotspot.com/

Generally the power consumption with high data rates is a significant
factor and an area of constant research/optimization. However, if people
have to choose between not to have a high speed data access at all, or
have a high speed data access for half a day or so when running on
battery and indefinitely when near mains, they choose to have the
feature. The keep-alives are the biggest problem as they eat the standby
time without giving clear benefits for users.

I also tend to believe that people do most of the data transmission when
they are rather still and near mains - e.g. at visited office, at home,
at summer cottage, or e.g. in train (in Finland the better trains have
power available on certain seats). 

Furthermore, the mobile device does not necessarily have to be handheld,
it can be an USB-stick which gets power from PC, or it can be a fixed
device e.g. in a car/bus/table that acts as WLAN AP for nearby devices
and uses cellular network as WAN. 

An alternative is to make mobile devices IPv6-only, but that would
introduce flag-day kind of problems:
- convince people that they should upgrade their old IPv4-only
applications/devices (is this really a possibility?)
- place the burden of doing IPv4-over-IPv6 to other devices (e.g.
laptops)
=> this solution has the problem of
not-providing-so-nice-transition-experience and also that for some
software there might not be IPv6-support available (in time) - an
important example is Java MIDP 2.0 runtime environment, which is
IPv4-only. MIDP 3 is bringing IPv6 support (optional), but that is not
yet approved standard. I.e. if transition would happen by large next
year, we probably would have to provide support for IPv4-only devices,
applications and run-time environments, but maybe 5 years from now
different approach would be possible.

>that we shouldn't restrict where the various functions can be 
>placed, but it seems desirable to minimise what is needed in 
>mobile devices.

True, but if IPv6-only is not practical option (see above), is native
dual-stack (for mobile device, for last-mile) always the most
cost-efficient solution? 

Consider a cellular operator with 100 million customers needing
simultaneous network connectivity. Which is the cheapest architecture
for them (I don't know the right answer):
1) provide native dual-stack air interface ("last mile") 
2) provide translator box (e.g. NAT-PT, MNAT-PT, NATv4v6v4)
3) provide static tunneling (e.g. configured tunnels (via provisioning),
SNAT, VPN, DSMIP)
4) provide dynamic tunneling (e.g. TSP)

1) requires resources for transmitting both address families over the
air interface/last mile. These resources include at least IPv4 address,
plus in some technologies also more resources from the first hop router
(in 3GPP this requires two parallel PDP contexts and thus more
powerful/costly GGSN). The IPv4 address could be conserved by on-demand
reservation, but if the on-demand reservation requries closing/opening
link-layers (e.g. PDP contexts) and thus brings in latencies, does that
provide good user experience?

2) Don't these require ALG support for either NAT-PT box, or also on the
mobile host in case MNAT-PT/NATv4v6v4 is implemented there? E.g. even if
application uses synthetic IPv4 source address and thus knows there is a
NAT on the path, the "client-side" of MNAT-PT/NATv4v6v4 needs to
implement IPv4->IPv6 ALG? (in the original NAT-PT this ALG would be only
on the NAT-PT box). ALG implementation burden to all mobile devices does
not sound very attractive.

3) Has the biggest header overhead and also requires IPv4 address. I
believe these solutions also introduce biggest requirements for tunnel
endpoint performance? 

4) Aren't these kind of solutions performance-wise most optimal? No NAT,
no ALG, and the tunnel-endpoint load is the lowest?


I would be happy if we would end up with just a single solution, but I
think we may need several for different deployment scenarios (which are
the used access technologies, how many simultaneous customers need to be
served, how heavily IPv4 addresses need to be conserved) and for
different moments of time (what is the level of IPv6-support in
softwares/hardwares/services). 

E.g. 
1) dual-stack could be a solution for home deployments
(DSL/hotspot-style, from CPE box to LAN)
2) translators for further in the future when IPv6 is widely supported
by applications/devices
3) static tunneling for more demanding use-cases such as where public
IPv4 address is required, for enterprises VPN uses, where mobility is
required, or for infrastructure (e.g. used to provide IPv4 connectivity
to that CPE box/WLAN hot-post)
4) dynamic tunneling for cases where subscriber base is very large and
IPv4 applications/devices that need to be supported are many?

Best regards,

	Teemu