< draft-joshi-dhcp-lease-query-ext-01.txt		draft-joshi-dhcp-lease-query-ext-02.txt >
	DHC Working Group B. Joshi		DHC Working Group B. Joshi
	Internet-Draft P. Kurapati		Internet-Draft P. Kurapati
	Expires: February 5, 2007 Infosys Technologies Ltd.		Expires: March 23, 2007 Infosys Technologies Ltd.
	August 4, 2006		September 19, 2006
	Extension of DHCP Leasequery in Bridging/Switching networks		Extension of DHCP Leasequery in Bridging/Switching networks
	draft-joshi-dhcp-lease-query-ext-01.txt		draft-joshi-dhcp-lease-query-ext-02.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 34 ¶		skipping to change at page 1, line 34 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on February 5, 2007.		This Internet-Draft will expire on March 23, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	As per industry trends, Access Networks have been migrating from		As per industry trends, Access Networks have been migrating from
	traditional ATM based networks to Ethernet networks. In Ethernet		traditional ATM based networks to Ethernet networks. In Ethernet
	based access networks, Access Concentrators are typically configured		based access networks, Access Concentrators are typically configured
	to act as traditional bridge. These Access Concentrators also act as		to act as traditional bridge. These Access Concentrators also act as
	relay agents and relay DHCP messages between hosts and DHCP servers.		relay agents and relay DHCP messages between hosts and DHCP servers.
	It also maintains and updates lease/location information while		It also maintains and updates lease/location information while
	relaying the DHCP messages. Access Concentrators may use the lease/		relaying the DHCP messages. Access Concentrators may use the lease/
	location information for anti-spoofing, data forwarding etc. This		location information for anti-spoofing, data forwarding etc. This
	lease/location information is lost if an Access Concentrator gets		lease/location information is lost if an Access Concentrator gets
	rebooted. RFC 4388 [4] has defined a new message type DHCPLEASEQUERY		rebooted. RFC 4388 [5] has defined a new message type DHCPLEASEQUERY
	to address similar limitation in Routed Access Networks.		to address similar limitation in Routed Access Networks.
	This document initially gives an overview of the functioning of the		This document initially gives an overview of the functioning of the
	Access Concentrator acting as a relay agent in a Layer 2 aggregation		Access Concentrator acting as a relay agent in a Layer 2 aggregation
	network. The limitation[as mentioned above] in a typical switched/		network. The limitation[as mentioned above] in a typical switched/
	bridged[layer 2] is then discussed followed by the proposal to extend		bridged[layer 2] is then discussed followed by the proposal to extend
	the DHCPLEASEQUERY message to address this limitation.		the DHCPLEASEQUERY message to address this limitation.
	Table of Contents		Table of Contents
	skipping to change at page 2, line 28 ¶		skipping to change at page 2, line 28 ¶
	3. Typical layer 2 access network . . . . . . . . . . . . . . . . 6		3. Typical layer 2 access network . . . . . . . . . . . . . . . . 6
	3.1. Access Concentrator acting as Layer 2 DHCP relay agent . . 6		3.1. Access Concentrator acting as Layer 2 DHCP relay agent . . 6
	4. Protocol Extension Overview . . . . . . . . . . . . . . . . . 8		4. Protocol Extension Overview . . . . . . . . . . . . . . . . . 8
	4.1. Lease/Location information in layer 2 Networks . . . . . . 8		4.1. Lease/Location information in layer 2 Networks . . . . . . 8
	4.2. Extension of DHCPLEASEQUERY in layer 2 Networks . . . . . 8		4.2. Extension of DHCPLEASEQUERY in layer 2 Networks . . . . . 8
	5. Protocol Extension Details . . . . . . . . . . . . . . . . . . 9		5. Protocol Extension Details . . . . . . . . . . . . . . . . . . 9
	5.1. Definition required for extension of DHCPLEASEQUERY		5.1. Definition required for extension of DHCPLEASEQUERY
	message . . . . . . . . . . . . . . . . . . . . . . . . . 9		message . . . . . . . . . . . . . . . . . . . . . . . . . 9
	5.2. Generating DHCPLEASEQUERY Message . . . . . . . . . . . . 9		5.2. Generating DHCPLEASEQUERY Message . . . . . . . . . . . . 9
	5.3. Handling DHCPLEASEQUERY Message in Layer-3 Relay Agent . . 11		5.3. Handling DHCPLEASEQUERY Message in Layer-3 Relay Agent . . 11
	5.4. Handling DHCPLEASEQUERY Message in DHCP Server . . . . . . 11		5.4. Handling DHCPLEASEQUERY Message in DHCP Server . . . . . . 12
	5.5. Handling DHCP Reply Message in Layer-3 Relay Agent . . . . 12		5.5. Handling DHCP Reply Message in Layer-3 Relay Agent . . . . 12
	5.6. Handling DHCP Reply Message in Access Concentrator . . . . 13		5.6. Handling DHCP Reply Message in Access Concentrator . . . . 13
	5.6.1. Handling DHCPLEASEUNASSIGNED Reply Message . . . . . . 13		5.6.1. Handling DHCPLEASEUNASSIGNED Reply Message . . . . . . 13
	5.6.2. Handling DHCPLEASEUNKNOWN Reply Message . . . . . . . 13		5.6.2. Handling DHCPLEASEUNKNOWN Reply Message . . . . . . . 13
	5.6.3. Handling DHCPLEASEACTIVE Reply Message . . . . . . . . 13		5.6.3. Handling DHCPLEASEACTIVE Reply Message . . . . . . . . 13
	5.6.4. Handling No Response to the DHCPLEASEQUERY Message . . 13		5.6.4. Handling multiple responses for DHCPLEASEQUERY
	5.6.5. Handling DHCPLEASEQUERY messages not belonging to		Message . . . . . . . . . . . . . . . . . . . . . . . 13
	Access Concentrator . . . . . . . . . . . . . . . . . 13		5.6.5. Handling No Response to the DHCPLEASEQUERY Message . . 14
	6. Security Consideration . . . . . . . . . . . . . . . . . . . . 14		5.6.6. Handling DHCPLEASEQUERY messages not belonging to
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		Access Concentrator . . . . . . . . . . . . . . . . . 14
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16		6. Lease query using Management IP address of Access
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17		Concentrator . . . . . . . . . . . . . . . . . . . . . . . . . 15
	9.1. Normative Reference . . . . . . . . . . . . . . . . . . . 17		7. Security Consideration . . . . . . . . . . . . . . . . . . . . 16
	9.2. Informative Reference . . . . . . . . . . . . . . . . . . 17		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
	Intellectual Property and Copyright Statements . . . . . . . . . . 19		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
			10.1. Normative Reference . . . . . . . . . . . . . . . . . . . 19
			10.2. Informative Reference . . . . . . . . . . . . . . . . . . 19
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
			Intellectual Property and Copyright Statements . . . . . . . . . . 21
	1. Introduction		1. Introduction
	Access networks are undergoing transformation from traditional ATM		Access networks are undergoing transformation from traditional ATM
	based networks to Ethernet based networks. Service providers have		based networks to Ethernet based networks. Service providers have
	deployed Access Concentrators in both Routing and Bridging modes. In		deployed Access Concentrators in both Routing and Bridging modes. In
	the Routing mode, Access Concentrator terminates the user connection		the Routing mode, Access Concentrator terminates the user connection
	and 'routes' the packets to the edge/core network. In the bridging		and 'routes' the packets to the edge/core network. In the bridging
	mode, Access Concentrator does frame switching based on MAC address,		mode, Access Concentrator does frame switching based on MAC address,
	VLANs etc. It also supports DHCP/PPPoE/IGMP snooping for better		VLANs etc. It also supports DHCP/PPPoE/IGMP snooping for better
	security and bandwidth management. In case of DHCP/PPPoE snooping,		security and bandwidth management. In case of DHCP/PPPoE snooping,
	Access Concentrator acts as a Relay Agent.		Access Concentrator acts as a Relay Agent.
	In both routing and bridging mode, Access Concentrator maintains		In both routing and bridging mode, Access Concentrator maintains
	lease/location information by extracting it from the DHCP replies		lease/location information by extracting it from the DHCP replies
	received from the DHCP server. This information is typically		received from the DHCP server. This information is typically
	maintained for anti-spoofing, data forwarding etc. This lease/		maintained for anti-spoofing, data forwarding etc. This lease/
	location information is lost when Access Concentrator gets rebooted.		location information is lost when Access Concentrator gets rebooted.
	RFC 4388 [4] has defined a method to access information from the DHCP		RFC 4388 [5] has defined a method to access information from the DHCP
	server in a lightweight and consistent manner. This is achieved by		server in a lightweight and consistent manner. This is achieved by
	the use of a new message type "DHCPLEASEQUERY" that allows Relay		the use of a new message type "DHCPLEASEQUERY" that allows Relay
	Agents to query DHCP servers to obtain location information of DHCP		Agents to query DHCP servers to obtain location information of DHCP
	clients.		clients.
	RFC 4388 [4] assumes that in a typical access environment, Access		RFC 4388 [5] assumes that in a typical access environment, Access
	Concentrator acts as a Layer 3 DHCP Relay Agent. This document		Concentrator acts as a Layer 3 DHCP Relay Agent. This document
	suggests extension to RFC 4388 [4] to make it suitable in a layer 2		suggests extension to RFC 4388 [5] to make it suitable in a layer 2
	access environment.		access environment.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [1].		document are to be interpreted as described in RFC 2119 [1].
	This document uses the following terms:		This document uses the following terms:
	skipping to change at page 4, line 40 ¶		skipping to change at page 4, line 40 ¶
	Protocol (BOOTP) and DHCP messages between clients and servers		Protocol (BOOTP) and DHCP messages between clients and servers
	residing on different subnets, per [RFC951] and [RFC1542].		residing on different subnets, per [RFC951] and [RFC1542].
	o "DHCP server"		o "DHCP server"
	A DHCP server is an Internet host that returns configuration		A DHCP server is an Internet host that returns configuration
	parameters to DHCP clients.		parameters to DHCP clients.
	o "downstream"		o "downstream"
	Downstream is the direction from the edge network towards the		Downstream is the direction from the edge network towards the DHCP
	broadband subscriber.		Clients.
	o "lease/location information"		o "lease/location information"
	Lease/Location information is information maintained by the Access		Lease/Location information is information maintained by the Access
	Concentrator to either forward traffic to a broadband-accessible host		Concentrator to either forward traffic to a broadband-accessible host
	or for anti-spoofing of MAC address/IP address or for both. This		or for anti-spoofing of MAC address/IP address or for both. This
	information includes knowledge of the host hardware address, host IP		information includes knowledge of the host hardware address, host IP
	address, the port or virtual circuit that leads to the host, lease		address, the port or virtual circuit that leads to the host, lease
	timeout for the associated IP address and/or the hardware address of		timeout for the associated IP address and/or the hardware address of
	the intervening subscriber modem.		the intervening subscriber modem.
	skipping to change at page 5, line 20 ¶		skipping to change at page 5, line 20 ¶
	o "Transparent Bridge"		o "Transparent Bridge"
	A device which does bridging based on MAC learning principles.		A device which does bridging based on MAC learning principles.
	Bridge learns the Source MAC of the incoming frames and updates a		Bridge learns the Source MAC of the incoming frames and updates a
	table with MAC/Interface information. While forwarding data packets,		table with MAC/Interface information. While forwarding data packets,
	bridge looks at this table to find the outgoing interface.		bridge looks at this table to find the outgoing interface.
	o "upstream"		o "upstream"
	Upstream is the direction from the broadband subscriber towards the		Upstream is the direction from the DHCP Clients towards the edge
	edge network.		network.
	3. Typical layer 2 access network		3. Typical layer 2 access network
	Figure 1 shows a typical access network where the Access Concentrator		Figure 1 shows a typical access network where the Access Concentrator
	acts as a traditional Transparent Bridge. In a typical layer 2		acts as a traditional Transparent Bridge. In a typical layer 2
	access network, multiple hosts may be connected to each port. These		access network, multiple hosts may be connected to each port. These
	hosts use DHCP to receive User/Host Specific configuration details.		hosts use DHCP to receive User/Host Specific configuration details.
	Access concentrator snoops DHCP requests and append relay agent		Access concentrator snoops DHCP requests and append relay agent
	information before bridging them to the upstream Layer-3 Relay Agent.		information before bridging them to the upstream Layer-3 Relay Agent.
	A DHCP server may use the Relay Agent information to apply policies		A DHCP server may use the Relay Agent information to apply policies
	skipping to change at page 8, line 12 ¶		skipping to change at page 8, line 12 ¶
	Agent option and identifies the outgoing interface based on the		Agent option and identifies the outgoing interface based on the
	details in Relay Agent option [3].		details in Relay Agent option [3].
	4. Protocol Extension Overview		4. Protocol Extension Overview
	4.1. Lease/Location information in layer 2 Networks		4.1. Lease/Location information in layer 2 Networks
	An Access Concentrator snoops all DHCP messages and maintains the		An Access Concentrator snoops all DHCP messages and maintains the
	information of outgoing interface, MAC Address, IP address and Lease		information of outgoing interface, MAC Address, IP address and Lease
	information for each DHCP Client. This information [MAC-IP-Interface		information for each DHCP Client. This information [MAC-IP-Interface
	Binding] MAY be used to prevent MAC/IP Spoofing attacks and MAY also		Binding] may be used to prevent MAC/IP Spoofing attacks and may also
	be used for bridging frames.		be used for bridging frames.
	4.2. Extension of DHCPLEASEQUERY in layer 2 Networks		4.2. Extension of DHCPLEASEQUERY in layer 2 Networks
	Access Concentrator acting as Transparent Bridge typically maintains		Access Concentrator acting as Transparent Bridge typically maintains
	lease/location information for all DHCP clients. This makes it		lease/location information for all DHCP clients. This makes it
	vulnerable to the same issue [location/lease information lost when		vulnerable to the same issue [location/lease information lost when
	Access Concentrator gets rebooted] which has been addressed in RFC		Access Concentrator gets rebooted] which has been addressed in RFC
	4388 [4] for Layer 3 networks. This document extends mechanism		4388 [5] for Layer 3 networks. This document extends mechanism
	proposed in [4] to address this issue for layer 2 networks.		proposed in [5] to address this issue for layer 2 networks.
	When Access Concentrator needs to bridge a frame, it MAY refer to		When Access Concentrator needs to bridge a frame, it MAY refer to
	location/lease information to verify the IP address or MAC address.		location/lease information to verify the IP address or MAC address.
	If the location/lease information is not available, Access		If the location/lease information is not available, Access
	Concentrator can query DHCP server to obtain the lease/location		Concentrator can query DHCP server to obtain the lease/location
	information using DHCPLEASEQUERY message.		information using DHCPLEASEQUERY message.
	Access Concentrator can generate a DHCPLEASEQUERY [Query by IP		Access Concentrator can generate a DHCPLEASEQUERY [Query by IP
	address, MAC address or client identifier [7]] with all the fields		address, MAC address or client identifier [9]] with all the fields
	properly populated as defined in RFC 4388 [4].		properly populated as defined in RFC 4388 [5].
	When Layer-3 Relay Agent receives a DHCPLEASEQUERY, before forwarding		When Layer-3 Relay Agent receives a DHCPLEASEQUERY, before forwarding
	it to DHCP server, it MUST populate the "giaddr" field with the IP		it to DHCP server, it MUST populate the "giaddr" field with the IP
	address of the interface on which the request has been received.		address of the interface on which the request has been received.
	Layer-3 Relay Agent should forward this DHCPLEASEQUERY to a		Layer-3 Relay Agent should forward this DHCPLEASEQUERY to a
	particular DHCP server, if it knows which DHCP server might possess		particular DHCP server, if it knows which DHCP server might possess
	location/lease information for the given IP address or it should send		location/lease information for the given IP address or it should send
	it to all the DHCP servers configured in the Layer-3 Relay Agent.		it to all the DHCP servers configured in the Layer-3 Relay Agent.
	DHCP reply message for DHCPLEASEQUERY would have destination IP		DHCP reply message for DHCPLEASEQUERY would have destination IP
	skipping to change at page 9, line 25 ¶		skipping to change at page 9, line 25 ¶
	access-concentrator-hwaddr		access-concentrator-hwaddr
	This option allows a Layer 3 Relay agent to unicast a DHCP		This option allows a Layer 3 Relay agent to unicast a DHCP
	reply for a DHCPLEASEQUERY message to the Access Concentrator		reply for a DHCPLEASEQUERY message to the Access Concentrator
	which had generated the DHCPLEASEQUERY message.		which had generated the DHCPLEASEQUERY message.
	The code for this option need to be allocated by IANA. The		The code for this option need to be allocated by IANA. The
	length of this option is 18.		length of this option is 18.
	code len [Hardware address details]		code [Hardware address details]
	+------+------+------------+----------+-------------+		+------+------+------------+------------+
	| X | 18 | htype (1) | hlen (1) | hwaddr (16) |		| X | len | htype (1) | hwaddr |
	+------+------+------------+----------+-------------+		+------+------+------------+------------+
	In the above option:		In the above option:
	o 'X' need to be allocated by IANA.		o 'X' need to be allocated by IANA.
	o "htype" represents Hardware address type, see ARP section		o "len" field contains the length of the "Hardware address
	in "Assigned Numbers" RFC; e.g., '1' = 10mb ethernet.		details" and can be used to deduce length of "hwaddr" field.
	o "hlen" represents Hardware address length (e.g. '6' for		o "htype" represents Hardware type. See the 'ARP parameters'
	10mb ethernet)		maintained in the database referenced by Assigned numbers RFC
			3232[4].
	o "hwaddr" is Access Concentrator hardware address.		o "hwaddr" is Access Concentrator hardware address.
	5.2. Generating DHCPLEASEQUERY Message		5.2. Generating DHCPLEASEQUERY Message
	When a data packet is received from a host, Access Concentrator MAY		When a data packet is received from a host, Access Concentrator may
	verify if it has location/lease information for the source IP address		verify if it has location/lease information for the source IP address
	or source MAC address of data packet received. Similarly when Access		or source MAC address of data packet received. Similarly when Access
	Concentrator receives a data packet from upstream interface, it MAY		Concentrator receives a data packet from upstream interface, it may
	verify location/lease information for the destination IP address or		verify location/lease information for the destination IP address or
	destination MAC address of the data packet. An Access Concentrator		destination MAC address of the data packet. An Access Concentrator
	would typically generate DHCPLEASEQUERY message if the location/lease		would typically generate DHCPLEASEQUERY message if the location/lease
	information is not available for the corresponding IP address or MAC		information is not available for the corresponding IP address or MAC
	address assuming that it has lost the location/lease information		address assuming that it has lost the location/lease information
	during last reboot. The DHCPLEASEQUERY message uses the DHCP message		during last reboot. The DHCPLEASEQUERY message uses the DHCP message
	format as described in RFC 2131 [2], and uses message number 10 in		format as described in RFC 2131 [2], and uses message number 10 in
	the DHCP Message Type option (option 53). The DHCPLEASEQUERY message		the DHCP Message Type option (option 53). The DHCPLEASEQUERY message
	has the following pertinent message contents:		has the following pertinent message contents:
	o "giaddr" field MUST not be set. Though RFC 4388 mandates that an		o "giaddr" field MUST NOT be set. Though RFC 4388 mandates that an
	Access Concentrator [in layer 3 mode] MUST set the "giaddr" field,		Access Concentrator [in layer 3 mode] MUST set the "giaddr" field,
	this document suggest that an Access Concentrator acting as		this document suggest that an Access Concentrator acting as
	Transparent Bridge MUST not set the "giaddr" field.		Transparent Bridge MUST not set the "giaddr" field.
	o Access concentrator which can receives a unicast reply for		o Access concentrator which can receive a unicast reply for
	DHCPLEASEQUERY message SHOULD add option "access-concentrator-		DHCPLEASEQUERY message SHOULD add option "access-concentrator-
	hwaddr" in DHCPLEASEQUERY message. Option "access-concentrator-		hwaddr" in DHCPLEASEQUERY message. Option "access-concentrator-
	hwaddr" SHOULD be populated based on the interface on which this		hwaddr" SHOULD be populated based on the interface on which this
	request is sent out. This option MUST be added as the last option		request is sent out.
	[but before 'End Option' 255] in the DHCPLEASEQUERY message.
	o TTL value in IP header MUST be set to 1. This is to make sure		o TTL value in IP header MUST be set to 255. This is to make sure
	that this packet is not forwarded beyond the Access Concentrator's		that this packet is not forwarded beyond the Access Concentrator's
	LAN.		LAN.
	o The Parameter Request List option (option 55) MUST include the		o The Parameter Request List option (option 55) MUST include the
	Relay Agent Information option (option 82).		Relay Agent Information option (option 82).
	o All the other options in Parameter Request List option (option 55)		o All the other options in Parameter Request List option (option 55)
	SHOULD be set as per the interest of the requester. The		SHOULD be set as per the interest of the requester. The
	interesting options are likely to include the IP Address Lease		interesting options are likely to include the IP Address Lease
	Time option (option 51) and possibly the Vendor class identifier		Time option (option 51) and possibly the Vendor class identifier
	skipping to change at page 10, line 49 ¶		skipping to change at page 10, line 49 ¶
	o Destination MAC address of the DHCPLEASEQUERY message MUST be set		o Destination MAC address of the DHCPLEASEQUERY message MUST be set
	to FF:FF:FF:FF:FF:FF.		to FF:FF:FF:FF:FF:FF.
	o Source MAC address of the DHCPLEASEQUERY message MUST be set to		o Source MAC address of the DHCPLEASEQUERY message MUST be set to
	the hardware address of the interface on which this request is		the hardware address of the interface on which this request is
	sent out.		sent out.
	All other fields in MAC header, IP header and DHCP header SHOULD be		All other fields in MAC header, IP header and DHCP header SHOULD be
	set as per RFC 2131 [2]. Additional details concerning different		set as per RFC 2131 [2]. Additional details concerning different
	query types are same as defined in RFC 4388 [4].		query types are same as defined in RFC 4388 [5].
	5.3. Handling DHCPLEASEQUERY Message in Layer-3 Relay Agent		5.3. Handling DHCPLEASEQUERY Message in Layer-3 Relay Agent
	A Layer-3 Relay Agent conforming to this document, MUST process the		A Layer-3 Relay Agent conforming to this document, MUST process the
	DHCP LEASEQUERY message received on its downstream interface. While		DHCP LEASEQUERY message received on its downstream interface. While
	processing a DHCPLEASEQUERY message, it MUST verify following:		processing a DHCPLEASEQUERY message, it MUST verify following:
	o If "giaddr" field is already set, "giaddr" field is not touched		o If "giaddr" field is already set, "giaddr" field is not touched
	and the DHCP request is forwarded as per [2].		and the DHCP request is forwarded as per RFC 2131 [2].
	o TTL value in IP header MUST be 1. If it is any other value, this		o TTL value in IP header MUST be 255. If it is any other value,
	packet MUST be silently discarded.		this packet MUST be silently discarded.
	After verifying the received DHCPLEASEQUERY request packet, Relay		After verifying the received DHCPLEASEQUERY request packet, Relay
	Agent should modify the DHCPLEASEQUERY request packet. The		Agent should modify the DHCPLEASEQUERY request packet. The
	DHCPLEASEQUERY message has the following pertinent message contents:		DHCPLEASEQUERY message has the following pertinent message contents:
	o "giaddr" field MUST be set to the primary IP address of the		o "giaddr" field MUST be set to the primary IP address of the
	interface on which this DHCPLEASEQUERY request has been received.		interface on which this DHCPLEASEQUERY request has been received.
	o No other fields in DHCP header needs to be changed.		o No other fields in DHCP header needs to be changed.
	o Source IP address of IP header MAY be set to either the primary IP		o Source IP address of IP header MAY be set to either the primary IP
	address of the interface on which this DHCPLEASEQUERY request has		address of the interface on which this DHCPLEASEQUERY request has
	been received or to the IP address of the Interface on which this		been received or to the IP address of the Interface on which this
	request will be sent out.		request will be sent out.
	o Destination IP address in IP header MUST be set to the IP address		o Destination IP address in IP header MUST be set to the IP address
	of the DHCP server.		of the DHCP server.
	o Rest of the fields in IP header and DHCP header should be set as		o Rest of the fields in IP header and DHCP header should be set as
	per [2].		per RFC 2131 [2].
			o As per RFC 3046 [3], Layer 3 Relay Agent SHALL add Relay Agent
			Information option to DHCP messages before forwarding them to the
			DHCP server. As explained in section 3, in layer 2 networks,
			layer 2 Relay Agent adds Relay Agent Information options to DHCP
			messages but does not populate "giaddr" before forwarding it to
			layer 3 Relay Agent. In case of DHCPLEASEQUERY message, layer 2
			Relay Agent does not add Relay Agent Information option and so a
			Layer 3 Relay Agent may add Relay Agent Information assuming it as
			a normal DHCP message. A Layer 3 Relay Agent conforming to this
			document MUST NOT add Relay Agent Information option to the
			DHCPLEASEQUERY messages generated by a Layer 2 Relay Agent.
	In Layer-3 environment, RFC 4388 does not recommend how to set the		In Layer-3 environment, RFC 4388 does not recommend how to set the
	"giaddr" field in DHCPLEASEQUERY message. While generating a		"giaddr" field in DHCPLEASEQUERY message. While generating a
	DHCPLEASEQUERY message, a Layer-3 Relay Agent conforming to this		DHCPLEASEQUERY message, a Layer-3 Relay Agent conforming to this
	document MUST always set the "giaddr" field to the primary IP address		document MUST always set the "giaddr" field to the primary IP address
	of the interface on which DHCPLEASEQUERY message will be sent. As		of the interface on which DHCPLEASEQUERY message will be sent. As
	described above, while receiving a DHCP reply, this helps Layer-3		described above, while receiving a DHCP reply, this helps Layer-3
	Relay Agent to identify if it had generated a DHCPLEASEQUERY message		Relay Agent to identify if it had generated a DHCPLEASEQUERY message
	or relayed it from an Access Concentrator.		or relayed it from an Access Concentrator.
	5.4. Handling DHCPLEASEQUERY Message in DHCP Server		5.4. Handling DHCPLEASEQUERY Message in DHCP Server
	DHCP servers conforming to this document MUST echo the entire		DHCP servers conforming to this document MUST echo the entire
	contents of the "access-concentrator-hwaddr" option [code 'X'] in the		contents of the "access-concentrator-hwaddr" option [code 'X'] in the
	reply. DHCP servers SHALL NOT place the echoed "access-concentrator-		reply for a DHCPLEASEQUERY request. DHCP servers SHALL NOT place the
	hwaddr" option in the overloaded sname or file fields. If a server		echoed "access-concentrator-hwaddr" option in the overloaded sname or
	is unable to copy a full "access-concentrator-hwaddr" option into a		file fields. If a server is unable to copy a full "access-
	response, it SHALL send the response without the "access-		concentrator-hwaddr" option into a response, it SHALL send the
	concentrator-hwaddr" option, and SHOULD increment an error counter		response without the "access-concentrator-hwaddr" option, and SHOULD
	for the situation.		increment an error counter for the situation.
	This document does not propose any other changes to RFC 4388 [4]. for		DHCP Server MUST NOT add or echo back this option in any other DHCP
			reply messages it generates.
			This document does not propose any other changes to RFC 4388 [5] for
	handling DHCPLEASEQUERY message in DHCP server.		handling DHCPLEASEQUERY message in DHCP server.
	5.5. Handling DHCP Reply Message in Layer-3 Relay Agent		5.5. Handling DHCP Reply Message in Layer-3 Relay Agent
	When Layer-3 Relay Agent receives a DHCP Reply message with message		When Layer-3 Relay Agent receives a DHCP Reply message with message
	type as DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN, it		type as DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN, it
	first verifies the destination IP address. Following options are		first verifies the destination IP address. Following options are
	considered:		considered:
	o If the destination IP address of the DHCP reply packet is same as		o If the destination IP address of the DHCP reply packet is same as
	the primary IP address of the interface this reply has been		the primary IP address of the interface this reply has been
	received, it is assumed that this request was generated by the		received, it is assumed that this request was generated by the
	Layer-3 Relay Agent. So it should not forward this DHCP Reply		Layer-3 Relay Agent. It SHOULD NOT forward this DHCP Reply
	message.		message.
	o If the destination IP address of the DHCP reply packet is same as		o If the destination IP address of the DHCP reply packet is same as
	the primary IP address of any of the outgoing interfaces except		the primary IP address of any of the outgoing interfaces except
	the one on which the reply was received, it is assumed that the		the one on which the reply was received, it is assumed that the
	request was generated by an Access Concentrator and so Layer-3		request was generated by an Access Concentrator and so Layer-3
	Relay Agent should forward this Reply message. Outgoing interface		Relay Agent should forward this Reply message. Outgoing interface
	for the DHCP reply would be the one which has the same IP address		for the DHCP reply would be the one which has the same IP address
	as the destination IP address.		as the destination IP address.
	skipping to change at page 13, line 10 ¶		skipping to change at page 13, line 23 ¶
	hardware address and use it to unicast the reply to the Access		hardware address and use it to unicast the reply to the Access
	Concentrator. If it does not find this option, it SHOULD		Concentrator. If it does not find this option, it SHOULD
	broadcast this reply over the outgoing interface identified as		broadcast this reply over the outgoing interface identified as
	above.		above.
	5.6. Handling DHCP Reply Message in Access Concentrator		5.6. Handling DHCP Reply Message in Access Concentrator
	5.6.1. Handling DHCPLEASEUNASSIGNED Reply Message		5.6.1. Handling DHCPLEASEUNASSIGNED Reply Message
	When a DHCPLEASEUNASSIGNED message is received by Access		When a DHCPLEASEUNASSIGNED message is received by Access
	Concentrator, that means that there is no currently active lease for		Concentrator, that means that there is no active lease for the IP
	the IP address present in the DHCP server, but that a server does in		address present in the DHCP server, but that a server does in fact
	fact manage that IP address. Access Concentrator SHOULD cache this		manage that IP address. Access Concentrator SHOULD cache this
	information for later use.		information for later use.
	5.6.2. Handling DHCPLEASEUNKNOWN Reply Message		5.6.2. Handling DHCPLEASEUNKNOWN Reply Message
	When a DHCPLEASEUNKNOWN message is received by Access Concentrator,		When a DHCPLEASEUNKNOWN message is received by Access Concentrator,
	it SHOULD cache this information but only for a short lifetime,		it SHOULD cache this information but only for a short lifetime,
	approximately for 5 minutes as suggested in RFC 4388 [4].		approximately for 5 minutes as suggested in RFC 4388 [5].
	5.6.3. Handling DHCPLEASEACTIVE Reply Message		5.6.3. Handling DHCPLEASEACTIVE Reply Message
	When Access Concentrator receives a DHCPLEASEACTIVE message, it MUST		When Access Concentrator receives a DHCPLEASEACTIVE message, it MUST
	update its location/lease information.		update its location/lease information.
	5.6.4. Handling No Response to the DHCPLEASEQUERY Message		5.6.4. Handling multiple responses for DHCPLEASEQUERY Message
	This has been discussed in detail in RFC 4388 [4] and the same holds		A Layer 3 Relay Agent can forward a DHCPLEASEQUERY request to more
			than one DHCP server and so a Layer 2 Relay Agent may receive more
			than one reply for a DHCPLEASEQUERY message.
			A Layer 2 Relay Agent MUST be able to process multiple responses for
			a DHCPLEASEQUERY message. For example:
			o It should be able to ignore all other responses once it receives
			DHCPLEASEACTIVE response from one of the DHCP server.
			5.6.5. Handling No Response to the DHCPLEASEQUERY Message
			This has been discussed in detail in RFC 4388 [5] and the same holds
	good for this document as well.		good for this document as well.
	5.6.5. Handling DHCPLEASEQUERY messages not belonging to Access		5.6.6. Handling DHCPLEASEQUERY messages not belonging to Access
	Concentrator		Concentrator
	o Since Layer 3 Relay Agent can broadcast the reply of		o Since Layer 3 Relay Agent can broadcast the reply of
	DHCPLEASEQUERY message, it will be processed by all the Access		DHCPLEASEQUERY message, it will be processed by all the Access
	Concentrators connected to the same LAN. Using Relay Agent		Concentrators connected to the same LAN. Using either Transaction
	Information Option, an Access Concentrator should be able to		Id or Relay Agent Information Option, an Access Concentrator
	correctly identify if the DHCPLEASEQUERY response is meant for		should be able to correctly identify if the DHCPLEASEQUERY
	itself. Responses which does not belong to an Access Concentrator		response is meant for itself. Responses which does not belong to
	MUST be silently discarded.		an Access Concentrator MUST be silently discarded.
	o In a typical bridged network, multiple Access Concentrators may		o In a typical bridged network, multiple Access Concentrators may
	share the same LAN. As DHCPLEASEQUERY message generated by an		share the same LAN. As DHCPLEASEQUERY message generated by an
	Access Concentrator is broadcast, it will be received by other		Access Concentrator is broadcast, it will be received by other
	Access Concentrators also. Access Concentrators MUST silently		Access Concentrators also. Access Concentrators MUST silently
	discard any DHCPLEASEQUERY message received on its upstream		discard any DHCPLEASEQUERY message received on its upstream
	interface.		interface.
	6. Security Consideration		6. Lease query using Management IP address of Access Concentrator
			Though rare, but if an Access Concentrator allows the use of
			Management IP address for communication with DHCP server, it can
			generate DHCPLEASEQUERY message as described in RFC 4388 instead of
			using the extension of DHCPLEASEQUERY message described in this
			document.
			7. Security Consideration
	o Access Networks flood traffic to all the ports if the destination		o Access Networks flood traffic to all the ports if the destination
	MAC is not present in MAC Learning table. The lease/location		MAC is not present in MAC Learning table. The lease/location
	information obtained by snooping the DHCP messages and refreshed		information obtained by snooping the DHCP messages and refreshed
	using DHCPLEASEQUERY mechanism, can be used to prevent this		using DHCPLEASEQUERY mechanism, can be used to prevent this
	flooding.		flooding.
	o If a Layer 2 Relay Agent, Layer 3 Relay Agent or DHCP server does		o If a Layer 2 Relay Agent, Layer 3 Relay Agent or DHCP server does
	not support the new option "access-concentrator-hwaddr", a Layer 3		not support the new option "access-concentrator-hwaddr", a Layer 3
	Relay Agent would broadcast the response of the DHCPLEASEQUERY to		Relay Agent would broadcast the response of the DHCPLEASEQUERY to
	the Access Concentrator. This response will be processed by all		the Access Concentrator. This response will be processed by all
	the Access Concentrators on the same LAN. This increases		the Access Concentrators on the same LAN. This increases
	unnecessary cpu processing on the Access Concentrator on the same		unnecessary cpu processing on the Access Concentrator on the same
	LAN.		LAN.
			o DHCP servers SHOULD prevent exposure of location information
			(particularly the mapping of hardware address to IP address lease,
			which can be an invasion of broadband subscriber privacy) by
			employing the techniques detailed in RFC3118[6].
			o Layer 3 Relay Agent that relays the DHCPLEASEQUERY message are
			essentially DHCP clients for the purposes of the DHCPLEASEQUERY
			messages generated by Layer 2 Relay Agent. Layer 3 Relay Agent
			MUST relay a DHCPLEASEQUERY message only when it comes from a
			trusted circuit. Thus, RFC3118[6] is an appropriate mechanism for
			DHCPLEASEQUERY messages.
			o Since RFC3118[6] discusses the normal DHCP client interaction,
			consisting of a DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, and DHCPACK,
			it is necessary to transpose the operations described in RFC3118
			[6] to the DHCPLEASEQUERY domain. The operations described in
			RFC3118 [6] for DHCPDISCOVER are performed for DHCPLEASEQUERY and
			the operations described for DHCPOFFER are performed for
			DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, and DHCPLEASEUNKNOWN
			messages.
	o All other security aspects are same as mentioned in "Security		o All other security aspects are same as mentioned in "Security
	Consideration" section of RFC 4388 [4].		Consideration" section of RFC 4388 [5].
	7. IANA Considerations		8. IANA Considerations
	This document needs IANA to provide a unique number for the new		This document needs IANA to provide a unique number for the new
	option to carry Hardware address of an Access Concentrator. Please		option to carry Hardware address of an Access Concentrator. Please
	refer to section 5.1 for more details.		refer to section 5.1 for more details.
	8. Acknowledgments		9. Acknowledgments
	Andre Kostur provided good feedback on this memo. A detailed		Stig and Andre Kostur provided good feedback on this memo. A
	discussion with Ted Lemon, Andre Kostur, Stefaan and David W.		detailed discussion with Ted Lemon, Andre Kostur, Stefaan and David
	Hankinson on how a Layer 3 Relay Agent can unicast the DHCP reply to		W. Hankinson on how a Layer 3 Relay Agent can unicast the DHCP reply
	an Access Concentrator was very helpful.		to an Access Concentrator was very helpful.
	9. References		Description of authentication for DHCPLEASEQUERY messages in security
			section are taken from RFC 4388.
	9.1. Normative Reference		10. References
			10.1. Normative Reference
	[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119, March 1997.		Levels", BCP 14, RFC 2119, March 1997.
	[2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,		[2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
	March 1997.		March 1997.
	[3] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046,		[3] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046,
	January 2001.		January 2001.
	[4] Woundy, R. and K. Kinnear, "Dynamic Host Configuration Protocol		[4] Reynolds, J., "IANA Assigned Numbers", RFC 3232, January 2002.
			[5] Woundy, R. and K. Kinnear, "Dynamic Host Configuration Protocol
	(DHCP) Leasequery", RFC 4388, February 2006.		(DHCP) Leasequery", RFC 4388, February 2006.
	9.2. Informative Reference		[6] Droms, R. and B. Arbaugh, "Authentication for DHCP Messages",
			RFC 3118, June 2001.
	[5] Croft, B. and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951,		10.2. Informative Reference
			[7] Croft, B. and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951,
	September 1985.		September 1985.
	[6] Wimer, W., "Clarifications and Extensions for the Bootstrap		[8] Wimer, W., "Clarifications and Extensions for the Bootstrap
	Protocol", RFC 1542, October 1993.		Protocol", RFC 1542, October 1993.
	[7] Droms, R. and S. Alexander, "DHCP Options and BOOTP Vendor		[9] Droms, R. and S. Alexander, "DHCP Options and BOOTP Vendor
	Extensions", RFC 2132, March 1997.		Extensions", RFC 2132, March 1997.
	Authors' Addresses		Authors' Addresses
	Bharat joshi		Bharat joshi
	Infosys Technologies Ltd.		Infosys Technologies Ltd.
	44 Electronics City, Hosur Road		44 Electronics City, Hosur Road
	Bangalore 560 100		Bangalore 560 100
	India		India
End of changes. 49 change blocks.
	84 lines changed or deleted		152 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/