Subject: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 10 Jul 2017 12:11:37 +0200

Hi,

The INFORMATIONAL RFC6459 "IPv6 in 3GPP" contains this paragraph:
> The 3GPP network allocates each default bearer a unique /64 prefix, 
> and uses layer-2 signaling to suggest to the UE an Interface 
> Identifier that is guaranteed not to conflict with the gateway's 
> Interface Identifier.  The UE must configure its link-local address 
> using this Interface Identifier.

I disagree that the UE must configure its LL using this IID.  Where is
this requirement from?

The UE should be allowed to form an IID at its will, if so it wishes.

This has consequences on privacy, and may impact interoperability when
DHCPv6-PD is used later in the process.

Also, this being an INFORMATIONAL document, in no case a party
implementing it could impose it on some other party.

Alex

---

From: Erik Kline <[email-masked]>
Date: Mon, 10 Jul 2017 19:48:47 +0900

It can form other IIDs, but (a) it uses this for link-local and (b)
it's the default used for its GUA.  But sending traffic from other
IIDs is perfectly fine (464xlat on Android does this in fact).

I'm not yet convinced there's much to worry about here.

On 10 July 2017 at 19:11, Alexandre Petrescu
<[email-masked]> wrote:
>> The 3GPP network allocates each default bearer a unique /64 prefix, and
>> uses layer-2 signaling to suggest to the UE an Interface Identifier that is
>> guaranteed not to conflict with the gateway's Interface Identifier.  The UE
>> must configure its link-local address using this Interface Identifier.
>
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 10 Jul 2017 13:14:36 +0200

Le 10/07/2017 à 12:48, Erik Kline a écrit :
> It can form other IIDs,

The RFC does not say it can.

> but (a) it uses this for link-local

It is an alternative, not a mandate.

RFC5072 "IPv6 over PPP" makes it clear that the IID matter is a peer to 
peer negotiation, and that the UE proposes it first.

> and (b) it's the default used for its GUA.

Should not be the default.  Should be an alternative.

Defaulting the operator-provided IID in a GUA may contradict
Recent Stds Track RFCs like RFC8064 "Recomm'n on stable IIDs".

> But sending traffic from other IIDs is perfectly fine

I agree.

> (464xlat on Android does this in fact).

It's good to know.

Also, other applications on HTTP with IIDs generated by the UE are also 
accepted by the operator.

> I'm not yet convinced there's much to worry about here.

There could be.

There is an operator that may condition acceptance of DHCP Solicit, and 
NA, only if issued from what that operator generated as IID.

My oppinion is that it should accept the DHCP Solicit and NA coming from 
an address formed from an IID generated by the UE as well.

Otherwise there could be some privacy concerns.

Alex

>>> The 3GPP network allocates each default bearer a unique /64 
>>> prefix, and uses layer-2 signaling to suggest to the UE an 
>>> Interface Identifier that is guaranteed not to conflict with the 
>>> gateway's Interface Identifier.  The UE must configure its 
>>> link-local address using this Interface Identifier.
>> 
>> 
>> I disagree that the UE must configure its LL using this IID. Where 
>> is this requirement from?
>> 
>> This has consequences on privacy, and may impact interoperability 
>> when DHCPv6-PD is used later in the process.
>> 
>> _______________________________________________ v6ops mailing list
>>  [email-masked] https://www.ietf.org/mailman/listinfo/v6ops

---

From: Mark Smith <[email-masked]>
Date: Mon, 10 Jul 2017 22:05:27 +1000

> implementing it could impose it on some other party.

I think the reason why it is INFORMATIONAL is that this is not an IETF
document on how to do IPv6, rather, it is the 3GPPs specification on
how to do IPv6 on their devices.

I think the IETF and the 3GPP's device models are different.

