Subject: Is NAT66 a help in migration to IPv6?

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 30 Nov 2020 09:40:02 +0000

IPv6 is much more flexible and complex on 1st hop: many prefixes, 2x more mechanisms for address assignment, SASA algorithm, and so on, so on, so on.
But NAT is still prohibited - Looks like a political decision.
Some people come and say: NAT was very useful (more useful than many new IPv6 features), Please return it. We would like to have this tool too.
The answer is "no", it is "the policy". Or else not enough incentives to migrate from IPv4 to IPv6 (partially true).

IMHO: the market should choose what is more useful and what is less. People should vote by resources (money in 1st place).
NAT66 should be available as a choice.

On discussion below about Mobility (hand-over) support - I do agree with Alexander that:
1. Additional Overlay (based on some sort of tunneling) with independent addressing is the "universal solution".
2. Some use cases do not want the complexity associated with universal mobility solution.
But I do not agree that NAT44 was not the resiliency solution for some scenarios (example: simple topology with 1 inevitable node on the path) - It was. It did decrease the need for universal Overlay solution.
The policy to block NAT66 really increases the importance of Overlay solutions in IPv6.

It reminds me the story that all important application 20+ years ago were running on "clustering" with full memory replication between hosts. Additionally, DC was designed and certified to high level of resiliency.
Then OTT did show that is it better to assume really minimal level of resiliency from infrastructure. If some resiliency is needed - then it is the particular application problem.
IMHO: Both approaches have their market niche (finance does still prefer to keep 100% resiliency on infrastructure level). The world is big enough for this diversity.

IMHO: the world is big enough to have the choice from:
1. no any resilience at all for some scenarios (mostly for the cases when only 1 PA carrier) - applications could go through the pain of address change (some mechanisms are still needed to inform about address change)
2. NAT66 for simplified topologies - permits to preserve address on applications. 1 roaming Notebook or just 1 CPE in the apartment are the very good examples. Or any topology where 1 node is mandatory on the path (single CPE).
3. Overlay with stable address space for complex scenarios. May be even 2 overlay solutions: optimized for roaming host and roaming router.
Let people vote by money.
I could bet that if NAT66 would be available then market niche for Universal Overlay solution would be at least 10x less compare to NAT66 (by number of IP addresses practicing this functionality).

The policy "let's block NAT66" did play well to stimulate subscribers migration from IPv4 to IPv6. Because great majority of them are single attached to Carrier.
The same policy would effectively block IPv4 to IPv6 migration for Enterprises, because they would not agree to deal with the complexity of Multi-home multi-prefix PA environment. Brian and Ole did show (in different RFC) "how deep is the rabbit hole".
IMHO: no NAT66 -> no progress for IPv6 in Enterprises. Because redundant connectivity to Carriers is needed very often.

Ed/
> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
> Sent: 27 ноября 2020 г. 20:28
> To: [email-masked]
> Subject: Re: [v6ops] How do you solve 3GPP issue if neither operator nor
> handset supports PD?
> 
> 
> 
> 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 [email-masked] Administrative
> > Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 30 Nov 2020 21:57:22 +0900

The problem with your statement "should vote by resources" is that NAT
reduces the cost of the party that deploys it (network operators) by
increasing the costs of the parties that do not deploy it (app developers,
OS developers). Those latter parties are the ones pushing back against NAT.

On Mon, Nov 30, 2020 at 6:40 PM Vasilenko Eduard <
[email-masked]> wrote:

