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

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 19 Sep 2017 09:23:52 -0300

Hi all,

RFC6877 (464XLAT) is an informational document.

However, this transition mechanism is the one that has a bigger deployment in terms of number of subscribers using it (hundreds of millions), which I think is even more than ALL the other transition mechanism together.

Doesn’t make any sense, in my opinion to keep it as an informational document, while we have many others that are standards track and don’t have such level of deployment.

I was commenting this last week with a couple of the co-authors of this document, and they have the same opinion.

So, should we aim to do this?

Can we even consider moving it to STD?

Regards,
Jordi

**********************************************
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: Alexandre Petrescu <[email-masked]>
Date: Tue, 19 Sep 2017 18:23:01 +0200

Sounds as trying to impose 464xlat to everyone else?

My little IoT IPv6 cellular device does not run 464xlat and neither 
IPv4.  If 464xlat becomes Stds Track does it mean that it MUST run 
464xlat?  I would disagree with that.

Alex

Le 19/09/2017 à 14:23, JORDI PALET MARTINEZ a écrit :
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 19 Sep 2017 12:55:51 -0400

On Sep 19, 2017, at 12:23 PM, Alexandre Petrescu <[email-masked]> wrote:
> My little IoT IPv6 cellular device does not run 464xlat and neither IPv4.  If 464xlat becomes Stds Track does it mean that it MUST run 464xlat?  I would disagree with that.

Um, when does standards track ever mean this, Alex?   The answer is never.   What it means for a document to be standards track is that it has IETF consensus as a standard, not that you are required to implement it.   Does your little IoT device implement XMPP?   That's a standard...

:)

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 19 Sep 2017 14:05:19 -0300

Not at all, just to avoid this protocol to be discriminated compared to others.

No reason to have some of the standard and others informational, even less if this is the one with has a bigger deployment. Just my opinion, but based in facts.

Regards,
Jordi

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

    
    Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 19 Sep 2017 21:33:01 +0200

> Not at all, just to avoid this protocol to be discriminated compared to others.

464xlat has more success than other transition mechanisms.  I saw it for 
myself.

Yet it's about IPv4.

How about Historical.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 19 Sep 2017 21:37:39 +0200

Le 19/09/2017 à 18:55, Ted Lemon a écrit :
> On Sep 19, 2017, at 12:23 PM, Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]>> wrote:
> Um, when does standards track ever mean this, Alex?

Right, and I agree with your XMPP comment.

But is 464xlat some software feature that only Android implements?  I 
did not see it on yocto.

>   The answer is 
> never.   What it means for a document to be standards track is that it 
> has IETF consensus as a standard,

consensus and?

Alex

  not that you are required to implement
> it.   Does your little IoT device implement XMPP?   That's a standard...
> 
> :)
>

---

From: Fred Baker <[email-masked]>
Date: Tue, 19 Sep 2017 13:27:51 -0700

Hmm. Wearing the chair hat, but not making pronouncements. Thinking through the options and considerations.

Some reading matter:
https://tools.ietf.org/html/rfc2026#section-5
https://tools.ietf.org/html/rfc6410
RFC 2026 section 4 as updated by 6410. 

https://tools.ietf.org/html/rfc6782
https://tools.ietf.org/html/rfc7269
https://tools.ietf.org/html/rfc7335
https://tools.ietf.org/html/rfc7445
https://tools.ietf.org/html/rfc7849
https://tools.ietf.org/html/rfc7934

I would agree that informational status is probably inappropriate at this point. I'll note that the progression is not all that unusual; GRE, for example, was originally informational (RFC 1701), was taken to Proposed Standard in RFC 2784, and has been updated by RFC 2890. If it were taken to Internet Standard, we would need to demonstrate the points raised in https://tools.ietf.org/html/rfc6410#section-2.2.

What gives me pause in using the PS/IS standards track is the issue of interoperation of multiple implementations. I'm not entirely sure what that means in an operational procedure or service, which is in my perception what 464XLAT is. If that is the interoperation of multiple networks, it might be the interoperation of an IPv6-only (subset of a) network with other IPv4 networks, as the interoperation of that same network with IPv6 networks or networks with IPv6 capabilities doesn't require such services. The description of a BCP in RFC 2026 sounds more like what we're looking at here.

My thought at the moment (which I can be argued out of) is that the right status is BCP, and that we would want an updated document that captures anything we have learned since RFC 6877 was published.

> On Sep 19, 2017, at 5:23 AM, JORDI PALET MARTINEZ <[email-masked]> wrote:
> 
> Hi all,
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Sep 2017 08:36:58 +1200

> Can we even consider moving it to STD?

It seems reasonable to me, but probably needs a new RFC, because of the
"Status of this memo" section, so I expect that would lead to nitpicking
discussions. Do the authors have the energy for that?

     Brian

---

From: Fred Baker <[email-masked]>
Date: Tue, 19 Sep 2017 13:41:50 -0700

Chair hat off.

If it were ONLY about IPv4, I might agree with you, or suggest another working group. 464XLAT is about connecting an IPv6-only (subset of a) network to an IPv4 network, which I would think remains a current issue. If we're serious about talking about IPv6-only networks, an important part of that is helping people get there. That has been my argument for doing anything related to transition mechanisms, in v6ops or anywhere else. 

If we were to declare anything HISTORIC, it would be other transition mechanisms that have been documented but not widely found useful. We killed 6to4 and Teredo...

> On Sep 19, 2017, at 12:33 PM, Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> 
> 464xlat has more success than other transition mechanisms.  I saw it for myself.
> 
> Yet it's about IPv4.
> 
> How about Historical.
> 
> Alex
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 19 Sep 2017 22:56:12 +0200

From my humble experience of following IPv6 cellular deployments, I
noticed that once 464XLAT got proposed DHCPv6 service was removed.  It
was suggested that that was the 'standard' (464XLAT) and that everyone
would do it.

I am not able to explain the relationship 464XLAT-yes / DHCPv6-no,
unless I make some speculations.

To avoid me speculating, I would like to ask you: do you think there is
any relationship between the two?  Do you think DHCPv6 is still
necessary when 464XLAT runs?  Do you think 464XLAT hampers somehow the
deployment of DHCPv6 (just like 64share does with DHCPv6-PD)?

I would like to say that if you consider 464XLAT to
be a good Android technology on good cellular networks - I agree with
you.  Just I doubt about the StdsTrack.

Alex

PS: if you have time:
 From the software side, I can say that some non-Android IoT device
connects ok to IPv6 cellular network and does not use 464XLAT.  It does
not need IPv4 connectivity to the IPv4 Internet.

I wonder whether the client-side 464XLAT implementation is open-source?
  Is it a kernel module or userspace?  Is there an option "464XLAT
support" in the kernel?  Or maybe there is no client-side 464XLAT (and
all happens in the network)?  Or maybe it is a binary in the modem that
implements 464xlat, and not the open-source in the linux.

Le 19/09/2017 à 14:23, JORDI PALET MARTINEZ a écrit :
> However, this transition mechanism is the one that has a bigger 
> deployment in terms of number of subscribers using it (hundreds of 
> millions), which I think is even more than ALL the other transition 
> mechanism together.
> 
> Doesn’t make any sense, in my opinion to keep it as an informational 
> document, while we have many others that are standards track and 
> don’t have such level of deployment.
> 
> I was commenting this last week with a couple of the co-authors of 
> this document, and they have the same opinion.
> 
> Regards, Jordi
> ********************************************** 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: Alexandre Petrescu <[email-masked]>
Date: Tue, 19 Sep 2017 23:15:53 +0200

Hi Fred,

Let me comment.

Le 19/09/2017 à 22:41, Fred Baker a écrit :
> Chair hat off.
> 
> If it were ONLY about IPv4, I might agree with you, or suggest
> another working group. 464XLAT is about connecting an IPv6-only
> (subset of a) network to an IPv4 network,

If it is an IPv6-only (subset of a) network then it must run DHCPv6-PD 
to get a prefix.  DHCPv6-PD is Standards Track.  I did not see DHCPv6-PD 
on networks where 464XLAT is present.

Second, when you say connecting IPv6-only network to an IPv4-only 
network: GTPU does that already.

A pure IPv6 IoT device that does not run 464XLAT connects to a cellular 
network and its IPv6 traffic gets encap/decap into an IPv4 network by 
using IPv6-in-GTP.  GTP is an IPv4 protocol.

A packet dump sent by the IPv6 IoT Router and captured on the PGW looks 
like this.  This capture was run on a network that does not use 464XLAT.

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.

Alex

---

From: Owen DeLong <[email-masked]>
Date: Tue, 19 Sep 2017 18:30:47 -0300

> On Sep 19, 2017, at 6:15 PM, Alexandre Petrescu <[email-masked]> wrote:
> 
> Hi Fred,
> 
> Let me comment.
> 
> If it is an IPv6-only (subset of a) network then it must run DHCPv6-PD to get a prefix.  DHCPv6-PD is Standards Track.  I did not see DHCPv6-PD on networks where 464XLAT is present.

This statement simply isn’t true.

Lots of IPv6 only networks exist that do not use DHCP at all.

Owen

---

From: Fred Baker <[email-masked]>
Date: Tue, 19 Sep 2017 17:02:54 -0700

> On Sep 19, 2017, at 2:15 PM, Alexandre Petrescu <[email-masked]> wrote:
> 
> Hi Fred,
> 
> Let me comment.
> 

Let's agree that it has to have a prefix. T-Mobile, for example, has a prefix. Cameron Byrne, from T-Mobile, is a co-author of 464XLAT.

> Second, when you say connecting IPv6-only network to an IPv4-only network: GTPU does that already.

Which is great if you're going to a mobile network. If you're going anywhere else on the Internet, a mobile-only protocol doesn't do much for you. That's why we defined 464XLAT.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 20 Sep 2017 10:40:25 +1000

In message <[email-masked]>, Fred Baker writes:
> > Le 19/09/2017  22:41, Fred Baker a crit :
> >> Chair hat off.
> Let's agree that it has to have a prefix. T-Mobile, for example, has a
> prefix. Cameron Byrne, from T-Mobile, is a co-author of 464XLAT.
>
> Which is great if you're going to a mobile network. If you're going
> anywhere else on the Internet, a mobile-only protocol doesn't do much for
> you. That's why we defined 464XLAT.

We defined 464XLAT because people deployed DNS64/NAT64 despite all
its flaws because the proponents of DNS64/NAT64 made lots of claims
that failed to eventuate in reality.  464XLAT exists to work around
the limitations of DNS64/NAT64.

Claims like we don't need to make changes to the node, yet we have
a CLATs being installed in every node.

Claims like DNS64 is the only way to move traffic to IPv6.  Traffic
moves to IPv6 just fine using address sorting.

Claims like we will naturally know when to turn off the DNS64/NAT64
but we can't do that with any other method.  Hogwash.

Now we have a complicated encapsulation/translation scheme that
requires payload translation at both ends being promoted over simple
IPv4 in IPv6 encapsulation.  464XLAT has zero benefits over simple
IPv4 in IPv6 encapsulation.

Complicated -> more bugs, more testing required, more cost and
reluctance to go to IPv6 at all.

NAT64 and 464XLAT makes it impossible to write a new protocol that
embeds IP addresses based on the transport being used.

All of DNS64, NAT64 and 464XLAT should be made historic despite
their prevalence.  They are all bad engineering.

Yes, this is betamax vs vhs.  Unfortunately we don't have DVD's
coming along to wipe out the bad market decision.  We are going
to be left with the consequences of this bad engineering for
decades to come.

Mark

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

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 19 Sep 2017 21:44:39 -0300

I will wait for the authors to confirm, but if they don’t have the energy, I’m ready to volunteer for that.

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: martes, 19 de septiembre de 2017, 17:37
Para: <[email-masked]>
Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info

    
         Brian

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 19 Sep 2017 21:51:33 -0300

I’ve deployed 464XLAT in cellular networks with SLAAC but also with DHCPv6-PD using LTE “routers”. Same for residential networks.

I don’t think one or the other is relevant to the suggestion I’m doing about reclassifying it as standard.

If you do it with SLAAC, as described in the RFC, the NAT46 will be stateful (by means of a previous NAT44) because you don’t have a specific /64 for the translation. Otherwise will be stateless.

