Re: nfsv4?
| From: | Theo de Raadt <deraadt-AT-cvs.openbsd.org> | |
| To: | Ted Unangst <ted.unangst-AT-gmail.com> | |
| Subject: | Re: nfsv4? | |
| Date: | Wed, 27 Oct 2010 19:34:15 -0600 | |
| Message-ID: | <201010280134.o9S1YFJR032562@cvs.openbsd.org> | |
| Cc: | FRLinux <frlinux-AT-gmail.com>, "James A. Peltier" <jpeltier-AT-sfu.ca>, misc-AT-openbsd.org | |
| Archive‑link: | Article |
> On Wed, Oct 27, 2010 at 5:26 PM, FRLinux <frlinux@gmail.com> wrote:
> > On Wed, Oct 27, 2010 at 9:45 PM, Theo de Raadt <deraadt@cvs.openbsd.org>
> > wrote:
> >> The design process followed by the NFSv4 team members matches the
> >> methodology taken by the IPV6 people. =A0(As in, once a mistake is made,
> >
> > Sorry, I'll bite. What exactly is wrong with IPv6 here? I gathered
> > from this list not a lot of developers here like it, but I still don't
> > get it. Please educate me (this should be enlightening).
>
> Instead of fixing the one problem with v4, they decided to fix a
> thousand additional "problems" that nobody really cares about.
in that regard i disagree, but perhaps only in tone.
With ipv6, they decided to create a bunch of new problems that
people now find they care deeply about
- they created a totally new problem by avoiding arp. the
benefit of their layer-2 discovery mechanism has been
absolutely zero; the best unit of measure for the cost of
that decision is "decades".
- they created a new problem by punting global routing to
"further study" (in this, they showed that they had deep
familiarity with appletalk and ipx).
- they created an entirely new and huge problem (destroying
SIOCGIFCONF backwards compat hurt IPV6 deployment in operating
systems on a massive scale) by not making their sockaddr be
a power of 2 in size. it sounds silly, but it turns out it
is the kind of thing which matters. when they were told of
this problem (very early on) they said something like "oh,
but we already have 3 engineers in the world running their
own ipv6 test code, so it is too late to change that".
this is the specific mindset which results in layers of bad
decisions papered over top of each other.
shit which comes out of research organizations all tends to suck these
days, doesn't it. or perhaps it always did (OSI networking, ipv6,
same same).
i have theorized in the past that the problem we face is
that an insufficient number of axe murderers are attending those kinds
of research meetings.
Posted Nov 4, 2010 2:36 UTC (Thu)
by dwmw2 (subscriber, #2063)
[Link] (5 responses)
The neighbour discovery system means that you need working multicast in your Ethernet drivers, which has occasionally been an issue, but not very often.
Global routing works fine. Theo may mean portability, in the sense of Mobile IP which is better defined in IPv6 in Legacy IP and won't always suffer the triangle routing problem, but isn't widely implemented yet. But it's still an improvement on IPv4.
SIOCGIFCONFIG was deprecated anyway around here, and I can't imagine why anyone would care about struct sockaddr being a power of 2 in size. Hell, if it matters that much to you, you can make struct sockaddr_storage however large you like.
Perhaps I'm missing something
Posted Nov 4, 2010 13:10 UTC (Thu)
by smurf (subscriber, #17840)
[Link]
Well, the vehemence of Theo's reaction and the real-world gravity of whatever problem he's reacting to have historically been shown to correlate by
well, not a whole lot. On average.
Worse, sometimes the correlation is negative.
In this case, anything that can't do multicast is not useable for IPv6 anyway. For instance, router advertisements won't be visible.
Posted Nov 6, 2010 10:57 UTC (Sat)
by Lennie (subscriber, #49641)
[Link] (3 responses)
It is actually the reason why IP-address-blocks have such a high price, a way to discourage people from getting their own. The more address-blocks are given out, the larger the routing tables.
Their was hope that IPv6 would bring along a solution to the routing problem. But the one solution for routing-table size that was proposed for IPv6 did not happen.
Here is a graph with the size:
You have to remember that any change in routing anywhere in the world could lead to an update being sent to every router in the world. That means that their are a lot of updates. That means on a quiet saturday still many updates per second.
The larger your network and thus more other networks you connect to, the more updates you get. Their are workarounds, but non of them are great.
One proposed solution is called LISP, which is a very confusing name for anyone with some background in programming. :-)
Posted Nov 6, 2010 18:52 UTC (Sat)
by dlang (guest, #313)
[Link] (2 responses)
if the problem is that the BGP protocol is sending the entire file for every update, that is easily fixable by adding a mode where a router can send diffs instead of the entire file.
Posted Nov 6, 2010 19:46 UTC (Sat)
by Lennie (subscriber, #49641)
[Link] (1 responses)
It's not so much the size alone, it is the amount of changes that the router-CPU has to crush through per second.
When providers need new hardware just because the routing table has grown to big for their router that is a bit sad, right ?
When we are not giving large and medium size companies a multi-homed address because the routing table can't deal with that, that is also sad.
Posted Nov 6, 2010 20:55 UTC (Sat)
by dlang (guest, #313)
[Link]
I don't consider it 'a bit sad' that routers get outgrown, I consider it a normal fact of life, the Internet grows over time, we know today what size router you would need for the worst possible case, but nobody buys that size router (even the core ISPs don't hit this worst-case). Everyone is buying something that's "good enough for now" and part of doing so is the fact that you may need to upgrade later.
large and medium sized companies are able to get multi-homed addresses. The place I work started doing so 12 years ago when getting 4MB on a router was a very expensive thing to do (IIRC the first BGP routers we got cost >$30K) at the time we were a 30-40 person company
I'm not sure I recognise any of those three as being real problems.
Re: nfsv4?
Re: nfsv4?
But if you can't get a route to the outside world, you can just use RFC1918 addresses and be done with it.
Re: nfsv4?
Re: nfsv4?
Re: nfsv4?
Re: nfsv4?