The IETF considers hosts and links to be separate things, so
supporting a new link type means no more than an IPv6-over-link RFC
that provides the required functionality to run IPv6 using generic
next layer up mechanisms. In the IETF model, there would be an
IPv6-over-3G RFC that resembled the IPv6 over PPP, IPv6 over Ethernet
etc. RFCs. After that, standard IPv6 mechanisms would be used to
bootstrap over the 3G link e.g., RAs, DHCPv6-PD etc.

3GPP seem to conflate hosts and links, and seem to be whole of device
generation or release oriented, rather than being piecemeal and
evolving feature and negotiated capability oriented that the IETF are.
As you've found they're much more prescriptive about device
capabilities and behaviours that occur higher in the stack than just
what is necessary to get IPv6 over the 3G link running.

The 3GPP model creates constraints that then have to be worked around
e.g., RFC7278, "Extending an IPv6 /64 Prefix from a Third Generation
Partnership Project (3GPP) Mobile Interface to a LAN Link".

Regards,
Mark.

---

From: <[email-masked]>
Date: Mon, 10 Jul 2017 12:49:39 +0000

Hi Alex, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : v6ops [mailto:[email-masked]] De la part de Alexandre
> Petrescu
> Envoyé : lundi 10 juillet 2017 12:12
> À : [email-masked]
> Objet : [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address
> 
> Hi,
> 

[Med] This is part of 3GPP spec. The GGSN/PGW selects an IID to be used when forming the link-local address. The goal is called in 3GPP specs :

"in order to avoid any conflict between the link-local address of the MS and that of the GGSN, the Interface-Identifier used by the MS to build its link-local address shall be assigned by the GGSN. The GGSN ensures the uniqueness of this interface-identifier. The MT shall then enforce the use of this Interface-Identifier by the TE."

BTW, this was inspired by https://tools.ietf.org/html/rfc5072#section-5: 

   As long as the interface identifier is negotiated in the IPV6CP phase
   of the PPP connection setup, it is redundant to perform duplicate
   address detection (DAD) as a part of the IPv6 Stateless Address
   Autoconfiguration protocol [3] on the IPv6 link-local address
   generated by the PPP peer.

> The UE should be allowed to form an IID at its will, if so it wishes.

[Med] It is allowed to do so...for non link-local addresses. 

> DHCPv6-PD is used later in the process.

[Med] I don't follow you here. There is no privacy concern out there. The IID used when forming a global IPv6 address will be selected by the terminal; no assumption is made about those bits.

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 10 Jul 2017 15:50:54 +0200

Med,

I think this is an issue _if_ the operator filters all incoming messages 
generated by the UE whose LL includes an IID different than what the 
network may have suggested to it.

If there is no such filter, then no need to debate specs.

Le 10/07/2017 à 14:49, [email-masked] a écrit :
> Hi Alex,
> 
> Please see inline.
> 
> Cheers, Med
> 
>> -----Message d'origine----- De : v6ops 
>> [mailto:[email-masked]] De la part de Alexandre Petrescu 
>> Envoyé : lundi 10 juillet 2017 12:12 À : [email-masked] Objet : 
>> [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address
>> 
>> Hi,
>> 
> [Med] This is part of 3GPP spec. The GGSN/PGW selects an IID to be 
> used when forming the link-local address. The goal is called in 3GPP 
> specs :
> 
> "in order to avoid any conflict between the link-local address of
> the MS and that of the GGSN,

That conflict is avoided by DAD.

The potential of conflict is very low anyways.

The 3GPP specs should be updated to allow the UE to form the IID as it
pleases, and use maybe DAD, or maybe PPP-style negotiation.

> the Interface-Identifier used by the MS to build its link-local 
> address shall be assigned by the GGSN. The GGSN ensures the 
> uniqueness of this interface-identifier. The MT shall then enforce 
> the use of this Interface-Identifier by the TE."
> 
> BTW, this was inspired by 
> https://tools.ietf.org/html/rfc5072#section-5:
> 
> of the PPP connection setup,

YEs, it is called "negotiation", it means that the UE can equally well
impose its IID.

> it is redundant to perform duplicate address detection (DAD) as a
> part of the IPv6 Stateless Address Autoconfiguration protocol [3] on
> the IPv6 link-local address generated by the PPP peer.

Well, I wonder what kind of redundancy could seem offensive?
There is already a lot NS/NA messaging for the multiple "privacy" GUAs, 
so one more NS/NA would not hurt.

> [Med] It is allowed to do so...for non link-local addresses.

Should be so for all, be them LLs or GUAs.

> [Med] I don't follow you here. There is no privacy concern out
> there. The IID used when forming a global IPv6 address will be
> selected by the terminal; no assumption is made about those bits.

There is a privacy concern: if the operator enforces the UE to always
use the network-assigned IID then that UE is trackable.

Alex

---

From: <[email-masked]>
Date: Mon, 10 Jul 2017 14:16:16 +0000

Alex, 

I'm focusing on this part of your answer. 

Please see inline. 

Cheers,
Med

> De : Alexandre Petrescu [mailto:[email-masked]]
> Envoyé : lundi 10 juillet 2017 15:51
> À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
> Objet : Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address
> 
> Med,
> 
> 

[Med] I'm not sure what you mean by "trackable" in this context. If you mean that "a UE can be identified by the network", then an UE is always identified by the network it connects to! At the IP level, an UE is identified by the bits of the IPv6 prefix, not IID bits. Further, a network does not need IP-related information to identify an UE. 

I still don't see any privacy concern in supplying an IID to an UE to be used for forming its link-local address.

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 10 Jul 2017 16:45:51 +0200

Le 10/07/2017 à 16:16, [email-masked] a écrit :
>> -----Message d'origine----- De : Alexandre Petrescu 
>> [mailto:[email-masked]] Envoyé : lundi 10 juillet 
>> 2017 15:51 À : BOUCADAIR Mohamed IMT/OLN; [email-masked] Objet : 
>> Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address
>> 
>> Med,
>> 
>> 
>>>> This has consequences on privacy, and may impact 
>>>> interoperability when DHCPv6-PD is used later in the process.
>>> 
>> There is a privacy concern: if the operator enforces the UE to 
>> always use the network-assigned IID then that UE is trackable.
>> 
> 
> [Med] I'm not sure what you mean by "trackable" in this context. If 
> you mean that "a UE can be identified by the network", then an UE is 
> always identified by the network it connects to!

YEs, and I thought that is a device-specific identifier like the IMEI,
not the link-local address.

> At the IP level, an UE is identified by the bits of the IPv6 prefix,
>  not IID bits.

Well - by the IP address.

> Further, a network does not need IP-related information to identify 
> an UE.

I agree, so why does it want to impose an IID to the UE?

> I still don't see any privacy concern in supplying an IID to an UE
> to be used for forming its link-local address.

Err...

It's because the supplied IID is very much like an IEEE MAC 48bit
address.  It is guaranteed unique, so it can also be used to track.

Why do you think it can not be used to track?

Alex

---

From: <[email-masked]>
Date: Mon, 10 Jul 2017 14:58:23 +0000

Re-,

Please see inline.

Cheers,
Med

> Envoyé : lundi 10 juillet 2017 16:46

[Med] No. I reiterate my answer: it is identified by the prefix not the full IPv6 address.  Policies at the network are enforced based on the prefix, not the full IPv6 address.  

> I agree, so why does it want to impose an IID to the UE?

[Med] This is an optimization to avoid DAD. 

> address. 

[Med] This is a link-local address not a GUA. So, not sure to understand your point. 

 It is guaranteed unique, so it can also be used to track.

[Med] to be tracked by whom?

---

From: Erik Kline <[email-masked]>
Date: Tue, 11 Jul 2017 00:23:37 +0900

> If there is no such filter, then no need to debate specs.

There is definitely various filtering going on.  In general you cannot, for
example, ping the default router on the mobile link (neither in v4 nor
v6).  Lots of other link-local broadcast/multicast stuff is dropped to save
radio.

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 10 Jul 2017 18:27:47 +0200

> [Med] This is an optimization to avoid DAD.

Ok about LL, but how about the GUA?  If the network uses a GUA same as 
the UE then there should be DAD for that GUA.

I dont think there is any spec that tells that the network MUST NOT 
assign a GUA on its interface towards the UE.

> [Med] This is a link-local address not a GUA. So, not sure to understand your point.

I can understand your point about GUA privacy vs LL privacy.

But.

Some packets with LLs as src have been witnessed in the Internet at large.

Some times some UE apps may put a link-local address in 
application-layer payloads.  Some protocols do it too (e.g. OSPF puts 
LLs in LSAs, DHCP puts interface IDs and LLs in payloads, etc).

> [Med] to be tracked by whom?

By the operator, and by other parties outside the operator network.

Also at the same time do not get me wrong: I do agree that in some cases 
some devices must be tracked by things like law enforcement; it's just 
that it should not be by the IP address.  There is operator-specific 
identifiers like IMEI, SIM card and other IDs for that.

Alex

---

From: Gert Doering <[email-masked]>
Date: Mon, 10 Jul 2017 19:09:11 +0200

Hi,

> the UE then there should be DAD for that GUA.

The network is not using addresses out of the /64 assigned to the handset.

> assign a GUA on its interface towards the UE.

Do not "think" when 3GPP specs are confirmed - just check.  This is
(as has been explained before) standardized quite well.

[..]
> Some packets with LLs as src have been witnessed in the Internet at large.

This is a bug in all the forwarding entities on the path and needs to be
fixed.

> LLs in LSAs, DHCP puts interface IDs and LLs in payloads, etc).

This would be a bug in the application, which would need to be fixed.

(Nobody stated, btw, that you'll get the *same* IID on every PDP setup...)

> By the operator, and by other parties outside the operator network.

The operator knows where you are and what you do, without having to refer
to LLAs.

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: Mon, 10 Jul 2017 19:53:52 +0200

> (as has been explained before) standardized quite well.

I am not sure what you mean there.

> This is a bug in all the forwarding entities on the path and needs to be

That is your oppinion.

There should be nothing wrong in sending packets to the Internet. 
Forwarding is based on the dst address.

Some people say that the src and dst addresses should have the same 
scope, but that is not true either.  Some protocols dont work w/o src 
GUA and dst link-scope multicast.

> This would be a bug in the application, which would need to be fixed.

Well - I think you dont understand.

Speaking only for DHCP here:

DHCP carries interface IDs in UDP payloads.  They're called "Link-layer 
address" 48bit, in Client Identifier, as an UDP payload in DHCPv6 
Solicit, by the User Terminal.

If the Server is in the operator's network, then one could think that 
there is no more tracking danger than without DHCP.  But if the Server 
and intermediary routers are outside the operator's network then there's 
real risk of tracking.

One could not fix the DHCP protocol to eliminate that Client identifier, 
because if so then DHCP will no longer work.

And we said we want DHCP to work in order to get this DHCPv6 Prefix 
Delegation.

Do you see?

I agree.

> The operator knows where you are and what you do, without having to refer

So why does it mandate an IID on the UE?  What is that protocol?

Alex

---

From: Gert Doering <[email-masked]>
Date: Mon, 10 Jul 2017 19:59:42 +0200

Hi,

> > This is a bug in all the forwarding entities on the path and needs to be

It's clear violation of internet standards that say "such packets MUST NOT
be forwarded", so what else can it be but "a bug"?

> Forwarding is based on the dst address.

Please do less thinking, and more reading of standards.

We've been here before.

[..]
> Well - I think you dont understand.

Yeah.

> Solicit, by the User Terminal.

That is not a protocol commonly routed across the internet, so it is of
total irrelevance in this context (and, using MAC address as client 
identifier is strictly optional in DHCPv6, unlike IPv4)

> and intermediary routers are outside the operator's network then there's 

How many networks do you know that route DHCPv6 requests about arbitrary
third party infrastructure?

> because if so then DHCP will no longer work.

Less thinking, more reading.  DHCPv6 initially was specified based on
DUIDs, and *not* MAC addresses.

Gert Doering
        -- NetMaster

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 10 Jul 2017 21:24:12 +0200

Gert,

> be forwarded", so what else can it be but "a bug"?

Well I can only agree with you here, but I will come back later.

[...]

> identifier is strictly optional in DHCPv6, unlike IPv4)

So, you seem to mean that the use of the IID in the payload of a DHCP 
Solicit is not necessarily mandatory.

So it is not because I dont set the right Client Identifier in the DHCP 
Solicit that I dont get replies.

> third party infrastructure?

Well, I think it will come.

The DHCPv6 requests could go very far - they're UDP.  I think the 
Solicit can go beyond link scope (site scope?), and can also be 
addressed to a GUA.

> DUIDs, and *not* MAC addresses.

Initially yes.

Alex

---

From: <[email-masked]>
Date: Tue, 11 Jul 2017 06:51:44 +0000

Hi Alex,

Please see inline.

Cheers,
Med

> Envoyé : lundi 10 juillet 2017 18:28
> > [Med] No. I reiterate my answer: it is identified by the prefix not the
> full IPv6 address.  Policies at the network are enforced based on the
> prefix, not the full IPv6 address.
> >
> >>
> Ok about LL, but how about the GUA?

[Med] No problem at that front either (reading from the 3GPP spec):

==
Since the GGSN guarantees that the Prefix is unique, the MS does not need to perform any Duplicate Address Detection on addresses it creates.
==

  If the network uses a GUA same as
> the UE then there should be DAD for that GUA.

[Med] Idem as above, the spec is clear: 

==
The GGSN shall not generate any globally unique IPv6 addresses for itself using the Prefix assigned to the MS in the Router Advertisement.
==

> assign a GUA on its interface towards the UE.

[Med] See for example, 3GPP TS. 29.061

> I can understand your point about GUA privacy vs LL privacy.

[Med] OK.

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 11 Jul 2017 11:28:03 +0200

>> I can understand your point about GUA privacy vs LL privacy.

Med - why there is no answer to my DHCPv6 PD Solicit?  I am using a GUA 
without the IID from the operator.

Alex

---

From: Erik Kline <[email-masked]>
Date: Tue, 11 Jul 2017 18:49:56 +0900

Is your carrier known to support PD?  I don't think it's very common
yet.  Also, shouldn't you be sending your PD request from a link-local
source address?

On 11 July 2017 at 18:28, Alexandre Petrescu
<[email-masked]> wrote:
>> Since the GGSN guarantees that the Prefix is unique, the MS does not need
>> to perform any Duplicate Address Detection on addresses it creates.
>> ==
>>
>> The GGSN shall not generate any globally unique IPv6 addresses for itself
>> using the Prefix assigned to the MS in the Router Advertisement.
>> ==
>>
>>>
>>>> [Med] This is a link-local address not a GUA. So, not sure to understand
>>>
>>> your point.
>>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 11 Jul 2017 12:09:26 +0200

What do you mean by 'not very common'?  Is it little common in some 
small place?

PD from ll src: I think the DHCP spec does not tell whether it could be 
an LL or a GUA.  I asked on the DHC WG email list.  The operator seems 
to prefer to hear the DHCP Solicit to be issued from a GUA.

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 12 Jul 2017 13:41:39 +0200

Med,

[...]
>>>>> Further, a network does not need IP-related information to
>>>>> identify an UE.
>>>> 
> == Since the GGSN guarantees that the Prefix is unique, the MS does
> not need to perform any Duplicate Address Detection on addresses it
> creates. ==
 >
> 
> == The GGSN shall not generate any globally unique IPv6 addresses for
> itself using the Prefix assigned to the MS in the Router
> Advertisement. ==

I think that spec is wrong (3GPP TS. 29.061?).

Because, in practice some operator on some APN puts a GUA (not an LLA) 
on its router's interface towards the UE.  It uses that GUA in the src 
of the RA sent to the UE.  Packet dump available upon request.

Alex

> 
>> 
>> I dont think there is any spec that tells that the network MUST
>> NOT assign a GUA on its interface towards the UE.
> 
>>>>> I still don't see any privacy concern in supplying an IID to
>>>>> an UE to be used for forming its link-local address.
>>>> 
>>>> Err...
>>>> 
>>>> It's because the supplied IID is very much like an IEEE MAC
>>>> 48bit address.
>>>

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 12 Jul 2017 20:43:39 +0900

On Wed, Jul 12, 2017 at 8:41 PM, Alexandre Petrescu <
[email-masked]> wrote:

> Because, in practice some operator on some APN puts a GUA (not an LLA) on
> its router's interface towards the UE.  It uses that GUA in the src of the
> RA sent to the UE.  Packet dump available upon request.
>

Just because you see it on a USB dongle does not mean the operator is doing
it.

---

From: <[email-masked]>
Date: Wed, 12 Jul 2017 12:02:16 +0000

Alex, 

The key part is not to use (or not) a GUA, but ...

The GGSN shall not generate any globally unique IPv6 addresses for
itself using the Prefix assigned to the MS in the Router
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^     
Advertisement.

Cheers,
Med

> Envoyé : mercredi 12 juillet 2017 13:42
> Objet : Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address and
> GUA
> 
> Med,
> 
> [...]

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 12 Jul 2017 14:03:45 +0200

Le 12/07/2017 à 13:43, Lorenzo Colitti a écrit :
> On Wed, Jul 12, 2017 at 8:41 PM, Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]>>
> wrote:
> 
> Because, in practice some operator on some APN puts a GUA (not an 
> LLA) on its router's interface towards the UE.  It uses that GUA in 
> the src of the RA sent to the UE.  Packet dump available upon
> request.
> 
> 
> Just because you see it on a USB dongle does not mean the operator is
>  doing it.

