On Sun, 2012-11-04 at 13:26 -0600, Jimmy Hess wrote:
On 11/1/12, Karl Auer <kauer@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 address space. 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. Regards, K. PS: I've put a lot of this, word for word, in my blog at www.biplane.com.au/blog -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687