Re: [dhcwg] Reg RFC6704 (Forcerenew Nonce Authentication)

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>
"Bernie Volz (volz)" writes:
>  
> Ted - I think you are spot on. We really have to prioritize and
> handle the major issues and also focus on the future - IPv6 and
> getting there.  Marginal extensions to IPv4 should be very low
> priority (or even better dropped).
>  
> - Bernie

Bernie,

FORCERENEW and Forcerenew Nonce Authentication apply to IPv6 as well
as IPv4.

A short draft saying the RFC6704 also applies to INFORM would not be a
big distraction.  A statement could even be short enough to be an
errata if we were willing to change RFC6704 with an errata (though I
don't suggest we do this as an errata).

Curtis


> On 9/11/12 10:52 PM, "Ted Lemon" <[e-mail]> wrote:
>  
> >On Sep 11, 2012, at 9:45 PM, "Gaurav Halwasia (ghalwasi)"
> ><[e-mail]>
> > wrote:
> >> I am talking about a deployment where we do create *session* database
> >>for hosts either based upon DHCP packet (Discover) or the normal IP
> >>packet in case few of the hosts has not done DHCP but instead has just
> >>DONE DHCP INFORM to get the config parameters. So in this kind of
> >>deployment we do anyways maintain the session(or binding in terms of
> >>DHCP) database on the box. Having said that I don't think storing client
> >>information is a problem (at least in this deployment). The only extra
> >>thing which we would need to store is a 'nonce'.
> >
> >This is a heavy burden for the working group to take on for a small
> >deployment.   Can you go into some detail about why this is the right way
> >to solve the problem, and what bad things would happen if you didn't have
> >FORCERENEW?
> >
> >I'm sorry to be stubborn about this, but you're talking about a DHCPv4
> >protocol extension, and as you know from another draft that just went to
> >the IESG, bandwidth is limited for the DHC working group - we've had
> >presentation marathons at the last two IETFs, and I've had to chivvy
> >presenters mercilessly just to avoid running over the generous time slots
> >we've been given.   I feel really bad about doing that, and so I'm going
> >to push back on proposals like this if I don't have a clear sense of
> >their broad utility.   I say this sort of wearing my working group
> >co-chair hat and sort of wearing my working group participant hat - as a
> >participant, I don't see the broad utility in this proposal, and as a
> >chair I see a lot of work in my future.   So please, give us a clear
> >sales pitch for why we should feel good about taking on this work.