Re: [v6ops] draft-ietf-v6ops-64share

[Alexandru Petrescu <[e-mail]>]

Le 22/01/2013 21:34, Cameron Byrne a écrit :
> Mark,
>
> On Tue, Jan 22, 2013 at 11:38 AM, Mark Smith
> <[e-mail]> wrote:
>>
>> Hi Cameron,
>>
>>
>>> ________________________________ From: Cameron Byrne
>>> <[e-mail]> To: Mark Smith <[e-mail]>
>>> Cc: v6ops v6ops WG <[e-mail]> Sent: Monday, 21 January
>>> 2013 3:53 AM Subject: Re: [v6ops] draft-ietf-v6ops-64share
>>>
>>>
>>> Mark, Sent from ipv6-only Android On Jan 20, 2013 3:31 AM, "Mark
>>> Smith" <[e-mail]> wrote:
>>>>
>>>> Hi,
>>>>
>>>>
>>>>> ________________________________ From: Cameron Byrne
>>>>> <[e-mail]> To: [e-mail] Sent: Sunday, 20
>>>>> January 2013 12:23 PM Subject: [v6ops]
>>>>> draft-ietf-v6ops-64share
>>>>>
>>>>>
>>>>> Hi, I posted this update as a WG draft
>>>>> http://tools.ietf.org/html/draft-ietf-v6ops-64share-00
>>>>> Please take the time to review this update and share your
>>>>> feedback. I hoping that a clearly defined scope, clear need
>>>>> for this work,  as well running code will make it easy to
>>>>> advance. I am now aware of 3 implementations that
>>>>> approximately use this method (ios6, an LTE mifi router, and
>>>>> Dan Drown's Android submission)
>>>>
>>>> Regarding this text,
>>>>
>>>> 9.  Since the address 2001:db8:ac10:f002:1234:4567:0:9/128 is
>>>> the only instance of the assigned /64 on the 3GPP interface,
>>>> there is no chance of an address conflict on that interface. On
>>>> the LAN interface, there is no chance of address conflict since
>>>> the
>>>>
>>>>
>>>>
>>>> Byrne                    Expires June 17, 2013 [Page 4]
>>>>
>>>> V6OPS Working Group   draft-ietf-v6ops-64share-00
>>>> December 14, 2012
>>>>
>>>>
>>>> address is defended using Duplicate Address Detection (DAD).
>>>>
>>>> I'd suggest adding something like "address is defended using
>>>> Duplicate Address Detection (DAD), as the LAN interface is
>>>> also assigned the address in use on the 3GPP interface."
>>>>
>>>> I struggled a bit with working out what was going on until it
>>>> became clear that the 3GPP and LAN interfaces are using the
>>>> same global unicast address.
>>>>
>>> The DAD procedure on the LAN is only scoped for the LAN. For the
>>> 3gpp link, it is the fact that only 1 off-link address is
>>> architecturally permitted by 3gpp that ensures no collision. Did
>>> I parse your concern correctly?
>>
>> Initially what confused me was I thought the /128 that is assigned
>> to the 3GPP interface had been "stolen" from within the /64
>> assigned to the LAN interface i.e. a hole had been punched in the
>> /64, and that is why I wondered how DAD was working in that
>> scenario. While covered in other areas, further reinforcing the
>> duplication of the address when functions would break without it
>> could be useful.
>>
>>>> I also think it would be better to be clearer about the type
>>>> of IPv6 address and also cover that their may be multiple IPv6
>>>> addresses, such as privacy addresses on the 3GPP/LAN
>>>> interface. For example, in 3. Method for Sharing the 3GPP
>>>> Interface /64 to the Tethered LAN,
>>>>
>>>> "The UE checks to make sure the 3GPP interfaces is active and
>>>> has an IPv6 address.  If the interface does not have an IPv6
>>>> address, an attempt will be made to acquire one, or else the
>>>> procedure will terminate."
>>>>
>>>> Strictly, the 3GPP interface always has an IPv6 address
>>>> because it always has a link local address, so the above would
>>>> be better if it clarified that the type of address to check for
>>>> is a global IPv6 address.
>>>>
>>> Ack. I will change it to "globally scoped address"
>>>> I'll have to do some digging, however I'm wondering if the
>>>> sockets API might have an assumption that an individual IPv6
>>>> address is only assigned to a single interface.
>>>>
>>>> Actually, reviewing the IPv6 Addressing Model in RFC4291, it
>>>> says, "An IPv6 unicast address refers to a single interface."
>>>>
>>>> Was a translational bridge model considered? That is, the 3GPP
>>>> and LAN interfaces are part of a bridge instance, and a single
>>>> bridge virtual layer 2/3 interface is assigned the UE's global
>>>> unicast address within the /64, with a /64 prefix length.
>>>> Enabling or disabling tethering would be a simple matter of
>>>> administratively enabling/disabling the LAN interface.
>>>>
>>> Is there an ietf doc on what a translational bridge is? We
>>> considered ndproxy but that method was deemed unfit due to
>>> insufficient loop prevention.
>>
>> Translational bridging goes back to the token ring and ethernet
>> days. At layer 2 they were similar enough (because they were both
>> IEEE standards), to be able to translate reasonably effectively
>> between them, such that they combined token ring/ethernet LAN was
>> presented as a single link at layer 3. I was wondering about
>> reusing that model because it could have been a way to avoid
>> duplicating the 3GPP address on the LAN interface. Whether it is
>> possible to do between 3GPP and Ethernet would depend on how
>> similar they are at layer 2, although one thing that would
>> probably help is that the 3GPP link (if I understand correctly), is
>> a point to point link, so the translational bridging would really
>> only be to present the single remote 3GPP device as an ethernet
>> device on the LAN interface.
>>
>
> I think would rather avoid any of this translational bridging
> business.  And in fact, i am only trying to document  running code to
> avoid multiple divergent methods of achieving the same goal.

As described, the 'translational' bridging looks new to me.  It looks
feasible, yes, yet I don't understand whether it would perform better
than the method in the draft.  I will read the draft better.

> That said, it appears a few folks (Rajiv and Alex) have some
> indigestion over having one IP address in multiple places.  It works
>  for me, but i can accept that it may not work well for others.
>
> So, i think i can change the wording to allows for 2 methods
>
> 1)  When tethering is enabled, move /64 from 3GPP interface to LAN
> interface and run 3GPP interface with only Link Local while
> tethering. This results in active connection possibly being bounced
> while tethering is turned on and off.

