Subject: RE: [dhcwg] Options differing in OFFER and ACK

From: "Kostur, Andre" <[email-masked]>
Date: Tue, 3 Feb 2004 08:41:24 -0800

Look in section 4.4, the state diagram.  If the client receives a NAK in the
Requesting state, it is to discard the offer, and transition back into the
Init state.  If this was an Init-Reboot, and the client is in the Rebooting
state, it is to "Restart" and transition to the Init state.

Nutshell version: if you get a NAK at this point, your current lease (or the
offered lease) is no longer valid.  Go back to Discover.

> -----Original Message-----
> From: Kevin A. Noll [mailto:[email-masked]]
> Sent: Tuesday, February 03, 2004 8:32 AM
> To: Ted Lemon
> Cc: [email-masked]
> Subject: RE: [dhcwg] Options differing in OFFER and ACK
> 
> I suppose this paragraph in item 4 of section 3.1 would imply 
> the protocol
> violation...
> 
>      If the selected server is unable to satisfy the 
> DHCPREQUEST message
>      (e.g., the requested network address has been allocated), the
>      server SHOULD respond with a DHCPNAK message.
> 
> I suppose my confusion is that 2131 doesn't give any guidance 
> about what
> the client is to do in this case.
> 
> --kan--
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On Behalf Of
> > Kevin A. Noll
> > Sent: Monday, 02 February, 2004 10:27 PM
> > To: Ted Lemon
> > Cc: [email-masked]
> > Subject: RE: [dhcwg] Options differing in OFFER and ACK
> >
> > I agree that it is not the correct behavior.
> >
> > What I'm looking for is a reference in 2131 that would say (or at
> > least imply) that this is a violation of the protocol.
> >
> > > -----Original Message-----
> > > From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of Ted
> > > Lemon
> > > Sent: Monday, 02 February, 2004 10:04 PM
> > > To: Kevin A. Noll
> > > Cc: [email-masked]
> > > Subject: Re: [dhcwg] Options differing in OFFER and ACK
> > >
> > >
> > > On Feb 2, 2004, at 7:30 PM, Kevin A. Noll wrote:
> > > > Can someone tell me if there is a specific answer to 
> this? Is there
> > > > a requirement that the server grant the IP address 
> being requested
> > > > if it was previously offered?
> > >
> > > This is a protocol violation on the part of the server.   
> The client
> > > should drop the packet like a hot potato - it's probably 
> a denial of
> > > service attack.
> > >
> > > I don't think 2131 is specific about cases like this.   I 
> tend to be in
> > > favor of interoperability over pickiness, but the server 
> is totally
> > > forbidden from doing this in RFC2131, and I don't see any 
> reason why
> > > the client should be forgiving about it.

---

From: "Kevin A. Noll" <[email-masked]>
Date: Tue, 03 Feb 2004 11:54:13 -0500

RE: [dhcwg] Options differing in OFFER and ACK
Yep, I understand this scenario.

What I'm missing is if the client receives an ACK, but the ACKed IP is
different than
the OFFERed IP.

Seems to me that the client should drop the ACK (like Ted suggests), or send
a
DHCPDECLINE. I just don't see any recommendation for this.

--kan--
  -----Original Message-----
  From: Kostur, Andre [mailto:[email-masked]]
  Sent: Tuesday, 03 February, 2004 11:41 AM
  To: 'Kevin A. Noll'; Ted Lemon
  Cc: [email-masked]
  Subject: RE: [dhcwg] Options differing in OFFER and ACK

  Look in section 4.4, the state diagram.  If the client receives a NAK in
the Requesting state, it is to discard the offer, and transition back into
the Init state.  If this was an Init-Reboot, and the client is in the
Rebooting state, it is to "Restart" and transition to the Init state.

  Nutshell version: if you get a NAK at this point, your current lease (or
the offered lease) is no longer valid.  Go back to Discover.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 3 Feb 2004 11:43:35 -0600

On Feb 3, 2004, at 10:54 AM, Kevin A. Noll wrote:
> Seems to me that the client should drop the ACK (like Ted suggests), 
> or send a

It's a completely inappropriate packet.   Sending a DHCPDECLINE in this 
case would be a very bad idea, because if it is a DoS attack, now the 
client is helping out, and might be able to squeak by a filter that 
would have prevented a direct attack on the server.

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