Subject: Re: [dhcwg] DHCPv6 Stateful Prefix Length

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 01 Oct 2007 17:06:56 +0900

At Fri, 28 Sep 2007 16:32:10 -0400,
"Bernie Volz (volz)" <[email-masked]> wrote:

> Not sure if you were asking Hemant or me or both ...
>  
> My reason is pretty simple ... it is completely unnecessary. RAs already
> handle this just fine.

I'd basically wait for the expected new I-D that is supposed to
explain why the introduction of such new DHCPv6 options is justified,
but for what it's worth, I agree with you for now.

We've seen arguments for the new options based on their own
motivations, but so far these are not convincing enough for me to
override the design principle described in Section 3.2 of RFC1958,
i.e., the reasons for the arguments do not look good enough to me not
to choose the same solution (=RA in this case).  In particular, I'd
not buy the argument of introducing the redundant functionality just
because there are implementations that do not follow RFC
specifications.  I hope the coming I-D will provide much stronger
arguments.

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

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

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 1 Oct 2007 09:35:54 -0700

> override the design principle described in Section 3.2 of RFC1958,

RFC1958 section 3.2 argues explicitly in favor of improvements - I
think that carrying potentially host-specific configuration data via
a mechanism that can carry host-specific contents very naturally to
be an improvement.

What I do think that RFC1958 tells us in this context is that as
DHCPv6 starts assuming this role, that Router Solicitation would be
deprecated, and go the route of e.g. BOOTP or IPv4's ICMP Router
Discovery.

This is simply a natural evolution.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 02 Oct 2007 02:40:54 +0900

At Mon, 1 Oct 2007 09:35:54 -0700,

> RFC1958 section 3.2 argues explicitly in favor of improvements - I

Yes.

> a mechanism that can carry host-specific contents very naturally to

The *potential* of host-specific config could be considered an
improvement, although I personally think it only covers very minor
usage, if any, and doesn't immediately justify the duplicate
functionality.  I know there are people who think it's sufficient,
while I suspect I'm not the only person who don't.  Again, I expect
the coming I-D will provide a solid ground of further discussion,
possibly including this point, and would rather wait for it than
repeating mostly the same points.

> deprecated, and go the route of e.g. BOOTP or IPv4's ICMP Router

Sorry, I don't understand this.  Could you please be more specific?
Are you saying RFC4861-style default router and on-link prefix
autoconfiguration will be deprecated?

					JINMEI, Tatuya

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 1 Oct 2007 11:26:59 -0700

> functionality.  I know there are people who think it's sufficient,

I think that IPv6 also covers a very minor usage (if any). :(

What I'm trying to say is that if we applied the rulebrick "it must
improve (or make possible!) only the majority of existing use cases"
to every IETF technology, we would get very little useful work done.

I think, for example, the IETF collectively tried to do that with HTTP
due to the existence of gopher?

So in the proven existence of a problem, "do not solve" is not a valid
answer, in my opinion.  I guess we're allowed to disagree on that...

But I do agree that on the subject of whether or not there really is a
"proven existence of a problem" is something to be elided until a
draft defining it exists...

On the subject of crystal gazing;

> autoconfiguration will be deprecated?

I only pretend to speak so far as the Router Solicitation and
Discovery components, but yes.  I do not pretend to speak on the
subject of Neighbor Discovery...I have no reason to think it needs
an improvement so severe it requires replacement.

It is my suspicion that RS/RA will follow the same path of previous
technologies that bear very similar characteristics (but more
importantly, the same limitations), including but not limited to;

	RARP
	BOOTP
	IPv4 ICMP Router Discovery

This is obviously an opinion unsubstantiated by anything other than
history, and my own experiences using IPv6 every day (which may bias
me in regards to the ways we've elected to solve the administrative
burdens of RS/RA, which are in no ways similar to the "IETF meeting
network" methods).

It is also not necessarily true that history always repeats itself.

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 02 Oct 2007 06:15:18 +0900

> I think that IPv6 also covers a very minor usage (if any). :(

Correct.

> to every IETF technology, we would get very little useful work done.

It is a good reasoning to eliminate not DHCP but ND.

As was recently discussed in ietf ML, there are ISPs trying to
allocate not /48 but /56 or /64 to end users where not ND but
DHCP works for address assignment with *MANY* subnets.

So, let's eliminate ND with very littile usefulness.

> an improvement so severe it requires replacement.

ND is fundamentally broken, because its model is that dumb end
systems MUST (even though ND should have been optional) rely on
intelligent intermediate systems. OTOH, DHCP, which is completely
optional, is harmless.

> It is also not necessarily true that history always repeats itself.

According to our observations, IPv6 failed to repeat the history
of IPv4.

							Masataka Ohta

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 02 Oct 2007 13:44:22 +0900

At Mon, 1 Oct 2007 11:26:59 -0700,

> I think that IPv6 also covers a very minor usage (if any). :(

Maybe you're just being cynical, but in case you're serious I don't
see the point.  In my understanding, IPv6 was proposed and adopted to
solve the serious and well-recognized problem of IP address shortage.
Even though not all IETF players may like the resulting design of the
new protocol, the underling problem was considered substantial enough
to justify the introduction of a duplicate layer 3 protocol.  IMO,
it's very different from the potential use case of host-specific
default-router and on-link prefix autoconfiguration.

					JINMEI, Tatuya