Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?

[Alexandre Petrescu <[e-mail]>]

Le 27/11/2020 à 17:43, Philip Homburg a écrit :
>> Can you please write a draft explaining how it is supposed to
>> work? And if it is true as you say that it is currently implemented
>> and deployed, what implementations support that, how do the
>> topologies look like etc? I work for a reasonably large vendor I
>> can guarantee you that we have not implemented support for
>> ephemeral addressing. ;-)
> 
> Maybe we are talking about different things.
> 
> What I'm talking about if that applications on phones keep working 
> even if the phone witch between mobile and wifi connections or moves
>  from one wifi to the next.

In IPv4 _most_ applications on smartphone do work ok after handover.
Other particular apps, eg Skype ongoing calls, break after handover.

The same behaviour is with IPv6.

If one wants an universal solution to deal with that mobility
universally at network layer, such that all apps - even the ones that
are not improved to deal with address changes - will continue working
after addresses change then that solution is the protocol Mobile IP
(there is Mobile IPv4 and Mobile IPv6).  But people dont need that.
Most apps that need to resist handovers do have some sort of handover
management built in; other apps never need to be handed over either (eg
always use the 4G everywhere).

In the case of cars, such a universal mobility protocol Mobile IP has
been extended with NEMO extensions (network mobility).  But it has some
drawbacks stemming from the mandatory use of tunnels and from the
security risks of its route optimization.

Without Mobile IP, it would be already an exceptional achievement if
cars got a shorter than /64 prefix from the cellular network, or if it
used /65 RAs SLAAC in the onboard network.  That would already have a
high impact.

> Similarly laptops can move from one wifi to the next. VM running on a
> laptop can be taken from one wifi to the next and keep working, etc.
> 
> Nobody expects to reboot a phone or laptop just because you connect 
> to another wifi. In the case of the VMs running on my laptop, they 
> are bridged, so they pick up new addresses even though there 
> connections stay up.
> 
> Now the question is we can also make this work for prefixes. Can I 
> give my VMs a separate prefix and expect that to be updated as I move
> around.

Mobile IP with NEMO extensions does mobility for prefixes, but it is
hard; it even use DHCPv6-PD to dynamically get a prefix - through the
tunnel - from home.  Yet it has too much encapsulation and a difficult
triangular routing involved.

In small networks (eg VMs moving between Xeon blades in datacenters) it
is possible to use something else than Mobile IP.  Maybe DHCPv6-PD with
CONFIRM messages coupled to a route update mechanism.

But in distant and non-cooperating networks (eg wifi hotspot and
cellular networks separated by firewalls) it's impossible to hand-over
even an address, because the route update involved will provoke 'route
churn'.  Imagine then handing over an entire prefix (not an address) and
the route updates that go with it.  One exception to this is the
Boeing/BGP/NASA experiments which update the routes to a plane ok.  But
despite the geographically large areas, they are still small networks -
the number of hops is small, the number of routers is small.

In these cases, one (myself included), would be very happy if one could
rely on the layer-2 handover mechanisms of the cellular networks which
guarantee the allocated address (and potentially a prefix) stays the
same within an area of certain size as long as the phone keeps heartbeating.

But we dont have even that: we cant connect a car to a cellular network
without involving multiple SIM cards, or additional Gateways (Home
Agents, VPN ageways, etc), additional tunnels, triangular routing, etc.

> If vendors of network equipment don't care about this, then there is
>  always IPv4 and NAT. Or maybe IPv6 and NAT.

I doubt the necessity of threatening, even if in this case the
threatening might indeed reflect a legitimate irritation.

In IPv4 the question is not well posed.  The fortunate fact that some
apps do resist handovers wifi-cellular is not thanks to NAT-IPv4.  It is
thanks to app-specific software dealing with such events, or due to the
web browsing nature which is bursts of req-response messages during
which address changes get unnoticed often; their speed is the speed at
which human users 'tap' or 'click'.  Also the nature of audio stream
listening where re-transmits and buffer accommodate temporary losses of
connectivity until next address is allocated.

It is not IPv4 NAT that helps apps continue after handovers.

As such, it will not be IPv6 NAT either that will help apps to continue
after handovers.

But, conceptually, IPv4 NAT and IPv6 NAT certainly do help to extend the
networks, to go beyond that bottom.

It is IPv4 NAT that makes today to extend networks beyond a smartphone.
  That is the legitimate irritation, because the immediate availablity of
IPv6 NAT software coupled with the lack of other-than-64 prefixes in
cellular networks and coupled to the 64-only SLAAC, it leads to this
potential fear that IPv6 NAT will also extend the networks.  I share
that potential fear.

Alex


> 
> -------------------------------------------------------------------- 
> IETF IPv6 working group mailing list [e-mail] Administrative 
> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
> --------------------------------------------------------------------
>