[dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt

On Tue, 11 Feb 2003, Ralph Droms wrote:
> draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt describes new DHCPv6 
> options and a mechanism through which a "delegating router" (e.g., an ISP 
> aggregation device) can assign and delegate one or more prefixes to a 
> "requesting router" (e.g., CPE).  This draft is available as 
> http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt

A few comments.

Bigger issues -- I'm sorry for bringing them up so late (relatively), but 
I haven't really thought/read about the big picture, before.

1) I fail to see why to add T1 and T2 in IA_PD.  They seem to be 
mostly redundant -- the requesting router should just take the minimum of 
lifetimes of the prefixes, calculate it in the same fashion, that's it.  
Of course, there is an assumption (which doesn't seem to be properly 
addressed!) that the requesting router is free to refresh the delegation 
when it feels right, even every hour, day, month etc. without regard to 
the lifetimes -- indeed, I think *NO* implementation would just wait until 
the last minute to refresh them.

Is there something I'm missing?

2) Multiple IA_PD looks unnecessarily complex.  Are there any valid
reasons why it wouldn't be just enough to have only one IA_PD per
requesting router?  (The option to and subsequent complexity of)
generating one for each interface seems like a completely unnecessary
feature to me -- it's the router which should be doing prefix delegation
to it's downstream interfaces!

The only feature I can quickly think of which could profit from this is 
kind of "shared routers" where the connected interfaces are separate 
administrative entities with differently configured properties at the ISP.  
This seems questionable to me, a case for manual configuration or 
"advanced prefix delegation" to me.

So, I think the possibility to do prefix delegation in more complex ways
than really necessary should be seriously considered.  Keep it Simple,
Stupid would be a good rule.

3) One item that may also need some consideration is the option to let the
requesting router give its preference to some values (prefix length,
lifetimes, IAprefix-options contents (maybe?), the prefixes).  I'm not
sure of the usefulness of these, really.  In the real world, I think ISP's
set them, either to some values communicated off-band, or otherwise.  The
complexity required (policy, policy,...) when the delegating router must
decide whether it can agree to the requested values seems like a big hit.  
I'm not really sure whether it's worth it, even though it may offer some
flexibility for some corner cases.  The only commonly used one I could
think of would be whether the customer wants _single_ /64 (for the only
one subnet!) or whole /48 -- seems like a heavy baggage for that.

4) As one who hasn't really read DHCPv6 specification, the spec was
confusing as it introduced options and code values, and reused ones from
DHCPv6 quite liberally (more of this below in detailed comments).  I would
have hoped for a bit clearer picture of elements associated with DHCP
prefix delegation.

5) as above, there doesn't seem to be clear structure to the document when
specifying the DHCPv6 PD-specific options (and different DHCPv6 options
altogether) [sections 8-9, mostly]: this makes it rather difficult to
follow the which options include which options, what options may be
embedded in which, etc.  This may partially be due to the fact I'm not so
familiar with DHCPv6, but some kind of "hierarchy" or "big picture" was
missing.