The CLAT, which is the “client” side (run in a cellular phone or a CPE or OS), is available in open source. Just look at the OpenWRT implementation, but I’m sure there are others.

Regards,
Jordi

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

    

    Alex
    
    PS: if you have time:

---

From: David Schinazi <[email-masked]>
Date: Tue, 19 Sep 2017 18:10:31 -0700

> On Sep 19, 2017, at 17:51, JORDI PALET MARTINEZ <[email-masked]> wrote:
> 

I don't think that's correct. In order to make 464XLAT stateless you need a separate /128, not /64. And SLAAC allows you to generate that extra /128. As far as I know, this is how Android works.

As far the discussion of changing the Category of the RFC, I'm not sure what it accomplishes, and whether it's worth spending time on.

David

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 19 Sep 2017 22:34:11 -0300

I think you may be right, it makes sense that a single /128 will be able to allow that, but I think it is clear that needs to be a different one that the CLAT WAN interface. I guess the authors indicated a separated /64 as it seems easier to allocate it than a single address if you’re using DHCPv6-PD. I was just recalling what is in the actual RFC:

6.3.  IPv6 Prefix Handling

   There are two relevant IPv6 prefixes that the CLAT must be aware of.

   First, CLAT must know its own IPv6 prefixes.  The CLAT should acquire
   a /64 for the uplink interface, a /64 for all downlink interfaces,
   and a dedicated /64 prefix for the purpose of sending and receiving
   statelessly translated packets.  When a dedicated /64 prefix is not
   available for translation from DHCPv6-PD [RFC3633], the CLAT may
   perform NAT44 for all IPv4 LAN packets so that all the LAN-originated
   IPv4 packets appear from a single IPv4 address and are then
   statelessly translated to one interface IPv6 address that is claimed
   by the CLAT via the Neighbor Discovery Protocol (NDP) and defended
   with Duplicate Address Detection (DAD).

Regards,
Jordi

-----Mensaje original-----
De: <[email-masked]> en nombre de David Schinazi <[email-masked]>
Responder a: <[email-masked]>
Fecha: martes, 19 de septiembre de 2017, 22:21
Para: <[email-masked]>
CC: <[email-masked]>
Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info

    
    
    David

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 20 Sep 2017 07:04:10 +0200

> Lots of IPv6 only networks exist that do not use DHCP at all.

I mean IPv6 subnet like a cellular-WiFi-Ethernet small router.  That is 
mobile, needs a prefix.

And I mean DHCPv6-PD, not DHCP.

Those IPv6 networks that dont need PD are those that are not mobile.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 20 Sep 2017 07:07:28 +0200

Le 20/09/2017 à 02:02, Fred Baker a écrit :
>>> Chair hat off. If it were ONLY about IPv4, I might agree with
>>> you, or suggest another working group. 464XLAT is about
>>> connecting an IPv6-only (subset of a) network to an IPv4
>>> network,
>> 
>> If it is an IPv6-only (subset of a) network then it must run
>> DHCPv6-PD to get a prefix.  DHCPv6-PD is Standards Track.  I did
>> not see DHCPv6-PD on networks where 464XLAT is present.
> 
> Let's agree that it has to have a prefix. T-Mobile, for example, has
> a prefix. Cameron Byrne, from T-Mobile, is a co-author of 464XLAT.

Hello to Mr. Byrne.

That prefix is not DHCPv6-PD.

That prefix is an INFORMATIONAL method that is 64share.

The StdsTrack method is DHCPv6-PD.

If one looks at making 464XLAT StdsTrack one also considers 64share to 
go StdsTrack.

> anywhere else on the Internet, a mobile-only protocol doesn't do much
> for you. That's why we defined 464XLAT.

Well, I dont think 464XLAT is deployed anywhere else than on cellular. 
These are the big numbers that the Original Poster talked about: 
miliions of users - they are on cellular.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 20 Sep 2017 07:16:22 +0200

Le 20/09/2017 à 02:51, JORDI PALET MARTINEZ a écrit :
> I’ve deployed 464XLAT in cellular networks with SLAAC but also with 
> DHCPv6-PD using LTE “routers”.

I would like to ask you which LTE modem was inside the LTE router?
Because the Balong modem in some Huawei smartphones, and the some
Qualcomm MDM8xxxx series in some IoT devices block DHCPv6 messages.

Was the LTE network providing a DHCPv6-PD server?

> Same for residential networks.

Residential network is a different matter.

The residential network I live on is not 464XLAT.  And that has some 
users too.

> I don’t think one or the other is relevant to the suggestion I’m 
> doing about reclassifying it as standard.

Why?

> If you do it with SLAAC, as described in the RFC,

Jordi - one cant get a prefix with SLAAC.  If there's some
RFC saying the contrary then that's INFORMAITONAL and should stay that way.

> the NAT46 will be stateful (by means of a previous NAT44)

I guess we dont want either kind of NATx to be any form of StdsTrack.

> because you
> don’t have a specific /64 for the translation. Otherwise will be
> stateless.
> 
> The CLAT, which is the “client” side (run in a cellular phone or a 
> CPE or OS), is available in open source. Just look at the OpenWRT 
> implementation, but I’m sure there are others.

OpenWRT is made for residential networks, not for cellular.

For example, it has an 'odhcp' client very thin which is very good.  But 
it takes time and effort to bring it to cellular modem.  The modem is 
different in cellular vs residential gw.  The size of devices is maybe 
an order of magnitutde different (think set-top-box vs matchbox).

I am not sure which part of OpenWRT (a whole OS distribution) you mean 
for 'CLAT'.  Is there some CLAT command line.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 20 Sep 2017 07:26:01 +0200

Le 20/09/2017 à 03:34, JORDI PALET MARTINEZ a écrit :
>     a /64 for the uplink interface, a /64 for all downlink interfaces

Why does it say '/64'?  Why not '/63'?

>     available for translation from DHCPv6-PD [RFC3633],

In cases where this is not available it's because it is a chicken and 
egg problem.

Some modem manufacturers say that because IETF does recommend RA instead 
of DHCP then they stop forwarding DHCP through their modems.  They 
wrongly understand what IETF recommends.  We have to go through tedious 
emails among us in v6ops to explain what really the recommendation is 
with respect to DHCPv6 vs RA.

Some operator say that because modems dont support then operator does 
not deploy DHCPv6-PD.

Some people say that modem should not do any sort of IP related stuff, 
whereas the modem people say that's the only way they can build one 
modem able to connect to so many different cellular network (it's not 
only the frequencies and codecs that change but also the way they set up 
the connections).

One should also know that at some point some modem did implement somehow 
correctly some DHCPv6 form of 'proxy', yet that became to block DHCPv6 
altogether recently.

> the CLAT may
>     perform NAT44 for all IPv4 LAN packets

'may'?  Or MAY?

Make NATx a StdsTrack?

Alex

> so that all the LAN-originated

---

From: Erik Kline <[email-masked]>
Date: Wed, 20 Sep 2017 15:03:24 +0900

There seem to be some misconceptions flying around here.

> Well, I dont think 464XLAT is deployed anywhere else than on cellular. These
> are the big numbers that the Original Poster talked about: miliions of users
> - they are on cellular.

464xlat is a client-side bit of code (the NAT64+DNS64 in the network
is the "other half").  It is primarily implemented in mobile devices,
and primarily in Android, to be more specific.

As such, the number of 464xlat capable nodes is numbered in the /billions/.

There are also some wifi (and wired) networks that are IPv6-only with
NAT64+DNS64; mobile networks aren't the only ones.

NAT64+DNS64 is easily the single most successful IPv6 transition
technology on the planet ([a] if one excludes "dualstack", [b] queue
the Sean Spicer jokes).  464xlat can help ease things on the client
side, but it's not the only way to do it (cf. iOS).

---

From: "t.petch" <[email-masked]>
Date: Wed, 20 Sep 2017 10:41:38 +0100

----- Original Message -----
From: "Fred Baker" <[email-masked]>
To: "JORDI PALET MARTINEZ" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, September 19, 2017 9:27 PM

> Hmm. Wearing the chair hat, but not making pronouncements. Thinking
through the options and considerations.

Fred

What was the final resolution of the IPR claim by China Mobile relating
to this work that caused much bemusement at the time of the approval
thereof and which also may have been a factor in changing the status
from BCP to Informational?

Tom Petch

> I would agree that informational status is probably inappropriate at
this point. I'll note that the progression is not all that unusual; GRE,
for example, was originally informational (RFC 1701), was taken to
Proposed Standard in RFC 2784, and has been updated by RFC 2890. If it
were taken to Internet Standard, we would need to demonstrate the points
raised in https://tools.ietf.org/html/rfc6410#section-2.2.
>
> What gives me pause in using the PS/IS standards track is the issue of
interoperation of multiple implementations. I'm not entirely sure what
that means in an operational procedure or service, which is in my
perception what 464XLAT is. If that is the interoperation of multiple
networks, it might be the interoperation of an IPv6-only (subset of a)
network with other IPv4 networks, as the interoperation of that same
network with IPv6 networks or networks with IPv6 capabilities doesn't
require such services. The description of a BCP in RFC 2026 sounds more
like what we're looking at here.
>
> My thought at the moment (which I can be argued out of) is that the
right status is BCP, and that we would want an updated document that
captures anything we have learned since RFC 6877 was published.
> > Doesn’t make any sense, in my opinion to keep it as an informational
document, while we have many others that are standards track and don’t
have such level of deployment.
> > Can we even consider moving it to STD?
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: Alexandre Petrescu <[email-masked]>
Date: Wed, 20 Sep 2017 14:54:59 +0200

No need to stress terms like billions; that's what modem manufacturers 
put on the market too routinely.  Maybe we can talk trillions of IoT 
devices.  Maybe we can use the SI prefixes, like exa, or peta.

That aside, I would like to ask you whether the CLAT src on Android is 
something I could look at?

Alex

---

From: Erik Kline <[email-masked]>
Date: Wed, 20 Sep 2017 22:17:29 +0900

https://android.googlesource.com/platform/external/android-clat/

On 20 September 2017 at 21:54, Alexandre Petrescu
<[email-masked]> wrote:
> No need to stress terms like billions; that's what modem manufacturers put
> on the market too routinely.  Maybe we can talk trillions of IoT devices.
> Maybe we can use the SI prefixes, like exa, or peta.
>
>>> These

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 20 Sep 2017 10:19:15 -0300

Google is your friend:

Same for other questions that you asked before … you can find it also for OpenWRT.

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Alexandre Petrescu <[email-masked]>
Responder a: <[email-masked]>
Fecha: miércoles, 20 de septiembre de 2017, 9:55
Para: Erik Kline <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info

    
    Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 20 Sep 2017 15:28:05 +0200

> https://android.googlesource.com/platform/external/android-clat/

Google is my friend.

Ctrl-F also, and that page does not seem to display any correction that 
says "DHCP" in the last 3 and a half years.

But I think CLAT should run DHCP somehow, otherwise it's a non standard 
way to get Prefix Delegation.  Does it?  (I may download it later and 
look at it).

As long as these two things stay distinct they are in competition.

Once you make 464XLAT StdsTrack you cant also keep DHCPv6-PD as 
StdsTrack - they are on the same layer.

But yes, you can keep XMPP on the StdsTrack, because it's on another layer.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 20 Sep 2017 15:34:20 +0200

> Same for other questions that you asked before … you can find it also for OpenWRT.

Jordi, please let me ask again: I would like to ask you which LTE modem 
was inside the LTE router?

Because the Balong modem in some Huawei smartphones, and some
Qualcomm MDM8xxxx series in some IoT devices block DHCPv6 messages.

OpenWRT is an OS, not a  modem.  An OS runs on many kinds of modems. 
Some modems block DHCP altogether.

You cant just redirect me to OpenWRT.

Alex

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 20 Sep 2017 10:35:21 -0300

Why you try to mix things?

CLAT is a transition mechanism. SLAAC or DHCPv6 (-PD) is a way to provision addresses/prefixes.

No sense to mix all them.

Many other transition mechanisms don’t state if SLAAC or DHCPv6 is used or not, and I think is perfectly correct.

Regarsd,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Alexandre Petrescu <[email-masked]>
Responder a: <[email-masked]>
Fecha: miércoles, 20 de septiembre de 2017, 10:28
Para: <[email-masked]>
Asunto: Re: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: reclassify 464XLAT as standard instead of info

    
    Google is my friend.

    

    
    Alex

---

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

Don’t know the chipset hardware details.

In our trials, they were several models from well know Chinese vendors.

I really doubt chipsets block DHCPv6 messages. You should contact those chipset vendors and make sure about that.

https://github.com/openwrt-routing/packages/blob/master/nat46/files/464xlat.sh

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Alexandre Petrescu <[email-masked]>
Responder a: <[email-masked]>
Fecha: miércoles, 20 de septiembre de 2017, 10:34
Para: <[email-masked]>
Asunto: Re: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: reclassify 464XLAT as standard instead of info

    

    
    
    Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 20 Sep 2017 15:44:21 +0200

> Why you try to mix things?

I dont mix.  You want a unique STdsTRack.  Do you think the place is empty?

As I said already, there is already IPv6-in-GTP for transitioning and 
DHCPv6-PD for Prefix Delegation.  These are standards.

> No sense to mix all them.

That's a problem.  You want them to work  together, not to compete.

You want them to have different functions.

But the function to get a prefix is a unique function.

> Many other transition mechanisms don’t state if SLAAC or DHCPv6 is used or not, and I think is perfectly correct.

Most of them are not dynamic in nature anyways, whereas CLAT seems to be.

As long as they dont claim, and they abstain from to dynamically set a 
prefix on the network they are fine with respect to DHCP-PD.

But once CLAT gets into statements qualifying which is better 
SLAAC-vs-DHCP then we have a big problem.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 20 Sep 2017 15:50:23 +0200

> Don’t know the chipset hardware details.

We cant make statements of functionality if we dont know which platform 
supports it.

> In our trials, they were several models from well know Chinese

Which ones?  Is Balong among them?

> I really doubt chipsets block DHCPv6 messages.

Jordi - I doubted too.  But then I checked.  I worked with operator and 
hw manufacturer.  I got advice from v6ops members.  We issued DHCP 
packets from linux and captured what arrives at PGW.  After months of 
test, I tell it is extremely likely the modem blocks.  Operator informs 
me it is extremely unlikely the BS, SGW and PGW blocks DHCP.  The linux 
does not block anything, it's open source, I checked.

What modems block is the following: std DHCP ports, multicast IP dst 
address of DHCP.  What modems dont block is the following: DHCP packets 
sent on non-std DHCP ports, or on unicast addresses.

There is no open source for these modems.

> You should contact
> those chipset vendors and make sure about that.

YEs, done that.  After discussion I can say that they feel like it's 
good to block it; they sometimes say "because that's the design".  I 
dont know what the design is that, but DHCPv6-PD is certainly not a 
design to block.

I wonder where do the modem manufacturers get the idea that a good 
design is one that does not do DHCP.

Alex
> -----Mensaje original----- De: v6ops <[email-masked]> en
> nombre de Alexandre Petrescu <[email-masked]> Responder
> a: <[email-masked]> Fecha: miércoles, 20 de septiembre
> de 2017, 10:34 Para: <[email-masked]> Asunto: Re: [v6ops] [*SPAM*
> Score/Req: 3.9/3.3] Re: reclassify 464XLAT as standard instead of
> info
> 
> 
> 
> Jordi, please let me ask again: I would like to ask you which LTE
> modem was inside the LTE router?
> 
>> -----Mensaje original----- De: v6ops <[email-masked]> en
>> nombre de Alexandre Petrescu <[email-masked]> 
>> Responder a: <[email-masked]> Fecha: miércoles, 20 de
>> septiembre de 2017, 9:55 Para: Erik Kline <[email-masked]> CC:
>> "[email-masked]" <[email-masked]> Asunto: Re: [v6ops] reclassify
>> 464XLAT as standard instead of info
>> 
>> No need to stress terms like billions; that's what modem
>> manufacturers put on the market too routinely.  Maybe we can talk
>> trillions of IoT devices.  Maybe we can use the SI prefixes, like
>> exa, or peta.
>> 
>> That aside, I would like to ask you whether the CLAT src on Android
>> is something I could look at?
>> 
>> Alex
>> 
>>>> Well, I dont think 464XLAT is deployed anywhere else than on
>>>> cellular. These are the big numbers that the Original Poster
>>>> talked about: miliions of users - they are on cellular.
>>> 
>>> 464xlat is a client-side bit of code (the NAT64+DNS64 in the
>>> network is the "other half").  It is primarily implemented in
>>> mobile devices, and primarily in Android, to be more specific.
>>> 
>>> There are also some wifi (and wired) networks that are IPv6-only
>>> with NAT64+DNS64; mobile networks aren't the only ones.
>>> 
>>> technology on the planet ([a] if one excludes "dualstack", [b]
>>> queue the Sean Spicer jokes).  464xlat can help ease things on
>>> the client side, but it's not the only way to do it (cf. iOS).
>>> 
>> 
>> 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

---

From: Owen DeLong <[email-masked]>
Date: Wed, 20 Sep 2017 12:13:10 -0300

> On Sep 20, 2017, at 10:44 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> 

I’m not sure where you get “unique”. I think Jordi wants 464XLAT moved to Standards track rather than informational. I don’t see anything about unique in his request.

> As I said already, there is already IPv6-in-GTP for transitioning and DHCPv6-PD for Prefix Delegation. These are standards.

I guess the question I have for this statement is “why is this relevant to whether or not we move 464XLAT
to standard?”

> That's a problem.  You want them to work  together, not to compete.

This makes no sense to me. IMHO, they don’t compete and CLAT can work regardless of how the IPv6 address on the client is obtained, whether SLAAC, DHCPv6, static, or otherwise.

> You want them to have different functions.

CLAT doesn’t have an IPv6 address assignment function so they do, in fact, have different functions.

> But the function to get a prefix is a unique function.

CLAT doesn’t have anything to do with getting a prefix for IPv6.

> Most of them are not dynamic in nature anyways, whereas CLAT seems to be.

My understanding is that CLAT is dynamic only on the IPv4 side. On the IPv6 side, to the best of my knowledge, it just uses whatever IPv6 address is available on the client’s interface(s).

> As long as they dont claim, and they abstain from to dynamically set a prefix on the network they are fine with respect to DHCP-PD.
> 
> But once CLAT gets into statements qualifying which is better SLAAC-vs-DHCP then we have a big problem.

Sigh… I agree that there’s no reason for CLAT to make any such statement. If the current CLAT RFC(s) do, then, perhaps we should argue for cleaning that up as part of the process of moving towards a standards track RFC, but if that’s what you’re on about here, then just say that. You’ve wasted multiple messages talking about completely orthogonal issues where the above statement is the first clue you’ve provided about what is apparently your actual concern.

Owen

> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>

---

From: Erik Kline <[email-masked]>
Date: Thu, 21 Sep 2017 00:21:46 +0900

> Ctrl-F also, and that page does not seem to display any correction that says
> "DHCP" in the last 3 and a half years.
>
> But I think CLAT should run DHCP somehow, otherwise it's a non standard way
> to get Prefix Delegation.  Does it?  (I may download it later and look at
> it).

There is no PD wrt 464xlat.  The /64 is implicitly delegated to the
mobile per the 3GPP architecture, as I'm sure you well know.

If you want to know how the device learns the DNS64/NAT64 prefix then
see https://tools.ietf.org/html/rfc7050 .

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 20 Sep 2017 17:26:22 +0200

Le 20/09/2017 à 17:13, Owen DeLong a écrit :
> 
>> On Sep 20, 2017, at 10:44 AM, Alexandre Petrescu 
> I’m not sure where you get “unique”. I think Jordi wants 464XLAT moved 
> to Standards track rather than informational. I don’t see anything about 
> unique in his request.
> 

BEcause 464XLAT is a transitioning mechanism and IPv6-in-GTP is a 
transitioning mechanism too, which is deployed too.

> This makes no sense to me. IMHO, they don’t compete and CLAT can work 
> regardless of how the IPv6 address on the client is obtained, whether 
> SLAAC, DHCPv6, static, or otherwise.

But you dont want CLAT's IPv6-in-IPv4 together with GTP encapsulation - 
that's too many encapsulations.

> CLAT doesn’t have anything to do with getting a prefix for IPv6.

But it only works with a /64.  It means it cant work when DHCPv6-PD 
gives it a /63.

>>> Many other transition mechanisms don’t state if SLAAC or DHCPv6 is 
>>> used or not, and I think is perfectly correct.
>>
> My understanding is that CLAT is dynamic only on the IPv4 side. On the 
> IPv6 side, to the best of my knowledge, it just uses whatever IPv6 
> address is available on the client’s interface(s).
> 
> Sigh… I agree that there’s no reason for CLAT to make any such 
> statement. If the current CLAT RFC(s) do, then, perhaps we should argue 
> for cleaning that up as part of the process of moving towards a 
> standards track RFC, but if that’s what you’re on about here, then just 
> say that. You’ve wasted multiple messages talking about completely 
> orthogonal issues where the above statement is the first clue you’ve 
> provided about what is apparently your actual concern.

I dont think it's orthogonal.

Alex
>>> De: v6ops <[email-masked] <mailto:[email-masked]>> en 
>>> nombre de Alexandre Petrescu <[email-masked] 
>>> <mailto:[email-masked]>>
>>> Responder a: <[email-masked] 
>>> <mailto:[email-masked]>>
>>> Para: <[email-masked] <mailto:[email-masked]>>
>>>     > Google is your friend:
>>>     >
>>>     > https://android.googlesource.com/platform/external/android-clat/
>>>          Google is my friend.
>>>          >
>>>     > Same for other questions that you asked before … you can find 
>>> it also for OpenWRT.
>>>     >
>>>     > Regards,
>>>     > Jordi
>>>     >
>>>     >
>>>     > -----Mensaje original-----
>>>     > De: v6ops <[email-masked] 
>>> <mailto:[email-masked]>> en nombre de Alexandre Petrescu 
>>> <[email-masked] <mailto:[email-masked]>>
>>>     > Responder a: <[email-masked] 
>>> <mailto:[email-masked]>>
>>>     > Fecha: miércoles, 20 de septiembre de 2017, 9:55
>>>     > Para: Erik Kline <[email-masked] <mailto:[email-masked]>>
>>>     > CC: "[email-masked] <mailto:[email-masked]>" <[email-masked] 
>>> <mailto:[email-masked]>>
>>>     > Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info
>>>     >
>>>     >      No need to stress terms like billions; that's what modem 
>>> manufacturers
>>>     >      put on the market too routinely.  Maybe we can talk 
>>> trillions of IoT
>>>     >      devices.  Maybe we can use the SI prefixes, like exa, or peta.
>>>     >
>>>     >      That aside, I would like to ask you whether the CLAT src 
>>> on Android is
>>>     >      something I could look at?
>>>     >
>>>     >      Alex
>>>     >
>>>     >      Le 20/09/2017 à 08:03, Erik Kline a écrit :
>>>     >      > There seem to be some misconceptions flying around here.
>>>     >      >
>>>     >      >> Well, I dont think 464XLAT is deployed anywhere else 
>>> than on cellular. These
>>>     >      >> are the big numbers that the Original Poster talked 
>>> about: miliions of users
>>>     >      >> - they are on cellular.
>>>     >      >
>>>     >      > 464xlat is a client-side bit of code (the NAT64+DNS64 in 
>>> the network
>>>     >      > is the "other half").  It is primarily implemented in 
>>> mobile devices,
>>>     >      > and primarily in Android, to be more specific.
>>>     >      >
>>>     >      > As such, the number of 464xlat capable nodes is numbered 
>>> in the /billions/.
>>>     >      >
>>>     >      > There are also some wifi (and wired) networks that are 
>>> IPv6-only with
>>>     >      > NAT64+DNS64; mobile networks aren't the only ones.
>>>     >      >
>>>     >      > NAT64+DNS64 is easily the single most successful IPv6 
>>> transition
>>>     >      > technology on the planet ([a] if one excludes 
>>> "dualstack", [b] queue
>>>     >      > the Sean Spicer jokes).  464xlat can help ease things on 
>>> the client
>>>     >      > side, but it's not the only way to do it (cf. iOS).
>>>     >      >
>>>     >
>>>     >      _______________________________________________
>>>     >      v6ops mailing list
>>>     > [email-masked] <mailto:[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 
>>> criminal offense. If you are not the intended recipient be aware that 
>>> any disclosure, copying, distribution or use of the contents of this 
>>> 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] <mailto:[email-masked]>
>>>     > https://www.ietf.org/mailman/listinfo/v6ops
>>>     >

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 20 Sep 2017 17:28:37 +0200