I dont know what you mean precisely by USB dongle, but I dont see it on
an USB dongle.

I see it with tcpdump on a Sierra IoT module running a form of embedded
linux, gnueabi is the target of the cross compiler.  It uses /dev/ttyAT
device.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 12 Jul 2017 15:19:08 +0200

> itself using the Prefix assigned to the MS in the Router

If it is not the GGSN then who does it?

The UE receives an RA with a GUA in its SRC; packet dump available upon 
request.

Alex

---

From: 神明達哉 <[email-masked]>
Date: Wed, 12 Jul 2017 07:58:06 -0700

At Wed, 12 Jul 2017 13:41:39 +0200,

> of the RA sent to the UE.  Packet dump available upon request.

I have no expertise in the 3GPP spec, but if I understand the above
correctly it's broken even more fundamentally: the source address
of an RA MUST be a link-local address.

4.2.  Router Advertisement Message Format
[...]
      Source Address
                     MUST be the link-local address assigned to the
                     interface from which this message is sent.
(from RFC4861)

If you really see an RA with a non-LL source address, a textual
snippet of the packet dump will certainly be interesting.

--
JINMEI, Tatuya

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 12 Jul 2017 23:59:49 +0900

> I dont know what you mean precisely by USB dongle, but I dont see it on

Sorry, let me reword: "just because you see it on your device does not mean
the operator is doing it".

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 12 Jul 2017 17:15:52 +0200

