[dhcwg] Re: Contents of dhcwg digest...

["Kapil Maheshwari" <[e-mail]>]

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: Friday, August 24, 2007 4:48 AM
To: [e-mail]
Subject: dhcwg Digest, Vol 40, Issue 26

Send dhcwg mailing list submissions to
	[e-mail]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www1.ietf.org/mailman/listinfo/dhcwg
or, via email, send a message with subject or body 'help' to
	[e-mail]

You can reach the person managing the list at
	[e-mail]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of dhcwg digest..."


Today's Topics:

   1. Re: lifetime of 'peer-address' (David W. Hankins)
   2. Re: lifetime of 'peer-address' (Bud Millwood)
   3. Re: lifetime of 'peer-address' (David W. Hankins)
   4. Re: lifetime of 'peer-address' (Bud Millwood)
   5. Re: lifetime of 'peer-address' (David W. Hankins)
   6. Re: lifetime of 'peer-address' (Bud Millwood)
   7. Vendor-specific options (Bud Millwood)
   8. RE: Vendor-specific options (Brzozowski, John)
   9. Re: Vendor-specific options (David W. Hankins)


----------------------------------------------------------------------

Message: 1
Date: Thu, 23 Aug 2007 10:35:50 -0700
From: "David W. Hankins" <[e-mail]>
Subject: Re: [dhcwg] lifetime of 'peer-address'
To: [e-mail]
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="us-ascii"

On Thu, Aug 23, 2007 at 08:41:25AM -0400, Bernie Volz (volz) wrote:
> There is no contract about the link-local address, but in general why
> would the client ever change that? It isn't like this address has
> privacy issues (or put another way, there's no need to protect it as the
> mac address is already available to others on the link).

Because of the DUID and IAID abstractions, it's entirely possible
that a client might change network devices (and thus hardware
addresses, and therefore link local addresses) without changing its
DUID or IAID.

So it's encouraged that if a system were to be given a new network
device (and therefore a new link-local), that it may still Confirm for
the same IAID,DUID pair with the old addresses (and possibly even
sessions) intact.

Since such a Confirm may reach one DHCPv6 server, but not another,
and either DHCPv6 server may answer, it's entirely possible that
the link local address would change without some servers being the
wiser.  Not to mention that I think many servers will not update
recorded information about clients on processing Confirms (I
certainly hope we never have to).

So in an infinite universe, there's at least one reason it may be so.

I think it's also possible, if highly improbable, that a client
may lose its addresses to another client on the network, normally
such as over a network disconnect, or abnormally such as when a
network partition is healed.

> There are actually applications where using this might come in handy.
> For example, a Reconfigure message when the client has no "usable"
> global address (perhaps because the global address is not reachable
> directly from the DHCP server). While there's no disagreement that for a
> Reconfigure a global address is better to be used, there's no reason to
> prohibit relayed Reconfigure messages.
> 
> And, for Reconfigure messages, the Reconfigure Key Auth. Protocol should
> prevent issues if the client has changed its link-local and a different
> client is now using that link-local address.

I agree that DHCPv6 Reconfigure is a fine place to use the link local
address and RFC3315 even gives guidance that the server could
synthesize a Relay-Reply using the client's previously known
peer-address field...I assume it can synthesize a full relay chain
based upon the most recent.  This also is dynamic information - the
server has no way of knowing whether or not the relay chain has been
changed, entire devices could be removed or replaced, resulting also
in changes in peer-address fields across the chain.

First, I think of this activity as being administrator-initiated
(directly or indirectly).  In many cases, a 'Reconfigure' tool will
probably let an operator specify the target address.  The operator can
and should be able to specify any address he knows - or thinks he
knows.  In the case of network administration systems that abstract
this - they should work well in whatever custom environments they're
tailored for.

But more importantly, Reconfigure is an operation that is accepted
to fail.  You don't need to rely on it to work - the client will
Renew eventually.  It's just an optimization.


I think it is problematic to rely upon the client's link local
address for any persistent operation where reliability is a
requirement.

