On 13/06/2013 10:06, Joe Touch wrote:
>
>
> On 6/12/2013 2:44 PM, Jeroen Massar wrote:
>> Unless the router in question knows what that HBH header will do (read:
>> it was implemented when the definition of that header was defined) or
>> what it should do with it, it won't be able to do anything with it
>> anyway. Thus just ignoring/skipping it, heck not parsing any headers at
>> all, will be quite fine...
>
> The only valid way to ignore the HBH header is when all its component
> options are "00" - skip option if not supported.
>
> If you don't check that, then you don't know whether it's valid to
> ignore the options. That would interfere with the semantics of options
> defined as "discard" or "discard and inform".
Reality check: high speed routers don't look at HbH options.
Your best hope is that they throw them on a slow path, but not
all designs have a slow path.
If you are designing a HbH option, you'd better assume that
some routers will ignore it.
On 13/06/2013 10:21, Ray Hunter wrote:
>> I think we should advocate 256 as a target for hardware designers; we know
>> that
>> > some of them have current hardware limits less than that, but a "SHOULD
>> > inspect 256"
>> > seems reasonable (and conversely, a "SHOULD NOT exceed 256" for hosts
>> > generating
>> > IPv6 packets).
>> >
>> > Given time (as somebody said, maybe ten years) this would palliate the
>> > problem.
>> >
>> > Brian
>
>
> Whilst I agree we need to take steps to simplify the problem, I'd like
> some feedback from hardware manufacturers either publicly or privately
> whether this limit is sufficient on its own.
I'm pretty sure that it isn't; it's a starting point for digging out
of the hole, because it bounds one aspect of the problem.
Brian (cross-posting with reluctance)
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