> snippet of the packet dump will certainly be interesting.

A textual snippet may include addresses that are considered private. 
But I will send you privately the snippet.

Alex

---

From: 神明達哉 <[email-masked]>
Date: Wed, 12 Jul 2017 09:53:56 -0700

At Wed, 12 Jul 2017 17:15:52 +0200,

> But I will send you privately the snippet.

You could mask the sensitive part of it, but, anyway, I actually see
RAs sent from a global address.  I don't know why it behaves that way,
but it's no secret that there are broken implementations so it's not
surprising.  Since the implementation is this broken I don't see any
point in discussing this particular case here - that is, no one here
will be able to answer why a broken implementation is broken or why an
operator uses that broken implementation.  You'll just need to talk to
that operator.

--
JINMEI, Tatuya

---

From: <[email-masked]>
Date: Thu, 13 Jul 2017 05:17:42 +0000

Dear Jinmei, 

I fully agree that there is no point to discuss a broken implementation. 

Alex seems to use a TE/MS split mode. So the addresses he is seeing are not coming from the network.

Cheers,
Med

> De : v6ops [mailto:[email-masked]] De la part de ????
> Envoyé : mercredi 12 juillet 2017 18:54
> À : Alexandre Petrescu
> Cc : [email-masked]

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 13 Jul 2017 11:40:37 +0200

