RE: Proposal for changing how IPv6 Hop-by-Hop Options are processed

["Xiejingrong (Jingrong)" <[e-mail]>]

Hi!
Thanks Gorry and Bob for this inspiring work !
I think the proposal of using one Option in HBH is really a perfect idea to make the HBH useful, practical, and survived.
For the worries about one HBH option limit, I think the option that expect to work nicely in HBH could/should be designed practical, compact, and also extensible.
For example, one could design the option with a basic option data part, and a flag field to indicate some "optional" parts, and the option length to include the basic part and the optional parts.
The "optional" part itself could even be some kind of sub-option-tlv of the option. 
It could even be an existing HBH Option TLV ---- directly embedded in another option to be used as the "only" HBH option of a packet.

Thanks
Jingrong

-----Original Message-----
From: ipv6 [mailto:[e-mail]] On Behalf Of Gorry Fairhurst
Sent: Friday, December 4, 2020 5:34 PM
To: Haoyu Song <[e-mail]>; Tianran Zhou <[e-mail]>; Bob Hinden <[e-mail]>; IPv6 List <[e-mail]>
Subject: Re: Proposal for changing how IPv6 Hop-by-Hop Options are processed

I see lots of thoughts - all of which might help see us through towards some conclusions.

Just on (1). Whether one HBH option si enough, might depend on the use-case.

The HBH options do not need to be set on every packet. For instance, they might be sent on packet that carries a transport-layer control payload (with no "data") to solict some feedback from the path. This might have good deployment possibilities ... because even if there is loss of such a packet because of its EH, this loss can be detected by the upper layer protocol, and it does not impact the data transmission.

A node can send multiple control such packets with different HBH options to perform different actions. That means even with only one HBH option per packet, I could still envisage performing different actions, MTU-discovery, etc.

I do expect other use cases, and we should identify and evaluate these!

On (2), I do think we can improve the wording. My own thoughts are that we need to find words that set the expectation correctly, to avoid people seeing this as just a significant DoS vector.

I hope we find support for something in the near future...

Gorry


