--- 1/draft-ietf-dhc-dhcpv6-ldra-02.txt 2010-10-20 00:14:59.000000000 +0200 +++ 2/draft-ietf-dhc-dhcpv6-ldra-03.txt 2010-10-20 00:15:00.000000000 +0200 @@ -1,23 +1,23 @@ DHC Working Group D. Miles, Ed. Internet-Draft S. Ooghe -Intended status: Standards Track Alcatel-Lucent -Expires: December 10, 2010 W. Dec - Cisco Systems +Updates: 3315 (if approved) Alcatel-Lucent +Intended status: Standards Track W. Dec +Expires: April 22, 2011 Cisco Systems S. Krishnan A. Kavanagh Ericsson - June 8, 2010 + October 19, 2010 Lightweight DHCPv6 Relay Agent - draft-ietf-dhc-dhcpv6-ldra-02 + draft-ietf-dhc-dhcpv6-ldra-03 Abstract This document proposes a Lightweight DHCPv6 Relay Agent (LDRA) that is used to insert relay agent options in DHCPv6 message exchanges identifying client-facing interfaces. The LDRA can be implemented in existing access nodes (such as DSLAMs and Ethernet switches) that do not support IPv6 control or routing functions. Status of this Memo @@ -28,21 +28,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2010 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 @@ -67,27 +67,28 @@ 5.3.2. Interface-ID Option . . . . . . . . . . . . . . . . . 6 6. Agent Behaviour . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Relaying a Client Message . . . . . . . . . . . . . . . . 7 6.1.1. Client Message Validation . . . . . . . . . . . . . . 7 6.1.2. Trusted and Untrusted Interfaces . . . . . . . . . . . 8 6.2. Relaying a Relay-Reply message from the network . . . . . 8 7. Network Topology . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Client and Server on Same Link . . . . . . . . . . . . . . 9 7.2. Client and Server behind Relay Agent . . . . . . . . . . . 10 7.3. Relay Agent in Front of LDRA . . . . . . . . . . . . . . . 11 - 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 - 11.2. Informative References . . . . . . . . . . . . . . . . . . 13 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 + 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 + 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 12.1. Normative References . . . . . . . . . . . . . . . . . . . 13 + 12.2. Informative References . . . . . . . . . . . . . . . . . . 13 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction DHCPv6 Relay-Agents [RFC3315] are deployed to forward DHCPv6 messages between clients and servers when they are not on the same IPv6 link and are often implemented alongside a routing function in a common node. A Lightweight DHCPv6 Relay Agent (LDRA) allows Relay Agent Information to be inserted by an access node that performs a link- 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 @@ -198,21 +199,21 @@ the same message types as a normal DHCPv6 Relay Agent. They are: o Relay-Forward Messages o Relay-Reply Messages 5.1. Relay-Forward Message The Relay-Forward message is created by any DHCPv6 Relay Agent, 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]. The Relay-Forward message contains relay agent parameters that identify the client-facing interface on which any reply messages should be forwarded. These parameters are link-address, peer-address and Interface-ID. The link-address parameter MUST be set to the unspecified address. The Interface-ID Relay Agent Option MUST be included in the Relay-Forward message. The LDRA MAY insert additional relay agent options. @@ -241,24 +242,22 @@ o Interface-ID Option 5.3.1. Relay-Message Option A DHCPv6 Relay Agent relays messages between clients and servers or other relay agents through Relay-Forward and Relay-Reply message types. The original client DHCP message (i.e. the packet payload, excluding UDP and IP headers) is encapsulated in a Relay Message option [RFC3315]. - As an LDRA does not implement ICMPv6, fragmentation of Relay-Messages - is not supported. If a Relay-Message would exceed the MTU of the - outgoing interface it MUST be discarded and an error condition SHOULD - be logged. + If a Relay-Message would exceed the MTU of the outgoing interface it + MUST be discarded and an error condition SHOULD be logged. 5.3.2. Interface-ID Option The LDRA MUST include the Interface-ID option [RFC3315] in all Relay- Forward messages. When a LDRA receives a Relay-reply message with an Interface-ID option present and link-address unspecified, the LDRA MUST relay the decapsulated message to the client on the interface identified in the Interface-ID option. Servers MAY use the Interface-ID for parameter assignment policies. @@ -325,80 +324,57 @@ 6.1.2. Trusted and Untrusted Interfaces In [RFC3046] DHCPv4 relay-agents had their client-facing interfaces set to trusted and untrusted. An LDRA MUST implement a configuration setting for all client-facing interfaces, marking them either as trusted or as untrusted. This setting SHOULD be configurable per interface. When a client-facing interface is deemed untrusted the LDRA MUST discard any message received from the client-facing 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 The LDRA MUST intercept and process all IP traffic received on the network-facing interface that has: o a link-local scoped source address; o a link-local scoped destination address; + o protocol type UDP; and o destination port 547 - An LDRA MUST inspect the DHCP message type and MUST silently discard - any DHCP message that is not type Relay-Reply or is otherwise an - invalid DHCPv6 packet. The LDRA SHOULD ignore any message that does - not meet this criteria and subject it to normal packet forwarding. + An LDRA MUST inspect the DHCP message type and only forward Relay- + Reply messages. Other DHCP message types MUST be silently discarded. 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] and: - The Interface-ID Option is present and the value corresponds to a valid interface in the access node, - 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 configured on the LDRA, and - the link-address is the Unspecified Address when no IP address is configured on the LDRA - The LDRA copies the peer-address into to the destination IP address - field. The LDRA SHOULD forward the packet to the correct client- - facing interface using the destination link-layer (MAC) address or - the Interface-Id in the Relay-Reply. The LDRA SHOULD NOT retransmit - the packet on any other interface. The contents of the Relay Message - Option is put into an IP/UDP packet and then forwarded to the client. + If the Relay-Reply message is valid, the LDRA copies the peer-address + into to the destination IP address field. The LDRA SHOULD forward + the packet to the correct client- facing interface using the + destination link-layer (MAC) address or the Interface-Id in the + Relay-Reply. The LDRA SHOULD NOT retransmit the packet on any other + 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 Relay-Reply message into the IP/UDP packet that is forwarded to the client. 7. Network Topology The LDRA intercepts any DHCPv6 message received on client-facing interfaces with a destination IP address of All_DHCP_Relay_Agents_and_Servers (FF02::1:2). The LDRA MUST NOT @@ -574,31 +548,37 @@ to the All_DHCPv6_Servers_and_Relay_Agents address on UDP port 547, the LDRA SHOULD implement some form of rate-limiting on received messages to prevent excessive process utilisation. As DHCP is session-oriented, messages in excess of the rate-limit may be silently discarded. The hop count based determination of the trustworthiness of the LDRA can be easily defeated by a rogue relay agent on the network-facing 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 Requirement Levels", RFC 2119, March 1997. [RFC3315] Droms, R., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. -11.2. Informative References +12.2. Informative References [L2RA] Joshi, B., "Layer 2 Relay Agent Information", IETF Draft draft-ietf-dhc-l2ra-04, April 2009. [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001. [TR-101] The Broadband Forum, "Migration to Ethernet-Based DSL Aggregation", Technical Report TR-101, April 2006. @@ -631,17 +610,18 @@ Phone: Email: wdec@cisco.com Suresh Krishnan Ericsson 8400 Blvd Decarie Town of Mount Royal, Quebec Canada Email: suresh.krishnan@ericsson.com - Alan Kavanagh] + + Alan Kavanagh Ericsson 8400 Blvd Decarie Town of Mount Royal, Quebec Canada Email: alan.kavanagh@ericsson.com