As for the RAs with GUA in src:

I may check the modemDaemon of Sierra Legato to see whether it is that 
generates these RAs with GUA in src, but I really doubt.

Why do you think these RAs dont come from the network?

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 13 Jul 2017 11:43:25 +0200

What is a TE/MS split mode?

Alex

---

From: <[email-masked]>
Date: Thu, 13 Jul 2017 11:32:56 +0000

Re-,

I meant TE/MT. 

I can direct you to 3GPP specs, but the key point is nicely summarized here: 
https://tools.ietf.org/html/rfc7066#section-2.4 

Cheers,
Med

> Envoyé : jeudi 13 juillet 2017 11:43
> À : BOUCADAIR Mohamed IMT/OLN; 神明達哉
> Cc : [email-masked]
> Objet : Re: [v6ops] RFC6459 "IPv6 in 3GPP" - TE/MS split mode?
> 
> and

---

From: <[email-masked]>
Date: Fri, 14 Jul 2017 10:33:04 +0000

See below with [HM]
-----Ursprüngliche Nachricht-----
Von: v6ops [mailto:[email-masked]] Im Auftrag von Alexandre Petrescu
Gesendet: Mittwoch, 12. Juli 2017 14:04
An: Lorenzo Colitti
Cc: [email-masked]
Betreff: Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address and GUA

