Re: [v6ops] RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link

[Alexandre Petrescu <[e-mail]>]

Le 18/02/2016 10:50, Mark Smith a écrit :
>
> On 18 Feb 2016 7:40 PM, "Alexandre Petrescu"
> <[e-mail] <mailto:[e-mail]>>
> wrote:
>>
>>
>>
>> Le 17/02/2016 20:56, Mark Smith a écrit :
>>>
>>>
>>> On 18 Feb 2016 2:26 AM, "Alexandre Petrescu"
>>> <[e-mail]
>>> <mailto:[e-mail]>
> <mailto:[e-mail]
> <mailto:[e-mail]>>>
>>>
>>> wrote:
>>>>
>>>>
>>>> Hi,
>>>>
>>>> I have a comment on this RFC7278.
>>>>
>>>> The comment comes from the observation that the operator also
>>>> uses an
>>>
>>> address from the 64share prefix (a global address).
>>>>
>>>>
>>>
>>> Are you sure about that?
>>
>>
>> YEs.  In the UE the address of the default router is an address
>> prefixed by the same prefix as the prefix that the UE believes is
>> for self (the 64share prefix).
>>
>> The default router address is not a link-local address (it's a
>> GUA), although it could have been LL in theory.
>>
>
> And in practice. Route next hops are supposed to be LLs except in
> some BGP cases.

I agree that route next hops are better LLs (or ULAs) in order to save
addressing space.  I think there is a draft about this.

> Share64 is based on the premise that the whole /64 is routed to the
> UE.

Yes.

> I don't know a lot about the 3GPP specs, but I presume that is what
> they say is to happen.
>
> I think the fundamental issue is that the 3GPP people decided to
> treat a smartphone as special, and came up with their own ways of
> doing IPv6 on them, rather than just treating the phone as nothing
> more than a host with a point to point link to the network, and then
> just writing an IPv6 over 3GPP link RFC, and therefore supporting
> standard IPv6 methods for ND, RAs, DHCPV6-PD etc. over that 3GPP
> link.
>
> So whatever appears in share64 is a work around to the
> non-conventional model they chose. It's going to have caveats and
> limitations because it isn't conventional. If somebody does something
> even more unconventional that 3GPP specs for IPv6, like a GUA router
> addresses rather than an LL (which they'd have if they were using
> RAs, because that is what the RA RFC says must be used) then share64
> probably won't work either.

I can agree.

It is even worse because we can't make definitive statements whether it
will work or not.  We dont know.  In some cases the random number
generators of IP-over-USB implementations may collide with the ppp
Interface ID generators on the cellular SGSN and this may lead to
disconnections of the devices behind the UE (in the moving network) or 
of the UE altogether.

Alex

