[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IPv6 Netowrk Device Numbering BP
- Subject: IPv6 Netowrk Device Numbering BP
- From: kauer at biplane.com.au (Karl Auer)
- Date: Thu, 01 Nov 2012 17:02:08 +1100
- In-reply-to: <[email protected]>
- References: <[email protected]>
On Wed, 2012-10-31 at 22:31 -0700, Crist J. Clark wrote:
> We're working out our dual stacked IPv4-IPv6 network. One
> issue that recently has arisen is how to number the management
> interfaces on the network devices themselves.
> Is there anything like a standard, best practice for this (yet)?
Yes and no. It's only best practice when enough people have done it, and
enough people have done *different, bad* things, for the practice to
emerge as, in general, best. I don't think enough people have done
either of those things. There are documents floating about that
purporting to describe best practice; I've never read one I really
agreed with - in particular they have a tendency to recommend
overloading address bits with non-address information.
So I think you should listen to lots of people then go about making your
own educated decisions, and thus become part of the adventure of
creating best practice. Either by being a beacon of wonderfulness to us
all, or by crashing and burning so that we can say, in hushed voices as
we pass by where you and your network used to be, "don't do that :-)
> What are other people doing and their reasons? Anyone have operational
> experience with what works and what does not (and the "what does
> not" is probably really of more interest)?
I espouse four principles (there are others, but these are the biggies):
- don't overload address bits with non-addressing information
- keep the network as flat as reasonably possible
- avoid tying topology to geography
- avoid exceptions
The first can be completely avoided and should be an ironcast rule IMHO.
Aggregation requirements will mean the third is always broken
eventually, and Murphy's Law will break the fourth. However, by
following each rule as far as possible and delaying the point where it
must be broken, you will end up with a more flexible, future-proof,
error-proof, extensible address plan.
I too would be really interested in whatever wisdom others have
developed, even if (especially if!) it doesn't agree with mine.
Karl Auer (kauer at biplane.com.au)
GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687