Subject: WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt

From: Ralph Droms <[email-masked]>
Date: Tue, 11 Feb 2003 10:37:56 -0500

(resent with correct Subject:)

This message announces a WG last call on "IPv6 Prefix Options for DHCPv6" 
<draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt>.  The last call will 
conclude on Friday, 2/28.

Note that this is a parallel WG last call in the dhc, and ipv6 WGs.

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

- Ralph Droms 

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Sat, 22 Feb 2003 22:57:10 +0200 (EET)

> 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

---

From: "Vijayabhaskar A K" <[email-masked]>
Date: Sun, 23 Feb 2003 23:30:36 +0530

Pekka

See my reply inline.

~Vijay

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Pekka Savola
> Sent: Sunday, February 23, 2003 2:27 AM
> To: Ralph Droms
> Cc: [email-masked]; [email-masked]
> Subject: [dhcwg] Re: WG last call on
> draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt
>
>

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.

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

> administrative entities with differently configured

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

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

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

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

> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg
>

---

From: Pekka Savola <[email-masked]>
Date: Sun, 23 Feb 2003 20:25:45 +0200 (EET)

Some comments inline.

On Sun, 23 Feb 2003, Vijayabhaskar A K wrote:
> > 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.
> >

That doesn't answer the real question.

That is, the requesting router is in charge of all the prefixes until they 
expire.  The robust requesting router implementation will perform some 
sane refreshing of these bindings way before they expire, even 
periodically.

Thus, I fail to see any reason why these values would have to be 
communicated from the delegator.

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

I know it is not mandatory: but it seems (mostly) unnecessary to me, which 
was the real point.

> you need multiple IA_PDs.

Prefix delegation by DHCP is not meant to be 
all-purpose-zero-configuration tool for routers, I think.

This seems conflicting -- a fringe case which should not came up.

Better would be just require that the requesting router will get a 
delegation from all the ISP's for itself, and subnet accordingly.

If the following does not apply, it seems to me that there must be routers 
connected to the downstreaming interfaces -- which in turn could perform 
prefix delegation directly from the ISP, the first router acting as a 
relay.

Doesn't seem to be need for this..

> IA_PD. I think, this is the simplest method possible.

Seems wrong to me:

   An IA_PD is a construct through which a delegating router and a
   requesting router can identify, group and manage a set of related
   IPv6 prefixes. 

and:

==> the model appears to be, to me, that the requesting router makes an
association with *one* delegating router.  In that case, multiple IA_PD's
for multiple seem unnecessary.  

If this is not the case, the applicability section needs to be worked out
a bit more.

Also, then I can't help wondering what multiple prefixes are for.  Why
would anyone (except for bogus /64 for every downstream link -delegating
requests) want multiple prefixes?  (note: site-local is not applicable,
different admin domains.)

Regardless of that, I'm not sure how the requesting router would discover
more of these delegating routers -- how would they be connected?  Which 
kind of infrastructure would typically be between requesting router and 
multiple delegating routers?

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

I agree that for certain requested values, the outcome would get very 
confusing for the requesting router if the delegating router could not 
fullfill these requirements.

But the point was different: I think the whole "preference for X" model 
seems mostly unnecessary.

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

I totally agree with that (that's the sensible thing to do!), but the
first sentence was not accurate, as you don't split /64 prefixes *IF* 
you'd do it nonetheless.

---

From: "Vijayabhaskar A K" <[email-masked]>
Date: Mon, 24 Feb 2003 23:58:06 +0530

My comments inline....

~ Vijay

> Sent: Sunday, February 23, 2003 11:56 PM
> To: Vijayabhaskar A K
> Cc: 'Ralph Droms'; [email-masked]; [email-masked]
> Subject: RE: [dhcwg] Re: WG last call on

Yes, I agree that the it can refresh the bindings at any periodic
intervals it want. But, what if the delegating router is dead
and not responding at all? Hence, dhcpv6 provides you with 
two values: 
T1 -> This is the time at which the requesting router starts 
contacting the delegating router for the renewal of the lease...
T2 -> If till the expiration of T2 it didn't get the response
from the delegating router, it can contact any available
dhcpv6 server to refresh its bindings.
Ofcourse, the requesting router can generate these values itself.
With DHCPv6 server sending T1 and T2 values, the requesting
router dont need to recalculate the values again and again..
Trust the DHCPv6 server, the values provided by it makes the
requesting router to refresh its bindings well before the expiry..

> Doesn't seem to be need for this..

Need not be. Simple case is Home networks, they dont afford to have
individual routers for every ISPs. They may need multiple ISPs 
for high availablity or some other reason. In this case, there will
be only one border router with mutiple appliances/nodes in the 
downstreaming interfaces, which may span in one or more links.
In this case, it needs to unique IA_PD for every ISP.

> different admin domains.)

