Subject: Re: [dhcwg] Relaxing text in RFC3633

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 04 Aug 2010 09:38:29 +0200

Le 29/07/2010 12:45, Suresh Krishnan a écrit :
> I would like to point to the following text in section 12.1 of
> RFC3633 "the requesting router MUST NOT assign any delegated prefixes
> or subnets from the delegated prefix(es) to the link through which it
> received the DHCP message from the delegating router." This text does
> not allow even RRs capable of handling such assignment to do so. I
> believe that this too strong. If this text is relaxed to a SHOULD
> NOT, it is possible to define the behavior of a mixed host/RR node
> (such as a LTE mobile phone) so that no more DHCPv6 changes are
> necessary.

Hi Suresh,

I do not quite see why would the LTE mobile phone (a host) need to
assign a prefix on the interface on which it performed DHCPv6-PD?

If the LTE mobile phone relies on the PMIPv6 concept of "prefix per MN"
then that prefix is delegated to the AR, not to the MN; presumable AR
performs DHCPv6-PD.  And AR subsequently assigns it on the link between
AR and MN.

Could you please a few hints about how you'd expect this DHCPv6-PD to
work on the LTE Mobile Phone?

Alex

> Cheers Suresh * As a refresher, this is a pointer to a discussion we
> had in 2008 about the topic
> _http://www.ietf.org/mail-archive/web/dhcwg/current/msg09088.html_
>
>
>
> _______________________________________________ dhcwg mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/dhcwg

---

From: jouni korhonen <[email-masked]>
Date: Wed, 4 Aug 2010 13:37:10 +0300

Alex,

> assign a prefix on the interface on which it performed DHCPv6-PD?

That is because of the 3GPP bearer/link model. The background is described in draft-korhonen-dhc-pd-exclude-00.

> performs DHCPv6-PD.  And AR subsequently assigns it on the link between

PMIPv6 has nothing to do with this. I don't actually follow what you are saying above.

> work on the LTE Mobile Phone?

DHCPv6-PD could work as usual. The issue what we have with 3633 originates from how the 3GPP bearer/link model has been defined and some architectural constraints there are. Therefore, we are looking for this particular "enhancement/relaxation" to make DHCPv6-PD fit better to the general EPC architecture.

- Jouni

> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 4 Aug 2010 12:50:39 +0200 (CEST)

> That is because of the 3GPP bearer/link model. The background is described in draft-korhonen-dhc-pd-exclude-00.

I read this and I still don't understand why the UE needs to assign a 
prefix to the interface where it got the PD from (from within the bearer I 
presume).

> DHCPv6-PD could work as usual. The issue what we have with 3633 
> originates from how the 3GPP bearer/link model has been defined and some 
> architectural constraints there are. Therefore, we are looking for this 
> particular "enhancement/relaxation" to make DHCPv6-PD fit better to the 
> general EPC architecture.

I've had the introduction to LTE and how bearers etc work, but I still 
don't understand why a prefix for that would have to be handled by the UE 
router?

I've always seen the GTP bearers as point to point interfaces, why do they 
now need a prefix on them?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Ole Troan <[email-masked]>
Date: Wed, 4 Aug 2010 13:34:22 +0200

Mikael,

> I read this and I still don't understand why the UE needs to assign a prefix to the interface where it got the PD from (from within the bearer I presume).
> 
> I've had the introduction to LTE and how bearers etc work, but I still don't understand why a prefix for that would have to be handled by the UE router?
> 
> I've always seen the GTP bearers as point to point interfaces, why do they now need a prefix on them?

the problem is as follows (as I understand it):

 - the delegating router / backend systems can only support a single prefix per customer
 - the point to point link to the customer has to be numbered (e.g if there is a single host and not a router)
 - prefix delegation must be supported in case of a connected network

this problem can be solved in a multitude of ways.
 1) DR "steals" a prefix from the delegated prefix to use on the p2p. RR detects this, or uses something like
     the proposed DHCP exclude options
 2) DR delegates only half of the prefix, a /64 of the other half is used for p2p link
 3) RR requests a single /64 for each of its downstream interfaces. DR aggregates this into a larger allocation

relaxing the 3633 restriction doesn't change any of this. but I think the point is that the restriction is on the wrong place. it should be on the DR. the RR gets delegated authority of the prefix and can do whatever 'it' likes with it. but, it would violate the protocol for the DR to borrow part of a prefix previously delegated.

cheers,
Ole

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 04 Aug 2010 13:45:41 +0200

Le 04/08/2010 12:37, jouni korhonen a écrit :
>>> RFC3633 "the requesting router MUST NOT assign any delegated
>>> prefixes or subnets from the delegated prefix(es) to the link
>>> through which it received the DHCP message from the delegating
>>> router." This text does not allow even RRs capable of handling
>>> such assignment to do so. I believe that this too strong. If this
>>> text is relaxed to a SHOULD NOT, it is possible to define the
>>> behavior of a mixed host/RR node (such as a LTE mobile phone) so
>>> that no more DHCPv6 changes are necessary.
>>
>> Hi Suresh,
>>
> That is because of the 3GPP bearer/link model. The background is
> described in draft-korhonen-dhc-pd-exclude-00.

It relates to the "unnumbered router model":
> The prefix excluding mechanism is targeted to deployments where
> DHCPv6-based prefix delegation is desired to be used but unnumbered
> router model is not available.

What is an unnumbered router model? Or where could I read more about
what is an unnumbered router model?

>> If the LTE mobile phone relies on the PMIPv6 concept of "prefix per
>> MN" then that prefix is delegated to the AR, not to the MN;
>> presumable AR performs DHCPv6-PD.  And AR subsequently assigns it
>> on the link between AR and MN.
>

Ok, sorry, so it's not about PMIPv6, forget it.

>> Could you please a few hints about how you'd expect this DHCPv6-PD
>>  to work on the LTE Mobile Phone?
>
> originates from how the 3GPP bearer/link model has been defined and
> some architectural constraints there are. Therefore, we are looking
> for this particular "enhancement/relaxation" to make DHCPv6-PD fit
> better to the general EPC architecture.

Sounds good intention.

In order to assign a prefix on the 3GPP bearer/link has one considered
the typical use of Router Advertisements, instead of DHCPv6-PD?  RAs do
contain on-link prefixes.

And the use of PPP IPv6?  Probably these have been discarded for some
reason(?).

Alex

>
> - Jouni
>
>
>
>>
>> Alex
>>
>>
>>> Cheers Suresh * As a refresher, this is a pointer to a discussion
>>> we had in 2008 about the topic

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 4 Aug 2010 13:49:28 +0200 (CEST)

> - the point to point link to the customer has to be numbered (e.g if there is a single host and not a router)

Why would a host request PD ? If it does request PD (and therefore is a 
router), why can't it use a logical interface to source traffic?

If it doesn't support PD, isn't there another way of handing out IP 
address to the bearer interface? I don't see why PD would be used in this 
case, and frankly I think it sounds really weird.

We've done testing on IPv6 on GTPv1 bearers in our 3G network and it works 
just fine, and we don't use PD.

