Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info

From: Lee Howard <[email-masked]>
Date: Wed, 20 Sep 2017 11:45:17 -0400

On 9/19/17, 8:23 AM, "v6ops on behalf of JORDI PALET MARTINEZ"
<[email-masked] on behalf of [email-masked]> wrote:

>Hi all,
>
>RFC6877 (464XLAT) is an informational document.
>...
>
>Can we even consider moving it to STD?

I don’t think v6ops can promote it to Standard, or Standards Track. Our
charter doesn’t explicitly say we’re not allowed to do standards work, but
I would want to hear from our AD and check with 6man before promoting it.

Generally, the two tests are rough consensus and multiple interoperable
implementations. 

Lee

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 20 Sep 2017 12:52:47 -0300

>From my perspective, there are multiple interoperable specs. We have several CLAT client implementations/vendors, from different vendors, and they work fine in the same and different operators and interoperate with different NAT64 and DNS64 vendors/implementations.

What I’m not sure is, because 464XLAT is basically RFC6145 (SIIT) + RFC6146 (Stateful NAT64) and also can use RFC6147 (DNS64), which are already Standards track, if we need also to move them to STD in that case, etc.

I guess we may need a chapter update, but I really think should not be a problem and we must do that.

Saludos,
Jordi

-----Mensaje original-----
De: Lee Howard <[email-masked]>
Responder a: <[email-masked]>
Fecha: miércoles, 20 de septiembre de 2017, 12:45
Para: <[email-masked]>, <[email-masked]>
Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info

    

    
    Lee

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: Ole Troan <[email-masked]>
Date: Wed, 20 Sep 2017 23:44:41 +0200

> I would want to hear from our AD and check with 6man before promoting it.

6man doesn't do IPv4.

> Generally, the two tests are rough consensus and multiple interoperable

Ole

---

From: Fred Baker <[email-masked]>
Date: Wed, 20 Sep 2017 18:00:40 -0700

> On Sep 20, 2017, at 8:52 AM, JORDI PALET MARTINEZ <[email-masked]> wrote:
> 

I'll repeat myself earlier. Looking at the definitions of the terms, there is no reason it can't or shouldn't be BCP, which our charter does allow us to do, and which is a one-shot standard more appropriate to the case (IMHO). If you want it to be a standardard, a BCP is a standard. Let's advance it to BCP.

---

From: Tim Chown <[email-masked]>
Date: Thu, 21 Sep 2017 08:00:24 +0000

Hi Fred,

> On 21 Sep 2017, at 02:00, Fred Baker <[email-masked]> wrote:
> 

I think there’s an argument for this.

But there will be people who will argue that encapsulation is the ‘best’ practice.  Is there scope for a BCP by translation and a BCP by encapsulation?  Or would the BCP say NAT64/DNS64/464XLAT is the best way to serve nodes in an IPv6-only network?

With IPv4 NAT, the IETF didn’t define specific NAT mechanisms, so we ended up with many varieties, with different properties. There’s an argument also I think to nail down one single best translation approach.

Tim

---

From: Ole Troan <[email-masked]>
Date: Thu, 21 Sep 2017 10:05:01 +0200

> With IPv4 NAT, the IETF didn’t define specific NAT mechanisms, so we ended up with many varieties, with different properties. There’s an argument also I think to nail down one single best translati…

Yes, I do wonder in what alternate universe the IETF consensus is that best current practice is NAT44 -> NAT46 -> NAT64 + DNS64. ;-)

Ole

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 Sep 2017 18:13:50 +1000

In message <[email-masked]>, Ole Troan writes:
>
> >>>> From my perspective, there are multiple interoperable specs. We have
> >>>> several CLAT client implementations/vendors, from different vendors, and
> >>>> they work fine in the same and different operators and interoperate with
> >>>> different NAT64 and DNS64 vendors/implementations.
> >>>
> >>> What I’m not sure is, because 464XLAT is basically RFC6145 (SIIT) +
> >>> RFC6146 (Stateful NAT64) and also can use RFC6147 (DNS64), which are
> >>> already Standards track, if we need also to move them to STD in that
> >>> case, etc.
> >>
> >> I'll repeat myself earlier. Looking at the definitions of the terms,
> >> there is no reason it can't or shouldn't be BCP, which our charter does
> >> allow us to do, and which is a one-shot standard more appropriate to the
> >> case (IMHO). If you want it to be a standardard, a BCP is a standard.
> >> Let's advance it to BCP.
> >
> > But there will be people who will argue that encapsulation is the
> > ‘best’ practice.  Is there scope for a BCP by translation and a BCP by
> > encapsulation?  Or would the BCP say NAT64/DNS64/464XLAT is the best way
> > to serve nodes in an IPv6-only network?
> >
> > With IPv4 NAT, the IETF didn’t define specific NAT mechanisms, so we
> > ended up with many varieties, with different properties. There’s an
> > argument also I think to nail down one single best translation approach.
>
> Yes, I do wonder in what alternate universe the IETF consensus is that
> best current practice is NAT44 -> NAT46 -> NAT64 + DNS64. ;-)
>
> Ole

Hopefully not this one.  Just because there is a $billion company
doing something it doesn't make it best practice.

There is also plenty of PD-Lite out there which has none of the
side effects of NAT46 + NAT64 + DNS64.

Mar 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 21 Sep 2017 10:35:31 +0200

Mr. Baker,

With all due respect, here is my comment.

Le 21/09/2017 à 03:00, Fred Baker a écrit :
>>> From my perspective, there are multiple interoperable specs. We 
>>> have several CLAT client implementations/vendors, from different 
>>> vendors, and they work fine in the same and different operators 
>>> and interoperate with different NAT64 and DNS64 
>>> vendors/implementations.
>> 
>> What I’m not sure is, because 464XLAT is basically RFC6145 (SIIT)
>> + RFC6146 (Stateful NAT64) and also can use RFC6147 (DNS64), which 
>> are already Standards track, if we need also to move them to STD
>> in that case, etc.
> 
> there is no reason it can't or shouldn't be BCP, which our charter 
> does allow us to do, and which is a one-shot standard more 
> appropriate to the case (IMHO). If you want it to be a standardard,
> a BCP is a standard. Let's advance it to BCP.

I would not suggest making something that relies on IPv4, or an 
INFORMATIONAL 64share, a BCP.

For the 'billions' argument - it is the easiness of duplicating matters
on Computers, not about their righteousness.  One can duplicate good
things, but one can also duplicate bad things, with the same easiness.

Alex

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Sep 2017 08:39:34 +1200

> Yes, I do wonder in what alternate universe the IETF consensus is that best current practice is NAT44 -> NAT46 -> NAT64 + DNS64. ;-)

We have a problem in that people confuse "a standard" with "the standard" and
"a best current practice" with "the best current prcatice". But in the end that's
just a matter of wording in the Abstract and Introduction. We say: if you want
to run a pure IPv6 network service while supporting IPv4-only clients and servers,
and do not wish to use any form of IPv4-in-IPv6 tunnel, here is a good way to do it.

That does sound like a BCP to me.

    Brian

---

From: Ole Troan <[email-masked]>
Date: Thu, 21 Sep 2017 22:47:05 +0200

> On 21 Sep 2017, at 22:39, Brian E Carpenter <[email-masked]> wrote:
> 

Quite the contrary. 
“Do not wish to...” isn’t a qualifier for deciding if this is what the community considers best current practice. 

Rfc2026 does actually say:
The BCP subseries of the RFC series is designed to be a way to standardize practices and the results of community deliberations. A BCP document is subject to the same basic set of procedures as standards track documents and thus is a vehicle by which the IETF community can define and ratify the community's best current thinking on a statement of principle or on what is believed to be the best way to perform some operations or IETF process function.

Ole

---

From: Mark Andrews <[email-masked]>
Date: Fri, 22 Sep 2017 08:33:05 +1000

In message <[email-masked]>, Brian E Carpenter w
rites:
> have several CLAT client implementations/vendors, from different vendors,
> and they work fine in the same and different operators and interoperate
> with different NAT64 and DNS64 vendors/implementations.
> >>>>
> >>>> What Im not sure is, because 464XLAT is basically RFC6145 (SIIT) +
> >> I think theres an argument for this.
> >>
> >> But there will be people who will argue that encapsulation is the best
> practice.  Is there scope for a BCP by translation and a BCP by
> >> With IPv4 NAT, the IETF didnt define specific NAT mechanisms, so we
> ended up with many varieties, with different properties. Theres an

I'd argue it is a "way to do it".  Good is not a adjective I'd apply
to it as it has lots of side effects that impact others that are
NOT using it the same way as NAT impacts every developer that uses
IPv4.

Because 464XLAT is almost always deployed with DNS64 (there are
potentially other ways to learn the address mappings):

YOU DO NOT KNOW IF THE IPV6 CONNECTION YOU ARE MAKING IS BEING
TERMINATED ON A IPV6 NODE.  This restricts what you can do with
that connection.  This impacts on EVERY developer.

DNS64/NAT64 and 464XLAT needs to die and the earth needs to be
salted where they are buried.  They are not like NAT44 where there
no other viable alternative.  There are plenty of alternatives.

Mark

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 22 Sep 2017 06:43:57 +0200

> That does sound like a BCP to me.

I could agree if it were "ABCP" for _a_ BCP.

But I am afraid in English you cant say "a Best", there is only "one 
Best" and maybe "a Better".

WE dont say several "Bests".

You may know better, though.

Alex

---

From: Erik Kline <[email-masked]>
Date: Fri, 22 Sep 2017 14:58:15 +0900

> that connection.  This impacts on EVERY developer.

This is a good point.  Apps that connect to an IPv4-only destination
via DNS64/NAT64 won't know that they cannot, for example, pass an IPv6
address as a useful reference/token.  If they could discover/be told
the DNS64 prefix then app could figure this out for themselves, but
that is indeed unwanted complexity.

Note that with 464xlat/clat in theory this problem could be avoided in
the case where IPv4 literals are used (without a getaddrinfo trick
that returns AAAAs for IPv4 literals, of course ;-).  Nevertheless,
this isn't all that helpful.

> no other viable alternative.  There are plenty of alternatives.

We'll see if folks (specifically mobile operators--the bulk of
NAT64/DNS64 deployment) deploy DS-Lite or MAP-E...

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 22 Sep 2017 15:17:45 +0900

On Fri, Sep 22, 2017 at 7:33 AM, Mark Andrews <[email-masked]> wrote:

> TERMINATED ON A IPV6 NODE.
>

Why don't you? All you need to do is compare the destination address with
the NAT64 prefix. If it's in that prefix, then it's an IPv4 node, otherwise
it's an IPv6 node.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 22 Sep 2017 17:07:19 +1000

> the NAT64 prefix. If it's in that prefix, then it's an IPv4 node, otherwise

Thank you for proving my point.

IPv6 applications need to add code to WORKAROUND breakages caused
by NAT64 the way they need add WORKAROUNDS for the NAT breakages
even if they are not using NAT64 or NAT respectively.  The cancer
that is NAT64 needs to be eradicated.

Mark

---

From: Erik Kline <[email-masked]>
Date: Fri, 22 Sep 2017 16:09:10 +0900

> that is NAT64 needs to be eradicated.

Sounds more like the cancer that is IPv4 is what needs eradicating...

---

From: Ole Troan <[email-masked]>
Date: Fri, 22 Sep 2017 09:22:15 +0200

> no other viable alternative.  There are plenty of alternatives.

From the perspective of forcing every IPv6 application to have to be able to deal with connecting to an IPv4 endpoint.
Breaking DNSSEC.
Requiring stateful devices in the network.

