Subject: prefix length in dhcpv6-15

From: Stig Ven�s <[email-masked]>
Date: Thu, 10 Aug 2000 16:30:48 +0200

Hi

I'm reading through draft-ietf-dhc-dhcpv6-15.txt, the issues I have
so far are:

The text says implisitly that the prefix-len field in the solicit
message sent by a client is 0, but I think it should be stated
more clearly.

In 10.3.3 it says:

   Once a client has selected Advertise message(s), the client will
   typically store information about each server, such as relay address
   and prefix length, server preference value, networks advertised,
   when the advertisement was received, and so on.  Depending on the
   requirements of the client's invoking user, the client MAY initiate a
   configuration exchange with the server(s) immediately, or MAY defer
   this exchange until later.

I don't see how the client knows the prefix length, and I can't see
why it would store it either.

Stig

-- 
Stig Venaas
UNINETT

---

From: Francis Dupont <[email-masked]>
Date: Thu, 10 Aug 2000 18:07:46 +0200

In your previous mail you wrote:

=> the prefix-len stuff is buggy but not for this reason.

=> 10.3.1. begins with a zeroed buffer then as the client doesn't set
the prefix-len field it sends the solicit with a zero prefix-len...

   In 10.3.3 it says:
   
      Once a client has selected Advertise message(s), the client will
      typically store information about each server, such as relay address
      and prefix length, server preference value, networks advertised,
      when the advertisement was received, and so on.
   
   I don't see how the client knows the prefix length,

=> agree

   and I can't see why it would store it either.

=> the prefix-len is supposed to be used in order to recognize
the link of off-link clients. This doesn't work because:
 - only the solicit message has a prefix-len client
 - if a prefix-len field is added in request messages then
   it should be added in advertisements too (your point), etc.
 - servers don't create/keep/... a database entry when they receive
   a solicit (they do this when they receive a request) then
   the prefix-len is not in messages used for database lookups...

My proposal is to replace the prefix + prefix-len by the link for
the database key (the other part of the key is the client link-local
address).
There are two kinds of links:
 - directly attached links (with on-link clients): the link is determined
   by the interface from which the packet was received.
 - not directly attached links (with off-link clients): the configuration
   file gives the list of the subnets of the link and the server finds
   a subnet (then a link) which matches with the relay address.
The last point fails only when:
 - there are multi-link subnets (this is explicitely not supported,
   a statement will be added in the non-goal section, and there is no
   IPv6 multi-link subnets today then it doesn't matter).
 - an address can match more than one subnet, I think this is a nice case
   of configuration error (ie. this should never happen).
A prefix-len can speed up subnet matching but is not necessary then
my proposal (IMHO) is only simpler and less confusing.
(a subnet is specified by a prefix, ie. <address>/<d>, 0 <= d <= 128,
the 128-d last bits of the address should be zeroed. Matching is done
by the comparison of the d first bits, with a prefix-len matching begins
by the check of equality with d (faster on the paper, don't forget than
the prefix-len will be almost always 64 :-)).

Regards

[email-masked]