1. GGSN (or equivalent) makes sure the UE gets an IP address via some 
mean, DHCPv6 or SLAAC or whatever.
2. If the UE wants a prefix, it does a PD request.

I must say that having the UE enumerate the link sounds really really 
strange, because it also involves creating logic in GGSN/PGW to make sure 
the UE doesn't try to enumerate it with IP addresses outside of the PD 
scope the UE was handed.

Why not use the existing mechanisms to hand out an IPv6 address if this is 
needed, and only use PD when it's actually needed?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 4 Aug 2010 13:50:38 +0200 (CEST)

> what is an unnumbered router model?

Look at the "weak" vs "strong" host model. 
<http://en.wikipedia.org/wiki/Host_model>
<http://www.faqs.org/rfcs/rfc1122.html>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 04 Aug 2010 13:52:58 +0200

> relaxing the 3633 restriction doesn't change any of this. but I think the point is that the restriction is on the wrong place. it should be on the DR. the RR gets delegated authority of the prefix…

But I believe the restriction could be held in place if a mix
RA+DHCP were used, or DHCP+DHCPPD.  Just some thought.

Relaxing the restriction, and extracting sub-prefixes from  the 
allocated prefix (draft-korhonen-dhc-pd-exclude-00) could work too.

Alex

Alex

---

From: Ole Troan <[email-masked]>
Date: Wed, 4 Aug 2010 14:37:16 +0200

Mikael,

> Why would a host request PD ? If it does request PD (and therefore is a router), why can't it use a logical interface to source traffic?
> 
> If it doesn't support PD, isn't there another way of handing out IP address to the bearer interface? I don't see why PD would be used in this case, and frankly I think it sounds really weird.

misunderstanding, it isn't either. but SLAAC/DHCP is supported as the addressing model of the point to point link.
PD in the case it is a router. still the requirement of a single customer has a single prefix.

> We've done testing on IPv6 on GTPv1 bearers in our 3G network and it works just fine, and we don't use PD.

no, but do you connect a router?

> 1. GGSN (or equivalent) makes sure the UE gets an IP address via some mean, DHCPv6 or SLAAC or whatever.
> I must say that having the UE enumerate the link sounds really really strange, because it also involves creating logic in GGSN/PGW to make sure the UE doesn't try to enumerate it with IP addresses outside of the PD scope the UE was handed.
> 
> Why not use the existing mechanisms to hand out an IPv6 address if this is needed, and only use PD when it's actually needed?

that is the intention as far as I can tell.

cheers,
Ole

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 4 Aug 2010 14:40:42 +0200 (CEST)

On Wed, 4 Aug 2010, Ole Troan wrote:

>> address to the bearer interface? I don't see why PD would be used in 
>> this case, and frankly I think it sounds really weird.
>

Yes, but I don't understand why the UE router needs to put part of the PD 
prefix on the bearer.

> no, but do you connect a router?

Nope, but my point was that using PD to number the bearer seems weird.

>> Why not use the existing mechanisms to hand out an IPv6 address if this 
>> is needed, and only use PD when it's actually needed?
>

Then I don't understand the rationale of relaxing the text in RFC3633 at 
all. I don't understand why it would ever be a good idea to numerate the 
bearer by having the UE take part of it's PD prefix and use it on the 
bearer.

---

From: jouni korhonen <[email-masked]>
Date: Wed, 4 Aug 2010 16:42:48 +0300

Hi Mikael,

> Why would a host request PD ? If it does request PD (and therefore is a router), why can't it use a logical interface to source traffic?

A mobile (in this case) can be in a host role or in a router role. It always starts as a host and gets assigned a prefix. Later, when the host so decides it can switch to a (requesting) router role.

> If it doesn't support PD, isn't there another way of handing out IP address to the bearer interface? I don't see why PD would be used in this case, and frankly I think it sounds really weird.

Touching the existing bearer model is seen as a no go, for various reasons. The host always gets assigned a prefix when the bearer comes up and the host can only use SLAAC to configure its own address. 

The delegated prefixes are not meant to the (cellular) bearer interface but other interfaces the device may have. Think about a cellular mobile with WLAN..

> We've done testing on IPv6 on GTPv1 bearers in our 3G network and it works just fine, and we don't use PD.

There is no PD so far. It is a rel-10 thing.

> 1. GGSN (or equivalent) makes sure the UE gets an IP address via some mean, DHCPv6 or SLAAC or whatever.

Only SLAAC in case of IPv6.

> 2. If the UE wants a prefix, it does a PD request.

UE always gets only /64 during bearer setup. Nowadays, if an UE were to do a HDCPv6-PD request it most probably wouldn't work nor go anywhere beyond the GGSN.

> Why not use the existing mechanisms to hand out an IPv6 address if this is needed, and only use PD when it's actually needed?

Well, PD is used only when needed.

- JOuni

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 4 Aug 2010 15:47:06 +0200 (CEST)

On Wed, 4 Aug 2010, jouni korhonen wrote:

> The delegated prefixes are not meant to the (cellular) bearer interface 
> but other interfaces the device may have. Think about a cellular mobile 
> with WLAN..

Then why do we need to relax RFC3633?

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 04 Aug 2010 16:23:39 +0200

Le 04/08/2010 15:47, Mikael Abrahamsson a écrit :
>> The delegated prefixes are not meant to the (cellular) bearer
>> interface but other interfaces the device may have. Think about a
>> cellular mobile with WLAN..
>

I have same question: if the delegated prefixes are not meant to the
bearer iface but for other ifaces the device may have - why do we need
the relaxation?

The rfc3633 text seems to accommodate this case well.