May be for high availabilty, it may get prefixes from multiple
ISPs.

> multiple delegating routers?

I beleive there will be unique dialup connection with each ISPs.

---

From: Ralph Droms <[email-masked]>
Date: Mon, 24 Feb 2003 14:34:29 -0500

Pekka,

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

My comments are in line...

- Ralph

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

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

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

>have hoped for a bit clearer picture of elements associated with DHCP

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.

>familiar with DHCPv6, but some kind of "hierarchy" or "big picture" was

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

>terminology, as it keeps cropping up all the time.

OK.

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

>of "responds with prefixes delegated to the requesing router" ?

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

>    delegation would be used.

OK.

>    unique among the IA_PD IDs on the requesting router.

Yes.

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

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

OK

>current one as a subsection, but some other clarification would also be

OK.

>T2, the parameters MUST be used" ?

OK.

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

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

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

Needs a pointer to the DHCPv6 spec?

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

Needs a pointer to the DHCPv6 spec?

>==> s/duration is/durations are/

OK.

>extra bits wouldn't be needed at all.

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

>using a similar sentence or whatever)
>

OK.

>prefixlengths etc.etc.).  [more of this was above]

Paranoid delegating routers can simply ignore the guidance...

---

From: Pekka Savola <[email-masked]>
Date: Tue, 25 Feb 2003 08:29:48 +0200 (EET)

On Mon, 24 Feb 2003, Vijayabhaskar A K wrote:
> > That is, the requesting router is in charge of all the prefixes until
> > they expire.  The robust requesting router implementation will perform
> > some sane refreshing of these bindings way before they expire, even
> > periodically.
> > 
> and not responding at all? 

Then it will try again a bit later and succeed.

> Hence, dhcpv6 provides you with 
> two values: 

Do you mean that similar T1 & T2 values are being used by DHCP base spec?  
In that case I guess it's ok, but otherwise, I still fail to see the 
usability.

> requesting router to refresh its bindings well before the expiry..

Well, typically the conventional wisdom is *not* to trust any external 
parties to any extent greater than necessary :-)

> In this case, it needs to unique IA_PD for every ISP.

Seems a bit far-fetched, IMO, but ok..

> > Regardless of that, I'm not sure how the requesting router would
> > discover more of these delegating routers -- how would they be
> > connected?  Which kind of infrastructure would typically be between
> > requesting router and multiple delegating routers?
> 

.. as above, I've yet to see dial-up routers deployed which would have two 
dial-out adapters and phone jacks, but ok..

---

From: Pekka Savola <[email-masked]>
Date: Tue, 25 Feb 2003 08:49:00 +0200 (EET)

Similar discussion has already been had, so I'll try to keep it at the 
minimum.

> by setting T1 and T2 to 0 (see section 8 of the draft).

Yes, I noticed they can be zero -- all I'm questioning is the usability of 
this flexibility.  I fail to see why such flexibility is useful.  The 
requesting router can be as flexible as it wants -- and refresh bindings 
when it deems it necessary even without guidance.

>  router might send one IA_PD for each ISP used by a customer site.

I don't see it overly restrictive myself: as an operator and end-user, if 
someone connects to two ISP's, it's (almost, at least) always done either 
from two separate routers (no use doing it from one, really), or in a 
serial fashion (terminate one, establish the other -- like dialup).
 
> to each of its downstream interfaces.

I understood well that the particular behaviour is only optional, but the 
problem seems to be that the "main behaviour" is described quickly 
(indeed, it's rather simple) and then the spec goes on at great length 
describing the fringe cases.  This makes an unwary reader think the fringe 
cases are actually more than just fringe cases.

At least, there should be some clearer separation between the two and 
possibly some guidance when (for example) not to use special mechanisms.

> the requesting router's preferences...

Certainly.  I see this as a potential problem from two directions:

1)  delegating router handling untrusted input values, creating 
delegations based on them, and

