Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address and GUA

[<[e-mail]>]

See below with[HM]

Holger

-----Ursprüngliche Nachricht-----
Von: v6ops [mailto:[e-mail]] Im Auftrag von Alexandre Petrescu
Gesendet: Freitag, 14. Juli 2017 21:02
An: [e-mail]
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.

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

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

> 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)?

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

That emulation must be standardised.

[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.

> 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?

[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).