For that sort of thing you really need a contract with the client
that they will continue to use an address for some length of time,
such as is implicit (and in the client's best interest) with an
addressed assigned via DHCPv6 IA_NA.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :
http://www1.ietf.org/pipermail/dhcwg/attachments/20070823/5076299a/attachmen
t.bin

------------------------------

Message: 2
Date: Thu, 23 Aug 2007 20:15:05 +0200
From: Bud Millwood <[e-mail]>
Subject: Re: [dhcwg] lifetime of 'peer-address'
To: [e-mail]
Message-ID: <[e-mail]>
Content-Type: text/plain;  charset="utf-8"

On Thursday 23 August 2007 19:35, David W. Hankins wrote:
> On Thu, Aug 23, 2007 at 08:41:25AM -0400, Bernie Volz (volz) wrote:
> > There is no contract about the link-local address, but in general why
> > would the client ever change that? It isn't like this address has
> > privacy issues (or put another way, there's no need to protect it as the
> > mac address is already available to others on the link).
>
> Because of the DUID and IAID abstractions, it's entirely possible
> that a client might change network devices (and thus hardware
> addresses, and therefore link local addresses) without changing its
> DUID or IAID.
>
> So it's encouraged that if a system were to be given a new network
> device (and therefore a new link-local), that it may still Confirm for
> the same IAID,DUID pair with the old addresses (and possibly even
> sessions) intact.

You're basically saying that a server should not use a previously recorded 
link-address during a client-initiated transaction, right? Under what 
circumstances *would* a server consider using a previously recorded link 
address for a client-initiated transaction?

- Bud



------------------------------

Message: 3
Date: Thu, 23 Aug 2007 13:33:48 -0700
From: "David W. Hankins" <[e-mail]>
Subject: Re: [dhcwg] lifetime of 'peer-address'
To: [e-mail]
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="us-ascii"

On Thu, Aug 23, 2007 at 08:15:05PM +0200, Bud Millwood wrote:
> You're basically saying that a server should not use a previously recorded

> link-address during a client-initiated transaction, right? Under what 

No...for uses totally external to DHCPv6 actually.  Any use in which
reliability beyond the current transaction is required.

The stipulation on [e-mail] was that "a DHCPv6 server 'knows'
the link-local addresses of all clients, because it can record the
'peer-address' field".  In context, they meant that this information
was reliable for a purpose that really couldn't be allowed to fail.

Where getting it wrong is substantially more expensive than failing a
Reconfigure; someone loses or can't get net.

I can find the mail in the archive if you like.  I'm really curious
if I'm missing something; the person's clarification was that the
server is always (reliably) updated in any event a link-local address
changes.

I haven't read that anywhere, so I'm wondering how we get from here
to there.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :
http://www1.ietf.org/pipermail/dhcwg/attachments/20070823/68d0bcde/attachmen
t.bin

------------------------------

Message: 4
Date: Thu, 23 Aug 2007 22:17:06 +0200
From: Bud Millwood <[e-mail]>
Subject: Re: [dhcwg] lifetime of 'peer-address'
To: [e-mail]
Message-ID: <[e-mail]>
Content-Type: text/plain;  charset="utf-8"

On Thursday 23 August 2007 22:33, David W. Hankins wrote:
> On Thu, Aug 23, 2007 at 08:15:05PM +0200, Bud Millwood wrote:
> > You're basically saying that a server should not use a previously
> > recorded link-address during a client-initiated transaction, right?
Under
> > what
>
> No...for uses totally external to DHCPv6 actually.  Any use in which
> reliability beyond the current transaction is required.
>
> The stipulation on [e-mail] was that "a DHCPv6 server 'knows'
> the link-local addresses of all clients, because it can record the
> 'peer-address' field".  In context, they meant that this information
> was reliable for a purpose that really couldn't be allowed to fail.
>
> Where getting it wrong is substantially more expensive than failing a
> Reconfigure; someone loses or can't get net.
>
> I can find the mail in the archive if you like.  I'm really curious
> if I'm missing something; the person's clarification was that the
> server is always (reliably) updated in any event a link-local address
> changes.
>
> I haven't read that anywhere, so I'm wondering how we get from here
> to there.

Aha, I see. I don't recall anything stating that the server *must* record
the 
link-local address. And as far as I know there's no standard way to query a 
DHCPv6 server for a client's link-local address. But since the DHCP server 
seems the logical place to track them for a given DUID/IAID, why not store
it 
and update it with CONFIRMS? If this information is needed by another 
protocol we could, for example, extend lease-query to support asking for
this 
info.

- Bud



------------------------------

Message: 5
Date: Thu, 23 Aug 2007 14:19:47 -0700
From: "David W. Hankins" <[e-mail]>
Subject: Re: [dhcwg] lifetime of 'peer-address'
To: [e-mail]
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="us-ascii"

On Thu, Aug 23, 2007 at 10:17:06PM +0200, Bud Millwood wrote:
> Aha, I see. I don't recall anything stating that the server *must* record
the 
> link-local address. And as far as I know there's no standard way to query
a 
> DHCPv6 server for a client's link-local address. But since the DHCP server

> seems the logical place to track them for a given DUID/IAID, why not store
it 
> and update it with CONFIRMS? If this information is needed by another 
> protocol we could, for example, extend lease-query to support asking for
this 
> info.

You sound certain that DHCPv6 servers are updated reliably...why?

This is 3 opinions for and one against, so I must be missing
something.

On the continuing subject of Confirm; a different server may answer
the Confirm without all servers seeing it, so if there's more than
one server there could be differing opinions of the client's address.
If the Confirm times out entirely (CNF_MAX_RD is 10 seconds), the
client may just continue to use their old addresses - and won't emit
more messages until t1.  So no server may have the up-to-date address.

That's even if you update your database on Confirms, which rather
ruins its lightweightness (a quality I rather like since operators
can manipulate t1, but they can't control how often boxes reboot).

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :
http://www1.ietf.org/pipermail/dhcwg/attachments/20070823/38348199/attachmen
t.bin

------------------------------

Message: 6
Date: Thu, 23 Aug 2007 23:42:57 +0200
From: Bud Millwood <[e-mail]>
Subject: Re: [dhcwg] lifetime of 'peer-address'
To: [e-mail]
Message-ID: <[e-mail]>
Content-Type: text/plain;  charset="utf-8"

On Thursday 23 August 2007 23:19, David W. Hankins wrote:
> On Thu, Aug 23, 2007 at 10:17:06PM +0200, Bud Millwood wrote:
> > Aha, I see. I don't recall anything stating that the server *must*
record
> > the link-local address. And as far as I know there's no standard way to
> > query a DHCPv6 server for a client's link-local address. But since the
> > DHCP server seems the logical place to track them for a given DUID/IAID,
> > why not store it and update it with CONFIRMS? If this information is
> > needed by another protocol we could, for example, extend lease-query to
> > support asking for this info.
>
> You sound certain that DHCPv6 servers are updated reliably...why?

No, IM'm just thinking out loud. Your argument against is a valid 
consideration, because it's true that multiple DHCP servers may have 
differing data for a client's LL address, and all servers may have stale 
data.

I see no way to guarantee that even one DHCP server has a LL address for a 
client that is *definitely* known to be valid. Having said that, it may be 
highly likely that it is valid. Is that useful for whoever needs the info?

Is there a better way to identify a client as being the same machine after
it 
changes its LL address? That's exactly what DUID gives you.

So unless there's a mechanism that mimics DUID that I'm not aware of, I
guess 
the conclusion is that you can't know for sure, but the DHCP server can give

you a reasonable guess. <glad to be of service folks, we'll be here all 
week> :)

- Bud



------------------------------

Message: 7
Date: Thu, 23 Aug 2007 23:59:32 +0200
From: Bud Millwood <[e-mail]>
Subject: [dhcwg] Vendor-specific options
To: [e-mail]
Message-ID: <[e-mail]>
Content-Type: text/plain;  charset="utf-8"

In DHCPv4, the vendor options contained in option 43 were interpreted 
according to the free-form text of option 60. Vendors were free to put 
anything in option 60, and many of them chose different data for different 
models of their equipment.

In DHCPv6 the vendor options are interpreted according to the vendor_id
field, 
but vendors are *not* free to put anything in there that they want - just 
their assigned id.

How are vendors expected to define different sets of options for different 
equipment? It seems to me that the possibilities are:

1. Vendors don't have different options, they use the 16-bit tag space to 
define all options for all devices. Seems like a bad idea for a couple of 
reasons, one being you can't easily narrow down and present to the user a
set 
of options for a particular piece of equipment.

2. Vendors start defining their own free-form text fields inside the VSO,
and 
we end up looking awfully similar to DHCPv4.

3. Vendors use 'vendor-sub-identifiers', hopefully modelled after the VSO.

It seems the VSO in DHCPv6 tried to solve the problem of allowing free-form 
vendor class, but just deferred the problem to parsing within the VSO - at 
least in the case where a vendor had multiple option 60 values for different

sets of vendor-specific options (in DHCPv4).

Are we going to see all sorts of crazy schemes in the DHCPv6 VSO to denote 
different option spaces?

Are any vendors currently partitioning their VSO suboptions?

Could/should we recommend that vendors use the VSO format inside the VSO if 
they want partitioned option spaces?

- Bud



------------------------------

Message: 8
Date: Thu, 23 Aug 2007 19:06:38 -0400
From: "Brzozowski, John" <[e-mail]>
Subject: RE: [dhcwg] Vendor-specific options
To: "Bud Millwood" <[e-mail]>,	<[e-mail]>
Message-ID:
	
<[e-mail]>
	
Content-Type: text/plain;	charset="iso-8859-1"

Hello Bud,

I am not sure if I am following all of the points below.  I will try to
offer some comments, however.

Vendor class in particular in DHCPv6 includes an enterprise-id that is used
to differentiate the values within.  Other options can be defined  in the
vendor option space (17) which also includes an enterprise-id.  An example
of where this has been used is in DOCSIS 3.0.

Is this what you were inquiring about?

HTH,

John
========================================= 
John Jason Brzozowski (CISSP, RHCT)
Comcast Corporation
e) mailto:[e-mail]
m) 609-377-6594
p) 856-324-2671
dc) 168*45683*22
=========================================