(rfc3633: "the requesting router MUST NOT assign any delegated prefixes
or subnets from the delegated prefix(es) to the link through which it
received the DHCP message from the delegating router.")

A clarification could be welcome though, like "the RR MUST NOT
assign prefixes to the link where DHCP happened, but to any of the other
links".

Alex

---

From: Ole Troan <[email-masked]>
Date: Wed, 4 Aug 2010 16:45:44 +0200

> assign prefixes to the link where DHCP happened, but to any of the other

the RFC3633 is largely orthogonal to this problem. I just pointed out that I thought the restriction was in the wrong place. it should be on the DR, if anywhere.

the problem, is how do you use DHCP PD together with RA/DHCP on a link, and end up with a single prefix representing the subscriber.
both for the /64 advertised on the link and the e.g /56 delegated to the RR.

cheers,
Ole

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 4 Aug 2010 10:50:25 -0400

Hi Dave,

On 10-07-30 05:16 AM, David W. Hankins wrote:
> On Thu, Jul 29, 2010 at 06:45:06AM -0400, Suresh Krishnan wrote:
>> "the requesting router MUST NOT assign any delegated prefixes or subnets from the delegated prefix(es) to the link through which it received the DHCP message from the delegating router."
> 
> I'm confused.  I thought we needed the reverse; where the DR receives
> a delegation for the phone (a /56), picks out a /64 and passes the
> rest down to the phone.

Exactly. What you quoted above is the current text in the RFC. To 
further clarify, the DR picks out a /64 and advertises it in an RA but 
DOES NOT use the prefix to configure an address on the interface where 
it sends out the RA.

Cheers
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 4 Aug 2010 10:53:52 -0400

Hi Ole,

> the RFC3633 is largely orthogonal to this problem. I just pointed out that I thought the restriction was in the wrong place. it should be on the DR, if anywhere.

+1.

> both for the /64 advertised on the link and the e.g /56 delegated to the RR.

Couldn't have said this better :-)

Cheers
Suresh

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 04 Aug 2010 17:19:39 +0200

Le 04/08/2010 16:45, Ole Troan a écrit :
>>>> interface but other interfaces the device may have. Think about
>>>> a cellular mobile with WLAN..
>>>
>> I have same question: if the delegated prefixes are not meant to
>> the bearer iface but for other ifaces the device may have - why do
>>  we need the relaxation?
>>
>> (rfc3633: "the requesting router MUST NOT assign any delegated
>> router.")
>> assign prefixes to the link where DHCP happened, but to any of the
>>  other links".
>
> the RFC3633 is largely orthogonal to this problem. I just pointed out
> that I thought the restriction was in the wrong place. it should be
> on the DR, if anywhere.
>
> the problem, is how do you use DHCP PD together with RA/DHCP on a
> link, and end up with a single prefix representing the subscriber.

Were that delegated /56 only a /64 then we'd have a problem, but if it
is /56 then I think no problem.

(I think in general there is potential confusion in the text "DR MUST
  NOT assign any delegated prefixes...", but in the word "assign", not
  in the "MUST NOT".

Assigning a prefix to a link means adding it as prefix on-link (ND) on
some interface?  Insert it as Cisco 'connected' route of one of its
interfaces?  Have some or all sub-prefixes through dst Gateways (routing
table entry) attached to some of its links?)

Alex

"ifconfig add"?  "route add -net"?

That single prefix could be the delegated /56 out of which the DR (not
the MR - Mobile Router) reserves a /64 RA'ed on the bearer.  The MR
would not need to assign that /64 on the bearer link, but it would need
to insert
> cheers, Ole

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 04 Aug 2010 17:21:08 +0200

Le 04/08/2010 16:53, Suresh Krishnan a écrit :
>>>>> interface but other interfaces the device may have. Think
>>>>> about a cellular mobile with WLAN..
>>> the bearer iface but for other ifaces the device may have - why
>>> do we need the relaxation?
>>>
>>> assign prefixes to the link where DHCP happened, but to any of
>>> the other links".
>>
>> the RFC3633 is largely orthogonal to this problem. I just pointed
>> out that I thought the restriction was in the wrong place. it
>> should be on the DR, if anywhere.
>
> +1.

But one would forbid DR to assign the delegated prefix to any one of its
links.

Alex

> Cheers Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 4 Aug 2010 10:51:44 -0400

Hi Mikael,
   This is the expected sequence of events.

a) Mobile attaches to EPC/LTE network and obtains a /64 for its use on 
the wireless uplink interface (i.e. it is acting as a host).
b) At some later point in time, the mobile becomes a RR in order to 
support devices/networks behind it. The operator has reserved a /56 for 
delegation to the mobile (the original SLAAC /64 came out of this prefix)
c) Mobile requests a prefix delegation from the DR. At this point the DR 
has the following options

1) Send the whole /56 in the IA_PD and expect the mobile to not use the 
/64 that was originally advertised to it. The mobiles that are capable 
of doing this will explicitly signal them to the DR.
2) Send only a /57 in the IA_PD so that the original /64 is left out of 
the delegated block. This is fully backward compatible, but some 
operators have issues with "address wastage" in this case.
3) Expect the Mobile to do multiple PD requests for a /57,/58.../64 so 
that the whole space is delegated out without wastage.

1) Requires relaxation of language in RFC3633. And my point was that the 
restriction in RFC3633 was on the wrong entity. The DR has delegated the 
prefix to the RR. It has no business using any sub-prefixes from that 
block. The RR on the other hand "owns" the prefix and should be able to 
do whatever with it as long as it does not break the DR.

Thanks
Suresh

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 4 Aug 2010 20:45:36 +0200 (CEST)

> do whatever with it as long as it does not break the DR.

I just think this is weird thinking.

I think these are better alternatives:

1. Just separate the two spaces, the customer has /64 for the link and /56 
for routing, and just accept that these are separate.

2. If this is not acceptable, make sure the UE drops the /64 and uses LL 
only to ask for the PD, run LL only on the bearer and have the UE use the 
weak host model for its own outgoing traffic (sourced from a loopback 
created from the PD prefix).

3. The whole "let's give the first /64 out of the /56 to the bearer and 
then if the UE asks for it, give it the rest of the bearer by having the 
UE assign the first (already existing) /64 to the bearer" is just messy. 
I'd rather just change (or clarify) the language in relevant RFC to make 
sure the UE understands that if a /64 out of the PD range it got handed 
was already assigned to an interface of itself, then it won't hand it out 
to someone else (it's now "reserved"). There is little need to actually 
"hand it out" to the bearer and have the UE "assign" it somewhere. It just 
needs to make sure it won't use it for anything else in the future.

This basically means the DR still "owns" the first /64, but I still think 
this is better than the alternative. I don't want the RR to hand out 
addresses to mobile core equipment (DR), that just feels plain wrong.

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 4 Aug 2010 14:53:20 -0400

Hi Mikael,

> for routing, and just accept that these are separate.

This was the first idea we went for, but it is not possible due to 
restrictions in the 3GPP Policy Control architecture. Please check

http://tools.ietf.org/html/draft-krishnan-intarea-pd-epc-00#section-4

for more info.

> created from the PD prefix).

Except that before becoming the RR, the UE may need to send traffic as a 
host. What address would it use?
	
> needs to make sure it won't use it for anything else in the future.

Yep. What you suggest makes perfect sense, but the current text in 
RFC3633 does not allow this.

> addresses to mobile core equipment (DR), that just feels plain wrong.

The RR owns the /64 as well. It uses the /64 to form an address on the 
interface towards the mobile core, but will not advertise this prefix 
towards the mobile core (as you say, this feels plain wrong).

Cheers
Suresh

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 4 Aug 2010 21:09:48 +0200 (CEST)

> host. What address would it use?

The UE already has a /64 it can use for traffic before it wants to become 
RR. Changing role from host to RR means dropping the IPv6 address it 
already has, and become a RR with PD and using the weak host model.

I noticed before that there was talk about address wastage, how much 
address waste isn't it to allocate a /56 to every UE regardless of if it's 
going to become RR or not?

