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

["Vijayabhaskar A K" <[e-mail]>]

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?