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

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 02 Apr 2013 16:47:22 +0200

Hello Ales,

Sorry for late reply.

YEs.  This is right.  The 3GPP specs there make think that the UE may
request several prefixes with DHCPv6 Prefix Delegation.  This is new to me.

What remains to be seen is how this UE uses these requested prefixes (in
addition to the use of the default /64 prefix).  I don't think I see
anything in the referred specs about how UE uses these prefixes.

This email to say that the 64share document is right how it is now
(assumes DHCPv6-PD in the future, and now just do this method).

Alex

Le 12/03/2013 04:50, Vízdal Aleš a écrit :
> 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
>
>> -----Original Message----- From: Alexandru Petrescu
>> [mailto:[email-masked]] Sent: Monday, March 11, 2013
>> 11:39 PM To: Vízdal Aleš Cc: joel jaeggli; [email-masked] Subject:
>> Re: [v6ops] Mic comments on link model in
>> draft-ietf-v6ops-64share-03
>>
>> Le 12/03/2013 00:55, Vízdal Aleš a écrit :
>>>>> The 3GPP Rel-10 has introduced DHCP-PD. What's the problem
>>>>> here?
>>>>
>>>> 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?
>>>
>>> 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
>>
>>>
>>>> Alex
>>>
>>> Ales
>>>
>>>
>>
>
>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 02 Apr 2013 16:53:56 +0200

Le 12/03/2013 21:26, Alexandru Petrescu a écrit :
> Le 12/03/2013 19:29, Dmitry Anipko a écrit :
[...]
>> 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.

After re-reading the discussion on v6ops I think I no longer need to
provide any new text to 64share document.  Thanks to all who discussed.

The detail about the conditions about where 64share is disadvantageous
are the following:
- it provides only one /64 prefix to the LAN, if the device receives
   only one address on the cellular link.
- some hacks on some USB dongles to which 64share is a competitor send
   NS and make 64share not work.  But that's not a problem because it's
   not the right way for these USB dongles to do.

In some past RFC I provided a counter-example corner case where a
particular protocol wouldn't work.  But that didnt serve anything in the
subsequent years (neither did it block nor did it help advance - it was
just useless.)

Alex

>
> 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.
>>
>> [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
>> 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
>>
>>>
>>> -----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 :
>>>> Hi,
>>>>
>>>> On Mon, Mar 11, 2013 at 09:32:15PM +0100, Alexandru Petrescu
>>>> wrote:
>>>>> Le 11/03/2013 19:58, Mikael Abrahamsson a écrit :
>>>>>> On Mon, 11 Mar 2013, Alexandru Petrescu wrote:
>>>>>>
>>>>>>> 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.
>>>>
>>>> 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
>>>
>>> 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).
>>>
>>>>> This is the future of 3GPP interfaces (as opposed to old ptp
>>>>> addressless links).
>>>>
>>>> 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'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.
>>>>
>>>> "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
>>>
>>>>
>>>> Gert Doering -- NetMaster
>>>>
>>>
>>>
>>> _______________________________________________ v6ops mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>>>
>>
>>
>>
>
>
> _______________________________________________ v6ops mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>
>

---

From: Vízdal Aleš <[email-masked]>
Date: Tue, 2 Apr 2013 17:26:37 +0200

Hi Alex,

> -----Original Message-----
> From: Alexandru Petrescu [mailto:[email-masked]]
> Sent: Tuesday, April 02, 2013 4:47 PM
> To: Vízdal Aleš
> Cc: joel jaeggli; [email-masked]
> Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03
> 
> Hello Ales,
> 
> Sorry for late reply.

No worries, watching the ietf lists is a full time job ... ;-)

> request several prefixes with DHCPv6 Prefix Delegation.  This is new to me.

Well, it may request several prefixes, but there is still a limitation that all prefixes 
assigned to an UE must be aggregatable, so it will most likely get only one prefix delegated.

> anything in the referred specs about how UE uses these prefixes.

It should use it to number its ip interfaces and it may delegate prefixes further down the LAN
in case it acts as the delegating router.

> (assumes DHCPv6-PD in the future, and now just do this method).

Cheers,
Ales

---

From: <[email-masked]>
Date: Thu, 4 Apr 2013 10:29:43 +0200

Hi all,

Prefix delegation should be used if the UE has more interfaces than just the 3GPP interfaces, and Internet access via the 3GPP interfaces should be shared to the other interfaces (e.g. WLAN, wired, Bluetooth) so that the devices connected to these interfaces can use the 3GPP uplink.

This is specified in RFC3769 (PE/Aggregating Device/Delegating Router=GGSN, CPE/Requesting Router=UE in Figure 1), and RFC3633. 

Holger

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Alexandru Petrescu
Gesendet: Dienstag, 2. April 2013 16:47
An: Vizdal, Ales
Cc: [email-masked]
Betreff: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03

Hello Ales,

Sorry for late reply.

YEs.  This is right.  The 3GPP specs there make think that the UE may request several prefixes with DHCPv6 Prefix Delegation.  This is new to me.

What remains to be seen is how this UE uses these requested prefixes (in addition to the use of the default /64 prefix).  I don't think I see anything in the referred specs about how UE uses these prefixes.

This email to say that the 64share document is right how it is now (assumes DHCPv6-PD in the future, and now just do this method).

Alex

Le 12/03/2013 04:50, Vízdal Aleš a écrit :
>>>>> The 3GPP Rel-10 has introduced DHCP-PD. What's the problem here?
>>>>
>>>> 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...
>>>>

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