Iljitsch, the last time we discussed this (on nanog@), we argued technical points until you finished with "I like RA." I will again admit freely that I can't (or won't) change what you do or do not like. It has never been my intent to adjust your desires.
I think this time you are leading us through an argument in circles,
we have discussed these points overmuch, and so I have no plan to
reply further.
I can agree that we disagree on fundamental principles.
On Thu, Oct 16, 2008 at 04:18:05PM +0200, Iljitsch van Beijnum wrote:
> Generally people run these protocols because they expect them to do
> something useful. If they knew in advance that the protcol wouldn't do
> anything useful they wouldn't run the protocol. With DHCPv6 we have the
> ability to know in advance that running the client is going to achieve
> results or only waste bandwidth. Telling people to ignore this information
> doesn't make any sense.
Here you are wrong; a machine in its cardboard box has no idea what
network it will be thrust into. Therefore, it must support "all"
potential interpretations of the word 'network'. Not "one."
> Anyone in the cellular industry reading this? What about firing up
> transmitters and using up battery every 120 seconds for a protocol that you
> KNOW isn't going to do anything useful?
Clearly if a cellphone required DHCPv6 to supply some configuration
parameter, then it would be better for the DHCPv6 server to reply
and fulfill that request. Governed by timing parameters, the phone
need not transmit (nor receive unsolicited broadcasts) for extended
intervals.
So in this case, disabling RA would be a technical advantage.
> RAs also react to changes in addresses
...identically to DHCPv6 if you weren't aware...
> or presence of routers in a
> reasonable way, which DHCP can't.
Actually, anyone who has ever used 'routed -q' would object with that
statement. Providing VRRP-protected exits for clients is a substantial
improvement over ICMP Router Discovery (which is identical to IPV6
RA).
Maybe you could get away with this if your network was 'best effort',
or even 'experimental'.
Anyone trying to make money will not see RA as an acceptable solution.
They may use VRRP, they may use OSPF, but they will not use RA for
router selection.
If for some reason the exits' locators need to change, DHCPv6 can
supply new updated configuration upon every Renew.
> RAs also share fate, which you can only
> do with DHCP if the server runs on the router.
The routers are probably DHCPv6 relays, so you can. But no one cares
to because VRRP is a better solution than 'routed -q' RA's.
> So RAs don't suck.
Now I know you're lying (or confused).
> new, but if DHCPv6 is so great, why would they use the IPv4 flavor of
> DHCP??
Let me be clear;
Client systems that support DHCPv6 are configured by it, even at
recent IETF meetings.
Client systems that do not support DHCPv6 (they have gotten drunk on
the RA lemonade) are configured by DHCPv4.
I propose we turn client systems that do not support DHCPv6 into
client systems that do support DHCPv6, and consequently provide an
IPv6 single-stack migration plan.
> But what happens today is of no importance in and of itself, as long as
> there is an upgrade path from where we are now to where we need to be when
> regular people start to run IPv6-only.
I agree. That is my entire goal.
IPv6 has to suck less than or equal to IPv4.
> try to upgrade the entire IPv4 internet. That doesn't mean that a 25 year
> old protocol with 15 year old extensions should be the blueprint for the
> future.
Hyperbole doesn't suit you. I think you will find I agree completely
with your intended statement:
Ancient technology like IPv4 ICMP Router Discovery and reverse-RARP
("DRARP") are unsuitable for modern use. They were deselected by
IPv4 network operators for technical, not marketing or political,
and still-true-today reasons.
So out with RA, in with DHCPv6.
> Well, the amount of people that complain that IPv6 changes too much seems
^
"on IETF mailing lists"
> to be about the same as those that complain that IPv6 doesn't change enough
> so my guess is that they got this more or less right.
Fixed it for you.
> For better or worse, IPv6 isn't just IPv4 with larger addresses.
I am a person who doesn't care what IPv6 is, except in the context of
how we transition to what it must be. I thought I agreed with your
own statement that today's practices are irrelevant except in terms
of transition strategies. I wonder why you now contradict yourself
in claiming that today's IPv6 is carved in stone for eternity.
>> My position is that always engaging DHCPv6, despite RA contents, puts
>> is in a migrate-able position.
>
> That doesn't get you closer to a situation where RAs no longer exist, which
> is not a desirable place to be in the first place.
I believe I qualified my technical position in earlier context, and
that this is a summary. Let me know if you require clarification.
> So why isn't there a subnet length field in DHCPv6 address assignment?
I believe DHCPv6's framers were fooled by false consensus.
>> Because
>> RA's services are a subset of what is made possible with DHCP,
>
> Yes, and a car is a subset of a plane. Of course if you don't need to fly
> and want fuel economy a car is more useful. What you're arguing is that all
> cars be outfitted with wings because that better fits with your world view.
I'm not sure if you realized this metaphor is backfiring on you. I
am proposing that IPv6 clients be presented with a single choice, and
not two, which your metaphor presents. In short, I'm proposing to
"lop off all the cars' wings".
Physical engineering principles do not directly apply to network
protocol engineering principles. If you have an argument to make, it
would be better to present it without the crutch of metaphor.
> We did this before when we went from ip6.int for the reverse DNS tree for
> IPv6 to ip6.arpa. Even at the very low IPv6 deployment levels at that point
> this must have cost MILLIONS in operational expenses without ANY real-world
> benefit.
I'm not sure what that has to do with anything, even if it were true.
> The internet isn't your personal playground where you get to change stuff
> just because you don't like it anymore. Changing stuff costs money, a tiny
> bit for vendors and huge amounts for operators. It's not yours to spend.
...
Haven't you heard?
DHCP is really "David Hankins Control Protocol."
It's funny because it's true.
--
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/
--
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
pgpehYmhpOVPi.pgp
Description: PGP signature
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