> mobile per the 3GPP architecture, as I'm sure you well know.

I well know 3GPP architecture and 3GPP deployment allows for PD.  That 
is not /64 explicit, and it is any length.

The fact that CLAT wants it to be 64 it is CLAT problem that should be 
solved in CLAT.

> see https://tools.ietf.org/html/rfc7050 .

Noted.

Alex

---

From: Owen DeLong <[email-masked]>
Date: Wed, 20 Sep 2017 16:35:43 -0300

> On Sep 20, 2017, at 12:26 PM, Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> 
>>> On Sep 20, 2017, at 10:44 AM, Alexandre Petrescu <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> 
>>> 
> BEcause 464XLAT is a transitioning mechanism and IPv6-in-GTP is a transitioning mechanism too, which is deployed too.

So what?

ISIS is a Standard and so is OSPF… both are IGPs.
For that matter, so is RIPv2.

There are lots of cases where more than one solution to the same problem becomes a standards track RFC.

For that matter, DHCPv6 and SLAAC are both standards. Both do address assignment.

> But you dont want CLAT's IPv6-in-IPv4 together with GTP encapsulation - that's too many encapsulations.

True, but I don’t want ISIS and OSPF running on the same links, either.

Not sure I understand why this is a relevant topic here. Operators are capable of choosing the standard that best meets their needs from multiple standards. Choice is often a good thing. This is an example of such a case.

> But it only works with a /64.  It means it cant work when DHCPv6-PD gives it a /63.

You’re making no sense here. An interface would still get a /64 from the /63 or /56 or /48 or whatever, so CLAT would still be perfectly capable of operating after the /64 was assigned to the interface.

> I dont think it's orthogonal.

It really is.

Really.

Owen

>>>> De: v6ops <[email-masked] <mailto:[email-masked]>> en nombre de Alexandre Petrescu <[email-masked] <mailto:[email-masked]>>
>>>> Responder a: <[email-masked] <mailto:[email-masked]>>
>>>>     > De: v6ops <[email-masked] <mailto:[email-masked]>> en nombre de Alexandre Petrescu <[email-masked] <mailto:[email-masked]>>
>>>>     > Responder a: <[email-masked] <mailto:[email-masked]>>
>>>>     > Para: Erik Kline <[email-masked] <mailto:[email-masked]>>
>>>>     > CC: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>

---

From: Owen DeLong <[email-masked]>
Date: Wed, 20 Sep 2017 16:37:27 -0300

> On Sep 20, 2017, at 12:21 PM, Erik Kline <[email-masked]> wrote:
> 

Isn’t that an artifact of 3GPP and not 464XLAT?

My understanding is that 464XLAT CLAT can work with any interface that has
a /64 on the interface, regardless of how it was assigned to the interface.

> see https://tools.ietf.org/html/rfc7050 .

If 3GPP is baked into 464XLAT, then I agree we still have work to generalize it
before making it STD.

Owen

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 20 Sep 2017 22:55:01 +0200

Le 20/09/2017 à 21:35, Owen DeLong a écrit :
>>>> <[email-masked] 
>>>> <mailto:[email-masked]>> wrote:
>>>> 
>>>> 
>>>> 
>>> I’m not sure where you get “unique”. I think Jordi wants 464XLAT 
>>> moved to Standards track rather than informational. I don’t see 
>>> anything about unique in his request.
>>>> As I said already, there is already IPv6-in-GTP for 
>>>> transitioning and DHCPv6-PD for Prefix Delegation. These are 
>>>> standards.
>>> I guess the question I have for this statement is “why is this 
>>> relevant to whether or not we move 464XLAT to standard?”
>> 
> ISIS is a Standard and so is OSPF… both are IGPs. For that matter,
> so is RIPv2.

YEs, and each uses some distinct number, maybe a UDP port number.  They
can work simultaneously on a Router.

But you cant have simultaneously CLAT and DHCPv6-PD on the same client.
  Because CLAT wants that to be a /64 prefix.  It will break when the
client gets a /63.

Moreover, design suggestions from CLAT assume that /64 is sufficient.
That is wrong - /64 is not sufficient.

> problem becomes a standards track RFC.

But one wont prohibit the other.

CLAT prohibits DHCPv6-PD.

> For that matter, DHCPv6 and SLAAC are both standards. Both do

Err, I agree.  Yet CLAT does not agree.  CLAT does not rely on DHCP to
get an address.  Why?  IT does not rely on DHCPv6-PD to get a prefix.  Why?

>>>>> CLAT is a transition mechanism. SLAAC or DHCPv6 (-PD) is a 
>>>>> way to provision addresses/prefixes. No sense to mix all 
>>>>> them.
>>>> 
>>> This makes no sense to me. IMHO, they don’t compete and CLAT can 
>>> work regardless of how the IPv6 address on the client is 
>>> obtained, whether SLAAC, DHCPv6, static, or otherwise.
>> 
>> But you dont want CLAT's IPv6-in-IPv4 together with GTP 
>> encapsulation - that's too many encapsulations.
> 

At some point there is some Gateway that is possible, which runs both
protocols OSPF and ISIS.  But there cant be conversion between CLAT and
DHCP.

> Not sure I understand why this is a relevant topic here. Operators 
> are capable of choosing the standard that best meets their needs
> from multiple standards. Choice is often a good thing. This is an
> example of such a case.

Operators are influenced by Device availability.  If Android is what is
available, then operators want to satisfy this.  If Android does CLAT,
then operators choose to not implement DHCPv6-PD, because DHCPv6-PD is
part of DHCPv6, and because CLAT does not need DHCPv6.

I dont know how to explain this better to you.

Android is very important to operators.

> You’re making no sense here. An interface would still get a /64 from 
> the /63 or /56 or /48 or whatever, so CLAT would still be perfectly 
> capable of operating after the /64 was assigned to the interface.

To be tried, before arguing.

Can you try?

Do you think a WiFi tablet behind a smartphone-on-cellular that uses a
prefix obtained with DHCPv6-PD and re-advertised with RA would be able
to get through that CLAT ok, and talk to IPv4 servers?

If you could try this, then we can have an answer on whether or not I
make sense.

Before that, we cant say CLAT and DHCPv6-PD are ok.

>>>>> Many other transition mechanisms don’t state if SLAAC or 
>>>>> DHCPv6 is used or not, and I think is perfectly correct.
>>>> 
>>> My understanding is that CLAT is dynamic only on the IPv4 side. 
>>> On the IPv6 side, to the best of my knowledge, it just uses 
>>> whatever IPv6 address is available on the client’s interface(s).
>>>> As long as they dont claim, and they abstain from to 
>>>> dynamically set a prefix on the network they are fine with 
>>>> respect to DHCP-PD.
>>>> 
>>> statement. If the current CLAT RFC(s) do, then, perhaps we
>>> should argue for cleaning that up as part of the process of
>>> moving towards a standards track RFC, but if that’s what you’re
>>> on about here, then just say that. You’ve wasted multiple
>>> messages talking about completely orthogonal issues where the
>>> above statement is the first clue you’ve provided about what is
>>> apparently your actual concern.
>> 

I tell you it is not.

As long as CLAT does not agree there is DHCPv6-PD and IPv6-in-GTP then
we have little to talk about.

We have a new transition method that appeared just because an OS creator
(Android) is not able, or not willing(?) to push their own suppliers
hardware vendors into implementing forwarding of DHCPv6-PD into their
modems.

Android created a software tool (CLAT) that is totally runnable in the
linux (not in the modem), so it is totally under their control (not
modem) just to avoid the hardware modem problem.  That's not the right
thing to do: the modem has to be fixed.

Android CLAT is also ignoring that IPv6-in-GTP exists (GTP is an IPv4
protocol at 3GPP), because the GTP part happens in the modem, and
Android does not control the modem.

If Android wanted "IPv6-only" devices then the right thing to do is to
create an IPv6 version of GTP, or, even better, get rid of GTP
altogheter.  But that again - it's in the modem.

Nothing of this is orthogonal to CLAT: CLAT does some things because the
modem is forcing it into doing.

Alex

---

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

> CLAT prohibits DHCPv6-PD.

RFC6877 section 6.3 states the opposite.

Ole

---

From: Ca By <[email-masked]>
Date: Wed, 20 Sep 2017 22:29:39 +0000

Alexandre,

There are several statements you made that i not consistent with my
understanding.

> >> transitioning mechanism too, which is deployed too.

IPv6-in-GTP is a transport mechanism with mobility. It does not help an
ipv6-only node communicate with an ipv4 internet.

That said, my deployment includes both IPv6-in-GTP and 464xlat
simulatenously

> But you cant have simultaneously CLAT and DHCPv6-PD on the same client.

I do not agree,  Please state what is structurally preventing this.
RFC6877 specifically calls for using dhcpv6-pd

>   Because CLAT wants that to be a /64 prefix.  It will break when the

It requires a /64, which may come to the CLAT via a /56 via dhcpv6-pd

> That is wrong - /64 is not sufficient.

It is sufficient for CLAT function of execuating rfc6145. CLAT just
rfc6145.

> CLAT prohibits DHCPv6-PD.

Not correct.

> protocols OSPF and ISIS.  But there cant be conversion between CLAT and

Not correct, again. Please see rfc6877.

> Operators are influenced by Device availability.

This operator (and esteamed co-authors)  saw a problem, came to the ietf,
worked with Android open source, worked with v6ops, and specified 464xlat.

Device availabilty followed.

If Android is what is
> part of DHCPv6, and because CLAT does not need DHCPv6.

Again. Dhcpv6-pd and 464xlat are compatible and their deployment
motivations are largely orthogonal.

> > capable of operating after the /64 was assigned to the interface.

Owen is correct here.

> To be tried, before arguing.

Seems you are the one interested in this area.

The Android source code is available for you.

> Before that, we cant say CLAT and DHCPv6-PD are ok.

We can say the specification allows CLAT and DHCPv6-PD to work together.
Running code is an exercise left to those with a demand for that usecase.

> >> I dont think it's orthogonal.

agreeing with Owen, it is orthogonal.

> we have little to talk about.

3 different things

CLAT is just rfc6145

Ipv6-in-GTP is just an ip in UDP tunnel for mobility in 3gpp
infrastructure, it has nothing to do with the internet or the UE

Dhcpv6-pd ... assignes prefixes.

3 different and orthogonal things.

> hardware vendors into implementing forwarding of DHCPv6-PD into their

Again, 464xlat was not pushed by Android, it was pulled by operators in the
ietf

> thing to do: the modem has to be fixed.

Modem is the wrong place ...

---

From: Owen DeLong <[email-masked]>
Date: Wed, 20 Sep 2017 23:20:04 -0300

> On Sep 20, 2017, at 5:55 PM, Alexandre Petrescu <[email-masked]> wrote:
> 
>>>> I guess the question I have for this statement is “why is this relevant to whether or not we move 464XLAT to standard?”

I suppose you could, technically, run ISIS and OSPF on the same router at the same time, but down that path lies madness.

> Because CLAT wants that to be a /64 prefix.  It will break when the

Again, I don’t entirely buy this because if the client gets an IA_PD /63, I’m not sure CLAT cares. CLAT cares about either the IA_NA or the interface address assigned by the DHCP client (which should be a /64).

> That is wrong - /64 is not sufficient.

If you feel strongly about this, publish an ID obsoleting the current CLAT specification and arguing for more than a /64.

> CLAT prohibits DHCPv6-PD.

Continuing to say this doesn’t make it true.

> get an address.  Why?  IT does not rely on DHCPv6-PD to get a prefix.  Why?

Neither do any Android phones, nor do the vast majority of systems that I administer.

What’s your point?