>> then if the UE asks for it, give it the rest of the bearer by having the UE 
>> assign the first (already existing) /64 to the bearer" is just messy. I'd 
>> rather just change (or clarify) the language in relevant RFC to make sure 
>> the UE understands that if a /64 out of the PD range it got handed was 
>> already assigned to an interface of itself, then it won't hand it out to 
>> someone else (it's now "reserved"). There is little need to actually "hand 
>> it out" to the bearer and have the UE "assign" it somewhere. It just needs 
>> to make sure it won't use it for anything else in the future.
>
> Yep. What you suggest makes perfect sense, but the current text in RFC3633 
> does not allow this.

Yes, but the text being quoted doesn't seem like the one that needs to be 
relaxed. We don't want the RR to hand out prefix to the bearer, we want 
the RR to notice it's already in use and treat it as reserved. The DR is 
still the one owning the bearer prefix and the RR treats it as reserved.

I still prefer the LL only on bearer and weak host model when the UE wants 
to become a RR for PD.

---

From: jouni korhonen <[email-masked]>
Date: Wed, 4 Aug 2010 23:58:19 +0300

Hi Ole,

> both for the /64 advertised on the link and the e.g /56 delegated to the RR.

This is a very good summary of the whole thing ;)

- Jouni

---

From: jouni korhonen <[email-masked]>
Date: Thu, 5 Aug 2010 00:16:09 +0300

Hi Mikael,

On Aug 4, 2010, at 10:09 PM, Mikael Abrahamsson wrote:

>>> 2. If this is not acceptable, make sure the UE drops the /64 and uses LL only to ask for the PD, run LL only on the bearer and have the UE use the weak host model for its own outgoing traffic (sourced from a loopback created from the PD prefix).
>> 
>> Except that before becoming the RR, the UE may need to send traffic as a host. What address would it use?
> 
> The UE already has a /64 it can use for traffic before it wants to become RR. Changing role from host to RR means dropping the IPv6 address it already has, and become a RR with PD and using the weak host model.
> 
> I noticed before that there was talk about address wastage, how much address waste isn't it to allocate a /56 to every UE regardless of if it's going to become RR or not?

EPC has ways to aid deployment here. <speculation> It is likely that there will be PD and non-PD enabled APNs. So the UE better know when establishing a bearer whether it wants to do PD at some point or not. So e.g. if the bearer is established to a non-PD APN, attempt to do PD would fail and no prefixes were ever allocated. If the bearer is established to a PD enabled APN, then prefixes get allocated regardless the UE does PD or not.. however, the price tag is probably different as well. </speculation>

- JOuni

