Re: 3177-bis

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

Tony,

I'd really welcome your feedback on how to make the document
better. But to be blunt, I am having difficulty extracting the
substantive content to apply to the document.

> The fundamental goal of this draft is just misguided.

As Brian says, please be clear. The goal of this draft is to make
clear that /48 is not a technical/architecural requirement and that the
concerns/motivations that led to the original recommendation of /48
can be met with end site assignments other than "/48 for everyone". If
you disagree with this, please elaborate.

> It is essentially trying to get the IETF to revisit history &
> restate the IAB's recommendation, in order to align it with the
> persistently short-sighted policies of the RIR's.

Revisit history? Come on. By that logic, we can't revise any document
that has been made into an RFC, since that would revisit history.

3177 was written some 8 years ago. Some of what it says needs
updating. Also, the consensus for the 3177 recommendations was what I
would call "rough", even back then. Case in point, I supported it. But
I now view /48 for everyone to be unnecssary and inappropriate.

> Due to their core objectives, the RIR's are incapable of supporting
> innovation and looking to the future because they are focused on the
> past, as their measures of 'fairness' are based on historical
> measures of efficient deployment of technologies and networking
> models from the last century.  The call for 'reasonable' is a prime
> example of how quickly this will fail, because perceptions of
> 'reason' that are based on the past will never accommodate future
> innovation.

This seems like nonsense to me. To say that the RIR's idea of fairness
is based on "historical measures" seems to ignore the vastly different
RIR policies currently in place for IPv6 vs. IPv4. There is literally
no comparison between the two, in terms of how much address space one
gets under IPv6 per current RIR policies.

> There is no math justifying the assertion that a /56 actually solves the
> collective set of goals. In particular, the scare tactic reference
> [ROUTE-SCALING] has no substantiating documentation, and even cursory
> thought about the problem would expose the point that moving bits from local
> to global routing will only make any scaling concerns worse.

The reference to [ROUTE-SCALING] is in the intro and is associated
with the sentence:

   There are a number of considerations that factor into address
   assignment policies. For example, to provide for the long-term health
   and scalability of the public routing infrastructure, it is important
   that addresses aggregate well [ROUTE-SCALING].

Are you saying that the sentence is false? Surely you are not going to
argue that aggregation isn't important. But more to the point, this
sentence is general background (and a true statement) and isn't
intended to (or actually used to) justify any other part of the
document. So I really don't get why you bring this up.

Also, moving bits from the left to the right does NOT automatically
make aggregation worse, as I indicated in another posting recently.
There are a number of other factors that come into play that are also
important. Aggregation is about the number of distinct prefixes that
the routing system must carry. The size of an individual prefix is
irrelevant. It's just the total number of prefixes that matter.
   
> The arguments at the mic today about fragmentation due to having to
> get additional space are an artifact of RIR policy, and no matter
> what size the IAB/IETF recommends, the RIR policies will insist on
> small periodic blocks for 'efficiency' (read that as power to say
> no), which will result in fragmentation over time.

I agree that RIR policy has a big impact on aggragation over time. But
that is not something this document can address, so I don't think this
has any impact on this document. (At least, not that I can tell.)

In any case, I'm optimistic that RIR policies can be made better to
address the aggregation problem, if that turns out to be a problem in
practice. 

> The other argument at the mic today about needing something longer
> than a /48 to avoid RIR policy to register assignments in whois,
> completely misses the point that it is the RIR policy that has
> failed, not the recommended size. For example, a policy that said
> 'any deaggregate which results in an explicit DFZ table entry is
> required to have a whois registration', would make much more sense
> than one that assumes all units of the same size have the same
> policy. There is no reason that end site assignments that are
> aggregated into the DFZ would need their own whois entry, but rather
> than fixing RIR policy, there is an expectation that the IETF/IAB
> should change to accommodate their unwillingness to act.

I agree that this argument is orthogonal to the end site assignment
size and out of scope for this document.

> The half-hearted discussion about bridging possibly not being desired,
> completely glosses over the point that time after time it has been shown
> that bridging between media types is prone to failure, and that there will
> be new media types that emerge during the lifetime of IPv6. Given the uproar
> over a past technology that only allowed a single cell to consume 10
> microseconds of link time, and that for the 100Gbps link Comcast used this
> week a full-sized Ethernet frame only consumes 120 nanoseconds of link time,
> we are already past due for a new framing technology. Whatever it is, there
> will be routed rather than bridged interconnection of those. (never mind
> that the IETF is supposed to be focused on L3 approaches, not promoting
> bridging of a 30 year old L2 one)

The key point for this document is that we shouldn't force bridging on
anyone. The document says that. I.e., it says:


     Although a /64 can (in theory) address an almost unlimited number
        of devices, sites should be given sufficient address space to be
        able to lay out subnets as appropriate, and not be forced to use
        address conservation techniques such as using bridging. Whether
        or not bridging is an appropriate choice is an end site
        matter.
	
I don't think we need to spend a lot of time arguing about what will
or will not happen with frame formats over the next ten years.

The current text was based on a list suggestion. I am willing to make
it stronger. Going back to
http://www.ops.ietf.org/lists/v6ops/v6ops.2008/msg00357.html, I'm
willing to add something like:

    In some cases, bridging is not an available alternative to routing
    or subnetting, as it requires a significant level of compatibility
    between the link layer technologies being bridged. For example, it
    is not possible to bridge between Ethernet and Bluetooth.)
	
(And FWIW, I think we are going to be stuck with Ethernet frame format
essentially forever, because the incremental improvement of other
formats simply aren't enough to get past the ease of interoperating
with a very well-established frame format.)

> The discussion about paying fees to get additional space is probably
> inappropriate, because it presumes that the IETF knows this is a bad
> business practice.

I am willing to take this out, but only reluctantly. I put it in to
counter the myth that ISPs charge for extra addresses because they
have to (i.e, because they are just passing along the cost of getting
addresses from RIRs.)  It is a myth that is widely
repeated. Unfortunately, the argument comes up when people voice
opposition to changing the end site assignment. Hence, I think it is
important to include it.

> The real goal here is to note that justifications on the past are
> irrelevant and can't be assessed appropriately when talking about
> future deployment needs. There are 281,474,976,710,656 /48's (minus
> special use prefixes), so claims that we will run out are
> absurd. The fact that the RIRs started out applying a host measure
> to what is a subnet assignment reality does not mean that the IAB
> was wrong. What it means is that people need to use real math
> justifications to back up their claims, not just vague notions of a
> problem that will never exist.

The RIRs are well past measuring "host utilization" for IPv6, and have
been for 6+ years. So I don't get why you bring this up.

Thomas