Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain)

On 11/06/2013 15:44, cb.list6 wrote:
> On Jun 10, 2013 8:34 PM, "Brian E Carpenter" <brian.e.carpenter@gmail.com>
> wrote:
>> On 11/06/2013 15:21, cb.list6 wrote:
>>> On Jun 10, 2013 7:23 PM, "Fernando Gont" <fgont@si6networks.com> wrote:
>>>> Folks,
>>>>
>>>> We're currently editing the aforementioned I-D. So far, the I-D just
>>>> required that the entire IPv6 header chain be present in the first
>>> fragment.
>>>> Based on recent/ongoing discussions on the 6man and v6ops lists, there
>>>> seems to be quite a few folks pushing the idea of limiting the size f
>>>> the IPv6 header chain to some value (typically in the order of a few
>>>> hundred bytes).
>>>>
>>>> An earlier version of draft-ietf-6man-oversized-header-chain limited
> the
>>>> header chain to 1280 bytes, but this requirement was later removed.
>>>>
>>>> However, since then a number of folks have produced real world data
>>>> which indicates that packets "won't make it to the destination node" if
>>>> the header chain is larger than a few hundred bytes, and I believe
> that,
>>>> overall, our understanding of the problem and situation has increased
>>>> since then.
>>>>
>>>> My question to th wg is:
>>>>
>>>> 1) Do we want to limit the size of the IPv6 header chain?
>>>>
>>>> 2) If so, which limit should we pick?
>>>>
>>> It's not the size, it is how you use it.
>>>
>>> I would suggest "common types" be permitted (tcp, udp, sctp, icmpv6,
> frag,
>>> esp, ah) while anything else must be behind an esp. This ensures all
>>> parties agree that further arbitrary headers will only be processed by
> the
>>> concenting end systems.
>> Truly, you won't get consensus for that; it isn't realistic. I think we're
>> already very near consensus on an unconstrained limit in the 128/256
>> area.
>>
>>     Brian
>>
> 
> Concenus from who? Ghosts of protocols past? Or what one fellow calls the
> "ipv6 priesthood" Is this yet another RA vs DHCPv6 disconnect?

No, from the discussion on these two lists in the last
week or so.
> 
> But what does 128/256 mean to a network operator? Load balancer or fw or
> router vendor?

It means the size that leading-edge hw can inspect at line speed,
from what a number of operators have been saying.

> 
> I believe meaningful guidance must be provided in terms of permutations
> that can be expressed in what the common folk call an "access list".

That's a second level issue and it isn't future-proof. It may well be
useful to document reasonable and unreasonable combinations of
extension headers, in terms of expectations of what firewalls might
be looking for, but there's no one-size-fits-all answer, especially
when you include extensions that haven't been invented yet.

> 
> Simply saying that there can be arbitrary chaining of x bytes long does not
> benefit anyone in a practical way, afaik.

IMHO it does; for a start it makes it clear that (say) 257 bytes of
headers have a vanishingly small chance of getting through the
network, and that's much more guidance than we give today. And it
gives hardware designers a target that seems to relate to reality.

    Brian
> 
> CB
> 
>>> CB
>>>> Thanks!
>>>>
>>>> Best regards,
>>>> --
>>>> Fernando Gont
>>>> SI6 Networks
>>>> e-mail: fgont@si6networks.com
>>>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>>>>
>>>>
>>>>
>>>>
>>>> --------------------------------------------------------------------
>>>> IETF IPv6 working group mailing list
>>>> ipv6@ietf.org
>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>> --------------------------------------------------------------------
>>>
>>> ------------------------------------------------------------------------
>>>
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> ipv6@ietf.org
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
> 