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

Pekka,

Thanks for your review and feedback on 
draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02

My comments are in line...

- Ralph

At 10:57 PM 2/22/2003 +0200, Pekka Savola wrote:
>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?

The spec allows for flexibility in deployment scenarios by
allowing the ISP (through the delegating router) to control
the behavior of the requesting router, or by leaving the
behavior under the control of the requesting router
by setting T1 and T2 to 0 (see section 8 of the draft).

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

There is no requirement that the delegating router supply more than
one IA_PD to the requesting router, and limiting the delegation to
only one IA_PD seems overly restrictive.  For example, a delegating
router might send one IA_PD for each ISP used by a customer site.

It is not the intention of the draft that the requesting router
receive one IA_PD for each of its downstream interfaces.  If that
is your understanding of the draft, then we need to clarify
the text.  In section 11.1, the draft specifies that the
requesting router assigns subnets from the delegated prefixes
to each of its downstream interfaces.

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

The cost of allowing the requesting router to express its preferences
isn't all that great - a simple delegating router can simply ignore
the requesting router's preferences...

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

Well, this option (and the spec) really isn't useful without DHCP,
so I don't think it's unreasonable to expect a fair amount of
familiarity with DHCPv6 on the part of the reader.  However, we can
edit the draft to include some additional definitions and concepts
from DHCPv6 for clarity.

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

We can take a look at those sections and try to edit them for
clarity, and we'll make some changes based on the more detailed
comments you made below...

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

OK.

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

I suppose we could break section 4 into a couple of subsections, to clarify
what text is describing the example scenario and what text is describing
the use of the prefix delegation option more generally.

>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" ?

"responds with prefixes[...]" is the correct clarification; we can
make that change.

>    Figure 1 illustrates a network architecture in which prefix
>    delegation would be used.
>
>==> s/would/could/ ?

OK.

>    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/ ?

Yes.

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

The format of the option code is (should be?) specified in the
DHCPv6 spec.

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

OK.

>==> 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"

OK

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

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" ?

OK.

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

We can add an entry in the terminology section with a pointer
to the DHCPv6 spec.

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

Needs a pointer to the DHCPv6 spec?

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

Needs a pointer to the DHCPv6 spec?

>==> 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/

OK.

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

But that wouldn't be "subnetting", I don't think - just reassignment?

>    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

OK.

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

Paranoid delegating routers can simply ignore the guidance...

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