Apple Airport Extreme IPv6 problems?

Mon Sep 17 23:45:51 UTC 2007

Valdis.Kletnieks at vt.edu wrote:
> On Mon, 17 Sep 2007 17:15:38 EDT, John Curran said:
> 
>>    In addition, if the AAAA record is added for the node, instead of
>>    service as recommended, all the services of the node should be IPv6-
>>    enabled prior to adding the resource record.  "
>>
>> Not a problem for names which are single services (www.foo.com),
>> but caution is required when the name has multiple services running.
> 
> My favorite shoot-self-in-foot on that topic - I stuck a quad-A in for a host
> that *was* IPv6-enabled on the production service, but it didn't have (at the
> time) an IPv6-ready ssh daemon.  Hilarity ensued when using an IPv6-enabled
> ssh client - you'd get back an RST packet real fast and it was Game Over.
> 
> So remember - there's probably more services you need to worry about. ;)

Indeed, which is why a good policy to have for 'servers' is to have:
 - a hostname, generally I bind these to the EUI-64 address
 - a servicename, eg 'www' or 'imap', which are bound to ::80 and ::993

Then when the box dies or you want to move the service to another box,
you just move the alias, or actually just kill the quagga on the box and
let another instance handle it ;) Still the maintainance of the box can
be done by directly accessing it. Of course one should simply have that
all integrated into the service deployment system and not care about the
boxes themselves, you just want <n> of them to provide service X and <m>
of them to handle service Z, or to use as many of them so that service Y
is running topnotch with capacity to spare. All depends on your size of
course ;)

Greets,
 Jeroen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 311 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20070918/5794fb59/attachment.sig>