draft-ietf-dhc-dhcpv6-ldra-03.txt | rfc6221.txt | |||
---|---|---|---|---|
DHC Working Group D. Miles, Ed. | Internet Engineering Task Force (IETF) D. Miles, Ed. | |||
Internet-Draft S. Ooghe | Request for Comments: 6221 S. Ooghe | |||
Updates: 3315 (if approved) Alcatel-Lucent | Updates: 3315 Alcatel-Lucent | |||
Intended status: Standards Track W. Dec | Category: Standards Track W. Dec | |||
Expires: April 22, 2011 Cisco Systems | ISSN: 2070-1721 Cisco Systems | |||
S. Krishnan | S. Krishnan | |||
A. Kavanagh | A. Kavanagh | |||
Ericsson | Ericsson | |||
October 19, 2010 | May 2011 | |||
Lightweight DHCPv6 Relay Agent | Lightweight DHCPv6 Relay Agent | |||
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 Digital Subscriber Link Access | |||
not support IPv6 control or routing functions. | Multiplexers (DSLAMs) and Ethernet switches) that do not support IPv6 | |||
control or routing functions. | ||||
Status of this Memo | ||||
This Internet-Draft is submitted in full conformance with the | Status of This Memo | |||
provisions of BCP 78 and BCP 79. | ||||
Internet-Drafts are working documents of the Internet Engineering | This is an Internet Standards Track document. | |||
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 | This document is a product of the Internet Engineering Task Force | |||
and may be updated, replaced, or obsoleted by other documents at any | (IETF). It represents the consensus of the IETF community. It has | |||
time. It is inappropriate to use Internet-Drafts as reference | received public review and has been approved for publication by the | |||
material or to cite them other than as "work in progress." | Internet Engineering Steering Group (IESG). Further information on | |||
Internet Standards is available in Section 2 of RFC 5741. | ||||
This Internet-Draft will expire on April 22, 2011. | Information about the current status of this document, any errata, | |||
and how to provide feedback on it may be obtained at | ||||
http://www.rfc-editor.org/info/rfc6221. | ||||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2010 IETF Trust and the persons identified as the | Copyright (c) 2011 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 | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction ....................................................3 | |||
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 | 1.1. Requirements Language ......................................3 | |||
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Background ......................................................3 | |||
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 3. Terminology .....................................................3 | |||
4. Server Considerations . . . . . . . . . . . . . . . . . . . . 4 | 4. Server Considerations ...........................................5 | |||
5. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 5 | 5. Message Format ..................................................5 | |||
5.1. Relay-Forward Message . . . . . . . . . . . . . . . . . . 5 | 5.1. Relay-Forward Message ......................................5 | |||
5.2. Relay-Reply Message . . . . . . . . . . . . . . . . . . . 5 | 5.2. Relay-Reply Message ........................................6 | |||
5.3. Mandatory DHCP Options . . . . . . . . . . . . . . . . . . 6 | 5.3. Mandatory DHCP Options .....................................6 | |||
5.3.1. Relay-Message Option . . . . . . . . . . . . . . . . . 6 | 5.3.1. Relay-Message Option ................................6 | |||
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 ...........................8 | |||
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 ......................11 | |||
7.3. Relay Agent in Front of LDRA . . . . . . . . . . . . . . . 11 | 7.3. Relay Agent in Front of LDRA ..............................12 | |||
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12 | 8. Contributors ...................................................15 | |||
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 | 9. Security Considerations ........................................15 | |||
10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | 10. References ....................................................15 | |||
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 | 10.1. Normative References .....................................15 | |||
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 | 10.2. Informative References ...................................16 | |||
12.1. Normative References . . . . . . . . . . . . . . . . . . . 13 | ||||
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. An 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 | |||
is functionally the equivalent of the Layer 2 DHCP Relay draft[L2RA] | is functionally the equivalent of the Layer 2 Relay Agent proposed | |||
proposed for DHCPv4 operation. | for DHCPv4 operation in [L2RA]. | |||
Unlike a DHCPv6 Relay-Agent specified in [RFC3315], a LDRA does not | Unlike a DHCPv6 Relay Agent specified in [RFC3315], an LDRA does not | |||
implement any IPv6 control functions (e.g. ICMPv6) or have any | implement any IPv6 control functions (e.g., ICMPv6) or have any | |||
routing capability in the node. | routing capability in the node. | |||
1.1. Requirements Language | 1.1. Requirements Language | |||
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 [RFC2119]. | document are to be interpreted as described in RFC 2119 [RFC2119]. | |||
2. Background | 2. Background | |||
A variety of different link-layer network topologies exist for the | A variety of different link-layer network topologies exist for the | |||
aggregation of IPv6 nodes into one or more routers. In Layer 2 | aggregation of IPv6 nodes into one or more routers. In Layer 2 | |||
aggregation networks (IEEE 802.1D bridging or similar) that have many | aggregation networks (IEEE 802.1D bridging or similar) that have many | |||
nodes on a single link, a DHCPv6 server or DHCP relay agent would | 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. | normally be unaware of how a DHCP client is attached to the network. | |||
The LDRA allows Relay Agent Information, including the Interface-ID | The LDRA allows Relay Agent Information, including the Interface-ID | |||
option [RFC3315], to be inserted by the access node so that it may be | option [RFC3315], to be inserted by the access node so that it may be | |||
used by the DHCPv6 server for client identification. A typical | used by the DHCPv6 server for client identification. A typical | |||
application in a broadband service provider may be as an equivalent | application in a broadband service provider could be equivalent to a | |||
to the Broadband Forum TR-101 Layer 2 DHCP Relay Agent [TR-101] | Layer 2 DHCP Relay Agent as described in the Broadband Forum TR-101 | |||
described in [L2RA]. | report [TR-101] and in [L2RA]. | |||
3. Terminology | 3. Terminology | |||
Access Node A device that combines many interfaces onto | Access Node A device that combines many interfaces onto | |||
one link. An access node is not IP-aware | one link. An access node is not IP-aware | |||
in the data path. | in the data path. | |||
Address An IP layer identifier for an interface or | Address An IP layer identifier for an interface or | |||
set of interfaces. | set of interfaces. | |||
skipping to change at page 4, line 24 | skipping to change at page 4, line 21 | |||
Lightweight Relay Agent A function on the access node that | Lightweight Relay Agent A function on the access node that | |||
intercepts DHCP messages between clients | intercepts DHCP messages between clients | |||
and servers. The function exists as a bump | and servers. The function exists as a bump | |||
in the wire on the IP link. | in the wire on the IP link. | |||
Link A communication facility or medium over | Link A communication facility or medium over | |||
which nodes can communicate at the link | which nodes can communicate at the link | |||
layer. | layer. | |||
Link-local address An IP address having only local-scope, | Link-local address An IP address having only local scope, | |||
indicated by having the address prefix | indicated by having the address prefix | |||
FE80::/10, that can be used to reach | fe80::/10, that can be used to reach | |||
neighbouring nodes attached to the same | neighbouring nodes attached to the same | |||
link. Every interface has a link-local | link. Every interface has a link-local | |||
address. | address. | |||
Network-facing An interface on the access node that | Network-facing An interface on the access node that | |||
carries traffic towards the DHCPv6 | carries traffic towards the DHCPv6 | |||
server(s). | server(s). | |||
Node A device that implements IPv6. | Node A device that implements IPv6. | |||
skipping to change at page 4, line 50 | skipping to change at page 5, line 7 | |||
Relay Agent A node that acts as an intermediary to | Relay Agent A node that acts as an intermediary to | |||
deliver DHCP messages between clients and | deliver DHCP messages between clients and | |||
servers and being on the same link as the | servers and being on the same link as the | |||
client. | client. | |||
Unspecified address An IPv6 address that is comprised entirely | Unspecified address An IPv6 address that is comprised entirely | |||
of zeros. | of zeros. | |||
4. Server Considerations | 4. Server Considerations | |||
This document updates the behavior specified in section 11 of DHCP | This document updates the behaviour specified in Section 11 of DHCP | |||
for IPv6 [RFC3315]. RFC3315 states, in part: | for IPv6 [RFC3315]. RFC 3315 states, in part: | |||
o If the server receives the message from a forwarding relay agent, | If the server receives the message from a forwarding relay agent, | |||
then the client is on the same link as the one to which the | then the client is on the same link as the one to which the | |||
interface, identified by the link-address field in the message | interface, identified by the link-address field in the message | |||
from the relay agent, is attached. | from the relay agent, is attached. | |||
DHCP server implementations conforming to this specification must, | DHCP server implementations conforming to this specification MUST, | |||
for the purposes of address selection, ignore any link-address field | for the purposes of address selection, ignore any link-address field | |||
whose value is zero. In the text from RFC3315 above, "link-address" | whose value is zero. In the above text from RFC 3315, "link-address" | |||
refers both to the link-address field of the Relay-forward message, | refers to both the link-address field of the Relay-Forward message, | |||
and also the link-address fields in any Relay-forward messages that | and the link-address fields in any Relay-Forward messages that may be | |||
may be nested within the Relay-forward message. | nested within the Relay-Forward message. | |||
5. Message Format | 5. Message Format | |||
The Lightweight DHCPv6 Relay Agent (LDRA) exchanges DHCP messages | The Lightweight DHCPv6 Relay Agent (LDRA) exchanges DHCP messages | |||
between clients and servers using the message formats established in | between clients and servers using the message formats established in | |||
[RFC3315]. | [RFC3315]. | |||
To maintain interoperability with existing DHCP relays and servers | To maintain interoperability with existing DHCP relays and servers, | |||
the message format is unchanged from [RFC3315]. The LDRA implements | the message format is unchanged from [RFC3315]. The LDRA implements | |||
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- | |||
and Interface-ID. The link-address parameter MUST be set to the | address, and Interface-ID. The link-address parameter MUST be set to | |||
unspecified address. The Interface-ID Relay Agent Option MUST be | the unspecified address. The peer-address parameter MUST be set as | |||
included in the Relay-Forward message. The LDRA MAY insert | specified in Section 6.1. The Interface-ID Relay Agent option MUST | |||
be included in the Relay-Forward message. The LDRA MAY insert | ||||
additional relay agent options. | additional relay agent options. | |||
5.2. Relay-Reply Message | 5.2. Relay-Reply Message | |||
The Relay-Reply message is constructed by a DHCPv6 server to send | The Relay-Reply message is constructed by a DHCPv6 server to send | |||
parameters to a DHCP client when a relay agent is present between the | 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 | server and the client. The Relay-Reply message may be sent after an | |||
initial Relay-Forward message as the parameters link-address, peer- | initial Relay-Forward message as the parameters link-address, peer- | |||
address, Interface-ID and the relay agent's IP address are learnt | address, and Interface-ID, as well as the relay agent's IP address, | |||
from the Relay-Forward message. | are learnt from the Relay-Forward message. | |||
The server MUST include the Interface-ID option in the Relay-Reply | The server MUST include the Interface-ID option in the Relay-Reply | |||
Message to indicate to the LDRA the interface on which the de- | Message to indicate to the LDRA the interface on which the | |||
capsulated message should be forwarded. | decapsulated message should be forwarded. | |||
5.3. Mandatory DHCP Options | 5.3. Mandatory DHCP Options | |||
Parameters are exchanged between DHCP client, relay-agent and server | Parameters are exchanged between the DHCP client, Relay Agent, and | |||
through the use of DHCP options. There is a set of mandatory DHCP | server through the use of DHCP options. There is a set of mandatory | |||
options that MUST be included by the LDRA in all Relay-Forward | DHCP options that MUST be included by the LDRA in all Relay-Forward | |||
messages. These are the: | messages. These are the: | |||
o Relay-Message Option | o Relay-Message Option | |||
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]. | |||
If a Relay-Message would exceed the MTU of the outgoing interface it | If a Relay-Message would exceed the MTU of the outgoing interface, it | |||
MUST be discarded and an error condition SHOULD be logged. | 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 an LDRA receives a Relay-Reply message with | |||
Interface-ID option present and link-address unspecified, the LDRA | an 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. | |||
The format of the Interface-ID is outside the scope of this | The format of the Interface-ID is outside the scope of this | |||
contribution. The Interface-ID SHOULD be considered an opaque value, | contribution. The Interface-ID SHOULD be considered an opaque value; | |||
i.e. the server SHOULD NOT try to parse the contents of the | i.e., the server SHOULD NOT try to parse the contents of the | |||
Interface-ID option. The LDRA SHOULD use the same Interface-ID value | Interface-ID option. The LDRA SHOULD use the same Interface-ID value | |||
for a given interface, and this value SHOULD be retained across | for a given interface, and this value SHOULD be retained across | |||
restarts. This is because, if the Interface-ID changes, a server | restarts. This is because if the Interface-ID changes, a server will | |||
will not be able to use it reliably in parameter assignment policies. | not be able to use it reliably in parameter assignment policies. | |||
6. Agent Behaviour | 6. Agent Behaviour | |||
The LDRA MUST have each of its interfaces configured as either | The LDRA MUST have each of its interfaces configured as either | |||
client-facing or network-facing. The LDRA uses the notion of client- | client-facing or network-facing. The LDRA uses the notion of client- | |||
facing and network-facing interfaces to process DHCPv6 messages. | facing and network-facing interfaces to process DHCPv6 messages. | |||
6.1. Relaying a Client Message | 6.1. Relaying a Client Message | |||
When a DHCPv6 message (defined in [RFC3315]) is received on any | The LDRA MUST intercept and process all IP traffic received on any | |||
client-facing interface, the LDRA MUST intercept and process the | client-facing interface that has: | |||
message. The LDRA MUST also prevent the original message from being | ||||
forwarded on the network facing interface. | o destination IP address set to All_DHCP_Relay_Agents_and_Servers | |||
(ff02::1:2); | ||||
o protocol type UDP; and | ||||
o destination port 547. | ||||
The LDRA MUST also prevent the original message from being forwarded | ||||
on the network-facing interface. | ||||
The lightweight relay agent adds any other options it is configured | The lightweight relay agent adds any other options it is configured | |||
or required to include in the Relay-Forward message. The LDRA MUST | or required to include in the Relay-Forward message. The LDRA MUST | |||
set the link-address field of the Relay-forward message to the | set the link-address field of the Relay-Forward message to the | |||
Unspecified Address (::) and MUST include the Interface-ID option in | Unspecified Address (::) and MUST include the Interface-ID option in | |||
all DHCP Relay-Forward messages. | all DHCP Relay-Forward messages. | |||
If the message received on the client-facing interface is a Relay- | If the message received on the client-facing interface is a Relay- | |||
Forward message, the LDRA MUST set the Hop-Count field in the newly | Forward message, the LDRA MUST set the hop-count field in the newly | |||
created Relay-Forward message to the value of the hop-count field in | created Relay-Forward message to the value of the hop-count field in | |||
the received message incremented by 1 as specified in [RFC3315]. | the received message, incremented by 1 as specified in [RFC3315]. | |||
The LDRA MUST copy the IP destination and link-layer destination | The LDRA MUST copy the IP destination and link-layer destination | |||
addresses from the client-originated message into the IP destination | addresses from the client-originated message into the IP destination | |||
address and link-layer destination address of the Relay-forward | address and link-layer destination address of the Relay-Forward | |||
message. | message. | |||
The LDRA MUST copy the IP source address from the client-originated | The LDRA MUST copy the IP source address from the client-originated | |||
message into the peer-address field of the Relay-forward message. | message into the peer-address field of the Relay-Forward message. | |||
The LDRA MUST copy the link-layer source address from the client- | The LDRA MUST copy the link-layer source address from the client- | |||
originated message into the link-layer source address of the Relay- | originated message into the link-layer source address of the Relay- | |||
forward message. | Forward message. | |||
6.1.1. Client Message Validation | 6.1.1. Client Message Validation | |||
On receipt of a DHCP message on a client-facing interface, the LDRA | On receipt of a DHCP message on a client-facing interface, the LDRA | |||
MUST discard a message if it is of one of following message types: | MUST discard a message if it is of one of the following message | |||
types: | ||||
o ADVERTISE (2) | o ADVERTISE (2) | |||
o REPLY (7) | o REPLY (7) | |||
o RECONFIGURE (10) | o RECONFIGURE (10) | |||
o RELAY-REPLY (13) | o RELAY-REPL (13) | |||
Options contained in the DHCPv6 message MUST NOT be validated by the | Options contained in the DHCPv6 message MUST NOT be validated by the | |||
LDRA, making it the responsibility of the DHCP server to check | LDRA, making it the responsibility of the DHCP server to check | |||
message option validity and allow new options to be introduced | message option validity and allow new options to be introduced | |||
without changes on the LDRA. | without changes on the LDRA. | |||
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 | |||
setting for all client-facing interfaces, marking them either as | configuration setting for all client-facing interfaces, marking them | |||
trusted or as untrusted. This setting SHOULD be configurable per | either as trusted or as untrusted. This setting SHOULD be | |||
interface. When a client-facing interface is deemed untrusted the | configurable per interface. When a client-facing interface is deemed | |||
LDRA MUST discard any message received from the client-facing | untrusted, the LDRA MUST discard any message of type RELAY-FORW (12) | |||
interface of type RELAY-FORWARD (12). | received from the client-facing 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 only forward Relay- | An LDRA MUST inspect the DHCP message type and only forward Relay- | |||
Reply messages. Other DHCP message types MUST be silently discarded. | Reply messages. Other DHCP message types MUST be silently discarded. | |||
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 are | |||
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 | |||
configured on the LDRA, and | address is 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. | |||
If the Relay-Reply message is valid, the LDRA copies the peer-address | If the Relay-Reply message is valid, the LDRA copies the peer-address | |||
into to the destination IP address field. The LDRA SHOULD forward | into the destination IP address field. The LDRA SHOULD forward the | |||
the packet to the correct client- facing interface using the | packet to the correct client-facing interface using the destination | |||
destination link-layer (MAC) address or the Interface-Id in the | link-layer (Media Access Control (MAC)) address or the Interface-ID | |||
Relay-Reply. The LDRA SHOULD NOT retransmit the packet on any other | in the Relay-Reply. The LDRA SHOULD NOT retransmit the packet on any | |||
interface. The contents of the Relay Message Option is put into an | other interface. The contents of the Relay Message option are put | |||
IP/UDP packet and then forwarded to the client. | 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 the traffic pattern specified in Section 6.1. The | |||
All_DHCP_Relay_Agents_and_Servers (FF02::1:2). The LDRA MUST NOT | LDRA MUST NOT forward the original client message to a network-facing | |||
forward the original client message to a network-facing interface, it | interface; it MUST process the message and add the appropriate Relay- | |||
MUST process the message and add the appropriate Relay-Forward | Forward options as described in previous sections. | |||
options as described in previous sections. | ||||
7.1. Client and Server on Same Link | 7.1. Client and Server on Same Link | |||
The access node acts as a bridge; it has no information about any IP | 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 | prefixes that are valid on the link. Thus, a server should consider | |||
address and parameter assignment as if the client DHCP message was | address and parameter assignment as if the client DHCP message were | |||
not relayed. | not relayed. | |||
+--------+ | +--------+ | |||
Client -------| | | Client -------| | | |||
| Access | | | Access | | |||
Client -------| Node |-----+ | Client -------| Node |-----+ | |||
| (LDRA) | | | | (LDRA) | | | |||
Client -------| | | | Client -------| | | | |||
+--------+ | | +--------+ | | |||
| +--------+ | | +--------+ | |||
|------| Server | | |------| Server | | |||
| +--------+ | | +--------+ | |||
skipping to change at page 9, line 48 | skipping to change at page 10, line 25 | |||
+--------+ | | +--------+ | | |||
Client -------| | | | Client -------| | | | |||
| Access | | | | Access | | | |||
Client -------| Node |-----+ | Client -------| Node |-----+ | |||
| (LDRA) | | | (LDRA) | | |||
Client -------| | | Client -------| | | |||
+--------+ | +--------+ | |||
<--------- IPv6 Link --------> | <--------- IPv6 Link --------> | |||
For example, if a client sent a DHCP solicit message that was relayed | For example, if a client sent a DHCP Solicit message that was relayed | |||
by the LDRA to the server, the server would receive the following | by the LDRA to the server, the server would receive the following | |||
Relay-Forward message from the LDRA: | Relay-Forward message from the LDRA: | |||
src-ip: client link-local address | src-ip: client link-local address | |||
dst-ip: All_DHCP_Relay_Agents_and_Servers | dst-ip: All_DHCP_Relay_Agents_and_Servers | |||
msg-type: RELAY-FORWARD | ||||
msg-type: RELAY-FORW | ||||
hop-count: 0 | hop-count: 0 | |||
link-address: Unspecified_Address | link-address: Unspecified_Address | |||
peer-address: client link-local address | peer-address: client link-local address | |||
Interface-ID Option: | Interface-ID Option: | |||
interface-id: LDRA-inserted interface-id | interface-id: LDRA-inserted interface-id | |||
Relay-Message Option, which contains: | Relay-Message Option, which contains: | |||
msg-type: SOLICIT | msg-type: SOLICIT | |||
Solicit Message Options: <from client> | Solicit Message Options: <from client> | |||
7.2. Client and Server behind Relay Agent | 7.2. Client and Server behind Relay Agent | |||
The client and server are on different IPv6 links, separated by one | 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 | or more relay agents that will typically act as a router. The LDRA | |||
will send Relay-Forward messages upstream towards the second relay | will send Relay-Forward messages upstream towards the second relay | |||
agent which in turn will process the messages. | agent, which in turn will process the messages. | |||
+--------+ | +--------+ | |||
Client -------| | | Client -------| | | |||
| Access | | | Access | | |||
Client -------| Node |-----+ | Client -------| Node |-----+ | |||
| (LDRA) | | | | (LDRA) | | | |||
Client -------| | | | Client -------| | | | |||
+--------+ | | +--------+ | | |||
| +--------+ +--------+ | | +--------+ +--------+ | |||
|------| RelayB |-------| Server | | |------| RelayB |-------| Server | | |||
| +--------+ +--------+ | | +--------+ +--------+ | |||
+--------+ | | +--------+ | | |||
Client -------| | | | Client -------| | | | |||
| Access | | | | Access | | | |||
Client -------| Node |-----+ | Client -------| Node |-----+ | |||
| (LDRA) | | | (LDRA) | | |||
Client -------| | | Client -------| | | |||
+--------+ | +--------+ | |||
<------- IPv6 Link A -------> <--IPv6 Link B--> | <------- IPv6 Link A -------> <--IPv6 Link B--> | |||
For example, if a client sent a DHCP solicit message that was relayed | 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 | by the LDRA to another relay agent and then to the server, the server | |||
would receive the following Relay-Forward message from the LDRA: | would receive the following Relay-Forward message from the LDRA: | |||
src-ip: relayB | src-ip: relayB | |||
dst-ip: server | dst-ip: server | |||
msg-type: RELAY-FORWARD | ||||
msg-type: RELAY-FORW | ||||
hop-count: 1 | hop-count: 1 | |||
link-address: relayB address from link A | link-address: relayB address from link A | |||
peer-address: client link-local address | peer-address: client link-local address | |||
Relay-Message Option, which contains: | Relay-Message Option, which contains: | |||
msg-type: RELAY-FORWARD | ||||
msg-type: RELAY-FORW | ||||
hop-count: 0 | hop-count: 0 | |||
link-address: Unspecified_Address | link-address: Unspecified_Address | |||
peer-address: client link-local address | peer-address: client link-local address | |||
Interface-ID Option: | Interface-ID Option: | |||
interface-id: LDRA-inserted interface-id | interface-id: LDRA-inserted interface-id | |||
Relay-Message Option, which contains: | Relay-Message Option, which contains: | |||
msg-type: SOLICIT | msg-type: SOLICIT | |||
Solicit Message Options: <from client> | Solicit Message Options: <from client> | |||
7.3. Relay Agent in Front of LDRA | 7.3. Relay Agent in Front of LDRA | |||
The client and server are on different IPv6 links, separated by one | 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 | or more relay agents that will typically act as a router, and there | |||
an [RFC3315] Relay Agent on the client-facing Interface of the LDRA. | is an [RFC3315] Relay Agent on the client-facing interface of the | |||
The LDRA will send Relay-Forward messages upstream towards the second | LDRA. The LDRA will send Relay-Forward messages upstream towards the | |||
relay agent which in turn will process the messages. | second relay agent, which in turn will process the messages. | |||
+--------+ | +--------+ | |||
RelayC -------| | | RelayC -------| | | |||
| Access | | | Access | | |||
RelayC -------| Node |-----+ | RelayC -------| Node |-----+ | |||
| (LDRA) | | | | (LDRA) | | | |||
RelayC -------| | | | RelayC -------| | | | |||
+--------+ | | +--------+ | | |||
| +--------+ +--------+ | | +--------+ +--------+ | |||
|------| RelayB |-------| Server | | |------| RelayB |-------| Server | | |||
| +--------+ +--------+ | | +--------+ +--------+ | |||
+--------+ | | +--------+ | | |||
RelayC -------| | | | RelayC -------| | | | |||
| Access | | | | Access | | | |||
RelayC -------| Node |-----+ | RelayC -------| Node |-----+ | |||
| (LDRA) | | | (LDRA) | | |||
RelayC -------| | | RelayC -------| | | |||
+--------+ | +--------+ | |||
<------- IPv6 Link A -------> <--IPv6 Link B--> | <------- IPv6 Link A -------> <--IPv6 Link B--> | |||
For example, if a client sent a DHCP solicit message that was relayed | For example, if a client sent a DHCP Solicit message that was relayed | |||
by RelayC and the LDRA to another relay agent, RelayB, and then to | by RelayC and the LDRA to another relay agent, RelayB, and then to | |||
the server, the server would receive the following Relay-Forward | the server, the server would receive the following Relay-Forward | |||
message: | message: | |||
src-ip: relayB | src-ip: relayB | |||
dst-ip: server | dst-ip: server | |||
msg-type: RELAY-FORWARD | ||||
msg-type: RELAY-FORW | ||||
hop-count: 2 | hop-count: 2 | |||
link-address: relayB address from link A | link-address: relayB address from link A | |||
peer-address: relayC | peer-address: relayC | |||
Relay-Message Option, which contains: | Relay-Message Option, which contains: | |||
msg-type: RELAY-FORWARD | ||||
msg-type: RELAY-FORW | ||||
hop-count: 1 | hop-count: 1 | |||
link-address: Unspecified_Address | link-address: Unspecified_Address | |||
peer-address: relayC | peer-address: relayC | |||
Interface-ID Option: | Interface-ID Option: | |||
interface-id: LDRA-inserted interface-id | interface-id: LDRA-inserted interface-id | |||
Relay-Message Option, which contains: | Relay-Message Option, which contains: | |||
msg-type: RELAY-FORWARD | ||||
msg-type: RELAY-FORW | ||||
hop-count: 0 | hop-count: 0 | |||
link-address: global or unspecified address | ||||
link-address: global or Unspecified_Address | ||||
peer-address: end client address | peer-address: end client address | |||
Interface-ID Option: (if required) | Interface-ID Option: (if required) | |||
interface-id: relayC inserted Interface-ID | ||||
interface-id: relayC-inserted Interface-ID | ||||
Relay-Message Option, which contains: | Relay-Message Option, which contains: | |||
msg-type: SOLICIT | msg-type: SOLICIT | |||
Solicit Message Options: <from end client> | Solicit Message Options: <from end client> | |||
8. Contributors | 8. Contributors | |||
The authors would like to thank the following for their support, | The authors would like to thank the following for their support: | |||
Lieven Levrau, Alastair Johnson, Robert Haylock, Mickey Vucic, Ludwig | Lieven Levrau, Alastair Johnson, Robert Haylock, Mickey Vucic, Ludwig | |||
Pauwels, Fernando Cuervo, John Kaippallimalil, Fredrik Garneij, | Pauwels, Fernando Cuervo, John Kaippallimalil, Fredrik Garneij, | |||
Alfred Hoenes and Ted Lemon. | Alfred Hoenes, Ted Lemon, Tatuya Jinmei, David Hankins, and Ralph | |||
Droms. | ||||
Comments are solicited and should be addressed to the DHC WG mailing | Comments are solicited and should be addressed to the DHC WG mailing | |||
list (dhcwg@ietf.org) and/or the author. | list (dhcwg@ietf.org) and/or the authors. | |||
9. IANA Considerations | ||||
This document does not introduce any new namespaces for the IANA to | ||||
manage. | ||||
10. Security Considerations | 9. Security Considerations | |||
Although the LDRA only listens to client-originated IPv6 traffic sent | The security issues pertaining to DHCPv6 Relay Agents as specified in | |||
to the All_DHCPv6_Servers_and_Relay_Agents address on UDP port 547, | Section 23 of [RFC3315] are also applicable to LDRAs. The LDRA | |||
the LDRA SHOULD implement some form of rate-limiting on received | SHOULD implement some form of rate-limiting on client-originated | |||
messages to prevent excessive process utilisation. As DHCP is | traffic in order to prevent excessive process utilisation. The | |||
session-oriented, messages in excess of the rate-limit may be | traffic to be rate-limited can be easily identified since the LDRA | |||
silently discarded. | listens only to client-originated IPv6 traffic sent to the | |||
All_DHCPv6_Servers_and_Relay_Agents address on UDP port 547 and does | ||||
not process any other client-originated traffic. 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 | 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. Acknowledgements | 10. 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 | 10.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", BCP 14, RFC 2119, March 1997. | |||
[RFC3315] Droms, R., "Dynamic Host Configuration Protocol for IPv6 | [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, | |||
(DHCPv6)", RFC 3315, July 2003. | C., and M. Carney, "Dynamic Host Configuration Protocol | |||
for IPv6 (DHCPv6)", RFC 3315, July 2003. | ||||
12.2. Informative References | 10.2. Informative References | |||
[L2RA] Joshi, B., "Layer 2 Relay Agent Information", IETF | [L2RA] Joshi, B. and P. Kurapati, "Layer 2 Relay Agent | |||
Draft draft-ietf-dhc-l2ra-04, April 2009. | Information", Work in Progress, April 2011. | |||
[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. | |||
Authors' Addresses | Authors' Addresses | |||
David Miles (editor) | David Miles (editor) | |||
Alcatel-Lucent | Alcatel-Lucent | |||
L3 / 215 Spring St | L3 / 215 Spring St. | |||
Melbourne, Victoria 3000 | Melbourne, Victoria 3000 | |||
Australia | Australia | |||
Phone: +61 3 9664 3308 | Phone: +61 3 9664 3308 | |||
Email: david.miles@alcatel-lucent.com | EMail: david.miles@alcatel-lucent.com | |||
Sven Ooghe | Sven Ooghe | |||
Alcatel-Lucent | Alcatel-Lucent | |||
Copernicuslaan 50 | Copernicuslaan 50 | |||
2018 Antwerp, | 2018 Antwerp, | |||
Belgium | Belgium | |||
Phone: | EMail: sven.ooghe@alcatel-lucent.com | |||
Email: sven.ooghe@alcatel-lucent.com | ||||
Wojciech Dec | Wojciech Dec | |||
Cisco Systems | Cisco Systems | |||
Haarlerberdweg 13-19 | Haarlerberdweg 13-19 | |||
1101 CH Amsterdam, | 1101 CH Amsterdam, | |||
The Netherlands | The Netherlands | |||
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. 115 change blocks. | ||||
190 lines changed or deleted | 238 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |