Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon?

[Owen DeLong <[e-mail]>]

> I'm sure we can design routers that can handle 10x the prefixes they can today, but at what cost?
> 
> Also, why should a core router in Europe have to care about an office connection being affected by something on the other side of the globe? IP has become successful because the core doesn't have to keep state for L4 connections, but if we radically increase the state needed to be kept for L3 destinations, we will most likely run into problems. Yes, they might be solved, but currently we do not know how.
> 
> So I would very much like to stay away from an architecture that suggests "PI for everybody".

The alternative perspective is that because we’ve been able to avoid this issue by treating most of the internet users as second-class citizens, we have chosen not to put resources into solving it.

Perhaps it is time to stop treating internet users as second-class citizens and actually put resources into solving this problem in a meaningful way.

It is truly unfortunate that the IETF deliberately punted on this issue during the development of IPv6. I believe this decision was driven by a number of the larger ISPs of the day (carriers) pushing to maintain CIDR as a mechanism of customer lock-in and exacerbated by sheer laziness from others.

I believe that an extra 32-bit field in the IPv6 header could have provided a significant step towards solving this problem by encoding the destination transit AS in the packet at the first router capable of resolving that information and then routing on that basis in the IDR realm. In that case, stub networks (non-transit autonomous systems) would not need to be visible in BGP and we would not need to track prefix state beyond the closest transit ASNs. A separate map of Prefix->Candidate Transit ASNs could be maintained through a mechanism somewhat similar to DNS.

Unfortunately, we don’t have the bits to do this in the IPv6 header and the solution will now be harder.

Owen