I would suggest this belongs in the newly invented document category: WCP - Worst Current Practice.

Ole

---

From: Gert Doering <[email-masked]>
Date: Fri, 22 Sep 2017 13:48:47 +0200

Hi,

> that is NAT64 needs to be eradicated.

It will nicely go away if all endpoints are reachable over v6.

Please make that happen!

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Ole Troan <[email-masked]>
Date: Fri, 22 Sep 2017 14:17:55 +0200

Gerd,

> On 22 Sep 2017, at 13:48, Gert Doering <[email-masked]> wrote:
> 
> Hi,
> 

I think that’s the concern. That it will not. 
IPv6 applications will have code to accommodate for NAT64 forever. 

Of course that’s slightly tangential to 464xlat which is just a poor IPv4 over IPv6 tunnel with null encap and session state. 

Ole

---

From: Gert Doering <[email-masked]>
Date: Fri, 22 Sep 2017 14:21:46 +0200

Hi,

On Fri, Sep 22, 2017 at 02:17:55PM +0200, Ole Troan wrote:
> I think that?fs the concern. That it will not. 

Yeah, but you can't have the cake and eat it.  Either we go v6-only
everywhere, or we keep running IPv4 everywhere until everybody else
is done, or we introduce v4/v6 NATs, or we add a CLAT to every single
operating system out there.

What's it gonna be, boys?

(Oh, "or we give up, roll back existing v6 deployments, and live happy
with v4 nat forever".  FAR less work, and for Joe Average User, it won't
make a difference.  Facebook and Youtube will continue to work, and
their IoT devices will keep drilling holes into firewalls to ensure that
they can be exploited no matter what)

Gert Doering
        -- NetMaster

---

From: Ole Troan <[email-masked]>
Date: Fri, 22 Sep 2017 14:26:03 +0200

s/d/t. Sorry. 

> On 22 Sep 2017, at 14:17, Ole Troan <[email-masked]> wrote:
> 
> Gerd,
>

---

From: Philip Homburg <[email-masked]>
Date: Fri, 22 Sep 2017 14:44:50 +0200

>operating system out there.

You left out the option where the CPE or other first hop router offers native
IPv4 to the host (probably involving some kind of IPv4 NAT, but that is
more or less standard these days) and tunnels the complete IPv4 packet to
the network's IPv4 gateway.

This avoid all of the NAT64/DNS64 problems.

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Fri, 22 Sep 2017 12:45:10 +0000

I don't think that there any iOS app that is not IPv6-only compatible (since the apple AppStore mandate more than a year* ago). Is there one ?

If Google playstore could mandate something similar (perhaps, there is one that I am not aware of), then almost all mobile UEs can happily live with v6-only without any Clat function.  Better battery life, likely.

Hence, There is no need for XLAT being a BCP at this time in that regard.

Of course, NAT64 inside the network would still be needed to accommodate the smaller  (% of traffic) v4-only internet connectivity. But that's an ongoing saga of another debate.

However, there is one exception - tethering :: if mobile UE is tethered and the other devices connecting to its W/LAN are stuck in legacy v4-only, then mobile ISPs might prefer to not leave them behind to ensure customer experience. What "technical" options do we have then? Well, really two == Let go of v6-only access (provide an IPv4-only APN if tethering is enabled resulting in a dual-stack UE) or stick with v6-only access, but turn on CLAT function !!

Cheers,
Rajiv

* https://developer.apple.com/support/ipv6/

On Sep 22, 2017, at 8:22 AM, Gert Doering <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

On 22 Sep 2017, at 13:48, Gert Doering <[email-masked]<mailto:[email-masked]>> wrote:

Gert Doering
       -- NetMaster

[email-masked]<mailto:[email-masked]>

---

From: Gert Doering <[email-masked]>
Date: Fri, 22 Sep 2017 14:46:41 +0200

Hi,

> This avoid all of the NAT64/DNS64 problems.

And why is that a desirable end goal, cement IPv4 in everybody's home
networks?

Either the goal is "get rid on IPv4 on as many cables as we can" or we
can just give up and interconnect IPv4 clouds over NAT gateways, using 
whatever underlay in between - MPLS, IPv6, IPv4, it will not matter.

Gert Doering
        -- NetMaster

---

From: Philip Homburg <[email-masked]>
Date: Fri, 22 Sep 2017 14:57:45 +0200

>can just give up and interconnect IPv4 clouds over NAT gateways, using=20

I'm perfectly fine with not offering any kind of IPv4 all. Literally, offering
no connection at all to the IPv4 internet.

What I'm not okay with is pretending that NAT64/DNS64 is a good thing for
the internet. If you want to offer some kind of tunneled IPv4, offer a
tunnel that preserves IPv4 headers and terminate it at the first hop router.

Forcing hosts to deal with NAT64 only serves to decrease the overal
reliability of the internet. Terminating NAT64 in a CPE is also bad, but not
quite as bad as requiring hosts to deal with NAT64.

---

From: Ca By <[email-masked]>
Date: Fri, 22 Sep 2017 13:07:34 +0000

On Fri, Sep 22, 2017 at 5:45 AM Rajiv Asati (rajiva) <[email-masked]>
wrote:

>
> I don't think that there any iOS app that is not IPv6-only compatible
> (since the apple AppStore mandate more than a year* ago). Is there one ?
>

I am simply here to disabuse you of the notion that this rule has been
perfect for the folks involved.

> If Google playstore could mandate something similar (perhaps, there is one
> that I am not aware of), then almost all mobile UEs can happily live with v6-only
> without any Clat function.  Better battery life, likely.
>

Fully agree. What if Google playstore cannot / will not enforce such a rule
?  We in v6ops / sunset4  are well aware that asking for a poney seldom
results in a poney .... hence warty solutions that thread one needle to
move another needle. Putting the E back into IETF.

> Of course, NAT64 inside the network would still be needed to accommodate
> the smaller  (% of traffic) v4-only internet connectivity. But that's an
> ongoing saga of another debate.
>
>
>
> However, there is one exception - tethering ::
>

Ah. What little control we have.

if mobile UE is tethered and the other devices connecting to its W/LAN are
> stuck in legacy v4-only, then mobile ISPs might prefer to not leave them
> behind to ensure customer experience. What "technical" options do we have
> then? Well, really two == Let go of v6-only access (provide an IPv4-only
> APN if tethering is enabled resulting in a dual-stack UE) or stick with
> v6-only access, but turn on CLAT function !!
>
> Cheers,
> Rajiv
>
>
> On Sep 22, 2017, at 8:22 AM, Gert Doering <[email-masked]> wrote:
>
> Hi,
>
>
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 22 Sep 2017 10:47:20 -0300

And the issue is that you’re talking only about the cellular networks, but we have the same issue with the residential ones … and the corporates that only use the network to “browse” (not to expose services outside).

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de "Rajiv Asati (rajiva)" <[email-masked]>
Responder a: <[email-masked]>
Fecha: viernes, 22 de septiembre de 2017, 9:45
Para: Gert Doering <[email-masked]>
CC: "[email-masked] WG" <[email-masked]>
Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info

    If Google playstore could mandate something similar (perhaps, there is one that I am not aware of), then almost all mobile UEs can happily live with v6-only without any Clat function.  Better
     battery life, likely. 

    

    However, there is one exception - tethering :: if mobile UE is tethered and the other devices connecting to its W/LAN are stuck in legacy v4-only, then mobile ISPs might prefer to not leave them behind to ensure customer experience. What "technical" options
     do we have then? Well, really two == Let go of v6-only access (provide an IPv4-only APN if tethering is enabled resulting in a dual-stack UE) or stick with v6-only access, but turn on CLAT function !!

    Cheers,
    Rajiv 

    

    
    Hi,

    

    

    

    

    

    

    

    

    

    

    

    

    

    
    Gert Doering
           -- NetMaster

---

From: Tim Chown <[email-masked]>
Date: Fri, 22 Sep 2017 13:59:31 +0000

> On 22 Sep 2017, at 08:22, Ole Troan <[email-masked]> wrote:
> 

I like that.  We could tag quite a few RFCs/protocols as WCP.  Starting with IPv4.

Tim

---

From: Lee Howard <[email-masked]>
Date: Fri, 22 Sep 2017 10:52:10 -0400

Speaking as participant, not as cochair.

>> It will nicely go away if all endpoints are reachable over v6.

How many significant digits in “all”?
90%? 99%? 99.9%? 99.999%?
Somewhere in there the engineering tradeoffs start looking different.

>IPv6 applications will have code to accommodate for NAT64 forever.

How many significant digits in “forever”?

I ask because if an app developer is 99.xx% sure that 99.xx% of users will
be on IPv6-enabled devices and networks, then they can remove any
compensation for IPv4.

Enough years have passed that “forever” isn’t as far off as it used to be.
Following adoption curves:
 The majority of hits on Google US will be IPv6 in six months.
 80% of hits on Google US will be IPv6 in two and a half years.
 90% of hits on Google US will be IPv6 in three and a half years.
 The majority of hits on Google worldwide will be IPv6 in two years.
 80% of hits on Google worldwide will be IPv6 in four years.
 90% of hits on Google worldwide will be IPv6 in five years.
https://www.vyncke.org/ipv6status/project.php?metric=p&timeforward=2000&tim
ebackward=2064&country=ww

In IETF time scales, we are about to be overtaken by events. Predicting
based on a logistic curve is tricky, but 99% IPv6 is within most of our
career lifetimes.

How rare does a case have to be before you can decide not to handle it?

For that matter, how rare does a case have to be before a network operator
decides it’s marginal and can be either outsourced or ignored? Asking for
a friend.

Lee

---

From: Gert Doering <[email-masked]>
Date: Fri, 22 Sep 2017 18:10:18 +0200

Hi,

> ebackward=2064&country=ww

I like your optimism :-)

But then, I look at mobile operators in Germany - the *incumbent* has 
done their homework and is providing IPv6, but the "new kids on the block"
mobile operators (like, "younger, agile", and all this) are not even having 
*plans* for IPv6 yet...

And this is only eyeball networks.

