Re: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: [*SPAM* Score/Req: 3.9/3.3] Re: reclassify 464XLAT as standard instead of info

[Alexandre Petrescu <[e-mail]>]

Le 21/09/2017 à 14:02, Ca By a écrit :
[...]
>      > IPv6-in-GTP is a transport mechanism with mobility. It does not
>     help an
>      > 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.
> 
> 
> 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.

>      > That said, my deployment includes both IPv6-in-GTP and 464xlat
>      > simulatenously
> 
>     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

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?

>     [...]
>      >     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
> 
>     RFC is one thing, but many implementations block some RFCs.
> 
>     What structurally prevents this is that there are very numerous Android
>     devices.
> 
> 
> 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.

[...]
>     It's not that way.  It is that CLAT means no DHCP.
> 
> 
> 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
>     sufficient.
>      >     That is wrong - /64 is not sufficient.
>      >
>      >
>      > It is sufficient for CLAT function of execuating rfc6145. CLAT just
>      > rfc6145.
> 
>     No.
> 
>     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.

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]