Subject: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03

From: Cameron Byrne <[email-masked]>
Date: Mon, 11 Mar 2013 10:27:15 -0700

Dave,

Here is the quote of the current draft text.  Does this correctly
describe the link model that the gateway does not consume an address?
Would you suggest a change?

"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 and does not
   perform ND or Network Unreachability Detection (NUD) [RFC4861]."

http://tools.ietf.org/html/draft-ietf-v6ops-64share-03

Cameron

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 11 Mar 2013 18:39:17 +0100

In addition to this, (sorry for intervening, I should have said this to
the mic), there is a need to state that this works only when:

- this is a cellular link of kind point-to-point; it does not work when
that cellular link is of kind 'shared link', eg with a qmi client, and
Qualcomm chipset.

- the Gateway does _not_ send an NS for _any_ of the addresses within
the /64 prefix.

- the Gateway does not use a 'Connected' route towards that /64.

There may exist cellular links on which this 64share does not work.

(and I find it strange to talk purely implementation in this draft, but
when it comes to its inconvenients to refer to some 3GPP spec - it is
widely known that 3GPP specs are implemented in various incompatible
ways; the draft would better talk pure implementation everywhere).

Alex

Le 11/03/2013 18:27, Cameron Byrne a écrit :
> describe the link model that the gateway does not consume an
> address? Would you suggest a change?
>
> Cameron _______________________________________________ v6ops mailing
> list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>
>

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 11 Mar 2013 10:59:37 -0700

Alex,

> that cellular link is of kind 'shared link', eg with a qmi client, and

There is no other 3GPP link model. There is only p2p. What i believe
you are referencing is a link model that is a specific implementation
towards tethered devices, and not within the scope of any 3GPP
standard.   We only consider 3GPP link model as described in the draft
explicitly and via reference to rfc6459.  Our hope is that publishing
this draft will avoid new invention from every OEM.

> - the Gateway does _not_ send an NS for _any_ of the addresses within

This is also already covered in stating that is this standard 3GPP operation

> - the Gateway does not use a 'Connected' route towards that /64.

I am not sure what this one is, but i assume it is covered in the same
way as above.

> There may exist cellular links on which this 64share does not work.

We believe all case for standard 3GPP links are covered.

> ways; the draft would better talk pure implementation everywhere).

I have running code for scenario 3.

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 11 Mar 2013 19:39:40 +0100

Le 11/03/2013 18:59, Cameron Byrne a écrit :
>> In addition to this, (sorry for intervening, I should have said
>> this to the mic), there is a need to state that this works only
>> when:
>>
>> - this is a cellular link of kind point-to-point; it does not work
>>  when that cellular link is of kind 'shared link', eg with a qmi
>> client, and Qualcomm chipset.
>>
>
> standard.

Well.

The 3GPP links which use IEEE MAC addresses are 3GPP links or not?

> We only consider 3GPP link model as described in the draft explicitly
> and via reference to rfc6459.  Our hope is that publishing this draft
> will avoid new invention from every OEM.

Well.

IETF does not specify 3GPP links.  It's impossible to write an RFC which
does so.

Cellular links exist out there, and some of them behave as some 3GPP
specs expect, others dont.

What would one call a cellular link of a cellular operator which does
IPv6 and uses IEEE MAC addresses - are these 3GPP links?

>> - the Gateway does _not_ send an NS for _any_ of the addresses
>> within the /64 prefix.
>>
>

I doubt we have a common understanding of what is "3GPP operation".  I
doubt implementations of 3GPP links act as 3GPP specs expect them to.

> I am not sure what this one is, but i assume it is covered in the
> same way as above.

A 'connected' route is Cisco terminology to say that there is no
next-hop in the Gateway's  routing table entry (linux's '*') for that
prefix /64.

I doubt 3GPP specs talk 'connected' route; but routers do have two
different kind sof routes for a /64 - a 'connected' route, or a
non-connected route (_has_ a nexthop for that /64).

This is why I am surprised we refer here to 3GPP specs.
> We believe all case for standard 3GPP links are covered.

What is a standard 3GPP link?  I doubt we can say so authoritatively at
IETF.

Besides, if one asks 3GPP specs, they'll tell that 64share is not possible.

>> (and I find it strange to talk purely implementation in this draft,
>> but when it comes to its inconvenients to refer to some 3GPP spec -
>> it is widely known that 3GPP specs are implemented in various
>> incompatible ways; the draft would better talk pure implementation
>> everywhere).
>>
>

Yes, I agree with you.  I have tried the same thing on linux with an USB
key.

However, it seems I may have tried an additional running code which
breaks at 64share - when the link is 'shared' kind.  I do not care
whether that link is compliant with 3GPP specs.  It is a link on a
cellular operator, at a cellular frequency.

If one asks 3GPP specs, they'll tell that 64share is not possible.

Alex

>>> Here is the quote of the current draft text.  Does this
>>> correctly describe the link model that the gateway does not
>>> consume an address? Would you suggest a change?
>>>
>>> "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 and does not perform ND or Network Unreachability
>>> Detection (NUD) [RFC4861]."
>>>
>>> Cameron _______________________________________________ v6ops
>>> mailing list [email-masked]
>> _______________________________________________ v6ops mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>
>

---

From: Gert Doering <[email-masked]>
Date: Mon, 11 Mar 2013 19:42:22 +0100

Hi,

> The 3GPP links which use IEEE MAC addresses are 3GPP links or not?

As far as I have learned, they are not 3GPP links, but 3GPP modems that
pretend to be "an ethernet thingie".  That's fully outside the 3GPP realm
of things.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 11 Mar 2013 19:51:41 +0100

Le 11/03/2013 19:42, Gert Doering a écrit :
> As far as I have learned, they are not 3GPP links, but 3GPP modems
> that pretend to be "an ethernet thingie".  That's fully outside the
> 3GPP realm of things.

But maybe in the realm of IETF?

IETF already describes MAC addresses and IPv6 addresses.

We are already the knees deep into thingies.  The IPv6 stack (the one
which uses IPv6 addresses, ND, routes, interfaces - as 64share requires)
is faced to these thingies.

The easiest way to clarify here would be to invent a new term 'thingie'
and say when thingies are present 64share does not work.

Alex

>
> Gert Doering -- NetMaster
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 11 Mar 2013 19:55:20 +0100 (CET)

> non-connected route (_has_ a nexthop for that /64).

The SPGW/GGSN routes the entire /64 onto the GTP tunnel. The tunnel is 
similar to IPIP or GRE, there is no mac header inside the tunnel. Think of 
it as basically a PPP interface, where it's just fine to route an entire 
prefix onto the p2p link.

> If one asks 3GPP specs, they'll tell that 64share is not possible.

Where?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 11 Mar 2013 19:58:23 +0100 (CET)

> is faced to these thingies.

The USB dongle does this magic in order to emulate a MAC layer towards the 
OS. It doesn't need to do this, but that's one way of doing it. For 
Windows machines, emulating an ethernet interface with an existing driver 
and doing ND spoofing, injecting RA etc is just a way of interfacing with 
the OS.

> and say when thingies are present 64share does not work.

Let's put it this way, the "thingie" you're talking about terminates the 
GTP tunnel and then spoofs stuff so that it looks like an ethernet 
segment. I can imagine that 64share doesn't work in that scenario, yes.

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 11 Mar 2013 21:22:57 +0100

Le 11/03/2013 19:55, Mikael Abrahamsson a écrit :
> The SPGW/GGSN routes the entire /64 onto the GTP tunnel. The tunnel
> is similar to IPIP or GRE, there is no mac header inside the tunnel.
> Think of it as basically a PPP interface, where it's just fine to
> route an entire prefix onto the p2p link.

What the CoreNetwork doess does not prevent the UE to use MAC addresses
on these links.