Right now, there's so much *content* IPv4-only that eyeball networks need
to put up CGN boxes to enable reachability to that content - and if these
boxes are in place anyway, what incentives does content have to enable
IPv6?  Looking at the Alexa Top sites, I see lots of red on Eric's 
page.  Basically, everything that's not Google or happens to sit behind
Cloudflare (for DE)... :-(

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Fri, 22 Sep 2017 18:13:37 +0200

Hi,

> Cloudflare (for DE)... :-(

Oh.  As a side note, "a fried" tells me that a major audio streaming
platform in DE had to turn off IPv6, because Samsung.

"If we listen to the stream over IPv4, and the phone goes to sleep, the
stream will continue playing.  If we listen over IPv6 and the phone goes
to sleep, it will stop".

Since there is no way to get Samsung to fix their shit (like, Google,
having proper requirements for Android vendors...) the radio station
decided that it's not worth the hassle and just turned off IPv6 again -
much less work than building something into their platforms that redirects
broken clients to an IPv4-only site and keeps IPv6 for the rest.

And stories like this is why I'm not overly optimistic anymore, after
barely 20 years of advocating IPv6.

Gert Doering
        -- NetMaster

---

From: Lee Howard <[email-masked]>
Date: Fri, 22 Sep 2017 13:55:24 -0400

As to the original question, I have a couple of questions:

1. What is gained by promoting rfc6877 "464XLAT: Combination of Stateful
and Stateless Translation”?  Regardless of whether the correct promotion
path is BCP or Proposed Standard, what is the goal?

2. rfc2026 “The Internet Standards Process”  says a BCP is the "best
current thinking on a statement of principle or on what is believed to be
the best way to perform some operations.”  What principle or what
operations is 464xlat best for?

The chairs are working out how to handle this request, and answers to
these questions will help us.

Thanks,

Lee

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 22 Sep 2017 15:22:35 -0300

Hi Lee,

See below in-line.

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Lee Howard <[email-masked]>
Responder a: <[email-masked]>
Fecha: viernes, 22 de septiembre de 2017, 14:56
Para: Lee Howard <[email-masked]>
CC: "[email-masked] WG" <[email-masked]>
Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info

[Jordi] My point is: I understand that when 464XLAT was proposed, it was not considered at the same level as other transition mechanisms, which are, from the start, standards track. Now that this is the most successful (in terms of number of users vs. all the other transition mechanisms), in my opinion there is no reason to discriminate it. So, either we drop to informational all the transition mechanisms that have so much lower degree of success or even to historic or deprecated those that are not used. Is a matter of fairness and recognize the reality.

[Jordi] Well, I was suggesting standards track, not BCP. So not sure how to read this question myself. Actually, I’ve drafted already (started two months ago, and not related at all to this discussion, but for lack of time availability, haven’t completed it yet, hopefully can have it early next week) a BCP which initially I’ve titled “464XLAT Deployment Guidelines in Operator Networks”. The idea come out after we had the discussion of deploying at the IETF network 464XLAT instead of just NAT64. In this document I’m describing how, according to my experience (and hopefully inputs from others once a first version is published), 464XLAT is being deployed in both cellular and non-cellular networks.

    Thanks,
    
    Lee

---

From: Gert Doering <[email-masked]>
Date: Fri, 22 Sep 2017 20:29:09 +0200

Hi,

coming back from my old man's rant (apologies) to the original question...

On Fri, Sep 22, 2017 at 01:55:24PM -0400, Lee Howard wrote:
> and Stateless Translation????  Regardless of whether the correct promotion

I do not think much is to be gained.  Implementations already exist,
so pointing to a BCP and asking vendors to "you want this, it's BCP!"
(or "Standard") isn't going to change much.  CPE vendors will add 
it if you wave money at them, and not otherwise, no matter what label
it carries.

> 2. rfc2026 ???The Internet Standards Process???  says a BCP is the "best
> the best way to perform some operations.???  What principle or what

464xlat is one possible approaches to enabling IPv4-to-IPv4 connections
across an IPv6-only network that provides NAT64 services and no tunneling
services.  So if you have a NAT64 / IPv6-only network already and have 
to care for IPv4-only applications, this might be the best approach.

If you need to transport IPv4 across an IPv6-only network and do not yet
have a NAT64 to use, one of the MAP-E/MAP-T stateless "transport" variants 
might be a *better* solution, given the statelessness of the MAP gateway.

So it depends on your network: if you want "IPv6-mostly" with a bit of
remaining external IPv4 to be handled by the DNS64/NAT64, and a few stubborn
applications insisting on literal IPv4 on the client side, 464xlat is
"best".  Otherwise, maybe not "WCP", but definitely just "one solution in
the toolchest"

Gert Doering
        -- NetMaster

---

From: Lee Howard <[email-masked]>
Date: Fri, 22 Sep 2017 14:48:44 -0400

On 9/22/17, 2:22 PM, "v6ops on behalf of JORDI PALET MARTINEZ"
<[email-masked] on behalf of [email-masked]> wrote:

>[Jordi] My point is: I understand that when 464XLAT was proposed, it was
>not considered at the same level as other transition mechanisms, which
>are, from the start, standards track. Now that this is the most
>successful (in terms of number of users vs. all the other transition
>mechanisms), in my opinion there is no reason to discriminate it. So,
>either we drop to informational all the transition mechanisms that have
>so much lower degree of success or even to historic or deprecated those
>that are not used. Is a matter of fairness and recognize the reality.

Well, rfc6877 doesn’t define a new protocol, it describes a way that
existing technologies could meet a need. I’m trying to read it as a
Technical Specification as defined by rfc2026, and I don’t see how it fits.

Who is discriminating against the most successful mechanism based on its
document track?

>[Jordi] Well, I was suggesting standards track, not BCP. So not sure how
>to read this question myself. Actually, I’ve drafted already (started two
>months ago, and not related at all to this discussion, but for lack of
>time availability, haven’t completed it yet, hopefully can have it early
>next week) a BCP which initially I’ve titled “464XLAT Deployment
>Guidelines in Operator Networks”. The idea come out after we had the
>discussion of deploying at the IETF network 464XLAT instead of just
>NAT64. In this document I’m describing how, according to my experience
>(and hopefully inputs from others once a first version is published),
>464XLAT is being deployed in both cellular and non-cellular networks.

Maybe I should have also asked the question, “How does rfc6877 meet the
standard of an Internet Standard according to rfc2026?”

Lee

---

From: Lee Howard <[email-masked]>
Date: Fri, 22 Sep 2017 16:23:24 -0400

>> ebackward=2064&country=ww

It’s evergreen.

>mobile operators (like, "younger, agile", and all this) are not even

I wonder if 5G will include native IPv4.

Because I was replying to this message, I paused to publish this blog post
about who would have the most impact on IPv6 deployment. It’s specific to
the US (because worldwide numbers aren’t readily available) but it could
be repeated for any other country.
http://www.wleecoyote.com/blog/whomatters.htm

In Germany, you’re looking for Vodafone, TDDE Telefonica, Digital Ocean,
EWE, MNET, Linode, Telecolobus, and O2. Then it’s a long tail of smaller
networks. I just ran the numbers, and 76% of Germans without IPv6 are
behind Liberty Global, Kabel Deustchland, Telefonica, Deutsche Telekom,
and Vodafone. Since DTAG, KD, and LGI have great deployments, I checked:
Telefonica alone has 26% of IPv6-incapable users, and Vodafone 16%.

Network Size		Pct of IPv6-incapable Germans

  100K-1M			76%

  10K-100K		16%

  1K-10K			6%

  <1K			2%

>Cloudflare (for DE)... :-(

If 99% of eyeball hardware runs IPv6, then we look more to NAT64 than to
464xlat. And in the U.S., (according to that blog post), AWS and Akamai
operate about 25% of the IPv6-incapable domains in the Top 1000.

I don’t mean to say that we don’t need transition mechanisms. Transition
mechanisms are the way networks can move to IPv6-only [1] at different
rates.

Lee

[1] For low values of “only"

---

From: Mark Andrews <[email-masked]>
Date: Sat, 23 Sep 2017 07:25:02 +1000

In message <[email-masked]>, Gert Doering writes:
> > >=20
> >=20
> > I think that?fs the concern. That it will not.=20
> > IPv6 applications will have code to accommodate for NAT64 forever.=20
> 
 
Or we use any of the *other* IPv4 as a service technologies that
are standards track.  Some of which are actually being used in
broadband deployments today to deliver IPv4 as a service with IPv6
only access networks.

	DS-Lite (RFC 6333 - Category: Standards Track)
	MAP-E   (RFC 7597 - Category: Standards Track)

CLAT is not needed.  DNS64 is not needed.  NAT64 is not needed.

> they can be exploited no matter what)

Stop exaggerating.  Google went and added CLAT to the Android.  They
can just as easily add DS-Lite to Android and we would have billions
of machines that support DS-Lite.  Just because NAT64 and 464XLAT are
sexy doesn't mean that it is good technology.

Mark

> --=20
> --pfqPuNG9QX5dciZ9
> Content-Type: application/pgp-signature; name="signature.asc"
> 
> -----BEGIN PGP SIGNATURE-----
> 
> iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlnFAFgACgkQ31bAZeTO
> f8WrRw//a3xZjAzhiK5hI9m0mFG4QVJ/bKf8keSjulE0YGdw+1eE2PoAmgdZTYKT
> vl2poBV98UnVRpn6OMru+kObCXI7OHY1zZmoqtBboCuqYYofA9rjN4SGdwn7Uagi
> RtuTBGWm4AjMzQuHzz1if6QZab1sbnh9yKUxBYwAofqVlkOMm166SUGnoYwhixuC
> /LIgUj53vVC67rPt+fi/UJaFS1Iu1FwaAPHS5vIexDfx8gDsGhfdQGw6OD4x5R9e
> zU2Apx88O7cEV3xQbgINzBXF6JOGGq06P8t40Ln5WUv1BnrrGuifY3j4MxogGOpy
> QMLskUMDYbfIg2OrFsaGSYBeuKFgP6f65ZjC2iKXNbqbbDy750/eiw/yp9KVCAoJ
> fixd1c6itOZsBjZgCZEKmsU9MDhnD5cS3CX0c+I49k3IEHpdNfqk8bB+x6zKraRx
> iTkWuL3okFFca7JBPZNgdNyTDmteSF0086+yCKkcTOa3XohYCYtjyBMon2dEKCfl
> AkmYHFoxvMfx20PUGZdkwWJyI+WiM4mDm+F2KiPMO/RWcMfZNj0ZuG4948PH6WhJ
> ei+yxJAeUPoMnqeSV+CQJrwRSSfm60YbFckocGZ7/4CuA5dmOc9U+KPyERyn7xid
> hYBeJhoBSdxWA6jx1CTjlCPga5HVpbdDfMkmXSXkUNzRpA6aDrk=
> =u0No
> -----END PGP SIGNATURE-----
> 
> --pfqPuNG9QX5dciZ9--

---

From: Gert Doering <[email-masked]>
Date: Fri, 22 Sep 2017 23:27:46 +0200

Hi,

> sexy doesn't mean that it is good technology.

The goal cannot be to add more stateful machinery in the network, so
DS-Lite has a good place in the WCP hall of shame.

Gert Doering
        -- NetMaster

---

From: Mark Andrews <[email-masked]>
Date: Sat, 23 Sep 2017 07:36:55 +1000

> whatever underlay in between - MPLS, IPv6, IPv4, it will not matter.

DS-Lite is a CPE or node based solution like CLAT is a CPE or node
based solution.  Both can be used in either mode.

Mark

> --Ew9mJ7yfAEtQK+FR
> iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlnFBjAACgkQ31bAZeTO
> f8WEXRAAjzTZM76c193jz+DwbAO8aeHr/r2iA3wYqO7aG6PEGcRjZ9WKxhuizzgG
> +QyidLcLrL/RmO3S+Y4PjDR1ZuTCSDriZvBBV/cd5IN0LDcpQ6zoUQ4pvFx4tMkH
> owq9lzZrqyJasVRGTB6hT1MrB5HfKolbg/oTnTYYLBnIzgpGeKzly0gJ3AaZhCp4
> bK+xjBVmO+F2DGRp1Ix2CzfeVVevssyZLfwHGurRIQYkrVtUXXgbmMLfwR6zRIH+
> bxCpw5QCQJd77SWQ12NquGLHZSGu9VUI3PFh/thW+/PD3WQhWg6eVcRj3jVFtyGp
> MkV9viTc17jme/+bLmNcd07BSV4HxtMe+OQquodfSHmhohEsYZ8kdmeTunMFDv9i
> RBN3DKZ5i9+PxS6zQRi+wwCBFnRVQCAPred05MKYUQCsehPpKPutprZhq0nYt93B
> Tz9RGqxcXzQwFB+r4AzQFYN46vwjBbisH5VHEdPk3TZs93cNV/9LZQn+mhgegY++
> 9OWTq4gyWXN2OOtG+gwXrrdhh/9TCtcdyF+pTEviPo4AQSE0575w0AlFyr4nqbPU
> 0HjQpxTV/3BciKjSxVveWctZqiqi3Gr5Xyr0S1oUxf/u7Jnz0KscF0ovU9Nwr6Pa
> qycT8vF0y2dMztIg0jHPC8q8Ev5i2QOM72WI4y+KjBRtieDKy9M=
> =XZ+h
> --Ew9mJ7yfAEtQK+FR--

---

From: Mark Andrews <[email-masked]>
Date: Sat, 23 Sep 2017 07:51:56 +1000

> > However, there is one exception - tethering ::

DS-Lite accomodates tethering.  It's in millions of broadband CPE devices
today 'tethering' the home IPv4 network to the rest of the world over IPv6
access networks.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 23 Sep 2017 10:50:09 +1200

> I would suggest this belongs in the newly invented document category: WCP - Worst Current Practice.

How about Best Current Practice for the Worst Current Solution?

I have never advocated v4/v6 translation. I said it was a bad thing
before IPv6 was even designed: https://tools.ietf.org/html/rfc1671#page-3

But we're apparently stuck with it.

    Brian

---

From: Erik Kline <[email-masked]>
Date: Sat, 23 Sep 2017 09:14:05 +0900

> broken clients to an IPv4-only site and keeps IPv6 for the rest.

A compliance test suite (CTS) test case was added to catch and prevent
this behaviour, in the Marshmallow time frame.

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 23 Sep 2017 14:08:05 +0200

Le 23/09/2017 à 00:50, Brian E Carpenter a écrit :
>>>> We have a problem in that people confuse "a standard" with "the
>>>> standard" and "a best current practice" with "the best current
>>>> prcatice". But in the end that's just a matter of wording in
>>>> the Abstract and Introduction. We say: if you want to run a
>>>> pure IPv6 network service while supporting IPv4-only clients
>>>> and servers, and do not wish to use any form of IPv4-in-IPv6
>>>> tunnel, here is a good way to do it.
>>> 
>>> I'd argue it is a "way to do it".  Good is not a adjective I'd
>>> apply to it as it has lots of side effects that impact others
>>> that are NOT using it the same way as NAT impacts every developer
>>> that uses IPv4.
>>> 
>>> salted where they are buried.  They are not like NAT44 where
>>> there no other viable alternative.  There are plenty of
>>> alternatives.
>> 
>> From the perspective of forcing every IPv6 application to have to
>> be able to deal with connecting to an IPv4 endpoint. Breaking
>> DNSSEC. Requiring stateful devices in the network.
>> 
> before IPv6 was even designed:
> https://tools.ietf.org/html/rfc1671#page-3

Maybe RFC1671 page 3 bullet "C" is a BCP.

> But we're apparently stuck with it [tunn/translate/DNS transitioning
> mechanisms].

Yet a common denominator among Current Practices of transitioninig is:
double stack.

A smartphone runs ok native IPv4 and native IPv6 simultaneously, without
needing translations nor encapsulations nor DNS v6-v4 mappings.

Is double stack BCP?

A few RFCs mentioning "dual stack" seem to be on StdsTrack (not BCP).
They seem all to involve some tunnelling or translation.

But double stack, understood as coexisting simultaneous use of IPv4 and
IPv6 independently, on the same Computer, without tunnelling, nor
translation, nor DNSv46 - could very well be a BCP.

Alex

---

From: Gert Doering <[email-masked]>
Date: Sun, 24 Sep 2017 19:50:47 +0200

Hi,

> > stream will continue playing.  If we listen over IPv6 and the phone goes
[..]
> this behaviour, in the Marshmallow time frame.

This is great news, and thanks for it.

Now, how can we get all those vendors with a big S to ship Android
upgrades for their phones on the market?

(We'd *really* like bring back this host to the IPv6 world... and we
can't while the market share of unfixed devices is still so high.  So 
maybe in a year or so...)

Gert Doering
        -- NetMaster

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 25 Sep 2017 10:33:19 +0900

On Sat, Sep 23, 2017 at 1:13 AM, Gert Doering <[email-masked]> wrote:

> having proper requirements for Android vendors...)

