draft-ietf-dhc-dhcpv6-ldra-00.txt   draft-ietf-dhc-dhcpv6-ldra-01.txt 
DHC Working Group D. Miles, Ed. DHC Working Group D. Miles, Ed.
Internet-Draft S. Ooghe Internet-Draft S. Ooghe
Intended status: Informational Alcatel-Lucent Intended status: Standards Track Alcatel-Lucent
Expires: January 3, 2010 W. Dec Expires: April 16, 2010 W. Dec
Cisco Systems Cisco Systems
S. Krishnan S. Krishnan
A. Kavanagh A. Kavanagh
Ericsson Ericsson
July 2, 2009 October 13, 2009
Lightweight DHCPv6 Relay Agent (LDRA) Lightweight DHCPv6 Relay Agent
draft-ietf-dhc-dhcpv6-ldra-00 draft-ietf-dhc-dhcpv6-ldra-01
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 3, 2010. This Internet-Draft will expire on April 16, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 19 skipping to change at page 2, line 19
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.
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. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Server Considerations . . . . . . . . . . . . . . . . . . . . 4
4.1. Relay-Forward Message . . . . . . . . . . . . . . . . . . 5 5. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Relay-Reply Message . . . . . . . . . . . . . . . . . . . 5 5.1. Relay-Forward Message . . . . . . . . . . . . . . . . . . 5
4.3. Mandatory DHCP Options . . . . . . . . . . . . . . . . . . 5 5.2. Relay-Reply Message . . . . . . . . . . . . . . . . . . . 5
4.3.1. Relay-Message Option . . . . . . . . . . . . . . . . . 5 5.3. Mandatory DHCP Options . . . . . . . . . . . . . . . . . . 6
4.3.2. Interface-ID Option . . . . . . . . . . . . . . . . . 6 5.3.1. Relay-Message Option . . . . . . . . . . . . . . . . . 6
5. Agent Behaviour . . . . . . . . . . . . . . . . . . . . . . . 6 5.3.2. Interface-ID Option . . . . . . . . . . . . . . . . . 6
5.1. Relaying a Client Message . . . . . . . . . . . . . . . . 6 6. Agent Behaviour . . . . . . . . . . . . . . . . . . . . . . . 7
5.1.1. Client Message Validation . . . . . . . . . . . . . . 7 6.1. Relaying a Client Message . . . . . . . . . . . . . . . . 7
5.1.2. Trusted and Untrusted Interfaces . . . . . . . . . . . 7 6.1.1. Client Message Validation . . . . . . . . . . . . . . 7
5.2. Relaying a Relay-Reply message from the network . . . . . 8 6.1.2. Trusted and Untrusted Interfaces . . . . . . . . . . . 8
6. Network Topology . . . . . . . . . . . . . . . . . . . . . . . 9 6.2. Relaying a Relay-Reply message from the network . . . . . 8
6.1. Client and Server on Same Link . . . . . . . . . . . . . . 9 7. Network Topology . . . . . . . . . . . . . . . . . . . . . . . 9
6.2. Client and Server behind Relay Agent . . . . . . . . . . . 10 7.1. Client and Server on Same Link . . . . . . . . . . . . . . 10
6.3. Relay Agent in Front of LDRA . . . . . . . . . . . . . . . 11 7.2. Client and Server behind Relay Agent . . . . . . . . . . . 10
7. Server Considerations . . . . . . . . . . . . . . . . . . . . 12 7.3. Relay Agent in Front of LDRA . . . . . . . . . . . . . . . 11
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
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 3, line 43 skipping to change at page 3, line 43
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 may be as an equivalent
to the Broadband Forum TR-101 Layer 2 DHCP Relay Agent[TR-101] to the Broadband Forum TR-101 Layer 2 DHCP Relay Agent[TR-101]
described in [L2RA] described in [L2RA]
3. Terminology 3. Terminology
Access Node A device that combines many interfaces onto
one link. An access node is not IP-aware
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
Client-facing An interface on the access node that
carries traffic towards the DHCPv6 client
Host A non-routing IPv6 node that is Host A non-routing IPv6 node that is
participating in DHCPv6 message exchange participating in DHCPv6 message exchange
IP Internet Protocol Version 6 (IPv6) IP Internet Protocol Version 6 (IPv6)
LDRA Lightweight DHCPv6 Relay Agent LDRA Lightweight DHCPv6 Relay Agent
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.
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
carries traffic towards the DHCPv6
server(s)
Node A device that implements IPv6 Node A device that implements IPv6
Router A node that forwards packets not directly Router A node that forwards packets not directly
addressed to itself 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 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
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.
Unspecified address An IP address that is comprised entirely of Unspecified address An IP address that is comprised entirely of
zeros zeros
4. Message Format 4. Server Considerations
This document updates the behavior specified in section 11 of DHCP
for IPv6 [RFC3315]. RFC3315 states, in part:
o 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
interface, identified by the link-address field in the message
from the relay agent, is attached.
DHCP server implementations conforming to this specification must,
for the purposes of address selection, ignore any link-address field
whose value is zero. In the text from RFC3315 above, "link-address"
refers both to the link-address field of the Relay-forward message,
and also the link-address fields in any Relay-forward messages that
may be nested within the Relay-forward message.
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
4.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.
4.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, Interface-ID and the relay agent's IP address are learnt
from the Relay-Forward message. 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 de-
capsulated message should be forwarded. capsulated message should be forwarded.
4.3. Mandatory DHCP Options 5.3. Mandatory DHCP Options
Parameters are exchanged between DHCP client, relay-agent and server Parameters are exchanged between DHCP client, relay-agent and server
through the use of DHCP options. There are a set of mandatory DHCP through the use of DHCP options. There are a set of mandatory DHCP
options that MUST be included by the LDRA in all Relay-Forward and options that MUST be included by the LDRA in all Relay-Forward and
Relay-Reply messages. These are the: Relay-Reply messages. These are the:
o Relay-Message Option o Relay-Message Option
o Interface-ID Option o Interface-ID Option
4.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 As an LDRA does not implement ICMPv6, fragmentation of Relay-Messages
is not supported. If a Relay-Message would exceed the MTU of the is not supported. If a Relay-Message would exceed the MTU of the
outgoing interface it MUST be discarded and an error condition SHOULD outgoing interface it MUST be discarded and an error condition SHOULD
be logged. be logged.
4.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.
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 not be able to use it reliably in parameter assignment policies. will not be able to use it reliably in parameter assignment policies.
5. 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 (DHCPv6 server) facing. The LDRA uses the client-facing or network (DHCPv6 server) facing. The LDRA uses the
notion of client-facing and network-facing interfaces to process the notion of client-facing and network-facing interfaces to process the
DHCPv6 messages. DHCPv6 messages.
5.1. Relaying a Client Message 6.1. Relaying a Client Message
When a DHCPv6 message (defined in [RFC3315]) is received on any When a DHCPv6 message (defined in [RFC3315]) is received on any
client-facing interface, the LDRA MUST intercept and process the client-facing interface, the LDRA MUST intercept and process the
message. The LDRA MUST also prevent the original message from being message. The LDRA MUST also prevent the original message from being
forwarded on the network facing interface. 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
skipping to change at page 7, line 18 skipping to change at page 7, line 41
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.
5.1.1. Client Message Validation 6.1.1. Client Message Validation
On receipt of a DHCP message on the client facing interface, the LDRA On receipt of a DHCP message on the 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 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-REPLY (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.
5.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 trusted/ set to trusted and untrusted. An LDRA MUST implement a configuration
untrusted definition for all client-facing interfaces that SHOULD be setting for all client-facing interfaces, marking them either as
configurable per interface. When a client-facing interface is deemed trusted or as untrusted. This setting SHOULD be configurable per
untrusted the LDRA MUST discard any message received from the client- interface. When a client-facing interface is deemed untrusted the
facing interface of type RELAY-FORWARD (12). 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 In DHCPv4 it was not possible for a DHCP server to determine whether
the client or an intermediate relay agent had added relay agent the client or an intermediate relay agent had added relay agent
options and thus trusted interfaces (relay-agent interfaces that options and thus trusted interfaces (relay-agent interfaces that
would allow any DHCP options to be present on incoming messages) and would allow any DHCP options to be present on incoming messages) and
untrusted interfaces (relay-agent interfaces that would ensure there untrusted interfaces (relay-agent interfaces that would ensure there
are no relay-agent options on incoming messages) were defined. In are no relay-agent options on incoming messages) were defined. In
DHCPv6, relay agents encapsulate the received message into the Relay- DHCPv6, relay agents encapsulate the received message into the Relay-
Message Option in addition to adding any relay-agent options. This Message Option in addition to adding any relay-agent options. This
nested message behaviour allows a server to identify the options each nested message behaviour allows a server to identify the options each
skipping to change at page 8, line 20 skipping to change at page 8, line 44
When an LDRA is deployed, DHCPv6 servers MAY be configured with the When an LDRA is deployed, DHCPv6 servers MAY be configured with the
Relay-Forward hop-count of the LDRA to instruct at which level of Relay-Forward hop-count of the LDRA to instruct at which level of
nesting the relay-agent options should be parsed. This removes the nesting the relay-agent options should be parsed. This removes the
need for an interface to be configured as trusted or untrusted by need for an interface to be configured as trusted or untrusted by
providing the DHCPv6 server with an awareness of the LDRA logical providing the DHCPv6 server with an awareness of the LDRA logical
location in the DHCP relay path. This behaviour is dependent on the location in the DHCP relay path. This behaviour is dependent on the
interception of all DHCP messages by the LDRA and the incrementing of interception of all DHCP messages by the LDRA and the incrementing of
the Relay-Forward hop-count if a Relay-Forward message is received the Relay-Forward hop-count if a Relay-Forward message is received
from the client-facing LDRA interface. from the client-facing LDRA interface.
5.2. Relaying a Relay-Reply message from the network 6.2. Relaying a Relay-Reply message from the network
When a valid Relay-Reply is received on any network-facing access The LDRA MUST intercept and process all IP traffic received on the
node interface, it MUST be intercepted by the LDRA. The LDRA MUST network-facing interface that has:
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. The LDRA SHOULD ignore any message that does
not meet this criteria and MUST allow it 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 o a link-local scoped source address;
MUST silently discard all other DHCP message types. 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.
In addition to the validity checks performed by a relay agent in In addition to the validity checks performed by a relay agent in
[RFC3315] , the Relay-Reply message is considered valid by the LDRA [RFC3315] , the Relay-Reply message is considered valid by the LDRA
if: if:
- 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 MUST be - 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 identical and MUST be a link-local scoped address when no IP address
is configured on the LDRA, and 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
The LDRA copies the peer-address into the destination IP address The LDRA copies the peer-address into to the destination IP address
field, and MAY use the destination link-layer address (MAC address) field. The LDRA SHOULD forward the packet to the correct client-
or Interface-ID to determine which interface to send the message to facing interface using the destination link-layer (MAC) address or
the client. The contents of the Relay Message Option is put into an the Interface-Id in the Relay-Reply. The LDRA SHOULD NOT retransmit
IP/UDP packet and then forwarded to the client. 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 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.
6. 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
forward the original client message to a network-facing interface, it forward the original client message to a network-facing interface, it
MUST process the message and add the appropriate Relay-Forward MUST process the message and add the appropriate Relay-Forward
options as described in previous sections. options as described in previous sections.
6.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 was
not relayed. not relayed.
+--------+ +--------+
Client -------| | Client -------| |
| Access | | Access |
Client -------| Node |-----+ Client -------| Node |-----+
| (LDRA) | | | (LDRA) | |
skipping to change at page 10, line 17 skipping to change at page 10, line 47
msg-type: RELAY-FORWARD msg-type: RELAY-FORWARD
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>
6.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 |
| +--------+ +--------+ | +--------+ +--------+
skipping to change at page 11, line 22 skipping to change at page 11, line 46
msg-type: RELAY-FORWARD msg-type: RELAY-FORWARD
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>
6.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 is
an [RFC3315] Relay Agent on the client-facing Interface of the LDRA. an [RFC3315] Relay Agent on the client-facing Interface of the LDRA.
The LDRA will send Relay-Forward messages upstream towards the second The LDRA will send Relay-Forward messages upstream towards the second
relay agent which in turn will process the messages. 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 |
| +--------+ +--------+ | +--------+ +--------+
skipping to change at page 12, line 29 skipping to change at page 13, line 5
msg-type: RELAY-FORWARD msg-type: RELAY-FORWARD
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>
7. Server Considerations
Although permitted in [RFC3315] the LDRA makes specific use of Relay-
Forward link-address fields with a zero value.
o A DHCPv6 server MUST ignore any Relay-Forward link-addresses field
with a zero value in Relay-Forward messages when searching for the
inner-most link-address field. This allows the DHCPv6 server to
select an address appropriate to the L3 link and supports a
combination of L3 DHCPv6 relay agents and LDRA.
o If no non-zero Relay-Forward link-address is found, the DHCPv6
server should act as though the message were directly received.
This is the case where no LDRA is present.
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 and Pauwels, Fernando Cuervo, John Kaippallimalil, Fredrik Garneij,
Alfred Hoenes. Alfred Hoenes and Ted Lemon.
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 author.
9. IANA Considerations 9. IANA Considerations
This document does not introduce any new namespaces for the IANA to This document does not introduce any new namespaces for the IANA to
manage. manage.
10. Security Considerations 10. Security Considerations
 End of changes. 36 change blocks. 
87 lines changed or deleted 101 lines changed or added

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