IMHO, no protocol should _RELY_ on DHCPv6 or DHCPv6_PD, but, instead, they should all function regardless of the mechanism by which addresses are assigned. Arguably you could say that insisting a link is a /64 is not valid and you might have a case there, but even there, I think for some things, that ship has sailed.

>>>>>> CLAT is a transition mechanism. SLAAC or DHCPv6 (-PD) is a way to provision addresses/prefixes. No sense to mix all them.

Right, because CLAT doesn’t assign addresses and DHCP doesn’t provide a gateway between IPv4 and IPv6.

That’s sort of like saying there can’t be conversion between RIP and TELNET.

It’s true, but I’m not sure why it matters.

>> Not sure I understand why this is a relevant topic here. Operators are capable of choosing the standard that best meets their needs

Sorry, but this is absurd logic.

The reason operators choose not to implement DHCPv6-PD in android-centric networks is because Android doesn’t support DHCPv6. That is a completely orthogonal issue to whether android supports 464XLAT/CLAT or not.

That would be sort of like saying “Because my linux system is running Quagga and speaks OSPF, it can’t handle SSH sessions.”

The lack of DHCPv6 on Android devices is (as near as I can tell) largely a religious position taken by Lorenzo.

This situation existed long before CLAT and if they chose to put DHCPv6 clients on Android, it wouldn’t eliminate their ability to run CLAT.

> I dont know how to explain this better to you.

I’m not the one who seems to be misunderstanding the situation.

> Android is very important to operators.

And? Android supports 464XLAT. It’s not going to support DHCPv6 until someone convinces Lorenzo (or someone above him at Alphabits) to do so. Support could be added without breaking 464XLAT/CLAT, so I really don’t see why you are connecting these two things other than perhaps in your mind they are connected because Lorenzo was also one of the early backers of 464XlAT.

> to get through that CLAT ok, and talk to IPv4 servers?

I don’t see why not. Admittedly, I don’t bother to try, I have enough IPv4 addresses on the networks I run that dual stack is a perfectly viable solution and the idea of all of these silly variants of the NAT shell game just turn my stomach. However, I recognize the real need in the real world for them.

Now, a counter-question… Do you think a WiFi tablet behind that same smart-phone-on-cellular that gets its address via static or some other address assignment mechanism would have the same difficulty? If not, why not?

> Before that, we cant say CLAT and DHCPv6-PD are ok.

You’re making the bold assertion that CLAT fails if the /64 on the interface is assigned by some mechanism other than 64share. As far as I’m concerned, it’s not my responsibility to prove that assertion false, it’s up to you to provide some factual basis behind the assertion and/or some proof that it is valid.

> modem is forcing it into doing.

Probably now is the time for us to (as usual) agree to disagree…

Regardless of the reason CLAT was created, it is now widely deployed and very popular. It is a pragmatic solution. Deploying it does not break any of the protocols that are near and dear to your heart. It provides an optional way to deal with circumstances where those protocols are not the best choice for the operator regardless of the reasons behind that.

Would it be nice to get the modem vendors to fix the silicon? Sure. But reality check here… They’re not going to retroactively replace the silicon in billions of smart phones even if they can be convinced to correct future chipsets. As such, the “right thing” is completely infeasible in the real world.

So again, I say that fixing the chipsets, DHCPv6, and IPv6-in-GTP are all orthogonal to this discussion because there is no inherent conflict in deploying CLAT on the phone, it simply provides yet another option for accomplishing a similar task.

In fact, unless I misunderstood IPv6-in-GTP, 464XLAT solves a different problem than IPv6-in-GTP in that IPv6-in-GTP provides (roughly) the cellular equivalent of a 6in4 tunnel rather than providing a mechanism for an IPv6-only device to speak to an IPv4 device at the far end.

Owen

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 21 Sep 2017 06:54:02 +0200

Le 20/09/2017 à 23:41, Ole Troan a écrit :
>> But you cant have simultaneously CLAT and DHCPv6-PD on the same
>> client. Because CLAT wants that to be a /64 prefix.  It will break
>> when the client gets a /63.
>> 
>> Moreover, design suggestions from CLAT assume that /64 is
>> sufficient. That is wrong - /64 is not sufficient.
>> 

Ole,

RFCs are one thing, and I agree with you.  And here we do RFCs.

But very much of what RFCs do is from implementations.

It's hard to claim RFC this and RFC that if on the other hand it is 
clear that Android blocks[*] DHCPv6 straight.  It looks like we would 
stick our head in the sand.

Androids are very numerous devices, and RFCs are less numerous.

Here, in this operations group, there is need that Android accepts these
RFCs.

And we need that before we even talk moving an Android-only CLAT from
INFORMATIONAL to something else.

Alex
PS: to support the claim that Android explicitely blocks DHCPv6, I can
provide pointers to public Google pages, numerous requests of DHCPv6
integration in Android (to avoid need of 'rooting' the devices), the
availability of DHCPv6 app in Android store that runs only on WiFi and
must 'root', invitations from competitor OSs to bring DHCPv6 there
instead of Android, and more.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 21 Sep 2017 07:22:29 +0200

In this email, the important part are at the beginning.  The rest is 
repetition.

Le 21/09/2017 à 00:29, Ca By a écrit :
[...]

> ipv6-only node communicate with an ipv4 internet.

It helps to transport the IPv6 packets through the intermediary network 
that is IPv4-only.  The intermediary network is made of modem, base 
station, SGW and PGW.  The linux part is not the modem.
> That said, my deployment includes both IPv6-in-GTP and 464xlat 

So, you have 2 encapsulations, right?

[...]
> RFC6877 specifically calls for using dhcpv6-pd

RFC is one thing, but many implementations block some RFCs.

What structurally prevents this is that there are very numerous Android 
devices.

Each of these Android device has a structural risk if it wants to 
'root'.  If the 'root' operation fails you can structurally through it 
out a window.

Android refuses to include DHCPv6-PD client in the main OS (public URL 
available upon request).  Because of that, one has to 'root' the device 
in order to include it.

Second, the modem part of many Android devices block DHCPv6.  Private 
indication of the dhcpv6 file blocking it is available upon request.  It 
is confidential information.  The rights are to Qualcom and Balong.

On another hand, I would like you to ask me what structurally does _not_ 
prevent Android to run DHCPv6-PD.  If you did, I would tell you this: 
the operator does not oppose running DHCPv6-PD (some already run); 
operator does not block DHCPv6 std ports, nor DHCPv6 std multicast; 
router manufacturer does offer DHCPv6-PD server in the infrastructure; 
open source software does exist for DHCPv6-PD server; 3GPP specs do tell 
DHCPv6-PD should run; Android app DHCPv6 does exist on Store; many 
flavors of DHCPv6-PD software was compiled and run on Android.

> It requires a /64, which may come to the CLAT via a /56 via dhcpv6-pd

It "can"?

I dont think it can.  See above the reasons.  Basically, Android opposes 
the inclusion of DHCPv6 software altogether in their code.

DHCPv6-PD can not run without DHCPv6 code.

But if you are afraid of IA_NA, dont mistake: DHCPv6 code has an option 
called IA_PD (or -P in some implementations) that makes that even if the 
DHCPv6 entire binary is present on the file system, only the IA_PD part 
is called (not the IA_NA).

That's why we have to be careful with words like "it can", or "is 
orthogonal to", or "is independent of", or "CLAT regardless of RA or DHCP".

It's not that way.  It is that CLAT means no DHCP.

> It is sufficient for CLAT function of execuating rfc6145. CLAT just 

No.

When you make such statement - have you tried?

>     CLAT prohibits DHCPv6-PD.

See above.  CLAT is what makes Android to explicitely not want DHCP.

Because CLAT says "we are independent of SLAAC or DHCP", but they also 
say "so we use _only_ SLAAC".

If you wanted to support your statement, then you showed me some 
implementation in where CLAT and DHCPv6 worked together.  There is no such.

> Not correct, again. Please see rfc6877.

See public URL in which discussion illustrates Android does not want DHCPv6.

See Android app on Android store that runs DHCPv6, but which is not 
integrated in Android.  Running it requires 'root'.

> This operator (and esteamed co-authors)  saw a problem, came to the 
> ietf, worked with Android open source, worked with v6ops, and specified 
> 464xlat.

Another operator has an option in which DHCPv6 is there.

Android blocks that.

Fix Android.

Modem blocks that - fix modem.

> motivations are largely orthogonal.

"Compatible", but have you tried?

> The Android source code is available for you.

That is true to some extent.  SOme smartphone manufacturers do offer the 
source code of their platforms, yes.  Some still not, but will come.

On another hand, in order to make my own OS I must 'root' the device. 
That's a risk.

The other option is that the responsible numerous Android devices take 
pride (not oppose) some RFCs like the ones you mention, before blocking 
them.

> We can say the specification allows CLAT and DHCPv6-PD to work 
> together.  Running code is an exercise left to those with a demand for 
> that usecase.

Promoting an RFC from INFO to StdsTrack demandes usecase.

> agreeing with Owen, it is orthogonal.

Orthogonal.

> Again, 464xlat was not pushed by Android, it was pulled by operators in 
> the ietf

Operators also ask what Android wants.

Operators dont oppose DHCPv6-PD.  3GPP doesnt either.  Yet Android 
refuses DHCPv6-PD.

> Modem is the wrong place ...

Modem manufacturers say differently.

Modem manufacturers do implement IP features.  Sometimes they block 
RFCs, just like Android blocks DHCP too.

But they found a sort of living together: it's the old Host-IMP interface.

The Host (Android) does some stuff assuming their matter is 'orthogonal' 
to the IMP (Qualcom).  However, for the IMP we are not allowed to know 
what it does and for Android we are not allowed to ask them do DHCP.

That's not an interface: it is independence, orthogonality.

That leads to problems.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 21 Sep 2017 07:39:25 +0200

Le 21/09/2017 à 04:20, Owen DeLong a écrit :
[...]

> Again, I don’t entirely buy this because if the client gets an IA_PD 
> /63, I’m not sure CLAT cares.

Yes, not sure either, but have you tried?

Do you understand this 'root' problem?

[...]

> If you feel strongly about this, publish an ID obsoleting the current 
> CLAT specification and arguing for more than a /64.

There is an Analysis of /64 boundary RFC, osme proposal to the Addr 
Archi RFC which has strong opposition too from, err, you will see.

That's done.

> Continuing to say this doesn’t make it true.

There is truth in trying: try it.

> IMHO, no protocol should _RELY_ on DHCPv6 or DHCPv6_PD, but, instead, 
> they should all function regardless of the mechanism by which addresses 
> are assigned.

I can agree with the principle, but in practice the situation may have 
another light.

> Arguably you could say that insisting a link is a /64 is 
> not valid and you might have a case there, but even there, I think for 
> some things, that ship has sailed.

Ship sailed...

> 
>>>>>>> CLAT is a transition mechanism. SLAAC or DHCPv6 (-PD) is a way to 
>>>>>>> provision addresses/prefixes. No sense to mix all them.
>>>>> work regardless of how the IPv6 address on the client is obtained, 
>>>>> whether SLAAC, DHCPv6, static, or otherwise.

On Android, what makes HTTP more successful than Telnet to access remote 
computers is that you dont need root access to run HTTP.

You dont need root access for CLAT to run, but you do for DHCPv6-PD.

> The reason operators choose not to implement DHCPv6-PD in 
> android-centric networks is because Android doesn’t support DHCPv6. That 
> is a completely orthogonal issue to whether android supports 
> 464XLAT/CLAT or not.

Android says CLAT is sufficient.

Please look at the public discussion on public URL about DHCPv6, CLAT, 
and everything.

> 
> That would be sort of like saying “Because my linux system is running 
> Quagga and speaks OSPF, it can’t handle SSH sessions.”
> 
> This situation existed long before CLAT and if they chose to put DHCPv6 
> clients on Android, it wouldn’t eliminate their ability to run CLAT.

I agree.

But I think they dont.

> And? Android supports 464XLAT. It’s not going to support DHCPv6 until 
> someone convinces Lorenzo (or someone above him at Alphabits) to do so. 
> Support could be added without breaking 464XLAT/CLAT, so I really don’t 
> see why you are connecting these two things other than perhaps in your 
> mind they are connected because Lorenzo was also one of the early 
> backers of 464XlAT.

