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

From: Cameron Byrne <[email-masked]>
Date: Sat, 19 Jan 2013 17:23:50 -0800

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)

CB

Sent from ipv6-only Android

---

From: Mark Smith <[email-masked]>
Date: Sun, 20 Jan 2013 03:31:31 -0800 (PST)

Hi,

>________________________________
> From: Cameron Byrne <[email-masked]>
>To: [email-masked] 
>Sent: Sunday, 20 January 2013 12:23 PM
>Subject: [v6ops] draft-ietf-v6ops-64share
> 
>
>Hi,
>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.

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.

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.

Regards,
Mark.

---

From: Cameron Byrne <[email-masked]>
Date: Sun, 20 Jan 2013 08:53:20 -0800

Mark,

> 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?

> 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,
> 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.

CB

---

From: Cameron Byrne <[email-masked]>
Date: Sun, 20 Jan 2013 09:07:40 -0800

Mark,

Just on the this one topic

<Snip>

Should we explicitly call it anycast then? Is that worth noting in the
draft, citing  tools.ietf.org/html/rfc4291#section-2.6

CB

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Sun, 20 Jan 2013 21:00:17 +0000

Hi Cameron,

It wasn't crystal clear that LAN side and WAN side interfaces were using the same IPv6 address. So, Mark's suggested text will make it clear.

You might also want to mention 'no DAD on WAN interface (i.e. 3GPP interface)' before mentioning DAD on LAN interface. 

Wrt assigning the same IP address on two different (IP-enabled) interfaces, I can only think of 'IP unnumbered' model and it might be worth mentioning.  Else, what could it be? What's implemented in iOS?

> Is there an ietf doc on what a translational bridge is? We considered

I don't think so, but there are number of RFCs that refer to IEEE specification for bridging. Check out the L2VPN WG.

> > "The UE checks to make sure the 3GPP interfaces is active and has

Cheers,
Rajiv

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Cameron Byrne
> Sent: Sunday, January 20, 2013 11:53 AM
> To: Mark Smith
> Cc: v6ops v6ops WG
> Subject: Re: [v6ops] draft-ietf-v6ops-64share
> 
> Mark,
> 
> > 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.
> >
> 
> it is the fact that only 1 off-link address is architecturally permitted by 3gpp
> that ensures no collision.
> 
> > 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,
> >
> 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.
> >
> 
> 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."
> >
> 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.
> >
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 22 Jan 2013 09:34:25 +0100

Le 20/01/2013 18:07, Cameron Byrne a écrit :
>> Actually, reviewing the IPv6 Addressing Model in RFC4291, it says,
>>
> "An IPv6 unicast address refers to a single interface."
>>
>
> Should we explicitly call it anycast then? Is that worth noting in
> the draft, citing tools.ietf.org/html/rfc4291#section-2.6
> <http://tools.ietf.org/html/rfc4291#section-2.6>

But that sense of anycast has a notion of 'neareast', whereas here
they'd be equally distant (on same computer) and hence the decision to
route it would be guided by an unknown rule.

Instead of calling it anycast, one alternative is to remove it from the
cellular interface (ifconfig del), and then assign it to the WLAN interface.

In this way there would be no worry about same address on two different
interfaces.

Alex

>
> CB
>
>
>
> _______________________________________________ v6ops mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Mark Smith <[email-masked]>
Date: Tue, 22 Jan 2013 11:38:27 -0800 (PST)

Hi Cameron,

>To: Mark Smith <[email-masked]> 
>Cc: v6ops v6ops WG <[email-masked]> 
>Sent: Monday, 21 January 2013 3:53 AM
>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. 

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.

>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.

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.

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 22 Jan 2013 12:34:07 -0800

Mark,

> 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 bet…

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.

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.

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)

CB

---

From: Vízdal Aleš <[email-masked]>
Date: Tue, 22 Jan 2013 22:42:05 +0100

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark
> Smith
> Sent: Tuesday, January 22, 2013 8:38 PM
> To: Cameron Byrne
> Cc: [email-masked]
 
