Subject: simpler prefix delegation

From: Pekka Savola <[email-masked]>
Date: Thu, 18 Mar 2004 10:50:21 +0200 (EET)

Hi,

This started from me looking at draft-bykim-ipv6-hpd-01.txt, what it
was before that, DHCPv6 + PD, a few proposals at v6ops for integrated
prefix delegation, etc.. -- I couldn't help thinking, "there must be
an easier way to delegate an IPv6 prefix in the simplest setups (e.g.,
when v6 connectivity is obtained through a tunnel) -- DHCPv6 is way
too heavy-weight".

This is where I got.  Thoughts appreciated.

Problems with the spec (draft-bykim-ipv6-hpd-01.txt)
----------------------

I think this is a useful continuation of Brian/Jim's Automatic Prefix
Delegation work.  All the problems in the world are not necessarily solved
by DHCPv6... so I think developing an extremely simple PD protocol could be
very useful.  The applicability area I see for this are the cases where
DHCPv6 is not being used, especially when the ISP wants to offer IPv6
support very simply, using a tunnel.

However, this document goes into a bit too complex direction.  There are
multiple problems with the approach as-is:

 - Why use PrefixCnt, and not PrefixLen when sending the Delegator Query? 
The most important thing is the length of the desired prefix, not the number
of them, after all.  The whole PrefixCnt thing seems fishy to me, all in all
-- the same information can be obtained by using an appropriate PrefixLen!

 - Similarly, PrefixDiff doesn't seem to be all that useful.

 - CGA security does not work unless you use Signature options from SEND as
well, so that can be scrapped.

 - 2 roundtrips are needed, with 4 different messages to get a prefix: a bit
too many for my taste.

 - The draft makes confusion about "built-in routing".  That sort of thing
is integrated with prefix delegation in any case: you can't have it without
-- as static routes are set in any case.  This seems unnecessary to mention
here.

 - The scope is not clear; why would one need hierarchical prefix
delegation where one would not use routing?  That is, if one gets a /64, it
cannot be delegated (in a meaningful way) forward.  If one gets a /48 (e.g.,
on a home network), why would one need to delegate it forward -- are there
routers there, requesting smaller prefixes -- I hope not!  And in an
Enterprise, you want to set this up manually in any case.  So the whole
hierarchical part appears to be really fishy, and should be removed unless
clear justification is found.

So -- I think think the spec has suffered from a serious feature creep, with
little regard to the actual user needs.

But, I'd still propose to go forward with this (or another document, started
from scratch), in an entirely different format and design tradeoffs, as
described below. 

I could write it, but I would prefer if someone else wanted to work on
this (too many things in progress at the moment.)

Current model is basically like:
--------------------------------

 1. Delegator Query, looking up the delegators and signalling the number of
    prefixes solicited (no prefix length?).
 2. Response w/ nmber of prefixes and prefix len difference (how?)
 3. Prefix Request to request prefixes (not telling which)
 4. Response w/ prefix delegated 

Return: prefix returned message -- replied with prefix returned.

Renewal: renewal message.

As you see, there are a lot of different messages, with different subcodes:
really difficult to understand..

Proposal
--------

Instead, use Neighbor Discovery messages rather than directly putting them
on top of ICMPv6.  This gives the benefit of being able to use all the
functions of SEND without any specification, as SEND only protects neighbor
discovery messages (and all of them, if you just plug in the signatures etc!).

