Subject: [dhcwg] Relaxing text in RFC3633

From: Suresh Krishnan <[email-masked]>
Date: Thu, 29 Jul 2010 06:45:06 -0400

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: Thu, 29 Jul 2010 13:05:44 +0200

"SHOULD NOT" allows an RR to do the assignment when it would be inappropriate.

- Ralph

On Jul 29, 2010, at 12:45 PM 7/29/10, Suresh Krishnan wrote:

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

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 29 Jul 2010 07:20:08 -0400

Hi Ralph,
 
> -----Original Message-----
> From: Ralph Droms [mailto:[email-masked]] 
> Sent: Thursday, July 29, 2010 1:06 PM
> To: Suresh Krishnan
> Cc: DHC Group Working
> Subject: Re: [dhcwg] Relaxing text in RFC3633
> 

Agree. But the goal is that the SHOULD NOT allows an exception for the cases where IT IS appropriate, while the MUST NOT allows no such leeway. I see this is as the very essence of SHOULD NOT ("Don't do this unless you really know what you are doing").

Thanks
Suresh

---

From: Ole Troan <[email-masked]>
Date: Thu, 29 Jul 2010 13:48:24 +0200

Suresh,

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

OK, so this is slightly different from what I understood during the dhc meeting.
is the RR assigning the prefix to it's WAN side interface, i.e. not using SLAAC and there is no RA being advertised to the RR on that interface including that prefix?

as long as the whole prefix is under full control of the RR I have no problem with relaxing the MUST.

the reason for the MUST, if I remember correctly, was to avoid the situation where the DR "stole" a /64 of the delegated prefix and used for the linknet between DR and RR. we might remove the MUST and potentially add some more text about how routing should work in a PD scenario. e.g the delegated router must have a route for the delegated prefix with a next-hop being the link-local address of the RR.

cheers,
Ole

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 29 Jul 2010 12:05:38 -0400

Hi Ole,

> From: Ole Troan [mailto:[email-masked]] On Behalf Of 
> Ole Troan
> Sent: Thursday, July 29, 2010 1:48 PM
> To: Suresh Krishnan
> Cc: [email-masked]
...
> is the RR assigning the prefix to it's WAN side interface, 
> i.e. not using SLAAC and there is no RA being advertised to 
> the RR on that interface including that prefix?
> 
> the reason for the MUST, if I remember correctly, was to 
> avoid the situation where the DR "stole" a /64 of the 
> delegated prefix and used for the linknet between DR and RR. 
> we might remove the MUST and potentially add some more text 
> about how routing should work in a PD scenario. e.g the 
> delegated router must have a route for the delegated prefix 
> with a next-hop being the link-local address of the RR.

Agree. Such a limitation on a DR makes perfect sense. But the
above stated limitation on the RR, not so much. I agree that we
need to carefully consider the operation of and the impacts on
the DR. Something like this text would be perfectly acceptable.

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

Thanks
Suresh

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 30 Jul 2010 11:16:54 +0200

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

I thought we decided we can't use the fix where the phone gets the /56
and puts a /64 on the upstream link (even if we figured out how to
signal to the phone that it is appropriate to do this)?

-- 
David W. Hankins	BIND 10 needs more DHCP voices.
Software Engineer		There just aren't enough in our heads.
Internet Systems Consortium, Inc.		http://bind10.isc.org/