[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IPv6 Netowrk Device Numbering BP
On Sun, 2012-11-04 at 13:26 -0600, Jimmy Hess wrote:
> 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.
I agree that positive is best, but my rules can be expressed in a few
phrases. There is value in being concise.
> 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.
Address bits are not precious; subnetting bits are. We have moved, with
IPv6, from conserving address space to conserving subnet space. Your
address space in a leaf subnet numbers in the billions of billions; your
subnetting space in a typical /48 site numbers in the tens of thousands.
By the way, there are two very diffferent kinds of subnet - the leaf
subnet that actually contains hosts, and the structural subnet that
divides your network up. I'm talking about structural subnetting.
> If encoding additional information can provide something worthwhile,
> then it should be considered.
Of course. But *as a rule* it should not be done. Only you can weigh the
benefits against the downsides. Remember I said these were rules for
students; I'm not going to tell a competent professional what to do. I
personally would however strenuously avoid overloading address bits
merely for the sake of human convenience or readability.
Systems with no necessary technical links inevitably diverge; if you
have encoded one in the other, the latter will eventually start lying to
you. You will have to work to keep the two things in sync, but if they
diverge enough that may not be possible, and you end up with one system
containing the irrelevant, misleading remnants of another.
> > - 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?
No, that's not what I'm suggesting. See above for the distinction I make
between leaf and structural subnets. I am suggesting keeping the network
structure as flat as possible.
> - Avoid flat networks; implement segmentation.
Yes at the edge, no in the network structure.
> > - avoid tying topology to geography
> It sounds like IPv4 thinking again --- avoid creating additional
> topology for geographic locations, in order to conserve address space.
Conserving address space is NOT one of my goals, though conserving
subnet space is. Without being foolishly parsimonious, though. As you
say, there is ample subnet space, but it's not nearly as ample as
I use "geography" in the broadest sense of "the physical world". The
reason for avoiding tying your network topology to geography is that
networks move and flex all the time. So does the physical world, in a
way - companies buy extra buildings, occupy more floors, open new state
branches, move to new buildings with different floor plans. New
administrative divisions arise, old ones disappear, divisions merge.
Building your topology on these shifting sands means that every time
they change, either your address schema moves further away from reality,
or you spend time adjusting it to the new reality. If you chose poorly
at the start, it may not be possible to adjust it easily. Again, I can't
second guess what physical constructs you will want or need to mirror in
your network topology, but I can say with confidence that you should
avoid doing so unless absolutely technically necessary.
These rules are not really IPv6-specific. It's just that in the IPv4
world, we basically can't follow them, because the technical
requirements of the cramped address space drive us towards particular,
unavoidable solutions. With IPv6, the rules gain new currency because we
*can* mostly follow them.
PS: I've put a lot of this, word for word, in my blog at
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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 230 bytes
Desc: This is a digitally signed message part