Subject: [dhcwg] Call for comments - LDRA

From: "MILES DAVID" <[email-masked]>
Date: Tue, 29 Sep 2009 14:15:27 +0800

Since updating to a WG document, there have been no further comments
received on the Lightweight DHCPv6 Relay Agent.
(draft-ietf-dhc-dhcpv6-ldra-00)

Chairs,

Is now a good time to progress this though for WGLC?

Cheers,

-David

---

From: Ted Lemon <[email-masked]>
Date: Tue, 29 Sep 2009 16:35:55 -0700

> Is now a good time to progress this though for WGLC?

In the process of answering this question, I decided to first reread  
the draft (go figure).   I have a few comments.   I figure I'd better  
get them to you now rather than waiting, or else I'll forget.   I  
think this is a really good document, and although I think some of my  
comments ought to get fixed prior to last call, I don't see any major  
impediments to going forward with this.

Anyway, on to the comments:

First, this draft is informational.   That's not going to work,  
because it updates section 11 of RFC3315 (more on this later).   I  
don't remember why this is informational - can you explain?

> An LDRA MUST implement a trusted/
>    untrusted definition for all client-facing interfaces that SHOULD  
> be
>    configurable per interface.

The language is awkward here and may be read wrong by someone who  
isn't a native english speaker.   I didn't understand it the first  
time I read it.   I would word it like this:

An LDRA MUST implement a configuration setting for all client-facing  
interfaces, marking them either as trusted or as untrusted.   This  
setting SHOULD be configurable per interface.

> When a valid Relay-Reply is received on any network-facing access
>    node interface, it MUST be intercepted by the LDRA.

I think you should make clear what "intercepted" means.   I know it's  
obvious, but I've seen clearer text misinterpreted.   I would say this:

When a valid Relay-Reply is received on any network-facing access node  
interface, the LDRA MUST NOT forward the message.   Instead, the LDRA  
MUST intercept the message for processing.

Also, I think you should define "network-facing" and "client-facing"  
in the glossary.   I missed your definition of them in the first  
paragraph of section 5 when I was reading the document the first time,  
and went to the glossary looking for the definition, which wasn't there.

The rest of this paragraph is kind of difficult as well:

> 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).

First of all, if the LDRA is configured as a node, it's not an LDRA.    
So I think the last sentence should just be deleted.   Secondly, the  
first sentence here would do better at the beginning of the paragraph,  
reworded to simply define what packets qualify for interception.

You go on to say this:

>    The LDRA MUST intercept and process all DHCP Relay-Reply messages  
> and
>    MUST silently discard all other DHCP message types.

Isn't this covered in the previous paragraph?   If not, what's missing  
there?   I actually like this paragraph--it's very clear--but it  
pretty much restates what's said in the previous paragraph.  Maybe you  
should lead with it.

> The LDRA copies the peer-address into the destination IP address
>    field, and MAY use the destination link-layer address (MAC address)
>    or Interface-ID to determine which interface to send the message to
>    the client.

Should be "which interface to use to send the message to the  
client."   Also, what would it do instead?   I would have expected you  
to advise using the interface id here, or else (ugh) send it to all  
client-facing interfaces.

> 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.

I don't know what "Although permitted in [RFC3315] ..." means.   I  
would write this section as follows:

---
7. Server Considerations

This document updates the behavior specified in section 11 of DHCP for  
IPv6 [RFC3315].   RFC3315 states, in part:

          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.
---

It's very tempting to enumerate all the possible cases here, but I  
think that in so doing, you make it harder for the reader to figure  
out exactly how to integrate this with section 11 of RFC3315,  
particularly since RFC3315 doesn't actually specify which link-address  
field to use if there's more than one.

I have one other comment about this.   It took me a while to grasp  
what you were doing with the link-address field.   I think that  
section 7 should be section 4, and that it should just explain what  
you do with the link-address field there.   Then a lot of things that  
came at me kind of haphazardly as I read through the rest of the  
document would already have been clear in my mind.

---

From: "MILES DAVID" <[email-masked]>
Date: Thu, 1 Oct 2009 10:58:01 +0800

Hi Ted,

Inline;

>don't remember why this is informational - can you explain?

I believe initially it was thought that RFC3315 updates could be avoided
and there were some comments on-list to make it informational.
Putting this on a standards-track does not cause any issues for me --
does it for anyone else

For your editorial comments, thank you - ill update the draft with the
text provided.

>reworded to simply define what packets qualify for interception.

Tried to make it clearer:

The LDRA MUST intercept and process all IP traffic received on the
network-facing interface that has:
	 a link-local scoped source address;
  	 a link-local scoped destination address;
	 protocol type UDP;
  	 destination port 547, and;
	 is a valid DHCPv6 message (per RFC 3315)

An LDRA MUST inspect the DHCP message type and MUST silently discard any
DHCP message that is not type Relay-Reply.

The LDRA SHOULD ignore any message that does not meet this criteria and
subject it to normal packet forwarding.

>should lead with it.

I think the above will cater to the issue.

>client-facing interfaces.

Good point, using interface-id is already there so to rephrase:
 
The LDRA copies the peer-address into to the destination IP address
field and SHOULD forward the packet to the correct client-facing
interface using the destination link-layer (MAC) address or the
Interface-Id in the Relay-Reply.

Do we go for a MUST?

>nested within the Relay-forward message.

Perfect.

>document would already have been clear in my mind.

I agree, describing what we are doing with link-address up front in
server considerations will help a lot. Will rename it to: Use of
Link-Address?

Thanks again Ted,

d