> IPv6 is much more flexible and complex on 1st hop: many prefixes, 2x more
> mechanisms for address assignment, SASA algorithm, and so on, so on, so on.
> Some people come and say: NAT was very useful (more useful than many new
> IPv6 features), Please return it. We would like to have this tool too.
> The answer is "no", it is "the policy". Or else not enough incentives to
> migrate from IPv4 to IPv6 (partially true).
>
> IMHO: the market should choose what is more useful and what is less.
> People should vote by resources (money in 1st place).
> But I do not agree that NAT44 was not the resiliency solution for some
> scenarios (example: simple topology with 1 inevitable node on the path) -
> It was. It did decrease the need for universal Overlay solution.
> It reminds me the story that all important application 20+ years ago were
> running on "clustering" with full memory replication between hosts.
> Additionally, DC was designed and certified to high level of resiliency.
> Then OTT did show that is it better to assume really minimal level of
> resiliency from infrastructure. If some resiliency is needed - then it is
> the particular application problem.
> IMHO: Both approaches have their market niche (finance does still prefer
> to keep 100% resiliency on infrastructure level). The world is big enough
> for this diversity.
>
> 1. no any resilience at all for some scenarios (mostly for the cases when
> only 1 PA carrier) - applications could go through the pain of address
> change (some mechanisms are still needed to inform about address change)
> 2. NAT66 for simplified topologies - permits to preserve address on
> applications. 1 roaming Notebook or just 1 CPE in the apartment are the
> very good examples. Or any topology where 1 node is mandatory on the path
> (single CPE).
> 3. Overlay with stable address space for complex scenarios. May be even 2
> overlay solutions: optimized for roaming host and roaming router.
> I could bet that if NAT66 would be available then market niche for
> Universal Overlay solution would be at least 10x less compare to NAT66 (by
> number of IP addresses practicing this functionality).
>
> The policy "let's block NAT66" did play well to stimulate subscribers
> migration from IPv4 to IPv6. Because great majority of them are single
> attached to Carrier.
> The same policy would effectively block IPv4 to IPv6 migration for
> Enterprises, because they would not agree to deal with the complexity of
> Multi-home multi-prefix PA environment. Brian and Ole did show (in
> different RFC) "how deep is the rabbit hole".
> IMHO: no NAT66 -> no progress for IPv6 in Enterprises. Because redundant
> connectivity to Carriers is needed very often.
>
> Ed/

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 30 Nov 2020 14:48:19 +0000

True, different people are losing/winning.
Just in my opinion: complexity of MHMP on PA addresses (see RFC 7157 and RFC 8028) overweights the complexity of NAT that exist only for some applications.
Looking to it – “other people” (responsible for networking) would block IPv6 progress in enterprises. Especially if they would read above mentioned RFCs

It should be not be a problem for big Enterprises that are ready to manage their own PI addresses.
I am wondering: is it possible to migrate more Enterprises to PI addresses?
Ed/
From: Lorenzo Colitti [mailto:[email-masked]]
Sent: 30 ноября 2020 г. 15:57
To: Vasilenko Eduard <[email-masked]>
Cc: [email-masked]
Subject: Re: Is NAT66 a help in migration to IPv6?

The problem with your statement "should vote by resources" is that NAT reduces the cost of the party that deploys it (network operators) by increasing the costs of the parties that do not deploy it (app developers, OS developers). Those latter parties are the ones pushing back against NAT.

On Mon, Nov 30, 2020 at 6:40 PM Vasilenko Eduard <[email-masked]<mailto:[email-masked]>> wrote:

Ed/
> From: ipv6 [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Alexandre Petrescu
> To: [email-masked]<mailto:[email-masked]>
> > IETF IPv6 working group mailing list [email-masked]<mailto:[email-masked]> Administrative
> [email-masked]<mailto:[email-masked]>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Fernando Gont <[email-masked]>
Date: Mon, 30 Nov 2020 12:00:15 -0300

On 30/11/20 09:57, Lorenzo Colitti wrote:
> increasing the costs of the parties that do not deploy it (app 
> developers, OS developers). Those latter parties are the ones pushing 
> back against NAT.

It would seem to me that, when a host is behind a diode-like stateful 
firewall, the additional cost implied by a NAT is not significant.

For IPv4, the stateful-firewall is usually a side-effect of NAT devices, 
and hence one might associate the implied cost to "NAT".

For IPv6 (with no NAT), it is evident that the diode-like firewall has 
nothing to do with NAT -- but such policy is still very widespread; e.g. 
that's the default configuration of the CE Routers provided by my ISP.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Fernando Gont <[email-masked]>
Date: Mon, 30 Nov 2020 15:51:47 -0300

On 30/11/20 11:48, Vasilenko Eduard wrote:
[...]
> I am wondering: is it possible to migrate more Enterprises to PI addresses?

Possible? - Yes
Desirable? - ? :-)

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 1 Dec 2020 08:51:54 +1300

Answering the question in the subject field: No [RFC2993] [RFC4864] [RFC6296].

> IMHO: no NAT66 -> no progress for IPv6 in Enterprises. Because redundant connectivity to Carriers is needed very often.

It is, and that's why the failure of SHIM6 is very sad. But the real failure is the reluctance of enterprise operators to do what comes naturally in IPv6: if you have two providers, run two prefixes everywhere [RFC8028]. That's why there is still, sadly enough, a case for [RFC6296]. Sadly, because [RFC2993] explains why NAT or NPT is a problem, and [RFC4864] explains how to avoid them (and needs [RFC8028], which came very late, sorry).

