Subject: Re: [Last-Call] [v6ops] Tsvart last call review of draft-ietf-v6ops-ipv6-ehs-packet-drops-05

From: Fred Baker <[email-masked]>
Date: Tue, 9 Mar 2021 05:07:49 -0800

> On Feb 24, 2021, at 9:01 AM, Tom Herbert <[email-masked]> wrote:
> 
> The problems have been caused by some
> routers implementations that have assumed unwritten requirements (like
> routers must access transport layer),

For the record, I don't know that this is a "router implementation" issue as much as it is an "operator requirement" interacting with the design of IPv4/IPv6 and UDP/TCP/ICMP. The protocol number, which operators filter on in ACLs, is carried in the transport layer headers.

---

From: Tom Herbert <[email-masked]>
Date: Tue, 9 Mar 2021 15:07:22 -0700

> For the record, I don't know that this is a "router implementation" issue as much as it is an "operator requirement" interacting with the design of IPv4/IPv6 and UDP/TCP/ICMP. The protocol number,…

Fred,

Yes, ACLs on transport layer ports are common requirements, however
the problem arises from related requirements that arise due to the
limitations of routers to be able to locate the transport layer
information in a packet. An example of such an implied requirement
from this draft is "don't send packets with IPv6 header chains that
are too long because some routers can't parse deep enough into packets
to find the transport layer ports due to implementation constraints
(like limited size parsing buffer)". While the rationale for the
requirement may make sense, the problem, at least from the host stack
perspective of trying to send packets with low probability they'll be
dropped, is that a requirement that "don't IPv6 header chains that are
too long" is is useless without any quantification as exactly to what
"too long" might be.

Tom

---

From: Fernando Gont <[email-masked]>
Date: Tue, 9 Mar 2021 20:03:03 -0300

On 9/3/21 19:07, Tom Herbert wrote:
[...]
> (like limited size parsing buffer)".

You seem to be reading more from the document than what we actually said 
in the document.

There are no requirements in this document. We simply explain things 
operators need to do, what are the associated limitations in real-world 
devices, and what's the likely outcome.

That's not an implied requirement, but simply a description of facts.

> While the rationale for the

"too long" for the processing device(s). You don't know what devices 
will process your packets, hence cannot even guess what "too long" might 
mean.

What you know for sure is that the longer the chain, the lower the 
chances of your packets surviving -- as per RFC7872.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Tom Herbert <[email-masked]>
Date: Tue, 9 Mar 2021 19:03:13 -0700

> That's not an implied requirement, but simply a description of facts.
It's obvious that the implied or at least inferred requirement is that
if a host wants to increase the probability of packets making it to
the destination then they should not make header chains too long. This
would also be an obvious interoperability requirement, i.e. if I make
my header chains too long then packets will be dropped and my host
stack is not interoperable with some elements in the network.

> chances of your packets surviving -- as per RFC7872.
That seems to me more like an assumption than a proven fact. To prove
it we'd need the data that correlates the length of the chain with
probability of drop, or alternatively, one could survey common router
implementations' capabilities and similarly extrapolate the
correlation. If we had this data then we could derive a meaningful
quantified requirement for both what routers are expected to process
and what hosts can expect. RFC7872 doesn't really have sufficient data
to make this correlation, and besides that it is not current.

In any case, this draft qualitatively describes why routers are
droppings. Which I suppose is good, but, given that information, I
don't see much that helps host developers that are sending packets in
the network and are trying to go beyond sending packets that conform
to the least common denominator of plain TCP/IP.

Tom