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

["Howard, Lee" <[e-mail]>]

I apologize for not continuing to ride herd on this thread since returning
from the IETF meeting.

Please, let us focus on this document in this thread.
Other IPv6 operational issues should get a different subject line.
Proposals for maintenance updates to the IPv6 protocol should go to 6man.
Proposals for fundamental changes should go to the IESG or IAB.

Lee

On 11/13/15, 12:39 PM, "v6ops on behalf of Owen DeLong"
<[e-mail] on behalf of [e-mail]> wrote:

>> 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
>
>_______________________________________________
>v6ops mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/v6ops


________________________________

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.