Subject: [dhcwg] Protocol Action: 'Lightweight DHCPv6 Relay Agent' to Proposed Standard (draft-ietf-dhc-dhcpv6-ldra-03.txt)

From: The IESG <[email-masked]>
Date: Mon, 24 Jan 2011 09:47:32 -0800

The IESG has approved the following document:
- 'Lightweight DHCPv6 Relay Agent'
  (draft-ietf-dhc-dhcpv6-ldra-03.txt) as a Proposed Standard

This document is the product of the Dynamic Host Configuration Working
Group.

The IESG contact persons are Ralph Droms and Jari Arkko.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-ldra/

Technical Summary

	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.

Working Group Summary

	This document appeared in the working group at the end of
	2008.  There has been substantial interest in this document.

Document Quality

	The document has undergone careful review, and the working
	group is satisfied with its quality.

Personnel
 
        The document shepherd is Ted Lemon <[email-masked]>.  Ralph
        Droms <[email-masked]> is the Responsible AD.

RFC Editor Note

In section 4, change "must" to "MUST":

OLD:

   DHCP server implementations conforming to this specification must,

NEW:

   DHCP server implementations conforming to this specification MUST,

* Section 5.1

OLD:
   The Relay-Forward message contains relay agent parameters that
   identify the client-facing interface on which any reply messages
   should be forwarded.  These parameters are link-address, peer-address
   and Interface-ID.  The link-address parameter MUST be set to the
   unspecified address.  The Interface-ID Relay Agent Option MUST be
   included in the Relay-Forward message.  The LDRA MAY insert
   additional relay agent options.

NEW:
   The Relay-Forward message contains relay agent parameters that
   identify the client-facing interface on which any reply messages
   should be forwarded.  These parameters are link-address, peer-address
   and Interface-ID.  The link-address parameter MUST be set to the
   unspecified address.  The peer-address parameter MUST be set as
   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.

* Section 6.1

OLD:
   When a DHCPv6 message (defined in [RFC3315]) is received on any
   client-facing interface, the LDRA MUST intercept and process the
   message.  The LDRA MUST also prevent the original message from being
   forwarded on the network facing interface.

NEW:

   The LDRA MUST intercept and process all IP traffic received on any
   client-facing interface that has:

   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.

* Section 7

OLD:
   The LDRA intercepts any DHCPv6 message received on client-facing
   interfaces with a destination IP address of
   All_DHCP_Relay_Agents_and_Servers (FF02::1:2).  The LDRA MUST NOT
   forward the original client message to a network-facing interface, it
   MUST process the message and add the appropriate Relay-Forward
   options as described in previous sections.

NEW:
   The LDRA intercepts any DHCPv6 message received on client-facing
   interfaces with the traffic pattern specified in Section 6.1.
   The LDRA MUST NOT forward the original client message to a
   network-facing interface, it MUST process the message and add the
   appropriate Relay-Forward options as described in previous sections.

* Security Considerations

OLD:
   Although the LDRA only listens to client-originated IPv6 traffic sent
   to the All_DHCPv6_Servers_and_Relay_Agents address on UDP port 547,
   the LDRA SHOULD implement some form of rate-limiting on received
   messages to prevent excessive process utilisation.  As DHCP is
   session-oriented, messages in excess of the rate-limit may be
   silently discarded.

NEW:
   The security issues pertaining to DHCPv6 relay agents as specified in
   Section 23 of [RFC3315] are also applicable to LDRAs. Although the
   LDRA only listens to client-originated IPv6 traffic sent
   to the All_DHCPv6_Servers_and_Relay_Agents address on UDP port 547,
   the LDRA SHOULD implement some form of rate-limiting on received
   messages to prevent excessive process utilisation.  As DHCP is
   session-oriented, messages in excess of the rate-limit may be
   silently discarded.

---

From: David Hankins <[email-masked]>
Date: Mon, 24 Jan 2011 10:20:12 -0800

>   session-oriented, messages in excess of the rate-limit may be

This is false, actually, the LDRA also listens to any "network-originated"
(in the draft's terminology) packets sent to link-local addresses and the
DHCPv6 client port, and it does process these messages: it must
de-encapsulate a relay-reply into a reply (or another nested relay-reply).

Does this language intend instead to imply that rate limiting should only be
applied to multicast traffic?

-- 
David W. Hankins
SRE
Google, Inc.

---

From: David Hankins <[email-masked]>
Date: Wed, 26 Jan 2011 11:41:50 -0800

+to iesg@, -to iesg-secretary@ per Cindy.

---------- Forwarded message ----------
From: David Hankins <[email-masked]>
Date: Mon, Jan 24, 2011 at 10:20 AM
Subject: Re: [dhcwg] Protocol Action: 'Lightweight DHCPv6 Relay Agent' to
Proposed Standard (draft-ietf-dhc-dhcpv6-ldra-03.txt)
To: The IESG <[email-masked]>
Cc: IETF-Announce <[email-masked]>, dhc mailing list <[email-masked]>,
dhc chair <[email-masked]>, Internet Architecture Board <
[email-masked]>, RFC Editor <[email-masked]>

-- 
David W. Hankins
SRE
Google, Inc.

-- 
David W. Hankins
SRE
Google, Inc.

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 31 Jan 2011 18:03:58 -0500

Hi David,
   Thanks for the comments.

David Hankins wrote:
> On Mon, Jan 24, 2011 at 9:47 AM, The IESG <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     OLD:
> 
> This is false, actually, the LDRA also listens to any 
> "network-originated" (in the draft's terminology) packets sent to 
> link-local addresses and the DHCPv6 client port, and it does process 
> these messages: it must de-encapsulate a relay-reply into a reply (or 
> another nested relay-reply).

What you say is correct (the LDRA also listens to network-originated 
traffic), but the text in the Security Considerations section was 
intended to apply only to the client-initiated IPv6 traffic and does not 
talk about the network-originated traffic. In the deployment scenarios 
we were targeting, the network-facing interfaces were considered to be 
trusted and hence there was no need to perform rate-limiting on 
network-originated traffic. Do you see a need to rate-limit 
network-originated traffic as well?

Thanks
Suresh

---

From: David Hankins <[email-masked]>
Date: Mon, 31 Jan 2011 16:48:06 -0800

> Thanks for the comments.

Sorry I only noticed this in the IESG diff.

> traffic), but the text in the Security Considerations section was intended
> to apply only to the client-initiated IPv6 traffic and does not talk about
> the network-originated traffic. In the deployment scenarios we were
> targeting, the network-facing interfaces were considered to be trusted and
> hence there was no need to perform rate-limiting on network-originated
> traffic. Do you see a need to rate-limit network-originated traffic as well?
>

That is what I expected - but I think someone could easily misinterpret the
existing text.  If you have the time or energy to try and make the statement
a bit more direct...I would open with the recommendation to rate-limit
client-originated traffic and close with admitting the only
client-originated traffic the LDRA receives is the one address/port pair
mentioned.

-- 
David W. Hankins
SRE
Google, Inc.