RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6

[Changming Liu <[e-mail]>]

This draft comes at the exact time we need it. We just implemeneted DHCP
server and client and one of our big customers run into this reconfig issue
in their planned deployment right away! I wish I would have read it early.

The scenario is different from the two described in section 3. Our customer
runs DHCP clients on two unpstream interfaces and DHCP server on on
downstream interface which connects to a LAN with PCs, etc, The DHCP is used
just to pass configuration info . Depending on the availaibility of upstream
routers which have different DNS server setup among other configs, the DHCP
server needs to update DNS to the LAN immediately to avoid service outage.
Note that these DNS servers are in different zones. This, to my opinion,
should be another major scenario: dynamic change of config info.


In section 5, among three proposed mechanisms, to me, only 1) looks viable.
Multicast support should not be any issue anyway. Is it true that the entire
stateless auto-config and ND are based on that? The only concern may be
security for forged reconfigure message. But this is a more generic issue
than just for reconfigure message itself. Or am I missing something?

The lifetime has several significant drawbacks. The first one is how to
engineer the lifetime value? A difficult choice. if too long it will cause
too long delay, which is unacceptable for service shortage. if too short, it
may cause periodic storms of request/replies. This itself sounds like a
attack to me. The second one is the maintenance effort for both server and
client to maintain these timers as someone pointed out in the meeting. 

The third option looks better, but it won't work between upstream router and
downstream router using DHCPv6 to pass auto-config info. The draft requires
the DHCP relay which may not exist in the scenario I just described.


I guess, actually, the debate, if any,  will boil down to event-driven or
polling? which is better and efficient? Agree?

Changming Liu
Netscreen Technologies Inc.

-----Original Message-----
From: JINMEI Tatuya / ????
To: Tim Chown
Cc: [e-mail]
Sent: 3/1/2004 5:11 PM
Subject: Re: [dhcwg] Renumbering Requirements for Stateless DHCPv6

>>>>> On Tue, 10 Feb 2004 13:45:49 +0000, 
>>>>> Tim Chown <[e-mail]> said:

> There have not been any list comments on a draft that I wrote with
Stig and
> A.K. after Minneapolis on the issue of how nodes using DHCPv6 only for
non
> address configuration options should leanr ofconfiguration changes.

>
http://www.ietf.org/internet-drafts/draft-chown-dhc-stateless-dhcpv6-ren
umbering-00.txt

I've read the draft, and don't see a major problem in it.

One minor comment:  the draft repeatedly say there should be no
additional security concerns in actual proposals to address the
renumbering issues:

In Section 4, it says
   The solution should also be secure, such that additional security
   concerns are not added to the stateless DHCPv6 networking
   environment.

And in Section 7, it says
   However, whatever mechanism is designed or chosen to address this
   problem should avoid the introduction of new security concerns for
   (stateless) DHCPv6.

I have sympathy for you here, but is this actually a clear and
realistic requirement?  In fact, draft-venaas-dhc-lifetime-01.txt,
which is expected to be a proposal to address the renumbering issue,
has the following security concern:

   An attacker could send a fake DHCP reply with a very low lifetime
   value.  This could make a client request new data almost immediately.
   The value is however not kept when the next request is made.

Regarding the clarity, I'm not sure by this consideration if an
additional security concern is not added.

Regarding the reality, I guess it is likely to see some security
concerns in actual proposals, since the proposals would be a protocol
extension that affects a core part of the base specification.

I don't think this comment is a technical issue though.  This is
probably a matter of wording.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba
Corp.
					[e-mail]

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

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