> 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.

To my understanding there is no link-layer addressing at the 3GPP interface, so it wouldn't
be easy to do l2 bridging.

> Mark.

Cheers,
Ales

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 22 Jan 2013 15:48:06 -0800

Relevant for this thread http://prolixium.com/blog?id=984

---

From: Mark Smith <[email-masked]>
Date: Wed, 23 Jan 2013 10:41:39 -0800 (PST)

Hi Cameron,

>Sent: Monday, 21 January 2013 4:07 AM
>Should we explicitly call it anycast then? Is that worth noting in the draft, citing  tools.ietf.org/html/rfc4291#section-2.6

While I think what you're doing could qualify as anycast, as the above text says, anycast addresses have to be flagged as anycast addresses -

"the nodes to which the address is
   assigned must be explicitly configured to know that it is an anycast
   address."

That influences ND operation for the anycast address - the first ND NA response received after a ND NS is the one accepted, rather than the last, and Duplicate Address Detection is switched off for the anycast address. If my understanding is correct, the latter defeats one of the main motivations for duplicating the address on the 3GPP and LAN interfaces in your scenario in the first place.

ND NS/NA handling anycast text
https://tools.ietf.org/html/rfc4861#section-7.2.7

ND anycast DAD text
https://tools.ietf.org/html/rfc4862#section-5.4

Regards,
Mark.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 24 Jan 2013 09:27:29 +0100

Le 22/01/2013 21:34, Cameron Byrne a écrit :
>>> ________________________________ From: Cameron Byrne
>>> <[email-masked]> To: Mark Smith <[email-masked]>
>>> Cc: v6ops v6ops WG <[email-masked]> 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" <[email-masked]> wrote:
>>>>
>>>> Hi,
>>>>
>>>>
>>>>> ________________________________ From: Cameron Byrne
>>>>> <[email-masked]> To: [email-masked] Sent: Sunday, 20
>>>>> January 2013 12:23 PM Subject: [v6ops]
>>>>> draft-ietf-v6ops-64share
>>>>>
>>>>>
>>>>> Hi, I posted this update as a WG draft
>>>>> 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
>>>>
>>>>
>>>>
>>>> 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.
>>>>
>>>> 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

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.

> 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).

> 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 -
>>
>> - 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.
>>>
>>>
>>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 24 Jan 2013 10:56:24 +0100

Le 22/01/2013 22:42, Vízdal Aleš a écrit :
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Mark Smith Sent:
>> Tuesday, January 22, 2013 8:38 PM To: Cameron Byrne Cc:
>> [email-masked] Subject: Re: [v6ops] draft-ietf-v6ops-64share
>
>> 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.
>
> To my understanding there is no link-layer addressing at the 3GPP
> interface, so it wouldn't be easy to do l2 bridging.

Well it depends.

In general I think very many cellular interfaces on the UE do not use
link-layer addressing.  The devices have 'all-zero' MAC address, use the
"NO_ARP" flag and so on.

However, more recent devices (e.g. USB keys for LTE: bandrich C502,
huawei e392, more) using qualcomm chipsets in some instances, using
'qmi' interfaces and drivers, exhibit a form of link-layer addressing.

First, these devices use centrally-allocated IEEE identifiers for
Company_ID.  Suprisingly to some, the well known file oui.txt exhibits
such id's for manufacturers of 3GPP-compatible equipment (traditionally
it mentions only manufacturers of IEEE-compatible equipment).

Second, some kernel modules, for instance in the 'qmi' family, form the
last 3 bytes of a 48bit address.

Finally, wireshark dumps of packets emitted by these cellular interfaces
show Ethernet headers with MAC src and dst addresses, and interprets
them according to oui.txt (wireshark interpretation is a good indicator
about the width of the spread of some protocol).

These three aspects make me think that maybe the new and future cellular
interfaces may be more and more link-layer addressable.

One consequence is the arrival of the use of classical ND on these
links, and, why not, the bridging forms which are customary on Ethernet
links.

