[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IPv6 Netowrk Device Numbering BP
On 11/1/12, Karl Auer <kauer at biplane.com.au> wrote:
> I espouse four principles (there are others, but these are the biggies):
Sounds like what is suggested is anti-practices, rather than
suggesting affirmative practices.
I would suggest slightly differently.
Complexity results in failure modes that are difficult to predict, so
- Keep addressing design as simple as possible, with as few
or distinctions as possible,
(such as multiple different prefix lengths for different nets,
different autoconfig methods,
different host IDs for default gateways, unique numbering
schemes, for different
network or host types, etc)
Without omitting requirements,
or overall opportunities for efficient reliable network operations.
- Keep addressing complexity in addressing.
E.g. Addressing may be simpler with a flat network, but don't
use that as an excuse to relocate 2x the cost of addressing
complexity to switching
infrastructure/routing design and scalability limits that will
forseeably be reached.
Don't implement carrier grade NAT, just because it ensures the
user's default gateway is
Ensure the simplicity and benefits of the whole is maximized, not
the individual design elements.
> - don't overload address bits with non-addressing information
You suggest building networks with address bits that contain only
It sounds like an IPv4 principle whose days are done; that,
addressing bits are precious, so don't waste a single bit encoding
If encoding additional information can provide something worthwhile,
then it should be considered. I'm not sure what exactly would be
worthwhile to encode, but something such as a POP#, Serving router,
Label/Tag id, Security level, type of network, hash of a circuit
ID, might be some potential contenders for some network operators
to encode in portions of the network ID for some networks.
Specifically P-t-P networks, to which a /48 end site numbered
differently may be routed.
> - keep the network as flat as reasonably possible
You are suggesting the avoidance of multiple networks, preferring instead
large single IP subnets for large areas, whenever possible? IPv6 has not
Bottlenecks such as unknown unicast flooding, broadcast domain chatter,
scalability limits still exist on IPv6oE.
Ample subnet IDs are available. With IPv6, there are more reasons than ever
to avoid flat networks, even in cases where a flat network might be an option.
My suggestion would be:
- Avoid flat networks; implement segmentation. Make new subnets;
whenever possible plus reliability, security, and serviceability
gains exceed the basic config, and continuous management costs.
Make flat networks when the benefits are limited, or segmented
networks are not possible, or too expensive due to poorly designed
hardware/software (E.g. software requiring a flat network between
devices that should be segmented).
> - avoid tying topology to geography
It sounds like IPv4 thinking again --- avoid creating additional
topology for geographic
locations, in order to conserve address space.
> - avoid exceptions
Consistency is something good designs should strive for;
when it can be achieved without major risks, costs, or
technical sacrifices, exceeding the value of that consistency.
> I too would be really interested in whatever wisdom others have
> developed, even if (especially if!) it doesn't agree with mine.
> Regards, K.