We actually do have a conformance test for this (but it only affects
devices on Android M or later). If you find devices that fail this test,
please let us know.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 25 Sep 2017 10:36:04 +0900

> maybe in a year or so...)

Can the radio station hand off to dual-stack URLs for working devices and
to IPv4-only URLs for broken devices? For example, based on user-agent?

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 25 Sep 2017 10:54:40 +0900

> sexy doesn't mean that it is good technology.

We added 464xlat to Android because there were credible deployment plans in
place for 464xlat on real networks that Android devices connect to. In
hindsight, we were right, as 464xlat went from credible plan to successful
deployment with an installed base in the tens of millions.

I personally think that if we had not done this, we wouldn't have IPv6-only
mobile networks today and we'd all still be lamenting the chicken and egg
problem for IPv6-only networks. Getting rid of IPv4 in the network is a
great step forward, and as Apple has shown, once that's happened, host OSes
can start removing IPv4 access from applications, too. (And make no
mistake: without 464xlat, those networks would *not* have gone IPv6-only,
and it would have been much harder, or even impossible, for Apple to say
that apps must operate in IPv6-only environments, because there would have
been no such environments.)

DS-Lite has no such credible deployment plans in place. Wifi networks are
going to provide IPv4 for many years. Mobile networks were never going to
deploy DS-Lite because the encapsulation would have broken their billing
platforms. And so, here we are.

We'll all get to IPv6-only eventually, and some time after that, we'll get
rid of IPv4. At that time, you can salt the earth over 464xlat if you want.
But until then, I wouldn't be too eager to bash 464xlat as a technology. It
was the right thing to do at the time.

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 25 Sep 2017 02:03:36 +0000

Pls see inline,

> On Sep 23, 2017, at 3:23 AM, Mark Andrews <[email-masked]> wrote:
> 
> 
> DS-Lite accomodates tethering.  

So do 464XLAT, MAP-T/E etc. i agree. 
However, the point was that CLAT function wouldn't be needed unless tethering was enabled (assuming apps were v6 compatible). 

Cheers,
Rajiv

> It's in millions of broadband CPE devices

---

From: Lee Howard <[email-masked]>
Date: Sun, 24 Sep 2017 16:45:37 -0400

Personal opinion...

Sent from my iPhone

> On Sep 23, 2017, at 8:08 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
> 
>> 
> 

Dual stack doesn't solve the problem IPv6 was created to solve, which is the lack of available IPv4 addresses. 

> translation, nor DNSv46 - could very well be a BCP.

At best it could be a Brief Current Practice on the way to IPv6 only. In most cases there will be another step: IPv6 plus translation. 

There's no single best way to manage IPv4 exhaustion. It's stinks, and is going to stink more. 

Lee

---

From: Gert Doering <[email-masked]>
Date: Mon, 25 Sep 2017 09:07:59 +0200

Hi,

> to IPv4-only URLs for broken devices? For example, based on user-agent?

It could.  

But someone would have to write and test said code, and test across a wide
enough range of handsets.  But everybody is already busy trying to keep the 
service and network itself up and running.  So the decision was "turn off 
IPv6, it's not making money but causing problems. revisit this later"...

With the new information ("newer S* devices might have this fixed"), I can
address the topic again, and then see what will happen.

Gert Doering
        -- NetMaster

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 25 Sep 2017 10:19:53 +0200

Le 24/09/2017 à 22:45, Lee Howard a écrit :
>> Yet a common denominator among Current Practices of transitioninig
>> is: double stack.
>> 
>> A smartphone runs ok native IPv4 and native IPv6 simultaneously,
>> without needing translations nor encapsulations nor DNS v6-v4
>> mappings.
>> 
>> Is double stack BCP?
> 

I agree.  However, during a transition time it is perfectly fine to use 
double stack (i.e. dual stack without tunnelling, nor translation nor IN 
A carried by IPv6 messages).

It may be a widely used method nobody talks about.

It may also be that we do speculate too much on IPv6-only cellular 
networks.  We speculate these are there now, whereas I may  speculate it 
may not really be the case.  There are some networks that are 
IPv6-only-to-end-user yet use GTP-IPv4.

In these networks, if there is GTP-IPv4, there could also be a DNSv4 and 
a NAT.

Actually, from where I look, I see many 'double stack' networks like these.

>> A few RFCs mentioning "dual stack" seem to be on StdsTrack (not
>> BCP). They seem all to involve some tunnelling or translation.
>> 
>> But double stack, understood as coexisting simultaneous use of IPv4
>> and IPv6 independently, on the same Computer, without tunnelling,
>> nor translation, nor DNSv46 - could very well be a BCP.
> 
> At best it could be a Brief Current Practice on the way to IPv6 only.

:-) I like that.

> In most cases there will be another step: IPv6 plus translation.

IPv6-IPv4 translations are evil.

> and is going to stink more.

:-) I can agree to that

Alex

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 25 Sep 2017 10:28:33 +0200 (CEST)

> IPv6-only-to-end-user yet use GTP-IPv4.

Are you saying that people from for instance T-Mobile USA saying they're 
doing IPv6 only GTP (and checking peoples phones the settings are IPv6 and 
not IPv4v6), are lying?

What do you mean by GTP-IPV4? We're talking about what access service is 
provided to the customers, and there are several that do IPv6 only GTP. 
Yes, the GTP packets might be carried over IPv4, but the SERVICE provided 
to the customer is IPv6 only.

> Actually, from where I look, I see many 'double stack' networks like 

There are plenty of examples of IPv4 only, IPv6 only, and IPv4v6 mobile 
access networks. It's all being done. What the provider chooses to do 
often has to do with their equipment vendor supports and how many IPv4 
addresses they might have. Also operational practices and preferences.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Kossut Tomasz - Hurt <[email-masked]>
Date: Mon, 25 Sep 2017 09:05:12 +0000

Hi,
True ! 464xlat enabled IPv6 transition for mobile networks. Thank you ! In IPv6-only network you can expect up to 60% native IPv6
Cheers,
TK

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Monday, September 25, 2017 3:55 AM
To: Mark Andrews
Cc: Gert Doering; [email-masked] WG
Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info

On Sat, Sep 23, 2017 at 6:25 AM, Mark Andrews <[email-masked]<mailto:[email-masked]>> wrote:

We added 464xlat to Android because there were credible deployment plans in place for 464xlat on real networks that Android devices connect to. In hindsight, we were right, as 464xlat went from credible plan to successful deployment with an installed base in the tens of millions.

I personally think that if we had not done this, we wouldn't have IPv6-only mobile networks today and we'd all still be lamenting the chicken and egg problem for IPv6-only networks. Getting rid of IPv4 in the network is a great step forward, and as Apple has shown, once that's happened, host OSes can start removing IPv4 access from applications, too. (And make no mistake: without 464xlat, those networks would *not* have gone IPv6-only, and it would have been much harder, or even impossible, for Apple to say that apps must operate in IPv6-only environments, because there would have been no such environments.)

DS-Lite has no such credible deployment plans in place. Wifi networks are going to provide IPv4 for many years. Mobile networks were never going to deploy DS-Lite because the encapsulation would have broken their billing platforms. And so, here we are.

We'll all get to IPv6-only eventually, and some time after that, we'll get rid of IPv4. At that time, you can salt the earth over 464xlat if you want. But until then, I wouldn't be too eager to bash 464xlat as a technology. It was the right thing to do at the time.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 25 Sep 2017 11:19:08 +0200

Response in-line

Saludos,
Jordi

-----Mensaje original-----
De: Lee Howard <[email-masked]>
Responder a: <[email-masked]>
Fecha: viernes, 22 de septiembre de 2017, 20:48
Para: <[email-masked]>, "[email-masked] WG" <[email-masked]>
Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info

    

[Jordi] We (IETF) are discriminating among different transition technologies. I understand that is not a new protocol, but I’m sure we can spend some time in investigating other standards track documents that are not actually “protocols” per se … just ways to do it. Unfortunately, may operators in the market don’t know all those “details” about the distinction in between an informational, a BCP, etc., so having “other” transition technologies as non-info and this one as info, makes a difference and I’ve heard this from several people the last weeks (also previously, but I refer to this period because last weeks, I’ve been in 3 different continents with people from many different countries).

You can read 4.2.2  Informational

   An "Informational" specification is published for the general
   information of the Internet community, and does not represent an
   Internet community consensus or recommendation.

Which clearly states “general information, does not represent an Internet community consensus” … which is not true in the sense that 464XLAT required consensus to be accepted and published, right? A reader that didn’t followed the process don't know the details.

[Jordi] It seems to me (unless missing something) that we are reading RFC2026 as if only a new “protocol” can be actually a standard (not discussing here what degree of maturity, as that discussion will be only relevant if first we accept that 464XLAT can be reclassified to that), which is not correct “”. To get 464XLAT working you actually need to implement code in both, the devices (UEs, CEs, etc.) and the network.

Reading the definition of TS and AS (section 3.1 and 3.2), it is clear to me that 464XLAT can fit in any of both definitions, so that should not be an issue for this reclassification. “A TS may be completely self-
   contained, or it may incorporate material from other specifications
   by reference to other documents (which might or might not be Internet
   Standards).”
    
    Lee

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 25 Sep 2017 11:20:01 +0200

Le 25/09/2017 à 10:28, Mikael Abrahamsson a écrit :
>> networks.  We speculate these are there now, whereas I may speculate 
>> it may not really be the case.  There are some networks that are 
> doing IPv6 only GTP

No, I would like to ask T-Mobile USA whether they use GTP-IPv6?  Or 
GTP-IPv4?

[...]

> What do you mean by GTP-IPV4?

I mean GTPU protocol that uses IPv4 addresses, and carries IPv6 packets 
inside; an example packet capture of what I call GTP-IPv4 is the following:
> INBOUND>>>>>  15:47:48:883 Eventid:142004(3)
> GTPU Rx PDU, from [IPv4-address]:2152 to [IPv4-address-2]:2152 (129)
> TEID: 0x80072183, Message type: GTP_TPDU_MSG (0xFF)
> Sequence Number:: NA
> GTP HEADER FOLLOWS:
> [snip]
> GTP HEADER ENDS.
>            Payload protocol: IPv6
> PROTOCOL PAYLOAD FOLLOWS:
> fe80::b9d9:c10a:2c2d:3c3b.546 > ff02::2.546:  [udp sum ok]
> IPv6 Header Follows:
> [snip]
> PROTOCOL PAYLOAD ENDS.

> We're talking about what access service is 
> Yes, the GTP packets might be carried over IPv4, but the SERVICE 
> provided to the customer is IPv6 only.

Excuse me, Mikael, but it is little possible to claim "IPv6-only" when 
there is IPv4.  One can call it "IPv6-only SERVICE", but there's still 
IPv4 - so it's an "IPv4-based IPv6-only SERVICE".

> addresses they might have. Also operational practices and preferences.

Yes, the operational practices and preferences are very important.

Their consequences too.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 25 Sep 2017 11:20:57 +0200

Le 25/09/2017 à 11:05, Kossut Tomasz - Hurt a écrit :
> Hi,
> 
> True ! 464xlat enabled IPv6 transition for mobile networks. Thank you ! 
> In IPv6-only network you can expect up to 60% native IPv6

? I thought in an IPv6-only network there is 100% native IPv6?

Alex

> 
> Cheers,
> 
> TK
> 
> *From:*Lorenzo Colitti [mailto:[email-masked]]
> *Sent:* Monday, September 25, 2017 3:55 AM
> *To:* Mark Andrews
> *Cc:* Gert Doering; [email-masked] WG
> *Subject:* Re: [v6ops] reclassify 464XLAT as standard instead of info
> 
> We added 464xlat to Android because there were credible deployment plans 
> in place for 464xlat on real networks that Android devices connect to. 
> In hindsight, we were right, as 464xlat went from credible plan to 
> successful deployment with an installed base in the tens of millions.
> 
> I personally think that if we had not done this, we wouldn't have 
> IPv6-only mobile networks today and we'd all still be lamenting the 
> chicken and egg problem for IPv6-only networks. Getting rid of IPv4 in 
> the network is a great step forward, and as Apple has shown, once that's 
> happened, host OSes can start removing IPv4 access from applications, 
> too. (And make no mistake: without 464xlat, those networks would *not* 
> have gone IPv6-only, and it would have been much harder, or even 
> impossible, for Apple to say that apps must operate in IPv6-only 
> environments, because there would have been no such environments.)
> 
> DS-Lite has no such credible deployment plans in place. Wifi networks 
> are going to provide IPv4 for many years. Mobile networks were never 
> going to deploy DS-Lite because the encapsulation would have broken 
> their billing platforms. And so, here we are.
> 
> We'll all get to IPv6-only eventually, and some time after that, we'll 
> get rid of IPv4. At that time, you can salt the earth over 464xlat if 
> you want. But until then, I wouldn't be too eager to bash 464xlat as a 
> technology. It was the right thing to do at the time.
> 
> 
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 25 Sep 2017 11:24:19 +0200

Le 25/09/2017 à 03:36, Lorenzo Colitti a écrit :
> On Mon, Sep 25, 2017 at 2:50 AM, Gert Doering <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> Can the radio station hand off to dual-stack URLs for working devices 
> and to IPv4-only URLs for broken devices? For example, based on user-agent?

I am not sure what do you mean?

There is no 'radio station' in 3GPP.  There are however FM radio 
stations if you wish.

Alex

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 25 Sep 2017 11:27:46 +0200

If you have IPv6-only access network, which is what 464XLAT is offering, you have 100% IPv6-only in the access network.

What you have at the customer sites/LANs and core/transit, is a different history.

This is the reason we need to have a clear definition … I will try to update the document this week:

draft-palet-ietf-v6ops-ipv6-only

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Alexandre Petrescu <[email-masked]>
Responder a: <[email-masked]>
Fecha: lunes, 25 de septiembre de 2017, 11:21
Para: <[email-masked]>
Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info

    
    
    Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 25 Sep 2017 11:37:50 +0200

Le 25/09/2017 à 11:27, JORDI PALET MARTINEZ a écrit :
> If you have IPv6-only access network, which is what 464XLAT is 
> offering, you have 100% IPv6-only in the access network.

Is that IPv6-only access network using GTP-IPv6? (a 3GPP spec that may 
exist that I dont have number)

Or is it using ATM? (IPv6 over ATM RFC2492, ATM is widely used to 
connect in-house networks to an operator)

> 3.  IPv6-only
> 
>    IPv6-only MUST be used only if, a complete network, end-to-end, is
>    actually not forwarding IPv4 at layer-2, which will mean that no-IPv4
>    addresses are configured, neither used for management, neither the
>    network is providing transition/translation support, neither there is
>    IPv4 transit/peering.

Is this "IPv6-only" something wrong?  What do you mean by "forwarding 
IPv4 at layer2".   IP is at layer 3, be it v4 or v6.  IP encapsulation 
is also layer 3.

Alex

> 
> Regards, Jordi
> 
> 
> -----Mensaje original----- De: v6ops <[email-masked]> en 
> nombre de Alexandre Petrescu <[email-masked]>
> Responder a: <[email-masked]> Fecha: lunes, 25 de
> septiembre de 2017, 11:21 Para: <[email-masked]> Asunto: Re: [v6ops]
> reclassify 464XLAT as standard instead of info
> 
> 
> 
>> True ! 464xlat enabled IPv6 transition for mobile networks. Thank 
>> you ! In IPv6-only network you can expect up to 60% native IPv6
> 
>> *From:*Lorenzo Colitti [mailto:[email-masked]] *Sent:* Monday, 
>> September 25, 2017 3:55 AM *To:* Mark Andrews *Cc:* Gert Doering; 
>> [email-masked] WG *Subject:* Re: [v6ops] reclassify 464XLAT as 
>> standard instead of info
>> 
>> can just as easily add DS-Lite to Android and we would have 
>> billions of machines that support DS-Lite.  Just because NAT64 and 
>> 464XLAT are sexy doesn't mean that it is good technology.
>> 
>> We added 464xlat to Android because there were credible deployment 
>> plans in place for 464xlat on real networks that Android devices 
>> connect to. In hindsight, we were right, as 464xlat went from 
>> credible plan to successful deployment with an installed base in 
>> the tens of millions.
>> 
>> chicken and egg problem for IPv6-only networks. Getting rid of IPv4
>> in the network is a great step forward, and as Apple has shown,
>> once that's happened, host OSes can start removing IPv4 access from
>> applications, too. (And make no mistake: without 464xlat, those
>> networks would *not* have gone IPv6-only, and it would have been
>> much harder, or even impossible, for Apple to say that apps must
>> operate in IPv6-only environments, because there would have been no
>> such environments.)
>> 
>> DS-Lite has no such credible deployment plans in place. Wifi 
>> networks are going to provide IPv4 for many years. Mobile networks 
>> were never going to deploy DS-Lite because the encapsulation would 
>> have broken their billing platforms. And so, here we are.
>> 
>> We'll all get to IPv6-only eventually, and some time after that, 
>> we'll get rid of IPv4. At that time, you can salt the earth over 
>> 464xlat if you want. But until then, I wouldn't be too eager to 
>> bash 464xlat as a technology. It was the right thing to do at the 
>> time.
>> 
>> 
>> 
>> _______________________________________________ v6ops mailing list
>>  [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>> 
> 
> _______________________________________________ v6ops mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
> 
> 
> 
> 
> ********************************************** IPv4 is over Are you 
> ready for the new Internet ? http://www.consulintel.es The IPv6 
> Company
> 
> This electronic message contains information which may be privileged 
> or confidential. The information is intended to be for the exclusive 
> use of the individual(s) named above and further non-explicilty 
> authorized disclosure, copying, distribution or use of the contents 
> of this information, even if partially, including attached files, is 
> strictly prohibited and will be considered a criminal offense. If
> you are not the intended recipient be aware that any disclosure,
> copying, distribution or use of the contents of this information,
> even if partially, including attached files, is strictly prohibited,
> will be considered a criminal offense, so you must reply to the
> original sender to inform about this communication and delete it.
> 
> 
> 
> _______________________________________________ v6ops mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Erik Kline <[email-masked]>
Date: Mon, 25 Sep 2017 18:47:41 +0900

When speaking from the perspective of a client OS I have frequently
observed and understood the phrase "IPv6-only network" to mean that
the link to which the client is connected only provisions and forwards
IPv6 packets.

IPv4 /may/ be available to the client as a service on these "IPv6-only
networks" within this definition, whether by 464xlat or VPN or by some
other means.  But that never seems to change the implied meaning of
"IPv6-only network" in these contexts.

Just an observation.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 25 Sep 2017 11:48:53 +0200

I’m going to make it clear in the new version. I mean using the in a layer 2 link “native IPv4 or native IPv6”. IPv6-only refers to “only” transporting native IPv6 packets, if IPv4 is translated or encapsulated on top of IPv6, then IPv4 is using the IPv6 as “if it was” a layer-2.

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 25 Sep 2017 11:51:29 +0200

Le 25/09/2017 à 11:48, JORDI PALET MARTINEZ a écrit :
> IPv4 at layer2".   IP is at layer 3, be it v4 or v6.  IP 
> encapsulation is also layer 3.
> 
> I’m going to make it clear in the new version. I mean using the in a 
> layer 2 link “native IPv4 or native IPv6”. IPv6-only refers to
> “only” transporting native IPv6 packets, if IPv4 is translated or 
> encapsulated on top of IPv6, then IPv4 is using the IPv6 as “if it 
> was” a layer-2.

The explanation sounds as reasonable beginning, but would need
refinement, I think.

I also heard the term "native IPv6".  This means there is no IPv4.

Would you accept a definition of the term "native IPv6" in the draft?

Alex

>> septiembre de 2017, 11:21 Para: <[email-masked]> Asunto: Re: 
>> [v6ops] reclassify 464XLAT as standard instead of info
>> 
>> 
>> 
>>> *From:*Lorenzo Colitti [mailto:[email-masked]] *Sent:* 
>>> Monday, September 25, 2017 3:55 AM *To:* Mark Andrews *Cc:* Gert 
>>> Doering; [email-masked] WG *Subject:* Re: [v6ops] reclassify 
>>> 464XLAT as standard instead of info
>>> 
>>> Stop exaggerating.  Google went and added CLAT to the Android. 
>>> They can just as easily add DS-Lite to Android and we would have
>>>  billions of machines that support DS-Lite.  Just because NAT64 
>>> and 464XLAT are sexy doesn't mean that it is good technology.
>>> 
>>> We added 464xlat to Android because there were credible 
>>> deployment plans in place for 464xlat on real networks that 
>>> Android devices connect to. In hindsight, we were right, as 
>>> 464xlat went from credible plan to successful deployment with an 
>>> installed base in the tens of millions.
>>> 
>>> IPv6-only mobile networks today and we'd all still be lamenting
>>> the chicken and egg problem for IPv6-only networks. Getting rid
>>> of IPv4 in the network is a great step forward, and as Apple has
>>> shown, once that's happened, host OSes can start removing IPv4
>>> access from applications, too. (And make no mistake: without
>>> 464xlat, those networks would *not* have gone IPv6-only, and it
>>> would have been much harder, or even impossible, for Apple to say
>>> that apps must operate in IPv6-only environments, because there
>>> would have been no such environments.)
>>> 
>>> networks are going to provide IPv4 for many years. Mobile 
>>> networks were never going to deploy DS-Lite because the 
>>> encapsulation would have broken their billing platforms. And so, 
>>> here we are.
>>> 
>>>  bash 464xlat as a technology. It was the right thing to do at 
>>> the time.
>>> 
>>> 
>>> 
>>> _______________________________________________ v6ops mailing 
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>>> 
>> 
>> This electronic message contains information which may be 
>> privileged or confidential. The information is intended to be for 
>> the exclusive use of the individual(s) named above and further 
>> non-explicilty authorized disclosure, copying, distribution or use 
>> of the contents of this information, even if partially, including 
>> attached files, is strictly prohibited and will be considered a 
>> criminal offense. If you are not the intended recipient be aware 
>> that any disclosure, copying, distribution or use of the contents 
>> of this information, even if partially, including attached files, 
>> is strictly prohibited, will be considered a criminal offense, so 
>> you must reply to the original sender to inform about this 
>> communication and delete it.
>> 
>> 
>>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 25 Sep 2017 11:53:15 +0200 (CEST)

> I mean GTPU protocol that uses IPv4 addresses, and carries IPv6 packets

This is not something the end user device sees or cares about. Why are you 
bringing this up?

---

From: Richard Patterson <[email-masked]>
Date: Mon, 25 Sep 2017 10:56:08 +0100

On 25 September 2017 at 10:20, Alexandre Petrescu <
[email-masked]> wrote:

>> We're talking about what access service is provided to the customers, and
>> there are several that do IPv6 only GTP. Yes, the GTP packets might be
>> carried over IPv4, but the SERVICE provided to the customer is IPv6 only.
>>
>
> there is IPv4.  One can call it "IPv6-only SERVICE", but there's still IPv4
> - so it's an "IPv4-based IPv6-only SERVICE".
>

That's like saying 6PE isn't good enough, which is ridiculous.
If the end-to-end customer-visible service is IPv6, what's the problem?

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 25 Sep 2017 11:57:11 +0200

Erik,

I would like to ask you clarification.

Le 25/09/2017 à 11:47, Erik Kline a écrit :
> When speaking from the perspective of a client OS

What is a "client OS"?  I think OSs are both clients and servers.

> I have frequently observed and understood the phrase "IPv6-only 
> network" to mean that the link to which the client is connected only 
> provisions and forwards IPv6 packets.

I agree with this definition of "IPv6-only network".  I would stress to
also mean "no IPv4" - be it encapsulation, translation, or DNS-x-y.

> IPv4 /may/ be available to the client as a service on these 
> "IPv6-only networks" within this definition,

Yes.  But not as a "service".  I never heard about "IP as a service"
other than some people at IETF, and other than in the context of a 
particular operator.

IP is not a service.

Services are at the services layer.  APIs are services, there is remote
access service, etc.

> whether by 464xlat or VPN or by some other means.

VPN and encapsulations are also called "virtual networks".

Is the "IPv6-as-a-service" a "virtual network"?

If so, we want "IPv6 as a real network".

> But that never seems to change the implied meaning of "IPv6-only
> network" in these contexts.

Depends who you ask.

Alex

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 25 Sep 2017 12:04:51 +0200 (CEST)

> also mean "no IPv4" - be it encapsulation, translation, or DNS-x-y.

You're in extreme minority to have that definition.

I don't care if my IP packet provider carries my packets over POS, 
ethernet, if they run native IPv4, IPv6 or MPLS in their core, if they use 
LDPv4 or LDPv6 for their control plane etc. What I care about is what I 
need to configure my equipment with to talk to them.

So an IPv6 only access uses only IPv6 packets in the access line, that the 
device can see. What happens in the ISP network once the packets hits that 
part is out of scope for the definition of IPv6 only access.

---

From: Erik Kline <[email-masked]>
Date: Mon, 25 Sep 2017 19:04:46 +0900

> I would like to ask you clarification.

I'm sorry but there is more clarification asked for and indeed
required here than I have time for.  Forget I said anything.

>> I have frequently observed and understood the phrase "IPv6-only network"
>> to mean that the link to which the client is connected only provisions and
>> forwards IPv6 packets.
>
>
>> networks" within this definition,
>
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 25 Sep 2017 12:07:32 +0200

Le 25/09/2017 à 11:53, Mikael Abrahamsson a écrit :
> This is not something the end user device sees or cares about.

But the end-user device connects to a network, and you claim that 
network is IPv6-only.

You claim that because there are networks that are IPv6-only then 
devices must run CLAT.

But what is "IPv6-only networks"?  Do they use IPv4 though?

> Why are 
> you bringing this up?

Because I need to understand whether the APNs dedicated to CLAT run 
IPv6-only.  Do these networks do GTP-v4?  And PDP type IPv4-IPv6?

One would like to have coherence between IPv4, IPv6, APN type, PDP type, 
encapsulations, translations.

The ideal is "double stack" - no encap, no translation, no IN A in UDPv6 
packets, no IN AAAA in UDPv4 packets, and PDP type v4v6.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 25 Sep 2017 12:12:27 +0200

Le 25/09/2017 à 12:04, Mikael Abrahamsson a écrit :
>> I agree with this definition of "IPv6-only network".  I would stress 
>> to also mean "no IPv4" - be it encapsulation, translation, or DNS-x-y.
> 

Excuse me, but that's used in many networks.

> ethernet, if they run native IPv4, IPv6 or MPLS in their core, if they 
> use LDPv4 or LDPv6 for their control plane etc. What I care about is 
> what I need to configure my equipment with to talk to them.

If they _can_ provide IPv4 too, then use it.

Dont make funny translations.  Translations break other matters in the 
Internet, like we saw with NAT.

> So an IPv6 only access uses only IPv6 packets in the access line, that 
> the device can see. What happens in the ISP network once the packets 
> hits that part is out of scope for the definition of IPv6 only access.

I agree, but dont make it look as if the network cant do IPv4.

If it can, then use it.

This very important.

Alex

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 25 Sep 2017 12:12:50 +0200 (CEST)

> IPv6-only.  Do these networks do GTP-v4?  And PDP type IPv4-IPv6?

It doesn't matter if it's GTP over IPv4 or IPv6. The end device doesn't 
care. The important thing is what type of PDP context that is supported. 
If it's only IPv6 type PDP supoorted (or used), then this is "IPv6 only 
access". That's all the device sees. What the ISP uses to produce this 
service is irrelevant in this discussion.

> packets, no IN AAAA in UDPv4 packets, and PDP type v4v6.

You're pretty much alone in that definition.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 25 Sep 2017 12:19:17 +0200 (CEST)

> If it can, then use it.

Some people want to migrate away from IPv4 in their networks. This has to 
be done incrementally, and since encap can be done over IPv4 and IPv6 
without the customer seeing any difference, then this is a good way to do 
things incrementally.

So over time we'll see people migrate from LDPv4 to LDPv6, from GTP over 
IPv4 to GTP over IPv6, from 6PE to 4PE etc.

In the end, IPv4 will be a corner case service tunneled/translated over an 
IPv6 network for most people. We might be up to 20 years out from this 
being done universally, but that's the end goal for most people who have 
actually put serious thought into their long time future. I know people 
who are already trying to do this because they're growing quickly and they 
don't have IPv4 addresses to spare, to waste on infrastructure use, and 
using RFC1918 addresses has lots of operational downsides.

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 25 Sep 2017 12:20:02 +0200

Le 25/09/2017 à 12:12, Mikael Abrahamsson a écrit :
[...]
> It doesn't matter if it's GTP over IPv4 or IPv6. The end device
> doesn't care.

Well it should care.

It should care about not breaking the apps that are IPv4, not breaking
DHCPv6-PD.  And dont try to be smart with funny translation methods;
because others tried too.

Dumb network.

> The important thing is what type of PDP context that is supported.

For IPv4 apps, the PDP context type should include IPv4 (in addition to
IPv6).  That's about it.

> If it's only IPv6 type PDP supoorted (or used), then this is "IPv6
> only access".

Well, that's "IPv6-only PDP type", it's not "IPv6-only access".

The Access Network is a huge concept that I am afraid no-one has seen an
IPv6-only version of.

> That's all the device sees. What the ISP uses to produce this service
> is irrelevant in this discussion.
> 
>> The ideal is "double stack" - no encap, no translation, no IN A in
>>  UDPv6 packets, no IN AAAA in UDPv4 packets, and PDP type v4v6.
> 

Hmm... and how about the many networks that provide simultaneous IPv4
and IPv6 access without any translation, encapsulation nor DNS-v4-v6?

If you sum them up I think you end with more than a single mobile
operator's subscribers.

Look at those stats of IPv6 google http hits - how many come from a
single mobile operator's subscribers?  All the rest are from "double
stack" networks.

Alex

---

From: Gert Doering <[email-masked]>
Date: Mon, 25 Sep 2017 12:20:34 +0200

Hi,

> There is no 'radio station' in 3GPP.  There are however FM radio 

Please read Lorenzo's mail in-thread, and it will be clear what sort
of radio he's talking about.

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Mon, 25 Sep 2017 12:22:50 +0200

Hi,

> I also heard the term "native IPv6".  This means there is no IPv4.

"native IPv6" usually means "IPv6 is not tunneled over IPv4" (where it
counts, so don't get started with GTP tunnels again).

"native IPv6" doesn't exclude native IPv4 from being on the same link,
so this term is totally irrelevant in a 464xlat discussion.

Gert Doering
        -- NetMaster

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 25 Sep 2017 12:25:48 +0200

Le 25/09/2017 à 12:19, Mikael Abrahamsson a écrit :
> Some people want to migrate away from IPv4 in their networks.

I aree, should be that direction.

> This has to be done incrementally

I agree - but start with the network, not with the Terminal.

Make first an IPv6-only network.

> and since encap can be done over IPv4 and IPv6 without the customer
> seeing any difference, then this is a good way to do things
> incrementally.

It was tried numerous times before CLAT: 3ffe, sixxs, 6to4, DS-MIPv6,
and others.

> So over time we'll see people migrate from LDPv4 to LDPv6, from GTP 
> over IPv4 to GTP over IPv6, from 6PE to 4PE etc.

During this time you prohibit a number of apps and protocols such as
DHCPv6-PD.

> In the end, IPv4 will be a corner case service tunneled/translated 
> over an IPv6 network for most people. We might be up to 20 years out 
> from this being done universally, but that's the end goal for most 
> people who have actually put serious thought into their long time 
> future. I know people who are already trying to do this because 
> they're growing quickly and they don't have IPv4 addresses to spare,

Tell them to do IPv6-PDP-Type v4v6, and NAT for IPv4, and leave IPv6 alone.

> to waste on infrastructure use, and using RFC1918 addresses has lots 
> of operational downsides.

CLAT has many operational downsides as well, forget it.

Fundamentally the IPv4 NAT issue is the fact that it translates.  But
CLAT also translates - they both have same issue.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 25 Sep 2017 12:26:59 +0200

> of radio he's talking about.

Sorry I dont have time.

Simply reading that email shows there is no knowledge about handovers.

So should not talk about matters where there is knowledge about.

Alex

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 25 Sep 2017 12:27:36 +0200

Maybe you’re not there, but operators live in a world where they don’t have any more IPv4 addresses, so double-stack is over in the access networks. However, there are devices and apps (in both cellular/tethering and non-cellular), that are IPv4-only, so user networks/LANs, need some transition support to make IPv4 transparently available end-to-end.

Last week I did a presentation and I was making a joke:

- I’ve been told that the only secure thing in this life is death … well not anymore, some scientifics said they are close to find the way avoid death … So. the new “for sure” thing in this life, is that we are going to an IPv6-only world (and I’m referring here to access networks, maybe even some core/distribution networks).

Saludos,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Alexandre Petrescu <[email-masked]>
Responder a: <[email-masked]>
Fecha: lunes, 25 de septiembre de 2017, 12:07
Para: Mikael Abrahamsson <[email-masked]>
CC: <[email-masked]>
Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info - double stack coexistence

    

    

    
    Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 25 Sep 2017 12:29:49 +0200

Le 25/09/2017 à 12:22, Gert Doering a écrit :
> "native IPv6" usually means "IPv6 is not tunneled over IPv4"

That's for you.

For me "native IPv6" means there is no IPv4.  And there are many such 
networks.

> (where it

No, you dont claim anymore these networks are "IPv6-only".  They are not.

> so this term is totally irrelevant in a 464xlat discussion.

If yous want to sit on an upper layer, looking from there, ignoring 
there is IPv4 below, then that is your problem.

The consequence of that is that your ignorance of IPv4 below you makes 
you forbid some IPv6 apps.  Some of them are, but not limited to, DHCPv6-PD.

Alex

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 25 Sep 2017 12:32:57 +0200 (CEST)

> you forbid some IPv6 apps.  Some of them are, but not limited to, 

This has nothing to do with DHCPv6-PD. DHCPv6-PD works just fine over both 
GTP-over-IPv4 and GTP-over-IPv6. There is no difference in this 
application.

GTP tunnel is a point-to-point tunnel and it doesn't matter what the 
infrastructure underneath is.

If the UE modem decides to drop IPv6 multicast packets it has received 
over the RLC layer (which doesn't have IPv4 or IPv6 encap underneath) then 
that's a bad modem. It has nothing to do with the rest of the discussion.

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 25 Sep 2017 12:34:09 +0200

Le 25/09/2017 à 12:27, JORDI PALET MARTINEZ a écrit :
> [...] but operators live in a world where they don’t have any more 
> IPv4 addresses,

False, they always have access to NAT space.

Keep NAT for IPv4, leave IPv6 alone.

> so double-stack is over in the access networks. However, there are
> devices and apps (in both cellular/tethering and non-cellular), that
> are IPv4-only, so user networks/LANs, need some transition support to
> make IPv4 transparently available end-to-end.

That need can not be satisfied to a large scale.  Make it work inside 
some domain, with some translation, but cant work for all.

It's plain NAT.

> - I’ve been told that the only secure thing in this life is death … 
> well not anymore, some scientifics said they are close to find the 
> way avoid death … So. the new “for sure” thing in this life, is that
>  we are going to an IPv6-only world (and I’m referring here to access
>  networks, maybe even some core/distribution networks).

I agree.

Saludos,

Alex

> Saludos, Jordi
> nombre de Alexandre Petrescu <[email-masked]> Responder
> a: <[email-masked]> Fecha: lunes, 25 de septiembre de
> 2017, 12:07 Para: Mikael Abrahamsson <[email-masked]> CC:
> <[email-masked]> Asunto: Re: [v6ops] reclassify 464XLAT as standard
> instead of info - double stack coexistence
> 
>> Why are you bringing this up?
> 
> One would like to have coherence between IPv4, IPv6, APN type, PDP 
> type, encapsulations, translations.
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 25 Sep 2017 12:37:23 +0200

Are you going to pay from your pocket the operators for the extra CGN cost? They may agree in that case!

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Alexandre Petrescu <[email-masked]>
Responder a: <[email-masked]>
Fecha: lunes, 25 de septiembre de 2017, 12:34
Para: <[email-masked]>
Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info - double stack coexistence

    

    
    
    It's plain NAT.

    I agree.
    
    Saludos,
    
    Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 25 Sep 2017 12:38:12 +0200

Le 25/09/2017 à 12:32, Mikael Abrahamsson a écrit :
> This has nothing to do with DHCPv6-PD. DHCPv6-PD works just fine over 
> both GTP-over-IPv4 and GTP-over-IPv6.

Have you tried?

I am afraid it will not work, I explained earlier why, I can explain 
again if necessary.

[...]

> over the RLC layer (which doesn't have IPv4 or IPv6 encap underneath) 
> then that's a bad modem. It has nothing to do with the rest of the 
> discussion.

It's not only that modem problem I talked about.

The fact that DHCPv6-PD does not work on Android has multiple causes. 
One is the modem.

The other is pure human reluctance to allow it to work.  The reason 
invoked for that is that "it is not needed, because CLAT does it".

So basically one forbids a pure-IPv6 method (DHCPv6-PD) and recommends a 
weak IPv4-IPv6 translation method instead.

Forget the IPv4-IPv6 translation methods.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 25 Sep 2017 12:41:44 +0200

> cost? They may agree in that case!

Look to be clear, I am not paying anything from my pocket.

Moreover, what I am saying is less cost.

CGNs and all computers in the world already run IPv4.  Continue do that 
for IPv4.

If you need new IPv4 address space, use NAT.

And if you want IPv6, then use all the available IPv6 software for it.

It's called "double stack".

Dont do v4-v6 translations, because they prohibit you from running some 
native IPv6 apps.  And they are expensive.

Alex

> 2017, 12:34 Para: <[email-masked]> Asunto: Re: [v6ops] reclassify
> 464XLAT as standard instead of info - double stack coexistence
> 
> 
> 
>> devices and apps (in both cellular/tethering and non-cellular),
>> that are IPv4-only, so user networks/LANs, need some transition
>> support to make IPv4 transparently available end-to-end.
> 
> That need can not be satisfied to a large scale.  Make it work
> inside some domain, with some translation, but cant work for all.
> 
> It's plain NAT.
> 
>> - I’ve been told that the only secure thing in this life is death
>> … well not anymore, some scientifics said they are close to find
>> the way avoid death … So. the new “for sure” thing in this life, is
>> that we are going to an IPv6-only world (and I’m referring here to
>> access networks, maybe even some core/distribution networks).
> 
> I agree.
> 
> Saludos,
> 
> Alex
> 
>> 
>> Saludos, Jordi
>> 
>> 
>> septiembre de 2017, 12:07 Para: Mikael Abrahamsson
>> <[email-masked]> CC: <[email-masked]> Asunto: Re: [v6ops]
>> reclassify 464XLAT as standard instead of info - double stack
>> coexistence
>> 
>> Because I need to understand whether the APNs dedicated to CLAT
>> run IPv6-only.  Do these networks do GTP-v4?  And PDP type
>> IPv4-IPv6?
>> 
>> ********************************************** IPv4 is over Are
>> you ready for the new Internet ? http://www.consulintel.es The
>> IPv6 Company
>> 
> strictly prohibited and will be considered a criminal offense. If you
> are not the intended recipient be aware that any disclosure, copying,
> distribution or use of the contents of this information, even if
> partially, including attached files, is strictly prohibited, will be
> considered a criminal offense, so you must reply to the original
> sender to inform about this communication and delete it.
> 
> 
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 25 Sep 2017 12:44:30 +0200 (CEST)

On Mon, 25 Sep 2017, Alexandre Petrescu wrote:

> The other is pure human reluctance to allow it to work.  The reason invoked 
> for that is that "it is not needed, because CLAT does it".

My guess would be that we do not have DHCPv6-PD in mobile networks because 
RFC7278 works well enough for most deployment scenarios, and it's a pain 
to get DHCPv6-PD into both mobile core and UEs (chicken and egg problem, 
plus "what we have seems to work for most" (ie 64SHARE)).

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 25 Sep 2017 12:45:16 +0200 (CEST)

> It's called "double stack".

Actually, it's called "dual stack".

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 25 Sep 2017 12:55:53 +0200

Le 25/09/2017 à 12:44, Mikael Abrahamsson a écrit :
> My guess would be that we do not have DHCPv6-PD in mobile networks 
> because RFC7278 works well enough for most deployment scenarios,

If it worked that well it were not INFORMATIONAL.

> and it's a pain to get DHCPv6-PD into both mobile core and UEs

For UE it is not a pain.  Again: for UE it is not a pain.  Stop claiming 
it is a pain.  There are DHCPv6 Android apps in the Store doing that. 
There are numerous software packages running on Androind doing DHCPv6 PD.

What _is_ a pain is explicit blocking by Android OS of DHCPv6 software.

(the modem pain is nothing compared to the above).

> (chicken and egg problem, plus "what we have seems to work for most"
> (ie 64SHARE)).

I disagree.  I dont know what you call "most".

64share is a non-scalable technology, should be get rid of.

This 64share, together with the 64bit limit in Address Architecture, 
stops growth at the edges.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 25 Sep 2017 12:58:21 +0200

> Actually, it's called "dual stack".

"dual stack" is what involves some encapsulation and some translation. 
E.g. RFC4213, note the "and":
> Dual stack implies providing
>    complete implementations of both versions of the Internet Protocol
>    (IPv4 and IPv6), and configured tunneling provides a means to carry
>    IPv6 packets over unmodified IPv4 routing infrastructures.

On another hand, "double stack" is IPv4 and IPv6 at the same time, 
without any encapsulation nor translation, nor DNS-v4-v6.  Just IPv4, 
IPv6 and DNS.

Alex

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 25 Sep 2017 13:07:05 +0200

Many operators have not CGN yet, so IPv6-only solutions even if they require NAT64 are more efficient (you have even open source for NAT64) and IPv4 usage of a few IPv4 public addresses scale much better with NAT64 than in CGN. And of course, if you have IPv6-only-access it means more and more of your traffic is going thru to IPv6 destinations, so you have less and less usage of any transition stuff.

In addition to that there are implications in terms of battery and radio bandwidth (keep-alives for CGN), which have much less impact if the access network is IPv6-only.

I’ve not seen any native IPv6 app that gets impacted by transition. I agree that transition is always imperfect, one way or another for IPv4, but we need to balance between long-term strategy or staying forever with IPv4.

Actually 464XLAT is really inexpensive, much less CapEx and OpEx than any other transition and even than dual-stack-access.

Saludos,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Alexandre Petrescu <[email-masked]>
Responder a: <[email-masked]>
Fecha: lunes, 25 de septiembre de 2017, 12:42
Para: <[email-masked]>
Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info - double stack coexistence

    

    

    
    
    Alex

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 25 Sep 2017 13:09:10 +0200 (CEST)

> without any encapsulation nor translation, nor DNS-v4-v6.  Just IPv4, 

Where is this defined?

I googled for "double stack" and IETF and I got ~900 hits. A lot of them 
seems to be from native french speakers, so I'd imagine there is some kind 
of translation from french that means some tend to use "double stack" 
instead of "dual stack"? "double stack" and IPv6 yields 4k hits.

"Dual stack" and ietf yields 75k hits and replacing ietf with ipv6 yields 
364k hits.

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 25 Sep 2017 14:00:52 +0200

Le 25/09/2017 à 13:09, Mikael Abrahamsson a écrit :
>>  without any encapsulation nor translation, nor DNS-v4-v6.  Just
>> IPv4, IPv6 and DNS.
> 
> Where is this defined?

In my emails.

> I googled for "double stack" and IETF and I got ~900 hits.

So it's a place to grab.

I relate "double stack" to a "coexistence" item C) in an earlier RFC
INFORMATIONAL by B. Carpenter.

With that, I can put up a draft, if you are interested to participate.

This kind of "double stack" is what many deployments do, and easier to
tell than twisting one's tongue around v6v4v6v4.

> A lot of them seems to be from native french speakers, so I'd imagine
> there is some kind of translation from french that means some tend to
> use "double stack" instead of "dual stack"? "double stack" and IPv6
> yields 4k hits.

Well, I am not a native french speaker, but because you make a 
speculation on how it came up here is an explanation: I wanted to say 
"dual stack" in our email exchanges, but then I realized some people say 
"dual stack" to mean simultaneous IPv4 and IPv6 involving some 
translation/encap/DNSv4v6/sharing (RFCs like RFC6333, RFC5555, RFC4213, 
RFC4241).

On another hand, no RFC talks about "dual stack" as simultaneous use of 
IPv4 and IPv6 without any form of translation, encap, RH, DNSv4v6, 
address sharing, etc.

So I propose "double stack" for that.

At least it's clear what I talk about.

Also, if you have some other more English term to denote that, (more 
English than "double stack"), then I am willing to use it.

Alex

> 
> "Dual stack" and ietf yields 75k hits and replacing ietf with ipv6 
> yields 364k hits.
>

---

From: Gert Doering <[email-masked]>
Date: Mon, 25 Sep 2017 14:04:08 +0200

Hi,

> > of radio he's talking about.

*You* are wasting 100s of man hours by not reading what other people
write (or trying to understand).  

So maybe you should just use your time to *read and think*, instead of 
massively contributing to the overall noise on this mailing list?

> So should not talk about matters where there is knowledge about.

Please follow your advice.

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Mon, 25 Sep 2017 14:05:07 +0200

Hi,

> For me "native IPv6" means there is no IPv4.  And there are many such 

Would you please just go away?  Redefining everything in different ways
from everyone else, and then complaining that things will not work out
the way you think it is is just wasting everyones time.

Gert Doering
        -- NetMaster

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 25 Sep 2017 14:20:14 +0200

Le 25/09/2017 à 13:07, JORDI PALET MARTINEZ a écrit :
> Many operators have not CGN yet,

When they get it it wont be an IPv6 CGN, please.

Because CGN means NAT.  We dont want NAT in IPv6.

> so IPv6-only solutions even if they require NAT64

Dont assume operators to come up with an IPv6 CGN, please.

So operators wont require NAT64.

Let operators do IPv4 NAT, CGN with IPv4, and native non-translated IPv6
all the way.

> are more efficient (you have even open source for NAT64) and IPv4 
> usage of a few IPv4 public addresses scale much better with NAT64 
> than in CGN.

Again: dont translate IPv6 to IPv4 or vice-versa.  It becomes a mess,
apps dont work.

> And of course, if you have IPv6-only-access it means more and more
> of your traffic is going thru to IPv6 destinations, so you have less
> and less usage of any transition stuff.

Yes, that way.

> In addition to that there are implications in terms of battery and 
> radio bandwidth (keep-alives for CGN), which have much less impact
> if the access network is IPv6-only.

Well, I am not sure what you mean?

You seem to be using the keep-alive argument (known for some apps to
keem state up in some NATs) to claim that 464XLAT involves the terminal
to consume less battery.

Keep-alives for NAT will kill the battery - yes, so reduce the time you
use IPv4 on the terminal.  If you use IPv6 on terminal for same apps
your battery will last longer.

So I dont understand how NAT keepalives are an argument in favor of a
translation mechanism.

> I’ve not seen any native IPv6 app that gets impacted by transition.

DHCPv6-PD is a native IPv6 app: it runs only IPv6 sockets, and it is an
Application in Android Store.  However, it is impacted by CLAT.  More
precisely: when CLAT runs DHCPv6-PD cant run.

> I agree that transition is always imperfect, one way or another for 
> IPv4, but we need to balance between long-term strategy or staying 
> forever with IPv4.

I agree.

The strategy is: use IPv4 with NAT (if you dont have enough IPv4
publicly routable addresses), and use IPv6 pure at the same time.

In the past there were other strategies like IPv6 growing islands
(6bone), or IPv6-IPv4 translations (6to4).

> Actually 464XLAT is really inexpensive, much less CapEx and OpEx
> than any other transition and even than dual-stack-access.

464XLAT involves some issues with some apps.  It's expensive to update
apps to work with 464XLAT.

Saying that 464XLAT is only part of the network (not in the terminal) is
false - there is CLAT in terminal.

Double-stack (IPv4-IPv6 PDP type, or PPPoE-v4-and-v6 on ADSL) is the 
least expensive.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 25 Sep 2017 14:21:34 +0200

Le 25/09/2017 à 14:04, Gert Doering a écrit :
[...]
> Please follow your advice.

DO you know what is a handover?

Then we can discuss.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 25 Sep 2017 14:23:13 +0200

> the way you think it is is just wasting everyones time.

Excuse me - since when can _you_ ask people to go away, just like that?

Have you ever come to a v6ops meeting?  If so, maybe we can meet and say 
hello.

BEfore that, I dont think you can talk like that.

Alex

---

From: Erik Kline <[email-masked]>
Date: Mon, 25 Sep 2017 23:15:27 +0900

> precisely: when CLAT runs DHCPv6-PD cant run.

If this is true then take it up with app author, but there's precisely
nothing that makes this adverse interaction a requirement.

And don't be mislead by DHCPv6-PD talk in RFC6877 -- it isn't
necessary, it's just one way to do things.

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 25 Sep 2017 16:32:01 +0200

> nothing that makes this adverse interaction a requirement.

Well, any DHCPv6-PD client needs to add addresses on the interfaces and 
in the routing table.  A favorite OS like Android does not allow it. 
That's adversity.

> necessary, it's just one way to do things.

I agree.  Also DHCPv6-PD RFC can work on its own.

Alex

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 26 Sep 2017 08:19:45 +1300

...
> Dual stack doesn't solve the problem IPv6 was created to solve, which is the lack of available IPv4 addresses. 

That made me sit up. In a sense it's true, but the reason for dual stack
as the original co-existence mechanism was so that *servers* could serve
both legacy (IPv4) and current (IPv6) clients throughout the transition
period. So dual stack, all the way from the server to to the client's
provider edge, was very much part of solving the lack of IPv4 addresses.

This became inadequate because too many ISPs and hosting providers were
too slow to support IPv6. That's why we're now in translation hell.

On 25/09/2017 23:27, JORDI PALET MARTINEZ wrote:

> Maybe you’re not there, but operators live in a world where they don’t have any more IPv4 addresses, so double-stack is over in the access networks. 

That isn't true everywhere. There are still plenty of places where consumer ISPs
have IPv4 addresses for new customers (one per customer, of course). Of course,

> Maybe you’re not there, but operators live in a world where they don’t have any more IPv4 addresses, so double-stack is over in the access networks. However, there are devices and apps (in both cel…

Yes, sadly. And in that situation, stating that 464XLAT is BCP seems quite
reasonable. Sad but true.

    Brian

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 25 Sep 2017 21:25:38 +0200

I guess the main issue is that we miscalculated how much time will take for the operators/hosting providers to deploy IPv6.

If the “deployment” work was started just 3-4 years before, the situation will be now totally different … (and that will mean that we will had spent much less effort in finding new and “best” transition mechanisms, etc.).

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Brian E Carpenter <[email-masked]>
Organización: University of Auckland
Responder a: <[email-masked]>
Fecha: lunes, 25 de septiembre de 2017, 21:20
Para: <[email-masked]>
Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info - double stack coexistence

    ...

    

    

        Brian

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 25 Sep 2017 21:30:20 +0200

Clarifying myself … in the sense that having deployed IPv6 much earlier will have avoided exhausting IPv4 addresses *before* IPv6 is actually deployed in s sufficient % of the networks.

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de JORDI PALET MARTINEZ <[email-masked]>
Responder a: <[email-masked]>
Fecha: lunes, 25 de septiembre de 2017, 21:26
Para: <[email-masked]>
Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info - double stack coexistence

    
    Regards,
    Jordi

    -----Mensaje original-----
    De: v6ops <[email-masked]> en nombre de Brian E Carpenter <[email-masked]>
    Organización: University of Auckland
    Responder a: <[email-masked]>
    Fecha: lunes, 25 de septiembre de 2017, 21:20
    Para: <[email-masked]>
    Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info - double stack coexistence
    
        ...

        

        

            Brian

---

From: Fred Baker <[email-masked]>
Date: Mon, 25 Sep 2017 12:31:31 -0700

Speaking as chair, the person who can actually ask someone to "please go away".

I'm not asking anyone to "go away". I will note that IETF working groups do much of their work on mailing lists, and have active participants who operate on their lists primarily, and in some cases only, on those lists. You are each active in v6ops, and appreciated by the chairs.

That said, Alexandre, I have to agree with Gert that the views you have expressed in the past few days have added little to the discussion. They differ from many of the networks and deployments discussed in v6ops, and aren't particularly helpful. In specific cases, as others have noted, they are incorrect.

What I, as chair, will ask - of each of us - is that if you have comments to make that are personal rather than technical, please address them privately to the person in question. We have close to 1000 people on this mailing list, and the other 999 don't really need the noise.

> On Sep 25, 2017, at 5:05 AM, Gert Doering <[email-masked]> wrote:
> 
> Hi,
>

---

From: Gert Doering <[email-masked]>
Date: Mon, 25 Sep 2017 22:41:00 +0200

Hi,

> DO you know what is a handover?

I do :-)

> Then we can discuss.

No.  You are beyond hope.  You are ignoring advice from people that have
the operatinal experience, are making up your own meanings for industry
accepted terms, and are generally confusing everything possible on all
possible layers.

There is no way to discuss with you before you learn to *read* and *think*,
and this will be my last response to you (until then).

Gert Doering
        -- NetMaster

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 28 Sep 2017 11:48:35 +0200

Noted