[[ the features in double brackets are ones that could be easily 
added, but IMHO I'm not sure whether that is worth the effort. ]]

Now, the messages could be like:

 Prefix Solicitation: sent to "all-prefix-delegators" link-local multicast
address or a unicast address (learned using means outside the scope of this
memo; but link local)
   * addresses checked to be link-local, TTL=255. (same for all the
messages.)
   * Includes PrefixLen field, indicating the preference for the prefix
     length
   * Includes a "Test" flag: if given, the routers does not
     actually delegate the prefix, only show which prefix they would have
     given. (This can be used to pick among the routers, as well as learn
     which kind of prefixes/lengths they would be giving.  But the point is
     that if there are multiple routers which are willing to give you a prefix,
     why not get prefix from each unless explicitly desiring otherwise?)
   * Includes a "No Refresh" flag: if given, do not refresh the existing
     prefixes, but allocate new ones; the old ones continue to be used.  If
     not given, refresh the old prefixes (if delegated) or allocate new ones
     (if no existing delegation).
   * [[ no PrefixCnt field, as this seems unnecessary -- just use 
     PrefixLen or ask again -- but could be plugged
     in later if deemed necessary ]]
   * [[ no authentication/user identification options; authentication 
     is assumed to be obtained
     on the link layer.  However, it is possible to include Authentication
     type and length fields (1 octet each) which can be used to piggyback
     different kinds of authentication information, later on if needed.
     Authentication could also be done with SEND. ]]
   * [[ one could have "reverse DNS delegation requested" flag here as well,
     with an option which could encode DNS server address(es), but I don't
     think that's really important for mainstream use.]]

 Prefix Delegation: sent to the unicast link-local address of solicitor
   * includes Test flag, to indicate whether delegation was really done
   * [[ could also have reverse DNS delegated flag, as described above, but
     IMHO doesn't seem to be really important for now.]]
   * includes the prefix(es) delegated to the user.

     [[  each prefix could have a
     lifetime as well; lifetime of zero means "not specified" -- no
     refreshing is needed as long as NUD works.  If lifetime not
     specified, the lifetime of RAs on downstream interfaces SHOULD NOT be
     greater than 7200 seconds. ]]

[[ Prefix Maintenance: miscellaneous messages
   * code 0: return the prefix; used by the solicitor to give back a prefix,
       either when ceasing to use it or when refusing the prefix delegation.
]] -- could be used for serious DoS unless authenticated.

The solicititor SHOULD run NUD on the interface.  If NUD fails to the
routers which have delegated prefix(es), MAY send a Prefix
Solicitation message with "No Refresh" not set (to know whether the
delegation exists; if it doesn't, to get a new one).  If some other
indication has been received that the interface has went up/down, may
similarly re-initiate the procedure.

Would this seem to make sense?  This also fulfills the prefix delegation
requirements draft's requirements pretty well AFAICS.

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

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Shin Miyakawa <[email-masked]>
Date: Thu, 18 Mar 2004 18:47:37 +0900 (JST)

> when v6 connectivity is obtained through a tunnel) -- DHCPv6 is way

"way too Heavy Weight" is not well-defined.
Please explain a bit more how you decide this. Pekka ?

When we dicuss about measurement, we should be mathematical.
Otherwise it sounds just a feeling or myth which 
leads us to just a superstition.

In this case, the information carried by the protocol
 - either DHCP format or whatever -  is essentially the same; 
just a prefix information which is about 128bits + prefix length.
Therefore the volume of the bits are also not so different  in either case. 
Also we need have some software (or maybe hardware)
to process prefix delegation but the complexity of either software is
just about the same, because it is very simple job.

When I  started the work of prefix delegation several years ago, 
Steve Deering told me that ICMP and RA are very fundamental 
so we should keep those as simple as possible.

I believe that that philosophy is worth to keep still (or forever).

Lastly, Let us recallvery important fact which is  that 
we should not have many options or protocols  for the same purpose. 

So, if we have DHCPv6 today, Let's use it.

Best regards,

Shin Miyakawa

---

From: Pekka Savola <[email-masked]>
Date: Thu, 18 Mar 2004 13:40:29 +0200 (EET)

> Therefore the volume of the bits are also not so different  in either case. 

There are many kinds of complexity / "heavy-weight":

 - specification complexity (how long the specs are, how difficul to 
understand, etc.) -- DHCPv6 + PD: ~120 pages.

 - implementation complexity (how many lines of code, any particularly 
difficult issues, etc.) -- DHCPv6: dozens? of thousands

 - requirements from the system (how does the mechanism interface with 
the routers, access databases, etc. -- e.g., do you need to have v6 
support in RADIUS databases, do you need to have customer information 
stored there, how is that communicated to the router or the DHCPv6 
server): It appears as if DHCPv6 has non-trivial set-up complexity.

 - the overhead in the messages (added bytes in all or some of the 
packets): not much, unless you run PPP like described e.g. in 
draft-shirasaki-dualstack-service-03.txt

 - the number of messages (how many packets (and how big) needed:  
DHCPv6 request at least two roundtrips (4 messages), if PPP is used,
even more.

It should be obvious that there is a significant difference here.

The critical questions, of course are:
 - is the difference significant enough (in any specific scenario)
 - if yes, does it make sense to have another solution for some 
   specific scenarios (whether commonplace or not)

> Steve Deering told me that ICMP and RA are very fundamental so we
> should keep those as simple as possible.

Well, I think we're discussing a very fundamental issue; it's IMHO 
much more non-sensical to invent new protocols just because we can.

> Lastly, Let us recall very important fact which is that we should
> not have many options or protocols for the same purpose.

These IMHO serve slightly different purposes.  DHCPv6 provides you
with a complex solution that works every time (well, on public LANs
setting up the key management is a mess); this proposal is aimed at
the simpler setups where the complexity is unnecessary and redundant.  
In such scenarios, DHCPv6 is more likely than not even used (e.g.,
with IPv6-over-IPv4 configured tunnels) -- and should not be required 
(IMHO, of course).

Let me ask another question: would you rather have proxy-ND for /64
prefixes or a simple (non-DHCPv6) prefix delegation for /48's?

---

From: Ralph Droms <[email-masked]>
Date: Thu, 18 Mar 2004 07:51:46 -0500

Pekka,

We have some experience with the DHCPv6 spec that is useful in evaluating
its complexity.  There are roughly 6-10 full implementations of
DHCPv6, including prefix delegation, address assignment and stateless.

We performed interoperability testing of 6 or so implementations last year
at TAHI and Connectathon.  I summarized the test results in an I-D (which
has since expired).  We discovered no show-stopper interoperability problems
with the implementations under test.  There were 10 or 12 less significant
problems that were easily fixed with clarifications to the spec.  I think
these interoperability results compare very favorably with initial testing
of most IETF specs.  We were able to integrate those fixes into the spec
before it was published as RFC 3315.

I received no complaints from any of the implementors that the spec was "too
complicated" or "too heavyweight".  I infer from these results that the spec
is readable and useful as the basis for an implementation.  I also point out
that, depending on how you read the requirements, the DHCPv6 spec could
advance to Draft Standard today, as we have demonstrated interoperability
among multiple, independently developed implementations based on RFC3315.

Here's a complete CLI for configuring the Cicso DHCPv6 server in IOS (note
that this implementation in IOS resides in routers and does not require
a separate server):

(1)  ipv6 local pool cpepref 3FFE:501:1000::/44 48
(2)  ipv6 dhcp pool cpepool
       prefix-delegation pool cpepref
       dns-server 2002:1:1:11::1
       dns-server 2002:1:1:11::2
       domain-name cisco.com
       domain-name eng.cisco.com
(3)  interface FastEthernet0/0
       ipv6 dhcp server cpepool

The CLI sets up a pool of prefixes for delegation(1), associates the prefix
pool with other DHCPv6 server configuration information (2) and enables the
server on an interface (3).  In this example, there is no customer
identification or authentication (which is optional).  It's hard to imagine
a simpler interface...

- Ralph

---

From: Ole Troan <[email-masked]>
Date: Thu, 18 Mar 2004 13:08:57 +0000

Pekka,

> when v6 connectivity is obtained through a tunnel) -- DHCPv6 is way

I disagree that DHCPv6 too heavy-weight (whatever that means).

Haberman's ICMP prefix delegation draft initiated the IPv6 W.G's work
on prefix delegation. it pretty soon became clear that we were
reinventing DHCP, so instead of developing a new DHCP lookalike, we
decided to reuse the existing DHCP infrastructure instead.

if I understand you correctly you want to specify a separate protocol
which handles prefix delegation in a restricted setup. how is the
requesting router going to determine which prefix delegation protocol
to use? can you auto-detect that the user setup is suitable for the
'simple' protocol?

as an implementor I find that implementing only one protocol to solve
a problem is less complex and results in a less heavyweight
implementation, than having to implement two protocols...

/ot

---

From: Pekka Savola <[email-masked]>
Date: Thu, 18 Mar 2004 15:36:55 +0200 (EET)

Reponding to both you and Ralph.

[Ralph:]
.....
> identification or authentication (which is optional).  It's hard to imagine

Yep -- the _interface_ can't be much simpler than that.  It can be 
set-up easily.  Then why again do we need 120+ pages, dozens of 
thousands of lines of codes, at least 4 messages, etc.etc. to 
accomplish all this?  This is a very simple case, solved with *very* 
simple means!

> decided to reuse the existing DHCP infrastructure instead.

That was probably based on the premise that it would have had to 
re-implement everything that DHCP could provide.  I don't make that 
assumption.  

Maybe the simple solution could be used in all the configured tunnel
cases now, and 50-90% of xDSL access cases; but someone is bound to
figure out uses for which one might desire something like DHCPv6 PD.  
I have no objection to that :).

> to use? can you auto-detect that the user setup is suitable for the

For the requestor, it doesn't really matter.  If you implement both,
you just run them in whichever order you want.  If you get a prefix,
you don't try with the other protocol.  The point is to support the
case if the delegator would only support one protocol (possibly the
"simpler" one), not both.

> as an implementor I find that implementing only one protocol to
> solve a problem is less complex and results in a less heavyweight

If everyone would implement the more complex protocol, possibly.  Of 
course, the question is -- why should everyone implement a complex 
protocol if they only need a very small part of it which can stand 
easily on its own?

This is a similar argument to the "DNS resolver discovery" in some
way, but more urgent in the sense that on dual-stack systems you don't
need to discover IPv6 DNS resolver, but you still need the prefix :-).

---

From: Ole Troan <[email-masked]>
Date: Thu, 18 Mar 2004 13:50:22 +0000

Pekka,

> accomplish all this?

DHCPv6 supports a two message exchange.

> This is a very simple case, solved with *very* simple means!

> re-implement everything that DHCP could provide.  I don't make that 

no, it was made on the assumption that the protocol would have to
fulfill the requirements as stated in the requirements document.

can you please specify exactly what you want to simplify? it is hard
to argue against vague statements like 'complex' and 'heavyweight'...

/ot

---

From: [email-masked]
Date: Thu, 18 Mar 2004 14:53:15 +0100

Hi,

We are working on the subject since last year
and have a first prototype that does prefix delegation and global 
address configuration
on a simple IPv6 network.

Here follows some thoughts that could help, I hope.

>Problems with the spec (draft-bykim-ipv6-hpd-01.txt)
How a delegator has to allocate address space is a key point IHMO.
A Delegator has to split a unique and large address space into several 
smaller ones.

And this address small can be used in two ways:
- link numbering
- sub-delegation

the right to sub-delegate a given prefix could be allowed by a delegator 
to a requetor, or not: only for link-numbering.
to avoid the usage of all the address space of delegated prefix very 
quickly.

> - Similarly, PrefixDiff doesn't seem to be all that useful.
how the prefix length is raising represents how fast the address space 
is used  from the root router to leaf routers.

> - 2 roundtrips are needed, with 4 different messages to get a prefix: a bit
Finding a delegator is different from retrieving a prefix. Like finding 
the authority and the resource.
I think is interesting to dissociate the 2 tasks,
for example to be able to retrieve prefixes from 2 different delegators.

>clear justification is found.
I see in HPD a simple way to have unique and global subnet values based 
on a global initial prefix.
And when link numbering is well done, resulting propagated  routes can 
be minimized.

>Current model is basically like:
I think the approach is good,
even using another link-local messaging,
we thought of course about using ND and SEND to secure the Delegator 
claimed role.

>Now, the messages could be like:
I think a first step could be to find a trusted Delegator,
to avoid abuse of a malicious prefix provider node (using SEND and 
signature ND option).

>requirements draft's requirements pretty well AFAICS.
to go further until link numebering,
and to avoid to much prefixes usage on the same link,
our experiment showed that a link prefix "negociation" is useful.

Hope the propositions above could help.

I'm adding a big Thanks to APD and HPD authors for their work on the 
problem.

Regards,

Laurent Clévy

-- 
Laurent Clévy                
Alcatel CIT, R&I             Voice: +33 (0)1 69 63 18 34
Route de Nozay               Fax  : +33 (0)1 69 63 13 59
91460 Marcoussis             mailto:[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Thu, 18 Mar 2004 16:24:00 +0200 (EET)

> fulfill the requirements as stated in the requirements document.

What I proposed does this; let's see:

3.1 Number and Length of Delegated Prefixes

==> fills all three requirements.

3.2 Use of Delegated Prefixes in Customer Network

==> fills both requirements.

3.3 Static and Dynamic Assignment

   The prefix delegation mechanism should allow for long-lived static
   pre-assignment of prefixes and for automated, possibly short-lived
   on-demand dynamic assignment of prefixes to a customer.

==> both allowed. (The former obviously requires configuration, but 
this is no different from DHCPv6.)  The short-lived delegation case 
may profit from the lifetime associated with the prefix.

3.4 Policy-based Assignment

   The prefix delegation mechanism should allow for the use of policy in
   assigning prefixes to a customer.  For example, the customer's
   identity and type of subscribed service may be used to determine the
   address block from which the customer's prefix is selected, and the
   length of the prefix assigned to the customer.

==> policy is outside the scope of the proposal, but this is a
"should" so it fulfills the requirements even as-is.  Obviously, this
is supported if a database or similar includes notion of policy in
terms of customer interfaces (or the like), or if you use the
authentication/user identification option.

3.5 Security and Authentication

   The prefix delegation mechanism must provide for reliable
   authentication of the identity of the customer to which the prefixes
   are to be assigned, and must provide for reliable, secure
   transmission of the delegated prefixes to the customer.

==> yes (incoming interface or other customer identification, SEND, or 
the authentication/identification option), yes (SEND).

3.6 Accounting

==> yes.

3.7 Hardware technology Considerations

   The prefix delegation mechanism should work on any hardware
   technology and should be hardware technology independent. The
   mechanism must work on shared links.  The mechanism should work with
   all hardware technologies either with an authentication mechanism or
   without, but ISPs would like to take advantage of the hardware
   technology's authentication mechanism if it exists.

==> yes; yes for shared links (requires authentication in some means 
as above; equally problematic with DHCPv6); yes.

So, it seems all the requirements are fulfilled, with much lower 
amount of complexity.

> to argue against vague statements like 'complex' and 'heavyweight'...

I want to simplify the protocol, for the protocol to be simple and
easy to understand, and trivial to implement.  DHCPv6 PD spec is about
20 pages long; that is one primer: the whole protocol should be no
longer than that.

Of course, all of this is a moot point if the consensus is that full
DHCPv6 must be implemented by every box (especially if it could be
used as a router); but I don't think such exists.

---

From: Ralph Droms <[email-masked]>
Date: Thu, 18 Mar 2004 09:45:12 -0500

For the IPv6 WG - let's cut to the chase.   Is there interest in expending
any more of the IETF's resources reopening a problem for which we
have rough consensus on a solution, published specifications and running
code?  We have lots of important problems that have *no* solution, yet;
let's move on to those problems and start deploying the solutions we already
have completed.

- Ralph

---

From: Pekka Savola <[email-masked]>
Date: Thu, 18 Mar 2004 17:13:02 +0200 (EET)

On Thu, 18 Mar 2004, Ralph Droms wrote:
> Is there interest in expending any more of the IETF's resources
> reopening a problem for which we have rough consensus on a solution,
> published specifications and running code?

You say that carefully, but still giving an impression as if rough
consensus had been gauged that only one solution would be specified --
otherwise there would not be "reopening" the problem. That has never
been even raised (AFAIR); I'd certainly have objected.

The fact that there is a solution out there, which fits the needs of
some users, does not mean that there can not (or should not) be a
different kind of solution which would seem to be much more
appropriate in some other scenarios or for some other users.

---

From: Christian Strauf <[email-masked]>
Date: Fri, 19 Mar 2004 12:32:11 +0100

> difficult issues, etc.) -- DHCPv6: dozens? of thousands
I don't see how this has a practical impact especially in terms of 
configuration. In all the implementations of DHCPv6 that I encountered, 
DHCPv6 PD is trivial to set up and to maintain.

Concerning RFC3315: I know people who implemented DHCPv6 and the 
essence of what they told me about the RFC is that, though it is quite 
a long document, it is indeed very comprehensive, sound, complete and 
it hardly poses any open questions.

> server): It appears as if DHCPv6 has non-trivial set-up complexity.
I disagree. Especially upcoming commercial DHCPv6 implementations will 
have a stress on easy maintenance and interoperability with external 
customer data sources like databases. And if this infrastructure is 
present, I can only see advantages in the use of DHCPv6.

> much more non-sensical to invent new protocols just because we can.
True. This is why I think we should stick to DHCPv6 for PD.

> with IPv6-over-IPv4 configured tunnels) -- and should not be required
As said before, DHCPv6 for PD is so trivial to configure that I don't 
see a point in trying to cook up an "easier" solution.

It is important to make sure which point of view we're talking about. 
To a certain extent, DHCPv6 might not make sense for smaller networks 
(maybe some 30 nodes that connect). But I have no doubt that for bigger 
networks it definitely presents quite a benefit. So from an enterprise 
point of view, I don't think anything else than DHCPv6 for PD makes 
sense. On the contrary, most enterprise site will most likely deploy 
DHCPv6 anyhow, so maintaining an additional mechanisms would create 
administrative overhead.

Christian
--
JOIN - IP Version 6 in the WiN  Christian Strauf
A DFN project                   Westfälische Wilhelms-Universität 
Münster
http://www.join.uni-muenster.de Zentrum für Informationsverarbeitung
Team: [email-masked]      Röntgenstrasse 9-13
Priv: [email-masked]    D-48149 Münster / Germany
GPG-/PGP-Key-ID: 1DFAAA9A       Fon: +49 251 83 31639, Fax: +49 251 83 
31653

---

From: Ralph Droms <[email-masked]>
Date: Sun, 21 Mar 2004 07:27:45 -0500

>What I proposed does this; let's see:

Let's be clear: Ole did not say anything about whether your proposal does or
does not meet the requirements in
draft-ietf-ipv6-prefix-delegation-requirement-04.txt.  Ole stated that
RFC3633 meets those requirements, which it does without requiring that a PD
delegating router "re-implement everything that DHCP could provide".

- Ralph

>[snip]

For clarity, no one has stated (or even suggested) that "DHCPv6 must be
implemented by every box".  If a vendor wants to make PD available in a
product, the vendor implements DHCPv6 PD.  If a vendor doesn't think PD will
be a selling point in a product, the vendor is free not to implement it.
Why would DHCPv6 PD be any different from any other IETF protocol?

- Ralph

---

From: Pekka Savola <[email-masked]>
Date: Sun, 21 Mar 2004 16:58:17 +0200 (EET)

On Sun, 21 Mar 2004, Ralph Droms wrote:
> draft-ietf-ipv6-prefix-delegation-requirement-04.txt.  

Right; I noticed this.

> Ole stated that

My point was that DHCP also provides N++ other features which are 
completely unnecessary.  The proposal was specificatlly *not* to 
re-implement everything DHCP is providing.

> implemented by every box".

Obviously -- but looking at the arguments made at different fora, this
is more or less the road we're treading.  Basically all CPE-grade
routers (or nodes which could be used as such, including also most
host sytems) need to be able to the receiving end of PD.  Include the
DNS resolver etc. discovery requirements on the mix and you're pretty
close to "implement in every box".

> If a vendor wants to make PD available in a product, the vendor
> implements DHCPv6 PD.

You're equating "vendor wants to provide PD" with "vendor wants to 
provide PD with DHCPv6".

---

From: Ole Troan <[email-masked]>
Date: Sun, 21 Mar 2004 15:30:16 +0000

Pekka,

>> Ole stated that RFC3633 meets those requirements, which it does
>> without requiring that a PD delegating router "re-implement
>> everything that DHCP could provide".
>

I'm not sure I understand where you're coming from. if you only want
to do DHCP PD, then you don't need to implement all those 'completely
unnecessary' features.

the amount of work required to implement PD using a DHCP based
protocol engine versus an ICMP based protocol engine is similar. the
benefit of reusing DHCP (ignoring the fact that its already an RFC and
has numerous implementation) is that the cost of implementing and
deploying all the N++ features (DNS, address assignment, SIP, ...)  is
much lower.

it sounds to me like the motivation here is to avoid DHCP at all
cost. I'm certainly not a big fan of DHCP, but I'm pragmatic enough to
see that reinventing DHCP just to get a different acronym isn't worth
it.

/ot

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Mon, 22 Mar 2004 15:50:56 +0900

>>>>> On Thu, 18 Mar 2004 09:45:12 -0500, 
>>>>> Ralph Droms <[email-masked]> said:

> let's move on to those problems and start deploying the solutions we already

I basically agree, especially in that this thread won't be productive
enough to spend everyone's energy.

Just to state my own opinions on some discussion points:

- whether (implementing) DHCPv6 is too complex for the purpose of
  prefix delegation.
  I'm reluctant to have this discussion, since this kind of discussion
  often tends to be a subjective one.  I personally don't think the
  spec is "too" complex from my experience of reviewing and
  implementing the document, but it would be difficult to prove my
  impression.

  For example, I needed three days to implement (an initial version)
  the prefix delegation mechanism using the "IA" based resource
  management, which corresponds to the core part of the DHCPv6
  specification.  Two weeks later (since then I had made some bug
  fixes and additional features to the initial implementation), I
  confirmed the interoperability of the implementation with several
  other vendors.  Can this fact be a proof that the specification is
  "not to complex to implement"?  May be not, particularly for those
  who do believe the complexity from the beginning...

  I also know several vendors that provide "cheap" CPE devices,
  including Yamaha, 6Wind and Allied Telesis (some of them may not be
  popular outside Japan), have implementations of prefix delegation
  based on DHCPv6.  Do we really want to provide (yet) other
  candidates due to the "complexity" even with this fact?  Probably
  yes, those who do believe the complexity...

- whether it is a good thing to provide other (new) possibilities.  Of
  course, having alternatives is in general good.  In this particular
  case, however, I don't see the need for it.  First, as already
  stated, I don't think the "complexity" (if any) can be a
  show-stopper of IPv6 prefix delegation.  In fact, (again as already
  stated) even vendors who would want a "simpler" specification have
  already implemented the specification.

  On the other hand, having several choices would increase
  implementation/operational cost.  Vendors will end up implementing
  both (or all) of them, considering possible combinations.  Operators
  will often have to learn how to configure the devices for all
  mechanisms (because in general we cannot assume a particular
  behavior at the other end).  These kinds of issues are not new or
  specific to prefix delegation; it's basically a trade off issue.
  But, IMO in this case, I don't think the advantages of flexibility
  outweigh the disadvantages of the cost.

In any event, I don't know how we can go about this discussion.  As
we've seen (or as far as I've seen), the points are quite subtle
and/or subjective and it will be difficult for any party to convince
the other.  One thing I'm quite sure is that it will be a waste of
time to continue the discussion here (whether the "simpler" mechanism
is a good idea or not).

So, I'd like to propose:

1. let's just stop this thread now.  On top of this,

2-1 if those who want to standardize the "simpler" mechanism can
  continue the work as individual, let them do it, and let "the
  market" decide.  If the market likes the "simpler" idea, vendors
  will start implementing it and operators will start deploying it.
  Then we can consider to take it as a wg item and/or publish it as an
  RFC, etc.

2-2 if those who want to standardize the "simpler" mechanism stick to
  adopting it as a wg document, then I don't know what to do.  But
  we'll at least need to see consensus to adopt it.  And, with all due
  respect (I'm trying to be fair as much as possible), the idea has
  not attracted many people.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]