I see it with tcpdump on a Sierra IoT module running a form of embedded
linux, gnueabi is the target of the cross compiler.  It uses /dev/ttyAT
device.
[HM] WWAN Modem Chipsets perform some kind of translation of packets, especially ICMPv6 packets, between the interface to the computer and the interface towards the provider network. The reason is that the computer wants to see an Ethernet broadcast interface, but the provider interface is point-to-point. For example, the computer needs Neighbor Discovery but this is not available on the provider interface. The provider's network device doesn't have a MAC address either, so the modem chipset emulates this missing MAC to the computer.

So what you capture on WWAN0 (or however your computer interface is named) is not what actually goes over the air.

Holger

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 14 Jul 2017 21:02:23 +0200

Le 14/07/2017 à 12:33, [email-masked] a écrit :
> See below with [HM] -----Ursprüngliche Nachricht----- Von: v6ops 
> [mailto:[email-masked]] Im Auftrag von Alexandre Petrescu 
> Gesendet: Mittwoch, 12. Juli 2017 14:04 An: Lorenzo Colitti Cc: 
> [email-masked] Betreff: Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID 
> in the LL address and GUA
> 
> 
> I see it with tcpdump on a Sierra IoT module running a form of 
> embedded linux, gnueabi is the target of the cross compiler.  It
> uses /dev/ttyAT device.

