DHC Working Group D. Miles, Ed. Internet-Draft S. Ooghe Intended status: Standards Track Alcatel-Lucent Expires: November 2, 2008 W. Dec Cisco Systems May 2008 Lightweight DHCPv6 Relay Agent (LDRA) draft-miles-dhc-dhcpv6-ldra-00 Status of this Memo By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 2, 2008. Abstract This document proposes a lightweight DHCPv6 relay agent that can be implemented in existing access nodes (such as DSLAMs and Ethernet switches) that do not support IPv6 control or routing functions. Miles, et al. Expires November 2, 2008 [Page 1] Internet-Draft Lightweight DHCPv6 Relay Agent (LDRA) May 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Relay-Forward Message . . . . . . . . . . . . . . . . . . 5 5.2. Relay-Reply Message . . . . . . . . . . . . . . . . . . . 5 5.3. Mandatory DHCP Options . . . . . . . . . . . . . . . . . . 6 5.3.1. Relay-Message Option . . . . . . . . . . . . . . . . . 6 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. Relay-Reply . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Miles, et al. Expires November 2, 2008 [Page 2] Internet-Draft Lightweight DHCPv6 Relay Agent (LDRA) May 2008 1. Introduction DHCPv6 Relay-Agents [RFC3315] are deployed to pass 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 which performs a link- layer bridging (non-routing) function. A LDRA resides on the same IPv6 link as the client and a DHCPv6 Relay Agent or Server and is functionally the equivalent of the Layer 2 DHCP Relay draft[draft-joshi-dhc-l2ra-00] proposed for IPv4 operation. Unlike a DHCPv6 Relay-Agent in [RFC3315], a LDRA does not implement any IPv6 control functions (ICMPv6) or have any routing capability in the node. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Requirements The Lightweight DHCPv6 Relay Agent (LDRA) MUST NOT require modifications to DHCPv6 clients, servers or relay-agent behaviours defined in RFC 3315. The LDRA MUST insert Relay Agent Information parameters into the DHCP message exchanges, allowing a server to identify the access node interface to which a client is attached. The LDRA MUST NOT require a global unicast address The LDRA MUST NOT require the implementation of IPv6 routing or IPv6 control protocols (ICMPv6) The LDRA MUST NOT require configuration of link-specific parameters 3. Background A variety of different link-layer network topologies exist for the aggregation of IPv6 nodes into one or more routers. In Layer 2 aggregation networks (IEEE 802.1D bridging or similar) that have many nodes on a single link, a DHCPv6 server or DHCP relay agent would normally be unaware of how a DHCP client is attached to the network. Miles, et al. Expires November 2, 2008 [Page 3] Internet-Draft Lightweight DHCPv6 Relay Agent (LDRA) May 2008 The LDRA allows Relay Agent Information, including the Interface-ID option, to be inserted by the access node so it may be used for client identification. A typical application in a broadband service provider may be as an equivalent to the Broadband Forum TR-101 Layer 2 DHCP Relay Agent[TR-101] described in [draft-joshi-dhc-l2ra-00] 4. Terminology address An IP layer identifier for an interface or set of interfaces host A node that is not a router IP Internet Protocol Version 6 (IPv6) LDRA Lightweight DHCPv6 Relay Agent link A communication facility or medium over which nodes can communicate at the link layer link-local address An IP address having only local-scope, indicated by having the address prefix FE80::/10, that can be used to reach neighbouring nodes attached to the same link. Every interface has a link-local address. node A device that implements IPv6 router A node that forwards packets not directly addressed to itself access node A device that combines many interfaces onto one link. An access node is not IP-aware in the data path relay agent A node that acts as an intermediary to deliver DHCP messages between clients and servers and being on the same link as the client lightweight relay agent A function on the access node that intercepts DHCP messages between clients and servers. The function exists as a bump in the wire on the IP link. Miles, et al. Expires November 2, 2008 [Page 4] Internet-Draft Lightweight DHCPv6 Relay Agent (LDRA) May 2008 unspecified address An IP address that is comprised entirely of zeros 5. Message Format The Lightweight DHCPv6 Relay Agent (LDRA) exchanges DHCP messages between clients and servers using the message formats established in [RFC3315]. To maintain interoperability with existing DHCP relays and servers the message format is unchanged from [RFC3315]. The LDRA implements the same message types as a normal DHCPv6 Relay Agent, being: o Relay-Forward Messages o Relay-Reply Messages 5.1. Relay-Forward Message The Relay-Forward message is created by any DHCPv6 Relay Agent according to [RFC3315] , including an LDRA to forward messages between clients and servers or other relay agents. The Relay-Forward message contains parameters that are used in server-to-client exchanges that provide the relay agent details of which interface the messages should use to be forwarded to the client. These parameters are link-address, peer-address and Interface-ID. The link-address parameter MUST be set to the unspecified value, following the behaviour described in [RFC3315], and the Interface-ID Relay Agent Option MUST be included in the Relay-Forward message. The LDRA may add additional relay agent options however they are outside the scope of this document.__ 5.2. Relay-Reply Message The Relay-Reply message is constructed by a server to pass parameters to a DHCP client when a relay agent is present between the server and the client. The Relay-Reply message may be sent after an initial Relay-Forward message as the parameters link-address, peer-address, Interface-ID and the relay agent's IP address are learnt from the Relay-Forward message. The Interface-ID option MUST be included in the Relay-Reply Message (by a server following the behaviour in [RFC3315]) to indicate to the LDRA which interface the decapsulated message should be forwarded out of. Miles, et al. Expires November 2, 2008 [Page 5] Internet-Draft Lightweight DHCPv6 Relay Agent (LDRA) May 2008 5.3. Mandatory DHCP Options Parameters are exchanged between DHCP client, relay-agent and server through the use of DHCP options. As a LDRA there are a set of mandatory DHCP options that MUST be included in all Relay-Forward and Relay-Reply messages. These are the: o Relay-Message Option 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. 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. The format of the Relay-Message Option is defined in [RFC3315]. 5.3.2. Interface-ID Option The LDRA MUST include the Interface-ID option in all Relay-Forward messages. When a LDRA receives a Relay-reply message with an Interface-ID option and link-address unspecified, the LDRA relays the relay message to the client through the interface identified in the Interface-ID option. Servers may use the Interface-ID for parameter assignment policies. The format of the Interface-ID is outside the scope of this contribution. The Interface-ID SHOULD be considered an opaque value, that is, the Interface-ID SHOULD NOT be internally parsed by the server. The Interface-ID value for an interface SHOULD remain unchanged, for example, after the LDRA is restarted; if the Interface-ID changes, a server will not be able to use it reliably in parameter assignment policies. The format of the Interface-ID Option is defined in [RFC3315]. Miles, et al. Expires November 2, 2008 [Page 6] Internet-Draft Lightweight DHCPv6 Relay Agent (LDRA) May 2008 6. Agent Behaviour 6.1. Relaying a Client Message When a DHCPv6 message (defined in [RFC3315]) is received on any client-facing access node interface, the LDRA MUST intercept and process the message, preventing it from being forwarded on-link. The lightweight relay agent adds any other options it is configured or required to include in the Relay-Forward message. The LDRA MUST set the link-address field of the Relay-forward message to the Unspecified Address (::) and the Interface-ID option MUST be included in all DHCP Relay-Forward messages. If the client message is a Relay-Forward message, the LDRA MUST increment the Hop-Count field in the Relay-Forward message following the specification for relay agent behaviour in [RFC3315]. The LDRA MUST copy the IP destination and link-layer destination addresses from the client-originated message into the IP destination address and link-layer destination address of the Relay-forward message. The LDRA MUST copy the IP source address from the client-originated message into the peer-address field of the Relay-forward message. The LDRA MUST copy the link-layer source address from the client- originated message into the link-layer source address of the Relay- forward message. 6.1.1. Client Message Validation On receipt of a DHCP message from the client, the LDRA MUST discard a message that is one of following message-types: o ADVERTISE (2) o REPLY (7) o RECONFIGURE (10) o RELAY-REPLY (13) Options contained in the DHCPv6 message SHOULD NOT be validated by the LDRA, making it the responsibility of the DHCP server to check message option validity and allow new options to be introduced without changes on the LDRA. Miles, et al. Expires November 2, 2008 [Page 7] Internet-Draft Lightweight DHCPv6 Relay Agent (LDRA) May 2008 6.1.2. Trusted and Untrusted Interfaces In [RFC3046] DHCPv4 relay-agents had their client-facing interfaces set to trusted and untrusted. In DHCPv4 it was not possible for a DHCP server to determine whether the client or an intermediate relay had added relay agent information 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. When an LDRA is deployed, DHCPv6 servers MUST be configured with the Relay-Forward hop-count of the LDRA to instruct 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 dependant 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. Relay-Reply When a valid Relay-Reply is received on any network-facing access node interface, it MUST be intercepted by the LDRA. If an IP address is not configured on the LDRA, the agent MUST listen to all IP traffic that has a link-local scoped source address, link-local scoped destination address, protocol type UDP and destination port 547. Any message that does not meet this criteria is not considered interesting to the LDRA and MUST be ignored and allowed to be forwarded like any other packet. The LDRA MAY be configured to listen only to a specific destination address if it has been configured as a node (implementing a full IP stack). The LDRA MUST intercept and process all DHCP Relay-Reply messages and MUST silently discard all other DHCP message types. In addition to the validity checks performed by a relay agent in [RFC3315] , the Relay-Reply message is considered valid by the LDRA if: - Interface-ID Option is present and the value corresponds to a valid interface in the access node Miles, et al. Expires November 2, 2008 [Page 8] Internet-Draft Lightweight DHCPv6 Relay Agent (LDRA) May 2008 - The Relay-Reply peer-address and the destination IP address MUST be identical and MUST be a link-local scoped address when no IP address is configured on the LDRA - The link-address is the Unspecified Address when no IP address is configured on the LDRA The LDRA copies the peer-address into the destination IP address field, and MAY use the destination link-layer address (MAC address) or Interface-ID to determine which interface to send the message to the client. The contents of the Relay Message Option is put into an IP/UDP packet and then forwarded to the client. 7. Network Topology Care must be taken to ensure that all DHCP messages are intercepted by the LDRA to avoid a relayed and non-relayed copy of the same client-message reaching another relay-agent or server. This is achieved by intercepting all traffic from the client with a destination address of the All_DHCP_Relay_Agents_and_Servers (FF02::1:2). 7.1. Client and Server on Same Link The access node acts as a bridge; it has no information about any IP prefixes that are valid on the link, thus a server should consider address and parameter assignment as if the client DHCP message was not relayed. +--------+ Client -------| | | Access | Client -------| Node |-----+ | (LDRA) | | Client -------| | | +--------+ | | +--------+ |------| Server | | +--------+ +--------+ | Client -------| | | | Access | | Client -------| Node |-----+ | (LDRA) | Client -------| | +--------+ <------IPv6 Link-----> Miles, et al. Expires November 2, 2008 [Page 9] Internet-Draft Lightweight DHCPv6 Relay Agent (LDRA) May 2008 For example, if a client sent a DHCP solicit message that was relayed by the LDRA and then to the server, the server would receive the following Relay-Forward message from the LDRA: src-ip: client link-local address dst-ip: All_DHCP_Relay_Agents_and_Servers msg-type: RELAY-FORWARD hop-count: 0 link-address: Unspecified_Address peer-address: client link-local address Interface-ID Option: interface-id: LDRA-inserted interface-id Relay-Message Option, which contains: msg-type: SOLICIT Solicit Message Options: 7.2. Client and Server behind Relay Agent The client and server are on different IPv6 links, separated by one or more relay agents that will typically act as a router. The LDRA will send Relay-Forward messages upstream towards the second relay agent which in turn will process the messages. +--------+ Client -------| | | Access | Client -------| Node |-----+ | (LDRA) | | Client -------| | | +--------+ | | +--------+ +--------+ |------| RelayB |---------| Server | | +--------+ +--------+ +--------+ | Client -------| | | | Access | | Client -------| Node |-----+ | (LDRA) | Client -------| | +--------+ <--IPv6 Link A--> <--IPv6 Link B--> For example, if a client sent a DHCP solicit message that was relayed by the LDRA to another relay agent and then to the server, the server would receive the following Relay-Forward message from the LDRA: Miles, et al. Expires November 2, 2008 [Page 10] Internet-Draft Lightweight DHCPv6 Relay Agent (LDRA) May 2008 src-ip: relayB dst-ip: server msg-type: RELAY-FORWARD hop-count: 1 link-address: relayB address from link A peer-address: client link-local address Relay-Message Option, which contains: msg-type: RELAY-FORWARD hop-count: 0 link-address: Unspecified_Address peer-address: client link-local address Interface-ID Option: interface-id: LDRA-inserted interface-id Relay-Message Option, which contains: msg-type: SOLICIT Solicit Message Options: 7.3. Relay Agent in Front of LDRA The client and server are on different IPv6 links, separated by one or more relay agents that will typically act as a router and there is an [RFC3315] Relay Agent on the client-facing Interface of the LDRA. The LDRA will send Relay-Forward messages upstream towards the second relay agent which in turn will process the messages. +--------+ RelayC -------| | | Access | RelayC -------| Node |-----+ | (LDRA) | | RelayC -------| | | +--------+ | | +--------+ +--------+ |------| RelayB |---------| Server | | +--------+ +--------+ +--------+ | RelayC -------| | | | Access | | RelayC -------| Node |-----+ | (LDRA) | RelayC -------| | +--------+ <--IPv6 Link A--> <--IPv6 Link B--> For example, if a client sent a DHCP solicit message that was relayed by the LDRA to another relay agent and then to the server, the server would receive the following Relay-Forward message from the LDRA: Miles, et al. Expires November 2, 2008 [Page 11] Internet-Draft Lightweight DHCPv6 Relay Agent (LDRA) May 2008 src-ip: relayB dst-ip: server msg-type: RELAY-FORWARD hop-count: 2 link-address: relayB address from link A peer-address: relayC Relay-Message Option, which contains: msg-type: RELAY-FORWARD hop-count: 1 link-address: Unspecified_Address peer-address: relayC Interface-ID Option: interface-id: LDRA-inserted interface-id Relay-Message Option, which contains: msg-type: RELAY-FORWARD hop-count: 0 link-address: global or unspecified address peer-address: end client address Interface-ID Option: (if required) interface-id: relayC intserted Interface-ID Relay-Message Option, which contains: msg-type: SOLICIT Solicit Message Options: 8. Contributors The authors would like to thank the following for their support, Lieven Levrau, Alastair Johnson, Robert Haylock, Mickey Vucic, Ludwig Pauwels, Fernando Cuervo and John Kaippallimalil. Comments are solicited and should be addressed to the DHC WG mailing list (dhcwg@ietf.org) and/or the author. 9. IANA Considerations This document does not introduce any new namespaces for the IANA to manage. 10. Security Considerations As the LDRA listens to all IPv6 traffic with UDP port 547 the LDRA must implement some form of rate-limiting on received messages to prevent excessive process utilisation on the LDRA. As DHCP is session-oriented, messages in excess of the rate-limit may be silently discarded. Miles, et al. Expires November 2, 2008 [Page 12] Internet-Draft Lightweight DHCPv6 Relay Agent (LDRA) May 2008 11. References 11.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. [draft-joshi-dhc-l2ra-00] Joshi, B., "Layer 2 Relay Agent Information", IETF Draft draft-joshi-dhc-l2ra-00, November 2007. 11.2. Informative References [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. Authors' Addresses David Miles (editor) Alcatel-Lucent L3 / 215 Spring St Melbourne, Victoria 3000 Australia Phone: +61 3 9664 3308 Email: david.miles@alcatel-lucent.com Sven Ooghe Alcatel-Lucent Copernicuslaan 50 2018 Antwerp, Belgium Phone: Email: sven.ooghe@alcatel-lucent.com Miles, et al. Expires November 2, 2008 [Page 13] Internet-Draft Lightweight DHCPv6 Relay Agent (LDRA) May 2008 Wojciech Dec Cisco Systems Haarlerberdweg 13-19 1101 CH Amsterdam, The Netherlands Phone: Email: wdec@cisco.com Miles, et al. Expires November 2, 2008 [Page 14] Internet-Draft Lightweight DHCPv6 Relay Agent (LDRA) May 2008 Full 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. 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. Intellectual Property 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. Miles, et al. Expires November 2, 2008 [Page 15]