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

Le 17/02/2016 20:56, Mark Smith a écrit :
>
> On 18 Feb 2016 2:26 AM, "Alexandre Petrescu"
> <alexandre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>>
>  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 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, rfc-editor@rfc-editor.org
> <mailto:rfc-editor@rfc-editor.org> 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:
>>> cameron.byrne@t-mobile.com
> <mailto:cameron.byrne@t-mobile.com>,
>>> dan@drown.org <mailto:dan@drown.org>, ales.vizdal@t-mobile.cz
>>> <mailto:ales.vizdal@t-mobile.cz> 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
>>> rfc-editor@rfc-editor.org
> <mailto:rfc-editor@rfc-editor.org>.  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
>> v6ops@ietf.org <mailto:v6ops@ietf.org>
>> https://www.ietf.org/mailman/listinfo/v6ops
>