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

["Bernie Volz (EUD)" <[e-mail]>]

Vijay:
 
How a client determines it has (possibly) moved to a new link is a client issue. If you're using wired Ethernet, the client can easily detect when the cable is disconnected/reconnected. If a client powers on (from Standby, etc), it should assume it MAY have moved to a new link and Confirm.
 
The DHCP server, as in IPv4, needs complete network configuration information. If you don't provide it all of the information it needs to operate, it will not be able to service clients successfully. This is true in IPv4 today and if you have multiple prefixes active on a single link, you need to tell the DHCP server this.
 
See below (prefixed by BV4>).
 
- Bernie

-----Original Message-----
From: Vijayabhaskar A K [mailto:[e-mail]]
Sent: Sunday, January 20, 2002 1:15 PM
To: 'Bernie Volz (EUD)'
Cc: [e-mail]; [e-mail]
Subject: RE: [dhcwg] Comments on 22 rev of the draft


Hi 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. 
 
BV4> The client has to Confirm the address when it detects that it may have moved. 

 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? 
 
BV4> See above.
 
- 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?  
 
BV4> How the link local address is determined is controlled by Stateless Autoconfiguration.
If a client believes the link has changed, it should take steps to make sure that the link-local
address it wants to use (was using) is still valid and not duplicated.
 
- 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? 
 
BV4> Only a valid link local address (per stateless autoconfiguration) may be used. 
 
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?
 
BV4> You have misconfigured your DHCP environment. Fix the configuration so that either
the relay always supplies the correct prefix or configure the DHCPv6 server to know about
both prefixes.