Subject: RE: [dhcwg] question on draft-ietf-dhc-dhcpv6-opt-cliprefprefix

From: [email-masked]
Date: Mon, 27 Oct 2003 14:36:22 +0000

Hi Vijay,

So if the server allocates addresses on ALL the 
prefixes sent by the client and if the client did send several prefixes,
then there will be a big number of addresses alocated and un-used since 
the client
only needs one valid address on link to communicate.
I think that this technique will result in a waist of commited 
addresses.

Stephane

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 27 October 2003 13:41
To: Stephane Antoine; [email-masked]
Subject: RE: [dhcwg] question on draft-ietf-dhc-dhcpv6-opt-cliprefprefix

Hi Stephane

The client is supposed to send the list of ALL the preferred prefixes on
which it wishes the server to allocate addresses. There is actually no
preference on the any of the prefixes. If the server's policy supports
this option and one or more prefixes are not known by the server (or)
doesn't belong to the client's link, then the server MUST send NotOnLink
error code. Otherwise, the server is expected to allocate addresses on
ALL the prefixes sent by the client. Hope this clarifies. Do getback to
me, if you need any further clarification

~ Vijay

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Monday, October 27, 2003 4:55 PM
To: [email-masked]
Subject: [dhcwg] question on draft-ietf-dhc-dhcpv6-opt-cliprefprefix

Dear Vijay,

About the processing of the list of preferred prefix option (scenario 3 
alike),
how would the server decide which prefix to assign its client if it 
receives
several prefixes from it?
If a Client sends a preferred prefix list, It will be easier 
if the prefixes were listed in order of decreasing value with 
a preference value associated with each prefix.
A default preference value of 0 if only one prefix 
had been advertised for example.
The client policy would decide how to order the prefixes with 
the preference value accordingly to its most preferred 
choice(s) 

stephane

========================================================================
======
Confidentiality Notice

The information contained in this E-mail, and any attachments, is
intended for the named recipients only. It may contain confidential
and/or privileged information.

If you are not the intended recipient, you must not copy, distribute, or
take any action in reliance on it. Any views expressed do not
necessarily reflect the views of Panasonic Mobile Communications
Development of Europe Limited.

Please note that whilst the company takes steps to protect against
viruses it cannot accept any liability for any damage, whether direct or
indirect, sustained as a result of any software viruses being
transmitted.

If you receive this E-mail by mistake, please advise the sender by using
the reply facility in your E-mail software and then delete it.
========================================================================
======

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

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

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

---

From: "Vijayabhaskar A K" <[email-masked]>
Date: Mon, 27 Oct 2003 20:15:28 +0530

Stephane,

You got my point wrong.. Client chooses 'n' number of preferred prefixes
from the available 'm' valid prefixes in the link.. here 1 <= n <= m..
The server is expected to allocate addresses from 'm' prefixes by
default.. Instead, the client can choose 'n' prefixes and send it in
this option, so that, the server can allocate addresses only from these
'n' prefixes.. This prevents wastage of m-n addresses which the client
doesn't want..

~ Vijay

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Monday, October 27, 2003 8:06 PM
To: [email-masked]; [email-masked]
Subject: RE: [dhcwg] question on draft-ietf-dhc-dhcpv6-opt-cliprefprefix

Hi Vijay,

Stephane

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 27 October 2003 13:41
To: Stephane Antoine; [email-masked]
Subject: RE: [dhcwg] question on draft-ietf-dhc-dhcpv6-opt-cliprefprefix

Hi Stephane

~ Vijay

-----Original Message-----

Dear Vijay,

stephane

---

From: Robert Elz <[email-masked]>
Date: Mon, 27 Oct 2003 21:43:54 +0700

Date:        Mon, 27 Oct 2003 14:36:22 +0000
    From:        [email-masked]
    Message-ID:  <H000025e00b57476.1067265380.contactserver1@MHS>

  | I think that this technique will result in a waist of commited 
  | addresses.

Why would anyone care about a waste of IPv6 addresses on a link?
There are 2^64 available.

Your client might only need one address (in which case it can send only one
prefix, if it gets a NotOnLink, it can try again with a different prefix).
Other clients wants lots of addresses - this allows the current state of
the art in multihoming (something approaching the stone age, maybe) to
be effective.

kre