This is right - possibly the application on the UE using the global
address may be interrupted if tethering is turned off.  The
implementation should make sure that when the tethering is turned off
the address is assigned back again to the cellular interface.

Speaking of which, I think it would be appropriate if the text discusses
(if it does not already) that when the UE wants to tether it will become
a Router.  A Router will not use the PIO in RA to form a global address.
  I.e. if tethering is turned on, and followed by UE connecting to
cellular, the UE will not have a global address on its cellular.  (if on
the other hand the UE first connects to cellular and then turns
tethering on, the address will stay on the cellular interface for a while).

> 2)  Alternatively, retain the /128 address on the 3GPP interface and
>  copy the /64 to the LAN with the same address as /128. (same as is
> documented already in 00)

Yes, it is documented, steps 1-9.

Alex

>
> CB
>
>> Thinking about it some more, perhaps the following model might
>> achieve a single IPv6 address identifying a single interface more
>> conventionally -
>>
>> - 3GPP link is "unnumbered", only having a link local address
>>
>> - UE has a bridge instance, with a bridge virtual interface (BVI)
>> that is always present.
>>
>> - the IPv6 address configuration information (i.e. RA PIO for
>> SLAAC) is received over the 3GPP link, but is used to configure
>> global IPv6 address(es) on the BVI, leaving the 3GPP link
>> "unnumbered". I think the "loophole" that would allow this is that
>> I don't think IPv6 requires that the address configuration
>> information used to configure addresses on an interface is
>> required to arrive over that interface, although commonly it does.
>>
>> - tethering is enabled or disabled by adding or removing the LAN
>> interface(s) to or from the bridge. An optimisation would be to
>> issue RAs immediately after the LAN interface is enabled.
>>
>> - conventional routing will take care of forwarding traffic
>> received over the 3GPP interface to the global addresses on the
>> BVI.
>>
>> Regards, Mark.
>>
>>
>>
>>
>>
>>> CB
>>>> Regards, Mark.
>>>
>>>
>>>
> _______________________________________________ v6ops mailing list
> [e-mail] https://www.ietf.org/mailman/listinfo/v6ops
>
>