RE: draft-narten-ipv6-3177bis-48boundary-02.txt

["Tony Hain" <alh-ietf@tndh.net>]

Thomas Narten wrote:
> FYI, draft-narten-ipv6-3177bis-48boundary-02.txt was submitted just
> prior to the ID cutoff, and the authors believe it is ready for
> publication as an RFC. We are in discussion with the ADs about having
> the document shepherded through the IESG as an informational document.
> Note that this document would formally replace RFC3177.
> 
> Comments welcome of course!

This document is not ready for publication and MUST NOT bypass the WG
consensus process. It is effectively an end run around consensus as it
suggests in the acknowledgments that it represents RIR discussions, though
fails to mention that no consensus exists. 

It purports to replace RFC 3177, but does so based on arbitrary preferences
to placate the hyper-conservation focused few rather than the considered
technical arguments in the established architectural recommendation. It does
not justify any specific changes in the math that 3177 used to highlight
that there are no technical reasons for other end site allocation units.
Instead it prefers to use hype and FUD such as 'excessive' and 'premature
depletion' without substantiation. This is despite the fact that one of the
co-authors own presentations in the referenced RIR discussions shows that
without this change current RIR practice would appropriately manage the pool
for around 500 years. This is far from 'premature', and is based on IPv4
trends which are gated on host growth rate rather than the IPv6 allocations
based on the substantially lower number of subnets. 

A specific note in the introduction argues that we need the suggested change
'for the long-term health and scalability of the public routing
infrastructure' without any reference to the impact that multiplicative
expansion and fragmenting the smaller public allocations would have. It
should be clear that by following this suggestion the potential to seriously
expand the size of and number of fragments in the public routing system far
exceeds any value that would be gained from the self stated 'more
conservative approach'. In the public RIR discussions there has not been a
clear consensus. The suggested conservation is misguided as the bits will be
wasted by replacement of the protocol which will occur for other than
depletion reasons long before we hit the 500 year mark. It uses the argument
of 'waste' by looking at the current end user deployment models rather than
recognizing that by opening up the space new deployment options become
available. This effort essentially amounts to an attempt to exercise control
over what end users are allowed to do by making them beg for each increment
of an abundant resource. 

This document argues that the goals 'could' be met in other ways, but does
not justify why they 'need' to be, or even show an assurance that they
'would' be. In fact it recognizes that renumbering subnets is still a
serious problem, then suggests in 4.1 that it is no big deal to just limit
the network topology to the assumed smaller allocation that would be the
result of this document. There is no discussion about the fragmentation that
would occur when a network outgrows its original space and would rather push
complexity into the global routing system rather than renumber. 

In section 2 it mentions that multiple prefix management is an issue,
suggesting that they all be the same length to reduce complexity, but there
is no discussion on how that would occur if providers choose arbitrary
allocation sizes. There appears to be an implied 'trust me' that it will all
work out and be possible for sites to get the same prefix lengths from
different providers. 

Also in section 2 it mentions in passing that the PTR tree is something to
consider, but does not spell out that managing that zone file across
multiple parties would be problematic and therefore recommend that forward
and reverse delegations be done on a nibble basis. It does provide more at
the very end of the summary, but still does not provide guidance on what
issues need 'adequate consideration'.

Referencing Multi6 & Shim6 seem out of place given that one produced nothing
and the other is producing something that is not deployable in real networks
where firewalls will kill the connections when the locators are changed. 

The entire effort is misguided in that 3177 is a recommendation based on
architectural balance, while this document is nothing more than ambiguous
FUD intended to shift parceling control from the end site network to the
ISP/RIR. It is presented under the guise of conservation in the routing
system simply to give cover to those that want to deviate from 3177, though
in fact it effectively balloons the routing system through fragmentation
spread over even more bits. There is no hard and fast boundary, and 3177
makes itself very clear that it is just a recommendation. If the RIRs want
to establish a different policy they can, though there is no architectural
justification for it.

RFC 3177 could use a tune-up, but it is not clear if opening the document is
worth the effort. The one thing that is clear is that this document is not a
replacement for it in any sense of the word. 

Tony