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

["Vijayabhaskar A K" <[e-mail]>]

Pekka

See my reply inline.

~Vijay

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On Behalf Of
> Pekka Savola
> Sent: Sunday, February 23, 2003 2:27 AM
> To: Ralph Droms
> Cc: [e-mail]; [e-mail]
> Subject: [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?

Normally, T1 will be assigned with a value which is 0.5 times the
shortest preferred lifetime of the prefixes in the IA_PD. This
means you have enough time till the expiration of lifetimes of the
prefixes.


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

Seperate IA_PDs for every downstream interface is not mandatory.
Look at the following text:

   One IA_PD can be associated
   with the requesting router, with a set of interfaces or with exactly
   one interface.  A requesting router must create at least one distinct
   IA_PD.  It may associate a distinct IA_PD with each of its downstream
   network interfaces and use that IA_PD to obtain a prefix for that
   interface from the delegating router.

Its requesting routers' wish to have single or multiple IA_PDs.

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

Exactly. That's the case.
When the downstreaming interfaces are served my multiple ISPs,
you need multiple IA_PDs.


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

Generate IA_PDs such that every ISP is associtated with a single
IA_PD. I think, this is the simplest method possible.

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

Yes. I too agree with you. If there is no pre-configured information
for the requesting router in the delegating router, it wont
be able to to know whether the requesting routers needs /48 or
/64 bit prefix.

Probably, the solution would be, in the request message, the requesting
routers can specify prefix length it prefers. But, the server MUST
process that and delegate prefixes accordingly, else it should
send back NoPrefixAvail.

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

Instead of getting multiple /64 prefixes, if the requesting router belonged
to
a site with huge number of links, then it can obtain /48 prefix and
distribute
it among the links.

>
>    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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/dhcwg
>

_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg