Subject: RE: Discussion Item - Reconfiguration in DHCPv6 (Items 8, 9, 18 o n Co nference Call Agenda)

From: Bernie Volz <[email-masked]>
Date: Mon, 11 Sep 2000 13:50:39 -0400

FYI - 

-----Original Message-----
From: Jim Bound [mailto:[email-masked]] 
Sent: Monday, September 11, 2000 9:48 AM
To: Bernie Volz
Cc: [email-masked]
Subject: Re: Discussion Item - Reconfiguration in DHCPv6 (Items 8, 9, 18
o n Co nference Call Agenda)

Hi Bernie,

My systems were all down this weekend they had to do some wiring in 
our building and shutdown power for 36 hours.

>This is more for my own clarification (I didn't send it to the list):

OK.

>For IPv6, suppose there is a router. It sends router advertisements with
the
>'M' bit set. It also sends the prefix list with the 'A' bit clear for those
>prefixes that are stateful, meaning that the client can not autoconfigure
an
>address. In those advertisements are also the lifetimes. How do these
>lifetimes and any DHCPv6 specified lifetimes interact.

If the A bit is clear the implementation basically ignores the addresses
and lifetimes.  So they won't interact with DHCPv6.  

The WG needs to understand this.  If the A bit is not set there is no
problem.  If the A bit was set for the same prefixes that DHCPv6 are
using then clearly the lifetimes would be affected.  I would think the
same admin people will be in control and this is really a
"misconfiguration".  

But what I did in a prototype is marked the if6_net addresses as
stateless or stateful.  As I did the code for all this on T64 I know it
well.   If a router reduces the lifetime this is a problem and we either
need to release it or renew.  

I don't think want to get into the role of telling the server from the
client here are the NEW lifetimes the stateless says you should use Mr.
Server?  That defeats the point of "tight control by dhcpv6 server
adim".

>Recall that I raised this issue in an earlier discussion (a few days ago).

Yep wanted to wait to see where it went?

>If router advertisements deprecate the address before the DHCPv6 specified
>lifetimes do, should the client honor it or assume that the lease is
>"correct" (unless the DHCPv6 server sends it a reconfigure). Or might this
>be used as a trigger for the client to attempt to renew the address?

Well according to stateless and nd specs the client must change the
leases as stateless is the head cheese so to speak.

Should we bring this up on the list?

regards,
/jim

---

From: "Peter Tam" <[email-masked]>
Date: Mon, 11 Sep 2000 15:28:21 -0400

Jim,

See in-line comments.

Regards....Peter Tam,
Nortel Networks

	-----Original Message-----
	From:	Jim Bound [SMTP:[email-masked]]
	Sent:	Friday, September 08, 2000 10:14 AM
	To:	DHCPv6 discussion list
	Subject:	Re: Discussion Item - Reconfiguration in DHCPv6
(Items 8, 9, 18 o n Co  nference Call Agenda)

	Bernie,

	>OK. I was just wondering whether it was possible ... it would
reduce
	>security issues as we push them off to the router advertisement
messages.
	>Agreed that they are going to be useful if there are no routers
(and perhaps
	>even if there are to effect transitions more quickly).

	Two things:

	1.  I am not saying there are no routers on the LAN where clients
exist
	but something much more important as an assumption and important we
	consider the assumption:

	    Network Admins may not want to use stateless addrconf for 
	    address configuration  but will have all routers set the M 
	    bit in router advertrisements and tell clients go do address
	    configuration with DHCPv6.  Its a customer/user policy decision
	    to not use stateless addrconf on purpose.  We need to be
prepared
	    for that policy as we enhance DHCPv6 as a working group.

	2.  If anyone wants to add to any of the Neighbor Discovery packets 
	    they must go propose this in the IPng Working Group.  Like
Mobile
	    IPv6 has done.  We can't do that here the expertise is not wide
	    enough on this list or enough of a quorum of IPv6 Neighbor 
	    Discovery implementors (I think we only have Tim, Erik, Francis,
	    and I as a note)????  And I think it should be done on IPng as 
	    IETF policy IMO.

	>BTW: If there are no router advertisements received (after some
period), I
	>assume a IPv6 host is supposed to attempt stateful address
configuration (by
	>default).

	It has been left unspecified if there are no router advertisements
so
	that means if a client does not hear from a router our
implementation
	will go look for a dhcpv6 server, once we nail this spec down of
course.

	>> RFC2462, section 5.5.2  does specify that a host MUST default to
stateful autoconfiguration, if router advertisements are absent. But, you
are right, it does NOT say it must be DHCPv6:
	"If a link has no routers, a host MUST attempt to use stateful
autoconfiguration....."

	But if there are router advertisements I read the specs that an
	implementaiton should not go look for DHCPv6 server unless the M bit
is
	set or the O bit (INFORM) is set.

	regards,
	/jim

---

From: Bernie Volz <[email-masked]>
Date: Sat, 16 Sep 2000 21:16:16 -0400

I agree with using multicast. I have no objection to its use.

I think the issue with the multicast has been that it opens up denial of
service attacks. Sending 1 message to mess up 1000s of clients is considered
bad (if you don't support multicast, a person attempting a DOS attack would
need to send 1000s of messages and need to know each clients address in
order to do that attack). The solution is pretty easy - require
authentication (of some level) especially with multicast.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]]
Sent: Friday, September 15, 2000 5:25 PM
To: DHCPv6 discussion list
Subject: Re: Discussion Item - Reconfiguration in DHCPv6 (Items 8, 9, 18
on Co nference Call Agenda)

> >We can always add multicast later...
> But we need Multicast now, today.

On an intuitive level I agree with you on this, Jim.   I don't
understand what the objection is to multicast.   Can someone concisely
summarize what the problems are with implementing multicast
reconfigure?

Thanks!

			       _MelloN_