Subject: [dhcwg] comments on draft-miles-dhc-dhcpv6-ldra-02

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Tue, 17 Mar 2009 15:17:10 -0700

I've read this draft.  I don't have a strong opinion on the proposal
itself (I'm certainly not a fan of this type of "layer-violating"
devices, but this is probably something we'd accept in reality), but I
have some technical questions that may help improve the proposal if
clarified.

(I've not followed discussions, if any, on previous versions of this
document.  If some of the points have already discussed and the
current version is a result of that, please point it out.  I'm
generally happy with any previous consensus).

I have a couple of higher-level questions:

1. I was not sure whether this specification requires a modification
   to servers.  In general, the draft seems to say that LDRAs can be
   transparently deployed, that is, without modification to servers
   (or to clients) although there may be additional benefit if the
   server is LDRA-aware.  However, Section 7 introduces a MUST for
   server implementations (which doesn't seem to be derived from
   RFC3315).  If this specification intends to introduce a mandatory
   modification to server implementations, this should be more clearly
   stated; otherwise, I guess the current text could be confusing and
   should be clarified.

2. This specification assumes an LDRA device only handle link-local
   DHCPv6 messages.  But RFC3315 allows scenarios that break this
   assumption:
   - the client and the server can negotiate on using unicast
     exchanges.  So, for example, a RENEW from a client can be
     directly sent to the server using global source and destination
     addresses.
   - A (normal) relay agent may also send a relay-forward message to
     an off-link server.
   I was not sure whether the LDRA proposal precludes such scenarios
   or just overlooks them.  In either case it should be clarified, and
   if the intent is to preclude off-link exchanges I believe it should
   be justified (because then LDRAs couldn't be introduced
   transparently)

Some other, relatively minor comments along with the draft text
follows:

- p.6, Section 4.3.1

   As an LDRA does not implement ICMPv6, fragmentation of Relay-Messages
   is not supported.

  I'm afraid there's a logic gap here.  First, I don't understand why
  fragmentation is not supported "as an LDRA does not implement
  ICMPv6".  I believe a device could fragment a large packet so that
  each fragment fits the outgoing link MTU, whether or not it supports
  ICMPv6.  Perhaps this means an LDRA cannot receive an ICMPv6 too big
  message to know the path MTU to the destination, but it's not clear
  from this text; even if that's the intent, that cannot be a reason
  why fragmentation isn't possible as I stated first.
  (I'm not opposing to the restriction per se, BTW.  I simply don't
  understand it).

- p. 6 Section 4.3.2

   Servers MAY use the Interface-ID for parameter assignment policies.
   The format of the Interface-ID is outside the scope of this
   contribution.  The Interface-ID SHOULD be considered an opaque value,
   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
   for a given interface, and this value SHOULD be retained across
   restarts.  This is because, if the Interface-ID changes, a server
   will not be able to use it reliably in parameter assignment policies.

 This paragraph uses capital keywords based on RFC3315 without noting
 that, and is thus confusing (this sounds like a new requirement of
 this proposal), especially because it also contains a real new
 requirement (i.e, the last two SHOULDs).

- p.8, Section 5.2

   [...] The LDRA MUST
   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.

  I was not sure whether the "any message that does not meet this
  criteria" includes, e.g., unicast exchanges between the client and
  the server with global addresses (see also higher-level question
  #2).  If it does, I also failed to understand why we separate these
  two cases.

- p.12, Section 7

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

  Aside from the point I asked in higher-level question #1, I was also
  not sure what this statement exactly means.  What does "MUST ignore"
  specifically mean?  It sounds like prohibiting something, but what
  is it?

   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 also not clear to me...what does "as though the message..."
  specifically mean?  Does this mean the server should follow the
  RFC3315 specification (while the first bullet doesn't)?  BTW, the
  double negation at the beginning of this sentence was hard to
  parse...perhaps this could be rephrased as something like this:

   o  If all Relay-Forward link-addresses are non-zero, the DHCPv6

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.

---

From: "MILES DAVID" <[email-masked]>
Date: Thu, 19 Mar 2009 14:23:42 +0800

Thanks Jinmei-san,

>   stated; otherwise, I guess the current text could be confusing and

Agree that clarification will help here. The requirement may in fact be redundant as it is stating the obvious - if you are using the link-address field to determine IP pool (for IA_NA or similar) then a value of zero should be an invalid link. If any such clarification is to be made it should be in updates to RFC3315 - not the LDRA draft. So we don't forget about this, I propose changing this to informative text? 

>   be justified (because then LDRAs couldn't be introduced

The intention was to exclude unicast from the intercepted messages. I'll make a not recommending that server unicast option should not be used where LDRA exist. This should prevent a client sending unicast Renew, Request, Release and Decline messages to the server (and thus bypassing the LDRA). I note 18.1 of RFC3315 states that : The server should enable the use of unicast only when relay agent options will not be used - so may draw reference to this text.

>   is not supported

You're right - only half an explanation (and probably the less important half!). Indeed it was the pointing out that path MTU issues would not be discovered - the root of this restriction was to avoid fragmentation and reassembly - it's probably better to add some DISCUSSION below this and note it's entirely possible but not part of the specification in an attempt to simplify the implementation.

> requirement (i.e, the last two SHOULDs).

Will fix this up

>  #2).  If it does, I also failed to understand why we separate these

The intention was to only intercept multicast messages sent from the client per the above comment. Perhaps another DISCUSSION point (re, why not intercept unicast). The discussions among the authors was that server-unicast operation was not desirable or required in networks where LDRAs were present (again, similar to the text in RFC 3315 that suggests unicast shouldn't be used in cases where relay options are used).

I think the last two comments should be covered off with a correction to the Server Considerations section above.

Please let us know what you think of the proposed changes and we will ensure they are incorporated in the next update.

Cheers,

-d

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 19 Mar 2009 11:54:15 -0700

On Thu, Mar 19, 2009 at 02:23:42PM +0800, MILES DAVID wrote:
> Agree that clarification will help here. The requirement may in fact be
> redundant as it is stating the obvious - if you are using the link-address
> field to determine IP pool (for IA_NA or similar) then a value of zero
> should be an invalid link. If any such clarification is to be made it
> should be in updates to RFC3315 - not the LDRA draft. So we don't forget
> about this, I propose changing this to informative text? 

I remember we discussed this during the DHCPv6 bakeoffs.  As we met,
we discussed the existence of devices that "do not have a link address
to supply", and implementors were asking what they should put in that
field instead - their link-local address?

It was generally decided that the link-local address would be largely
useless and only serve to complicate server implementations, so such
relays should instead insert a zero value.  My interpretation of our
discussion is that most server implementors seemed already to do
this. [1]

This is along the same vein as supplying a zeroed IPv6-address IAADDR
option, for the purpose of supplying "requested values" for the
lifetime fields.

I think this MUST is a clarification, and it would be my preference
that it appear in an RFC /sometime./  I think it is most topical to
an LDRA as one such type of agent that does not have a valid value to
give, but I understand if you think it is out of scope (changes the
intent or meaning of your draft too greatly).

> The intention was to exclude unicast from the intercepted messages. I'll
> make a not recommending that server unicast option should not be used where
> LDRA exist. This should prevent a client sending unicast Renew, Request,
> Release and Decline messages to the server (and thus bypassing the LDRA). I
> note 18.1 of RFC3315 states that : The server should enable the use of
> unicast only when relay agent options will not be used - so may draw
> reference to this text.

The 3315 text you quote is the best and simplest guidance on this
subject.  There are scenarios where relay agent options are used where
the unicast option may still (safely) be used, but it is too difficult
to describe those scenarios completely without losing the reader, and
it is an optimization anyway.  An informative statement not to use
unicast when deploying LDRA works simplest.

---

[1]  From ISC DHCP server/dhcpv6.c, "shared_network_from_packet6()":

        /*
         * First, find the link address where the packet from the client
         * first appeared (if this packet was relayed).
         */
        first_link_addr = NULL;
        chk_packet = packet->dhcpv6_container_packet;
        while (chk_packet != NULL) {
                link_addr = &chk_packet->dhcpv6_link_address;
                if (!IN6_IS_ADDR_UNSPECIFIED(link_addr) &&
                    !IN6_IS_ADDR_LINKLOCAL(link_addr)) {
                        first_link_addr = link_addr;
                        break;
                }
                chk_packet = chk_packet->dhcpv6_container_packet;
        }

  I actually had to fix this at the last bakeoff.  Shane wrote it
  this way, I convinced him to change it on review, and I was wrong,
  so I changed it back.  :(  We both might have been saved the trouble
  with some normative hints!

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins