Re: [dhcwg] Confusion on RFC 3011 subnet selection option

"Matt Frick" <mfrick@netopia.com> Mon, 04 February 2002 22:03 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06836 for <dhcwg-archive@odin.ietf.org>; Mon, 4 Feb 2002 17:03:05 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA03502 for dhcwg-archive@odin.ietf.org; Mon, 4 Feb 2002 17:02:57 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01098; Mon, 4 Feb 2002 16:21:25 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01067 for <dhcwg@ns.ietf.org>; Mon, 4 Feb 2002 16:21:13 -0500 (EST)
Received: from mercury.netopia.com (mail.netopia.com [163.176.4.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06189 for <dhcwg@ietf.org>; Mon, 4 Feb 2002 16:21:10 -0500 (EST)
Received: from netopia.com ([163.176.45.190]) by mercury.netopia.com (Netscape Messaging Server 4.15) with ESMTP id GR11YI00.MQV; Mon, 4 Feb 2002 13:20:42 -0800
Message-ID: <3C5EFAE5.B85DBFD7@netopia.com>
Date: Mon, 04 Feb 2002 13:19:33 -0800
From: Matt Frick <mfrick@netopia.com>
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Glenn Waters <gww@nortelnetworks.com>
CC: dhcwg@ietf.org
Subject: Re: [dhcwg] Confusion on RFC 3011 subnet selection option
References: <0D7FC1D8D861D511AEA70002A52CE5E60136F72A@zcard0ke.ca.nortel.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org
Content-Transfer-Encoding: 7bit

In the case where a server is serving addresses from multiple logical
subnets on the same network segment, how does the server know which
subnet the DHCP client is sending the DHCP discover/request out on when
it's broadcast to all 1s?

It seems like this would be the most appropriate option for selecting
the subnet in the above scenario, but requiring the giaddr to be set
prevents it from being usable in the above scenario.  Is there any way
it could have been written so that the option would work directly from a
DHCP client to a DHCP server such as the above scenario?  It seems like
requiring the giaddr is only useful when there's no routing between the
two interfaces, but by forcing it to be required, doesn't that make this
option only usable in that specific circumstance?

-Matt Frick

Glenn Waters wrote:

>
>
> This option is intended for use by a device that is requesting address
> on behalf of another device. The word client in this case implies that
> you already have an IP address (static or dynamic).
>
> This option is not intended to allocate an address on a specific
> subnet on devices that are connected to multiple subnets. The correct
> way to allocate an address on a specific subnet is to send the DHCP
> request out on the subnet for which you wish to have an address
> allocated.
>
> /gww
>
> -----Original Message-----
> From: Matt Frick [mailto:mfrick@netopia.com]
> Sent: Friday, February 01, 2002 18:50
> To: dhcwg@ietf.org
> Subject: [dhcwg] Confusion on RFC 3011 subnet selection option
>
> After re-reading RFC 3011 many times, I'm still a bit confused, and
> hopefully there are some talented indivuals out there on the email
> list
> that can help me out.
>
> From what I understand, (other than the obvious subnet-related parts)
> the subnet selection option overrides the current usage of giaddr
> which
> is used by relay agents to specify:
> 1) the address to which the server is to send it's reply, and
> 2) the subnet from which to allocate the address.
> It seems that the option is designed to be used / necessary only when
> a
> relay agent needs the server to reply to an address on a subnet that
> is
> different than the subnet on which the address should be allocated,
> since
>
>         "in all packets that the DHCP client sends that contain the
> subnet
>         selection option, the giaddr field in the BOOTP header MUST be
>
>         set to an IPv4 address on which the DHCP client will accept
>         DHCP packets. (e.g.: the address on the subnet connected
>         to the internal network)." [RFC 3011, page 4]
>
> Since the RAS device in the motivational example is connected to the
> internal network on which the DHCP server is located, does that mean
> that the RAS device is the "client" in the above quote?  If it is,
> then
> that would explain why it has an address on which it can receive DHCP
> packets to put in the giaddr when sending a discover or request (ie.
> when it's not bound) -- perhaps the address sent in the giaddr field
> is
> not a DHCP obtained address, but a statically defined address on the
> internal network.
>
> Can this option be sent by a end client (host) directly to a server,
> or
> must it pass through a relay agent?  The reason it seems likely that a
>
> relay agent is required, is that when the giaddr is nonzero, the
> server
> will repond to the server port, not the client port:
>
>        "The server SHOULD next check the 'giaddr' field.  If this
> field
> is
>         non-zero, the server SHOULD send the BOOTREPLY as an IP
> unicast
>         to the IP address identified in the 'giaddr' field.  The UDP
>         destination port MUST be set to BOOTPS (67)." [RFC 1542, page
> 20]
>
> especially since:
>
>         "This option does not require changes to operations or
> features
> of the
>         DHCP server other than to select the subnet on which to
> allocate
> on
>         address." [RFC 3011, page 3]
>
> So, I guess the big mystery (atleast for me,) is this: can an end
> client
> send a subnet selection option?  When the client doesn't have a
> binding
> (and it's sending a subnet selection option,) can / should the giaddr
> be
> set to zero?
> Or, is this option reserved for situations more complicated than a
> simple scenario where a DHCP server has several subnets and a directly
>
> connected client wants to request an address on a specific subnet?
>
> Thanks for reading this far, hopefully this RFC can be clarified.
> -Matt Frick
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg