classful addressing considered harmful [was Re: Closure?]

[Randy Bush]

[ please excuse the roughness and sloppiness of this.  i am at the end of
  weeks on the road, and utterly jet slagged ]

> Just to clarify the above point. I believe it is a misunderstanding of
> the intent of the various IPv6 addressing documents to compare them
> with classful addressing.

the scheme in 2374 sec 3.1 seems to segment the address space with [TNS]LA
boundaries based on lightly specified socio-political theories of how much
space different kinds of entities will need.  to many of us crass and
under-educated operators, this does not appear to be much different than
the classic and classful A, B, and C design.

this whole subject we have been discussing seems to say

  o we don't really know what those boundaries should be today, but are
    trying to make a stab at it in the practices document under discussion

  o the current /35 suggested isp allocation is not even in the 'addressing
    architecture' and seems too lightly treated in the document under
    discussion.  yet it is of critical interest to the ops community (and
    many suspect it needs adjusting)

  o the size to be given by iana to rirs has not even been described.  the
    /29 being discussed does not map to any of the boundaries in 2374

  o many folk strongly suspect that the tla-for-global-isp idea is lawyer
    chum

> The only firm boundaries within addresses that have been defined by the
> architecture are the 64/64 split (routing part and interface identifier).

huh?  so 2374 sec 3.1 and its proposed update are not firm, yet it is going
for draft status?  i am more confused than usual.  allow me to quote

   "Top-Level Aggregation Identifiers (TLA ID) are the top level in the
   routing hierarchy.  Default-free routers must have a routing table
   entry for every active TLA ID ..."

this would seem to take a poorly-substantiated socio-political theory and
mandate its enshrinement in the core of v6 routing.  while we ops folk
appreciate that it is kindly trying to reduce route explosion, doing so on
a fixed boundary for a routing protocol we hope will last more than the two
decades of ipv4 seems, shall we say, optimistic.

some relevant lessons we might take from v4 are

  o i suspect that the folk who did A, B, and C thought they would be
    useful and expected them to last forever.  it seems they may have had a
    social view of network addressing topology [0]

  o fixed unicast boundaries became a serious problem, yet people had coded
    them in software and protocols (e.g. RIPv1), and we have regretted it
    sorely

  o the only useful boundary was that between uni- and multi-cast, i.e. one
    where protocols must treat things very differently

  o the soft socio-political allocation boundaries move in time, from /18
    (pre danvers), to /19 (on a widespread consensus), and recently /20 (by
    arin's unilateral act)

so i suggest that

  o non-technical boundaries such as tlas, ... need to be omitted from
    standards (as opposed to practice) documents

  o this document, the allocation best current practice description, should
    be the main place we describe these socio-political boundaries.  and we
    appreciate the word 'current' in this context.

  o gse/8+8 is the type of thing for which we should place boundaries in
    standards

randy

---

[0] rfc791 is the first i found with a, b, and c.  it says

    "To provide for flexibility in assigning address to networks and
    allow for the  large number of small to intermediate sized networks
    the interpretation of the address field is coded to specify a small
    number of networks with a large number of host, a moderate number of
    networks with a moderate number of hosts, and a large number of
    networks with a small number of hosts.  In addition there is an
    escape code for extended addressing mode."

    some earlier documents are instructive

    ien-111 and 115 had only what we think of as A addressing, 8/24
    ien-122 mapped hardware issues
    ien-162 used the second octet to add hierarchy
    ien-170 and 171 tried to deal with the hardware hierarchy
    rfc760 still had only 8/24

-30-