BEcause Lorenzo makes same argument against DHCPv6.

Were Lorenzo (because you name him) to agree DHCPv6 is necessary on 
Android, then many things would change, including CLAT.

If CLAT works ok with DHCPv6-PD, then I have no problem with CLAT.

If CLAT works ok with only 64share (and not with DHCPv6-PD), then I 
disagree with both CLAT and 64share.

That will bring  you even further back, but that's the way it is.

> I don’t see why not. Admittedly, I don’t bother to try, I have enough 
> IPv4 addresses on the networks I run that dual stack is a perfectly 
> viable solution and the idea of all of these silly variants of the NAT 
> shell game just turn my stomach. However, I recognize the real need in 
> the real world for them.
> 
> Now, a counter-question… Do you think a WiFi tablet behind that same 
> smart-phone-on-cellular that gets its address via static or some other 
> address assignment mechanism would have the same difficulty? If not, why 
> not?

I think the smartphone will get a prefix from the operator that is very 
different than the prefix that is assigned on the smartphone interface. 
The tablet will use that prefix to form an address.  The smartphone has 
a different address and prefix on its CLAT-supporting interface.  I am 
afraid there is some non-working there.

I did not try it.  I am stumbling on this 'root' feature.

Make CLAT StdsTrack - but does it work with DHCPv6-PD?

> You’re making the bold assertion that CLAT fails if the /64 on the 
> interface is assigned by some mechanism other than 64share. As far as 
> I’m concerned, it’s not my responsibility to prove that assertion false, 
> it’s up to you to provide some factual basis behind the assertion and/or 
> some proof that it is valid.

That's about the effort - who does the effort.  I did some part of it: I 
shown DHCPv6-PD is possible on cellular, that modems have some problem, 
and that there is a 'root' problem.  All these are questions that were 
raised on the list.

I think it is up on the CLAT proponents to move on StdsTrack to answer 
to questions like: is CLAT compatible with existing protocols.

Its not sufficient to say it's orthogonal.  That does not mean anything.

> Regardless of the reason CLAT was created, it is now widely deployed and 
> very popular. It is a pragmatic solution. Deploying it does not break 
> any of the protocols that are near and dear to your heart.

It does not work with DHCPv6-PD.

  It provides
> an optional way to deal with circumstances where those protocols are not 
> the best choice for the operator regardless of the reasons behind that.
> 
> Would it be nice to get the modem vendors to fix the silicon? Sure. But 
> reality check here… They’re not going to retroactively replace the 
> silicon in billions of smart phones even if they can be convinced to 
> correct future chipsets. As such, the “right thing” is completely 
> infeasible in the real world.

I disagree.  Some look at this seriously.

> 
> So again, I say that fixing the chipsets, DHCPv6, and IPv6-in-GTP are 
> all orthogonal to this discussion because there is no inherent conflict 
> in deploying CLAT on the phone, it simply provides yet another option 
> for accomplishing a similar task.
> 
> In fact, unless I misunderstood IPv6-in-GTP, 464XLAT solves a different 
> problem than IPv6-in-GTP in that IPv6-in-GTP provides (roughly) the 
> cellular equivalent of a 6in4 tunnel rather than providing a mechanism 
> for an IPv6-only device to speak to an IPv4 device at the far end.

For some reason, I think we discussed this already.

Alex

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 21 Sep 2017 14:46:29 +0900

On Wed, Sep 20, 2017 at 10:10 AM, David Schinazi <[email-masked]>
wrote:

> > If you do it with SLAAC, as described in the RFC, the NAT46 will be
> stateful (by means of a previous NAT44) because you don’t have a specific
> /64 for the translation. Otherwise will be stateless.
>
> I don't think that's correct. In order to make 464XLAT stateless you need
> a separate /128, not /64. And SLAAC allows you to generate that extra /128.
> As far as I know, this is how Android works.
>

The NAT46 part of 464xlat is always stateless. Device-originated traffic
does not require any NAT table entries. On Android, the IPv4 stack emits
packets using an IPv4 address in 192.0.0.0/29 and then we statelessly
translate them to IPv6. However, when enabling IPv4 tethering, devices
behind the hotspot are NATed, so that, say, 192.168.43.12 first goes
through stateful NAT44 to 192.0.0.4 before being statelessly translated to
IPv6.

Instead of NAT4464, it would have been possible to use extra IPv6 addresses
to represent the tethered devices. On mobile networks, which provide a
dedicated /64 and guarantee no collisions the implementation could just
statelessly translate 192.168.43.12 to c0a8:2b0c and store that in a
well-known place in the IID somewhere. On networks that have other devices
on them the translation would need to be stateful, and in order to make it
stateless, another prefix could be requested (e.g., via DHCPv6 PD). In
effect that would change NAT4464 back to NAT464

On Android we chose not to do this because of the extra complexity. We
already had to support IPv4 NAT for native IPv4 connections, and it seemed
pointless to save an extra NAT step when the packet always has to go
through a stateful NAT64 anyway.

As far the discussion of changing the Category of the RFC, I'm not sure
> what it accomplishes, and whether it's worth spending time on.
>

+1

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 21 Sep 2017 08:49:41 +0200

Lorenzo - I am not interfering with your discussion, but let me say this.

Le 21/09/2017 à 07:46, Lorenzo Colitti a écrit :
[...]

> Instead of NAT4464, it would have been possible to use extra IPv6 
> addresses to represent the tethered devices.

If you can make DHCPv6-PD software available on Android without needing
to root-risk the device, then I can look at making DHCPv6-PD deliver
these extra addresses.

> On mobile networks, which provide a dedicated /64 and guarantee no
> collisions

Some cellular mobile network provides a dedicated /64 per UE, but also
DHCPv6-PD service, at the same time.  I would like to use that, on Android.

> the implementation could just statelessly translate 192.168.43.12 to
> c0a8:2b0c and store that in a well-known place in the IID somewhere.
> On networks that have other devices on them the translation would
> need to be stateful, and in order to make it stateless, another
> prefix could be requested (e.g., via DHCPv6 PD). In effect that would
> change NAT4464 back to NAT464

I will try to understand that, but see above what I can do.

Alex

> On Android we chose not to do this because of the extra complexity.
> We already had to support IPv4 NAT for native IPv4 connections, and
> it seemed pointless to save an extra NAT step when the packet always
> has to go through a stateful NAT64 anyway.
> 
> As far the discussion of changing the Category of the RFC, I'm not 
> sure what it accomplishes, and whether it's worth spending time on.
> 
> 
> +1
> 
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 21 Sep 2017 15:52:06 +0900

> to root-risk the device, then I can look at making DHCPv6-PD deliver

There's no need for any extra addresses. The traffic is already NATed once
and making IPv4 go from 4464 to 464 is not worth the additional complexity,
particularly because the tethered clients will have end-to-end IPv6.

---

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

Hi,

> On 21 Sep 2017, at 05:54, Alexandre Petrescu <[email-masked]> wrote:
> 
> It's hard to claim RFC this and RFC that if on the other hand it is clear that Android blocks[*] DHCPv6 straight.  It looks like we would stick our head in the sand.
> 

There’s now CLAT support in various Windows platforms too, isn’t there?

I don’t think we should tangle up the address configuration debate with 464XLAT (as much as I’d personally like to see Android support DHCPv6..).

Tim

---

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

Le 21/09/2017 à 08:52, Lorenzo Colitti a écrit :
> On Thu, Sep 21, 2017 at 3:49 PM, Alexandre Petrescu 
>         Instead of NAT4464, it would have been possible to use extra
>         IPv6 addresses to represent the tethered devices.
> 
> 
> There's no need for any extra addresses. The traffic is already NATed 
> once and making IPv4 go from 4464 to 464 is not worth the additional 
> complexity, particularly because the tethered clients will have 
> end-to-end IPv6.

I am not sure how the tethered clients will have end-to-end IPv6 if they 
dont have a prefix dedicated to them.  Or maybe do you propose that to 
be 64share?

Alex

---

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

[...]
> There's no need for any extra addresses. 

I think we should stop here.

Forget CLAT.

Alex

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 21 Sep 2017 10:31:10 +0200 (CEST)

> dont have a prefix dedicated to them.  Or maybe do you propose that to 

That's what android already does, and have done for years. Probably Apple 
iOS devices as well. RFC7278.

-- 
Mikael Abrahamsson    email: [email-masked]

---

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

Le 21/09/2017 à 10:31, Mikael Abrahamsson a écrit :
>> I am not sure how the tethered clients will have end-to-end IPv6 if 
>> they dont have a prefix dedicated to them.  Or maybe do you propose 
>> that to be 64share?
> 
> That's what android already does, and have done for years. Probably 
> Apple iOS devices as well. RFC7278.

So you propose moving 64share to BCP as well?

Alex

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 21 Sep 2017 10:48:35 +0200 (CEST)

On Thu, 21 Sep 2017, Alexandre Petrescu wrote:

>>> dont have a prefix dedicated to them.  Or maybe do you propose that to be 
>>> 64share?
>> 

I am not proposing anything. I have no objections to it being moved to BCP 
though, sounds like a good idea.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 21 Sep 2017 19:20:03 +0900

> I think we should stop here.

No, sorry. We shouldn't forget something that tens of millions of Internet
users use every day.

To be clear: I don't think we need to do anything about 464xlat. We have an
RFC. We have implementations. They work. Nothing special to be done here.
But we should not forget about the technologies that real world networks
are built on. If we do that, the IETF will rapidly become irrelevant.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 21 Sep 2017 12:28:55 +0200

Le 21/09/2017 à 12:20, Lorenzo Colitti a écrit :
> On Thu, Sep 21, 2017 at 5:10 PM, Alexandre Petrescu 
> No, sorry. We shouldn't forget something that tens of millions of 
> Internet users use every day.
> 
> To be clear: I don't think we need to do anything about 464xlat. We have 
> an RFC. We have implementations. They work. Nothing special to be done 
> here. But we should not forget about the technologies that real world 
> networks are built on. If we do that, the IETF will rapidly become 
> irrelevant.

It's as if I talk about some funny networks on another planet?

I propose we discuss responsibly, Lorenzo.

Alex

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 21 Sep 2017 07:33:36 -0300

Yes, why not?

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Alexandre Petrescu <[email-masked]>
Responder a: <[email-masked]>
Fecha: jueves, 21 de septiembre de 2017, 5:35
Para: Mikael Abrahamsson <[email-masked]>
CC: "[email-masked] WG" <[email-masked]>
Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info

    
    
    Alex

---

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

> Yes, why not?

Because DHCPv6-PD does that.

Alex

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 21 Sep 2017 08:03:24 -0300

DHCPv6-PD is a good thing to have. I’ve confronted thoughts on DHCPv6 vs SLAAC … However, I understand it will be nice to have DHCPv6 implemented everywhere, as for example enterprise environments prefer a more controlled environment.

However, having DHCPv6 doesn’t exclude having 64share as well.

Otherwise, if we follow your suggestion, we should cleanup 60-70% of the protocols that we have, because they are redundant.

Regards,
Jordi

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

    
    
    Alex

---

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

Le 21/09/2017 à 13:03, JORDI PALET MARTINEZ a écrit :
> DHCPv6-PD is a good thing to have. I’ve confronted thoughts on DHCPv6
> vs SLAAC … However, I understand it will be nice to have DHCPv6
> implemented everywhere, as for example enterprise environments prefer
> a more controlled environment.
> 

It does: try to run both on a computer and you will see.

In practice: a particular operator had to make some choice some time. 
That choice led to either 64share on an APN, or DHCPv6-PD on another 
APN.  They had some reason to put each such thing on a distinct APN.

It's not simply a matter of having two distinct RFCs.  I can live with 
thousands of RFCs if you wish.  But I cant live with different APN each 
for an RFC.

I dont want a Connection Management software to switch between APNs like 
that.

I am not sure whether I explain this ok, but that's the way it is.

> Otherwise, if we follow your suggestion, we should cleanup 60-70% of
> the protocols that we have, because they are redundant.

In this discussion we talk 64share and DHCPv6-PD.  Pick one.

(for the other 60-70% protocols in MIB we can discuss separately if you 
wish).

Alex

