IPv6 Netowrk Device Numbering BP

Sun Nov 4 19:26:52 UTC 2012

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
"interesting things"
     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
     always 192.168.1.1.

     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
addressing information.
It sounds like an IPv4 principle whose days are done;   that,
addressing bits are precious, so don't waste a single bit  encoding
extra information.

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
replaced ethernet.

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.
--
-JH