draft-ietf-dhc-dhcpv6-ldra-02.txt   draft-ietf-dhc-dhcpv6-ldra-03.txt 
DHC Working Group D. Miles, Ed. DHC Working Group D. Miles, Ed.
Internet-Draft S. Ooghe Internet-Draft S. Ooghe
Intended status: Standards Track Alcatel-Lucent Updates: 3315 (if approved) Alcatel-Lucent
Expires: December 10, 2010 W. Dec Intended status: Standards Track W. Dec
Cisco Systems Expires: April 22, 2011 Cisco Systems
S. Krishnan S. Krishnan
A. Kavanagh A. Kavanagh
Ericsson Ericsson
June 8, 2010 October 19, 2010
Lightweight DHCPv6 Relay Agent Lightweight DHCPv6 Relay Agent
draft-ietf-dhc-dhcpv6-ldra-02 draft-ietf-dhc-dhcpv6-ldra-03
Abstract Abstract
This document proposes a Lightweight DHCPv6 Relay Agent (LDRA) that This document proposes a Lightweight DHCPv6 Relay Agent (LDRA) that
is used to insert relay agent options in DHCPv6 message exchanges is used to insert relay agent options in DHCPv6 message exchanges
identifying client-facing interfaces. The LDRA can be implemented in identifying client-facing interfaces. The LDRA can be implemented in
existing access nodes (such as DSLAMs and Ethernet switches) that do existing access nodes (such as DSLAMs and Ethernet switches) that do
not support IPv6 control or routing functions. not support IPv6 control or routing functions.
Status of this Memo Status of this Memo
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on December 10, 2010. This Internet-Draft will expire on April 22, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 32 skipping to change at page 2, line 32
5.3.2. Interface-ID Option . . . . . . . . . . . . . . . . . 6 5.3.2. Interface-ID Option . . . . . . . . . . . . . . . . . 6
6. Agent Behaviour . . . . . . . . . . . . . . . . . . . . . . . 7 6. Agent Behaviour . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Relaying a Client Message . . . . . . . . . . . . . . . . 7 6.1. Relaying a Client Message . . . . . . . . . . . . . . . . 7
6.1.1. Client Message Validation . . . . . . . . . . . . . . 7 6.1.1. Client Message Validation . . . . . . . . . . . . . . 7
6.1.2. Trusted and Untrusted Interfaces . . . . . . . . . . . 8 6.1.2. Trusted and Untrusted Interfaces . . . . . . . . . . . 8
6.2. Relaying a Relay-Reply message from the network . . . . . 8 6.2. Relaying a Relay-Reply message from the network . . . . . 8
7. Network Topology . . . . . . . . . . . . . . . . . . . . . . . 9 7. Network Topology . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Client and Server on Same Link . . . . . . . . . . . . . . 9 7.1. Client and Server on Same Link . . . . . . . . . . . . . . 9
7.2. Client and Server behind Relay Agent . . . . . . . . . . . 10 7.2. Client and Server behind Relay Agent . . . . . . . . . . . 10
7.3. Relay Agent in Front of LDRA . . . . . . . . . . . . . . . 11 7.3. Relay Agent in Front of LDRA . . . . . . . . . . . . . . . 11
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . . 13 12.1. Normative References . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 12.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
DHCPv6 Relay-Agents [RFC3315] are deployed to forward DHCPv6 messages DHCPv6 Relay-Agents [RFC3315] are deployed to forward DHCPv6 messages
between clients and servers when they are not on the same IPv6 link between clients and servers when they are not on the same IPv6 link
and are often implemented alongside a routing function in a common and are often implemented alongside a routing function in a common
node. A Lightweight DHCPv6 Relay Agent (LDRA) allows Relay Agent node. A Lightweight DHCPv6 Relay Agent (LDRA) allows Relay Agent
Information to be inserted by an access node that performs a link- Information to be inserted by an access node that performs a link-
layer bridging (i.e. non-routing) function. A LDRA resides on the layer bridging (i.e. non-routing) function. A LDRA resides on the
same IPv6 link as the client and a DHCPv6 Relay Agent or Server and same IPv6 link as the client and a DHCPv6 Relay Agent or Server and
skipping to change at page 5, line 35 skipping to change at page 5, line 35
the same message types as a normal DHCPv6 Relay Agent. They are: the same message types as a normal DHCPv6 Relay Agent. They are:
o Relay-Forward Messages o Relay-Forward Messages
o Relay-Reply Messages o Relay-Reply Messages
5.1. Relay-Forward Message 5.1. Relay-Forward Message
The Relay-Forward message is created by any DHCPv6 Relay Agent, The Relay-Forward message is created by any DHCPv6 Relay Agent,
including an LDRA, to forward messages between clients and servers or including an LDRA, to forward messages between clients and servers or
other relay agents. These messages are built as specified in . other relay agents. These messages are built as specified in
[RFC3315]. [RFC3315].
The Relay-Forward message contains relay agent parameters that The Relay-Forward message contains relay agent parameters that
identify the client-facing interface on which any reply messages identify the client-facing interface on which any reply messages
should be forwarded. These parameters are link-address, peer-address should be forwarded. These parameters are link-address, peer-address
and Interface-ID. The link-address parameter MUST be set to the and Interface-ID. The link-address parameter MUST be set to the
unspecified address. The Interface-ID Relay Agent Option MUST be unspecified address. The Interface-ID Relay Agent Option MUST be
included in the Relay-Forward message. The LDRA MAY insert included in the Relay-Forward message. The LDRA MAY insert
additional relay agent options. additional relay agent options.
skipping to change at page 6, line 30 skipping to change at page 6, line 30
o Interface-ID Option o Interface-ID Option
5.3.1. Relay-Message Option 5.3.1. Relay-Message Option
A DHCPv6 Relay Agent relays messages between clients and servers or A DHCPv6 Relay Agent relays messages between clients and servers or
other relay agents through Relay-Forward and Relay-Reply message other relay agents through Relay-Forward and Relay-Reply message
types. The original client DHCP message (i.e. the packet payload, types. The original client DHCP message (i.e. the packet payload,
excluding UDP and IP headers) is encapsulated in a Relay Message excluding UDP and IP headers) is encapsulated in a Relay Message
option [RFC3315]. option [RFC3315].
As an LDRA does not implement ICMPv6, fragmentation of Relay-Messages If a Relay-Message would exceed the MTU of the outgoing interface it
is not supported. If a Relay-Message would exceed the MTU of the MUST be discarded and an error condition SHOULD be logged.
outgoing interface it MUST be discarded and an error condition SHOULD
be logged.
5.3.2. Interface-ID Option 5.3.2. Interface-ID Option
The LDRA MUST include the Interface-ID option [RFC3315] in all Relay- The LDRA MUST include the Interface-ID option [RFC3315] in all Relay-
Forward messages. When a LDRA receives a Relay-reply message with an Forward messages. When a LDRA receives a Relay-reply message with an
Interface-ID option present and link-address unspecified, the LDRA Interface-ID option present and link-address unspecified, the LDRA
MUST relay the decapsulated message to the client on the interface MUST relay the decapsulated message to the client on the interface
identified in the Interface-ID option. identified in the Interface-ID option.
Servers MAY use the Interface-ID for parameter assignment policies. Servers MAY use the Interface-ID for parameter assignment policies.
skipping to change at page 8, line 19 skipping to change at page 8, line 19
6.1.2. Trusted and Untrusted Interfaces 6.1.2. Trusted and Untrusted Interfaces
In [RFC3046] DHCPv4 relay-agents had their client-facing interfaces In [RFC3046] DHCPv4 relay-agents had their client-facing interfaces
set to trusted and untrusted. An LDRA MUST implement a configuration set to trusted and untrusted. An LDRA MUST implement a configuration
setting for all client-facing interfaces, marking them either as setting for all client-facing interfaces, marking them either as
trusted or as untrusted. This setting SHOULD be configurable per trusted or as untrusted. This setting SHOULD be configurable per
interface. When a client-facing interface is deemed untrusted the interface. When a client-facing interface is deemed untrusted the
LDRA MUST discard any message received from the client-facing LDRA MUST discard any message received from the client-facing
interface of type RELAY-FORWARD (12). interface of type RELAY-FORWARD (12).
In DHCPv4 it was not possible for a DHCP server to determine whether
the client or an intermediate relay agent had added relay agent
options and thus trusted interfaces (relay-agent interfaces that
would allow any DHCP options to be present on incoming messages) and
untrusted interfaces (relay-agent interfaces that would ensure there
are no relay-agent options on incoming messages) were defined. In
DHCPv6, relay agents encapsulate the received message into the Relay-
Message Option in addition to adding any relay-agent options. This
nested message behaviour allows a server to identify the options each
relay-agent has inserted along the path, whenever the data path
between LDRA and server falls within a protected or operator
controlled environment.
When an LDRA is deployed, DHCPv6 servers MAY be configured with the
Relay-Forward hop-count of the LDRA to instruct them at which level
of nesting the relay-agent options should be parsed. This removes
the need for an interface to be configured as trusted or untrusted by
providing the DHCPv6 server with an awareness of the LDRA logical
location in the DHCP relay path. This behaviour is dependent on the
interception of all DHCP messages by the LDRA and the incrementing of
the Relay-Forward hop-count if a Relay-Forward message is received
from the client-facing LDRA interface.
6.2. Relaying a Relay-Reply message from the network 6.2. Relaying a Relay-Reply message from the network
The LDRA MUST intercept and process all IP traffic received on the The LDRA MUST intercept and process all IP traffic received on the
network-facing interface that has: network-facing interface that has:
o a link-local scoped source address; o a link-local scoped source address;
o a link-local scoped destination address; o a link-local scoped destination address;
o protocol type UDP; and o protocol type UDP; and
o destination port 547 o destination port 547
An LDRA MUST inspect the DHCP message type and MUST silently discard An LDRA MUST inspect the DHCP message type and only forward Relay-
any DHCP message that is not type Relay-Reply or is otherwise an Reply messages. Other DHCP message types MUST be silently discarded.
invalid DHCPv6 packet. The LDRA SHOULD ignore any message that does
not meet this criteria and subject it to normal packet forwarding.
The Relay-Reply message is considered valid by the LDRA if it passes The Relay-Reply message is considered valid by the LDRA if it passes
the validity checks to be performed by a relay agent per [RFC3315] the validity checks to be performed by a relay agent per [RFC3315]
and: and:
- The Interface-ID Option is present and the value corresponds to a - The Interface-ID Option is present and the value corresponds to a
valid interface in the access node, valid interface in the access node,
- the Relay-Reply peer-address and the destination IP address is - the Relay-Reply peer-address and the destination IP address is
identical and it is a link-local scoped address when no IP address is identical and it is a link-local scoped address when no IP address is
configured on the LDRA, and configured on the LDRA, and
- the link-address is the Unspecified Address when no IP address is - the link-address is the Unspecified Address when no IP address is
configured on the LDRA configured on the LDRA
The LDRA copies the peer-address into to the destination IP address If the Relay-Reply message is valid, the LDRA copies the peer-address
field. The LDRA SHOULD forward the packet to the correct client- into to the destination IP address field. The LDRA SHOULD forward
facing interface using the destination link-layer (MAC) address or the packet to the correct client- facing interface using the
the Interface-Id in the Relay-Reply. The LDRA SHOULD NOT retransmit destination link-layer (MAC) address or the Interface-Id in the
the packet on any other interface. The contents of the Relay Message Relay-Reply. The LDRA SHOULD NOT retransmit the packet on any other
Option is put into an IP/UDP packet and then forwarded to the client. interface. The contents of the Relay Message Option is put into an
IP/UDP packet and then forwarded to the client.
The LDRA MUST copy the link-layer and IP source address from the The LDRA MUST copy the link-layer and IP source address from the
Relay-Reply message into the IP/UDP packet that is forwarded to the Relay-Reply message into the IP/UDP packet that is forwarded to the
client. client.
7. Network Topology 7. Network Topology
The LDRA intercepts any DHCPv6 message received on client-facing The LDRA intercepts any DHCPv6 message received on client-facing
interfaces with a destination IP address of interfaces with a destination IP address of
All_DHCP_Relay_Agents_and_Servers (FF02::1:2). The LDRA MUST NOT All_DHCP_Relay_Agents_and_Servers (FF02::1:2). The LDRA MUST NOT
skipping to change at page 13, line 33 skipping to change at page 13, line 11
to the All_DHCPv6_Servers_and_Relay_Agents address on UDP port 547, to the All_DHCPv6_Servers_and_Relay_Agents address on UDP port 547,
the LDRA SHOULD implement some form of rate-limiting on received the LDRA SHOULD implement some form of rate-limiting on received
messages to prevent excessive process utilisation. As DHCP is messages to prevent excessive process utilisation. As DHCP is
session-oriented, messages in excess of the rate-limit may be session-oriented, messages in excess of the rate-limit may be
silently discarded. silently discarded.
The hop count based determination of the trustworthiness of the LDRA The hop count based determination of the trustworthiness of the LDRA
can be easily defeated by a rogue relay agent on the network-facing can be easily defeated by a rogue relay agent on the network-facing
interface of the LDRA. interface of the LDRA.
11. References 11. Acknowledgements
11.1. Normative References The authors would like to thank Tatuya Jinmei, David Hankins, Ted
Lemon and Ralph Droms for reviewing this document and suggesting
changes.
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
[RFC3315] Droms, R., "Dynamic Host Configuration Protocol for IPv6 [RFC3315] Droms, R., "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003. (DHCPv6)", RFC 3315, July 2003.
11.2. Informative References 12.2. Informative References
[L2RA] Joshi, B., "Layer 2 Relay Agent Information", IETF [L2RA] Joshi, B., "Layer 2 Relay Agent Information", IETF
Draft draft-ietf-dhc-l2ra-04, April 2009. Draft draft-ietf-dhc-l2ra-04, April 2009.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", [RFC3046] Patrick, M., "DHCP Relay Agent Information Option",
RFC 3046, January 2001. RFC 3046, January 2001.
[TR-101] The Broadband Forum, "Migration to Ethernet-Based DSL [TR-101] The Broadband Forum, "Migration to Ethernet-Based DSL
Aggregation", Technical Report TR-101, April 2006. Aggregation", Technical Report TR-101, April 2006.
skipping to change at page 15, line 4 skipping to change at page 14, line 29
Phone: Phone:
Email: wdec@cisco.com Email: wdec@cisco.com
Suresh Krishnan Suresh Krishnan
Ericsson Ericsson
8400 Blvd Decarie 8400 Blvd Decarie
Town of Mount Royal, Quebec Town of Mount Royal, Quebec
Canada Canada
Email: suresh.krishnan@ericsson.com Email: suresh.krishnan@ericsson.com
Alan Kavanagh]
Alan Kavanagh
Ericsson Ericsson
8400 Blvd Decarie 8400 Blvd Decarie
Town of Mount Royal, Quebec Town of Mount Royal, Quebec
Canada Canada
Email: alan.kavanagh@ericsson.com Email: alan.kavanagh@ericsson.com
 End of changes. 15 change blocks. 
55 lines changed or deleted 38 lines changed or added

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