Subject: Re: New Version Notification for draft-herbert-6man-icmp-limits-03.txt

From: 神明達哉 <[email-masked]>
Date: Fri, 9 Mar 2018 12:13:43 -0800

I've read draft-herbert-6man-icmp-limits-03.  I have a few comments:

- Since this is supposed to be returned by a middlebox that snoops on
  the portion of the packet that is not necessary for forwarding.  So
  I can imagine a concern like: "the real problem is that these boxes
  are broken; we should fix them rather than introduce more stuff to
  the standard protocol to mitigate the problem caused by broken
  nodes".  I personally don't take such a purist position, but I think
  this document should explicitly discusses the point and gives some
  justification to the idea.  (I remember something similar was
  discussed on the list, but I don't remember all details and the
  conclusion, if any.  sorry if it's totally a duplicate).

- (I also remember this was somewhat discussed before) It's not clear
  to me what the sending node that receives the error can do.  Section
  4.2 discusses the possibility, but depending on the nature of the
  extension header, it may not be feasible to omit the header/option
  that triggers the drop.  I guess we can't be sure until/unless we
  have some specific extension headers or options for which this error
  helps, and I'm okay with defining the error even before we have the
  case as a way of solving the chicken-and-egg situation.  But I'd
  like this document to discuss this point explicitly.  (or, if
  there's already a known specific case where this proposal would
  help, it's even better to show it).

- On a related note to the previous point, I'm afraid it's tricky for
  applications to benefit from this error (the first bullet of Section
  4.2) in practice.  There's currently no standard and portable way
  for an application using the common socket API to get this level of
  details.  So, for example, Section 11.3 of RFC3542 introduced a
  dedicated socket option so that a UDP application can get the MTU
  notified via an ICMPv6 packet too big error.  We'd need something
  similar to this for the proposed ICMPv6 error to be useful for
  applications.  I know (and agree) that this layer of issue is out of
  scope for a protocol specification, but we can't ignore practical
  implication at the end of the day.  I'd suggest at least briefly
  discussing this point, probably in an appendix.

- And, one other small point: it was not clear to me how the
  "Destination Unreach type for aggregate header limits" (Section 3)
  is different from "Extension header chain too long" (Section 2.4)
  (for the limit on the total size).

--
JINMEI, Tatuya

---

From: Tom Herbert <[email-masked]>
Date: Fri, 9 Mar 2018 16:58:33 -0800

> I've read draft-herbert-6man-icmp-limits-03.  I have a few comments:

Hi Jinmei,

Thanks for the comments!

>   conclusion, if any.  sorry if it's totally a duplicate).

No argument from me that nodes should be fixed to conform to
protocols! Nevertheless, middleboxes dropping packets with EH remains
fairly common and probably will be for the forseeable future. One
intent of this proposal is to get visbility into what they are doing
even if it doesn't conform to the protocol. Also, these ICMP errors
are not just generated by middleboxes. An end host might send an ICMP
error if it drops because of processing limits (for instance Section
5.3 of draft-ietf-6man-rfc6434-bis).

>   help, it's even better to show it).

It's also true that extension headers have not been widely used to
date so there might not have been much concern over what to do when
they're dropped. But that might be changing with proposal like SRv6. A
use case of EH that we are proposing is FAST
(http://buildbot.tools.ietf.org/html/draft-herbert-fast-00). The
intent here is to use dst ops on the Internet. Given that there is a
possibility of drops, we'll need to deal with that. ICMP errors could
help here.

>   discussing this point, probably in an appendix.
Yes, the socket APIs must be changed or at least augmented. It's
probably also true that applications even setting EH on a socket like
we want to do in FAST will need some better support.

>   (for the limit on the total size).
Aggregate header limits error can be used if all the headers in a
packet that a node wishes to process are too long. This could include
headers other then EH for instance.

Tom