RE: [dhcwg] Comments on 22 rev of the draft
"Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se> Mon, 21 January 2002 07:37 UTC
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02168 for <dhcwg-archive@odin.ietf.org>; Mon, 21 Jan 2002 02:37:57 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA23988 for dhcwg-archive@odin.ietf.org; Mon, 21 Jan 2002 02:37:59 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA23423; Mon, 21 Jan 2002 02:29:11 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA23347 for <dhcwg@optimus.ietf.org>; Mon, 21 Jan 2002 02:29:07 -0500 (EST)
Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02001 for <dhcwg@ietf.org>; Mon, 21 Jan 2002 02:29:03 -0500 (EST)
Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g0L7SaS09076 for <dhcwg@ietf.org>; Mon, 21 Jan 2002 01:28:36 -0600 (CST)
Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g0L7Saf06140 for <dhcwg@ietf.org>; Mon, 21 Jan 2002 01:28:36 -0600 (CST)
Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Mon Jan 21 01:28:35 2002 -0600
Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <ZP0Q47D5>; Mon, 21 Jan 2002 01:28:34 -0600
Message-ID: <66F66129A77AD411B76200508B65AC69B4CDC9@EAMBUNT705>
From: "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se>
To: "'vijayak@india.hp.com'" <vijayak@india.hp.com>
Cc: dhcwg@ietf.org
Subject: RE: [dhcwg] Comments on 22 rev of the draft
Date: Mon, 21 Jan 2002 01:28:33 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A24D.3B39A6A0"
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org
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:vijayak@india.hp.com] Sent: Sunday, January 20, 2002 1:15 PM To: 'Bernie Volz (EUD)' Cc: dhcwg@ietf.org; vijayak@india.hp.com 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.
- [dhcwg] Comments on 22 rev of the draft Vijay Bhaskar A K
- RE: [dhcwg] Comments on 22 rev of the draft Bernie Volz (EUD)
- RE: [dhcwg] Comments on 22 rev of the draft Ralph Droms
- Re: [dhcwg] Comments on 22 rev of the draft Vijay Bhaskar A K
- Re: [dhcwg] Comments on 22 rev of the draft Vijay Bhaskar A K
- RE: [dhcwg] Comments on 22 rev of the draft Bernie Volz (EUD)
- RE: [dhcwg] Comments on 22 rev of the draft Bernie Volz (EUD)
- Re: [dhcwg] Comments on 22 rev of the draft Vijay Bhaskar A K
- Re: [dhcwg] Comments on 22 rev of the draft Vijay Bhaskar A K
- RE: [dhcwg] Comments on 22 rev of the draft Bernie Volz (EUD)
- RE: [dhcwg] Comments on 22 rev of the draft Vijayabhaskar A K
- RE: [dhcwg] Comments on 22 rev of the draft Bernie Volz (EUD)
- Re: [dhcwg] Comments on 22 rev of the draft Ralph Droms
- Re: [dhcwg] Comments on 22 rev of the draft Vijay Bhaskar A K
- Re: [dhcwg] Comments on 22 rev of the draft Vijay Bhaskar A K
- Re: [dhcwg] Comments on 22 rev of the draft Ted Lemon
- Re: [dhcwg] Comments on 22 rev of the draft Vijay Bhaskar A K
- Re: [dhcwg] Comments on 22 rev of the draft Ted Lemon
- Re: [dhcwg] Comments on 22 rev of the draft Ted Lemon
- Re: [dhcwg] Comments on 22 rev of the draft Martin Stiemerling
- Re: [dhcwg] Comments on 22 rev of the draft Jim Bound
- Re: [dhcwg] Comments on 22 rev of the draft Martin Stiemerling
- [dhcwg] Question on DHCPv6 Draft 23. Paul Tan