Subject: Re: [dhcwg] DHCPv6 Stateful Prefix Length

From: Alain Durand <[email-masked]>
Date: Mon, 01 Oct 2007 08:43:34 -0400

On 9/30/07 9:52 AM, "Hemant Singh (shemant)" <[email-masked]> wrote:

> Alain,
>  
> What indication does DHCPv6 is its current form provide to a host to determine
> on-link? Nothing! All DHCPv6 provides is an address, not prefix length. That
> is why we said what we said in our draft.
> 
> ==> agreed, this is why I¹m proposing to add the prefix len option.
>  
> Do also note ND clearly says in the PIO (Prefix Information Option) definition
> section (4.6.2) that even prefix length is not enough to make an on-link
> determination. Prefix length has to be combined with the L-bit in PIO to make
> an on-link determination.
> 
> 
> ==> see my previous email. If things can be off-link, just do not use the
> prefix len option and send everything to the local router.
>  
> It's a soup if ND and RA use both prefix length and L-bit in PIO to make
> on-link determination while your new suggested DHCPv6 prefix length option is
> used alone to make on-link determination. Then as Bernie said, you will have
> to bring more and more of PIO into DHCPv6 for options. Bernie has also argued
> in IETF IPv6 mailer that once both ND RA and DHCPv6 start doling out the same
> options and if a host receives conflicting information, which of DHCPv6 or ND
> options win?
> 
> ==> This is no different from having 2 routers on the link sending conflicting
> RAs
> 
>  
> I think I appreciate your problem, but not the solution. We just spent the
> last 10 years with ND and DHCPv6 in their current shape and form where by
> design DHCPv6 does nor provide any information to make an on-link
> determination and it's the router an ND's RA that provides the on-link
> information. Given this fundamental design, one cannot just change DHCPv6
> without upsetting or introducing a bug in ND. I already mentioned one bug in
> my first reply to this thread where an RA with no PIO wanted host to send
> traffic to router while host sees a DHCPv6 option with prefix length and your
> option told the host to use say, a /64 for on-link determination - this host
> could send NS when the host was signaled by ND that all non-link-local
> destinations are off-link.

* ==> we have spend 10 years talking about DHCPv6 without any real
deployment feedback. Now, this feedback is coming,please don¹t ignore it

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

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 1 Oct 2007 20:46:58 -0400

Alain,
 
Your problem of millions of DHCPv6 clients for which you want to
configure multiple prefixes per link on an aggregator is something that
can be supported using configuration on a DHCPv6 server and associated
provisioning systems and SAS (Source Address Selection) on the DHCPv6
clients. 
 
Like Tatuya said,  I will wait for the draft some folks are coming out
with and let's see where their reasons are - one document is always
better for review than folks discussing an issue in countless emails. We
will review those reasons with a fine tooth and comb.  It is a good time
to also ask on ETA of this impending draft.
 
Hemant

________________________________

From: Alain Durand [mailto:[email-masked]] 
Sent: Monday, October 01, 2007 8:44 AM
To: Hemant Singh (shemant); Bernie Volz (volz); David W. Hankins; DHC WG
Subject: Re: [dhcwg] DHCPv6 Stateful Prefix Length

	Alain,
	
	What indication does DHCPv6 is its current form provide to a
host to determine on-link? Nothing! All DHCPv6 provides is an address,
not prefix length. That is why we said what we said in our draft.
	
	==> agreed, this is why I'm proposing to add the prefix len
option.
	
	Do also note ND clearly says in the PIO (Prefix Information
Option) definition section (4.6.2) that even prefix length is not enough
to make an on-link determination. Prefix length has to be combined with
the L-bit in PIO to make an on-link determination.

	==> see my previous email. If things can be off-link, just do
not use the prefix len option and send everything to the local router.
	
	It's a soup if ND and RA use both prefix length and L-bit in PIO
to make on-link determination while your new suggested DHCPv6 prefix
length option is used alone to make on-link determination. Then as
Bernie said, you will have to bring more and more of PIO into DHCPv6 for
options. Bernie has also argued in IETF IPv6 mailer that once both ND RA
and DHCPv6 start doling out the same options and if a host receives
conflicting information, which of DHCPv6 or ND options win?
	
	==> This is no different from having 2 routers on the link
sending conflicting RAs

	I think I appreciate your problem, but not the solution. We just
spent the last 10 years with ND and DHCPv6 in their current shape and
form where by design DHCPv6 does nor provide any information to make an
on-link determination and it's the router an ND's RA that provides the
on-link information. Given this fundamental design, one cannot just
change DHCPv6 without upsetting or introducing a bug in ND. I already
mentioned one bug in my first reply to this thread where an RA with no
PIO wanted host to send traffic to router while host sees a DHCPv6
option with prefix length and your option told the host to use say, a
/64 for on-link determination - this host could send NS when the host
was signaled by ND that all non-link-local destinations are off-link.

*	==> we have spend 10 years talking about DHCPv6 without any real
deployment feedback. Now, this feedback is coming,please don't ignore it

   - Alain.

---

From: Alain Durand <[email-masked]>
Date: Mon, 01 Oct 2007 21:41:28 -0400

Hemant,

This list is NOT the place to discuss how we should or should not run our
networks. The problem I described is larger than the one you think you are
trying to solve for me. This is about sharing a link with different
populations that should not see each other at layer 3, regardless of the
underlying layer 2 technology.

That said, I agree that this discussion will benefit from some kind of
problem statement. I'm going to find some cycles to put a draft together.
If somebody would like to join me in this effort, please contact me offline.

   - Alain.

On 10/1/07 8:46 PM, "Hemant Singh (shemant)" <[email-masked]> wrote:

> Alain,
>  
> Your problem of millions of DHCPv6 clients for which you want to configure
> multiple prefixes per link on an aggregator is something that can be supported
> using configuration on a DHCPv6 server and associated provisioning systems and
> SAS (Source Address Selection) on the DHCPv6 clients.
>  
> Like Tatuya said,  I will wait for the draft some folks are coming out with
> and let's see where their reasons are - one document is always better for
> review than folks discussing an issue in countless emails. We will review
> those reasons with a fine tooth and comb.  It is a good time to also ask on
> ETA of this impending draft.
>  
> Hemant
> 
> 
>> What indication does DHCPv6 is its current form provide to a host  to
>> determine on-link? Nothing! All DHCPv6 provides is an address, not prefix
>> length. That is why we said what we said in our draft.
>> 
>> Do also note ND clearly says in the PIO (Prefix Information Option)
>> definition section (4.6.2) that even prefix length is not enough to make an
>> on-link determination. Prefix length has to be combined with the L-bit in PIO
>> to make an on-link determination.
>> 
>> 
>> ==> This is no different from having 2  routers on the link sending
>> conflicting RAs
>> 
>>  
> * ==> we have spend 10 years talking about  DHCPv6 without any real deployment
> feedback. Now, this feedback is  coming,please don¹t ignore it
> 
> 
>    - Alain.