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

"Glenn Waters"<gww@nortelnetworks.com> Mon, 04 February 2002 15:22 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 KAA25428 for <dhcwg-archive@odin.ietf.org>; Mon, 4 Feb 2002 10:22:14 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA08808 for dhcwg-archive@odin.ietf.org; Mon, 4 Feb 2002 10:22:16 -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 KAA07034; Mon, 4 Feb 2002 10:00:12 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07008 for <dhcwg@optimus.ietf.org>; Mon, 4 Feb 2002 10:00:08 -0500 (EST)
Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24473 for <dhcwg@ietf.org>; Mon, 4 Feb 2002 10:00:06 -0500 (EST)
Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g14ExaH07259; Mon, 4 Feb 2002 09:59:37 -0500 (EST)
Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g14ExZ328282; Mon, 4 Feb 2002 09:59:35 -0500 (EST)
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <D8QAXBRZ>; Mon, 4 Feb 2002 09:59:34 -0500
Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E60136F72A@zcard0ke.ca.nortel.com>
From: "Glenn Waters"<gww@nortelnetworks.com>
To: Matt Frick <mfrick@netopia.com>, dhcwg@ietf.org
Subject: RE: [dhcwg] Confusion on RFC 3011 subnet selection option
Date: Mon, 4 Feb 2002 09:59:32 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1AD8C.8D43EBF0"
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

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