Regards
   Brian Carpenter

---

From: Tom Herbert <[email-masked]>
Date: Mon, 30 Nov 2020 13:38:47 -0700

> that's the default configuration of the CE Routers provided by my ISP.
Nevertheless, the costs to hosts for dealing with stateful network
devices, like NAT and stateful firewalls, has been quite significant.
In the presence of a stateful devices we need to consider whether the
network device is going to be able to find the transport layer
information it requires (e.g. many such devices won't look past
extension headers so hosts are reluctant to use them, and of course
fragmentation is right out :-) ). Another problem is state evictions
which are especially problematic when they are timer based (hence
motifvation to send keepalives for idle connections). Yet another
problem is that stateful network devices also require consistent
routing so that packets of a flow always got through the network
device that holds the state , and if packets are routed differently
through another device then connections become unviable and are
dropped (hence we can't do anything that might cause the packet to be
routed differently). Since there's no general way for hosts to know if
their packets go through a stateful device or if they do what the are
characteristics and requirements those devices enforce, we pretty much
have to assume there is which drives the hosts to only using the least
common denominator of protocols and hence ossification of the Internet
ensues.

Back in the early days of IPv6, I remember Bob Hinden explaining that
one of the primary benefits of IPv6 was that NAT would no longer be
needed. Specifically, this would be a benefit to low powered idle
devices because they would no longer need to wake up periodically just
to send a keepalive to keep TCP connections open. I assume this is
still a benefit (maybe for TCP, but QUIC doesn't care?)

Tom

---

From: Simon Hobson <[email-masked]>
Date: Mon, 30 Nov 2020 20:56:55 +0000

> The answer is "no", it is "the policy". Or else not enough incentives to migrate from IPv4 to IPv6 (partially true).

NAT is very expensive all round. And apart from one issue, I'll be glad to see the back of it.

> The problem with your statement "should vote by resources" is that NAT reduces the cost of the party that deploys it (network operators) by increasing the costs of the parties that do not deploy it…

Indeed. But you missed out users and support - users lose when it's not working/not working right, and they lose again when they have to pay for the support call to fix whatever it is that's not working.

Fernando Gont <[email-masked]> wrote:

> It would seem to me that, when a host is behind a diode-like stateful firewall, the additional cost implied by a NAT is not significant.

Have I missed a nuance here - or are you **only** considering the cost in the router/firewall rather than the overall cost ?

> It is, and that's why the failure of SHIM6 is very sad. But the real failure is the reluctance of enterprise operators to do what comes naturally in IPv6: if you have two providers, run two prefixe…

And that's the only issue I have. I'm used to defining traffic rules based on knowledge of the available links and how I'd like different types of traffic to be split between those links. Once you run 2 (or more) prefixes to the end hosts then you have pushed that decision to the hosts - and there's no way to give the hosts the information on how I want them to route their traffic.
Granted, there is a benefit since the host (and the software running on it) has a better visibility of what the different streams are (e.g. in principle it would be possible to have a massive file transfer done over https routed down the "cheap but not as fast" link, while the interactive web browsing over https goes over the faster but more expensive link) - but unless someone can correct me, there is no mechanism other than manual configuration to do that.

So NPT as in RFC6296 does, as you say, have it's attractions - it does at least avoid most (not all) of the things in NAPT44 that break things, and it does avoid the most creative ways some vendors (like Zyxel) have of making NAPT breakage immune to workarounds.

Simon

---

From: [email-masked]
Date: Tue, 1 Dec 2020 00:11:50 +0100

> It is, and that's why the failure of SHIM6 is very sad. But the real failure is the reluctance of enterprise operators to do what comes naturally in IPv6: if you have two providers, run two prefixe…

The failure of SHIM6 or ILNP or even 8+8 is indeed sad.
MPMH hasn't exactly taken off. I ran it for a while but gave up. 8028 isn't enough, SADR is a big change.
Enterprises don't want to depend on host behaviour for exit selection.
Ref, the slaac-renum discussion I'd imagine Enterprises also wants a level of isolation from ISP/global addressing.
Keeping track of 4++ addresses per-host isn't a favourite with Enterprise network operators either.
And we can't exactly say that host implementations and applications have caught up with MPMH either.

PI or LISP MH are available solutions.
Multi-homing with NAT66 wouldn't work nearly as well (and you could argue stick with v4 then, which I guess is what they do).

Ole

---

From: Fernando Gont <[email-masked]>
Date: Tue, 1 Dec 2020 03:36:15 -0300

On 30/11/20 16:51, Brian E Carpenter wrote:
> It is, and that's why the failure of SHIM6 is very sad. But the real failure is the reluctance of enterprise operators to do what comes naturally in IPv6: if you have two providers, run two prefixes everywhere [RFC8028].

In all fairness (and sadness), I don't think RFC8028 is widespread. So, 
for all practical purposes, IPv6 multi-prefix/multi-router support is 
broken.

RFC8028 should be a MUST in the Node Reqs -- and I do mean "MUST" ;-)

