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

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Mon, 21 Jan 2002 01:28:33 -0600

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:[email-masked]]
Sent: Sunday, January 20, 2002 1:15 PM
To: 'Bernie Volz (EUD)'
Cc: [email-masked]; [email-masked]
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.

---

From: Vijay Bhaskar A K <[email-masked]>
Date: Wed, 23 Jan 2002 21:41:10 +0530 (IST)

> the relay always supplies the correct prefix or configure the DHCPv6 server to know about

No, both the server and relay  knows  about both  prefixes A and B.  The
problem here is, choosing the prefix.  If the relay's  link  attached to
the  client has both the  prefixes,  the what will the relay  choose?  I
feel like, here the subnet  selection option is really needed.  This can
be useful in two ways.

i) the client can says its prefered prefix in the SOLICIT/REQUEST message.
ii) it can say  about  the  prefix  it was  allocated  to it in  Confirm
meessage.  This  prefix  (say  3ffe::/64)  will  be  compared  with  the
prefixes in the relay's  link  attached to the client.  If the relay has
addresses  with 2 prefixes  3ffe::/64  and  5ffe::/64  in the  interface
attached to client's link, then it puts the  link-address  as 3ffe::/64.
This info will be used by server to check whether the client  resides in
the valid link.

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Wed, 23 Jan 2002 18:12:02 +0100

What possible use can there be in allowing the client to select the prefix 
that it wants?   DHCP clients are intended to arrange for ad-hoc 
connections.   Under what circumstances would the client have any knowledge 
of what prefixes might be better than others?

---

From: Vijay Bhaskar A K <[email-masked]>
Date: Thu, 24 Jan 2002 00:10:27 +0530 (IST)

> that it wants?   

Please go through the follow scenario.  Router is advertising  3ffe::/64
prefix and a host has generated an address of prefix  3ffe::/64  using
router  advertisements.  Now, the host  needs  some  more  addresses  of
prefix  3ffe::/64.  It chooses to use stateful  autoconf  (dhcpv6).  The
server  sends  advertise  saying  that,  it can  allocate  addresses  in
3ffe::/64  and  5ffe::/64.  Since,  the  client's  wish  is to get  only
3ffe::/64,  it can tell the server its  preference  for the prefix while
sending  Request.  This will help in server not allocating the addresses
that the client doesn't want.

Moreover, if the client wants to communicate  with the external site, it
requires  global  rather  than site local  addresses.  Here also, it can
show the preference.

DHCP clients are intended to arrange for ad-hoc 
> of what prefixes might be better than others?

Obviosuly, the client using the stateless  autoconf,  knows the prefixes
in the link, (by router advertisements).  From the Advertise messages of
the various servers, it knows about the prefixes in the link.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 23 Jan 2002 21:17:51 +0100

> Router is advertising  3ffe::/64
> prefix  3ffe::/64.

Why would the client want to do this?   What mechanism would cause the 
client to do this?

> It chooses to use stateful  autoconf  (dhcpv6).  The
> 3ffe::/64  and  5ffe::/64.

Unless I misunderstand the DHCPv6 draft, this is _not_ how it works.   The 
server allocates addresses for the client.   The client can ask for 
temporary addresses, but otherwise it simply takes what the server offers.
    There's no either-or proposition here - the server offers what it offers,
  and the client takes all of it.   There is no reason why the client should 
need to pick and choose - if the server says it will give the client 
addresses on both these networks in the DHCP Advertise message, then when 
the client sends a DHCP Request message, the DHCP server will in fact give 
the client addresses on both these networks.   AFAIK it is not intended in 
the draft that the client either need to nor be able to pick and choose 
among addresses within an IA.

> the various servers, it knows about the prefixes in the link.

This is not only not true, but it doesn't answer the question I asked.   
Unless I am dreadfully mistaken, there is no requirement that there be a 
router on a link in order for IPv6 networking to function.   And the 
question was not "how does the client know what prefixes are available on 
the link," but rather, "on what basis would the client want to choose 
between such prefixes?"

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 24 Jan 2002 10:28:50 +0100

--On Donnerstag, Januar 24, 2002 00:10:27 +0530 Vijay Bhaskar A K 
<[email-masked]> wrote:

>> What possible use can there be in allowing the client to select the
>> prefix  that it wants?
>

The client has nothing to choose! When the IPv6 router says in his router 
advertisements "use stateless autoconfiguration" (Flags in router 
advertisement are M=0, O=0), the client has to use stateless 
autoconfiguration, i.e. form an IPv6 address with the advertised prefix. 
When the router says "use stateful autoconfiguration" (Flags in router 
advertisement are M=1, O=1), the client has to use stateful 
autoconfiguration, i.e. request an IPv6 address from a DHCPv6 server. See 
RFC 2641, section 4.2, and RFC 2462, section 5.2.

We can't change the base IPv6 specification for DHCPv6.

>> connections.   Under what circumstances would the client have any
>> knowledge  of what prefixes might be better than others?
>

Martin Stiemerling

NEC Europe Ltd. -- Network Laboratories      [email-masked]
IPv4: http://www.ccrle.nec.de             IPv6: http://www.ipv6.ccrle.nec.de

---

From: Jim Bound <[email-masked]>
Date: Thu, 24 Jan 2002 08:46:46 -0500 (EST)

Martin,

It is permissable to get addresses from stateless and stateful in IPv6
addr conf.  

/jim

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 24 Jan 2002 17:21:54 +0100

> It is permissable to get addresses from stateless and stateful in IPv6
Jim,

Where is this specified?

Martin