(caveat emptor: yes much intelligence exists in the small computer in a
USB key that may make some things appear what they are not - proxying,
on behalf of, etc. - yet they don't run the IP stack, it's the USB Host
computer which runs the stack).

Alex

>
>> Regards, Mark.
>
> Cheers, Ales _______________________________________________ v6ops
> mailing list [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 24 Jan 2013 11:39:34 +0100

> Relevant for this thread http://prolixium.com/blog?id=984

Right; is this ipv6 MASQUERADE implementing the RFC 6296 "IPv6-to-IPv6
Network Prefix Translation"?

If yes then I think it is relevant to aspects of the problem that
64share solve.  I.e. if one wants to do tethering one could use RFC6296
instead of 64share.

This RFC could be cited and commented in the 64share draft.

Alex

> On Jan 19, 2013 5:23 PM, "Cameron Byrne" <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> Hi,
>
> 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

---

From: Vízdal Aleš <[email-masked]>
Date: Thu, 24 Jan 2013 13:58:08 +0100

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Alexandru Petrescu
> Sent: Thursday, January 24, 2013 10:56 AM
> To: [email-masked]

Alex,

> link-layer addressing.  The devices have 'all-zero' MAC address, use the

What are you seeing is not the 3GPP link traffic, but the Ethernet emulation 
done by the modem firmware. To be able to sniff on the 3GPP interface level
you would need a tracer to see what's happening there.

Ales

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 24 Jan 2013 14:00:45 +0100

Le 24/01/2013 13:58, Vízdal Aleš a écrit :
>> [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
>> Sent: Thursday, January 24, 2013 10:56 AM To: [email-masked]
>>> To my understanding there is no link-layer addressing at the
>>> 3GPP interface, so it wouldn't be easy to do l2 bridging.
>>
>> Well it depends.
>>
>> In general I think very many cellular interfaces on the UE do not
>> use link-layer addressing.  The devices have 'all-zero' MAC
>> address, use the "NO_ARP" flag and so on.
>
> What are you seeing is not the 3GPP link traffic, but the Ethernet
> emulation done by the modem firmware.

YEs to some extent.

But what that firmware does may be more than simple emulation.

(an emulator would not generate packets at its will but only upon request).

An IP stack is happier to work with an emulator than with a 3GPP link.

> To be able to sniff on the 3GPP interface level you would need a
> tracer to see what's happening there.

Ok, but what is a tracer?  Where can I obtain one?

Do you mean wireshark?

Alex

>
>> However, more recent devices (e.g. USB keys for LTE: bandrich
>> C502, huawei e392, more) using qualcomm chipsets in some instances,
>> using 'qmi' interfaces and drivers, exhibit a form of link-layer
>> addressing.
>>
>> Company_ID.  Suprisingly to some, the well known file oui.txt
>> exhibits such id's for manufacturers of 3GPP-compatible equipment
>> (traditionally it mentions only manufacturers of IEEE-compatible
>> equipment).
>>
>> Second, some kernel modules, for instance in the 'qmi' family, form
>> the last 3 bytes of a 48bit address.
>>
>> Finally, wireshark dumps of packets emitted by these cellular
>> interfaces show Ethernet headers with MAC src and dst addresses,
>> and interprets them according to oui.txt (wireshark interpretation
>> is a good indicator about the width of the spread of some
>> protocol).
>>
>> These three aspects make me think that maybe the new and future
>> cellular interfaces may be more and more link-layer addressable.
>>
>> links, and, why not, the bridging forms which are customary on
>> Ethernet links.
>>
>> (caveat emptor: yes much intelligence exists in the small computer
>> in a USB key that may make some things appear what they are not -
>> proxying, on behalf of, etc. - yet they don't run the IP stack,
>> it's the USB Host computer which runs the stack).
>>
>> Alex
>
> Ales
>
>

---

From: Vízdal Aleš <[email-masked]>
Date: Thu, 24 Jan 2013 15:56:36 +0100

> From: Alexandru Petrescu [mailto:[email-masked]]
> Sent: Thursday, January 24, 2013 2:01 PM
> To: Vízdal Aleš
> Cc: [email-masked]

Alex,

> Ok, but what is a tracer?  Where can I obtain one?

That's something the chipset vendors can provide the terminal testers
with, so they can see the 3gpp link traffic in the provided tracing software.

> Do you mean wireshark?

No, I don't as wireshark cannot be attached directly to the 3gpp link as it
has no access to it.

Ales

---

From: Vízdal Aleš <[email-masked]>
Date: Thu, 24 Jan 2013 16:08:21 +0100

> Sent: Thursday, January 24, 2013 11:40 AM
> To: [email-masked]

Alex,
 
> Network Prefix Translation"?

there are two ip6tables modules available - ip6t_NAt that is providing
RFC6296 support that allows you to set the IPv6 prefix IPv6 packets will
be translated to and ip6t_MASQUERADE that is taking the prefix
from a defined interface (e.g. wwan0).

> This RFC could be cited and commented in the 64share draft.

Well, there is a difference as the current draft allows for /64 sharing and 
a GUA to be assigned to a host, the 6296 approach wouldn't support
it. (i am not saying that's bad, just noting it)

Ales

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 24 Jan 2013 18:38:56 +0100

Cameron, thank you for the new version, and as WG item.

I have some comments below, if time allows.  This is my personal oppinion.

> router, and Dan Drown's Android submission)

Well, in addition to this mostly handheld mobile device implementations,
one could add a larger PC variable platform for deploying in vehicles -
a Mobile Router using ubuntu linux, on atom 32bit and 64bit, with 3G,
LTE-in-3G-mode testing using nokia, icon, bandrich and huawei USB keys
and miniPCI 3G+, with ppp and qmi.

The method described in the draft was tested, as well as some variations
of it (e.g. assign the IP address solely on the LAN interface and remove
it from the WWAN interface; configure the IPv6 address from RA or
scripted, on ptp link or on Ethernet 'emulated' link, etc.).

BAsed on that experience I comment on the draft below.

> This document describes a known and implemented method of sharing a
> /64 IPv6 prefix from a User Equipment 3GPP radio interface to a
> tethered LAN.

This is a terminology discussion, but I have some issues digesting this
use of the word 'sharing'.  It is not blocking comments, and we could
pursue with it ok.

'Sharing' one personal 3G subscription with several other users is ok.
But 'sharing' a prefix across two links - especially if it's a /64 - is
very hard to understand.

Or we could find something else instead of 64sharing.  Sounds to me more
like
'extending the use of a /64 beyond the link initially allocated' or
'making a Host into a Router when only one /64 prefix  is valid on only
  one of its interfaces which is a Ethernet-compatible' or
'Point-to-Point IPv6 extended with a shared Ethernet'
  or something else.

The problems I have are about this '64' which sounds like '6 to 4', as
if we used the IPv4 cell connection to form an IPv6 prefix for WLAN.
And with the 'sharing', because the prefix is not shared at all - it is
_moved_ from one interface to the other.

I am using a lot the term 'shared link' (between Hosts on a link) and
and they are not as in the way described in this draft.

I also have problems with the word 'tethering' because in many cases
there's actually no tether - it's without wires (exception USB cable or
Ethernet cable).  With the vehicle case, the PC Mobile Router has most
likely wireless interfaces.

> this document describes how the 3GPP UE interface assigned /64 subnet
> may be shared from the 3GPP interface to a tethered LAN.

That /64 is maybe little 'assigned' - I think it is rather 'announced'
on that ptp link.

The 3GPP uses indeed the term 'assign a /64 to a UE' but I dont like it.

> This is achieved by specifying the UE 3GPP interface as an IPv6 /128
> subnet taken from the 3GPP interface's network assigned /64 subnet.

This has formulation and content problems, to my reading.  I will follow
it whether it evolves.

> Then, assign the same address to the tethered LAN interface with the
> full /64 subnet.

This has formulation problems.  How about:
"Then, assign that address to the ingress interface, and set its prefix
  length on that interface as 64".

'tethered LAN' has problems because often it's WLAN and W means no
tether.  Reading 'tethered LAN' makes think that this does not work on
WLAN or WPAN.

> The /64 tethered LAN subnet will then be advertised to the tethered
> LAN via Router Advertisements (RA) [RFC4861].

"The prefix and the prefix length received in the PIO in the RA on the
  cellular interface are copied in the PIO in the RA sent on the ingress
  interface".  This is a non-typical operation (not seen elsewhere,
  other than maybe Router Renumbering) and yes deserves mentioning.

> The end result is that all UE interfaces have link-local IPv6
> addresses, the UE's 3GPP interface has a /128 address from the 3GPP
> network assigned /64, and the same address that is assigned to the
> 3GPP interface is assigned to the tethered LAN interface with a /64
> subnet and advertised to the LAN via RA.

This is too long, and a bit illogic, and a bit for discussion.

Each UE interface does indeed have a ll address, but this is due to
architecture spec, not an end result of this spec.

'UE 3GPP iface has a /128 address' - any other address is a /128,
suffices it to say 'an address'.

It is not necessary for the UE to keep that global address (derived from
the IID of the interface, together with the PIO in the received RA).  It
can remove it altogether from the egress interface.

Besides, when it becomes a Router, the UE will no longer self-configure
an address based on the RA (and its IID) - it will just log the
reception of that RA.

> This approach only impacts the UE configuration and does not require
>  any changes to the 3GPP network.

Yes, I agree, and deserves being mentioned.  This is an important aspect
which may lead to widespread deployment.  I'd even stress that it does
not need any changes to the 3GPP network nor to any other entity in the
3GPP network or elsewhere in the Internet.

> Neighbor Discovery Proxy (ND Proxy) [RFC4389] functionality has been
> suggested as an option for sharing the assigned /64 from the 3GPP
> interface to the LAN, but ND Proxy is an experimental protocol and
> has some limitations with loop-avoidance.

... and issues with security - proxying for somebody without that
somebody agreeing to be represented may be seen as a leap of faith.

> As [RFC6459] describes, the 3GPP network assigned /64 is completely
> dedicated to the UE and the gateway does not consume any of the /64
> addresses.  The gateway routes the entire /64 to the UE

Yes.  The method described in this document works because the gateway
does not issue a NS for an IP address prefixed by the announced prefix
on that link.  The gateway considers (1) the route to be all towards a
device, instead of towards a next-hop IP address (the route is expressed
as a triplet "prefix-0-device" instead of "prefix-nexthop-device"), and
(2) the link of the device to be point-to-point, with maximum two
addresses on that link, and each address with link-local scope and (3)
when the gateway needs  to deliver a packet whose destination address
matches that prefix in its routing table, it will not issue a NS to
obtain the MAC address of the destination address.

> and does not perform ND or Network Unreachability Detection (NUD)
> [RFC4861].

Yes, too.

> Communication between the UE and the gateway is only done using link-
> local addresses and the link is point-to-point.

Well I am not sure about the first part.

I haven't seen much communication exclusively between the UE and the
gateway (other than maybe the RAs).

And, even if one removes the global address from the 3GPP interface (and
assigns it on the ingress interface) it is still  possible for the
gateway to communicate to the UE by using their respective global address.

However, some things which are more sure are: (1) the RA is sent to the
a link-scoped multicast address, and with a link-local src address (2)
the nexthop field of the default route entry in UE's routing table is a
link-local address, etc.

> This allows for the UE to use the 3GPP network assigned /64 to
> assign itself a /128 address to the 3GPP radio interface for
> consistent network connection formation and the same address with a
> /64 to the tethered LAN interface.

Again this is too long.

I can understand it, but it could be shortened and I could propose if
needed.

> The tethered LAN interface may then advertise the /64 to the LAN with
> RA.  The LAN interface RA configuration must be tightly coupled with
> the 3GPP interface state. If the 3GPP interface goes down or changes
> address, that state should be reflected in the LAN IPv6
> configuration.

YEs.

> Just as in a standard IPv6 router, the packet TTL will be
> decremented when passing packets between interfaces.

Yes, and just as in a standard IPv6 Router, the UE will no longer form
an IPv6 address at the reception of the RA on its egress interface (not
as when it did when it was a Host).

> The procedure may also be described in terms of the following usage
> example:

Yes, I read it and it works.

Alternatively, one could describe a method with deletion of the Address
from the egress interface.

Alex
PS:
> 4.  The UE copies the address 2001:db8:ac10:f002:1234:4567:0:9 with
> a 64 bit mask from the 3GPP interfaces to the wireless LAN interfaces
>  and begins announcing the prefix 2001:db8:ac10:f002::/64 via RA to
> the wireless LAN.

(this is an example where it's written 'wireless LAN interfaces' and
which means precisely the same that was referred to earlier as 'tethered
LAN' - yet tether is not wireless).

> 6.  The UE directly processes all packets destine to itself at
> 2001:db8:ac10:f002:1234:4567:0:9.

'destined'.  And last 0 could be omitted or made an 8 instead.

>
> The UE should be compliant with the relevant requirements in [I-
> D.draft-binet-v6ops-cellular-host-requirement].

In particular, it should not run QMI and not present the ptp link to the
IP stack as a Ethernet link with MAC addresses.  Otherwise the method in
this document will fail.

> 4. Security Considerations

There is security problem if the operator of that 3GPP link does not
want to allow several Hosts behind a single one.  This problem is bigger
when the link is LTE because the larger bandwidth (and lower latencies)
compared to 3G will lead to more opportunities to share one LTE
connection with more users.

Alex

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 24 Jan 2013 10:11:46 -0800

Alex,

Thanks for the detailed review.

I am considering adding 2 more scenarios in addition to the one
already described

1) The UE only has LLA, and just relays the 3GPP RA announced /64 to
the LAN.  In this case, the UE is effectively off-line while tethering
since it does not have a global address, it is just doing a router
function.

2) The same as above, but the UE assigns itself an address on the LAN.
 This avoids the multiple interface address issue.

3) Maintain the existing method which allows for long lived
connections and is the running Android code that we have.

If those 3 methods are defined, the solution becomes more general, so
i would like feedback from the group on if the document should move to
BCP , become more general, and remove all 3GPP related language.

The BCP would say 1) Do DHCPv6-PD 2) when DHCPv6-PD is not available
for whatever reason, these 3 method can support extending a /64 subnet
from a WAN to a LAN.