2) the requesting router requesting something that architectually differs 
*a lot* from what's given (example: /64's directly for its interfaces, and 
one /48 delegated).  Then what?  Can the requesting router handle this 
kind of situation?  The problem is that entering preferences *in-band* 
(instead of out-of-band, as usual) seems problematic, as it creates 
difficult situations at both ends in the cases the preferences are not met 
(and policy decisions even if met).

At the very least, one should clarify something along the lines of "In any 
case, the requesting router MUST NOT depend on any of its preferences to 
be honored" if this feature is really necessary.

> The format of the option code is (should be?) specified in the

Ok -- it's just that AFAICS, I don't see that a connection has been made 
between the two (even if they use the same name).
 
> Needs a pointer to the DHCPv6 spec?

At the minimum.

> Needs a pointer to the DHCPv6 spec?

Yes please, and spell out the abbreviation in the text (no need to put it 
up in terminology IMO).

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

Ah, got me there :-).  The problem with the language seems to be that even 
though it says "when ... subnets", there are no other "whens" so this 
paragraph is taken to imply all of it (especially since the main form of 
prefix delegation always includes subnetting, as noted earlier in the 
draft).

> Paranoid delegating routers can simply ignore the guidance...

Yep, put that in there :-)

---

From: "Vijayabhaskar A K" <[email-masked]>
Date: Wed, 26 Feb 2003 00:34:49 +0530

> Sent: Tuesday, February 25, 2003 12:00 PM
> To: Vijayabhaskar A K

The time "bit later" is well defined by DHCPv6 base architecture.

> In that case I guess it's ok, but otherwise, I still fail to see the 

Yes, T1 and T2 values are being used in DHCPv6 base spec.

> parties to any extent greater than necessary :-)

If you are able to trust the prefixes given by DHCPv6, then there will be
no harm in trusting the time values provided by it :-)

---

From: Pekka Savola <[email-masked]>
Date: Tue, 25 Feb 2003 21:25:55 +0200 (EET)

> no harm in trusting the time values provided by it :-)

It's not about that kind of trust -- rather "I trust that the times 
provided to me by the operator are the best possible choices, and they 
have in fact provided them" -- I'd imagine you trust your own DHCPv6 
implementation and configuration more than your ISP's.

---

From: "Vijayabhaskar A K" <[email-masked]>
Date: Wed, 26 Feb 2003 01:22:07 +0530

> Sent: Tuesday, February 25, 2003 12:19 PM
> To: Ralph Droms
> Subject: Re: [dhcwg] Re: WG last call on
> describes new DHCPv6

On reading your previous mail, i thought you have agreed with T1 and T2 :-)
Probably, the routers which are "wise" enough to rely up of prefixes
provided by the DHCPv6 server and "dumb" enough to trust the time
values provided by it, may need this ;-) Perhaps, these T1 and T2 values
exist from
DHCPv4 architecture itself and worked successfully.
If the requesting routers doesn't want to trust the time values,
they can just ignore the T1 and T2 values and refresh the leases
whenever it wishes.

> serial fashion (terminate one, establish the other -- like dialup).

Simultaneous connection is also needed in some cases, as i told
earlier, like, high availablity

> one /48 delegated).

The same problem will occur, when the requesting router is expecting
the /48 and the server ignoring its preference and just gives
it /64.
The solution would be,
1) when a site registers with ISP, preconfigure the topology of the
site in the dhcpv6 server. Thus, it can provide the requesting
router with necessary prefixes.
2) If the site topology is not known, configure dhcpv6 server
with some dynamic pool which always provide a single /64 prefix
for the IA_PD. Let the requesting router send as many as IA_PD
it wants. But, here the concept of subnetting dies.

If there is no preconfiguration, then the server wont be
able to provide the preferred prefix of the requesting routers.
This problem remains unsolved.

Basically, the site which is connecting to ISP is authenticated,
moreover, they pay for whatever service they use, i dont see
that any harm in taking the preference from the requesting
router and assign the prefix accordingly.

> Then what?  Can the requesting router
> handle this

I pay for my using the services provided by ISPs, why shouldn't
my preferences be honoured?

---

From: Pekka Savola <[email-masked]>
Date: Tue, 25 Feb 2003 23:22:20 +0200 (EET)

> On reading your previous mail, i thought you have agreed with T1 and T2 :-)

Well, if it's DHCPv6 functionality, it's ok to keep some of those intact 
even if misguided.. :-)

