Re: [Spud] endpoint control

["Smith, Kevin, (R&D) Vodafone Group" <[e-mail]>]

Thanks for the pointers Tom and Joe - good to see more direction on HBH. I hold to my initial point for practical reasons: PLUS is a worthy research option until HBH options are respected properly, and (more importantly) operators can support HBH via IPv6 adoption.

All best,
Kevin

PS Tom's HBH thread for reference: https://www.ietf.org/mail-archive/web/ipv6/current/msg24729.html 


-----Original Message-----
From: Tom Herbert [mailto:[e-mail]] 
Sent: 30 June 2016 01:33
To: Joe Touch
Cc: Smith, Kevin, (R&D) Vodafone Group; Brian Trammell ([e-mail]); [e-mail]
Subject: Re: [Spud] endpoint control

On Wed, Jun 29, 2016 at 5:04 PM, Joe Touch <[e-mail]> wrote:
>
>
> On 6/29/2016 4:26 PM, Tom Herbert wrote:
>> ...
>> Probably down to forwarding performance too, as Hop-by-Hop must be processed by all network devices. And deployability as you say; because IPv6 is unfortunately not prevalent yet in mobile core networks...
>>
>> The first problem is being relaxed in 2460bis draft. It allows HBH to 
>> be ignored by network devices, which should cover the case where 
>> there are "too many options to parse" in a DOS attack.
>
> That doc recognizes that many devices do this, not that this is OK.
>
Here is the wording that I believed was agreed on in 6man for next version of the 2460bis draft:

"NOTE: While RFC2460 required that all nodes must process the Hop-by-Hop Options header, it is now expected that nodes only process the Hop-by-Hop Options header if explicitly configured to do so. Nodes that do not process or examine the Hop-by-Hop Options header must ignore it, and it must be passed on unchanged if forwarded."

As I understand it, the use of "expected" here instead of "SHOULD" or "MAY" is necessary since 2460 is being proposed to become a full standard and the protocol behavior can't change in that process. But for all practical purposes this allows nodes to ignore HBH. Without this allowance HBH would never be deployable.

Tom