> 
>>> 3. The whole "let's give the first /64 out of the /56 to the bearer and then if the UE asks for it, give it the rest of the bearer by having the UE assign the first (already existing) /64 to the bearer" is just messy. I'd rather just change (or clarify) the language in relevant RFC to make sure the UE understands that if a /64 out of the PD range it got handed was already assigned to an interface of itself, then it won't hand it out to someone else (it's now "reserved"). There is little need to actually "hand it out" to the bearer and have the UE "assign" it somewhere. It just needs to make sure it won't use it for anything else in the future.
>> 
>> Yep. What you suggest makes perfect sense, but the current text in RFC3633 does not allow this.
> 
> Yes, but the text being quoted doesn't seem like the one that needs to be relaxed. We don't want the RR to hand out prefix to the bearer, we want the RR to notice it's already in use and treat it as reserved. The DR is still the one owning the bearer prefix and the RR treats it as reserved.
> 
> I still prefer the LL only on bearer and weak host model when the UE wants to become a RR for PD.
> 
> --

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 4 Aug 2010 21:31:08 -0500

Suresh:

Perhaps I'm really confused, but how would changing the restriction in
RFC 3633 from request router to delegating router help here ... in fact,
it makes things worse as the delegating router is first using it as a
/64 to assign addresses to that link and then as /56 for the PD request.
So, I don't see how Ole's fix works here at all.

Part of the problem is that PD just allows assigning prefixes on a power
of 2 boundary. So, you can't carve out a /64. Perhaps you need a
IAPREFIXEXCLUSION option that would specify the /64 that has already
been used (that way, the IA_PD contains an IAPREFIX with the /56 and a
IAPREFIXEXCLUSION with the /64).

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Suresh Krishnan
Sent: Wednesday, August 04, 2010 10:52 AM
To: Mikael Abrahamsson
Cc: [email-masked]; Alexandru Petrescu
Subject: Re: [dhcwg] Relaxing text in RFC3633

Hi Mikael,

delegation to the mobile (the original SLAAC /64 came out of this
prefix)

Thanks
Suresh

>> The delegated prefixes are not meant to the (cellular) bearer
interface 
> Then why do we need to relax RFC3633?

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

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 5 Aug 2010 06:11:10 +0200 (CEST)

On Thu, 5 Aug 2010, jouni korhonen wrote:

> EPC has ways to aid deployment here. <speculation> It is likely that 
> there will be PD and non-PD enabled APNs. So the UE better know when 
> establishing a bearer whether it wants to do PD at some point or not. So 
> e.g. if the bearer is established to a non-PD APN, attempt to do PD 
> would fail and no prefixes were ever allocated. If the bearer is 
> established to a PD enabled APN, then prefixes get allocated regardless 
> the UE does PD or not.. however, the price tag is probably different as 
> well. </speculation>

I think this model makes a lot more sense, it would also involve the 
possibility of running LL on the bearer only, and using the weak host 
model for sourcing traffic from RR itself, if the ISP wants to make sure 
the user is in a single /56.

It also means there is no change needed to any RFC and this would actually 
follow one of the deployment models in 
<http://bgp.potaroo.net/ietf/idref/draft-ietf-v6ops-ipv6-cpe-router/>.

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 5 Aug 2010 00:37:43 -0400

Hi Bernie, 

> From: Bernie Volz (volz) [mailto:[email-masked]] 
> Sent: Wednesday, August 04, 2010 10:31 PM
> To: Suresh Krishnan; Mikael Abrahamsson
> Subject: RE: [dhcwg] Relaxing text in RFC3633
> 
> Suresh:
> 
> Perhaps I'm really confused, but how would changing the 
> restriction in RFC 3633 from request router to delegating 
> router help here ... in fact, it makes things worse as the 
> delegating router is first using it as a

The DR is not really using the /64. It is advertising the /64 in an RA for the RR to use.

> So, I don't see how Ole's fix works here at all.

Ole's fix clarifies that the DR does not use the prefix other than to advertise it.

> 
> Part of the problem is that PD just allows assigning prefixes 
> on a power of 2 boundary. So, you can't carve out a /64. 
> Perhaps you need a IAPREFIXEXCLUSION option that would 
> specify the /64 that has already been used (that way, the 
> IA_PD contains an IAPREFIX with the /56 and a 

Yes. I think that this is one of the solutions that we need to pursue.
This is the basic premise behind

http://tools.ietf.org/id/draft-korhonen-dhc-pd-exclude-00.txt

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 5 Aug 2010 00:45:23 -0400

Hi Mike, 

> From: Mikael Abrahamsson [mailto:[email-masked]] 
> Sent: Thursday, August 05, 2010 12:11 AM
> To: jouni korhonen
> Cc: Suresh Krishnan; [email-masked]; Alexandru Petrescu
> > establishing a bearer whether it wants to do PD at some 
> point or not. 
> > So e.g. if the bearer is established to a non-PD APN, 
> attempt to do PD 
> > established to a PD enabled APN, then prefixes get allocated 
> > regardless the UE does PD or not.. however, the price tag 
> is probably 
> > different as well. </speculation>
> 
> I think this model makes a lot more sense, it would also 
> involve the possibility of running LL on the bearer only, and 
> using the weak host model for sourcing traffic from RR 
> itself, if the ISP wants to make sure the user is in a single /56.

The model makes sense but, unfortunately, the UE needs to operate even before it becomes an RR. For this purpose, the UE needs to receive an RA with a auto-configurable prefix. In the current state of things(3GPP Release 8/9), stateful DHCPv6 is not supported on mobiles, and the only IETF based address configuration mechanism is SLAAC. The question is how do we build on top of what we have to introduce DHCP-PD.

Thanks
Suresh

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 5 Aug 2010 07:26:19 +0200 (CEST)

On Thu, 5 Aug 2010, Suresh Krishnan wrote:

> The model makes sense but, unfortunately, the UE needs to operate even 
> before it becomes an RR.

Why?

> For this purpose, the UE needs to receive an RA with a auto-configurable 
> prefix. In the current state of things(3GPP Release 8/9), stateful 
> DHCPv6 is not supported on mobiles, and the only IETF based address 
> configuration mechanism is SLAAC. The question is how do we build on top 
> of what we have to introduce DHCP-PD.

But if DHCPv6 is not supported on devices, why would they support 
DHCPv6-PD ?

---

From: jouni korhonen <[email-masked]>
Date: Thu, 5 Aug 2010 11:19:43 +0300

On Aug 5, 2010, at 8:26 AM, Mikael Abrahamsson wrote:

>> The model makes sense but, unfortunately, the UE needs to operate even before it becomes an RR.
> 
> Why?
> 
>> For this purpose, the UE needs to receive an RA with a auto-configurable prefix. In the current state of things(3GPP Release 8/9), stateful DHCPv6 is not supported on mobiles, and the only IETF based address configuration mechanism is SLAAC. The question is how do we build on top of what we have to introduce DHCP-PD.
> 
> But if DHCPv6 is not supported on devices, why would they support DHCPv6-PD ?

DHCPv6 is not supported for configuring the /64 for the UE. DHCPv6 is already there for configuring other information. Next step would be using DHCPv6-PD (without any other IA than IA_PD..).

- JOuni

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 5 Aug 2010 13:01:19 +0200 (CEST)

On Thu, 5 Aug 2010, jouni korhonen wrote:

>>> For this purpose, the UE needs to receive an RA with a 
>>> auto-configurable prefix. In the current state of things(3GPP Release 
>>> 8/9), stateful DHCPv6 is not supported on mobiles, and the only IETF 
>>> based address configuration mechanism is SLAAC. The question is how do 
>>> we build on top of what we have to introduce DHCP-PD.
>>
> DHCPv6 is not supported for configuring the /64 for the UE. DHCPv6 is 
> already there for configuring other information. Next step would be 
> using DHCPv6-PD (without any other IA than IA_PD..).

But if DHCPv6 for address is not supported, how would the initial proposal 
work where the RR would hand out addresses on the bearer to the PGW?

Anyway, I think having PD expanded with the capability of telling "holes" 
in the prefix is the best idea I've seen so far.

---

From: Ole Troan <[email-masked]>
Date: Thu, 5 Aug 2010 13:07:09 +0200

Mikael,

> But if DHCPv6 for address is not supported, how would the initial proposal work where the RR would hand out addresses on the bearer to the PGW?

that wasn't the proposal.
it was for the DR to advertise the /64 in an RA, taken from the same block that it delegated to the RR.
the problems with that of course is that the RR might not detect the use of the block in time, and legacy implementations would in any case fail.

> Anyway, I think having PD expanded with the capability of telling "holes" in the prefix is the best idea I've seen so far.

indeed. would have been nice(est) if we could encode this into a single option instead of requiring two though.

cheers,
Ole

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 5 Aug 2010 13:12:27 +0200 (CEST)

> it was for the DR to advertise the /64 in an RA, taken from the same block that it delegated to the RR.

That's not how I read the start of this thread, but ok, fair enough.

> the problems with that of course is that the RR might not detect the use 
> of the block in time, and legacy implementations would in any case fail.

As far as I can see there are no way of avoiding legacy implementations of 
failing (since all suggestions I've seen so far involves new options or 
new behaviour).

>> Anyway, I think having PD expanded with the capability of telling 
>> "holes" in the prefix is the best idea I've seen so far.
>

Sure.

---

From: jouni korhonen <[email-masked]>
Date: Thu, 5 Aug 2010 14:48:22 +0300

On Aug 5, 2010, at 2:12 PM, Mikael Abrahamsson wrote:

> As far as I can see there are no way of avoiding legacy implementations of failing (since all suggestions I've seen so far involves new options or new behaviour).

The absence of the new option tells the DR that the RR is a legacy one. It also tells to the network management that there are still RRs lurking in the network which need to be upgraded.  The DR has a choice to reject RR's PD request. Although the RR might not be happy but at least things don't break.

- Jouni

---

From: <[email-masked]>
Date: Thu, 5 Aug 2010 22:50:32 +0200

> >> the problems with that of course is that the RR might not detect the
> use of the block in time, and legacy implementations would in any case
> fail.
> >
> > As far as I can see there are no way of avoiding legacy
> implementations of failing (since all suggestions I've seen so far
> involves new options or new behaviour).
> 
> The absence of the new option tells the DR that the RR is a legacy one.
> It also tells to the network management that there are still RRs
> lurking in the network which need to be upgraded.  The DR has a choice
> to reject RR's PD request. Although the RR might not be happy but at
> least things don't break.

And as stated in the draft the DR may choose to use "waste half of the delegated space" when serving legacy RR.

Teemu

---

From: Ted Lemon <[email-masked]>
Date: Sat, 14 Aug 2010 11:22:15 -0400

So having just read through this discussion from start to finish, I am going to try to summarize my understanding of what has transpired so that people can tell me where I'm wrong.

1. Suresh initially proposed to change a MUST to a SHOULD in RFC3633 so that he could get the behavior he wanted.
2. Ole explained that the reason we want to do this is so that the DR can advertise a /64 for the RR to pick up, but assign a /56 that *contains* that /64 in a PD to the RR when the RR requests a PD, and can *continue* to advertise the /64 even though RFC3633 currently forbids this.
3. There's talk of the RR sending an option to signal to the DR that it knows how to do this, so that the DR will not do this for legacy RRs that might break.

Then discussion kind of petered out, seemingly without reaching a conclusion.   Is that about right, or did I miss something?

---

From: jouni korhonen <[email-masked]>
Date: Sun, 15 Aug 2010 23:05:10 +0300

Hi Ted,

> 1. Suresh initially proposed to change a MUST to a SHOULD in RFC3633 so that he could get the behavior he wanted.

Yes. Additionally, with plain MUST->SHOULD change one still has to document & mandate the behavior per deployment/link type. I would assume this is not an issue because virtually every SDO document their own link model etc peculiarities. 

> 2. Ole explained that the reason we want to do this is so that the DR can advertise a /64 for the RR to pick up, but assign a /56 that *contains* that /64 in a PD to the RR when the RR requests a P…

Yes. Just to make sure that the scenario I and Teemu originally had in mind is captured. In our scenario the DR advertises the /64 in a RA and the RR uses SLAAC to configure its address. The PD takes place after that. At the end, both RA and DHCPv6 based address configuration has to be supported in the above case.

> 3. There's talk of the RR sending an option to signal to the DR that it knows how to do this, so that the DR will not do this for legacy RRs that might break.

Yes. This was the draft-korhonen-dhc-pd-exclude.

> Then discussion kind of petered out, seemingly without reaching a conclusion.   Is that about right, or did I miss something?

There was no crystal clear conclusion. Though, I sensed support towards 3.

- Jouni

---

From: Ted Lemon <[email-masked]>
Date: Sun, 15 Aug 2010 22:00:23 -0400

> There was no crystal clear conclusion. Though, I sensed support towards 3.

That is to say, 3 and *not* 1?

---

From: Ole Troan <[email-masked]>
Date: Mon, 16 Aug 2010 09:35:24 +0200

Ted,

> 1. Suresh initially proposed to change a MUST to a SHOULD in RFC3633 so that he could get the behavior he wanted.

just changing the MUST to a SHOULD wouldn't really solve this issue.

> 2. Ole explained that the reason we want to do this is so that the DR can advertise a /64 for the RR to pick up, but assign a /56 that *contains* that /64 in a PD to the RR when the RR requests a P…

I still want 3633 to forbid this. the _only_ think I tried to say was that the restriction in 3633 is in the wrong place. the RR should be free to do whatever it wants with the prefix. the _DR_ is not allowed to do anything with the prefix when it has been delegated.
so, no, it cannot advertise a /64 in an RA on the link if it has delegated the /56 the /64 is a subnet of.

> 3. There's talk of the RR sending an option to signal to the DR that it knows how to do this, so that the DR will not do this for legacy RRs that might break.

my understanding / hope / thinking was that instead the RR would signal support with an ORO option and that the DR would delegate a e.g /56 - 1.

cheers,
Ole

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 16 Aug 2010 14:33:36 -0400

Hi Ted/Ole,

> just changing the MUST to a SHOULD wouldn't really solve this issue.

Ack. More work is required and as Jouni said, 3. fits the bill for the 
additional work required.

> so, no, it cannot advertise a /64 in an RA on the link if it has delegated the /56 the /64 is a subnet of.

Fully agree. RFC3633 now has the restriction in the wrong place. Placing 
this restriction on the DR instead of the RR will fully resolve any 
issues I have.

>> Then discussion kind of petered out, seemingly without reaching a conclusion.   Is that about right, or did I miss something?

You are right.

Thanks
Suresh

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 16 Aug 2010 15:50:35 -0500

Sorry to be jumping in late.  But another question I have is why is it
that RFC3633 PD mechanism is only supported over stateful DHCPv6 and not
over stateless DHCPv6?  In fact, it is not  mentioned in any RFC that
stateless DHCPv6 cannot be used for RFC 3633 PD acquisition, but I have
heard from the authors of RFC 3633 that stateless DHCPv6 cannot be used
with RFC 3633.  Well now that we are looking at RFC 3633, it is time for
this question to be put to bed as well and see if any text needs to be
added to RFC 3633 etc.

Thanks,

Hemant

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Suresh Krishnan
Sent: Thursday, July 29, 2010 6:45 AM
To: [email-masked]
Subject: [dhcwg] Relaxing text in RFC3633

I would like to point to the following text in section 12.1 of RFC3633

"the requesting router MUST NOT assign any delegated prefixes or subnets
from the delegated prefix(es) to the link through which it received the
DHCP message from the delegating router." 

This text does not allow even RRs capable of handling such assignment to
do so. I believe that this too strong.

If this text is relaxed to a SHOULD NOT, it is possible to define the
behavior of a mixed host/RR node (such as a LTE mobile phone) so that no
more DHCPv6 changes are necessary.

Cheers

Suresh

* As a refresher, this is a pointer to a discussion we had in 2008 about
the topic 

http://www.ietf.org/mail-archive/web/dhcwg/current/msg09088.html

---

From: Ralph Droms <[email-masked]>
Date: Mon, 16 Aug 2010 18:21:53 -0400

Read section 12 of RFC 3633.  PD (IA_PD) is a stateful assignment mechanism and uses the same message sequences as used for address assignment through IA_NA and IA_TA.

- Ralph

On Aug 16, 2010, at 4:50 PM 8/16/10, Hemant Singh (shemant) wrote:

> Sorry to be jumping in late.  But another question I have is why is it that RFC3633 PD mechanism is only supported over stateful DHCPv6 and not over stateless DHCPv6?  In fact, it is not  mentioned in any RFC that stateless DHCPv6 cannot be used for RFC 3633 PD acquisition, but I have heard from the authors of RFC 3633 that stateless DHCPv6 cannot be used with RFC 3633.  Well now that we are looking at RFC 3633, it is time for this question to be put to bed as well and see if any text needs to be added to RFC 3633 etc.
>  
> Thanks,
>  
> Hemant
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Suresh Krishnan
> This text does not allow even RRs capable of handling such assignment to do so. I believe that this too strong.
>  
> If this text is relaxed to a SHOULD NOT, it is possible to define the behavior of a mixed host/RR node (such as a LTE mobile phone) so that no more DHCPv6 changes are necessary.
>  
> Cheers
> Suresh
>  
> * As a refresher, this is a pointer to a discussion we had in 2008 about the topic
>

---

From: Ralph Droms <[email-masked]>
Date: Mon, 16 Aug 2010 18:34:40 -0400

On Aug 16, 2010, at 2:33 PM 8/16/10, Suresh Krishnan wrote:

> Ack. More work is required and as Jouni said, 3. fits the bill for the additional work required.

Not sure what you're acking.  Ole proposed, as an erratum to RFC 3633, dropping this text from section 12.1:

  with the following exception: the requesting router MUST
  NOT assign any delegated prefixes or subnets from the delegated
  prefix(es) to the link through which it received the DHCP message
  from the delegating router.

and adding text:

   When the DR delegates prefixes to a Requesting Router, the
   Requesting Router has sole authority for assignment of those
   prefixes, and the Delegating Router MUST NOT assign any prefixes
   from that delegated prefix to any of its own links.

These changes fix the problem with the authority over delegated prefixes, but do not provide a way for the DR to signal to the RR that the RR should assign a prefix to the DR-RR link.

> Fully agree. RFC3633 now has the restriction in the wrong place. Placing this restriction on the DR instead of the RR will fully resolve any issues I have.

OK.

>>> Then discussion kind of petered out, seemingly without reaching a conclusion.   Is that about right, or did I miss something?

So one solution would be an explicit option indicating to the RR that it should manage the prefix on the DR-RR link?  I like that better than any kind of heuristic through which the RR tries to deduce its behavior.

- Ralph

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 16 Aug 2010 19:23:25 -0400

On 10-08-16 06:34 PM, Ralph Droms wrote:
> References: <[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<alpine.DEB.1.10.100	[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]> <EEEFC08F-6AF4-4F3A-A811-2C8C5DD9DB9D@employees.
o! rg> <[email-masked]>
> To: Suresh Krishnan <[email-masked]>
> X-Mailer: Apple Mail (2.1078)
> X-Brightmail-Tracker: AAAAAxWWNLgVlt1wFZcTuw=
> X-OriginalArrivalTime: 16 Aug 2010 22:34:44.0235 (UTC) FILETIME=96135B0:01CB3D93]
> 
> 

I was acking Ole that more work (than replacing the MUST with a SHOULD) 
is required :-).

>    from that delegated prefix to any of its own links.

I did propose the same fix earlier on in this thread.

http://www.ietf.org/mail-archive/web/dhcwg/current/msg10975.html

> So one solution would be an explicit option indicating to the RR that it should manage the prefix on the DR-RR link?  I like that better than any kind of heuristic through which the RR tries to ded…

Yes. I also believe that this is the best way forward.

Thanks
Suresh

---

From: Ralph Droms <[email-masked]>
Date: Mon, 16 Aug 2010 19:29:56 -0400

Suresh - just to be clear, replacing MUST with SHOULD is orthogonal to the problem at hand.  The correct fix is to remove all restrictions on the RR and add the appropriate restriction on the DR that the "Delegating Router MUST NOT assign any prefixes from that delegated prefix to any of its own links."  Your suggested text in http://www.ietf.org/mail-archive/web/dhcwg/current/msg10975.html is not exactly the same as Ole's, and I think Ole's is correct.

It *might* be appropriate to add a note to RFC 3633 describing the possibility that the DR and RR might make conflicting prefix assignments on the DR-RR link, but explicit signaling to coordinate DR/RR prefix assignments is beyond the scope of RFC 3633.

- Ralph

On Aug 16, 2010, at 7:23 PM 8/16/10, Suresh Krishnan wrote:

> I was acking Ole that more work (than replacing the MUST with a SHOULD) is required :-).
>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 16 Aug 2010 23:15:29 -0400

>  from the delegating router.

When I read this text, the way it first appeared to me was that it was saying the RR should not do PD on the link on which it got the prefix, but it's not saying that, so I guess my main objection to changing this text goes away.

However, if we add the ability to knock out a /64 from a delegated prefix, the need to relax this restriction goes away--it makes much more sense for the DR to assign the RR an address out of the /64 than it does for the DR to *delegate* the /64 to the RR.

What's the scenario where the RR would get a *delegation* of a /64 and then assign it to the interface on which it received the delegation?   How would that even work?   I think this change is simply unnecessary.

---

From: Ole Troan <[email-masked]>
Date: Tue, 17 Aug 2010 10:46:23 +0200

Ted,

> However, if we add the ability to knock out a /64 from a delegated prefix, the need to relax this restriction goes away--it makes much more sense for the DR to assign the RR an address out of the /…

indeed.

> What's the scenario where the RR would get a *delegation* of a /64 and then assign it to the interface on which it received the delegation?   How would that even work?   I think this change is simp…

this discussion started off by claims that the "MUST NOT assign any..." hindered using a part of a delegated prefix on the DR-RR link. changing the text will not change any behaviour. it is purely a clarification, one that makes it even clearer that authority of the address space is transferred as a part of the protocol. the new "owner" of that prefix should have no restrictions on its use. I think the current text has led to some misunderstandings, which is why I would like to put in the erratum.

you are right in that this will not result in any changes on either RR or DR behaviour. which is why it is an erratum not 3633bis.

cheers,
Ole

---

From: Jyrki Soini <[email-masked]>
Date: Tue, 17 Aug 2010 12:04:25 +0300

On 21:59, Ralph Droms wrote:
> - Ralp

I think that an explicit option is needed, indeed.

On the one hand it is logical that once the prefix is delegated to RR,
it has the sole authority.

On the other hand I find it illogical that RR would assign part of the
prefix for the DR-RR link.
DR would learn which part RR had assigned for DR-RR link only by
receiving RA from RR.
Generally DR is on higher  hierarchy level than RR and it would be more
logical that it would
assign link prefix.

Therefore I would prefer RR to explicitly request DR to assign a /64
prefix for the link and DR to
delegate /48 or /56 or other prefix length EXCEPT /64 assigned to DR-RR
link.
That's what draft-korhonen-dhc-pd-exclude-00 proposes.

The issue is not just 3G network peculiarity but it might also make life
simpler on xDSL/metro-Ethernet network implementations where VLAN per
customer model is used.

--
Jyrki

---

From: Ole Troan <[email-masked]>
Date: Tue, 17 Aug 2010 11:27:40 +0200

> Generally DR is on higher  hierarchy level than RR and it would be more

agree.

> That's what draft-korhonen-dhc-pd-exclude-00 proposes.

I'd rather that the DR decides what and how addressing should be done on the DR-RR link.
the RR should signal support for a prefix -1 option (ORO). the RR should not request a /64 for the RR-DR link. how does it even know that global address is used for the link? the DR decides what prefix(es) to delegate.
the RR does not in any way have to have any coupling with how it acquires an address on it's RR-DR link interface with the prefix delegation process.

cheers,
Ole

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 17 Aug 2010 10:12:01 -0400

Hi Ralph,

> Suresh - just to be clear, replacing MUST with SHOULD is orthogonal to the problem at hand.  The correct fix is to remove all restrictions on the RR and add the appropriate restriction on the DR th…

Removing all restrictions on the RR is fine by me, but the reason I 
requested a SHOULD was that Jinmei pointed out issues with removing it 
altogether in

http://www.ietf.org/mail-archive/web/dhcwg/current/msg09092.html

I have no issues with Ole's text. I think it is correct as well.

> It *might* be appropriate to add a note to RFC 3633 describing the possibility that the DR and RR might make conflicting prefix assignments on the DR-RR link, but explicit signaling to coordinate D…

Agree. This will be the focus of Jouni's draft.

Thanks
Suresh

---

From: Ralph Droms <[email-masked]>
Date: Tue, 17 Aug 2010 10:39:41 -0400

There may certainly be problems if both the DR and the RR assign a prefix to the DR-RR link.  I think Jinmei-san's example can be generalized to problems resulting from automated router configuration that is not communicated to other routers.  Even if the DR advertises the prefix it has assigned to the DR-RR link, the RR won't be aware of the assignment because the RR don't process the RAs from the DR.  Of course, a routing protocol would solve the problem (along with a host of other problems at the boundary between the subscriber and SP admin domains)...

However, the problem is a deployment/provisioning/configuration/mangement problem, and changing:

   the requesting router MUST
   NOT assign any delegated prefixes or subnets from the delegated
   prefix(es) to the link through which it received the DHCP message
   from the delegating router

to "SHOULD NOT" is of scope for this document (and is ineffective at preventing the problem). 

- Ralph
 
On Aug 17, 2010, at 10:12 AM 8/17/10, Suresh Krishnan wrote:

> Removing all restrictions on the RR is fine by me, but the reason I requested a SHOULD was that Jinmei pointed out issues with removing it altogether in
>

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 17 Aug 2010 17:57:25 -0400

Hi Ralph,

> to "SHOULD NOT" is of scope for this document (and is ineffective at preventing the problem). 

I am not sure I understand your intent. Are you saying that changing 
this MUST NOT to a SHOULD NOT is out of scope of the document and is 
ineffective, but removing the text altogether is in scope and will 
prevent the problem?

Thanks
Suresh

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 18 Aug 2010 09:06:12 -0700 (PDT)

I agree with Mikael and Alex.

I don't see anything needed " to make DHCPv6-PD  fit better to the general EPC 
architecture"?

I can understand that there are some new requirements from the emerging M2M 
communication. That's what we should discuss and probably not the requirements 
from the general EPC architecture.

Regards,

Behcet

----- Original Message ----
> From: Mikael Abrahamsson <[email-masked]>
> To: jouni korhonen <[email-masked]>
> Cc: [email-masked]; Alexandru Petrescu <[email-masked]>
> Sent: Wed, August 4, 2010 5:50:39 AM
> I read this and I still don't  understand why the UE needs to assign a prefix 
>to the interface where it got the  PD from (from within the bearer I presume).
> 
> > DHCPv6-PD could work as  usual. The issue what we have with 3633 originates 
>from how the 3GPP bearer/link  model has been defined and some architectural 
>constraints there are. Therefore,  we are looking for this particular 
>"enhancement/relaxation" to make DHCPv6-PD  fit better to the general EPC 
>architecture.
> 
> I've had the introduction to  LTE and how bearers etc work, but I still don't 
>understand why a prefix for that  would have to be handled by the UE router?
> 
> -- Mikael Abrahamsson    email: [email-masked]

---

From: Ralph Droms <[email-masked]>
Date: Wed, 18 Aug 2010 12:32:16 -0400

Sorry for being unclear.  Changing MUST NOT to SHOULD NOT will not fix the problem.  Fixing the problem is out of scope for this document, anyway, because it is a deployment/provisioning/configuration/mangement problem.

Eliminating the text is part of fixing what is wrong with this document, which is that once the DR has delegated a prefix, it has ceded control of that prefix and MUST NOT assign or delegate any subprefix of the delegated prefix.

- Ralph

On Aug 17, 2010, at 5:57 PM 8/17/10, Suresh Krishnan wrote:

> I am not sure I understand your intent. Are you saying that changing this MUST NOT to a SHOULD NOT is out of scope of the document and is ineffective, but removing the text altogether is in scope and will prevent the problem?
> 
> Thanks
> Suresh
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 18 Aug 2010 15:19:56 -0400

> Eliminating the text is part of fixing what is wrong with this document, which is that once the DR has delegated a prefix, it has ceded control of that prefix and MUST NOT assign or delegate any su…

I don't agree that this text should be removed, and am disturbed that there's now an erratum filed on the document that removes the text.   The text serves a necessary purpose, which is to prevent the RR from using the delegated prefix on the upstream link.

I don't understand how removing that text fixes the problem you're referring to.

---

From: Ole Troan <[email-masked]>
Date: Wed, 18 Aug 2010 21:27:37 +0200

Ted,

> I don't understand how removing that text fixes the problem you're referring to.

the text is not removed. it is moved to the delegating router section.

cheers,
Ole

---

From: Ralph Droms <[email-masked]>
Date: Wed, 18 Aug 2010 15:34:08 -0400

Ole - isn;t the sense of the text in the DR section now to put a restriction on the DR not the RR?

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Wed, 18 Aug 2010 15:35:06 -0400

Ted - in my opinion, it is a management/deployment (policy) issue as to what device is responsible for assigning a prefix to the RR-DR link.  Deployment models have been proposed in which the RR assigns a prefix to the RR-DR link have already been proposed.

Upleveling, I'm not quite sure what it actually means to "assign [...] prefixes or subnets from the delegated prefix(es) to the link".  Perhaps choosing an address from a prefix to assign to an interface, or advertising the prefix on the link?

In any event, in my opinion it is out of scope for RFC 3633 to make a policy statement about which of the DR and RR is responsible for the prefix assigned to the RR-DR link.

- Ralph

---

From: Ole Troan <[email-masked]>
Date: Wed, 18 Aug 2010 21:37:32 +0200

> Ole - isn;t the sense of the text in the DR section now to put a restriction on the DR not the RR?

yes, that's correct.

cheers,
Ole

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 18 Aug 2010 16:40:48 -0400

Hi Ralph,

> Sorry for being unclear.  Changing MUST NOT to SHOULD NOT will not fix the problem.  Fixing the problem is out of scope for this document, anyway, because it is a deployment/provisioning/configurat…

I am in complete agreement with this.

> Eliminating the text is part of fixing what is wrong with this document, which is that once the DR has delegated a prefix, it has ceded control of that prefix and MUST NOT assign or delegate any su…

Sounds good.

Thanks
Suresh

---

From: Ted Lemon <[email-masked]>
Date: Wed, 18 Aug 2010 17:19:56 -0400

> In any event, in my opinion it is out of scope for RFC 3633 to make a policy statement about which of the DR and RR is responsible for the prefix assigned to the RR-DR link.

That may or may not be so, but my point is that it simply doesn't make sense for the RR to offer a prefix it received from the DR on the upstream link.   Isn't that what that text was intended to prevent?

---

From: Ralph Droms <[email-masked]>
Date: Wed, 18 Aug 2010 18:21:32 -0400

Ted - seems to me that there may well be deployment scenarios in which the RR decides on the RR-DR prefix.  It's a policy decision, which shouldn't be in an update to RFC 3633.

BTW, filing an erratum is only the first step of the process.  The erratum is reviewed by the Appropriate Experts before it is approved for publication.

- Ralph

---

From: <[email-masked]>
Date: Thu, 19 Aug 2010 23:46:49 +0200

Hi,

I wish to ensure people are clear that the problem we have in 3GPP EPC is not fixed by allowing RR to assign a prefix to its uplink, because a prefix must be allocated to RR's uplink even before RR is requesting any (i.e. a /64 is allocated with SLAAC before RR asks for prefix delegation).

I agree fix for that should be on separate specification (as we propose).

Best regards,

Teemu

> Of ext Ralph Droms
> Sent: 19. elokuuta 2010 01:22
> To: Ted Lemon
> Cc: DHC Group Working; [email-masked]
> Subject: Re: [dhcwg] Relaxing text in RFC3633 [recap]
> 
> Ted - seems to me that there may well be deployment scenarios in which
> the RR decides on the RR-DR prefix.  It's a policy decision, which
> shouldn't be in an update to RFC 3633.
> 
> BTW, filing an erratum is only the first step of the process.  The
> erratum is reviewed by the Appropriate Experts before it is approved
> for publication.
> 
> - Ralph
> 
> >> In any event, in my opinion it is out of scope for RFC 3633 to make
> a policy statement about which of the DR and RR is responsible for the
> prefix assigned to the RR-DR link.
> >
> > That may or may not be so, but my point is that it simply doesn't
> make sense for the RR to offer a prefix it received from the DR on the
> upstream link.   Isn't that what that text was intended to prevent?
> >
>