Subject: Re: [v6ops] How my Android phone got assigned with IPv6 address via 4G LTE?

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Wed, 5 Sep 2018 19:53:01 +0000

BTW, section 2.3.2 https://tools.ietf.org/html/draft-ietf-dnsop-isp-ip6rdns-05#section-2.3.2 reminded me of the solution described here for tracking MAC-IP address coupling in environments such as those of enterprises etc.

https://tools.ietf.org/html/draft-asati-dhc-ipv6-autoconfig-address-tracking

--
Cheers,
Rajiv

From: v6ops <[email-masked]> on behalf of Lee Howard <[email-masked]>
Date: Tuesday, August 28, 2018 at 10:35 AM
To: "[email-masked]" <[email-masked]>
Subject: Re: [v6ops] How my Android phone got assigned with IPv6 address via 4G LTE?

On 08/28/2018 08:15 AM, Rajiv Asati (rajiva) wrote:
With IPv6, usage of DDNS should be recommended as a good practice to get hostname - IP mapping. Also important is to formulate the host names that comply with sanity.

Only if you care about hostname - IP mapping. It matters for some kinds
of servers, and is handy for traceroutes. Hosts that are clients don't
generally get looked up by name.

Of course, the typical v4 practice of formulating hostnames by encoding the entire v4 address in the host name must not be followed.

It could be. "Sanity" (as you said above) is hard to define, especially
when you don't want to give away private user information.

Perhaps, a topic for a different thread.

This draft is very close to publication:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-isp-ip6rdns/
The AD has for a very few minor changes, which I hope to make in the
next 48 hours. It still needs IETF Last Call.

Lee

Cheers,
Rajiv

On Aug 28, 2018, at 12:38 AM, Mark Andrews <[email-masked]<mailto:[email-masked]>> wrote:

On 28 Aug 2018, at 2:07 pm, Erik Kline <[email-masked]<mailto:[email-masked]>> wrote:

Yup, agreed.  I wasn't implying a protocol didn't exist, only that it
wasn't being used.

To be honest, I've never try to use DNS UPDATE as a client/in an
application, so I don't know if there are any unaddressed aspects to
its use *other* than simply trying in the first place.
* DNS UPDATE is used by Active Directory (using GSS-TSIG to authenticate).
* DNS UPDATE is used by DHCP servers with TSIG in enterprises to update
   forward and reverse zones.
* DNS UPDATE is/was used by DynDNS with TSIG and SRV to update forward zones
   from CPE routers usually.
* MacOS uses DNS UPDATE with TSIG and SRV to update forward zones.
   (System Preferences -> Sharing -> Edit -> Use Dynamic Global Hostname)

There is actually a good chance that it was used behind the scenes with
equipment that you have used. It’s just not used ubiquitously and it should
be.

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

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

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

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 6 Sep 2018 19:27:11 +0900

On Thu, Sep 6, 2018 at 4:53 AM Rajiv Asati (rajiva) <rajiva=
[email-masked]> wrote:

> BTW, section 2.3.2
> https://tools.ietf.org/html/draft-ietf-dnsop-isp-ip6rdns-05#section-2.3.2
> reminded me of the solution described here for tracking MAC-IP address
> coupling in environments such as those of enterprises etc.
>
>
>
>

I wonder if it's time to revive that draft? It would seem to be the easiest
solution to support address tracking in existing architectures built around
DHCP, and could facilitate enterprise networks transitioning from IPv4 to
IPv6.

---

From: David Farmer <[email-masked]>
Date: Thu, 6 Sep 2018 18:09:37 -0500

On Thu, Sep 6, 2018 at 5:27 AM, Lorenzo Colitti <
lorenzo=[email-masked]> wrote:

>> BTW, section 2.3.2 https://tools.ietf.org/html/
>> draft-ietf-dnsop-isp-ip6rdns-05#section-2.3.2 reminded me of the
>> solution described here for tracking MAC-IP address coupling in
>> environments such as those of enterprises etc.
>>
>>
>>
> I wonder if it's time to revive that draft? It would seem to be the
> easiest solution to support address tracking in existing architectures
> built around DHCP, and could facilitate enterprise networks transitioning
> from IPv4 to IPv6.
>

I've always thought this is an interesting idea, however, I think it needs
to be done for both IPv6 and IPv4.  IPv4 can have statically configured
hosts as well.

Also, I'm not sure it should be part of DHCPv6 or DHCPv4 protocols though,
maybe it should be its own protocol. The trust model between the routers
and a server for this function is quite different than the trust model for
host learning their configuration. It probably makes sense to have a common
database with DHCP, especially DHCPv4 since this is the only practical way
to automatically configure IPv4 hosts. If you have a common database with
DHCPv4, then the same thing with DHCPv6 makes some sense too. So I can see
implementing this protocol in DHCP servers, but maybe it shouldn't be part
of the DHCP protocol v4 or v6.

I understand why DHCPv4 and DHCPv6 are different and I mostly agree with
the reasons. Nevertheless, when a naive network admin looks to implement
IPv6 they think, oh, I can use DHCPv6 and it will work the same as DHCPv4,
and it is a bit of a bait-and-switch when they learn it doesn't work that
way. This DHCPv6 bait-and-switch is a big hindrance to IPv6 adoption
especially for enterprises with operational workflows built around the way
DHCPv4 works.

So, if we add a capability like this it needs to be operationally similar
for both IPv6 and IPv4.

Thanks.

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 7 Sep 2018 15:19:32 +0200