There is a distinction:

CoreNetwork-IntermediateSystem-UserEquipment.

The Intermediate System and the User Equipment are in the same Computer.

This distinction is not agreed here.  Some say this is a thingie.

>> If one asks 3GPP specs, they'll tell that 64share is not possible.

I don't think there's a precise place, just a metter of interpretation.

The 3GPP specs say that the /64 is for an UE.

The UE is an User Equipment.  3GPP specs have no notion of a UR (User
Router or so).

The UE has one single interface - the 3GPP interface.

But 64share needs more than one interface to work, at least one being
non-3GPP (the WiFi).

That's why I think 3GPP specs think that 64share is impossible.

Additionnally, many operators of these 3GPP links will appreciate little
the use of 64share on devices which they dont control. (i.e. use 64share
on a laptop PC with linux, rather than on an operator-controlled
smartphone).

For these two reasons, I find strange for this document to refer to 3GPP
documents to explain that 64share must work.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 11 Mar 2013 21:32:15 +0100

Le 11/03/2013 19:58, Mikael Abrahamsson a écrit :
>> We are already the knees deep into thingies.  The IPv6 stack (the
>> one which uses IPv6 addresses, ND, routes, interfaces - as 64share
>>  requires) is faced to these thingies.
>
> The USB dongle does this magic in order to emulate a MAC layer
> towards the OS. It doesn't need to do this, but that's one way of
> doing it.

This is a kind effort from the USB key - it  helps a lot the IPv6
stack.  The stack sees the 3GPP interface just like any other Ethernet
interface.  The stack does not need to do wacky things like NO_ARP.

This is the future of 3GPP interfaces (as opposed to old ptp addressless
links).

It's not only me who thinks so.  Why would manufacturers of 3GPP USB
keys go through the effort to ask IEEE for Organization IDs, if it were
not for a belief in a technical advantage of using MAC addresses on 3GPP
links.

> For Windows machines, emulating an ethernet interface with an
> existing driver and doing ND spoofing, injecting RA etc is just a way
> of interfacing with the OS.

I think that is good for Windows as well.

This emulation is what the intermediate layers do to help stacks
(witness other intermediate layers like in 6lowpan, header compression,
802.16/WiMax) - they are all new developments and go the way of offering
an Ethernet-like interface to the IPv6 stack.

>> The easiest way to clarify here would be to invent a new term
>> 'thingie' and say when thingies are present 64share does not work.
>
> Let's put it this way, the "thingie" you're talking about terminates
>  the GTP tunnel and then spoofs stuff so that it looks like an
> ethernet segment. I can imagine that 64share doesn't work in that
> scenario, yes.

Well yes, and thus the good 64share is not working with the good
64thingie.  Each taken independently is a good thing, but both at the
same time is not working.  This should be ack'ed.

Maybe one should specify the thingie to be such that it works ok with
64share... (i.e. don't send an NS for any arbitrary address within the
allocated /64). (but only if one is sure that it is the thingie who
sends it, not the Gateway).

Alex

---

From: joel jaeggli <[email-masked]>
Date: Mon, 11 Mar 2013 16:33:44 -0400

> on a laptop PC with linux, rather than on an operator-controlled
The policy question seems unrelated to the technical mechanism used for 
tethering.

Doesn't really seem any different than in IPv4 except I don't need DPI 
to observe it.

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 11 Mar 2013 21:47:05 +0100

Le 11/03/2013 21:33, joel jaeggli a écrit :
>> Additionnally, many operators of these 3GPP links will appreciate
>> little the use of 64share on devices which they dont control.
>> (i.e. use 64share on a laptop PC with linux, rather than on an
>> operator-controlled smartphone).
>>
> The policy question seems unrelated to the technical mechanism used
> for tethering.

If it were not, then DHCPv6-PD for Mobile Routers would be correctly
specified at 3GPP, and it would be at least in test deployment phases.

