Re: [dhcwg] additional option for dhcpv6

Vijay Bhaskar A K <> Sun, 20 January 2002 14:36 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id JAA10927 for <>; Sun, 20 Jan 2002 09:36:01 -0500 (EST)
Received: (from daemon@localhost) by (8.9.1a/8.9.1) id JAA18022 for; Sun, 20 Jan 2002 09:36:06 -0500 (EST)
Received: from (localhost []) by (8.9.1a/8.9.1) with ESMTP id JAA17965; Sun, 20 Jan 2002 09:30:47 -0500 (EST)
Received: from (odin []) by (8.9.1a/8.9.1) with ESMTP id JAA17936 for <>; Sun, 20 Jan 2002 09:30:46 -0500 (EST)
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id JAA10868 for <>; Sun, 20 Jan 2002 09:30:38 -0500 (EST)
Received: from ( []) by (Postfix) with ESMTP id 6D112E00CAD; Sun, 20 Jan 2002 06:30:06 -0800 (PST)
Received: (from vijayak@localhost) by (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id UAA22474; Sun, 20 Jan 2002 20:04:24 +0530 (IST)
From: Vijay Bhaskar A K <>
Message-Id: <>
Subject: Re: [dhcwg] additional option for dhcpv6
Date: Sun, 20 Jan 2002 20:04:24 +0530 (IST)
In-Reply-To: <> from Mark Stapp at Jan "18, " 2002 "05:07:29" pm
X-Mailer: ELM [$Revision: $]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <>
Content-Transfer-Encoding: 7bit


Thanks for your thorough review. See my comments inline.

~ Vijay

> 1) The FQDN option needs, I think, to look a lot like the FQDN option for 
> dhcpv4. 

The option i defined here is, for just  transfering the FQDN releated to
temporary  address.  It is  similar  to  hostname  option in  DHCPv4.  I
will rename it to hostname  option.  I feel like, since the DDNS updates
are still TBD, we can define the FQDN  option  with  appropriate  fields
needed later, once DDNS specs are finalised.

> The name encoding must be specified. 

Yes. It is needed. I will add the appropriate text.

> There needs to be 
> specification about hosts who do not initially know their entire fqdn.
> There needs to be a way to communicate about which party (if any) will be 
> updating DNS. It's probably on my plate to produce that, actually.

For the  temporary  addresses,  DNS update is done by server.  So, these
fields are not necessary.

> 2) The subnet-selection option text should not compel the server to somehow 
> obey the client's suggestion. It should be explict that the server 
> administrator's configuration takes precedence, and that the client's 
> indication that it desires a specific subnet can only be a hint that's 
> considered along with all of the other information available to the server.

This is the only way the client can tell its  prefernce  for the prefix.
If the server is not supposed to allocate  address for that prefix, then
it wont.  If the  client is not very  particular  about the  prefix,  it
should not use this  option.  This  option  will be more  helpful in the
network with two prefixes and the client wants a particular one.

> A nit: isn't the option-len sufficient to determine the prefix length? Is 
> the prefix-len byte necessary?

No, it is not sufficient.  Without the prefix-len field, you cannot find
out the exact prefix length.  For example, you can identify  whether the
prefix  length  is  between  57 and 64.  You  cannot  find out the exact
prefix length.

> 3) The encoding for the domain names in the NIS and NIS+ Domain Name 
> options should be DNS encoding, shouldn't it? That seems more robust than 
> ASCII to me.


> 4) The 'Service Location Protocol Directory Agent Option' places the 
> 'typed-scope-list-len' field before the 'DA address', rather than before 
> the 'typed scope list'. Couldn't the length of the list immediately precede 
> the list?

I think,  it won't  make any  difference.  Let me  know, if there are any
serious issues on this.

dhcwg mailing list