In Atlanta, there was discussion about the need for a more general solution.

CB

On Thu, Jan 24, 2013 at 9:38 AM, Alexandru Petrescu
<[email-masked]> wrote:
> [email-masked]

---

From: Mark Smith <[email-masked]>
Date: Thu, 24 Jan 2013 11:25:17 -0800 (PST)

Hi,

----- Original Message -----
> From: Alexandru Petrescu <[email-masked]>
> To: [email-masked]
> Cc: 
> Sent: Thursday, 24 January 2013 9:39 PM

RFC6296 is experimental, I think it would be better to avoid it.

Generally I think there is nothing wrong the the model being pursued, I think the only issue is making sure it complies with the existing IPv6 addressing model and related expectations, such as API ones.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 25 Jan 2013 11:36:59 +0100

Le 24/01/2013 20:25, Mark Smith a écrit :
>> From: Alexandru Petrescu <[email-masked]> To:
>> [email-masked] Cc: Sent: Thursday, 24 January 2013 9:39 PM
>> Right; is this ipv6 MASQUERADE implementing the RFC 6296
>> "IPv6-to-IPv6 Network Prefix Translation"?
>>
>
> Generally I think there is nothing wrong the the model being
> pursued, I think the only issue is making sure it complies with the
> existing IPv6 addressing model and related expectations, such as API
> ones.