(AFAIK, DHCPv6-PD is specified in 3GPP but for purposes which cant make
'tethering' - to me that's on purpose, policy).

> Doesn't really seem any different than in IPv4 except I don't need
> DPI to observe it.

In IPv4 there is a unique NAT mechanism, whereas here a number of
options are on the table: NPT, 64share, DHCPv6-PD.  None of these is in
the 3GPP specs AFAIK.  I wonder why if it were not for policy...

That said, I also agree that one may leave policy aside and implement
whatever one likes to - which is especially true when inter-operability
may not be at stake - which is the case here: we only talk this
smartphone, which does not need to be interoperable with  anything,
because we assume 3GPP specs forbid the impossible thingie cases...
which make 64share bound to 3GPP...

Alex

>> For these two reasons, I find strange for this document to refer
>> to 3GPP documents to explain that 64share must work.
>>
>> Alex
>>
>>
>>
>>>
>>
>>

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 11 Mar 2013 13:52:53 -0700

> This is the future of 3GPP interfaces (as opposed to old ptp addressless

can you cite this from a 3GPP document ? Or is this your own idea?

I believe what you are seeing is (3gpp network)---standard 3gpp p2p
link ---- (USB stick (proprietary trickery) )---LAN---

IMHO, your observations about the USB stick are not relevant to the
3GPP network or the related standards.

> not for a belief in a technical advantage of using MAC addresses on 3GPP

At the end of the day, i think these efforts are happening in a
proprietary way because they needed to fill a space on ipv6 tethering
is to work.

draft-ietf-v6ops-64share-03 exists to fill this space with an open
approach that is known to work.  The idea being that folks can cite
this approach instead of everyone building their own.

All that said, the draft-ietf-v6ops-64share-03 scopes the solution
with specific text about p2p links and direct pointers to the known
3GPP model.

Do you have an issue with this text as written with the current scope?
If so, do you have a text suggestion?  I would like to avoid
broadening the scope from what the current text has set, because it
believe that would be an impossible problem to solve.

CB

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 11 Mar 2013 22:20:36 +0100

Le 11/03/2013 21:52, Cameron Byrne a écrit :
>>>> We are already the knees deep into thingies.  The IPv6 stack
>>>> (the one which uses IPv6 addresses, ND, routes, interfaces - as
>>>> 64share requires) is faced to these thingies.
>>>
>>>
>>> towards the OS. It doesn't need to do this, but that's one way
>>> of doing it.
>>
>>
>> stack.  The stack sees the 3GPP interface just like any other
>> Ethernet interface.  The stack does not need to do wacky things
>> like NO_ARP.
>>
>> This is the future of 3GPP interfaces (as opposed to old ptp
>> addressless links).
>>
>

It is my own speculation, after seeing the developments of IEEE 802.16
and IETF 6lowpan.  These developments of intermediate layers were
beneficial to IP stacks, at a time when 3GPP  was the only cellular and
Bluetooth was mainly ppp/ptp.

> link ---- (USB stick (proprietary trickery) )---LAN---

Yes and no.  I see:
(3gpp network)---standard 3gpp p2p link ---- (USB stick (proprietary
trickery) )---(Computer-Running-IP-stack)----(WiFi stick)-----LAN---

> 3GPP network or the related standards.

But they are relevant to IPv6 stack, arent they?  This is what the IPv6
stack on the Computer sees - the 'thingie'.  The thingie is not
specified by anybody, it's Proprietary, it brings some benefits when
64share is not there, but may break 64share.

>> It's not only me who thinks so.  Why would manufacturers of 3GPP
>> USB keys go through the effort to ask IEEE for Organization IDs, if
>> it were not for a belief in a technical advantage of using MAC
>> addresses on 3GPP links.
>>
>
> proprietary way because they needed to fill a space on ipv6
> tethering is to work.

But IPv6 tethering works _only_ if these proprietary means dont get in
the way.

> this approach instead of everyone building their own.

64share and proprietary IP proxies on USB keys are not competing in
their goals.

One cant suggest a USB key manufacturer to implement 64share rather than
the ND-proxying.  The ND-proxying (if that's what it does) helps other
goals (e.g. allow the stack to use its ND multicast unmodified, others).
  The 64share is not helping at all to run ND multicast on 3GPP links.

> with specific text about p2p links and direct pointers to the known

Cameron - the draft is a pure experimentation effort, which is very
good.  It should be as experimental about 3GPP specs as well, not just
citing them.

This draft and no 3GPP specs and no discussion on this email list
describe what do IEEE-legitimate MAC addresses are doing on these 3GPP
links.  They are there, are used, but are not reported.  Rather we
redirect to 3GPP specs...

> Do you have an issue with this text as written with the current
> scope? If so, do you have a text suggestion?  I would like to avoid

Right, no, not my intention to say this is an impossible problem to
solve, nor to broaden the scope (I have no solution for this).

As I suggested at the beginning of the discussion, the draft should ack
that there are cases (like when the UE receives a NS for an IPv6 address
within the allocated /64, when MAC addresses may be used on 3GPP links,
and when QMI may be used, and when the route at the Gateway be
"Connected") where 64share is not working.  Just ack it, that's all.

As for suggesting text - yes I could suggest text, here on the list -
would you like me to?

Alex

>>> existing driver and doing ND spoofing, injecting RA etc is just a
>>> way of interfacing with the OS.
>>
>>
>> (witness other intermediate layers like in 6lowpan, header
>> compression, 802.16/WiMax) - they are all new developments and go
>> the way of offering an Ethernet-like interface to the IPv6 stack.
>>
>>
>>> Let's put it this way, the "thingie" you're talking about
>>> terminates the GTP tunnel and then spoofs stuff so that it looks
>>>  like an ethernet segment. I can imagine that 64share doesn't
>>> work in that scenario, yes.
>>
>>
>> 64thingie.  Each taken independently is a good thing, but both at
>> the same time is not working.  This should be ack'ed.
>>
>> Maybe one should specify the thingie to be such that it works ok
>> with 64share... (i.e. don't send an NS for any arbitrary address
>> within the allocated /64). (but only if one is sure that it is the
>>  thingie who sends it, not the Gateway).
>>
>> Alex
>>
>>

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 11 Mar 2013 14:36:13 -0700

> 64share is not there, but may break 64share.

My idea is that 64share and "thingie" are mutually exclusive.

> As for suggesting text - yes I could suggest text, here on the list -

Yes.  I would be especially in favor or text that tunes the 64share
scope to be mutually exclusive to ( QMI | Thingie | Proprietary
Trickery).  I think the current scope makes this clear already in that
we clearly describe a p2p link with a /64 that is dedicated tot he UE
only.... but i acknowledge that QMI and related thingies are out
there, and if we can more clearly state that they are out of scope,
that would be great.

CB

---

From: Gert Doering <[email-masked]>
Date: Mon, 11 Mar 2013 22:53:27 +0100

Hi,

> interface.  The stack does not need to do wacky things like NO_ARP.

I'm not sure why you think that this is helpful or kind - it just 
complicates things, while PPP interfaces have been around and well-
understood for over 20 years - no need for a MAC layer, extra overhead,
"smart" firmware breaking stuff (like "packets coming from the wrong
link-layer address" as necessary consequence of EUI-64 not giving
the computer the link-local address that the network is expecting, etc.)

> This is the future of 3GPP interfaces (as opposed to old ptp addressless

I hope not.  It's a kludge.

> not for a belief in a technical advantage of using MAC addresses on 3GPP

"It makes windows drivers easier".  Yay.

Gert Doering
        -- NetMaster

---

From: Vízdal Aleš <[email-masked]>
Date: Mon, 11 Mar 2013 23:15:54 +0100

Alex,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Alexandru Petrescu
> Sent: Monday, March 11, 2013 2:40 PM
> To: Cameron Byrne
> Cc: [email-masked]
> Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03
> 

The 3GPP can hardly be using an IEEE MAC as there is no link-layer, you may
be talking about the PC facing interface such as USB.

> IPv6 and uses IEEE MAC addresses - are these 3GPP links?

As written above, are you talking about the 3GPP or USB (or any other) interface?

> doubt implementations of 3GPP links act as 3GPP specs expect them to.

Well, if someone violates the standard he/she should not surprised if things go wrong.

> non-connected route (_has_ a nexthop for that /64).

I believe that the packet core nodes have no next-hops as they're sending all
the matching traffic to the GTP tunnel.

> What is a standard 3GPP link?  I doubt we can say so authoritatively at

The respective 2G/3G or LTE 3GPP TS.

> Besides, if one asks 3GPP specs, they'll tell that 64share is not possible.

The 3GPP specs to me are more concerned about the architecture. The 3GPP spec
can be potentially referring to this draft/rfc.

---

From: Vízdal Aleš <[email-masked]>
Date: Mon, 11 Mar 2013 23:22:50 +0100

Alex,

> Sent: Monday, March 11, 2013 4:47 PM
> To: joel jaeggli
> Cc: [email-masked]

The 3GPP Rel-10 has introduced DHCP-PD. What's the problem here?
 
> which make 64share bound to 3GPP...

Ales

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 11 Mar 2013 23:58:58 +0100

Le 11/03/2013 22:53, Gert Doering a écrit :
> understood for over 20 years

PPP on cellular 3GPP links have failed to evolve for some strange
reason. (many other links have moved away from this ppp nature).

When a new kind of link shows up it first gets seen by IPv6 stack as a
serial, or as a ptp link.  Then it slowly evolves to IEEE, MAC
addressable, multicast capable links.  Now 3GPP links try the same...

> - no need for a MAC layer, extra overhead, "smart" firmware breaking
>  stuff (like "packets coming from the wrong link-layer address" as
> necessary consequence of EUI-64 not giving the computer the
> link-local address that the network is expecting, etc.)

Strange, the absence of a proper MAC layer is what allows 64share to work...

(no doubt DHCPv6 is not deployed on these MAC-less links, because
DHCPv6, like IPv6 ND, rely a lot on having a good MAC layer).

> I hope not.  It's a kludge.

It may be implemented as what looks like kludgy patch, but it may
improve in the future.  We should let space for that.

It may turn in circles, but the first thing this 64share draft says is
that DHCPv6-PD is the right thing to do.  And DHCPv6-PD is working
better on links which have MAC layers (e.g. during the mulitcast SErver
discovery phase one better has a multicast feature built-in).  Were the
3GPP links to have right MAC layers (non kludgy) then maybe DHCPv6-PD
were used instead of 64share.

> "It makes windows drivers easier".  Yay.

Recent linux kernel efforst try to work in the same way as windows ndis
drivers do with recent USB LTE keys.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 12 Mar 2013 00:21:43 +0100

Le 11/03/2013 23:15, Vízdal Aleš a écrit :
> Alex,
>
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
>> Sent: Monday, March 11, 2013 2:40 PM To: Cameron Byrne Cc:
>> [email-masked] Subject: Re: [v6ops] Mic comments on link model in
>> draft-ietf-v6ops-64share-03
>>
>>> There is no other 3GPP link model. There is only p2p. What i
>>> believe you are referencing is a link model that is a specific
>>> implementation towards tethered devices, and not within the
>>> scope of any 3GPP standard.
>>
>> Well.
>>
> The 3GPP can hardly be using an IEEE MAC as there is no link-layer,
> you may be talking about the PC facing interface such as USB.

Yes, I am talking about what the IPv6 stack on the PC sees: it sees
Ethernet-encapsulated IPv6 packets.  This IPv6 stack on the PC
supposedly implements 64share.

(64share would not be implemented on 3GPP USB keys).

>
>>> We only consider 3GPP link model as described in the draft
>>> explicitly and via reference to rfc6459.  Our hope is that
>>> publishing this draft will avoid new invention from every OEM.
>>
>> Well.
>>
>> IETF does not specify 3GPP links.  It's impossible to write an RFC
>> which does so.
>>
>> Cellular links exist out there, and some of them behave as some
>> 3GPP specs expect, others dont.
>>
>> What would one call a cellular link of a cellular operator which
>> does IPv6 and uses IEEE MAC addresses - are these 3GPP links?
>

I am talking about what the IPv6 stack on the PC sees.

I am not talking about the IPv6 'thingie' software which runs on the USB
key. (I doubt it has a full IPv6 stack).

Besides, I have no idea whether that NS is originated by the Gateway, or
by the USB key.  And nobody seems to know (other than speculating by
reading the 3GPP specs).

Were it to be generated by the USB key, then we could call it kludge,
fake proxying, bad thing.  But if it were originated by the Gateway then
we'd call it the right thing to do.

>> I doubt we have a common understanding of what is "3GPP
>> operation". I doubt implementations of 3GPP links act as 3GPP specs
>> expect them to.
>

Yes and no.

Standards shouldd follow implementations as well.

>> next-hop in the Gateway's  routing table entry (linux's '*') for
>> that prefix /64.
>>
> I believe that the packet core nodes have no next-hops as they're
> sending all the matching traffic to the GTP tunnel.

If it so, then it is a problem, because that link must be configured to
_not_ do ARP, not do ND, etc.

>> What is a standard 3GPP link?  I doubt we can say so
>> authoritatively at IETF.
>

No no...

3GPP standards cant stop people from implementing this kind of
MAC-addressable links... chipset manufacturers, kernel developpers, etc.

It's the other way around.  Standards should document implementations -
this is what 64share spec does too.

> The 3GPP specs to me are more concerned about the architecture. The
> 3GPP spec can be potentially referring to this draft/rfc.

Circular references?

3GPP refers to 64share which works _only_ if that other 3GPP spec works?

Alex

>>>> (and I find it strange to talk purely implementation in this
>>>> draft, but when it comes to its inconvenients to refer to some
>>>> 3GPP spec - it is widely known that 3GPP specs are implemented
>>>> in various incompatible ways; the draft would better talk pure
>>>> implementation everywhere).
>>>>
>>>
>> Yes, I agree with you.  I have tried the same thing on linux with
>> an USB key.
>>
>>>>> 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 and does not perform ND or Network
>>>>> Unreachability Detection (NUD) [RFC4861]."
>>>>>
>>>> _______________________________________________ v6ops mailing
>>>> list [email-masked]

---

From: Dmitry Anipko <[email-masked]>
Date: Mon, 11 Mar 2013 23:29:57 +0000

Alexandru,

>> Were the 3GPP links to have right MAC layers (non kludgy) then maybe DHCPv6-PD were used instead of 64share.

The actual point is that wherever DHCP-PD is available, it should be used instead of /64share. Not just where there is a "right" MAC layer. So there seems to be a violent agreement about the long term direction and that it will cover the wider scenarios.

/64share is not the long term direction - it is a short/mid-term fix. The draft says that, and in my opinion, it doesn't need changes in this respect, because it is intentionally scoped to be a short/mid-term fix for particular types of scenarios.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
Sent: Monday, March 11, 2013 3:59 PM
To: Gert Doering
Cc: [email-masked]
Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03

Le 11/03/2013 22:53, Gert Doering a écrit :
>> Ethernet interface.  The stack does not need to do wacky things like 
>> NO_ARP.
>

PPP on cellular 3GPP links have failed to evolve for some strange reason. (many other links have moved away from this ppp nature).

When a new kind of link shows up it first gets seen by IPv6 stack as a serial, or as a ptp link.  Then it slowly evolves to IEEE, MAC addressable, multicast capable links.  Now 3GPP links try the same...

> necessary consequence of EUI-64 not giving the computer the link-local 
> address that the network is expecting, etc.)

(no doubt DHCPv6 is not deployed on these MAC-less links, because DHCPv6, like IPv6 ND, rely a lot on having a good MAC layer).

> I hope not.  It's a kludge.

It may be implemented as what looks like kludgy patch, but it may improve in the future.  We should let space for that.

It may turn in circles, but the first thing this 64share draft says is that DHCPv6-PD is the right thing to do.  And DHCPv6-PD is working better on links which have MAC layers (e.g. during the mulitcast SErver discovery phase one better has a multicast feature built-in).  Were the 3GPP links to have right MAC layers (non kludgy) then maybe DHCPv6-PD were used instead of 64share.

>> keys go through the effort to ask IEEE for Organization IDs, if it 
>> were not for a belief in a technical advantage of using MAC addresses 
>> on 3GPP links.
>

Recent linux kernel efforst try to work in the same way as windows ndis drivers do with recent USB LTE keys.

Alex

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 12 Mar 2013 01:31:58 +0200

> IPv6 and uses IEEE MAC addresses - are these 3GPP links?

It has been repeated quite many times that the 3GPP link has no
link-layer addresses.

When you see one on your host, someone is playing tricks.

- Jouni

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 12 Mar 2013 00:51:28 +0100

Le 11/03/2013 23:22, Vízdal Aleš a écrit :
>> Sent: Monday, March 11, 2013 4:47 PM To: joel jaeggli Cc:
>>>> Additionnally, many operators of these 3GPP links will
>>>> appreciate little the use of 64share on devices which they dont
>>>> control. (i.e. use 64share on a laptop PC with linux, rather
>>>> than on an operator-controlled smartphone).
>>>>
>>> The policy question seems unrelated to the technical mechanism
>>> used for tethering.
>>
>> If it were not, then DHCPv6-PD for Mobile Routers would be
>> correctly specified at 3GPP, and it would be at least in test
>> deployment phases.
>>
>> (AFAIK, DHCPv6-PD is specified in 3GPP but for purposes which cant
>> make 'tethering' - to me that's on purpose, policy).
>

As far as I can remember, that is a PD for something in the core, the
delegated prefix is for the UE to use on its cellular (not for the UE to
use on its WLAN).

Were that 3GPP use of DHCPv6-PD to be for a prefix on the UEs WLAN then...

Or am I wrong about this?

Alex

>> options are on the table: NPT, 64share, DHCPv6-PD.  None of these
>> is in the 3GPP specs AFAIK.  I wonder why if it were not for
>> policy...
>>
>> That said, I also agree that one may leave policy aside and
>> implement whatever one likes to - which is especially true when
>> inter-operability may not be at stake - which is the case here: we
>> only talk this smartphone, which does not need to be interoperable
>> with  anything, because we assume 3GPP specs forbid the impossible
>> thingie cases... which make 64share bound to 3GPP...
>>
>> Alex
>
> Ales
>
>

---

From: Vízdal Aleš <[email-masked]>
Date: Tue, 12 Mar 2013 00:55:44 +0100

> Or am I wrong about this?

You seem to be wrong here as the PD is intended for an UE to delegate a prefix to a LAN.

Ales

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 12 Mar 2013 04:37:44 +0100

> When you see one on your host, someone is playing tricks.

And who's that?

3GPP cant stop him/her from doing so - it's on the market, and in the 
kernel.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 12 Mar 2013 04:38:59 +0100

> You seem to be wrong here as the PD is intended for an UE to delegate a prefix to a LAN.

Please point me to the 3GPP ref?

(last time I checked it was a prefix for the UE on its 3GPP link)

Alex

---

From: Vízdal Aleš <[email-masked]>
Date: Tue, 12 Mar 2013 04:50:19 +0100

Hi Alex,

let's start with TS 29.061 version 10.0.0, Section 11.2.1.3.5 IPv6 Prefix Delegation via DHCPv6
that includes further references. (http://www.3gpp.org/ftp/Specs/archive/29_series/29.061/29061-a00.zip)

Cheers,
Ales

> From: Alexandru Petrescu [mailto:[email-masked]]
> Sent: Monday, March 11, 2013 11:39 PM
> To: Vízdal Aleš
> Cc: joel jaeggli; [email-masked]

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 12 Mar 2013 05:21:54 +0100 (CET)

> supposedly implements 64share.

In some cases, yes. The sticks usually have two operating modes. Put the 
same usb stick in a linux machine and it'll see a ppp0.

> (64share would not be implemented on 3GPP USB keys).

On USB keys that presents a MAC layer to the OS that is.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 12 Mar 2013 05:24:34 +0100 (CET)

> (last time I checked it was a prefix for the UE on its 3GPP link)

Not for *prefix delegation*.

Otoh it's said that the 3GPP /64 should be part of of the larger PD 
prefix (for instance a /56).

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 12 Mar 2013 13:01:03 +0100

Le 12/03/2013 00:29, Dmitry Anipko a écrit :
> Alexandru,
>
>>> Were the 3GPP links to have right MAC layers (non kludgy) then
>>> maybe DHCPv6-PD were used instead of 64share.
>
> The actual point is that wherever DHCP-PD is available, it should be
> used instead of /64share. Not just where there is a "right" MAC
> layer. So there seems to be a violent agreement about the long term
> direction and that it will cover the wider scenarios.

YEs, the long term intention is right.  I agree in the long term one
should use DHCPv6-PD to get a prefix for the WLAN of the UE connected on
LTE.

The only minor comment here is that I think (just suppose), from my
recollection, that 3GPP specs need some clarification about this
DHCPv6-PD use.

> /64share is not the long term direction - it is a short/mid-term
> fix. The draft says that, and in my opinion, it doesn't need changes
> in this respect, because it is intentionally scoped to be a
> short/mid-term fix for particular types of scenarios.

Yes, right.  It does not need to stress it is a midterm solution.  It is
already said.

On another hand, for each one of the 3 scenarios, if 64share receives a
NS from the network about the IPv6 address within the /64 - it will break.

Alex

> Sent: Monday, March 11, 2013 3:59 PM To: Gert Doering Cc:
>>>>> (the one which uses IPv6 addresses, ND, routes, interfaces -
>>>>> as 64share requires) is faced to these thingies.
>>>>
>>>>  towards the OS. It doesn't need to do this, but that's one
>>>> way of doing it.
>>>
> When a new kind of link shows up it first gets seen by IPv6 stack as
> a serial, or as a ptp link.  Then it slowly evolves to IEEE, MAC
>> - no need for a MAC layer, extra overhead, "smart" firmware
>> breaking stuff (like "packets coming from the wrong link-layer
>> address" as necessary consequence of EUI-64 not giving the
>> computer the link-local address that the network is expecting,
>> etc.)
>
> It may turn in circles, but the first thing this 64share draft says
> is that DHCPv6-PD is the right thing to do.  And DHCPv6-PD is
> working better on links which have MAC layers (e.g. during the
> mulitcast SErver discovery phase one better has a multicast feature
> built-in). Were the 3GPP links to have right MAC layers (non kludgy)
> then maybe DHCPv6-PD were used instead of 64share.
>
>>> USB keys go through the effort to ask IEEE for Organization IDs,
>>> if it were not for a belief in a technical advantage of using MAC
>>> addresses on 3GPP links.
>>
> Recent linux kernel efforst try to work in the same way as windows
> ndis drivers do with recent USB LTE keys.
>
> Alex
>
>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 12 Mar 2013 13:02:03 +0100

Le 12/03/2013 00:55, Vízdal Aleš a écrit :
>> As far as I can remember, that is a PD for something in the core,
>> the delegated prefix is for the UE to use on its cellular (not for
>> the UE to use on its WLAN).
>>

Well... I may need to check that once again in the specs and I will come
back to the list abou tthis.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 12 Mar 2013 13:04:44 +0100

Le 12/03/2013 05:21, Mikael Abrahamsson a écrit :
> In some cases, yes. The sticks usually have two operating modes. Put
> the same usb stick in a linux machine and it'll see a ppp0.

Yes, and put it on a linux machine and run QMI (qmiclient) instead of
pppd and it'll see a wwan0 with MAC addresses just like a wlan0.

> On USB keys that presents a MAC layer to the OS that is.

Yes.

I think 64share is not intended to be implemented on any USB keys for
that matter (be them with or w/o MAC addresses).

Alex

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 12 Mar 2013 13:32:23 +0100 (CET)

> that matter (be them with or w/o MAC addresses).

Well, I wouldn't be so sure. There are products out there that take a USB 
dongle for WWAN connectivity. I would imagine they should be fine to 
implement 64share if they run the dongle in ppp mode.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 12 Mar 2013 14:23:20 +0100

Le 12/03/2013 13:32, Mikael Abrahamsson a écrit :
>> I think 64share is not intended to be implemented on any USB keys
>> for that matter (be them with or w/o MAC addresses).
>
> Well, I wouldn't be so sure. There are products out there that take a
>  USB dongle for WWAN connectivity. I would imagine they should be
> fine to implement 64share if they run the dongle in ppp mode.

Do you mean 64share script in the USBkey?  Or 64share script in the
computer on which the USB key is attached? (I think the latter only).

Alex

---

From: Vízdal Aleš <[email-masked]>
Date: Tue, 12 Mar 2013 14:30:22 +0100

> From: Mikael Abrahamsson [mailto:[email-masked]]
> Sent: Tuesday, March 12, 2013 12:25 AM
> To: Alexandru Petrescu
> Cc: Vízdal Aleš; [email-masked]

It's a must as the 3GPP architecture supports just one routing entry per subscriber,
so both the 3GPP link and delegated prefix must be aggregatable.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 12 Mar 2013 14:38:42 +0100 (CET)

> computer on which the USB key is attached? (I think the latter only).

Latter only.

---

From: Gert Doering <[email-masked]>
Date: Tue, 12 Mar 2013 15:41:53 +0100

Hi,

> DHCPv6, like IPv6 ND, rely a lot on having a good MAC layer).

Nothing wrong with DHCPv6 on PPP (or generic p2p) links.

> were used instead of 64share.

There is no need for any sort of "multicast" support on a ptp link,
as there is only one other party, which will see your packets when
you stuff it into the link.

Your ramblings have no substance - DHCPv6-PD is not supported because
the 3GPP network vendors have not implemented it, not because the link 
is of a "p2p-ish nature".  Non-3GPP BRAS vendors have offered DHCPv6
and DHCPv6-PD on "p2p" links (SDH/SONET, PPP, PPPoE, ...) for ages.

> drivers do with recent USB LTE keys.

But that's not because it's useful, it's because these dongles work that
way and Linux has to find a way to make it work there, too.

Don't mix cause and symptom.

Gert Doering
        -- NetMaster

---

From: Dan Drown <[email-masked]>
Date: Tue, 12 Mar 2013 11:11:52 -0500

> that matter (be them with or w/o MAC addresses).

The USB keys you are talking about (the ones that translate between  
ethernet and 3GPP) are doing some form of 64share on the USB key  
itself.  It has a point to point upstream and an ethernet downstream.   
The USB key firmware takes the /64 and assigns it to its end of the  
virtual ethernet interface.  It may have a global address and it may  
not.  It might properly do neighbor discovery and handle being (layer  
2) bridged to other ethernet networks and it might ignore standards  
and only expect one device downstream.  That's all up to the USB key  
vendor's implementation.

So if by "implemented on" USB keys you mean in the USB key's firmware,  
that sounds like it's already covered.  If you mean sharing your USB  
key connection to other devices, that's all up to the USB key vendor  
following the standards for IPv6 over ethernet.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 12 Mar 2013 17:16:17 +0100

> Nothing wrong with DHCPv6 on PPP (or generic p2p) links.

Well yes, still...

I have not seen DHCPv6 running on the 3GPP link (3G+) that I use.  There
is no answer to DHCPv6 Solicits.

If MAC-less ptp links is not a reason for lack of DHCPv6 on 3GPP links,
then what's the technical reasons?

>> built-in).  Were the 3GPP links to have right MAC layers (non
>> kludgy) then maybe DHCPv6-PD were used instead of 64share.
>

Yes it works on ptp link.

> Your ramblings have no substance - DHCPv6-PD is not supported
> because the 3GPP network vendors have not implemented it,

There must be a technical reason for why vendors didnt implement it.

> not because the link is of a "p2p-ish nature".  Non-3GPP BRAS vendors
> have offered DHCPv6 and DHCPv6-PD on "p2p" links (SDH/SONET, PPP,
> PPPoE, ...) for ages.
>
>>>> It's not only me who thinks so.  Why would manufacturers of
>>>> 3GPP USB keys go through the effort to ask IEEE for
>>>> Organization IDs, if it were not for a belief in a technical
>>>> advantage of using MAC addresses on 3GPP links.
>>>
> But that's not because it's useful, it's because these dongles work
> that way and Linux has to find a way to make it work there, too.

No no, the dongles that I talk about work equally well as ppp or as
MAC-addressable device.  It's not that that dongle does not work with
ppp, it can as well (depends how one initialiwes it).

If presented with an option to choose between two interfaces, which one
would one prefer - a ptp no-ARP ppp interfaces?  Or a MAC-addressable
WiFi-like ND interface?  I prefer the latter - its features can be
advantageously used by ND, DHCPv6, MLD and other protocols.

Alex

---

From: Gert Doering <[email-masked]>
Date: Tue, 12 Mar 2013 17:34:13 +0100

Hi,

> then what's the technical reasons?

"Vendors not having it implemented on the other side" (or "operators not
having switched it on", but as far as I hear from Telco folks, the 
problem is more around "Vendors not implementing it").

If I turn off the DHCPv6 server off on my nifty MAC based ethernet link,
you won't get anything back for your solicits either.  Even if it has
all the ethernet framing you want.

[..]
> There must be a technical reason for why vendors didnt implement it.

"Priorization of scarce development manpower"?

"The customer that waves with the biggest wad of money gets their feature
first", and nobody complaining loudly enough about lack of DHCPv6-PD?

[..]
> advantageously used by ND, DHCPv6, MLD and other protocols.

I'd prefer a ptp interface any day, because that's much closer to 
the real link characteristics - the "I pretend to be an ethernet 
thingie" interface is actually *breaking* communication in certain 
cases.

There are 3G networks where the UE is assigned a fixed link-local
address (in the PDP setup), and if you do not send your NS/RS using 
*that* source address, the other end will just not answer.  With 
a PPP based link, telling the client it's link-local address is 
part of the protocol and works nicely, with an ethernet based link, 
it *can not be done*, so your thingie won't work properly in those 
networks.   (Communication using "any global address out of the /64"
actually worked fine, just link-local stuff using a different-than-
assigned address didn't)

Gert Doering
        -- NetMaster

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 12 Mar 2013 17:54:36 +0100 (CET)

> then what's the technical reasons?

The technical reason is that 3GPP didn't standardize DHCPv6 on that link. 
DHCPv6-PD is in Release 10, which isn't implemented by any vendors yet 
afaik.

> advantageously used by ND, DHCPv6, MLD and other protocols.

That's your personal preference. I don't understand why this is of any 
advantage.

---

From: Vízdal Aleš <[email-masked]>
Date: Tue, 12 Mar 2013 18:25:21 +0100

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Mikael
> Abrahamsson
> Sent: Tuesday, March 12, 2013 12:55 PM
> To: Alexandru Petrescu
> Cc: [email-masked]

Just a note: As specified in Rel-10 the UE shall use SLAAC to get it's 3GPP link address, 
the DHCP-PD feature is there only for a LAN prefix delegation. So there is no full DHCPv6 
support in the 3GPP specs.  

Ales

---

From: Vízdal Aleš <[email-masked]>
Date: Tue, 12 Mar 2013 18:31:29 +0100

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Gert
> Doering
> Sent: Tuesday, March 12, 2013 12:34 PM
> To: Alexandru Petrescu
> Cc: [email-masked]
 
> address (in the PDP setup), 

Those networks and UEs are following the spec that requires the gateway (GGSN/PGW)
to hint the UE the host part of the LLA. Given that the gateway must not use any
address from the /64 GUA available to the UE it removes the need for DAD.

Ales

---

From: Dmitry Anipko <[email-masked]>
Date: Tue, 12 Mar 2013 18:29:38 +0000

Thanks Alexandru.

>> The only minor comment here is that I think (just suppose), from my recollection, that 3GPP specs need some clarification about this DHCPv6-PD use.

If 3gpp specs need such clarification, it doesn't seem to be in scope for draft-ietf-v6ops-64share?

>> On another hand, for each one of the 3 scenarios, if 64share receives a NS from the network about the IPv6 address within the /64 - it will break.

The draft currently says " The gateway routes the entire /64 to the UE and does not perform ND or Network Unreachability Detection (NUD) [RFC4861].". If you think this is not sufficient, do you want to suggest the particular text you'd like to see?

Thank you.

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: Tuesday, March 12, 2013 5:01 AM
To: Dmitry Anipko
Cc: Gert Doering; [email-masked]
Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03

Le 12/03/2013 00:29, Dmitry Anipko a écrit :
> used instead of /64share. Not just where there is a "right" MAC layer. 
> So there seems to be a violent agreement about the long term direction 
> and that it will cover the wider scenarios.

YEs, the long term intention is right.  I agree in the long term one should use DHCPv6-PD to get a prefix for the WLAN of the UE connected on LTE.

The only minor comment here is that I think (just suppose), from my recollection, that 3GPP specs need some clarification about this DHCPv6-PD use.

> /64share is not the long term direction - it is a short/mid-term fix. 
> The draft says that, and in my opinion, it doesn't need changes in 
> this respect, because it is intentionally scoped to be a 

Yes, right.  It does not need to stress it is a midterm solution.  It is already said.

On another hand, for each one of the 3 scenarios, if 64share receives a NS from the network about the IPv6 address within the /64 - it will break.

Alex

> better on links which have MAC layers (e.g. during the mulitcast 
> SErver discovery phase one better has a multicast feature built-in). 
>>> were not for a belief in a technical advantage of using MAC 
>>> addresses on 3GPP links.
>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 12 Mar 2013 21:03:39 +0100

Le 12/03/2013 17:11, Dan Drown a écrit :
> itself.

Hum?  This is a surprise to me.

This would mean that MAC-enabled USB LTE keys are already implementing a
method similar to 64share.

> It has a point to point upstream and an ethernet downstream. The USB
> key firmware takes the /64 and assigns it to its end of the virtual
> ethernet interface.  It may have a global address and it may not. It
> might properly do neighbor discovery and handle being (layer 2)
> bridged to other ethernet networks

I may agree with this description.

At some point I speculated that it is not the dongle which sends these
ND messages, but the Gateway.  I am told that's not possible because
3GPP specification; but I would need to see it in practice.

Until then I am still on a fence about this.

> and it might ignore standards and only expect one device downstream.
>  That's all up to the USB key vendor's implementation.

Remark, from the standpoint of these vendors, the 64share document is an
IETF ongoing developping document which does not respect their way of
doing '64share'.

And it means that we here contribute a 64share IETF document which
ignores the other running code.

This argument of who is compliant to what standard is misleading.  It
can be used both ways, it may fire back.  It's too easy!

I will try to restrain myself from further posting on this.  I will go
back to the invitation from Cameron to contribute text.

Alex

> So if by "implemented on" USB keys you mean in the USB key's
> firmware, that sounds like it's already covered.  If you mean sharing
> your USB key connection to other devices, that's all up to the USB
> key vendor following the standards for IPv6 over ethernet.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 12 Mar 2013 21:16:02 +0100

Le 12/03/2013 17:34, Gert Doering a écrit :
>>>> (no doubt DHCPv6 is not deployed on these MAC-less links,
>>>> because DHCPv6, like IPv6 ND, rely a lot on having a good MAC
>>>> layer).
>>>
>> I have not seen DHCPv6 running on the 3GPP link (3G+) that I use.
>> There is no answer to DHCPv6 Solicits.
>>
>> If MAC-less ptp links is not a reason for lack of DHCPv6 on 3GPP
>> links, then what's the technical reasons?
>
> "Vendors not having it implemented on the other side" (or "operators
> not having switched it on", but as far as I hear from Telco folks,
> the problem is more around "Vendors not implementing it").

Vendors must have a reason of not doing so.

> If I turn off the DHCPv6 server off on my nifty MAC based ethernet
> link, you won't get anything back for your solicits either.  Even if
> it has all the ethernet framing you want.

Right... but MLD would work ok, faster than if there were no MAC
addresses, which allows to start using ND reliably... which in turn
allows for this DNS discovery by MAC and so on.  DHCPv6 discovery phase
is but one.

On ptp ppp links we have none of these link-scoped protocols.  We dont
have ND, no MLD no DNS discovery on link, etc.  For all these features
we rely on non-IETF protocols, like for example the non-IETF way of
forming Interface Identifiers.

All these ptp ppp aspects are peculiarities which are specific only to
the cellular link of the Computer.  For all the other non-cellular
links, the stack on the Computer uses a homogeneous way to deal with
LAN, PAN, MAN whatsoever.

> "Priorization of scarce development manpower"?

Right...

> "The customer that waves with the biggest wad of money gets their
> feature first", and nobody complaining loudly enough about lack of
> DHCPv6-PD?

Right...

> [..]
>> If presented with an option to choose between two interfaces,
>> which one would one prefer - a ptp no-ARP ppp interfaces?  Or a
>> MAC-addressable WiFi-like ND interface?  I prefer the latter - its
>> features can be advantageously used by ND, DHCPv6, MLD and other
>> protocols.
>

Aha... sounds reasonable.

But pretend to be Ethernet thingie may one day become a real one, with
cellular shared links, where neighbors may talk directly to each other
without going through a fixed base station.

> *that* source address, the other end will just not answer.  With a
> PPP based link, telling the client it's link-local address is part
> of the protocol and works nicely, with an ethernet based link, it
> *can not be done*, so your thingie won't work properly in those

I read.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 12 Mar 2013 21:19:14 +0100

Le 12/03/2013 17:54, Mikael Abrahamsson a écrit :
> The technical reason is that 3GPP didn't standardize DHCPv6 on that
> link. DHCPv6-PD is in Release 10, which isn't implemented by any
> vendors yet afaik.
>
>> If presented with an option to choose between two interfaces, which
>>  one would one prefer - a ptp no-ARP ppp interfaces?  Or a
> That's your personal preference. I don't understand why this is of
> any advantage.

MAC-addressed links allows to use a single software implementation for
many IEEE links and these are very many, cellular is not IEEE and is but
one kind of link.

There are many protocols at IETF which could be used unmodified on
cellular links if they were MAC-addressable, and wouldt be used if
they're not MAC addressable - MLD, DNS discovery, SeND, you name it.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 12 Mar 2013 21:26:17 +0100

Le 12/03/2013 19:29, Dmitry Anipko a écrit :
> Thanks Alexandru.
>
>>> The only minor comment here is that I think (just suppose), from
>>> my recollection, that 3GPP specs need some clarification about
>>> this DHCPv6-PD use.
>

Right, no, it's not in the scope of 64share document to explain why
DHCPv6-PD is not correctly specified at 3GPP.

>>> On another hand, for each one of the 3 scenarios, if 64share
>>> receives a NS from the network about the IPv6 address within the
>>> /64 - it will break.
>
> The draft currently says " The gateway routes the entire /64 to the
> UE and does not perform ND or Network Unreachability Detection (NUD)
> [RFC4861].". If you think this is not sufficient, do you want to
> suggest the particular text you'd like to see?

Yes, I will, soon, thanks for asking.  I will send something soon.

Basically that text is incomplete.  It says it 'routes' but it doesnt
say how.  Or here we have a fundamental distinctions for the how; these
boil down to what does the routing table entry at the Gateway towards
the UE looks like: is there a nexthop, is there a device name, is the
dev a ptp or a MAC-adressed link, etc.  It's because of the particular
mixture of these parameters that 64share mechanism works.  Were it for
the Gateway to have a different mixture, 64share wouldnt work.

Also, the part which says that "the Gateway does not perform ND on that
link" is very strange, because RFCs require ND on all interfaces IIRC.
Also, this is a router and should not accept RAs.

Alex

>
> Thank you.
>
> -----Original Message----- From: Alexandru Petrescu
> [mailto:[email-masked]] Sent: Tuesday, March 12, 2013
> 5:01 AM To: Dmitry Anipko Cc: Gert Doering; [email-masked] Subject:
> Re: [v6ops] Mic comments on link model in
>> The actual point is that wherever DHCP-PD is available, it should
>> be used instead of /64share. Not just where there is a "right" MAC
>> layer. So there seems to be a violent agreement about the long
>> term direction and that it will cover the wider scenarios.
>
> should use DHCPv6-PD to get a prefix for the WLAN of the UE
> connected on LTE.
>
>> fix. The draft says that, and in my opinion, it doesn't need
>> changes in this respect, because it is intentionally scoped to be a
> On another hand, for each one of the 3 scenarios, if 64share
> receives a NS from the network about the IPv6 address within the /64
> - it will break.
>
> Alex
>
>>
>>>>>> We are already the knees deep into thingies.  The IPv6
>>>>>> stack (the one which uses IPv6 addresses, ND, routes,
>>>>>> interfaces - as 64share requires) is faced to these
>>>>>> thingies.
>>>>>
>>>>> The USB dongle does this magic in order to emulate a MAC
>>>>> layer towards the OS. It doesn't need to do this, but that's
>>>>> one way of doing it.
>>>>
>>>> This is a kind effort from the USB key - it  helps a lot the
>>>> IPv6 stack.  The stack sees the 3GPP interface just like any
>>>> other Ethernet interface.  The stack does not need to do wacky
>>>> things like NO_ARP.
>>>
>>> complicates things, while PPP interfaces have been around and
>>> well- understood for over 20 years
>>
>> When a new kind of link shows up it first gets seen by IPv6 stack
>> as a serial, or as a ptp link.  Then it slowly evolves to IEEE, MAC
>> It may turn in circles, but the first thing this 64share draft
>> says is that DHCPv6-PD is the right thing to do.  And DHCPv6-PD is
>> mulitcast SErver discovery phase one better has a multicast
>> feature built-in). Were the 3GPP links to have right MAC layers
>> (non kludgy) then maybe DHCPv6-PD were used instead of 64share.
>>

---

From: Owen DeLong <[email-masked]>
Date: Tue, 12 Mar 2013 14:20:24 -0700

> many IEEE links and these are very many, cellular is not IEEE and is but

Meh… There are lots of non-IEEE (or more accurately, non-Ethernet-like)
links in the world. Serial point to point (such as POS, DS-3, DS-1, etc.),
will persist and have existed for a very long time. PPP is well known and
well understood by virtually every operating system and is simple, clean,
and efficient. I see no reason to treat a point-to-point cellular link as other
than point-to-point and no advantage to coercing it to behaving as if it
was an ethernet just so you can use ethernet drivers and then need a bunch
of odd-ball software to cope with the aspects of the connection that are not
ethernet-like.

> they're not MAC addressable - MLD, DNS discovery, SeND, you name it.

There is no need whatsoever for MLD on a point to point link since multicast
makes no sense in such an environment. There are two hosts on the link.
If you are the sender, then the other one will receive whatever you send and
vice versa. What is the point of putting in a bunch of overhead to enable
multicast on such a link?

Not sure how you see DNS discovery playing out on such a link. I would
expect that to play out on the /64 and across the point to point link to 
a more distant DNS server where the actual context of the PPP link
should be relatively irrelevant as to whether it is ethernet-like or not.

SeND is a secure form of Neighbor Discovery. Again, I fail to see the
relevance of Neighbor Discovery on a point to point link.

As such, it seems that all of the technologies you are describing as being
usable on Point to Point links only if the point to point link pretends to be
an ethernet-like BMA or NBMA network are actually intended to overcome
the complexities imposed by BMA/NBMA networks. Since those complexities
don't exist in a point to point link, I fail to see any advantage to implementing
those complexities just so you can take advantage of the existing solutions
designed to overcome those complexities.

Perhaps I am missing or misunderstanding something in what you are
advocating, but unless that is the case, I think that it makes far more sense
to treat cellular connections as point to point connections between routers
(one router at the cellular provider and one in the {handset,usb fob, midi, etc.}
device.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Tue, 12 Mar 2013 14:24:34 -0700

> without going through a fixed base station.

Unlikely unless you expect the physics of radio to radically change in the near future.

A low power transmitter (as you find in the average cellular device) is unlikely to
be able to reliably reach all of the neighbors within the same cell without being
retransmitted by the cell itself. As such, treating cellular as point to point links makes
much MUCH more sense from a bandwidth conservation and protocol simplicity
perspective.

Owen

---

From: Vízdal Aleš <[email-masked]>
Date: Wed, 13 Mar 2013 14:24:33 +0100

> Sent: Tuesday, March 12, 2013 4:26 PM
> To: Dmitry Anipko
> Cc: [email-masked]

> the Gateway to have a different mixture, 64share wouldnt work.

It routes ... the packet core gateway (ggsn/p-gw) is the default router for the
UE and the TTL is being decremented by the gateway. On the gateway you
would probably see the /64 prefix linked to a PDP Context / PDN connection or
a GTP tunnel.
 
> Also, this is a router and should not accept RAs.

As there is no link-layer there is no need for ND to my understanding.

Ales

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 13 Mar 2013 14:29:40 +0100 (CET)

On Wed, 13 Mar 2013, Vízdal Aleš wrote:

> It routes ... the packet core gateway (ggsn/p-gw) is the default router 
> for the UE and the TTL is being decremented by the gateway. On the 
> gateway you would probably see the /64 prefix linked to a PDP Context / 
> PDN connection or a GTP tunnel.

Not all GGSN/PGW decrement TTL. When I traceroute from my UE to the 
Internet, my first hop seen in traceroute is the GUA address of the first 
router hop after the PGW:

UE<-GTP->SPGW<-IPv6->PE

So my traceroute hop 1 is the GUA address of the PE.

---

From: jouni korhonen <[email-masked]>
Date: Wed, 13 Mar 2013 18:28:09 +0200

>> It routes ... the packet core gateway (ggsn/p-gw) is the default router
for the UE and the TTL is being decremented by the gateway. On the gateway
you would probably see the /64 prefix linked to a PDP Context / PDN
connection or a GTP tunnel.
> So my traceroute hop 1 is the GUA address of the PE.

This is vendor implementation specific. Very popular but not really
defined in 3gpp specs except for some deprecated stuff.

- jouni

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 14 Mar 2013 04:27:51 +0100

Le 13/03/2013 17:28, jouni korhonen a écrit :
>
> 13.3.2013 9.29 "Mikael Abrahamsson" <[email-masked]
> <mailto:[email-masked]>> kirjoitti:
>>
>>> It routes ... the packet core gateway (ggsn/p-gw) is the default
>>>  router for the UE and the TTL is being decremented by the
>>> gateway.
>
> On the gateway you would probably see the /64 prefix linked to a PDP
> Context / PDN connection or a GTP tunnel.

Something like:

Prefix             Next-hop   Device
2001:db8:1:1::/64  ::         GTPtunnel0

or something like:

Prefix             Next-hop   Device
2001:db8:1:1::/64  fe80::5    GTPtunnel0

If the former, and that PDPContext/PDNconnectio-or-GTPtunnel is
MAC-addressable, then 64share wont work.

> Internet, my first hop seen in traceroute is the GUA address of the
> first router hop after the PGW:
>>
>> UE<-GTP->SPGW<-IPv6->PE
>>

Jouni - this is way too generic to be understandable.

(if we want to do any reverse engineering :-)

Alex

>
> - jouni
>
>>
>> -- Mikael Abrahamsson    email: [email-masked]
>> <mailto:[email-masked]>
>>
>> [email-masked] <mailto:[email-masked]>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 14 Mar 2013 04:32:59 +0100 (CET)

> MAC-addressable, then 64share wont work.

There is no MAC header in the GTP tunnel. It's "ip-in-ip" kind of 
encapsulation, similar to IP proto 41.

So anything causing there to be mac addressing is doing magic and perhaps 
the draft should mention this, but I don't see what else can be done.

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 13 Mar 2013 21:02:24 -0700

> MAC-addressable, then 64share wont work.

Mikael already answered this, but if i may, it does work.  There is
running code.  Feel free to test it / review it
http://dan.drown.org/android/clat/

CB

---

From: <[email-masked]>
Date: Mon, 25 Mar 2013 13:18:52 +0100

Alexandru,

the gateway only sees the link as the next-hop, as it is a P2P link:

Prefix             Next-hop   Device

Such a scenario

Prefix             Next-hop             Device
2001:db8:1:1::/64  00:aa:bb:cc:dd:ee    GTPtunnel0

would probably exist on the USB dongle interfacing the OS side Ethernet WWAN interface to the 3GPP P2P interface, but that's implementation specific. The same way as for IPv4, the USB dongle is absorbing/generating ARP requests towards the OS, and sometimes sets weird netmasks on the IPv4 addresses issued by DHCP towards the OS.

Holger

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Alexandru Petrescu
Gesendet: Donnerstag, 14. März 2013 04:28
An: [email-masked]
Betreff: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03

Le 13/03/2013 17:28, jouni korhonen a écrit :
>>> router for the UE and the TTL is being decremented by the gateway.
>

Something like:

Prefix             Next-hop   Device

or something like:

Prefix             Next-hop   Device

If the former, and that PDPContext/PDNconnectio-or-GTPtunnel is MAC-addressable, then 64share wont work.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 25 Mar 2013 13:38:08 +0100

> 2001:db8:1:1::/64  ::         GTPtunnel0

Thanks! This is good to know. For this case, the 64share method on the
Smartphone will work ok.

> 2001:db8:1:1::/64  00:aa:bb:cc:dd:ee    GTPtunnel0

I meant the Next-hop an IPv6 address, not a MAC address.

 From this on there are three other possibilities that could be reversely
engineered.

Depending on that, the 64share works or not.

> would probably exist on the USB dongle interfacing the OS side
> Ethernet WWAN interface to the 3GPP P2P interface, but that's
> implementation specific. The same way as for IPv4, the USB dongle is
> absorbing/generating ARP requests towards the OS, and sometimes sets
> weird netmasks on the IPv4 addresses issued by DHCP towards the OS.

I didnt know USB dongle would generate also ARP requests (in addition to
ND). This is good to know for a potential version IPv4 version of 64share.

Alex