Is it that the operational *requirement* is less? Or that the current
operational *capability* is less?
It seems like, given the RFC, the requirement is not yet within the capability
of the existing backbone. Which is, at most, an argument for allowing some
additional time for the backbone to be upgraded. And (since the RFC is how
many years old by now?) not necessarily an enormous amount of additional time.
Bill Jouris
Inside Products, Inc.
www.insidethestack.com
831-659-8360
925-855-9512 (direct)
________________________________
From: Lorenzo Colitti <[email protected]>
To: Tony Hain <[email protected]>
Cc: "[email protected] WG" <[email protected]>; IETF IPv6 Mailing List
<[email protected]>
Sent: Friday, June 14, 2013 3:15 PM
Subject: Re: [v6ops] Limiting the size of the IPv6 headerchain
(draft-ietf-6man-oversized-header-chain)
On Fri, Jun 14, 2013 at 2:19 PM, Tony Hain <[email protected]> wrote:
Focus on the real operational requirement (firewall functionality), then make
sure that the constraint automatically tracks evolution in firewall
>functionality. Getting there leads to L4 in the first fragment, and anything
>else leads to artificial constraints that will need to be redone, if that is
>even possible.
>
The problem with that approach is that for a very substantial fraction of
Internet backbones, the real operational requirement is substantially *less*
capable than what is written in RFC 2460 and than what you propose here.
_______________________________________________
v6ops mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/v6ops
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
