draft-ietf-dhc-dhcpv6-ldra-01.txt   draft-ietf-dhc-dhcpv6-ldra-02.txt 
DHC Working Group D. Miles, Ed. DHC Working Group D. Miles, Ed.
Internet-Draft S. Ooghe Internet-Draft S. Ooghe
Intended status: Standards Track Alcatel-Lucent Intended status: Standards Track Alcatel-Lucent
Expires: April 16, 2010 W. Dec Expires: December 10, 2010 W. Dec
Cisco Systems Cisco Systems
S. Krishnan S. Krishnan
A. Kavanagh A. Kavanagh
Ericsson Ericsson
October 13, 2009 June 8, 2010
Lightweight DHCPv6 Relay Agent Lightweight DHCPv6 Relay Agent
draft-ietf-dhc-dhcpv6-ldra-01 draft-ietf-dhc-dhcpv6-ldra-02
Abstract
This document proposes a Lightweight DHCPv6 Relay Agent (LDRA) that
is used to insert relay agent options in DHCPv6 message exchanges
identifying client-facing interfaces. The LDRA can be implemented in
existing access nodes (such as DSLAMs and Ethernet switches) that do
not support IPv6 control or routing functions.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted 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). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on December 10, 2010.
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 April 16, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This document proposes a Lightweight DHCPv6 Relay Agent (LDRA) that described in the Simplified BSD License.
is used to insert relay agent options in DHCPv6 message exchanges
identifying client-facing interfaces. The LDRA can be implemented in
existing access nodes (such as DSLAMs and Ethernet switches) that do
not support IPv6 control or routing functions.
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 . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . 7
6.1.2. Trusted and Untrusted Interfaces . . . . . . . . . . . 8 6.1.2. Trusted and Untrusted Interfaces . . . . . . . . . . . 8
6.2. Relaying a Relay-Reply message from the network . . . . . 8 6.2. Relaying a Relay-Reply message from the network . . . . . 8
7. Network Topology . . . . . . . . . . . . . . . . . . . . . . . 9 7. Network Topology . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Client and Server on Same Link . . . . . . . . . . . . . . 10 7.1. Client and Server on Same Link . . . . . . . . . . . . . . 9
7.2. Client and Server behind Relay Agent . . . . . . . . . . . 10 7.2. Client and Server behind Relay Agent . . . . . . . . . . . 10
7.3. Relay Agent in Front of LDRA . . . . . . . . . . . . . . . 11 7.3. Relay Agent in Front of LDRA . . . . . . . . . . . . . . . 11
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
skipping to change at page 3, line 38 skipping to change at page 3, line 38
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 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 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.
Client-facing An interface on the access node that Client-facing An interface on the access node that
carries traffic towards the DHCPv6 client 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 a 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 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.
Router A node that forwards packets not directly Router A node that forwards packets not directly
addressed to itself addressed to itself.
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 IP address that is comprised entirely of Unspecified address An IPv6 address that is comprised entirely
zeros of zeros.
4. Server Considerations 4. Server Considerations
This document updates the behavior specified in section 11 of DHCP This document updates the behavior specified in section 11 of DHCP
for IPv6 [RFC3315]. RFC3315 states, in part: for IPv6 [RFC3315]. RFC3315 states, in part:
o If the server receives the message from a forwarding relay agent, 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 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.
skipping to change at page 5, line 35 skipping to change at page 5, line 35
the same message types as a normal DHCPv6 Relay Agent. They are: the same message types as a normal DHCPv6 Relay Agent. They are:
o Relay-Forward Messages o Relay-Forward Messages
o Relay-Reply Messages o Relay-Reply Messages
5.1. Relay-Forward Message 5.1. Relay-Forward Message
The Relay-Forward message is created by any DHCPv6 Relay Agent, The Relay-Forward message is created by any DHCPv6 Relay Agent,
including an LDRA, to forward messages between clients and servers or including an LDRA, to forward messages between clients and servers or
other relay agents. These messages are built as specified in other relay agents. These messages are built as specified in .
[RFC3315] [RFC3315].
The Relay-Forward message contains relay agent parameters that The Relay-Forward message contains relay agent parameters that
identify the client-facing interface on which any reply messages identify the client-facing interface on which any reply messages
should be forwarded. These parameters are link-address, peer-address should be forwarded. These parameters are link-address, peer-address
and Interface-ID. The link-address parameter MUST be set to the and Interface-ID. The link-address parameter MUST be set to the
unspecified address. The Interface-ID Relay Agent Option MUST be unspecified address. The Interface-ID Relay Agent Option MUST be
included in the Relay-Forward message. The LDRA MAY insert included in the Relay-Forward message. The LDRA MAY insert
additional relay agent options. additional relay agent options.
5.2. Relay-Reply Message 5.2. Relay-Reply Message
skipping to change at page 6, line 14 skipping to change at page 6, line 14
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.
5.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 is 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
Relay-Reply 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,
skipping to change at page 7, line 8 skipping to change at page 7, line 8
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.
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 (DHCPv6 server) facing. The LDRA uses the client-facing or network-facing. The LDRA uses the notion of client-
notion of client-facing and network-facing interfaces to process the facing and network-facing interfaces to process DHCPv6 messages.
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 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
skipping to change at page 7, line 43 skipping to change at page 7, line 42
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 the 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 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.
6.1.2. Trusted and Untrusted Interfaces 6.1.2. Trusted and Untrusted Interfaces
In [RFC3046] DHCPv4 relay-agents had their client-facing interfaces In [RFC3046] DHCPv4 relay-agents had their client-facing interfaces
set to trusted and untrusted. An LDRA MUST implement a configuration set to trusted and untrusted. An LDRA MUST implement a configuration
setting for all client-facing interfaces, marking them either as setting for all client-facing interfaces, marking them either as
skipping to change at page 8, line 35 skipping to change at page 8, line 33
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
relay-agent has inserted along the path, whenever the data path relay-agent has inserted along the path, whenever the data path
between LDRA and server falls within a protected or operator between LDRA and server falls within a protected or operator
controlled environment. controlled environment.
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 them at which level
nesting the relay-agent options should be parsed. This removes the of nesting the relay-agent options should be parsed. This removes
need for an interface to be configured as trusted or untrusted by the 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.
6.2. Relaying a Relay-Reply message from the network 6.2. Relaying a Relay-Reply message from the network
The LDRA MUST intercept and process all IP traffic received on the The LDRA MUST intercept and process all IP traffic received on the
network-facing interface that has: network-facing interface that has:
o a link-local scoped source address; o a link-local scoped source address;
o a link-local scoped destination address;
o a link-local scoped destination address;
o protocol type UDP; and o protocol type UDP; and
o destination port 547 o destination port 547
An LDRA MUST inspect the DHCP message type and MUST silently discard An LDRA MUST inspect the DHCP message type and MUST silently discard
any DHCP message that is not type Relay-Reply or is otherwise an any DHCP message that is not type Relay-Reply or is otherwise an
invalid DHCPv6 packet. The LDRA SHOULD ignore any message that does invalid DHCPv6 packet. The LDRA SHOULD ignore any message that does
not meet this criteria and subject it to normal packet forwarding. not meet this criteria and subject it to normal packet forwarding.
In addition to the validity checks performed by a relay agent in The Relay-Reply message is considered valid by the LDRA if it passes
[RFC3315] , the Relay-Reply message is considered valid by the LDRA the validity checks to be performed by a relay agent per [RFC3315]
if: 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 MUST be - the Relay-Reply peer-address and the destination IP address is
identical and MUST be a link-local scoped address when no IP address identical and it is a link-local scoped address when no IP address is
is configured on the LDRA, and configured on the LDRA, and
- the link-address is the Unspecified Address when no IP address is - the link-address is the Unspecified Address when no IP address is
configured on the LDRA configured on the LDRA
The LDRA copies the peer-address into to the destination IP address The LDRA copies the peer-address into to the destination IP address
field. The LDRA SHOULD forward the packet to the correct client- field. The LDRA SHOULD forward the packet to the correct client-
facing interface using the destination link-layer (MAC) address or facing interface using the destination link-layer (MAC) address or
the Interface-Id in the Relay-Reply. The LDRA SHOULD NOT retransmit the Interface-Id in the Relay-Reply. The LDRA SHOULD NOT retransmit
the packet on any other interface. The contents of the Relay Message 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. Option is put into an IP/UDP packet and then forwarded to the client.
skipping to change at page 10, line 29 skipping to change at page 10, line 24
|------| Server | |------| Server |
| +--------+ | +--------+
+--------+ | +--------+ |
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 and then to the server, the server would receive the by the LDRA to the server, the server would receive the following
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-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:
skipping to change at page 11, line 12 skipping to change at page 11, line 12
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-FORWARD
hop-count: 1 hop-count: 1
link-address: relayB address from link A link-address: relayB address from link A
skipping to change at page 12, line 12 skipping to change at page 12, line 12
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 |
| +--------+ +--------+ | +--------+ +--------+
+--------+ | +--------+ |
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 the LDRA to another relay agent and then to the server, the server by RelayC and the LDRA to another relay agent, RelayB, and then to
would receive the following Relay-Forward message from the LDRA: the server, the server would receive the following Relay-Forward
message:
src-ip: relayB src-ip: relayB
dst-ip: server dst-ip: server
msg-type: RELAY-FORWARD msg-type: RELAY-FORWARD
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-FORWARD
hop-count: 1 hop-count: 1
skipping to change at page 13, line 46 skipping to change at page 13, line 46
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
[RFC3315] Droms, R., "Dynamic Host Configuration Protocol for IPv6 [RFC3315] Droms, R., "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003. (DHCPv6)", RFC 3315, July 2003.
11.2. Informative References 11.2. Informative References
[L2RA] Joshi, B., "Layer 2 Relay Agent Information", IETF [L2RA] Joshi, B., "Layer 2 Relay Agent Information", IETF
Draft draft-ietf-dhc-l2ra-02, May 2008. Draft draft-ietf-dhc-l2ra-04, April 2009.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", [RFC3046] Patrick, M., "DHCP Relay Agent Information Option",
RFC 3046, January 2001. RFC 3046, January 2001.
[TR-101] The Broadband Forum, "Migration to Ethernet-Based DSL [TR-101] The Broadband Forum, "Migration to Ethernet-Based DSL
Aggregation", Technical Report TR-101, April 2006. Aggregation", Technical Report TR-101, April 2006.
Authors' Addresses Authors' Addresses
David Miles (editor) David Miles (editor)
 End of changes. 41 change blocks. 
77 lines changed or deleted 75 lines changed or added

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