[prev in list] [next in list] [prev in thread] [next in thread]
List: ipng
Subject: Re: Comments on draft-ietf-6man-hbh-processing-00
From: Tom Herbert <tom () herbertland ! com>
Date: 2022-02-10 20:21:12
Message-ID: CALx6S35PUdpBvZVB_xxqhGme9F1ixY76fyPKwb6-cCFvWVnbqA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Thu, Feb 10, 2022, 12:10 PM Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:
> Tom
>
> On one point:
> On 11-Feb-22 08:44, Tom Herbert wrote:
>
> ...
>
> > General question: RFC2460 specified that all routers must process HBH
> > options, RFC8200 relaxed that requirement to allow routers to ignore
> > HBH options. Is this draft changing that to be that routers MUST
> > process at least one option, or can they still ignore all HBH options?
>
> It doesn't matter what we write, leading-edge line-speed routers will
> ignore
> them. So IMHO this statement in the draft is unrealistic:
>
> "This document updates [RFC8200] that a node MUST process the first Option
> in the Hop-by-Hop Header at full forwarding rate..."
>
> and only a SHOULD is realistic.
>
> I also object to this:
>
> "A node configured not to process HBH options, MUST drop the packet if the
> top two bits of the Option Type field of the first HBH option is non-zero."
>
Oh, I missed that. That would indeed answer my question if this is draft
requiring routers to process one option. Agree, this is not a feasible
requirement and seems to be somewhat reverting what RFC8200 states.
Tom
>
> I can't see any vendor of really high speed routers implementing that as
> a default behavior. Why would they even look beyond the Destination
> Address?
> They wouldn't even have an option to process or not process HBH.
>
> Brian
>
[Attachment #5 (text/html)]
<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">On Thu, Feb 10, 2022, 12:10 PM Brian E Carpenter <<a \
href="mailto:brian.e.carpenter@gmail.com">brian.e.carpenter@gmail.com</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex">Tom<br> <br>
On one point:<br>
On 11-Feb-22 08:44, Tom Herbert wrote:<br>
<br>
...<br>
<br>
> General question: RFC2460 specified that all routers must process HBH<br>
> options, RFC8200 relaxed that requirement to allow routers to ignore<br>
> HBH options. Is this draft changing that to be that routers MUST<br>
> process at least one option, or can they still ignore all HBH options?<br>
<br>
It doesn't matter what we write, leading-edge line-speed routers will ignore<br>
them. So IMHO this statement in the draft is unrealistic:<br>
<br>
"This document updates [RFC8200] that a node MUST process the first Option in \
the Hop-by-Hop Header at full forwarding rate..."<br> <br>
and only a SHOULD is realistic.<br>
<br>
I also object to this:<br>
<br>
"A node configured not to process HBH options, MUST drop the packet if the top \
two bits of the Option Type field of the first HBH option is \
non-zero."<br></blockquote></div></div><div dir="auto"><br></div><div \
dir="auto">Oh, I missed that. That would indeed answer my question if this is draft \
requiring routers to process one option. Agree, this is not a feasible requirement \
and seems to be somewhat reverting what RFC8200 states.</div><div \
dir="auto"><br></div><div dir="auto">Tom</div><div dir="auto"><div \
class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"> <br>
I can't see any vendor of really high speed routers implementing that as<br>
a default behavior. Why would they even look beyond the Destination Address?<br>
They wouldn't even have an option to process or not process HBH.<br>
<br>
Brian<br>
</blockquote></div></div></div>
--------------------------------------------------------------------
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