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

[Alexandre Petrescu <[e-mail]>]

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

> On 10 July 2017 at 19:11, Alexandre Petrescu 
> <[e-mail]> wrote:
>> 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
>> 
>> _______________________________________________ v6ops mailing list
>>  [e-mail] https://www.ietf.org/mailman/listinfo/v6ops