==> in consequence I think there are at least two items, 1-3 which need 
some thought (if they haven't already been brought up and discussed), and 
at least 4-5 which would clarify the specification which are IMO very 
important in conveying the right message.

As for more detailed comments...:

   Identity Association for Prefix Delegation (IA_PD) A collection of
                       prefixes assigned to the requesting router.  Each
                       IA_PD has an associated IAID.

==> first use of "IAID", so spell it out, or even put is as an item in the 
terminology, as it keeps cropping up all the time.

4. Model and Applicability

==> the middle/latter part of this paragraph could be reorganized/reworded 
a bit to say that the model described there is indeed just an example; 
perhaps break off starting at page 5 as a separate sub-section?

The delegating router chooses prefix(es)
   for delegation, and returns the prefix(es) to the requesting router.

==> the use of "returns the prefix(es)" seems slightly ambiguous -- could 
one read that and get a picture that the delegator gives back the same 
prefixes requested?  Did I misunderstand, or did you mean along the lines 
of "responds with prefixes delegated to the requesing router" ?

   Figure 1 illustrates a network architecture in which prefix
   delegation would be used.

==> s/would/could/ ?

   The IAID uniquely identifies the IA_PD and must be chosen to be
   unique among the IA_PD IDs on the requesting router. 

==> s/IDs/IAIDs/ ?

   option-code:      OPTION_IA_PD (TBD)

   option-length:    12 + length of IA_PD-options field.

==> is it necessary to say how the option-code is stored/transported 
(signed/unsigned) ?  I guess this is clear enough?

==> length of IA_PD-options field in which units?  Octets, seems likely?

==> same issues in sect 9

   T1                The time at which the requesting router contacts
   T2                The time at which the requesting router contacts

==> s/contacts/should contact/ or even "is instructed to contact"

   IA_PD-options     Options associated with this IA_PD.

   The IA_PD-options field encapsulates those options that are specific
   to this IA_PD.  For example, all of the IA_PD Prefix Options carrying
   the prefixes associated with this IA_PD are in the IA_PD-options
   field.

==> one should refer to the next section and explain that currently, only 
IA_PD Prefix option is defined? (I'd structure section 9 maybe 
differently: like "IA_PD options" as the main section title, and the 
current one as a subsection, but some other clarification would also be 
ok).

        In a message sent
   by a delegating router to a requesting router, the requesting router
   MUST use the values in the T1 and T2 fields for the T1 and T2
   parameters.

==> the first part of the sentence is awkward, did you mean something like 
"In case the message sent by the delegating router included non-zero T1 or 
T2, the parameters MUST be used" ?

   The status of any operations involving this IA_PD Prefix option is  
   indicated in a Status Code option in the IAprefix-options field.

==> Status Code options haven't been explained.

  The requesting router MUST ignore any Advertise message that includes
   a Status Code option containing the value NoPrefixAvail,

==> where is the defintion of NoPrefixAvail or other codes?

   message for the user, a Server Identifier option with the delegating
   router's DUID and a Client Identifier option with the requesting
   router's DUID.

==> DUID used for the first time (inherited from DHCPv6 spec I think), 
spell it out?

==> all in all, I think one should have a better picture which kinds of 
options from DHCPv6 spec which aren't mentioned in the draft are ok (or if 
some aren't applicable) -- or at least refer to those in the previous 
sections.

   Each prefix has valid and preferred lifetimes whose duration is

==> s/duration is/durations are/

   When a requesting router subnets a delegated prefix, it must assign
   additional bits to the prefix to generate unique, longer prefixes.
   For example, if the requesting router in Figure 1 were delegated
   3FFE:FFFF:0::/48, it might generate 3FFE:FFFF:0:1::/64 and
   3FFE:FFFF:0:2::/64 for assignment to the two links in the subscriber
   network.

==> I'm not sure if the first sentence is entirely accurate.  One could 
use prefix delegation to get multiple /64's directly from your ISP, then 
extra bits wouldn't be needed at all.

   When a delegating router receives a Request message from a requesting
   router that contains an IA_PD option, and the delegating router is
   authorised to delegate prefix(es) to the requesting router, the
   delegating router selects the prefix(es) to be delegated to the
   requesting router.  The mechanism through which the delegating router
   selects prefix(es) for delegation is not specified in this document.
   Section 10.2 gives examples of ways in which a delegating router
   might select the prefix(es) to be delegated to a requesting router.

   A delegating router examines the prefix(es) identified in IA_PD
   Prefix options (in an IA_PD option) in Renew and Rebind messages and
   responds according to the current status of the prefix(es). [...]

==> These paragraph deal with a different message types and situations, 
etc., so separating them more clearly in the text would be useful (start 
using a similar sentence or whatever).

==> same goes in the next paragraph

14. Security Considerations

==> personally I'm rather worried about the requestor being able to give 
"guidance" to the delegator what on what it wants.  Unreliable input could 
lead to bad results in an implementation which hasn't been done carefully 
(requesting link/site-local prefixes which don't exist, effect of bogus 
prefixlengths etc.etc.).  [more of this was above]

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg