RE: [dhcwg] Comments on 22 rev of the draft

"Bernie Volz (EUD)" <> Sat, 19 January 2002 14:49 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id JAA19504 for <>; Sat, 19 Jan 2002 09:49:02 -0500 (EST)
Received: (from daemon@localhost) by (8.9.1a/8.9.1) id JAA08469 for; Sat, 19 Jan 2002 09:49:06 -0500 (EST)
Received: from (localhost []) by (8.9.1a/8.9.1) with ESMTP id JAA08427; Sat, 19 Jan 2002 09:43:09 -0500 (EST)
Received: from (odin []) by (8.9.1a/8.9.1) with ESMTP id JAA08398 for <>; Sat, 19 Jan 2002 09:43:08 -0500 (EST)
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id JAA19453 for <>; Sat, 19 Jan 2002 09:42:40 -0500 (EST)
Received: from ( []) by (8.11.3/8.11.3) with ESMTP id g0JEggh29018 for <>; Sat, 19 Jan 2002 08:42:42 -0600 (CST)
Received: from eamrcnt749 ( []) by (8.11.3/8.11.3) with SMTP id g0JEggf21532 for <>; Sat, 19 Jan 2002 08:42:42 -0600 (CST)
Received: FROM BY eamrcnt749 ; Sat Jan 19 08:42:41 2002 -0600
Received: by with Internet Mail Service (5.5.2653.19) id <ZP0QT4F8>; Sat, 19 Jan 2002 08:42:41 -0600
Message-ID: <66F66129A77AD411B76200508B65AC69B4CDC1@EAMBUNT705>
From: "Bernie Volz (EUD)" <>
To: 'Vijay Bhaskar A K' <>
Subject: RE: [dhcwg] Comments on 22 rev of the draft
Date: Sat, 19 Jan 2002 08:42:41 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A0F7.8C4FF0A0"
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <>


I've cut out much of the text to avoid the delays due to the size of the messages.

See my comments as BV3.

> BV2> Again, all the server does is use the address to determine the LINK.
> So, the server needs to know about the site local prefix being active on
> the link but that's all. If the server fails to find the prefix for the
> address, it can either drop the request or it could simply assume it must
> have come from the LINKs associated with the interface the packet was
> received on. So, it is happy.
> Note that the client really should be using the link local address UNLESS
> it is unicasting to a server (in which case it must use an address of
> sufficient scope valid for the server to send replies). The All DHCP
> Agents address is link scoped, so the source address only needs to be
> linked scoped as well.
> So, I don't see any issues here. Or am I failing to understand your concern?

VB2> What i mean is, for  finding  the  link,  server  should  not trust
client.  It  knows  the  link  where it is  received.  Based  on its own
address  in the link, it should  allocate  address  to the  client.  The
client may not be  knowing  where it is.  Sometimes,  what it has may be
wrong.  So, the src address in IP datagram may show wrong information.

VB2> Assume,  a client is moving from the 3ffe::/64 network to 5ffe::/64
network.  As per the draft, it will the  confirm  message.  16.2.2  says
that, the server will just compare the binding info it's having with the
one in confirm  message.  I think the server MUST check the prefix also.
It must  check  whether  the  addresses  in the IA are  having  the same
prefixes of the link in which the client is  connected  to.  I think, no
where in the draft, the draft is not dealing with the prefix  comparison
of the link and IA  addresses.  So, in this  case,  the  server  sends a
positive  reply.  The client wont get it,  because, it does have a valid
address to receive it.

VB2> After some time, if it requires another address, it will send a new
request with the src address with 3ffe::/64  prefix and hence the server
allocates the address with 3ffe::/64  prefix for the 5ffe::/64  network.
I think the neat and clean way of client  asking for the  addresses in a
particular  prefix,  is sending  through  an option,  similar  to subnet
selection  option  (RFC 3011).  I can include the text for this  option.
This is one of the  option,  i have  forgetten  to tell in the  previous


BV3> You are forgetting ONE case ... what if the client was allowed to
unicast to the server. In that case, we really do need to use the address
supplied by the client as that is the only way the server can determine
were the client is.

And you are not considering the rules for the source address that the
client is supposed to be using. So, if we assume clients are playing by
the rules (which they MUST IMHO), you have the following possibilities:
1) The client is communicating via a relay agent. In that case things are
easy since the server receives a Reply-Forw.
2) The client is on the local link (and NOT unicasting), in that case
the client's address MUST be the link-local address and the server uses
the interface on which the request was received.
3) The client is UNICASTING because the server has allowed it to do so.
In that case, the server MUST use the client's source address to determine
the address. The client MUST also use a source address that is of sufficient
scope to reach the server. Ideally, this should be a global address as that
avoids any issues with the client moving to a new link (since global addresses
are "valid" anywhere). In this case you also don't have any problems because
if the client has moved to a new link, it should be sending a CONFIRM which
is *NOT* unicast.

So, I don't see why there are any cases where there are problems if the
client follows the rules I've outlined above (which I believe was our intent).

I've already indicated that we should clean up the language in the draft
that says a client MUST use the link-local unless it is UNICASTING to a server.

BTW, I haven't checked the source address selection draft out lately, but it
was my understanding that if a sender is sending to a link-local address (such
as the All DHCP Agents Multicast) that it should also use a link-local address
as the source address (since there is no reason not to).

- Bernie Volz