On 04/12/2020 02:26, Haoyu Song wrote:
> I share the same concerns. In my opinion, we should only enforce that routers will not drop packets with HbH options and allow the routers to be configured to process 0, 1, or more HbH options or do it in the best effort fashion. So it basically means, packet with HbH options are guaranteed to be forwarded but the processing of the option is optional.
>
> BR,
> Haoyu
>
> -----Original Message-----
> From: ipv6 <[e-mail]> On Behalf Of Tianran Zhou
> Sent: Thursday, December 3, 2020 5:42 PM
> To: Bob Hinden <[e-mail]>; IPv6 List <[e-mail]>
> Cc: Gorry Fairhurst <[e-mail]>
> Subject: RE: Proposal for changing how IPv6 Hop-by-Hop Options are 
> processed
>
> Hi Bob,
>
> " A very short summary is that there can only be one Hop-by-Hop option in a Hop-by-Hop Option header, and that Hop-by-Hop Options must be process in the fast path."
>
> I have two concerns:
> 1. Only one option may restrict many future applications. I believe there are needs to do multiple actions with the hbh behavior. Moreover, the chip capability will improve year by year. We can predict the future the capability to deal with multiple options.
>
> 2. The HbH option "must" be processed in the fast path seems also too strict. That means HbH cannot be processed by slow path. I would like to say it "must be firstly processed in the fast path". That means this option should not be blindly sent to slow path. But it should firstly be considered in the fast path. Then several following options: fast path, slow path, by pass.
>
> Best,
> Tianran
>
>
> -----Original Message-----
> From: ipv6 [mailto:[e-mail]] On Behalf Of Bob Hinden
> Sent: Friday, December 4, 2020 7:16 AM
> To: IPv6 List <[e-mail]>
> Cc: Gorry Fairhurst <[e-mail]>; Bob Hinden 
> <[e-mail]>
> Subject: Proposal for changing how IPv6 Hop-by-Hop Options are 
> processed
>
> Hi,
>
> Gorry and I put together a draft that proposes to change how IPv6 Hop-by-Hop Options are processed.  Links to the draft below.
>
> Abstract:
>
>    This document specifies procedures for how IPv6 Hop-by-Hop options
>    are processed.  It modifies the procedures specified in the IPv6
>    Protocol Specification (RFC8200) to make processing in routers more
>    practical with the goal of making IPv6 Hop-by-Hop options useful to
>    deploy in the Internet.  When published, this document updates
>    RFC8200.
>
> A very short summary is that there can only be one Hop-by-Hop option in a Hop-by-Hop Option header, and that Hop-by-Hop Options must be process in the fast path.
>
> Please read and comment on the draft (that is, not on just this email).   We think this might make Hop-by-Hop options practical to use in the Internet.
>
> Bob & Gorry
>
>
>> Begin forwarded message:
>>
>> From: [e-mail]
>> Subject: New Version Notification for 
>> draft-hinden-6man-hbh-processing-00.txt
>> Date: December 3, 2020 at 3:04:46 PM PST
>> To: "Robert M. Hinden" <[e-mail]>, "Godred Fairhurst"
>> <[e-mail]>, "Robert Hinden" <[e-mail]>, 
>> "Gorry Fairhurst" <[e-mail]>
>>
>>
>> A new version of I-D, draft-hinden-6man-hbh-processing-00.txt
>> has been successfully submitted by Robert M. Hinden and posted to the 
>> IETF repository.
>>
>> Name:		draft-hinden-6man-hbh-processing
>> Revision:	00
>> Title:		IPv6 Hop-by-Hop Options Processing Procedures
>> Document date:	2020-12-03
>> Group:		Individual Submission
>> Pages:		11
>> URL:            https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-hinden-6man-hbh-processing-00.txt&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C2d02d0b86be0472a572208d897f5ee10%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637426429867138791%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=CUJFqmkmjLLcT0lFWZn2HVpX0Fp8BU0DN9yskwaeBas%3D&amp;reserved=0
>> Status:         https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-hinden-6man-hbh-processing%2F&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C2d02d0b86be0472a572208d897f5ee10%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637426429867138791%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=FD9nh8S1xvkoCCYAGuCXv%2FiH%2BdGNRX3IBig1BLz0QMk%3D&amp;reserved=0
>> Html:           https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-hinden-6man-hbh-processing-00.html&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C2d02d0b86be0472a572208d897f5ee10%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637426429867138791%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=TvBfaQURQuZvIMUFT59VdI4wqP8gNdQF1uGo13CC6dY%3D&amp;reserved=0
>> Htmlized:       https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-hinden-6man-hbh-processing-00&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C2d02d0b86be0472a572208d897f5ee10%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637426429867138791%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=VBUOGO%2BkrnPCPP64l4CguOTU5SIQyduVSmT%2BLOMnyOU%3D&amp;reserved=0
>>
>>
>> Abstract:
>>    This document specifies procedures for how IPv6 Hop-by-Hop options
>>    are processed.  It modifies the procedures specified in the IPv6
>>    Protocol Specification (RFC8200) to make processing in routers more
>>    practical with the goal of making IPv6 Hop-by-Hop options useful to
>>    deploy in the Internet.  When published, this document updates
>>    RFC8200.
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of 
>> submission until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>>
>>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fipv6&amp;data=04%7C01%7Chaoyu.song%40f
> uturewei.com%7C2d02d0b86be0472a572208d897f5ee10%7C0fee8ff2a3b240189c75
> 3a1d5591fedc%7C1%7C0%7C637426429867138791%7CUnknown%7CTWFpbGZsb3d8eyJW
> IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&
> amp;sdata=tWTygpRYLt56POZasHaJY50BnUgtUmOQLQlem47lZSk%3D&amp;reserved=
> 0
> --------------------------------------------------------------------


--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------