Subject: RE: [dhcwg] A problem of unicasting Solicit message

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Tue, 20 Dec 2005 06:59:36 -0500

I believe this is likely another errata we'll have for a revised version
of RFC 3315. (Probably just a cut and paste error during drafting and we
missed it in reviews.)

Offhand I can't think of why a SOLICIT could be unicast.

- Bernie

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of haoda
> Sent: Tuesday, December 20, 2005 5:05 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [dhcwg] A problem of unicasting Solicit message
> 
> Hi!
> 
> I have a problem of RFC3315.
> It is about the using with unicast address in Solicit message.
> 
> At "15. Message Validation",(P27, line 1506)
> RFC said like this,
> "  A server MUST discard any Solicit, Confirm, Rebind or
>    Information-request messages it receives with a unicast destination
>    address."
> My understanding is the server must discard the Solicit message
> via unicast.
> 
> But at the other place, "17.2.2 " (P37, line 2058)
> there is differrent description.
> "   If the Solicit message was received directly by the server, the
>    server unicasts the Advertise message directly to the client using
>    the address in the source address field from the IP 
> datagram in which
>    the Solicit message was received.  The Advertise message MUST be
>    unicast on the link from which the Solicit message was received."
> This pragraph tells me that the server need send Advertise message
> via unicast when receiving a uncasting Solicit message.
> 
> It looks not consitent,isn't it? 
> Please tell me how to understand the 2 ones.
> 
> 
> Regard yours,
> Haoda
> 
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 

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