[prev in list] [next in list] [prev in thread] [next in thread]
List: ipng
Subject: RE: Proposal for changing how IPv6 Hop-by-Hop Options are processed
From: "Xiejingrong (Jingrong)" <xiejingrong () huawei ! com>
Date: 2020-12-15 3:40:14
Message-ID: 266f9acdddc14976a477c19b10daaabe () huawei ! com
[Download RAW message or body]
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:ipv6-bounces@ietf.org] On Behalf Of Gorry Fairhurst
Sent: Friday, December 4, 2020 5:34 PM
To: Haoyu Song <haoyu.song@futurewei.com>; Tianran Zhou <zhoutianran@huawei.com>; Bob \
Hinden <bob.hinden@gmail.com>; IPv6 List <ipv6@ietf.org>
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 <ipv6-bounces@ietf.org> On Behalf Of Tianran Zhou
> Sent: Thursday, December 3, 2020 5:42 PM
> To: Bob Hinden <bob.hinden@gmail.com>; IPv6 List <ipv6@ietf.org>
> Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
> 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:ipv6-bounces@ietf.org] On Behalf Of Bob Hinden
> Sent: Friday, December 4, 2020 7:16 AM
> To: IPv6 List <ipv6@ietf.org>
> Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>; Bob Hinden
> <bob.hinden@gmail.com>
> 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: internet-drafts@ietf.org
> > 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" <bob.hinden@gmail.com>, "Godred Fairhurst"
> > <gorry@erg.abdn.ac.uk>, "Robert Hinden" <bob.hinden@gmail.com>,
> > "Gorry Fairhurst" <gorry@erg.abdn.ac.uk>
> >
> >
> > 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%2F \
> > www.ietf.org%2Farchive%2Fid%2Fdraft-hinden-6man-hbh-processing-00.txt&data=04% \
> > 7C01%7Chaoyu.song%40futurewei.com%7C2d02d0b86be0472a572208d897f5ee10%7C0fee8ff2a3b \
> > 240189c753a1d5591fedc%7C1%7C0%7C637426429867138791%7CUnknown%7CTWFpbGZsb3d8eyJWIjo \
> > iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CUJFqmkmjLLcT0lFWZn2HVpX0Fp8BU0DN9yskwaeBas%3D&reserved=0
> >
> > Status: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2F \
> > datatracker.ietf.org%2Fdoc%2Fdraft-hinden-6man-hbh-processing%2F&data=04%7C01% \
> > 7Chaoyu.song%40futurewei.com%7C2d02d0b86be0472a572208d897f5ee10%7C0fee8ff2a3b24018 \
> > 9c753a1d5591fedc%7C1%7C0%7C637426429867138791%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w \
> > LjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=FD9nh8S1xvkoCCYAGuCXv%2FiH%2BdGNRX3IBig1BLz0QMk%3D&reserved=0
> >
> > Html: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2F \
> > www.ietf.org%2Farchive%2Fid%2Fdraft-hinden-6man-hbh-processing-00.html&data=04 \
> > %7C01%7Chaoyu.song%40futurewei.com%7C2d02d0b86be0472a572208d897f5ee10%7C0fee8ff2a3 \
> > b240189c753a1d5591fedc%7C1%7C0%7C637426429867138791%7CUnknown%7CTWFpbGZsb3d8eyJWIj \
> > oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=TvBfaQURQuZvIMUFT59VdI4wqP8gNdQF1uGo13CC6dY%3D&reserved=0
> >
> > Htmlized: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2F \
> > tools.ietf.org%2Fhtml%2Fdraft-hinden-6man-hbh-processing-00&data=04%7C01%7Chao \
> > yu.song%40futurewei.com%7C2d02d0b86be0472a572208d897f5ee10%7C0fee8ff2a3b240189c753 \
> > a1d5591fedc%7C1%7C0%7C637426429867138791%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM \
> > DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=VBUOGO%2BkrnPCPP64l4CguOTU5SIQyduVSmT%2BLOMnyOU%3D&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
> ipv6@ietf.org
> Administrative Requests:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fipv6&data=04%7C01%7Chaoyu.song%40f
> uturewei.com%7C2d02d0b86be0472a572208d897f5ee10%7C0fee8ff2a3b240189c75
> 3a1d5591fedc%7C1%7C0%7C637426429867138791%7CUnknown%7CTWFpbGZsb3d8eyJW
> IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&
> amp;sdata=tWTygpRYLt56POZasHaJY50BnUgtUmOQLQlem47lZSk%3D&reserved=
> 0
> --------------------------------------------------------------------
--------------------------------------------------------------------
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
--------------------------------------------------------------------
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic