On Jun 9, 2011, at 11:18 AM, Philip Homburg wrote:
In your letter dated Thu, 9 Jun 2011 10:37:56 -0400 you wrote:
I have also seen those claims in v6ops email (haven't caught up with all of
it
, but have seen a few messages). I don't buy the argument. Clearly the
inten
t of this draft and protocol action are to discourage use of 6to4,
particularl
y in new implementations. You can't discourage use of 6to4 in new
implementat
ions without harming people who are already using it and depending on it.
(That would be a bit like declaring IPv4 Historic and discouraging new
impleme
ntations from supporting it - when we all know that there will be people
using
IPv4 in corner cases for many years even after the public Internet no longer
routes it. Legacy hardware and software that's still in use, etc.)
When the draft is clearly intended to do harm to 6to4, and there are clearly
p
eople using 6to4 in the Real World, it strikes me as disingenuous for its
prop
onents to claim that the document will do no harm.
I think this is likely to happen anyway. In all discussions it has been come
clear that 6to4 has nothing to offer for ordinary users, and that the
situation
is going to get worse over time (more NAT, more broken 6to4 installation).
I don't buy the notion that "ordinary users" only use some small number of
killer apps. "ordinary users" are quite diverse.
I certainly agree that increased deployment of LSN will do harm to 6to4 and its
users. This wouldn't bother me if ISPs were going to roll out a native v6
solution concurrently with LSNs, but my impression is that v6 support is going
to lag LSN imposition.
So for any CPE manufacturer is makes perfect sense to start planning on
dropping support for 6to4 in future CPEs, or not add it at all, if they have
yet to release firmware with IPv6 support.
I agree that v4 CPE manufacturers, at least those for consumer applications
where the networks are likely to be saddled with LSN, certainly should not
automatically enable 6to4 in their products.
There's some justification for their not implementing it at all. However it's
my experience that "consumer" CPEs are often used to provide connectivity for
small business customers also. In general, LSN is not suitable for those
customers, and they could benefit from 6to4 support in the CPE.
But I'm more concerned about the potential for this action to result in 6to4
support being prematurely removed from hosts, than I am about its effects on
CPEs.
This is independent of whether the protocol is declared historic.
On the other hand, there is no reason why open source distribution would
have to drop 6to4 support. As long as there are people to maintain it, it
can stay. Also on other operation systems, as long as there is some sort of
tunnel interface, you can implement 6to4. It is just a few lines of code,
everybody can do it.
"A few lines of code" imposes a significant barrier. I've done a fair amount
of kernel hacking in the past, written device drivers, and brought up Linux and
FreeBSD and NetBSD (in that order) on laptops back in the days when laptop
hardware was really flaky and poorly documented and there was no support in the
kernels for their network interfaces. I'm not scared of writing kernel-level C
code. But I don't do it all the time, and realistically it would take me
several days to fetch the source code, update myself on the build process, and
figure out exactly how to re-insert 6to4 into the kernel. And that's for
Linux or NetBSD - I have less familiarity with MacOS and other kernels. And
I'd have no idea about how to retro-fit 6to4 into Windows if support for it
were removed. I generally don't write code for Windows, but I am occasionally
forced to use it.
And somehow I suspect that my skills in this area are considerably more than
the typical 6to4 user.
So I don't see the big fuzz. If you want to use it, just create a web page
that lists software implementation of 6to4 for every possible platform. And
let the authors of the software know have much their software is appreciated.
Similarly, I don't see why there's such a desire to deprecate 6to4 and declare
it Historic. It's the first time I can recall a proposal to move something to
Historic that was widely deployed, widely used, and for which there was no
suitable and widely available replacement.
Nor do I understand why, in an organization that is supposedly about building
consensus, there's such a demand for a divisive and obviously harmful action.
Generally the way you build consensus is by focusing on things for which there
is wide agreement, and crafting compromises on the other things. But the
proponents of this draft have taken a 'no compromise' position.
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf