classful addressing considered harmful [was Re: Closure?]

[Brian E Carpenter]

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

It's more coherent than most of the mail on the ietf list...

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

IPv6 is intrinsically based on VLSNs with the boundaries in the TLA format
being administratively overlayed. I think that is an important difference
from classful IPv4. Also there are moveable boundaries within the fields
of the address, which give CIDR like properties. But you are correct that
there is an assumption about the topology being unflat to the extent of
having backbone operators who get a TLA, many more regional operators who 
don't, and sites that hang off the regionals. If reality doesn't look like 
that, the entropy will be worse than we hoped. 

> 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

Well, the field sizes were not chosen at random. 13 bits for the TLA = 8k
backbone operators. With 200 countries in the world, that seems a lot.

>   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)

It might, but have we seen enumerated topology scenarios to show that it might?

>   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

No, why does it need to? It's not inconsistent with 2374.

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

Only if you make "what is a backbone" into a judgement call. If we have
precise and non-discriminatory criteria we ought to avoid the lawyers.
But this certainly has to be worked out very carefully. In fact I thought
it was covered in the *existing* RIR policies on IPv6 allocation such
as http://www.ripe.net/ripe/docs/ripe-196.html .
They are written for sub-TLAs but transforming them for TLAs is
straightforward.

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

They are only administrative boundaries. BGP4 and other routing protocols
won't know anything about them. Maybe 2374 should have been a BCP not
a Draft Standard; but we certainly need the administrative boundaries
globally agreed if TLA aggregation is to have any chance. <imagine
multihoming-breaks-aggregation text here>

> 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]

Indeed. hence it's important that the TLA boundaries are administrative only
 
>   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

Indeed. Nobody should code in anything except the 64/64 boundary and one or two
of the special case format prefixes.

>   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)

Indeed. And no doubt the IPv6 boundaries will slide.
> 
> so i suggest that
> 
>   o non-technical boundaries such as tlas, ... need to be omitted from
>     standards (as opposed to practice) documents

that's an IESG debate, but you have a point IMHO. It doesn't change any
technical proposal.
> 
>   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.

not sure I can parse "this document". There is no proposal that I know
of to change RFC 2374 . draft-iesg-ipv6-addressing-recommendations-00.txt
builds on 2374, and is clearly a current practice document that only
makes sense if the RIRs agree to it.

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

Yes, although that actually places three boundaries (6+2+8) where today
we have two architecturally (8+8) with the other ones being admin.

   Brian


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