On 14 okt 2008, at 18:32, David W. Hankins wrote:
See my earlier emails.
Why? They don't answer the question. If we apply the thinking that
all multicasts must be avoided, then there are a great many protocols
outside of DHCPv6 to which we must also direct our attention.
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.
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?
Your earlier emails have not convinced me in the slightest.
I assure you that the feeling is completely mutual.
Further, it seems pretty clear to me that router
solicitation is on a long path towards deprecation,
Where do you see evidence for that? I haven't seen this.
RA, despite its subtle differences, sucks in precisely the same ways.
The only time I have trouble with RAs is when there are rogue routers
on a subnet. But this happens with rogue DHCP (v4) servers as well so
no difference there.
The good thing about RAs is that my systems always get the same
address without having to configure stuff and/or have a server keep
track of leases. RAs also react to changes in addresses or presence of
routers in a reasonable way, which DHCP can't. RAs also share fate,
which you can only do with DHCP if the server runs on the router.
So RAs don't suck.
anyone who runs dual
stack today uses DHCPv4 to configure IPv6 (using IPv4 nameservers)!
I can understand they don't use RAs for this because RFC 5006 is
relatively new, but if DHCPv6 is so great, why would they use the IPv4
flavor of DHCP??
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.
There are reasons that IPv4 networks today are built using VRRP
default gateways, and that DHCP is the singly used host configuration
protocol, by a wide margin over others.
IPv4 doesn't have and can't have stateless autoconfig. It could have
RAs for default gateways and dead neighbor detection so VRRP is
unnecessary, but the current stuff works well enough that it's not
worth the trouble to 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.
It is not because "the
operators just don't understand how cool it would be if they did
everything differently." It has been a dialogue between IETF
protocols and network operators, and in starting from scratch with
IPv6, the IETF has made the mistake of throwing out the meaningful
results of this dialogue.
Well, the amount of people that complain that IPv6 changes too much
seems 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.
For better or worse, IPv6 isn't just IPv4 with larger addresses. You
can do a lot of things the same as in IPv4, but there are also things
that you can do with IPv6 that are impossible with IPv4. Or DHCPv6,
for that matter. For instance, if you want to use SEND, or run shim6
with uses HBA which is a SEND extension as its security mechanism,
hosts need to be able to create their own interface identifier. You
could of course modify DHCPv6 such that a host can create an IID and
the DHCP server assigns the top 64 bits and then wait 5 years for
everyone to implement this and a few more years for people to deploy
and configure it correctly, but this without any trouble with
stateless autoconfig today so that would only benefit job security and
nothing else.
(Note that I'm not against _registering_ addresses that hosts create
using DHCPv6, although it could also be done differently, in
environments where central knowledge of which host has which address
is beneficial.)
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.
If you don't have such clients then you can set the A bit to 0 if
you want
DHCP only so this is a reasonable line of thought but do you really
want to
have three different types of hosts on your network:
No. I only want one (precisely one). All clients should behave
consistently (=compatibly).
In that case we should deprecate DHCPv6. And also RFC 3041.
IPv6 incorporates all the address configuration mechanisms from IPv4,
IPX and AppleTalk. We'll have to live with that.
The error in your reasoning is in thinking that "forked paths will
simplify the network." It complicates it. We need a single place to
look for host configuration, not two and certainly not three.
So why isn't there a subnet length field in DHCPv6 address assignment?
Whether you like it or not, the above doesn't decribe IPv6 and
ditching stateless autoconfig is not a solution, nor is it desirable
or deployable.
If anything, we should get rid of DHCP. The whole notion that we need
to specify a binary format for every new piece of data that may need
to be configured and then wait until both clients and servers are
updated is completely outdated. A much cleaner approach would be to
advertise a URL in RAs where hosts can download their configuration
info in XML format over HTTP. Need an extension? Define it yourself on
your own servers and clients leveraging the X in XML without having to
wait for vendors to modify code. I'm sure at some point someone will
take the time to write down how to do this and it will take the world
by storm.
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.
This means either to proceed on a long-path to
deprecate RA and select DHCPv6, or to extend RA to fulfill the
complete requirements (turning it into a DHCPv6-alike in the process),
or to scrap both and create a new single protocol. These are our real
choices. I've chosen one which I believe is most expedient: select
DHCPv6.
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.
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.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
