failing over better with multiple prefixes?

[Benedikt Stockebrand]

Hi Dave and list,

Dave Taht <d at teklibre.org> writes:

> I can see Costa Rica (about 18 km) but word has it that the Net sucks
> even harder over there. Am still thinking that running a wireless link
> over to there would make sense...

if you have somebody to peer with over there, give it a try.  If
nothing else, it should give you some independence from domestic
carriers.

> So (after about a year of using it down here) 6to4 tends to be more
> reliable, faster, and lower latency on the whole than using tunnels,
> due to the accumulated MTBF of the other 20+ routers between me and
> hurricane.

Ok, that's a point for now.  As soon as you find a tunnel provider
more close to you I'd still recommend to drop 6ot4.

> I recently read of a deployment using 6RD (and just started building
> that into my kernels) which looked like an encouraging adaptation of
> 6to4 tech...

6RD only provides you with a single subnet per IPv4 address, so for
setups I'd consider "normal" (from the first world perspective) it
doesn't get you very far.

> Aside: What does it take to own an operate a 6to4 router?

Check RFC 3068 for some operational requirements.  It basically boils
down to this: If you screw up and don't remove the IPv4 anycast
address (192.88.99.1/24) from your BGP, you may cause lots of trouble
to all sorts of people.  There are a number of security precautions
you are expected to take.  And of course you need an AS to advertise
the anycast address...

Setting up a private relay router (not using the anycast address) is
fairly straightforward.

>>   Once you have native IPv6
>> connectivity and a cooperative provider
> I may well be old and gray before that happens. Most providers down
> here stick people behind at least one layer of NAT, sometimes two or
> three. I'm pretty sure this is the case throughout the third world and
> asia.

Actually, since the pain is worse than elsewhere there's quite a
chance that people will actually do something about it sooner than
over here.

> It really sounds like I have to bite the bullet and become my own ISP.

Good luck.  But then, if the competition is clueless, doing so may
well be worth it.

> Anyway, getting a real, independent IPv6 address space and a AS number
> would hopefully let me egress/ingres from the multiple points where I
> have control of the IPv4 address, but no, it doesn't solve all
> problems.

Don't forget you need peering partners, too.  If you don't find any
decent ones, you are no better off than before.

>> First of all, unless the situation in your setup is way beyond what
>> I'd consider reasonably reliable, you can normally limit yourself to
>> two or three addresses.
>>
> It's way beyond what I'd consider reasonably reliable. Power outages
> last 8 hrs to 3 days, power flickers on and off 5-10 times a day, we
> have persistently low voltage (<95v) which wrecks UPSes, and a horde
> of other problems.

Ok, I didn't know the situation was that bad in Nicaragua.  I've seen
some situations when travelling in "real" Africa a few years ago and
thought you couldn't really beat that (except in parts of
California:-).

As far as the UPSes and damage due to flaky power go, I heard
something along the lines in Malawi or Zambia, either from an
hydrology engineer or a Medecins Sans Frontiere doctor.  If you get a
chance, see if you can find some higher quality equipment for the
non-IT market, like for medical equipment or such.  Apparently this
stuff isn't as expensive as it sounds.

Depending on your business you might even consider running your own
diesel generator on a permanent basis during business hours.

> It is a dramatic contrast to how everything else is getting done "in
> the cloud" these days. It's so dark I can't even see the cloud...

The good news is that the Internet was originally designed for even
worse conditions during the Cold War.  I remember those Internet cafes
in Africa some years ago.  They worked fairly well compared to just
about anything else.

And you don't have people who rely so heavily on Internet connectivity
(or electricity, or tap water, or whatever) that any 30 second
downtime causes weeks of cleaning up the damage.

>> As far as the DNS issue goes: That's what scripts are there for.
>>
>>
> Well, it would be nice if I knew how to detect deprecated addresses on
> the client side on either windows or linux without polling.

Can't you do it centrally as soon as you switch to the fallback
radvd.conf?

