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

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Sat, 19 Jan 2002 08:42:41 -0600

Vijay:

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
mail.

----

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

---

From: "Vijayabhaskar A K" <[email-masked]>
Date: Sun, 20 Jan 2002 23:44:57 +0530

RE: [dhcwg] Comments on 22 rev of the draftHi Bernie,
See my reply inline prefixed by VB3>
  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.

  VB3> This is where the problem arises. If the client network
  has two prefixes, 3ffe::/64 and 5ffe::/64 and the client wants
  the address with 3ffe::/64 prefix, it has not the flexibility of
  choosing the source address. The source address selection
  algorithm may choose any address. It is based on the destination
  address. If the destination address (server addr) is 5ffe::/64,
  then the source address selection chooses the source address
  from 5ffe::/64 only. So, the subnet selection option is the only
  way of indicating the client's wish of the prefix.
  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).

  VB3> I am sure that global address is unique over the world, but i am not
sure,
  whether it is valid anywhere. I am not sure, whether the host with
  subnet preifx 3ffe::/64 moved to 5ffe::/64, will be able to receive the
  packet with destined to its 3ffe::/64 address.
   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.

  VB3> Regarding the confirm, i have few doubts.
  - draft says that, when the client moves to new link, it has to send
confirm
  message. How can the host identify it has moved to a new network?
  Are we taking care of ICMP error messages?
  - Link local address is unique within the link. When a node is moved
  from one link to another one, we cannot surely say that the link local
  address is unique. What will happen, the link local address of the
  interface is used by some other node in that link?
  - since, this address is the one, which has to be used as source address
for confirm,
  does the client has to do a ND first for confirming uniqueness within the
link?

  VB3> As i told earlier, a text has to be added for checking whether the
addresses
  in the IA has the same prefix as that of the link it resides, when confirm
message
  is received in the server. Otherwise, the confirm will get a positive
reply from the
  server, resulting in defeat of the purpose of confirm.

  VB3> Here, i have another doubt. Assume the following scenario.
  Assume the Relay agent has addresses from two prefix A and B
  in the link attached to the client. Client has some addresses of
  prefix A. It has  been rebooted now. So, it sends the confirm packet.
  The confirm is received in the relay agent's interface. Now, what
  prefix it has to put in the link-address field. If it chooses to put B,
  then the addresses assigned to client becomes invalid. In what
  basis, the Relay agent chooses the prefixes, if the interface
  attached to the client's link has more than one prefixes?