-----Original Message-----
From: Bud Millwood [mailto:[e-mail]]
Sent: Thu 8/23/2007 5:59 PM
To: [e-mail]
Subject: [dhcwg] Vendor-specific options
 
In DHCPv4, the vendor options contained in option 43 were interpreted 
according to the free-form text of option 60. Vendors were free to put 
anything in option 60, and many of them chose different data for different 
models of their equipment.

In DHCPv6 the vendor options are interpreted according to the vendor_id
field, 
but vendors are *not* free to put anything in there that they want - just 
their assigned id.

How are vendors expected to define different sets of options for different 
equipment? It seems to me that the possibilities are:

1. Vendors don't have different options, they use the 16-bit tag space to 
define all options for all devices. Seems like a bad idea for a couple of 
reasons, one being you can't easily narrow down and present to the user a
set 
of options for a particular piece of equipment.

2. Vendors start defining their own free-form text fields inside the VSO,
and 
we end up looking awfully similar to DHCPv4.

3. Vendors use 'vendor-sub-identifiers', hopefully modelled after the VSO.

It seems the VSO in DHCPv6 tried to solve the problem of allowing free-form 
vendor class, but just deferred the problem to parsing within the VSO - at 
least in the case where a vendor had multiple option 60 values for different

sets of vendor-specific options (in DHCPv4).

