Addressing plan exercise for our IPv6 course

Sat Jul 24 16:23:06 UTC 2010

On Sat, 2010-07-24 at 08:50 -0700, Matthew Kaufman wrote:
> Even if all your hosts end up with external connectivity that works, the odds 
> that they can reliably talk to each other is low.

I hope I'm not taking the above quote out of context, but why do you
think this? How does the fact that interfaces on your host may have more
than one public address translate into low odds that they can talk to
each other?

The only thing I can think of is that if an interface in your network
has a public address from only one provider, and another interface in
your network has a public address only from another provider, then the
connection will go out through one provider and back in from the other,
which would be less than optimal. On the other hand, there is no reason
to think this would be particularly unreliable, and if such a situation
existed it would either indicate a fault or be what you actually wanted.

The discussion was in the context of a renumbering exercise. Using the
simple method of having a period where both provider ranges are active
and allowing the old provider range to "time out" may result in lost
connections; there may also be caching difficulties with some
applications. Neither situation is long-lived, and both can be mitigated
by careful planning. Is that what you meant?

Maybe I've missed your point.

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer at biplane.com.au)                   +61-2-64957160 (h)
http://www.biplane.com.au/~kauer/                  +61-428-957160 (mob)

GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156
Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20100725/4ed1e864/attachment.sig>