> DHCPv4 architecture itself and worked successfully.

Well, the routers MUST have this code *anyway*, as they cannot be sure 
T1/T2 will always be provided, so I really see little use..

> > I don't see it overly restrictive myself: as an operator and end-user,
> > if someone connects to two ISP's, it's (almost, at least) always done
> > either from two separate routers (no use doing it from one, really),
> > or in a serial fashion (terminate one, establish the other -- like
> > dialup).
> 

High availability to two ISP's from one router is a joke.

> the /48 and the server ignoring its preference and just gives

Sure.  (Or the same for different changes in prefix lengths.)

> router with necessary prefixes.

I think it is natural to be able to expect that the ISP configures this
kind of stuff (one /64, multiple /64, /48 -- that's all they need!)
out-of-band.  As currently.  I don't think there's any reason to expect
otherwise.

> it wants. But, here the concept of subnetting dies.

Very discourageable, IMO.
 
> router and assign the prefix accordingly.

You fail to understand the relationship between the ISP and the user.

Whether they use /64, /48 or whatever is, and will typically be, 
pre-agreed when people sign up for the service.  Communicated out-of-band.  
I don't think that typically the user is able to affect that decision (at 
prefix delegation time) at all.

Of course, ISP's could change their models, but don't count on it.. 

> my preferences be honoured?

ISP's will love you for spending 50$/mo for the premium service instead of
30$/mo, so -- maybe they'll let you say the preference.  For the rest, it
won't matter and it's configured out-of-band.

Most agreements with ISP's are very draconian.  The problems like these 
are not solved with specifications.

---

From: Ole Troan <[email-masked]>
Date: Wed, 26 Feb 2003 01:56:56 +0000

Pekka,

> to it's downstream interfaces!

let me pick this one up from the start.
the reasons for allowing multiple IA_PDs are:

 - consistency with address assignment as you can use multiple IA_NAs
 - future-proofing. in the ISP/user scenario I do see little need for
   multiple IA_PDs. if PD is used within an administrative domain
   assigning prefixes to downstream interfaces may make more sense

it does add some complexity, and I think we've made it pretty clear in
the draft that the typical usage will be to use one IA_PD. we just
didn't want to close the door on possible future uses of the protocol.

/ot

---

From: Pekka Savola <[email-masked]>
Date: Wed, 26 Feb 2003 08:33:55 +0200 (EET)

>    assigning prefixes to downstream interfaces may make more sense

My take on this is is that "we don't need that yet, so why add it yet"; 
leaving the "base prefix delegation spec" extendable (e.g. define multiple 
IA_PD's in a later document) would be just fine.
 
> didn't want to close the door on possible future uses of the protocol.

IMO, it wasn't as clear as that.

I can live with this, but I can't help wondering why the base spec has to
cover even all the theoretical cases.  I'd much rather see a very simple 
basic version of prefix delegation which can be used to get started.  
There's no way we could anticipate what will be needed in 3-5 years and we 
could further define the extensions when they're needed.

---

From: Ole Troan <[email-masked]>
Date: Thu, 27 Feb 2003 00:26:16 +0000

Pekka,

> could further define the extensions when they're needed.

well, I have to disagree with you there. keeping PD consistent with
other DHCP options makes for an easier understanding of how it works
and for a simpler implementation. the fundamental idea behind using
DHCP for PD is to re-use the existing DHCP infrastructure including
option semantics. Distilled into one line: "Prefix Delegation with
DHCP is done in exactly the same way as address assignment with DHCP is".

/ot

---

From: Pekka Savola <[email-masked]>
Date: Thu, 27 Feb 2003 09:35:52 +0200 (EET)

> DHCP is done in exactly the same way as address assignment with DHCP is".

I can live with that.

I hear many (two sets of groups) are implementing DHCPv6 either for:
 - configuration parameters
 - prefix delegation (for the lack of alternatives)

If you don't want address assignment in DHCP, doing it the same way in PD
may seem like a burden.

---

From: Tim Chown <[email-masked]>
Date: Thu, 27 Feb 2003 09:47:54 +0000

>  - prefix delegation (for the lack of alternatives)

I would just add a "flag wave" for 6NET's Deliverable D3.2.3 which reports
on DHCPv6 implementations which may be of interest to people here [apologies
if a pointer has already been posted - just dipping in :]

Tim