> a: <[email-masked]> Fecha: jueves, 21 de septiembre de
> 2017, 7:57 Para: <[email-masked]> Asunto: Re: [v6ops] reclassify
>> Responder a: <[email-masked]> Fecha: jueves, 21 de
>> septiembre de 2017, 5:35 Para: Mikael Abrahamsson
>> <[email-masked]> CC: "[email-masked] WG" <[email-masked]> Asunto:
>> Re: [v6ops] reclassify 464XLAT as standard instead of info
>> 
>> 
>> 
>>>> I am not sure how the tethered clients will have end-to-end
>>>> IPv6 if they dont have a prefix dedicated to them.  Or maybe do
>>>> you propose that to be 64share?
>>> 
>>> That's what android already does, and have done for years.
>>> Probably Apple iOS devices as well. RFC7278.
>>

---

From: Ca By <[email-masked]>
Date: Thu, 21 Sep 2017 12:02:43 +0000

> station, SGW and PGW.  The linux part is not the modem.

Not correct. GTP only runs, in LTE, from the eNB to the SGW / PGW.  There
is not GTP on the UE or modem.

> So, you have 2 encapsulations, right?

Only GTP is encap. You can think of 464 translation scenario (ipv4
literals) as being encap in v6 to nat64 ... but i see it as translation not
encap

> client.

Say the same about Apple. Show me Apple running dhcpv6 on LTE interface.

> It's not that way.  It is that CLAT means no DHCP.

This seems to be your unique perspective

> When you make such statement - have you tried?

Not for me to try. I do not care about dhcpv6.

I am telling you what is in the rfc, this is the ietf. We do rfc. There is
a lot in the world outside of rfc, i agree. But that is for you to handle
in the world outside the ietf.

> Operators dont oppose DHCPv6-PD.  3GPP doesnt either.  Yet Android

Operating not opposing dhcp is not enough. This is the part you need to
work on outside the ietf.

---

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

Le 21/09/2017 à 14:02, Ca By a écrit :
[...]
> Not correct. GTP only runs, in LTE, from the eNB to the SGW / PGW.  
> There is not GTP on the UE or modem.

Ok, I can agree if you say so.  I can not capture packets on the UE to 
confirm or infirm; the "UE" is the "modem", that's how Balong calls it; 
there is no source code for that part.

It seems that you tried to capture on modem?  Or is it that somebody 
told this to you?  Or is it that it is in the 3GPP specs?

The doubt I have is the following: operator tells that the Terminal does 
some form of connection setup.  I dont see it.  Operator does not see it 
  either.  I speculate that that connection setup includes GTP.  It's a 
speculation.

I do see packets on PGW that show IPv6 encapsulated in GTP (an IPv4 
protocol).

My point is that even then, there _is_ encapsulation.

> literals) as being encap in v6 to nat64 ... but i see it as translation 
> not encap

So we dont end up with double encapsulation, but we end up with 
encapsulation _and_ translation.

Other less prestigious transition mechanisms use just one.  Why should 
we use two?

> Say the same about Apple. Show me Apple running dhcpv6 on LTE interface.

For that, I would need to acquire an Apple smartphone, and a development 
kit.  I dont know how how much things cost.  If I can get one for trial, 
I am highly interested.

I wonder whether one has to root-risk the iPhone before able to compile 
a poor man's DHCPv6-PD client on it?  This is a show-stopper, I wont risk.

What are the DHCPv6-PD clients available that compile on Apple iPhone? 
Maybe python library scapy is known to work there, or not.

I wonder what modem is inside an Apple iPhone (is it Qualcomm, which MDM 
version of the QDSP6 - is it MDM8xxx series - that is known to bloc). 
Or is it some other brand of modem.

With these at hand, I can try to work on something of Apple iPhone 
running DHCPv6-PD on its LTE interface.

[...]
> This seems to be your unique perspective

No, repeating what I said to others: some operator does 64share on an 
APN, and DHCPv6-PD on another APN.  This makes no sense and it's hard to 
live with.

The invoked reason is that "464XLAT DNS-some4-6 figure is the new 
standard" and especially it is supported by Android, which are very 
numerous.

[...]>      >     Moreover, design suggestions from CLAT assume that /64 is
> I am telling you what is in the rfc, this is the ietf. We do rfc. There 
> is a lot in the world outside of rfc, i agree. But that is for you to 
> handle in the world outside the ietf.

But now you want to make a new RFC status.  That should be done responsibly.

You should know the potential consequences.

One of the potential consequences is that we go with DHCPv6-PD on an APN 
and 64share on another APN.

Alex

[snip]

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 21 Sep 2017 10:40:17 -0300

My guess, didn't tired that, is that if and implementation is using both DHCPv6-PD and 64share, it should be possible to have a single APN. You just need to not “force” the use of the PD if is not being requested by the UE. Is a quick though, but don't see a problem on that.

By the way, if the operator was having problems with DHCPv6-PD, it means that the chipset was not filtering that as you indicated before, so blame some chipset vendors, not the IETF.

I also see a valid case for having 2 APNs. 1) for LTE broadband routers that require more than a /64 (and thus DHCPv6-PD), and 2) for the rest that are regular UEs and only require a /64 (64share for the tethering)

Regards,
Jordi

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

    

    

    

    Alex

---

From: Gert Doering <[email-masked]>
Date: Thu, 21 Sep 2017 15:52:35 +0200

Hi,

> I also see a valid case for having 2 APNs. 1) for LTE broadband routers that require more than a /64 (and thus DHCPv6-PD), and 2) for the rest that are regular UEs and only require a /64 (64share f…

The claim that you need multiple APNs for that is not logical.

The basic function "assign a /64 for each PDP" is 3GPP standard, any APN
needs to do that (and that's the /64 you use for 64share).

The extra function "DHCPv6-PD" is conceptually totally independent - you
need an IPv6 capable link, nothing else, and whether or not a /64 has been
assigned is not relevant for PD.  

Now, if a given *vendor* can only turn on one or the other on their gear 
is an implementation choice, and that REALLY doesn't belong here - if at
all, it's a 3GPP standardization topic ("if you add DHCPv6PD, you MUST
continue to provide a /64 for each subscriber").

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: Alexandre Petrescu <[email-masked]>
Date: Thu, 21 Sep 2017 15:56:10 +0200

Le 21/09/2017 à 15:40, JORDI PALET MARTINEZ a écrit :
> My guess, didn't tired that, is that if and implementation is using 
> both DHCPv6-PD and 64share, it should be possible to have a single 
> APN. You just need to not “force” the use of the PD if is not being 
> requested by the UE. Is a quick though, but don't see a problem on 
> that.

Dont standardize on something that you think it may work.  We should be
sure it works.

> By the way, if the operator was having problems with DHCPv6-PD,

No, the operator had no problems with DHCPv6-PD.  They had problems with
DHCPv6 - they found it superfluous.  Android did 464xlat, 64share and
NAT-figurex-figurey, so everything was fine.

> it means that the chipset was not filtering that as you indicated 
> before, so blame some chipset vendors, not the IETF.

At some point in time, some modems (e.g. a modem in Huawei E392 USB
dongle) acted as a sort of DHCPv6 Server.  My linux issued DHCPv6
requests, someone answered, and the  operator said it isnt them.  So it
was the modem.

Newer modems like MDM8xxx dont even bother to answer - they simply
block.  Moreover, the designers ack they are blocking it, 'because noone
needs it'.

> I also see a valid case for having 2 APNs. 1) for LTE broadband 
> routers that require more than a /64 (and thus DHCPv6-PD), and 2) for
> the rest that are regular UEs and only require a /64 (64share for the
> tethering)

I can agree to that use case of LTE broadband router vs smartphone, or
one for M2M "Business" devices and one for smartphones.

But two APNs, both for smartphones to connect, is not viable.

You want one APN and many kinds of smartphones and cars to connect to
that single APN.

(there are long discussions about this, and in the past one has seen
movements in that direction)

Alex

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 21 Sep 2017 15:56:59 +0200 (CEST)

> told this to you?  Or is it that it is in the 3GPP specs?

It's in the 3GPP spec. In 3G it's GTP GGSN-RNC, and then it's handled by 
the RLC layer between RNC and UE. I'd imagine it's something similar in 
LTE but then instead between UE and eNodB (since there is no RNC).

> I do see packets on PGW that show IPv6 encapsulated in GTP (an IPv4 

GTP can be either IPv4 or IPv6, and the encapsulated packets can be either 
IPv4 or IPv6 (and probably other protocols as well, I haven't used it for 
anything else).

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 21 Sep 2017 11:04:10 -0300

You’re right, that’s why I said quick thought because I’ve seen operators doing that actually (two APNs one for broadband LTE, one for smartphones) ;-)

So, a single APN, provides by default a /64. Then if it is a broadband router starts DHCPv6-PD (not sure then if NO need to use RFC6603 for excluding the WAN link if the initial “default” /64 was already used as well for the WAN link).

Regards,
Jordi

-----Mensaje original-----
De: Gert Doering <[email-masked]>
Responder a: <[email-masked]>
Fecha: jueves, 21 de septiembre de 2017, 10:52
Para: JORDI PALET MARTINEZ <[email-masked]>
CC: <[email-masked]>
Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info

    Hi,

    

    
    Gert Doering
            -- NetMaster

---

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

Le 21/09/2017 à 15:56, Mikael Abrahamsson a écrit :
>> confirm or infirm; the "UE" is the "modem", that's how Balong calls 
>> it; there is no source code for that part.
>>

So you mean the UE does GTP?

(Mr. Byrne and another person said that GTP is not run in the UE.)

But has one tried it?

I am asking you because of this: the 3GPP and IETF specs say that DHCPv6 
should run on the Client and on the Server.  There is no notion of 
"proxy DHCP".  Yet modems do just that: some run DHCPv6, some block 
DHCPv6 - all non-standard ways of DHCP.  They are like middle-boxes, 
trying to be transparent.

By this logic, could it be that some modem implements also GTP?

>> The doubt I have is the following: operator tells that the Terminal 
>> does some form of connection setup.  I dont see it.  Operator does not 
>> see it
> GTP can be either IPv4 or IPv6, and the encapsulated packets can be 
> either IPv4 or IPv6 (and probably other protocols as well, I haven't 
> used it for anything else).

When I read that, I wonder whether it is better to encapsulate IPv6 in 
GTP-that-uses-IPv6addresses-as-src-and-dst?

Alex

Subject: RE: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis-09.txt - questions about Solicit Prefix Delegation
From: Vízdal Aleš <[email-masked]>
To: Alexandre Petrescu <[email-masked]>
Cc: Ted Lemon <[email-masked]>, dhcwg <[email-masked]>, "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 17 Jul 2017 21:42:56 +0000

response inline

Ales

> -----Original Message-----
> From: Alexandre Petrescu [mailto:[email-masked]]
> Sent: Friday, July 14, 2017 9:50 PM
> To: Vízdal Aleš <[email-masked]>
> Cc: Ted Lemon <[email-masked]>; dhcwg <[email-masked]>; Bernie Volz
> (volz) <[email-masked]>
> Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis-09.txt - questions
> about Solicit Prefix Delegation
>
>
>
> Le 14/07/2017 à 21:26, Vízdal Aleš a écrit :
> >
> >
> >> On 14 Jul 2017, at 21:15, Alexandre Petrescu
> >>> Le 14/07/2017 à 20:35, Ted Lemon a écrit : So are the DHCP clients
> >>> you are talking about setting the IP header hop count to
> >>>  0/1, or the DHCP header hop-count field to 0/1?   That is, what
> >>>  is the behavior you are concerned about, and why do you think it
> >>> might cause a problem in this case?
> >>
> >> Some clients I am talking about issue DHCP Solicit with Hop Limit
> >> field in the IPv6 base header (not DHCP UDP header) with value 1.
> >>
> >> This Solicit is sent on a cellular network.  The cellular network
> >> encapsulates at some point in IPv4, and further decapsulates.  The
> >> encapsulation protocol is called "GTPU" by some non-wireshark packet
> >> dump format, with fields like "TEID", "GTP_TPDU_MSG".  This  cellular
> >> network does not offer IPv4 access to end user, it only offers IPv6.
> >>
> >> There is no GTP RFC.
> >
> > GTP aka GPRS Tunnelling Protocol has been specified by 3GPP.
> >
> > It starts at the eNodeB and terminates at the PGW where the DHCP
> > server/relay would sit.
>
> You see, I am also told that my "MT" ("Mobile Terminal"?) terminates GTP.  I
> guess both are possible (terminate some times at eNodeB and other times at
> MT).

