Doug,
But it's not. ... We _really_ want to get this right NOW. Adding more
kludges so that we can "Just get it deployed" is actually going to
make life (and future deployment) harder down the road, not easier.
Agreed so far.
Suresh wants to support a particular type of a deployment, and it
doesn't help him if some design is the "right" one or matches with
our *desires* of what hosts and other devices should be doing or
implementing. The primary concern should be that we have something
that works.
Wrong wrong wrong wrong wrong. Sorry, but maybe if I say it enough
times in this post I'll stop having to say it over and over again in
subsequent posts. I know I'm talking out of both sides of my face
here, since I'm usually the one who is complaining about the IETF not
listening to the operators (especially in IPv6) but this is one case
where the operator is just plain wrong, and what they want to add to
the specification is a not only a bad idea, it's a dangerous one.
Maybe there's a misunderstanding somewhere, but I did not argue in favor
of any particular solution or architecture. I do get the point that we
have to look at the architecture, the need for this model of deployment
and make some hard decisions about what's reasonable.
But if your argument is that we should ignore real life problems, then,
sorry, I'm obviously going to disagree. My point is that no matter what
we are doing (Suresh's option, DHCPv6, something else) we should try to
understand the practical implications for people that are using these
things. Its not enough that all the specs are aligned or that in theory
you can the network to work. It really has to work by default on all
devices, given that we are talking about consumers. As an example, it is
IMHO not enough that software is available on a given platform, if it is
not turned on by default then for all practical purposes its not there.
If you look at it this way, then in my experience at least the devices
that cannot do DHCPv6 are not a small minority that can be ignored as a
corner case.
Host support is important because that is an area where neither the
IETF, any single vendor, or the DSL operators have any easy way to
change the situation. But it is of course by no means the only
constraint. The operators have their issues as well. Even though they
are in control of their own networks, they probably want to keep
their underlying L2 network architecture as it is, despite
introduction of IPv6 or other new features.
Two responses. If we can't expect the hosts to be changed in order for
this to work, how do we expect them to send clever new RS messages
even if the draft is adopted (or perhaps I'm misunderstanding something)?
That's the problem. Or one of the problems in one particular solution.
And I don't know if it's common in other countries or not, but every
broadband account I've ever signed up for in the US has come with a
dis[kc] of special software that I "had to install" to make my system
able to access the intartubez. Now back in the 90's when these things
came on floppy disks there often was some sort of mandatory sign-in
software that I couldn't get on line without.
In my experience that is not so common these days any more. YMMV.
Since I was dual-booting FreeBSD at the time, and the software was
only available for windows, I had to figure out a solution for myself
because my OS was not supported.
Nowadays these things come on CD, and I've long since learned NOT to
install them because they are overwhelmingly likely to do Bad
Things(TM). But it does make one think that there may be a solution to
the "Random host doesn't do DHCPv6, and/or doesn't do it by default"
problem; even if one doesn't like Woj's CPE-related solution (which
I've already said I do think is the right answer).
Not really, IMO. First of all, if we are talking about a bridged, not
routed home network then there are likely to be multiple computers,
several appliances and so on that are all visible to the service
provider and that all need an address. There's no way the service
provider can give you updates for all of these.
Jari
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