I also think that there's stuff in RFC8028 that should be developed 
further or made more explicit.

Thanks,

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 1 Dec 2020 07:52:52 +0000

Hi Brian,
> Answering the question in the subject field: No [RFC2993] [RFC4864] [RFC6296].
2 RFCs are informational. 1 is experimental.
And dozens RFCs where NAT is proclaimed "never-ever" in a very strong form.

I do agree that RFC 8028 is the best from what we have for this problem now.
You said "run two prefixes everywhere" - it is not enough to explain the essence of this RFC.
One additionally should mention that it reverts the host logic: source address should be chosen first, only then next hop should be decided.
Unfortunately, I believe that RFC 8028 would fail market acceptance too. For 2 reasons:
1. As Fernando said - it is not "MUST-MUST". I would say more: it is written in the gentle language without clear recommendation to change host logic. It is possible to read only "between lines". Hence, not many people have even understood this.
2. The problem is very complex (it is not the fault of RFC 8028, just IPv6 has too much flexibility). Comparing to current situation - Enterprise admins would not agree to all this complexity.

Yes, NAT has some problems. Tom is right with his list of challenges.
But in the current satiation - it is the only way to persuade Enterprises to migrate to IPv6.
They do accustom to NAT - it is the natural path for them.

Except PI addresses that I am not sure is possible to promote properly.

PS: Any overlay would not be accepted as the mainstream solution too.

Eduard
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: 30 ноября 2020 г. 22:52
> To: Vasilenko Eduard <[email-masked]>; [email-masked]
> It is, and that's why the failure of SHIM6 is very sad. But the real failure is the
> reluctance of enterprise operators to do what comes naturally in IPv6: if you
> have two providers, run two prefixes everywhere [RFC8028]. That's why there is
> still, sadly enough, a case for [RFC6296]. Sadly, because [RFC2993] explains why
> NAT or NPT is a problem, and [RFC4864] explains how to avoid them (and needs
> [RFC8028], which came very late, sorry).
> 
> Regards
>    Brian Carpenter
> 
> > IMHO: the market should choose what is more useful and what is less. People
> should vote by resources (money in 1st place).
> scenarios (example: simple topology with 1 inevitable node on the path) - It was.
> It did decrease the need for universal Overlay solution.
> running on "clustering" with full memory replication between hosts. Additionally,
> DC was designed and certified to high level of resiliency.
> > Then OTT did show that is it better to assume really minimal level of resiliency
> from infrastructure. If some resiliency is needed - then it is the particular
> application problem.
> > IMHO: Both approaches have their market niche (finance does still prefer to
> keep 100% resiliency on infrastructure level). The world is big enough for this
> diversity.
> >
> > 1. no any resilience at all for some scenarios (mostly for the cases
> > when only 1 PA carrier) - applications could go through the pain of address
> change (some mechanisms are still needed to inform about address change) 2.
> NAT66 for simplified topologies - permits to preserve address on applications. 1
> roaming Notebook or just 1 CPE in the apartment are the very good examples.
> Or any topology where 1 node is mandatory on the path (single CPE).
> > I could bet that if NAT66 would be available then market niche for Universal
> Overlay solution would be at least 10x less compare to NAT66 (by number of IP
> addresses practicing this functionality).
> >
> > The policy "let's block NAT66" did play well to stimulate subscribers migration
> from IPv4 to IPv6. Because great majority of them are single attached to Carrier.
> > The same policy would effectively block IPv4 to IPv6 migration for Enterprises,
> because they would not agree to deal with the complexity of Multi-home multi-
> prefix PA environment. Brian and Ole did show (in different RFC) "how deep is
> the rabbit hole".
> >> Subject: Re: [v6ops] How do you solve 3GPP issue if neither operator
> >> nor handset supports PD?
> >>
> >>
> >>
> >> 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.
> >> 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.
> >>>
> >>> 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.
> >> 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.
> >>
> >> 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.
> >>
> >> 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.
> >>
> >> 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