draft-ietf-dhc-l2ra-extensions-00.txt   draft-ietf-dhc-l2ra-extensions-01.txt 
DHC Working Group B. Joshi DHC Working Group B. Joshi
Internet-Draft P. Kurapati Internet-Draft P. Kurapati
Expires: December 16, 2008 M. Kamath Expires: August 29, 2009 M. Kamath
Infosys Technologies Ltd. Infosys Technologies Ltd.
S. De Cnodder S. De Cnodder
Alcatel-Lucent Alcatel-Lucent
June 14, 2008 February 25, 2009
Extensions to Layer 2 Relay Agent Extensions to Layer 2 Relay Agent
draft-ietf-dhc-l2ra-extensions-00.txt draft-ietf-dhc-l2ra-extensions-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
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.
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 December 16, 2008. This Internet-Draft will expire on August 29, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
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 a transparent bridge in Layer 2 mode. These Access to act as a transparent bridge in Layer 2 mode. These Access
Concentrators also act as Layer 2 relay agents. Layer 2 Relay Agent Concentrators also act as Layer 2 relay agents. Layer 2 Relay Agent
functionality does not provide means to avoid flooding of DHCP functionality does not provide means to avoid flooding of DHCP
messages and also needs to be extended to support DHCP LeaseQuery messages and also needs to be extended to support DHCP LeaseQuery
skipping to change at page 2, line 31 skipping to change at page 2, line 39
Agent . . . . . . . . . . . . . . . . . . . . . . . . 10 Agent . . . . . . . . . . . . . . . . . . . . . . . . 10
5.2.3. Handling DHCPLEASEQUERY Message in DHCP Server . . . . 10 5.2.3. Handling DHCPLEASEQUERY Message in DHCP Server . . . . 10
5.2.4. Handling DHCP Reply Message in Layer 3 Relay Agent . . 10 5.2.4. Handling DHCP Reply Message in Layer 3 Relay Agent . . 10
5.2.5. Handling DHCP Reply Message in Layer 2 Relay Agent . . 11 5.2.5. Handling DHCP Reply Message in Layer 2 Relay Agent . . 11
5.3. DHCPLEASEQUERY using Management IP address of Layer 2 5.3. DHCPLEASEQUERY using Management IP address of Layer 2
Relay Agent . . . . . . . . . . . . . . . . . . . . . . . 12 Relay Agent . . . . . . . . . . . . . . . . . . . . . . . 12
6. Prevention of flooding of DHCP replies from Layer 3 Relay 6. Prevention of flooding of DHCP replies from Layer 3 Relay
Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Flooding of DHCP reply messages from Layer 3 Relay 6.1. Flooding of DHCP reply messages from Layer 3 Relay
Agent . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Agent . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1.1. Unicast-Address Sub-Option . . . . . . . . . . . . . . 13 6.1.1. Unicast-Address Sub-Option . . . . . . . . . . . . . . 14
6.2. Flooding of DHCPLEASEQUERY reply messages from Layer 3 6.2. Flooding of DHCPLEASEQUERY reply messages from Layer 3
Relay Agent . . . . . . . . . . . . . . . . . . . . . . . 15 Relay Agent . . . . . . . . . . . . . . . . . . . . . . . 16
6.2.1. Relay Agent Hardware Address option . . . . . . . . . 16 6.2.1. Relay Agent Hardware Address option . . . . . . . . . 16
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
8. Security Consideration . . . . . . . . . . . . . . . . . . . . 19 8. Security Consideration . . . . . . . . . . . . . . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative Reference . . . . . . . . . . . . . . . . . . . 21 10.1. Normative Reference . . . . . . . . . . . . . . . . . . . 21
10.2. Informative Reference . . . . . . . . . . . . . . . . . . 21 10.2. Informative Reference . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 23
1. Introduction 1. Introduction
DHCP Relay Agents eliminate the necessity of having a DHCP server on DHCP Relay Agents eliminate the necessity of having a DHCP server on
each physical network. RFC 3046 [3] defines a new option 'Relay each physical network. [RFC3046] defines a new option 'Relay Agent
Agent Information' which is added to DHCP messages by Relay Agents. Information' which is added to DHCP messages by Relay Agents. DHCP
DHCP servers may use this option for IP address and other parameter servers may use this option for IP address and other parameter
assignment policies. assignment policies.
In case of Layer 2 Access Networks, Access Concentrators typically In case of Layer 2 Access Networks, Access Concentrators typically
act as Layer 2 Relay Agents [7]. act as Layer 2 Relay Agents [draft-ietf-dhc-l2ra].
This document proposes enhancements in Layer 2 Relay Agent [7] which This document proposes enhancements in Layer 2 Relay Agent
addresses issues like flooding between Layer 3 Relay Agent and Layer [draft-ietf-dhc-l2ra] which addresses issues like flooding between
2 Relay Agent and retrieving lease information from server using DHCP Layer 3 Relay Agent and Layer 2 Relay Agent and retrieving lease
leasequery mechanism. information from server using DHCP leasequery mechanism.
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 [RFC2119].
This document uses the following terms: This document uses the following terms:
o "Access Concentrator" o "Access Concentrator"
An Access Concentrator is a router or switch at the broadband access An Access Concentrator is a router or switch at the broadband access
provider's edge of a public broadband access network. This document provider's edge of a public broadband access network. This document
assumes that the Access Concentrator acts as a Transparent Bridge and assumes that the Access Concentrator acts as a Transparent Bridge and
includes the DHCP relay agent functionality. For example: In DSL includes the DHCP relay agent functionality. For example: In DSL
environment, this is typically known as DSLAM.(Digital Subscriber environment, this is typically known as DSLAM.(Digital Subscriber
Line Access Multiplexer) Line Access Multiplexer)
o "DHCP client" o "DHCP client"
A DHCP client is an Internet host using DHCP to obtain configuration A DHCP client is an Internet host using DHCP to obtain configuration
parameters such as a network address. parameters such as a network address.
o "IPoA"
IP over AAL5: One of the call types used in xDSL networks where CPE
acts as a routing device and encapsulates IP frames directly inside
ATM Adaptation Layer 5.
o "Layer 3 Relay Agent" o "Layer 3 Relay Agent"
A Layer 3 Relay Agent is a third-party agent that transfers Bootstrap A Layer 3 Relay Agent is a third-party agent that transfers Bootstrap
Protocol (BOOTP) and DHCP messages between clients and servers Protocol (BOOTP) and DHCP messages between clients and servers
residing on different subnets, per RFC951 [8] and RFC1542[9]. 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 DHCP Downstream is the direction from the edge network towards the DHCP
Clients. Clients.
skipping to change at page 6, line 8 skipping to change at page 6, line 8
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 DHCP Clients towards the edge Upstream is the direction from the DHCP Clients towards the edge
network. network.
3. Enhancements in Layer 2 Relay Agent 3. Enhancements in Layer 2 Relay Agent
This section looks at various enhancements possible in Layer 2 Relay This section looks at various enhancements possible in Layer 2 Relay
Agents. Following issues are seen in a typical Layer 2 Relay Agents. Following issues are seen in a typical Layer 2 Relay Agent
Agent[7] deployments [draft-ietf-dhc-l2ra] deployments
o Broadcasting DHCP requests on all interfaces o Broadcasting DHCP requests on all interfaces
A normal Layer 2 Relay Agent[7] would broadcast a DHCP request A normal Layer 2 Relay Agent [draft-ietf-dhc-l2ra] would broadcast a
message to all its interfaces except on which the message was DHCP request message to all its interfaces except on which the
received. Because of this, a DHCP request message is received by message was received. Because of this, a DHCP request message is
those devices which would not be interested in it. Configuring an received by those devices which would not be interested in it.
uplink port that leads to a Layer 3 Relay Agent or DHCP server can Configuring an uplink port that leads to a Layer 3 Relay Agent or
solve this issue. Some of the existing implementations [Mostly in DHCP server can solve this issue. Some of the existing
xDSL Access Concentrators] already supports this. implementations [Mostly in xDSL Access Concentrators] already
supports this.
o Recovering Lease Information from Server o Recovering Lease Information from Server
A Layer 2 Relay Agent[7] may snoop DHCP messages and maintain the A Layer 2 Relay Agent [draft-ietf-dhc-l2ra] may snoop DHCP messages
lease information. This information is lost if the Layer 2 Relay and maintain the lease information. This information is lost if the
Agent reboots. RFC 4388 suggests Leasequery mechanism to get the Layer 2 Relay Agent reboots. [RFC4388] suggested Leasequery
lease information from the server. This document extends the same mechanism to get the lease information from the server. This
for Layer 2 Relay Agent. document extends the same for Layer 2 Relay Agent.
o Layer 3 Relay Agent broadcasting DHCP replies o Layer 3 Relay Agent broadcasting DHCP replies
Layer 3 Relay Agents generally broadcast DHCP replies towards Layer 2 Layer 3 Relay Agents generally broadcast DHCP replies towards Layer 2
Relay Agents. This will be received by those devices which would not Relay Agents. This will be received by those devices which would not
be interested in it. In general, broadcasts should be avoided in be interested in it. In general, broadcasts should be avoided in
Layer 2 networks. A new sub-option in Relay Agent Information option Layer 2 networks. A new sub-option in Relay Agent Information option
can be used to solve this issue. To avoid broadcasts in case of can be used to solve this issue. To avoid broadcasts in case of
replies to Leasequery, a new option is defined. replies to Leasequery, a new option is defined.
skipping to change at page 9, line 9 skipping to change at page 9, line 9
broadcast domain except the interface on which it was received. This broadcast domain except the interface on which it was received. This
leads to flooding of DHCP messages which is unnecessary. Hence there leads to flooding of DHCP messages which is unnecessary. Hence there
is a need to identify an "Uplink Port", through which the DHCP is a need to identify an "Uplink Port", through which the DHCP
request messages could be relayed towards the DHCP server. The request messages could be relayed towards the DHCP server. The
uplink port SHOULD be a configurable parameter. uplink port SHOULD be a configurable parameter.
5. Extension of DHCPLEASEQUERY for Layer 2 Relay Agent 5. Extension of DHCPLEASEQUERY for Layer 2 Relay Agent
5.1. Protocol Extension Overview 5.1. Protocol Extension Overview
A Layer 2 Relay Agent [7] may want to maintain the information of A Layer 2 Relay Agent [draft-ietf-dhc-l2ra] may need to maintain the
outgoing interface, MAC Address, IP address and Lease information for information of outgoing interface, MAC Address, IP address and Lease
each DHCP Client. This information [MAC-IP-Interface Binding] could information for each DHCP Client. This information [MAC-IP-Interface
be used to prevent MAC/IP Spoofing attacks. It could also be used Binding] is mostly used to prevent MAC/IP Spoofing attacks by
for bridging frames. Maintain this information makes a Layer 2 Relay installing anti-spoofing filters. It could also be used for bridging
Agent vulnerable to the same issue [location/lease information lost frames. Maintain this information makes a Layer 2 Relay Agent
when Layer 2 Relay Agent gets rebooted] which has been addressed in vulnerable to the same issue [location/lease information lost when
RFC 4388 [5] for Layer 3 networks. This document extends mechanism Layer 2 Relay Agent gets rebooted] which has been addressed in
proposed in [5] to address this issue for layer 2 networks. [RFC4388] for Layer 3 networks. This document extends mechanism
proposed in [RFC4388] to address this issue for layer 2 networks.
When Layer 2 Relay Agent needs to bridge a frame, it MAY refer to
location/lease information to verify the IP address or MAC address.
If the location/lease information is not available, it can query DHCP
server to obtain the lease/location information using DHCPLEASEQUERY
message.
A Layer 2 Relay Agent can generate a DHCPLEASEQUERY [Query by IP When a Layer 2 Relay Agent reboots, it can obtain the lease
address, MAC address, client identifier [10]] with all the fields information by using DHCPLEASEQUERY message. The DHCPLEASEQUERY
properly populated as defined in RFC 4388 [5]. message can be generated with data driven approach by using Query by
IP address, MAC address or Client Identifier with all the fields
populated as defined in [RFC4388] or with a new non-data driven
approach by using Query by remote-id as defined in
[draft-ietf-dhc-leasequery-by-remote-id]
5.2. Protocol Extension Details 5.2. Protocol Extension Details
5.2.1. Generating DHCPLEASEQUERY Message 5.2.1. Generating DHCPLEASEQUERY Message
When a data packet is received from a host, Layer 2 Relay Agent [7] For data driven lease query approach, when a packet is received from
may verify if it has location/lease information for the source IP a host, Layer 2 Relay Agent [draft-ietf-dhc-l2ra] may verify if it
address or source MAC address of data packet received. Similarly has location/lease information for the source IP address or source
when Layer 2 Relay Agent receives a data packet from the uplink port, MAC address of data packet received. Similarly a Layer 2 Relay Agent
it may verify location/lease information for the destination IP may verify if it has location/lease information for a given user
address or destination MAC address of the data packet. A Layer 2 connection as soon as the device comes up or a specific connection
Relay Agent would typically generate DHCPLEASEQUERY message if the comes up. A Layer 2 Relay Agent would typically generate
location/lease information is not available for the corresponding IP DHCPLEASEQUERY message if the location/lease information is not
address or MAC address assuming that it has lost the location/lease available for the corresponding IP address or MAC address or
information during last reboot. The DHCPLEASEQUERY message uses the connection assuming that it has lost the location/lease information
DHCP message format as described in RFC 2131 [2], and uses message during last reboot. The DHCPLEASEQUERY message uses the DHCP message
number 10 in the DHCP Message Type option (option 53). The format as described in [RFC2131], and uses message number 10 in the
DHCPLEASEQUERY message has the following pertinent message contents: DHCP Message Type option (option 53). The DHCPLEASEQUERY message has
the following pertinent message contents:
o "giaddr" field MUST NOT be set. Though RFC 4388 [5] mandates that o "giaddr" field MUST NOT be set. Though [RFC4388] mandates that an
an Access Concentrator [in Layer 3 mode] 'MUST' set the "giaddr" Access Concentrator [in Layer 3 mode] 'MUST' set the "giaddr"
field, this document suggest that a Layer 2 Relay Agent acting as field, this document suggest that a Layer 2 Relay Agent acting as
Transparent Bridge must not set the "giaddr" field. Transparent Bridge must not set the "giaddr" field.
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 options SHOULD be set as per the interest of the requester. The options
of interest are likely to be the IP Address Lease Time option of interest are likely to be the IP Address Lease Time option
(option 51) and possibly the Vendor class identifier option (option 51) and possibly the Vendor class identifier option
skipping to change at page 10, line 28 skipping to change at page 10, line 28
to broadcast address 255.255.255.255. to broadcast address 255.255.255.255.
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 [RFC2131]. Additional details concerning different query
query types are same as defined in RFC 4388 [5]. types are same as defined in [RFC4388].
5.2.2. Handling DHCPLEASEQUERY Message in Layer 3 Relay Agent 5.2.2. 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 similar DHCP LEASEQUERY message received on its downstream interface similar
to the other DHCP messages. to the other DHCP messages.
5.2.3. Handling DHCPLEASEQUERY Message in DHCP Server 5.2.3. Handling DHCPLEASEQUERY Message in DHCP Server
While generating a DHCP reply for a DHCPLEASEQUERY message, if the DHCP server prepares the reply to the DHCPLEASEQUERY message as
message type is DHCPLEASEUNASSIGNED or DHCPLEASEUNKNOWN, it MUST echo desribed in [RFC4388] and [draft-ietf-dhc-leasequery-by-remote-id].
back the Relay Agent Information received in the DHCPLEASEQUERY
message. If the message type is DHCPLEASEACTIVE, DHCP server
prepares the message as described in RFC 4388 and ignores the Relay
Agent Information option received in the DHCPLEASEQUERY message.
This document does not propose any other changes to RFC 4388 [5] for
handling DHCPLEASEQUERY message in DHCP server.
5.2.4. Handling DHCP Reply Message in Layer 3 Relay Agent 5.2.4. 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
must have a way to identify if it had generated the leasequery must have a way to identify if it had generated the leasequery
message or it had relayed it for a Layer 2 Relay Agent. message or it had relayed it for a Layer 2 Relay Agent.
When the DHCP Reply message is received, a Layer 3 Relay Agent may When the DHCP Reply message is received, a Layer 3 Relay Agent may
use 'giaddr' or 'state information' to identify the outgoing use 'giaddr' or 'state information' to identify the outgoing
interface. interface.
5.2.5. Handling DHCP Reply Message in Layer 2 Relay Agent 5.2.5. Handling DHCP Reply Message in Layer 2 Relay Agent
5.2.5.1. Handling DHCPLEASEUNASSIGNED Reply Message 5.2.5.1. Handling DHCPLEASEUNASSIGNED Reply Message
When a DHCPLEASEUNASSIGNED message is received by a Layer 2 Relay When a DHCPLEASEUNASSIGNED message is received by a Layer 2 Relay
Agent, it means that there is no active lease for the IP address Agent, it means that there is no active lease for the IP address
present in the DHCP server, but that a server does in fact manage present in the DHCP server, but that a server does in fact manage
that IP address. Layer 2 Relay Agent SHOULD cache this information that IP address. Layer 2 Relay Agent can use this information to
for later use. discard the relevant data streams matching this reply. For data
driven query approach as defined in [RFC4388] Relay Agent MAY decide
to cache this entry to avoid sending a similar query to the server
again. If a query by remote-id
[draft-ietf-dhc-leasequery-by-remote-id] is used caching MAY be
avoided.
5.2.5.2. Handling DHCPLEASEUNKNOWN Reply Message 5.2.5.2. Handling DHCPLEASEUNKNOWN Reply Message
When a DHCPLEASEUNKNOWN message is received by Layer 2 Relay Agent, When a DHCPLEASEUNKNOWN message is received by Layer 2 Relay Agent,
it SHOULD cache this information but only for a short lifetime, it SHOULD cache this information for data driven approach but only
approximately for 5 minutes as suggested in RFC 4388 [5]. for a short lifetime, approximately for 5 minutes as suggested in
[RFC4388]. For query by remote-id
[draft-ietf-dhc-leasequery-by-remote-id] this caching MAY be avoided.
5.2.5.3. Handling DHCPLEASEACTIVE Reply Message 5.2.5.3. Handling DHCPLEASEACTIVE Reply Message
When Layer 2 Relay Agent receives a DHCPLEASEACTIVE message, it MUST When Layer 2 Relay Agent receives a DHCPLEASEACTIVE message, it MUST
update its location/lease information. update its location/lease information.
5.2.5.4. Handling multiple responses for DHCPLEASEQUERY Message 5.2.5.4. Handling multiple responses for DHCPLEASEQUERY Message
A Layer 3 Relay Agent can forward a DHCPLEASEQUERY request to more 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 DHCP server and so a Layer 2 Relay Agent may receive more
than one reply for a DHCPLEASEQUERY message. than one reply for a DHCPLEASEQUERY message.
A Layer 2 Relay Agent MUST be able to process multiple responses for A Layer 2 Relay Agent MUST be able to process multiple responses for
a DHCPLEASEQUERY message. For example: a DHCPLEASEQUERY message. For example:
o It should be able to ignore all other responses once it receives o It should be able to ignore all other responses once it receives
DHCPLEASEACTIVE response from one of the DHCP server. DHCPLEASEACTIVE response from one of the DHCP server.
5.2.5.5. Handling No Response to the DHCPLEASEQUERY Message 5.2.5.5. Handling No Response to the DHCPLEASEQUERY Message
This has been discussed in detail in RFC 4388 [5] and the same holds This has been discussed in detail in [RFC4388] and the same holds
good for this document as well. good for this document as well.
5.2.5.6. Handling DHCPLEASEQUERY messages not belonging to Layer 2 5.2.5.6. Handling DHCPLEASEQUERY messages not belonging to Layer 2
Relay Agent Relay Agent
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 Layer 2 DHCPLEASEQUERY message, it will be processed by all the Layer 2
Relay Agents connected to the same LAN. Using either Transaction Relay Agents connected to the same LAN. Using either Transaction
Id or Relay Agent Information Option, a Layer 2 Relay Agent should Id or Relay Agent Information Option, a Layer 2 Relay Agent should
be able to correctly identify if the DHCPLEASEQUERY response is be able to correctly identify if the DHCPLEASEQUERY response is
meant for itself. Responses which do not belong to an Access meant for itself. Responses which do not belong to an Access
Concentrator MUST be silently discarded. Concentrator MUST be silently discarded.
o In a typical bridged network, multiple Layer 2 Relay Agents may o In a typical bridged network, multiple Layer 2 Relay Agents may
share the same LAN. As a DHCPLEASEQUERY message generated by a share the same LAN. As a DHCPLEASEQUERY message generated by a
skipping to change at page 13, line 12 skipping to change at page 13, line 12
using the extension of DHCPLEASEQUERY message described in this using the extension of DHCPLEASEQUERY message described in this
document. document.
6. Prevention of flooding of DHCP replies from Layer 3 Relay Agent 6. Prevention of flooding of DHCP replies from Layer 3 Relay Agent
Figure 1 shows an example where each access concentrator adds the Figure 1 shows an example where each access concentrator adds the
relay agent information option containing the port information of the relay agent information option containing the port information of the
host sending the DHCP messages. IP edge router relays these DHCP host sending the DHCP messages. IP edge router relays these DHCP
messages to the server. messages to the server.
RFC 2131[2] defines the meaning of the broadcast flag in the flags RFC 2131[RFC2131] defines the meaning of the broadcast flag in the
field: it indicates whether the client wishes to receive the flags field: it indicates whether the client wishes to receive the
DHCPOFFER and DHCPACK message as a broadcast or a unicast from the DHCPOFFER and DHCPACK message as a broadcast or a unicast from the
DHCP server or the DHCP relay agent. In the scenario of Figure 1, DHCP server or the DHCP relay agent. In the scenario of Figure 1,
this means that the IP edge router will broadcast the DHCPOFFER and this means that the IP edge router will broadcast the DHCPOFFER and
DHCPACK messages to all access concentrators if the broadcast flag is DHCPACK messages to all access concentrators if the broadcast flag is
set. Whether or not broadcast is used between the Layer 3 Relay set. Whether or not broadcast is used between the Layer 3 Relay
Agent and the trusted Layer 2 Relay Agents depends on the behavior of Agent and the trusted Layer 2 Relay Agents depends on the behavior of
the DHCP clients. However broadcasts in the aggregation network are the DHCP clients. However broadcasts in the aggregation network are
to be avoided. So it is preferred to always use unicast from the to be avoided. So it is preferred to always use unicast from the
Layer 3 DHCP relay agent to the trusted layer 2 DHCP relay agent. Layer 3 DHCP relay agent to the trusted layer 2 DHCP relay agent.
Between the trusted layer 2 DHCP relay agent and the host, broadcast Between the trusted layer 2 DHCP relay agent and the host, broadcast
flag has to be honored. flag has to be honored.
Even though the DHCP clients are not setting the broadcast flag, it Even though the DHCP clients are not setting the broadcast flag, it
is still possible that the DHCPOFFER and DHCPACK messages from the is still possible that the DHCPOFFER and DHCPACK messages from the
DHCP server are sent to all access concentrators. This is when the DHCP server are sent to all access concentrators. Consider the
access concentrator implements a MAC concentration or MAC translation scenario where CPE is doing IPoA (IP over AAL5).
function. When such a MAC operation is performed, the access
concentrator replaces the source MAC address of all upstream frames IPoAAL5 L2
by another MAC address, for instance with its own MAC address. In CPE----------L2RA--------L3RA-------Server
this case, the MAC addresses of the hosts will remain unknown in the
network between the trusted layer 2 DHCP relay agent and the Layer 3 Figure 2
DHCP relay agent. Hence all unicast messages sent by the Layer 3
DHCP relay agent using this MAC address will be flooded to all access In this case, there will not be any Ethernet for CPE and hence it
concentrators. would populate chaddr with 0s. L2RA bridges the IP frames to the
L3RA by adding its own Ethernet header. The intermediate L2 network
would only know L2RA MAC address. Hence all the messages from the
L3RA needs to be broadcasted in the L2 network
6.1. Flooding of DHCP reply messages from Layer 3 Relay Agent 6.1. Flooding of DHCP reply messages from Layer 3 Relay Agent
To overcome these two previously mentioned problems, a new sub-option To overcome these two previously mentioned problems, a new sub-option
'unicast-address' is defined for the Relay Agent Information option. 'unicast-address' is defined for the Relay Agent Information option.
With this sub-option, the Layer 3 Relay Agent will always unicast the With this sub-option, the Layer 3 Relay Agent will always unicast the
messages towards the trusted Layer 2 Relay Agent with a hardware messages towards the trusted Layer 2 Relay Agent with a hardware
address that is known in the network. address that is known in the network.
6.1.1. Unicast-Address Sub-Option 6.1.1. Unicast-Address Sub-Option
skipping to change at page 14, line 16 skipping to change at page 14, line 23
unicast-address sub-option MUST be an address that can be used to unicast-address sub-option MUST be an address that can be used to
send unicast packets towards the client. send unicast packets towards the client.
The format of the option is as follows: The format of the option is as follows:
SubOpt Len [Hardware address details] SubOpt Len [Hardware address details]
+------+------+----------+-------------+ +------+------+----------+-------------+
| X | Len | htype(1) | hwaddr | | X | Len | htype(1) | hwaddr |
+------+------+----------+-------------+ +------+------+----------+-------------+
Figure 2 Figure 3
o 'X' is the sub-option code which needs to be allocated by IANA. o 'X' is the sub-option code which needs to be allocated by IANA.
o 'Len' represents the length of the 'value' which includes both o 'Len' represents the length of the 'value' which includes both
htype and hwaddr fields htype and hwaddr fields
o "htype" represents Hardware type. See the 'ARP parameters' o "htype" represents Hardware type. See the 'ARP parameters'
maintained in the database referenced by Assigned numbers RFC 3232 maintained in the database referenced by Assigned numbers
[6]. [RFC3232].
o "hwaddr" is the unicast hardware address. o "hwaddr" is the unicast hardware address.
6.1.1.2. Layer 3 Relay Agent Behavior 6.1.1.2. Layer 3 Relay Agent Behavior
When Layer 3 DHCP Relay Agent receives a DHCP packet with unicast- When Layer 3 DHCP Relay Agent receives a DHCP packet with unicast-
address sub-option added, it SHOULD unicast that message towards the address sub-option added, it SHOULD unicast that message towards the
layer 2 DHCP relay agent with destination address set to the value layer 2 DHCP relay agent with destination address set to the value
contained in the hwaddr field of the sub-option. A Layer 3 relay contained in the hwaddr field of the sub-option. A Layer 3 relay
agent that supports this option SHOULD ignore the broadcast flag if agent that supports this option SHOULD ignore the broadcast flag if
skipping to change at page 15, line 35 skipping to change at page 15, line 41
SHOULD act as a Layer 3 DHCP relay agent would do. SHOULD act as a Layer 3 DHCP relay agent would do.
So if the DHCP server receives DHCP messages with giaddr set to zero So if the DHCP server receives DHCP messages with giaddr set to zero
and a valid unicast-address sub-option, the DHCP server SHOULD ignore and a valid unicast-address sub-option, the DHCP server SHOULD ignore
the broadcast flag and unicast the DHCP messages to the hardware the broadcast flag and unicast the DHCP messages to the hardware
address in the unicast-address sub-option. The DHCP Server SHOULD address in the unicast-address sub-option. The DHCP Server SHOULD
also include this sub-option in the option 82 of its reply. also include this sub-option in the option 82 of its reply.
6.1.1.5. Example Scenarios 6.1.1.5. Example Scenarios
o The trusted layer 2 DHCP relay agent acts as a bridge. In such a o The trusted layer 2 DHCP relay agent and CPE acts as a bridge : In
case, the layer 2 DHCP relay agent puts the MAC address in the such a case, the layer 2 DHCP relay agent puts the MAC address in
chaddr field of DHCP messages in the unicast-address sub-option. the chaddr field of DHCP messages in the unicast-address sub-
The Layer 3 DHCP relay agent will then send the DHCPOFFER and option. The Layer 3 DHCP relay agent will then send the DHCPOFFER
DHCPACK messages from the DHCP server as unicast to the layer 2 and DHCPACK messages from the DHCP server as unicast to the layer
DHCP relay agent, which converts the message to broadcast if the 2 DHCP relay agent, which converts the message to broadcast if the
broadcast flag is set. broadcast flag is set.
o The Layer 2 Relay Agent does MAC translation/concentration o The CPE uses IPoA call type: In this case layer 2 DHCP relay agent
function. In this case layer 2 DHCP relay agent adds unicast- adds unicast-address sub-option which contains the MAC address
address sub-option which contains the MAC address that the Layer 2 that the Layer 2 DHCP Relay Agent is using for upstream frames.
DHCP Relay Agent is using for upstream frames.
6.2. Flooding of DHCPLEASEQUERY reply messages from Layer 3 Relay Agent 6.2. Flooding of DHCPLEASEQUERY reply messages from Layer 3 Relay Agent
The above suboption would not work for reply message for a LEASEQUERY The above suboption would not work for reply message for a LEASEQUERY
request because the reply message type other than LEASEACTIVE for a request because the reply message type other than LEASEACTIVE for a
LEASEQUERY message will not have Relay Agent Information option. LEASEQUERY message will not have Relay Agent Information option.
This can be resolved by creating a new option which is echoed back by This can be resolved by creating a new option which is echoed back by
the DHCP server in DHCP reply messages for a LEASEQUERY message. the DHCP server in DHCP reply messages for a LEASEQUERY message.
This document need the definition of following new option for DHCP This document need the definition of following new option for DHCP
skipping to change at page 16, line 24 skipping to change at page 16, line 29
"relay-agent-hwaddr" option allows a Layer 3 Relay agent to unicast a "relay-agent-hwaddr" option allows a Layer 3 Relay agent to unicast a
DHCP reply for a DHCPLEASEQUERY message to the Layer 2 Relay Agent DHCP reply for a DHCPLEASEQUERY message to the Layer 2 Relay Agent
which had generated the DHCPLEASEQUERY message. The code for this which had generated the DHCPLEASEQUERY message. The code for this
option need to be allocated by IANA. option need to be allocated by IANA.
code [Hardware address details] code [Hardware address details]
+------+------+------------+------------+ +------+------+------------+------------+
| X | len | htype (1) | hwaddr | | X | len | htype (1) | hwaddr |
+------+------+------------+------------+ +------+------+------------+------------+
Figure 3 Figure 4
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 "len" field contains the length of the "Hardware address details" o "len" field contains the length of the "Hardware address details"
and can be used to deduce length of "hwaddr" field. and can be used to deduce length of "hwaddr" field.
o "htype" represents Hardware type. See the 'ARP parameters' o "htype" represents Hardware type. See the 'ARP parameters'
maintained in the database referenced by Assigned numbers RFC maintained in the database referenced by Assigned numbers RFC
skipping to change at page 19, line 11 skipping to change at page 19, line 11
Description of authentication for DHCPLEASEQUERY messages in security Description of authentication for DHCPLEASEQUERY messages in security
section are taken from RFC 4388. section are taken from RFC 4388.
8. Security Consideration 8. Security Consideration
o Layer 3 Relay Agent that relays the DHCP message are essentially o Layer 3 Relay Agent that relays the DHCP message are essentially
DHCP clients for the purposes of the DHCP messages relayed by DHCP clients for the purposes of the DHCP messages relayed by
Layer 2 Relay Agent. Layer 3 Relay Agent MUST relay a DHCP Layer 2 Relay Agent. Layer 3 Relay Agent MUST relay a DHCP
message only when it comes from a trusted circuit. Thus, message only when it comes from a trusted circuit. Thus,
RFC3118[4] is an appropriate mechanism for DHCP messages relayed RFC3118[RFC3118] is an appropriate mechanism for DHCP messages
by Layer 2 Relay Agent. relayed by Layer 2 Relay Agent.
o This document suggest new option which MAY be added by Layer 2 o This document suggest new option which MAY be added by Layer 2
Relay Agents in DHCP message. If a server finds this new option Relay Agents in DHCP message. If a server finds this new option
included in a received message, the server MUST compute any hash included in a received message, the server MUST compute any hash
function as if the option were NOT included in the message without function as if the option were NOT included in the message without
changing the order of options. Whenever the server sends back changing the order of options. Whenever the server sends back
this option to a relay agent, the server MUST not include this this option to a relay agent, the server MUST not include this
option in the computation of any hash function over the message. option in the computation of any hash function over the message.
9. IANA Considerations 9. 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 a Relay Agent. Please refer to option to carry Hardware address of a Relay Agent. Please refer to
section 6.1 for more details.
This document also needs IANA to provide a unique number for the
following new suboptions in Relay Agent Information option [Option
82]:
o To carry the hardware address of a Relay Agent. Please refer to
section 6.2 for more details. section 6.2 for more details.
This document also needs IANA to provide a unique number for a new
suboptions in Relay Agent Information option [Option 82] to carry the
hardware address of the Relay Agent. Please refer to section 6.1 for
more details.
10. References 10. References
10.1. Normative Reference 10.1. Normative Reference
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
March 1997. RFC 2131, March 1997.
[3] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, [RFC3046] Patrick, M., "DHCP Relay Agent Information Option",
January 2001. RFC 3046, January 2001.
[4] Droms, R. and B. Arbaugh, "Authentication for DHCP Messages", [RFC3118] Droms, R. and B. Arbaugh, "Authentication for DHCP
RFC 3118, June 2001. Messages", RFC 3118, June 2001.
[5] Woundy, R. and K. Kinnear, "Dynamic Host Configuration Protocol [RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration
(DHCP) Leasequery", RFC 4388, February 2006. Protocol (DHCP) Leasequery", RFC 4388, February 2006.
[6] Reynolds, J., "Assigned Numbers", RFC 3232, January 2002. [RFC3232] Reynolds, J., "Assigned Numbers", RFC 3232, January 2002.
[7] Joshi, B. and P. Kurapati, "Layer 2 Relay Agent Information", [draft-ietf-dhc-l2ra]
draft draft-ietf-dhc-l2ra-01.txt, May 2008. Joshi, B. and P. Kurapati, "Layer 2 Relay Agent
Information", draft draft-ietf-dhc-l2ra-03.txt,
January 2009.
[draft-ietf-dhc-leasequery-by-remote-id]
Kurapati, P., Joshi, B., and R. Desetti, "DHCPv4
Leasequery by relay agent remote ID",
draft draft-ietf-dhc-leasequery-by-remote-id-01.txt,
January 2009.
10.2. Informative Reference 10.2. Informative Reference
[8] Croft, B. and J. Gilmore, "Bootstrap Protocol (BOOTP)", [RFC951] Croft, B. and J. Gilmore, "Bootstrap Protocol (BOOTP)",
RFC 951, September 1985. RFC 951, September 1985.
[9] Wimer, W., "Clarifications and Extensions for the Bootstrap [RFC1542] Wimer, W., "Clarifications and Extensions for the
Protocol", RFC 1542, October 1993. Bootstrap Protocol", RFC 1542, October 1993.
[10] Droms, R. and S. Alexander, "DHCP Options and BOOTP Vendor [RFC2132] 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
skipping to change at page 23, line 4 skipping to change at line 747
URI: http://www.infosys.com/ URI: http://www.infosys.com/
Stefaan De Cnodder Stefaan De Cnodder
Alcatel-Lucent Alcatel-Lucent
Francis Wellesplein 1, Francis Wellesplein 1,
B-2018 Antwerp B-2018 Antwerp
Belgium Belgium
Email: stefaan.de_cnodder@alcatel-lucent.be Email: stefaan.de_cnodder@alcatel-lucent.be
URI: http://www.alcatel-lucent.com URI: http://www.alcatel-lucent.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The IETF Trust (2008). This document is subject to the
rights, licenses and restrictions contained in BCP 78, and except as
set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 49 change blocks. 
137 lines changed or deleted 158 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/