Le 27/08/2018 à 02:50, Davey Song a écrit :
> Hi folks,
> 
> Recently the IPv6 4G LTE of China moible and China Telecom is working. 
> And I got the address information on my android phone, like :
> 
> China Mobile : 2409:8900:8a10:6dof:4177:9599:de56:7092
> China Telecom: 240e:ff:b10a:54a9:b5f7:5e4c:2f2d:9847

Excellent.  My question is whether when this address is assigned on 
android you can ping6 some IPv6 site (maybe ping6 ipv6.google.com)?

Because there are some cellular operators that do assign IPv6 addresses 
to android and other phones but dont provide IPv6 connectivity to the 
Internet (can not ping6).

> My question is : How these IPv6 addresses are assigned to my pohone and 
> what type of address they are?

That can be answered definitely only by trying.  It's good to know the 
specs too, but better try it to know for sure.

There are three main 'native' ways into which that address could have 
been allocated to your android:
- maybe the android did a DHCPv6 request and the operator responded with
   a DHCPv6 acknowledgment containing the address.
- maybe the layer 2 protocol (IPv6CP - stands for Control Protocol, or
   ppp) negotiated an Interface ID of 64bit length, and then the router
   in the network sent a Router Advertisement, and then the android
   formed an address with the prefix in the RA and the IID negotiated
   earlier.
- maybe the layer 2 protocol negotiated the full IPv6 address rather
   than just the Interface ID (and there was no RA from a
   Router prior to forming an IPv6 address).

Then there are more non-native ways, like 'hacks' that are implemented 
by an application that is specific: it can form an IPv6 address by 
requesting it first with an IPv4 proprietary protocol.

All these I have seen in deployed cellular networks.

You can try it yourself by doing the following:
- contact the phone manufacturer to obtain key to be able to log in root
   in the smartphone.  They are legally obliged to allow you to.  Many
   already do (I know Huawei, SOny and and few others).
- log in the android and learn how to ls, and certainly not rm -rf /.
- then cross-compile a tshark or a tcpdump (it is a packet capture
   tool).
- run the packet dump tool to record which packets circulate (RA, DHCP,
   etc.)
- download the packet dumps to your laptop to see it on nice GUI with
   wireshark.
- identify whether android used pppd, or qmicli or mmicli in order to 
make the connection.  pppd is available for many  modems, qmicli is 
specific to Qualcomm, and mmicli to others.  Other modem manufacturers 
may have other tools.
- use '-v' options to these tools.
- look at the /var/log/messages
- kill all ConnectionManager or NetworkManager.
- there is a certain ability needed to be able to capture before an 
interface is put up, because normally capturing happens while the 
interface is already up.  But when it is already up you already obtained 
the address.
- there is a need to capture more than just IP datagrams, but link-layer 
datagrams.

> They looks no EUI-64 address, without 
> FFFE in the middle of low 64 bits.

Yes, looks so.

Forming 64bit Interface IDs that dont have FF:FE in the middle can 
happens modernly by recent androids (recent linuces, in fact).  Either 
the linux formed such a non-FFFE IID, or that IID was formed by a server 
and delivered to android by the layer2 protocol

> And it can not be done by DHCPv6 
> because I heard Android does not support DHCPv6, right?

Android is an Operating System.  It uses a modified linux kernel.  When 
people say android does not implement DHCPv6 it is because the 
manufacturer of that phone chose to put an Android that has no DHCPv6 
client.  It is however straightforward to put yourself (or your 
operator) a DHCPv6 client on an Android.  We did it numerous times with 
many (5?) DHCPv6 clients.  Android supports them all ok.

Also, this is based on the remark that the manufacturer of that phone 
puts the android and that manufacturer has a hard time to remove the 
SLAAC (a competitor to DHCPv6) from Android: SLAAC is built into the 
linux part of Android.  And Google _and_ Android _and_ phone 
manufacturer dont have enough capacity or will to _remove_ SLAAC from 
linux kernel, because it is not their design.

In that sense: yes, DHCPv6 is _not_ in Android (could easily be added), 
and SLAAC _is_ in Android (could hardly be removed).

> I'm not sure 
> how my LTE provider provisioning IPv6 address.

In the LTE provider's network there is much more private and proprietary 
mechanisms to provision the IPv6 addresses.  What the end user sees is 
only the tip of the iceberg: the RA.

Some of the mechanisms are described in some RFCs that relate to Proxy 
Mobile IP.  I am not saying that's what's used at your operator, but 
these texts approach the most to what's used.

> So The only possbile way 
> is SLAAC+private address？

What you shown above is not a private address.  They both start with 
24-something.  The 'private' addresses in IPv6 are called 'ULA's (for 
Unique Local Addresses) and they start with fd-something or fc-something.

And no, it is not the only possible way to be SLAAC.  I would even say 
that, judged by the excitement, this might be the first time these 
operators give IPv6 to end-users, and I would say it is rather a 
proprietary form of IPv6CP.  But I may be wrong in case these operators 
acquired very recent state-of-the-art hardware and learned from recent 
experience of operators who went with SLAAC.

Alex

> 
> Anyone who can help me out on this question? Or share your experience on 
> how the mobile ISP commonly provison their users. Thanks.

> Best regards,
> Davey
> [email-masked]

---

From: Davey Song <[email-masked]>
Date: Mon, 10 Sep 2018 09:58:59 +0800

Hi Alex, from this thread I filled the gap of IPv6 LTE provisioning in my
mind. Thank you all.

Davey