Hop-by-Hop Forwarding Options Header
draft-li-6man-hbh-fwd-hdr-01
| Document | Type | Expired Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Zhenbin Li , Shuping Peng , Gyan Mishra | ||
| Last updated | 2021-08-23 (Latest revision 2021-02-19) | ||
| Stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats |
Expired & archived
|
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
https://www.ietf.org/archive/id/draft-li-6man-hbh-fwd-hdr-01.txt
Abstract
RFC8200 specifies the HBH header that is assumed to be processed by each hop in the delivery path of the packet. However, RFC8200 also expects that nodes processing the HBH header have been explicitly configured to do so. Therefore, it cannot be assumed that a HBH header present in the packet is processed. It all depends on the configuration of each node across the path. Moreover, in most of networks today, the processing of the HBH header is done in the control plane (slow processing path) which incurs several limitations among which resources consumption and security risk. For these reasons, over time, the Hop-by-Hop Options header has been sparsely used without any form of large scale deployment. Also, most of already defined HBH options are forwarding options which contain forwarding plane information that needs not to be sent to the control plane. This document proposes a new Hop-by-Hop Forwarding Options Header in order to carry Hop-by-Hop options that are solely intended to and processed by the forwarding plane. This new HBH header is confined in and dedicated to the forwarding plane while the current HBH header can still be used for control plane options.
Authors
Zhenbin Li
Shuping Peng
Gyan Mishra
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)