>
>
>> And this time, different from my earlier experiments, the 64share
>> happens on the module - i.e. there is no intermediary modem like a
>> cellular USB dongle or something which would do things not in
>> control, like proxy ND or proxy DHCP.
>>
>>
>>> It was my understanding that the unconventional thing about a
>>> 3GPP setup was that all traffic to all addresses within the /64
>>> was (blindly) forwarded to the UE, even if the UE uses one or
>>> more of those addresses on the end of the link. I think that is
>>> only possible because the link is a point to point one.
>>
>>
>> YEs, that is the case - all addresses in the prefix are forwarded
>> to the UE.  But I doubt the operator forwards to UE the packets
>> addressed to the default router.  This is something I can try and
>> report.
>>
>> (it would be strange that the packets addressed of the default
>> router be forwarded to the UE, but one never knows with the ppp
>> links).
>>
>>
>>> (Presumably the UE has a discard route for the /64 to prevent
>>> loops for non-existent addresses.)
>>
>>
>> YEs.  W/o 64share the UE installs a route for the /64 on its
>> cellular interface (a "*" route on which UE does ND).  Then when
>> doing 64share the UE must remove that route from the cellular
>> interface and install it on its other interface (USBnet in my
>> case).  I guess this is what you mean by discard route.
>>
>> However, it must maintain on its celluar interface the default
>> route (a /128 host-based route).
>>
>> Alex
>>
>>>> As such that address too should not be used in the 'LAN'.
>>>>
>>>> This may lead to several textual modifications to the
>>>> document. For
>>>
>>> example:
>>>>>
>>>>>
>>>>> R-2: The UE MUST defend all of its IPv6 addresses on the LAN
>>>>> link.
>>>>
>>>>
>>>>
>>>> This is wrongly stated, because the UE does not own that
>>>> prefix, so
>>>>
>>> it can't say "its IPv6 addresses".  That prefix is belonging to
>>> a link not to the UE, because the operator also makes an address
>>> out of it.
>>>>
>>>>
>>>> Alex
>>>>
>>>> Le 26/06/2014 22:55, [e-mail]
> <mailto:[e-mail]>
>>>
>>> <mailto:[e-mail]
> <mailto:[e-mail]>> a écrit :
>>>
>>>>>
>>>>> A new Request for Comments is now available in online RFC
>>>>> libraries.
>>>>>
>>>>>
>>>>> RFC 7278
>>>>>
>>>>> Title:      Extending an IPv6 /64 Prefix from a Third
>>>>> Generation Partnership Project (3GPP) Mobile Interface to a
>>>>> LAN Link Author: C. Byrne, D. Drown, A. Vizdal Status:
>>>>> Informational Stream: IETF Date:       June 2014 Mailbox:
>>>>> [e-mail]
>>>>> <mailto:[e-mail]>
>>>
>>> <mailto:[e-mail]
>>> <mailto:[e-mail]>>,
>>>>>
>>>>> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
> <mailto:[e-mail]>>, [e-mail]
> <mailto:[e-mail]>
>>>>> <mailto:[e-mail]
>>>>> <mailto:[e-mail]>>
> Pages:      10 Characters:
>>>>>
>>>>> 19965 Updates/Obsoletes/SeeAlso:   None
>>>>>
>>>>> I-D Tag:    draft-ietf-v6ops-64share-10.txt
>>>>>
>>>>> URL: http://www.rfc-editor.org/rfc/rfc7278.txt
>>>>>
>>>>> This document describes requirements for extending an IPv6
>>>>> /64 prefix from a User Equipment Third Generation Partnership
>>>>> Project (3GPP) radio interface to a LAN link and describes
>>>>> two implementation examples.
>>>>>
>>>>> This document is a product of the IPv6 Operations Working
>>>>> Group of
>>>
>>> the IETF.
>>>>>
>>>>>
>>>>>
>>>>> INFORMATIONAL: This memo provides information for the
>>>>> Internet
>>>
>>> community.
>>>>>
>>>>> It does not specify an Internet standard of any kind.
>>>>> Distribution of this memo is unlimited.
>>>>>
>>>>> This announcement is sent to the IETF-Announce and rfc-dist
>>>>> lists. To subscribe or unsubscribe, see
>>>>> http://www.ietf.org/mailman/listinfo/ietf-announce
>>>>> http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
>>>>>
>>>>> For searching the RFC series, see
>>>>> http://www.rfc-editor.org/search For downloading RFCs, see
>>>>> http://www.rfc-editor.org/rfc.html
>>>>>
>>>>> Requests for special distribution should be addressed to
>>>>> either the author of the RFC in question, or to
>>>>> [e-mail] <mailto:[e-mail]>
>>>
>>> <mailto:[e-mail]
> <mailto:[e-mail]>>.  Unless
>>>>>
>>>>> specifically noted otherwise on the RFC itself, all RFCs are
>>>>> for unlimited distribution.
>>>>>
>>>>>
>>>>> The RFC Editor Team Association Management Solutions, LLC
>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________ v6ops mailing
>>>> list [e-mail] <mailto:[e-mail]>
>>>> <mailto:[e-mail]
> <mailto:[e-mail]>>
>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>
>>>
>