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

[Mark Smith <[e-mail]>]

On 18 Feb 2016 7:40 PM, "Alexandre Petrescu" <[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]>>
>>
>>  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.

Share64 is based on the premise that the whole /64 is routed to the UE. 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.


> 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]> 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]>,
>>>>
>>>> [e-mail] <mailto:[e-mail]>, [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]>.  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]>
>>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>>