Subject: [v6ops] Need ref to 3GPP spec for the use of DHCPv6 Prefix Delegation, e.g. for smartphone tethering

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 07 Oct 2013 10:18:57 +0200

Hello,

I need a reference to a 3GPP spec which requires or explains the use of
DHCPv6 Prefix Delegation for smartphone tethering (mobile hotspot).

This is because we write a problem statement draft in DHC WG ""Route
Problem at Relay during DHCPv6 Prefix Delegation".

I would like that draft to reflect the problem not only in the
homenet-kind of deployments (DSL, broadband forum) but also smartphone
deployments.

Thanks in advance,

Alex

(in that draft, we are refer to a BroadBand Forum document "Broadband
Forum, Technical Report, TR-177, "IPv6 in the Context of TR-101, Issue:
1, Issue date: November 2010", document freely available at the
URL http://www.broadbandforum.org/technical/download/TR-177.pdf accessed
on October 4th, 2013." which lists a number of problems and requirements
for Relay during PD.)

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 7 Oct 2013 10:33:35 +0200 (CEST)

> homenet-kind of deployments (DSL, broadband forum) but also smartphone

http://www.3gpp.org/ftp/Specs/html-info/23402.htm

If you download the 10.8.0 spec you will find:

"4.7.5	IPv6 Prefix Delegation using S2c
Optionally a single network prefix shorter than a /64 prefix may be 
assigned to a PDN connection (TS 23.401 [4]). When S2c is used to access a 
PDN, the UE acting as a Mobile Router may request delegation of one or 
more IPv6 prefix(es) via DHCPv6 Prefix Delegation signalling as described 
in RFC 6267 [56]. The UE does not need to explicitly register these 
additional prefixes using S2c signaling as implicit mode registration is 
used."

So this is not specific to smartphone tethering, but to any kind of mobile 
device that wants to act as a router.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 07 Oct 2013 13:43:35 +0200

Le 07/10/2013 10:33, Mikael Abrahamsson a écrit :
>> I need a reference to a 3GPP spec which requires or explains the
>> use of DHCPv6 Prefix Delegation for smartphone tethering (mobile
>> hotspot).
>>
>> This is because we write a problem statement draft in DHC WG
>> ""Route Problem at Relay during DHCPv6 Prefix Delegation".
>>
>> homenet-kind of deployments (DSL, broadband forum) but also
>> smartphone deployments.
>
> "4.7.5    IPv6 Prefix Delegation using S2c Optionally a single
> network prefix shorter than a /64 prefix may be assigned to a PDN
> connection (TS 23.401 [4]). When S2c is used to access a PDN, the UE
> acting as a Mobile Router may request delegation of one or more IPv6
> prefix(es) via DHCPv6 Prefix Delegation signalling as described in
> RFC 6267 [56]. The UE does not need to explicitly register these
> additional prefixes using S2c signaling as implicit mode registration
> is used."

Thanks for the reference.  This is the kind of use at 3GPP that I am
looking for.  I will use it right away.

(for info: there are some errors in the above text (I guess they mean
RFC 6276 bit 6267; second, I doubt Prefix Delegation with NEMO is needed
in this context - but rather simple PD without tunnels; RFC 6276 assumes
the Relay is on the mobile router, whereas the cellular deployment would
host the Relay in the fixed network).)

> So this is not specific to smartphone tethering, but to any kind of
> mobile device that wants to act as a router.

Yes, I agree, they call it 'UE acting as a Mobile Router'.

Alex

---

