Slashdot Mirror

http://bill.herrin.us/network/...

This guy came up with a one-page proposal to extend the IPv4 address space, without IPv6 complexity and IPv4 backwards-compatibility.

Really wish someone would try implementing it so we could bypass the failed IPv6 adoption.

The problem with the approach is that it's very difficult to do in a way that doesn't break backwards compatibility, and if you're going to break compatibility then you may as well fix other things at the same time.

Didn't have to be that way. We could have had an IPv5 with all the addresses and none of the backwards compatibility issues if not for special interests in the IETF:

    http://bill.herrin.us/network/ipxl.html

Gets my vote for IPv7...

None of the developers spoke up and said, "Hey, this is a really bad idea!"

In point of fact, I spoke up. Loudly. And eventually resigned when the problems were not adequately addressed.

In August 2006 I wrote a white paper detailing the issues, including the "mail your friends" code that the invite URL falls under:

http://bill.herrin.us/composer.html

In fairness, the director of technology at the time no longer works for the DNC. The current guy inherited the problem.

I'd like to know a bit more about that

Take a look at: http://bill.herrin.us/network/geoag.gif

Nodes A through H represent autonomous systems.
The black lines indicate physical network connections.
The blue circles represent geographic areas which you want to aggregate into a single global route.
The green arrows indicate payment for service. (thus the green. Get it?) The black lines without green arrows are peering links.

If you construct the routes with normal BGP ignoring the geographic areas, all nodes can reach all other nodes and the packets will only travel peering links and links where there is a trail of green arrows from either the packet source node or the packet destination node. In other words, it accurately represents the business relationships that form the basis of the Internet's physical construction.

With geographically aggregated routes, the nodes in one circle see only a single route for all of the nodes in the other circle. No matter how you construct the forwarding information base (FIB) at each node, at least one of the following is true:

D routes to E via the B-C link (payment violation)
H routes to A via the F-G link (payment violation)
Some nodes can't reach other nodes.

The only way it functions without violating one of the company's networks is if B and F are the same company and C and G are the same company where from a payment perspective it doesn't matter which of the inter-geography links your packet transits to get to its destination.

So unfortunately when the IPNG guys back in 1998 thought they were going to solve the routing problem with hierarchical aggregation (which at least at one level is identical to geographic aggregation), it turned out they were in error about the feasibility. That really wrecked the whole routing plan for IPv6. The Regional Internet Registries are still adjusting to that reality, which is another drag on IPv6's deployment.

Are you absolutely sure you will continue to remain qualified under whatever procedures and policies are adopted to conserve IPv4 address and routing table space?

Yes. Yes I am. I keep up with ARIN PPML and NANOG and I've run the back-of-the-napkin calculations. There simply aren't any likely scenarios in which its more cost-effective to cut me off than it is to buy YFRV's next router. There aren't any scenarios where its even close enough to consider.

If you disagree, feel free to suggest a scenario so I can debunk it.

Is it? I thought you just got through explaining why it wouldn't be good for everybody.

Touche! Obviously I meant that its good for the folks who aren't in my position if the folks who are in my position don't hold up the wide deployment of IPv6.

Then, we'd have an IPv6 address crunch hit us just like the IPv4 crunch that looms over us now.

The IPv6 address space is more than 28 orders of magnitude larger than the IPv4 address space. More really when you consider how much of the IPv4 space has been lost for stupid reasons (coughmulticastcough). I don't think any of us has fully come to grips with exactly how large the IPv6 space is.

The number of legacy IPv4 registrants who announce IPv4 addresses but don't qualify for IPv6 addresses is well under 50,000. Fair or not, a one-time hit to the address space and DFZ table isn't going to hurt anybody.

The only IPv6 crunch likely in anything approaching the near term is a DFZ-size crunch. That could be handled with something like: http://bill.herrin.us/trrp.html

Can you name any fully-featured file systems for Unix that provide transparent compression? How 'bout any Unix that provides transactional file system behavior? Alternate streams/extended attributes that can be read and written as files?

You're looking for ZFS. It's in OpenSolaris, BSD 7.x, and Mac OS X 10.5. Linux has a FUSE port, but until the kernel devs get over their 'rampant layering violation' buggywhip-thought Linux doesn't/won't really have it.

How many versions of Unix have case insensitive file systems? (Personally, I feel that case sensitive file systems should be considered a dated practice.)

All I know about is HFS+, on linux and Mac OS X and ext3ci from fellow Slashdotter Bill Herrin, but that's because I haven't looked to hard. JFS has it too, I think.

Reiser4 provides what I think is a much better model for how to handle that sort of thing.

Agreed, Reiser4 is awesome from this regard. I'm not sure if ZFS is that advanced or not, especially in the realm of semantics.

But the others are things that I wish that Linux had. And that's just looking at the file system.

Would it be too rude for me to say, "look harder"? At a minimum I'm glad you posted the question here before giving up. Have fun!

In all but the largest unix/linux installations, managing the users in LDAP is an exercise in futility. When you're all done you have something that's still more difficult to manage than adduser/deluser on the individual machines. Worse, its now brittle: the LDAP server breaks and now every unix box in the system fails at every task that requires a UID to user mapping.

Far more useful is managing the users locally but authenticating them (i.e. checking their password) via LDAP. For example, in an enterprise you might want to piggyback the Windows Active Directory passwords or the IBM/Lotus Domino passwords. This turns out to be trivial to do via a PAM module but the LDAP connectors don't seem to exist. They all want to pull the crypt or MD5 password from LDAP and then compute it instead of binding against LDAP with the given credentials. Every time I want to do this I find myself having to write another PAM module like http://bill.herrin.us/freebies/notesldap.tar.gz

One of first culture shocks for people moving from Windows to Linux is the case sensitivity of file names.

I wrote a patch that creates an "ext3ci", a case-insensitive ext3 filesystem for Linux. Because it creates a seperate driver, you can have parts of the directory tree set up as classic case-sensitive and parts insensitive. Bash's wildcard expansion still expects case sensitive names but its great for web servers and similar machines where the users are expecting case-insensitive behavior.

http://bill.herrin.us/freebies/

Yeah, I hate that about Word. I have a perl script that strips out the worst of junk that MS Word seems to add. It does the job for me. Your milage may vary.

http://bill.herrin.us/freebies/striphtml.pl