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
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
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
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 needed
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, we
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++
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++
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 running
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 probably
[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 running code?
- 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
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
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
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
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 mathematical.
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
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.,
when v6
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
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 is
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
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 infrastructure
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 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
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 carefully, but
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
25 matches
Mail list logo