I can only recommend checking the 3GPP technical specification dealing with the architecture and protocol details.
Google will help.

> Or otherwise the expression "terminate at" may have different meanings to
> different people.
>
> >> There is an RFC for "Generic Packet Tunnelling in IPv6".  This RFC
> >> says that encap/decap decrements the Hop Limit.
> >>
> >> This raises a potential speculation that the network drops an
> >> incoming packet that has Hop Limit 1.
> >>
> >> It may be that the GTP encapsulation (no RFC) does not decrement the
> >> Hop Limit of a packet-to-be-encapsulated.  In this case there is no
> >> problem with DHCP Solicit having Hop Limit 1.
> >
> > It shall keep the packet as-is, since it is not visible from
> > user/data-plane point of view.
>
> I dont understand that.  Not sure what you mean by user-data planes.

You can imagine that your IP traffic (originated by the UE or devices behind the UE) is a payload to the Mobile Network.
It is received on the radio interface of the eNodeB that puts the packet into the GTP, there is no routing involved.
In other words, your UE is assigned an IP address / IPv6 prefix, the L3 next hop is the GGSN/PGW, so any other node between
your UE and the GGSN/PGW does not change the packet as it forwards based on the GTP header.

> The IP Hop Limit is in the IP header.  Some IP tunnelling mechanisms do touch
> the Hop Limit of the encapsulated packet.  Why would GTP be different than
> the other IP tunnelling mechanisms?

As stated above, there is no routing involved. What is received on the radio interface is encapsulated into GTP and forwarded towards the GGSN/PGW.

> > I suggest a deep dive into 3GPP specs ...
>
> It is certainly advantageous to understand the 3GPP specs.

It is key to understand the architecture ...

> But I'd rather consider putting that into an Internet Draft.

Not sure if recasting 3GPP, ETSI, BBF and other specs as ID's would help.

> Alex
>
> >
> >> Alex
> >>
> >>
> >>
> >>> On Fri, Jul 14, 2017 at 8:32 PM, Alexandre Petrescu
> >>> wrote: Le 13/07/2017 à 23:14, Ted Lemon a écrit : On Jul 13, 2017
> >>> 16:01, "Alexandre Petrescu" <[email-masked]
> >>> <mailto:[email-masked]>
> >>> <mailto:[email-masked]
> >>> <mailto:[email-masked]>>> wrote: My oppinion is to
> >>> make DHCP spec Hop Limit > 1.  In order to make sure that the
> >>> encap/decap of DHCP Solicit in IPv4 GTP happening on a cellular link
> >>> does not drop it to 0 upon decap. If a link local sourced multicast
> >>> with a hop limit of one is dropped between sender and receiver, ip
> >>> is broken on that link, ne c'est pas? If that link is a real link
> >>> then yes - ip is broken on that link. But if the link is a virtual
> >>> link - like when on a tunnel - then it may be that tunnel works or
> >>> no. Alex
> >>
> >> _______________________________________________ dhcwg mailing list
> >> [email-masked] https://www.ietf.org/mailman/listinfo/dhcwg
> >
> > Zásady komunikace, které společnost T-Mobile Czech Republic a.s.
> > užívá při sjednávání smluv, jsou uvedeny
> > zde<http://www.t-
> mobile.cz/dcpublic/Zasady_komunikace_pri_sjednavani_smluv_cz.pdf>.
> >
> >
> >
> Není-li v zásadách uvedeno jinak, nepředstavuje tato zpráva konečný
> > návrh na uzavření či změnu smlouvy ani přijetí takového návrhu. The
> > communication principles which T-Mobile Czech Republic a.s. applies
> > when negotiating contracts are defined
> > here<http://www.t-
> mobile.cz/dcpublic/Zasady_komunikace_pri_sjednavani_smluv_en.pdf>.
> >
> >
> >
> Unless otherwise stated in the principles, this message does not
> > constitute the final offer to contract or an amendment of a contract
> > or acceptance of such offer.
> >

Zásady komunikace, které společnost T-Mobile Czech Republic a.s. užívá při sjednávání smluv, jsou uvedeny zde<http://www.t-mobile.cz/dcpublic/Zasady_komunikace_pri_sjednavani_smluv_cz.pdf>. Není-li v zásadách uvedeno jinak, nepředstavuje tato zpráva konečný návrh na uzavření či změnu smlouvy ani přijetí takového návrhu. The communication principles which T-Mobile Czech Republic a.s. applies when negotiating contracts are defined here<http://www.t-mobile.cz/dcpublic/Zasady_komunikace_pri_sjednavani_smluv_en.pdf>. Unless otherwise stated in the principles, this message does not constitute the final offer to contract or an amendment of a contract or acceptance of such offer.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 21 Sep 2017 16:47:22 +0200 (CEST)

On Thu, 21 Sep 2017, Alexandre Petrescu wrote:

>>> It seems that you tried to capture on modem?  Or is it that somebody told 
>>> this to you?  Or is it that it is in the 3GPP specs?
>> 
>> the RLC layer between RNC and UE. I'd imagine it's something similar in LTE 
>> but then instead between UE and eNodB (since there is no RNC).
>

No.

---

From: Owen DeLong <[email-masked]>
Date: Thu, 21 Sep 2017 11:49:39 -0300

> Here, in this operations group, there is need that Android accepts these

I’m not sure that we want to take on the role of RFC Enforcement Police in this group.

> INFORMATIONAL to something else.

First, I don’t accept your idea that CLAT is “Android-only”. While Android may be the most prolific example of CLAT implementation, it is certainly not the only implementation, nor is there anything preventing CLAT from being deployed in other devices beyond those where it is currently implemented.

It seems clear at this point that your intent is to try and hijack this thread to apply pressure to Android developers to implement DHCPv6 on Android. Regardless of the worthiness (or not) of that goal, the simple reality is that it is a completely orthogonal issue unrelated to 464XLAT or CLAT in any meaningful way and there’s simply no validity to your argument.

Jordi, Ole, Cameron, and myself, have all made it clear to you that the claims you have made in an attempt to tie the issues together are not supported by the facts. CLAT and DHCP can co-exist on the same network. CLAT and IPv6-in-GTP can co-exist as well.

DHCP is an address and/or prefix assignment mechanism.
IPv6-in-GTP is a tunneling mechanism for moving IPv6 packets through an IPv4 mobile network.
CLAT and/or 464XLAT are an IPv6 transition mechanism allowing an IPv6-only client to connect to IPv4 servers via an IPv6-only network with appropriate PLAT support.

They are three completely separate solution spaces and all three can co-exist.

> instead of Android, and more.

We get it… Android doesn’t support DHCPv6 and you don’t like that.

However, this isn’t about Android, it’s about 464XLAT and CLAT. These are protocols, not vendors.

Take your Android issues up with the Android developers. They are unrelated to this thread.

Owen

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 21 Sep 2017 16:54:41 +0200 (CEST)

> So you mean the UE does GTP?

Since at least one more person has asked about this.

GTP: GGSN-RNC
RLC: RNC-UC

GTP tunnel is terminated in RNC and packet is decapsulated before reaching 
the RLC layer (in the GGSN->UE direction).

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 21 Sep 2017 16:59:34 +0200

Le 21/09/2017 à 16:47, Mikael Abrahamsson a écrit :
>>>> Ok, I can agree if you say so.  I can not capture packets on the UE 
>>>> to confirm or infirm; the "UE" is the "modem", that's how Balong 
>>>> calls it; there is no source code for that part.
>>>>
>>> It's in the 3GPP spec. In 3G it's GTP GGSN-RNC, and then it's handled 
>>> by the RLC layer between RNC and UE. I'd imagine it's something 
>>> similar in LTE but then instead between UE and eNodB (since there is 
>>> no RNC).
>>

So I understand from three different persons that UE does not use GTP.

If nobody else tries, I will have to ask the modem manufacturer.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 21 Sep 2017 17:04:07 +0200

Le 21/09/2017 à 16:49, Owen DeLong a écrit :
[...]
> CLAT and DHCP can co-exist on the same network.

This is not shown anywhere.

I tell you they dont, and they will not.

Alex

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 21 Sep 2017 17:07:34 +0200 (CEST)

> If nobody else tries, I will have to ask the modem manufacturer.

Correct. The RLC layer is what's run over the "radio". The GTP tunnel 
header is taken out before it enters this, because it's kind of its own 
"tunnel".

It's the same misconception that there is PPP in 3GPP networks. There 
isn't, it's just an abstraction between the UE baseband and the operating 
system.

3G:
GTP between GGSN-SGSN-RNC.
RLC between RNC-enodb-UE baseband.

4G:
GTP between SPGW-enodb
RLC between enodb-UE baseband.

Then the baseband can have all kinds of interfaces to handoff packets to 
the kernel. It can pretend to be an ethernet bridge, it can pretend to be 
PPP tunnel, I'm sure it can pretend to be other things.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 21 Sep 2017 17:17:28 +0200

Le 21/09/2017 à 17:07, Mikael Abrahamsson a écrit :
> isn't, it's just an abstraction between the UE baseband and the 
> operating system.

Yet, Mikael, there is ppp on ARM and there is meaningful dialogue 
between ARM and something.  The operator says they dont do any ppp.

So, the modem does a sort of 'ppp proxy' that is not documented anywhere.

That's what you call 'misconception' - it's the modem that does things 
that nobody knows what.

> the kernel. It can pretend to be an ethernet bridge, it can pretend to 
> be PPP tunnel, I'm sure it can pretend to be other things.

YEs.  We dont know any of these.

It's hard to make any stnadards decision if we dont know this modem 
behaviour.

Imagine it does a sort of 64share itself, and the ARM also does 64share 
- there are two levels of  this 'sharing'.  It's not good.

Alex

---

From: Ca By <[email-masked]>
Date: Thu, 21 Sep 2017 15:20:27 +0000

> I tell you they dont, and they will not.

OpenWrt / LEDE supports both CLAT and dhcpv6-pd

https://forum.openwrt.org/viewtopic.php?id=59528

---

From: Ca By <[email-masked]>
Date: Thu, 21 Sep 2017 15:24:00 +0000

> https://forum.openwrt.org/viewtopic.php?id=59528
Better links for one page view of support of CLAT and dhcp
https://wiki.openwrt.org/doc/uci/network6

But i agree with Owen, this point and conversation is not useful / helpful.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 21 Sep 2017 17:25:27 +0200

Le 21/09/2017 à 17:20, Ca By a écrit :
> 
> On Thu, Sep 21, 2017 at 8:04 AM Alexandre Petrescu 

Good, but have you tried OpenWRT CLAT and dhcpv6-pd on cellular at the 
same time?  I tell you they dont run together neither on OpenWRT nor 
anywhere else.

If you claim otherwise: please tell me the modem name, manufacturer.

Alex

---

From: Erik Kline <[email-masked]>
Date: Fri, 22 Sep 2017 00:35:37 +0900

+1

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 21 Sep 2017 18:04:23 +0200 (CEST)

> If you claim otherwise: please tell me the modem name, manufacturer.

There is nothing in the standards that tell us these can't be used 
together. What you're talking about is an implementation problem, not a 
standardisation problem.

Just because current modem implementations do the wrong thing doesn't mean 
this can't work.

---

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

> Say the same about Apple. Show me Apple running dhcpv6 on LTE interface.

Nothing would, but I would like to look closer at this for a while.

Do you think one needs to root-risk an iPhone before one could add an IP 
address to its interface?

(root-risking is a special operation during boot time whereby one needs 
a special code from hardware manufacturer, one is asked to agree to the 
risk of 'rooting' the device, responsibility; this is a make-or-break 
operation; the device is expensive, so money is at risk - if the 
operation does not succeed, then the iPhone may die entirely, no way to 
recover.)

Alex

---

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

> GTP can be either IPv4 or IPv6, 

Spec please?

Alex

> and the encapsulated packets can be