Re: initial issues

[Thomas Narten <narten@raleigh.ibm.com>]

Things are jumping a little bit of ahead of themselves. To clarify:

Brian E Carpenter <brian@hursley.ibm.com> writes:

> Sean Doran wrote:
> ...
> > Randy noted also that
> > the IESG has asked for a revision to §2.5.6 of 
> > draft-ietf-ipngwg-addr-arch-v3-04.txt to make it classless rather
> > than clasful.  In other words, the multihoming environment for v6
> > is going to be identical to v4, viz. CIDR.   TLA/NLA will no longer exist.

> Somehow I doubt if this is a done deal in the WG.


The IESG is currently discussing
draft-ietf-ipngwg-addr-arch-v3-04.txt. The IPng WG has requested that
it be advanced to Draft Standard. During the IESG discussions, text
relating to Section 2.5.6 is being scrutinized (appended here for
your reading pleasure).

> 
> 2.5.6 Aggregatable Global Unicast Addresses
> 
>    The global aggregatable global unicast address is defined in [AGGR].
>    This address format is designed to support both the current provider
>    based aggregation and a new type of aggregation called exchange
>    providers.  The combination will allow efficient routing aggregation
>    for sites which connect directly to the current type of providers and
>    who connect to exchange providers.  Sites will have the choice to
>    connect to either type of aggregation point.
> 
>    The IPv6 aggregatable global unicast address format is as follows:
> 
>    | 3|  13 | 8 |   24   |   16   |          64 bits               |
>    +--+-----+---+--------+--------+--------------------------------+
>    |FP| TLA |RES|  NLA   |  SLA   |         Interface ID           |
>    |  | ID  |   |  ID    |  ID    |                                |
>    +--+-----+---+--------+--------+--------------------------------+
> 
>    Where
> 
>       001          Format Prefix (3 bit) for Aggregatable Global
>                    Unicast Addresses
>       TLA ID       Top-Level Aggregation Identifier
>       RES          Reserved for future use
>       NLA ID       Next-Level Aggregation Identifier
>       SLA ID       Site-Level Aggregation Identifier
>       INTERFACE ID Interface Identifier
> 
>    The contents, field sizes, and assignment rules are defined in
>    [AGGR].

The point has been made that this address format, and in particular,
the hard boundaries that are implied here, have no business being part
of the IPv6 *architecture*. That is, from the perspective of
implications for implementors, these boundaries are meaningless and
shouldn't be taken into consideration in implementations. Furthermore,
the boundaries themselves may not be correct today (or ten years from
now), so again, having them be part of a draft standard seems
inappropriate. So, one of the discussion points has been to move this
out of draft-ietf-ipngwg-addr-arch-v3-04.txt. Some other points have
been discussed, but they haven't been written up yet. I.e, this is
fast-breaking news (all in the last few days) and so hasn't made it to
the IPng list yet (or to the WG chairs, authors, ...)

Also, let's be careful about terminology here.  Calling the TLA/NLA
stuff equivalent to "classful routing" is (IMO) at best misleading and
has a tendancy to push people's hot buttons in ways that is NOT
productive or constructive, as the implication is that IPv6 is
reinventing classful routing, and hasn't learned anything from IPv4
and CIDR.

Thomas