> [HM] WWAN Modem Chipsets perform some kind of translation of packets,

This seems like a generalisation.  I do not understand what do you mean 
by WWAN Modem Chipsets - can you give an example of a WWAN Modem Chipset?

In my particular case there is no separated Modem Chipset from an 
Application Chipset, or App Processor vs. Broadband Processor, or 
something like that that one can find in many smartphones.  Or like 
Host-IMP distinciton of early RFCs.

In my case it is an IoT device.  It is called an "integrated module" and 
it runs linux.  It is from Sierra, format CF3, series WP8.

There is only one module running both linux and the cellular interface.

> especially ICMPv6 packets, between the interface to the computer and
> the interface towards the provider network. The reason is that the
> computer wants to see an Ethernet broadcast interface, but the
> provider interface is point-to-point. For example, the computer needs
> Neighbor Discovery but this is not available on the provider
> interface. The provider's network device doesn't have a MAC address
> either, so the modem chipset emulates this missing MAC to the
> computer.

Do you think it is a linux kernel module that performs that emulation, 
or is it completely another OS (like ThreadX)?

That emulation must be standardised.

> So what you capture on WWAN0 (or however your computer interface is 
> named) is not what actually goes over the air.

If you think that something else goes over the air, can you tell me how, 
or what capturing tool, did you find out that there is something else 
over the air?

My operator asks me the same thing - what goes over the air - and I dont 
know what to answer.

Alex

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

---

From: <[email-masked]>
Date: Mon, 17 Jul 2017 07:17:52 +0000

See below with[HM]

Holger

-----Ursprüngliche Nachricht-----
Von: v6ops [mailto:[email-masked]] Im Auftrag von Alexandre Petrescu
Gesendet: Freitag, 14. Juli 2017 21:02
An: [email-masked]
Betreff: Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address and GUA

> [HM] WWAN Modem Chipsets perform some kind of translation of packets,

This seems like a generalisation.  I do not understand what do you mean by WWAN Modem Chipsets - can you give an example of a WWAN Modem Chipset?

In my particular case there is no separated Modem Chipset from an Application Chipset, or App Processor vs. Broadband Processor, or something like that that one can find in many smartphones.  Or like Host-IMP distinciton of early RFCs.

In my case it is an IoT device.  It is called an "integrated module" and it runs linux.  It is from Sierra, format CF3, series WP8.

[HM] Look into their datasheets, they call it "Telecom core" there, and it seems to be a Qualcomm Hexagon based chipset.

[HM] And this module has two processors, one for the application, and one for the telecom side (usually called "the modem").

> either, so the modem chipset emulates this missing MAC to the 

Do you think it is a linux kernel module that performs that emulation, or is it completely another OS (like ThreadX)?

[HM] No, it is a separate processor (actually a DSP).

[HM] Well, obviously nobody saw the need for it until now, it is actually implementation specific. It would be a good idea indeed to specify this. Most of these translation layers drop all DHCPv6 traffic so no chance to get Prefix Delegation working if it is initiated by the host. There is a need for such translation otherwise Ipv6 won't work. Ipv4 neither - Ipv4 address assignment on the carrier side does not use DHCPv4 which the mobile host usually speaks. This is the downside of presenting an Ethernet interface to the Operating system. The upside is the there is no need to change OS specific handling of a WWAN interface since it can be handled like any other Ethernet interface. Otherwise, each OS would have to implement an interface driver complying to 3GPP's view of the wireless network connectivity.

> named) is not what actually goes over the air.

If you think that something else goes over the air, can you tell me how, or what capturing tool, did you find out that there is something else over the air?

[HM] I traced within the operator's network, looking at the GTP traffic just in front of the GGSN/PGW.

My operator asks me the same thing - what goes over the air - and I dont know what to answer.
[HM] Tell them to trace your GTP traffic right in front of their GGSN/PGW (e.g. Gn interface).