Re: I-D Action: draft-herbert-6man-eh-limits-00.txt

[Tom Herbert <[e-mail]>]

On Mon, Jun 28, 2021 at 4:23 PM Brian E Carpenter
<[e-mail]> wrote:
>
> I think the basic proposal is to limit extension headers to a total of 64 bytes, if outside a limited domain (TL;DR: see page 9 of the draft).
>
> Now, I'm well aware that shim6 (RFC5533) is not used; the main reason being that the Internet is largely opaque to its extension headers. Nevertheless, shim6 is a fully worked out use case for extension headers that would need to cross the open Internet.
>
> I wrote in 2016 as part of the RFC2460bis discussion that "I was surprised a while back to discover that a legal shim6 extension header could in fact exceed a kilobyte, specifically it is only limited to 1240 bytes by the standard." More to the point, a typical "large" shim6 extension header would be 40 bytes between dual-homed hosts. If hosts were more-than-dual-homed and therefore needed to exchange more addresses, the extension header would increase by 16 bytes per extra address.
>
> So, if we prescribed a 64 byte limit, we would also limit what extension headers can achieve.
>
Hi Brian,

It is ironic, but it seems the only way to save extension headers is
to limit them. This is a consequence of the robustness principle. For
instance, if one sends a shim6 header of 1240 bytes into the Internet,
there's a good chance the packet will be dropped by some intermediate
node that needs to look at the transport layer but doesn't have
capabilities to look deep into the packet. So sending a packet with
1240 bytes of extension headers to an arbitrary destination on the
public Internet and expecting it to work probably isn't the best idea
;-). But, this implies there should be some acceptable number of bytes
value N where 0 < N < 1240 (we want N > 0 lest extension headers are
obsoleted). This draft suggests N be 64.

As you point out, a greater limit could be applied when sending into a
limited domain. More specifically, a greater limit could be applied if
the sender has knowledge that all nodes in the path to a destination
will accept packets that exceed the limit. There is a lot of latitude
in how this knowledge is acquired, the sender may know that the whole
path to the destination is confined to a limited domain, or the sender
may use capabilities probing to the destination or have a priori
information about the path (like from a mash-up map of capabilities of
the Internet). The send clause of the robustness principle might be
amended as "be conservative in what you send unless you possess
knowledge that allows otherwise".

The receive clause of the robustness principle is also pertinent, This
draft states that all nodes MUST accept packets with sixty-four bytes
of extension headers. Grant it, per RFC8200 all nodes are supposed to
accept packets with extension headers up to the MTU, however it's
pretty clear that is not sufficiently supported in reality. I believe
that the sixty-four byte requirement is realistic for deployment (and
it's much greater than zero byte limits, i.e. better than devices
arbitrarily dropping packets with any extension header).

There is  precedent for limiting the number of bytes of extension
headers that a sender can send. For instance, the number of bytes in
extension headers in QUIC packets is limited. From RFC9000:

"This requirement to support a UDP payload of 1200 bytes limits the
space available for IPv6 extension headers to 32 bytes or IPv4 options
to 52 bytes if the path only supports the IPv6 minimum MTU of 1280
bytes."

This follows the same philosophy of this draft, a baseline limit is
established for sending into the Internet, and the limit can be
exceeded if there is information that allows otherwise. In the case of
QUIC the information that would allow sending more than thirty-two
bytes of extension headers would be that the path MTU is greater than
1280 bytes.

As for protocols that carry lists of IPv6 addresses, it's often been
pointed out that constitutes considerable packet overhead (for example
in discussions about SRv6)-- i.e. each IPv6 address in a packet
represents 1% overhead in standard MTU. The answer to this seems to be
to compress the list (like CRH for example).

Tom

> Regards
>    Brian
>
> On 23-Jun-21 13:01, [e-mail] wrote:
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> >
> >
> >         Title           : Limits on Sending and Processing IPv6 Extension Headers
> >         Author          : Tom Herbert
> >       Filename        : draft-herbert-6man-eh-limits-00.txt
> >       Pages           : 18
> >       Date            : 2021-06-22
> >
> > Abstract:
> >    This specification defines various limits that may be applied to
> >    receiving, sending, and otherwise processing packets that contain
> >    IPv6 extension headers.  The need for such limits is pragmatic to
> >    facilitate interoperability amongst hosts and routers in the presence
> >    of extension headers and thereby increasing the feasibility of
> >    deployment of extension headers.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-herbert-6man-eh-limits/
> >
> > There is also an htmlized version available at:
> > https://datatracker.ietf.org/doc/html/draft-herbert-6man-eh-limits-00
> >
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> >
> > _______________________________________________
> > I-D-Announce mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/i-d-announce
> > Internet-Draft directories: http://www.ietf.org/shadow.html
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------