>> It's always good when everything is working -- the headaches come from
>> not thinking in time about how to keep it that way:-)
>>
>>
> Staying in the US - or better, moving to Europe - might have been a
> good idea.

Well, we have our share of problems in Europe as well.  And as far as
reliable electricity is concerned, the US seems to have their's, too.

>> You can't really do that on the routers.  Check RFC 3484 for the
>> details on how address selection works.  Unfortunately, at least last
>> time I checked Linux didn't have a configurable address selection
>> table -- but then, you'd have to do this on the hosts as well, so it
>> is pretty much out of an option.
>>
> I'm not really sure what you mean here.  libc has a rule database for
> address selection built into it, am not sure about uclibc....

Last time I checked this table was configurable with Solaris and the
BSDs but not Linux.  Maybe they have fixed that since, but in most
situation I consider "normal" there's little use in tweaking it
anyway.

> My thought was I would (in case of failure of a given prefix) block
> outgoing source addresses from that prefix at the local router and
> return the correct ICMPv6 unreachable message (not sure what that is).
>
> The clients would then cycle through their other source addresses
> rapidly until it finds one that works.

Unfortunately, as far as I know you can't do that with the source
address, only with the destination address.

Applications that are properly written cycle through all records found
in a DNS reply for destination addresses, but for every destination
address only a single source address is tried.

In some cases this may still work, because one of the criteria used is
"longest shared prefix" between a destination address and the
candidate source addresses.  Check RFC 3484, it does have the details.

>> I'd actually rather avoid using any Linux- or whatever-specific stuff
>> for this.
>>
> Got an alternate suggestion? I think highly of BSD but it doesn't run
> on either my wireless router or "smart server" of choice...

No, but I've seen what happens if you do this sort of thing.  Three
years from now, recent versions of Linux don't support your hacks any
more and the old version you use has a remotely exploitable security
hole, or doesn't run on the hardware that's still available to the
market, or whatever.

> That's another reason why you don't want to use multiple tunnels
> either, or anything short of a BGP mediated internet
> connection. Multihoming is actually something that NAT is useful
> for....

So are proxies.  Can you set up proxies for all protocols you need, or
is that infeasible?

>> Yes, just set the preferred lifetime to 0.
>>
> I was under the impression that lifetimes of less than 7200 secs were
> problematic. I'll try it!

You can't set the valid lifetime in a router advertisement to 7200
without prior "countdown", but it's ok to set the preferred lifetime.

> No, well, I'd like it very much if radvd went away and what it did got
> integrated into Xorp or some more complete routing solution.

You can do the router advertisement stuff with Quagga, but I'm not
entirely sure if that helped that much.

> as I wrote earlier whatsmyip is unreliable, so tunneling that way
> tends to be error prone.

Ok, I've used Hexago some years ago and didn't find any problems then,
but NAT is simply something you want to avoid whenever possible.

> aiccu? some other tunneling mechanism? One thought I had is that I
> have control of several machines in the states that have native ipv6
> connectivity and can also run 6to4. I don't have control of the native
> ipv6 stuff (/64s) so am limited to delegating my own 2002 from there
> here....
> [snip]

Yes, setting up your own private 6to4 relay is definitely helpful.
More generally, being in control of both tunnel ends makes life
significantly easier.

If you have any chance at all of setting up a shorter prefix than /64
on one of those machines, consider using configured tunnels to it
instead.


Cheers,

    Ben

-- 
			 Business Grade IPv6
		    Consulting, Training, Projects

Dipl. Inform.                 Tel.:  +49 (0) 69 - 247 512 362
Benedikt Stockebrand          Mobil: +49 (0) 177 - 41 73 985           
Fichardstr. 38                Mail:  me at benedikt-stockebrand.de        
D-60322 Frankfurt am Main     WWW:   http://www.benedikt-stockebrand.de/

Bitte kein Spam, keine unaufgeforderten Werbeanrufe, keine telefonischen
Umfragen.  Anrufe werden ggf. zu rechtlichen Zwecken aufgezeichnet.  
No spam, no unsolicited sales calls, no telephone surveys, please. Calls
may be recorded for legal purposes.