Are we going to see all sorts of crazy schemes in the DHCPv6 VSO to denote 
different option spaces?

Are any vendors currently partitioning their VSO suboptions?

Could/should we recommend that vendors use the VSO format inside the VSO if 
they want partitioned option spaces?

- Bud

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




------------------------------

Message: 9
Date: Thu, 23 Aug 2007 16:18:01 -0700
From: "David W. Hankins" <[e-mail]>
Subject: Re: [dhcwg] Vendor-specific options
To: [e-mail]
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="us-ascii"

On Thu, Aug 23, 2007 at 11:59:32PM +0200, Bud Millwood wrote:
> 1. Vendors don't have different options, they use the 16-bit tag space to 
> define all options for all devices. Seems like a bad idea for a couple of 
> reasons, one being you can't easily narrow down and present to the user a
set 
> of options for a particular piece of equipment.

This is my understanding.

I think that DOCSIS, concerned I think about having a large number of
options in one 16-bit space, has elected to use a sub-parameter-
request-list option.  I might be thinking of something else, but I
think DOCSIS 3 specified one.

Where software supports it - the operator configures all the values
for all the different options, and they get delivered automatically
to the clients that want them.

	option vendor.foo ...;
	option vendor.bar ...;
	option vendor.baz ...;

Where software doesn't support it - the operator configures "classes"
that match individual vendor class options, and configure values
relevant to those classes of clients in one place.  The output packet
contains only that which is relevant to the class of client in
question.

	class "thingits" {
		match if vivco.example = "thingit";
		option vendor.foo ...;
	}
	class "whatsis" {
		match if vivco.example = "whatsis";
		option vendor.bar ...;
	}
	class "dongles" {
		match if vivco.example = "dongles";
		option vendor.baz ...;
	}

(where vivco is 'vendor identified vendor class option'...I can't
remember which is which anymore...is it "vcio" for DHCPv6?)


The worst case is that the clients get big packets.

I don't think there's a danger that vendors are going to have multiple
option spaces with one enterprise-ID...but if someone says they might,
we should listen.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :
http://www1.ietf.org/pipermail/dhcwg/attachments/20070823/a90c00dd/attachmen
t.bin

------------------------------

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


End of dhcwg Digest, Vol 40, Issue 26
*************************************


DISCLAIMER
==========
This e-mail may contain privileged and confidential information which is the property of Persistent Systems Pvt. Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Pvt. Ltd. does not accept any liability for virus infected mails.

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