I am not sure which API expectations are considered.

If API is BSD Socket, then I think there are some relationships with the
ways the application on the UE uses the Address in question.

The following sequence works:
- assign IP address on egress interface
- application stops
- assign Address on ingress interface
- delete Address from egress interface
- application start

Other sequences may work and yet others may not work.

A sequence which may break the application is:
- assign Address on egress interface
- application start
- delete Address from egress interface
(application may break, packets may get lost)
- add Address on the ingress interface
(application may restart by itself or may need manual restart)

Not sure whether this is the kind of API expectation which are considered.

Yours,

Alex

>> 64share solve.  I.e. if one wants to do tethering one could use
>> RFC6296 instead of 64share.
>>
>>> 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)
>>>
>>> CB
>>>
>>> _______________________________________________ v6ops mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>>>
>>
>>

---

From: <[email-masked]>
Date: Tue, 29 Jan 2013 16:25:07 +0100

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Cameron Byrne
Gesendet: Dienstag, 22. Januar 2013 21:34
An: Mark Smith
Cc: [email-masked]
Betreff: Re: [v6ops] draft-ietf-v6ops-64share

Cameron,

> 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.

> 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.

I personally also don't like the idea of having the same IP address in two places. I always look at this as the UE's own IPv6 address attached to an internal interface int0 inside the UE, and the UE building a "virtual brigde" connecting the wlan0, int0 and wwan0 interface together. In front of the wwan0 interface, there is a matching logic adapting Ethernet L2 towards the WWAN L2 the same way as it was done when connecting Frame Relay PPP connections into Ethernet interfaces (Juniper calls this "translational crossconnects"; I am sure other vendors have similar implementations as well). However, I don't have a good word for describing such a scenario.

