Re: [dhcwg] additional option for dhcpv6

Vijay Bhaskar A K <> Wed, 23 January 2002 16:47 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id LAA15866 for <>; Wed, 23 Jan 2002 11:47:18 -0500 (EST)
Received: (from daemon@localhost) by (8.9.1a/8.9.1) id LAA04086 for; Wed, 23 Jan 2002 11:47:21 -0500 (EST)
Received: from (localhost []) by (8.9.1a/8.9.1) with ESMTP id LAA03534; Wed, 23 Jan 2002 11:32:35 -0500 (EST)
Received: from (odin []) by (8.9.1a/8.9.1) with ESMTP id LAA03509 for <>; Wed, 23 Jan 2002 11:32:32 -0500 (EST)
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id LAA15185 for <>; Wed, 23 Jan 2002 11:32:29 -0500 (EST)
Received: from ( []) by (Postfix) with ESMTP id 1EC51E003DC; Wed, 23 Jan 2002 11:32:00 -0500 (EST)
Received: (from vijayak@localhost) by (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id WAA03344; Wed, 23 Jan 2002 22:06:17 +0530 (IST)
From: Vijay Bhaskar A K <>
Message-Id: <>
Subject: Re: [dhcwg] additional option for dhcpv6
Date: Wed, 23 Jan 2002 22:06:16 +0530 (IST)
In-Reply-To: <> from Mark Stapp at Jan "21, " 2002 "09:44:31" am
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

> Vijay,
> 1) FQDN Option. I really think that we should use a single option that can 
> convey both a complete FQDN or a partial 'hostname'. It's unnecessary to 
> try to specify two options and the relationship between them. Certainly, 
> there's no need to include the RCODE fields that were part of the v4 FQDN 
> option: like the two name encodings in the v4 version, those fields were 
> left in place because there was a large base of deployed clients who 
> expected those fields to be present. I'd suggest that we specify the same 
> method that's used in the v4 option to distinguish between fully-qualified 
> and unqualified names: if the last label in the name field is null-length, 
> the name is fully-qualified. If a client believes it knows a complete FQDN, 
> it sends that name and terminates it accordingly. If it only knows a 
> partial name, it sends the labels it knows.

Agreed.  But, i feel that,  insteading  of discussing  now on the fields
needed for FQDN  option, we can finalise  the DDNS updates and then come
back to format definition for FQDN option.

> >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.
> I think that the specification must be clear about the behavior that the 
> paragraph in your reply describes. The server MAY consider the subnet 
> specified as it considers the other information available to it about its 
> allocation policies and about the client.

I will include whatever i have explained in the text for this option.

> > >
> > > 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.
> There are so many examples of the field len/field value convention that I 
> think it's much clearer to continue using that convention unless there's a 
> very good reason not to. I don't think that there is such a reason in this 
> case, and I think that it will make the specification and implementation of 
> this option more robust if we retain that convention.

I assumed  SLP DA address  and scope list as data, i didn't  want put an
len field in between.


dhcwg mailing list