From: Vízdal Aleš <[email-masked]>
Date: Mon, 7 Oct 2013 14:19:51 +0200

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Alexandru Petrescu
> Sent: Monday, October 07, 2013 1:44 PM
> To: Mikael Abrahamsson
> Cc: [email-masked]
> Subject: Re: [v6ops] Need ref to 3GPP spec for the use of DHCPv6 Prefix Delegation,
> e.g. for smartphone tethering
> 
> >> I need a reference to a 3GPP spec which requires or explains the use
> >> of DHCPv6 Prefix Delegation for smartphone tethering (mobile
> >> hotspot).
> >>
> > prefix(es) via DHCPv6 Prefix Delegation signalling as described in RFC
> > 6267 [56]. The UE does not need to explicitly register these
> Thanks for the reference.  This is the kind of use at 3GPP that I am looking for.  I will
> use it right away.
> 
> (for info: there are some errors in the above text (I guess they mean RFC 6276 bit
> 6267; second, I doubt Prefix Delegation with NEMO is needed in this context - but
> rather simple PD without tunnels; RFC 6276 assumes the Relay is on the mobile router,
> whereas the cellular deployment would host the Relay in the fixed network).)

I guess that the right RFCs shall be 3633 & 6603.
 
> Yes, I agree, they call it 'UE acting as a Mobile Router'.

Ales

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 07 Oct 2013 15:58:18 +0200

