This discussion (and the bykim draft) reminds me of some materials
I briefed a long time ago during an NGTRANS session at IETF50:
http://6bone.net/ngtrans/IETF-50-Minneapolis/Templin-v6v4compat.ppt
(See slides #15-#19; note that the colors in the diagrams denote distinct
IPv6 prefix assignments).
FWIW RFC 2461+2462 is 118 pages and I don't recall people complaining
about them being too complex to implement. I suspect 2 more pages
for DHCPv2 + DHCPV6 PD isn't that significant.
So I think there is something other than page count that matters.
Writing clear specifications which answers the i
> On Thu, 18 Mar 2004 09:45:12 -0500,
> Ralph Droms <[EMAIL PROTECTED]> said:
> 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
>> 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 t
> 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+
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".
>
> My point was that DHCP also provides N++ other features which are
> completely unnecessary. The proposal was specifi
On Sun, 21 Mar 2004, Ralph Droms wrote:
> 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.
Right; I noticed this.
> Ole stated that
> RFC3633 meets those requirements, which i
At 04:24 PM 3/18/2004 +0200, Pekka Savola wrote:
On Thu, 18 Mar 2004, Ole Troan wrote:
> >> 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,
> The network architect/engineer/admin (customer) community should be
> considered here, as well. Are there any customers that have said "DHCPv6 PD
> is too complex, we want something simpler"? I haven't heard from any.
That's too much saying.
If delegation of ``prefix'' to CPE is not neede
At 10:44 AM 3/20/2004 +0200, Pekka Savola wrote:
On Fri, 19 Mar 2004, Brian E Carpenter wrote:
> > As I've said before in reference to the recursive name server discovery
> > discussion, I don't believe it benefits the network operations community
> > to have multiple solutions to these kind of req
On Fri, 19 Mar 2004, Brian E Carpenter wrote:
> > As I've said before in reference to the recursive name server discovery
> > discussion, I don't believe it benefits the network operations community
> > to have multiple solutions to these kind of requirements.
>
> The vendor community would probab
Reaching rough consensus? As all of us might know, alternatives to DHCP
have always been controversial. Even I admit that DHCPv6 looks good for
hierarchical prefix delegation and it is hard to find HDCP-less place,
even though some of my colleagues are still frenzy about 1894 Ubiquitous
something
- implementation complexity (how many lines of code, any particularly
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
[EMAIL PROTECTED] wrote:
>
> On 18 March 2004, Pekka Savola wrote:
> > 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 run
On Mar 18, 2004, at 8:47 AM, [EMAIL PROTECTED] wrote:
On 18 March 2004, Pekka Savola wrote:
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
18 mars 2004 15:24
> A : Ole Troan
> Cc : [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Objet : Re: simpler prefix delegation
>
>
> On Thu, 18 Mar 2004, Ole Troan wrote:
> > >> Haberman's ICMP prefix delegation draft initiated
On 18 March 2004, Pekka Savola wrote:
> 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 carefull
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
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
On Thu, 18 Mar 2004, Ole Troan wrote:
> >> 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 infra
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.
Pekka Savola wrote:
Hi,
This started from me looking at draft-bykim-ipv6-hpd-
Pekka,
> [Ralph:]
> .
>> 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 i
Reponding to both you and Ralph.
[Ralph:]
.
> 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 authe
Pekka,
> 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.,
> wh
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
On Thu, 18 Mar 2004, Shin Miyakawa wrote:
> > when v6 connectivity is obtained through a tunnel) -- DHCPv6 is way
> > too heavy-weight".
>
> "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 math
> 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 co
27 matches
Mail list logo