Holger

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 29 Jan 2013 17:20:02 +0100

Le 29/01/2013 16:25, [email-masked] a écrit :
> -----Ursprüngliche Nachricht----- Von: [email-masked]
> [mailto:[email-masked]] Im Auftrag von Cameron Byrne
> Gesendet: Dienstag, 22. Januar 2013 21:34 An: Mark Smith Cc:
> [email-masked] Betreff: Re: [v6ops] draft-ietf-v6ops-64share
>
> Cameron,
>
>> business.  And in fact, i am only trying to document  running code
>> to avoid multiple divergent methods of achieving the same goal.
>
>> 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.
>
> I personally also don't like the idea of having the same IP address
> in two places. I always look at this as the UE's own IPv6 address
> attached to an internal interface int0 inside the UE, and the UE
> building a "virtual brigde" connecting the wlan0, int0 and wwan0
> interface together. In front of the wwan0 interface, there is a
> matching logic adapting Ethernet L2 towards the WWAN L2

The bridging of the virtual interface and the other two real interface-
I could visualize it, with a single address attributed to the virtual
interface.

However, I wonder what this bridging may mean to routing.  If all the
interfaces on this machine are 'bridged' (maybe brconfig, brctl) then is
there any IP routing possible on this machine.

I guess the two subnets - the one on wwan0 and the one on wlan0 - shoudl
stay separate scope.  One wouldn't want a NS sent by a Host in the WLAN
subnetwork be transmitted to the WWAN subnetwork.

> the same way as it was done when connecting Frame Relay PPP
> connections into Ethernet interfaces (Juniper calls this
> "translational crossconnects"; I am sure other vendors have similar
> implementations as well).

I guess the figure there would be similar, but I have never seen a Frame
Relay.

Alex

> However, I don't have a good word for describing such a scenario.
>
> Holger _______________________________________________ v6ops mailing

---

From: Vízdal Aleš <[email-masked]>
Date: Wed, 30 Jan 2013 11:50:11 +0100

> Sent: Tuesday, January 29, 2013 5:20 PM
> To: [email-masked]

I believe you're either bridging or routing, but not both at the same time.
 
> subnetwork be transmitted to the WWAN subnetwork.

I am supporting the same view, so keep both wwan and lan interfaces separate.

Cheers,
Ales