Le 07/10/2013 14:19, Vízdal Aleš a écrit :
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
>> Sent: Monday, October 07, 2013 1:44 PM To: Mikael Abrahamsson Cc:
>> [email-masked] Subject: Re: [v6ops] Need ref to 3GPP spec for the
>> use of DHCPv6 Prefix Delegation, e.g. for smartphone tethering
>>
>>>> I need a reference to a 3GPP spec which requires or explains
>>>> the use of DHCPv6 Prefix Delegation for smartphone tethering
>>>> (mobile hotspot).
>>>>
>>> connection (TS 23.401 [4]). When S2c is used to access a PDN, the
>>> UE acting as a Mobile Router may request delegation of one or
>>> more IPv6 prefix(es) via DHCPv6 Prefix Delegation signalling as
>>> described in RFC 6267 [56]. The UE does not need to explicitly
>>> register these additional prefixes using S2c signaling as
>>> implicit mode registration is used."
>>
>> Thanks for the reference.  This is the kind of use at 3GPP that I
>> am looking for.  I will use it right away.
>>
>> (for info: there are some errors in the above text (I guess they
>> mean RFC 6276 bit 6267; second, I doubt Prefix Delegation with
>> NEMO is needed in this context - but rather simple PD without
>> tunnels; RFC 6276 assumes the Relay is on the mobile router,

I think yes, sure, that's better, that's the pure PD and the PD-exclude
RFCs.  Not sure about the necessity of PD-exclude in a 3GPP specific
scenario, but there may exist a reason for that -exclude.

Remark though that in that spec I couldnt find enunciating a problem of
routing at Relay, during the Prefix Delegation process.

It's strange, because the broadband forum _has_ identified such a problem.

Either there is no problem, in which case 3gpp would rather advise bf to
not worry  about it; or there is, and 3gpp would need to ack it.

Alex
PS: the BroadBand's problem at Relay during Prefix Delegation is
described in technical report titled "IPv6 in the context of TR-101",
dated November 2010 as:
> "hosts receiving IPv6 addresses from the RR are not known to the
> BNG, i.e. the BNG is not aware of what addresses/prefixes are
> assigned to hosts attached to the RG acting as RR."

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 7 Oct 2013 14:12:01 +0000

>>assigned to hosts attached to the RG acting as RR."

We may be getting off-topic here, but why is the above deemed as a
problem? It is a hierarchical distribution model after all.

-- 

Cheers,
Rajiv Asati
Distinguished Engineer, Cisco

-----Original Message-----
From: Alexandru Petrescu <[email-masked]>
Date: Monday, October 7, 2013 9:58 AM
To: Vízdal Aleš <[email-masked]>, Mikael Abrahamsson
<[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [v6ops] Need ref to 3GPP spec for the use of DHCPv6 Prefix
Delegation, e.g. for smartphone tethering

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 07 Oct 2013 16:31:30 +0200

> problem? It is a hierarchical distribution model after all.

Not trying to get off-topic.  This is a DHC discussion.

BAsically it all starts at section 14 "Relay Agent Behaviour" of RFC 
3633 DHCPv6-PD which says this:
>    If a delegating router communicates with a requesting router through
>    a relay agent, the delegating router may need a protocol or other
>    out-of-band communication to add routing information for delegated
>    prefixes into the provider edge router.

Absent that protocol or out of band communication, the routing 
information is not getting into that router.

(for bbf it's  BNG, for 3gpp it could be AR).

Even with a hierarchical distribution model, these allocated prefixes 
need to appear in the routing table of that AR only if the prefix is 
allocated, and otherwise be absent from that table.

And, one may note that a pure hierarchical model may not be possible for 
"UE acting as Mobile Router".  Such a smartphone MR needs an e.g. /64 
for its wifi LAN link and another /64 for its cellular link.  One 
couldn't  aggregate a /64 into another, unless of course one uses 
64share... (which is of course deemed unnecessary _if_ DHCPv6-PD is used).

Alex

---

From: Vízdal Aleš <[email-masked]>
Date: Mon, 7 Oct 2013 17:57:30 +0200

> From: Alexandru Petrescu [mailto:[email-masked]]
> Sent: Monday, October 07, 2013 4:32 PM
> To: Rajiv Asati (rajiva); Vízdal Aleš; Mikael Abrahamsson
> Cc: [email-masked]
> Absent that protocol or out of band communication, the routing information is not
> getting into that router.
> 
> Even with a hierarchical distribution model, these allocated prefixes need to appear in
> the routing table of that AR only if the prefix is allocated, and otherwise be absent
> from that table.
> 
> And, one may note that a pure hierarchical model may not be possible for "UE acting as
> Mobile Router".  Such a smartphone MR needs an e.g. /64 for its wifi LAN link and
> another /64 for its cellular link.  One couldn't  aggregate a /64 into another, unless of
> course one uses 64share... (which is of course deemed unnecessary _if_ DHCPv6-PD is
> used).

There are no relays in the 3GPP case. The UE can either be assigned a /64 or a shorter
prefix using DHCP-PD. In case the mobile router is multihomed it needs to do source based
routing or any other magic to deal with it.

Ales

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 07 Oct 2013 18:10:23 +0200

Le 07/10/2013 17:57, Vízdal Aleš a écrit :
>> -----Original Message----- From: Alexandru Petrescu
>> [mailto:[email-masked]] Sent: Monday, October 07,
>> 2013 4:32 PM To: Rajiv Asati (rajiva); Vízdal Aleš; Mikael
>> Abrahamsson Cc: [email-masked] Subject: Re: [v6ops] Need ref to
>> 3GPP spec for the use of DHCPv6 Prefix Delegation, e.g. for
>> smartphone tethering
>>
>>>> PS: the BroadBand's problem at Relay during Prefix Delegation
>>>> is described in technical report titled "IPv6 in the context
>>>> of TR-101", dated November 2010 as:
>>>>> "hosts receiving IPv6 addresses from the RR are not known to
>>>>> the BNG, i.e. the BNG is not aware of what
>>>>> addresses/prefixes are assigned to hosts attached to the RG
>>>>> acting as RR."
>>>
>>> We may be getting off-topic here, but why is the above deemed as
>>> a problem? It is a hierarchical distribution model after all.
>>
>> BAsically it all starts at section 14 "Relay Agent Behaviour" of
>> RFC 3633 DHCPv6-PD which says this:
>>> If a delegating router communicates with a requesting router
>>> through a relay agent, the delegating router may need a protocol
>>> or other out-of-band communication to add routing information
>>> for delegated prefixes into the provider edge router.
>>
>> Even with a hierarchical distribution model, these allocated
>> prefixes need to appear in the routing table of that AR only if
>> the prefix is allocated, and otherwise be absent from that table.
>>
>> And, one may note that a pure hierarchical model may not be
>> possible for "UE acting as Mobile Router".  Such a smartphone MR
>> needs an e.g. /64 for its wifi LAN link and another /64 for its
>> cellular link.  One couldn't  aggregate a /64 into another, unless
>> of course one uses 64share... (which is of course deemed
>> unnecessary _if_ DHCPv6-PD is used).
>
> There are no relays in the 3GPP case.

There may be a misunderstanding here, because that 3gpp spec seems to
mention Relay several times... like the Serving GW being the Relay and
the PDN GW being the Server.

> The UE can either be assigned a /64 or a shorter prefix using
> DHCP-PD. In case the mobile router is multihomed it needs to do
> source based routing or any other magic to deal with it.

(ok, but I didnt mean multihomed mobile router, I meand a mobile router
with a cellular interface towards the 3gpp network and a wifi interface
towards that person's PAN devices).

Alex

---

From: Vízdal Aleš <[email-masked]>
Date: Mon, 7 Oct 2013 18:19:09 +0200

> There may be a misunderstanding here, because that 3gpp spec seems to mention
> Relay several times... like the Serving GW being the Relay and the PDN GW being the
> Server.

Hmm there is one ... as the TS 24.302 mentioned earlier is 'Architecture enhancements for non-3GPP accesses'
and there is another one TS 24.301 talking about the 3GPP access and that's the one I believe you're looking for.

http://www.3gpp.org/ftp/Specs/html-info/23401.htm (5.3.1.2.6	IPv6 Prefix Delegation via DHCPv6)

Ales

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 07 Oct 2013 18:50:53 +0200

Le 07/10/2013 18:19, Vízdal Aleš a écrit :
>> There may be a misunderstanding here, because that 3gpp spec seems
>> to mention Relay several times... like the Serving GW being the
>> Relay and the PDN GW being the Server.
>
> Hmm there is one ... as the TS 24.302 mentioned earlier is
> 'Architecture enhancements for non-3GPP accesses' and there is
> another one TS 24.301 talking about the 3GPP access and that's the
> one I believe you're looking for.
>

Ok I looked at that as well.

That section talks that the PDN GW being the DHCP Server.

That section does not mention the use of a Relay Agent.

However, given the number of intermediary boxes one sees between the UE
and the PDN GW in figure 4.2.1-1 (e.g. Serving Gateway, PDN Gateway,
more), one could hardly imagine that the UE and the PDN GW are neighbors
in terms of IP.  I have a doubt about it.

BEcause of this doubt, I assume that there is a Relay Agent somewhere
between the UE and the PDN GW (DHCP discovery phase would not work
without a Relay Agent if the Server were not a neighbor).

This may be wrong though...

This is why I wonder whether or not 3gpp uses DHCPv6 Relay Agent
functionality, or not.

Alex

---

From: Gert Doering <[email-masked]>
Date: Mon, 7 Oct 2013 19:09:14 +0200

Hi,

> This is why I wonder whether or not 3gpp uses DHCPv6 Relay Agent

This is really an implementation detail on the PE side, as in "it is
not relevant to the user side".  Of course, if you're using a relay,
the relaying router needs to understand what it relays and what the
response means - and again, that's an implementation detail the 
vendor in question needs to solve, nothing particularily confusing about
that.

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 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 07 Oct 2013 19:31:21 +0200

> vendor in question needs to solve, nothing particularily confusing about

YEs and no.

Indeed it is implementation detail the vendor in question needs  to solve.

Just that solving it for DHCPv6 Prefix Delegation is going to be more 
complex than just solving it for DHCPv6 for addresses, as the bbf 
document presents it.

Alex

---

From: Gert Doering <[email-masked]>
Date: Mon, 7 Oct 2013 21:17:43 +0200

Hi,

> complex than just solving it for DHCPv6 for addresses, as the bbf 

Well, DHCPv6-for-addresses is about as complex if you do it via a relay,
and the addresses do not come from a locally assigned pool.

DHCPv6-for-addresses is much easier indeed if you only assign for a 
directly connected multiaccess network (cable, for example...) and do not 
have to deal with "ok, assignment has been done, now what addresses need
to be stuffed into routing?"

But still, I'm not sure what the context is to make a big deal out of 
it now?

Gert Doering
        -- NetMaster

---

From: Vízdal Aleš <[email-masked]>
Date: Mon, 7 Oct 2013 22:51:25 +0200

> Sent: Monday, October 07, 2013 6:51 PM
> To: Vízdal Aleš; Rajiv Asati (rajiva); Mikael Abrahamsson
> Cc: [email-masked]
> >> mention Relay several times... like the Serving GW being the Relay
> >> and the PDN GW being the Server.
> >
> > 'Architecture enhancements for non-3GPP accesses' and there is another
> > one TS 24.301 talking about the 3GPP access and that's the one I
> > believe you're looking for.
> >
> However, given the number of intermediary boxes one sees between the UE and the
> PDN GW in figure 4.2.1-1 (e.g. Serving Gateway, PDN Gateway, more), one could
> hardly imagine that the UE and the PDN GW are neighbors in terms of IP.  I have a
> doubt about it.
> 
> BEcause of this doubt, I assume that there is a Relay Agent somewhere between the
> UE and the PDN GW (DHCP discovery phase would not work without a Relay Agent if
> the Server were not a neighbor).
> 

The GGSN/PGW is UEs next-hop as the traffic is tunnelled in GTP through all the intermediate nodes.
 
> This is why I wonder whether or not 3gpp uses DHCPv6 Relay Agent functionality, or
> not.
> 
> Alex
> 
> >
> > Ales

Ales

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 08 Oct 2013 09:42:41 +0200

Le 07/10/2013 21:17, Gert Doering a écrit :
>> Just that solving it for DHCPv6 Prefix Delegation is going to be
>> more complex than just solving it for DHCPv6 for addresses, as the
>> bbf document presents it.
>
> Well, DHCPv6-for-addresses is about as complex if you do it via a
> relay, and the addresses do not come from a locally assigned pool.
>
> directly connected multiaccess network (cable, for example...) and do
> not have to deal with "ok, assignment has been done, now what
> addresses need to be stuffed into routing?"

Right, that is one point.  DHCPv6-for-addresses Relay bevaviour
considers that the Relay is already preconfigured statically with a
single prefix which covers all assigned addresses.  There is no need to
dynamically insert/remove that prefix upon address assignment.

On another hand, DHCPv6-for-prefixes may not consider a single prefix
covering (aggregating) all dynamically assigned prefixes.  One such case
is when the smartphone  is assigned one /64 for its ptp link and another
/64 for its LAN (one couldn't aggregate one /64 into another).

> But still, I'm not sure what the context is to make a big deal out
> of it now?

No big deal.  And yes, it is known since some time.

In DHC WG there were many drafts discussing these aspects, since some years.

Just that now we spend some time on writing a Problem Statement draft
(individual proposal) per AD suggestion.

Comments welcome here, because v6ops WG has expertise in the cellular
networks IPv6 deployments (note the 64share and related discussions).

Alex

>
> Gert Doering -- NetMaster
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 08 Oct 2013 09:45:18 +0200

Le 07/10/2013 22:51, Vízdal Aleš a écrit :
>> 2013 6:51 PM To: Vízdal Aleš; Rajiv Asati (rajiva); Mikael
>>>> There may be a misunderstanding here, because that 3gpp spec
>>>> seems to mention Relay several times... like the Serving GW
>>>> being the Relay and the PDN GW being the Server.
>>>
>>> another one TS 24.301 talking about the 3GPP access and that's
>>> the one I believe you're looking for.
>>>
>> However, given the number of intermediary boxes one sees between
>> the UE and the PDN GW in figure 4.2.1-1 (e.g. Serving Gateway, PDN
>> Gateway, more), one could hardly imagine that the UE and the PDN GW
>> are neighbors in terms of IP.  I have a doubt about it.
>>
>> BEcause of this doubt, I assume that there is a Relay Agent
>> somewhere between the UE and the PDN GW (DHCP discovery phase would
>> not work without a Relay Agent if the Server were not a neighbor).
>>

Ah, right, there is a GTP tunnel above all the intermediary IP nodes.

However, even when a tunnel is dynamically set up, a routing table entry
is added in the Relay's routing table (or other similar entry).  The
parameters of that entry necessarily include, among others, the prefix
which is allocated.

No?

Alex

---

From: Vízdal Aleš <[email-masked]>
Date: Tue, 8 Oct 2013 10:49:04 +0200

> However, even when a tunnel is dynamically set up, a routing table entry is added in
> the Relay's routing table (or other similar entry).  The parameters of that entry
> necessarily include, among others, the prefix which is allocated.
> 
> No?

The tunnel stays up for the lifetime of the PDP/PDN context. There is no relay in the 3GPP access
architecture. If the tunnel drops the PGW/GGSN will remove the route from their routing table,
once a new tunnel is setup the routing table is updated accordingly.

Ales

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 08 Oct 2013 10:55:45 +0200

Le 08/10/2013 10:49, Vízdal Aleš a écrit :
>> However, even when a tunnel is dynamically set up, a routing table
>>  entry is added in the Relay's routing table (or other similar
>> entry).  The parameters of that entry necessarily include, among
>> others, the prefix which is allocated.
>>
>> No?
>
> The tunnel stays up for the lifetime of the PDP/PDN context.

Ok.

> There is no relay in the 3GPP access architecture.

Ok.

> If the tunnel drops, the PGW/GGSN will remove the route from their
> routing table, once a new tunnel is setup the routing table is
> updated accordingly.

The route associated with that tunnel should contain a parameter 
containing the Delegated Prefix.  When there is no delegated prefix, 
that route entry should be updated.

The tunnel could stay up but only for the Smartphone.  Or it could stay 
up for both the Smartphone _and_ the Hosts in the smartphone's LAN. 
These are two different things.

Alex

---

From: Vízdal Aleš <[email-masked]>
Date: Tue, 8 Oct 2013 11:00:23 +0200

> > routing table, once a new tunnel is setup the routing table is updated
> > accordingly.
> 
> The route associated with that tunnel should contain a parameter containing the
> Delegated Prefix.  When there is no delegated prefix, that route entry should be
> updated.
> 
> The tunnel could stay up but only for the Smartphone.  Or it could stay up for both the
> Smartphone _and_ the Hosts in the smartphone's LAN.

There is only one GTP tunnel and there is only one route as both the GGSN/PGW to UE
prefix (/64) and the delegated prefix route must be aggregateable. Check the specs ;-)
or take this one offline.

Ales

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 22 Oct 2013 13:35:14 +0200

Hello participants to v6ops WG,

We have just submitted draft-petrescu-relay-route-pd-problem-00
http://tools.ietf.org/html/draft-petrescu-relay-route-pd-problem-00
"Route Problem at Relay during DHCPv6 Prefix Delegation"
M. Boucadair (France Telecom)
L. Yeh (Freelancer Technologies)
A. Petrescu (CEA).

It presents a problem of routing at Relay during Prefix Delegation of
DHCPv6; also lists some solutions I-Ds.  The problem may be relevant in
the DHC WG, at the Broadband Forum and maybe at 3GPP.

Please comment on this draft.

Thanks,

Alex

Le 08/10/2013 10:55, Alexandru Petrescu a écrit :
>>> However, even when a tunnel is dynamically set up, a routing
>>> table entry is added in the Relay's routing table (or other
>>> similar entry).  The parameters of that entry necessarily
>>> include, among others, the prefix which is allocated.
>>>
>>> No?
>>
> The tunnel could stay up but only for the Smartphone.  Or it could
> stay up for both the Smartphone _and_ the Hosts in the smartphone's
> LAN. These are two different things.
>
> Alex
>
>
>>
>>> Alex
>>
>> Ales
>>
>>
>
>
> _______________________________________________ v6ops mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>
>