Subject: IPR on draft-ietf-6man-mtu-option

From: [email-masked]
Date: Fri, 3 Sep 2021 12:29:29 +0200

All,

As part of the shepherds writeup we need to answer:

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

There is an IPR files against this:
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-6man-mtu-option

Patent here:
https://patents.google.com/patent/CN100459576C/en?oq=CN200510089086

From my perspective it's hard to see how RFC1063 wouldn't be prior art.
Any other views regarding this?

Best regards,
Ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 3 Sep 2021 15:18:19 +0200

Le 03/09/2021 à 12:29, [email-masked] a écrit :
> (8) Has an IPR disclosure been filed that references this document?
> If so, summarize any WG discussion and conclusion regarding the IPR
> disclosures.
> 
> 
> From my perspective it's hard to see how RFC1063 wouldn't be prior
> art. Any other views regarding this?

 From efforts of reading the difficult to read translated text without
figures, it seems the patent is for IPv6 whereas RFC1063 is for IPv4
PMTUD.  The former uses a Packet Too Big error message and successively
the src adapts to that error, whereas with RFC1063 the intermediary
routers update a passing regular datagram (not an error message) with
MTU values if smaller.  The mechanisms are different.  IMHO there could
be an IPR if the IPv6 PMTUD were imported into IPv4, but that is not the
case here.

Maybe that is why you think that RFC1063 IPv4 PMTUD is relevant, because
that also uses a normal message rather than an error message, and
because the claimed IPR proposes HbH can be seen closer to a normal message.

On another hand, the IPv6 PMTU of RFC1981 of year 1996 would be more
challenging for the claimed IPR, because that too is for IPv6.

The claimed IPR cites a few problems with IPv6 PMTUD RFC which could be
true.  But it does not cite the RFC1981 IPv6 PMTUD in its prior art,
although it does appear in the running text.  That is a fundamental
problem from my point of view: the IPR authors should cite the RFC
officially, plainly and upfront.  In that respect I would even say that
one of the goals of the open process of RFCs has a little bit failed to
impress.  So, citing the IETF RFC plainly would make the IPR more
friendly to IETFers and less naïve in its appearance.

The method described in the claimed IPR is a variation of the RFC1981.

One of the problems described first by the claimed IPR is that the path
idetified during the PMTUD process which sends back PTB messages might
change, so what the src node thought to be true min MTU (1350bytes) is
actually 1400bytes.  This problem of path dynamicity is my
interpretation of the hard to read description.  But it is clear that
there is where they see a problem with RFC1981.

A second problem authors see is in the security, maybe the opportunity
for DDoS attacks for PMTUD.  This is very interesting to understand.  If
authors see it as a problem, then they should tell it clearly and
describe it clearly.  If it is a real risk, then they do have a
responsibility in suggesting a countermeasure, and that should be public
and easy to implement.  In that sense, their IPR suggestion is very welcome.

Here's a solution the claimed IPR proposes with respect to the DDoS
risk: use HbH options (IPv6 hop-by-hop options extension headers, an
intermediary header, more of a 'built-in' to IPv6).  Presumably, this is
different than the PTB message (an ICMPv6 message, more of a 'payload'
to IPv6 datagrams), and different enough such as to earn novelty aspects.

This IPR seems to be granted in China only (I dont know?).  In such a
case, if that PMTUD does not travel outside China, the Internet as a
whole might not worry, but Internet might not take advantage of its DDoS
protection capabilities either.  But it is still very advantageous that
this is mentioned here at IETF.  If Internet is to benefit from this
protection at large, then it should be an easy licensing scheme, like
RAND.  Is the organisation ready to do RAND, I dont know?

The year it entered into force is 2009 and expires in 2025.  That is 4
years from now, and the I-D in question might take a few more time
before becoming an RFC.  Should one worry about this IPR at all, I dont
know?

Are there more recent patent applications (not yet granted) from this
organization on the same topic?

Alex

> 
> Best regards, Ole
> 
> 
> -------------------------------------------------------------------- 
> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
> --------------------------------------------------------------------
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 4 Sep 2021 09:26:34 +1200

It's not the IETF's job to decide whether or not prior art is relevant. Each individual implementer needs to make their own assessment. As RFC3699 says, "Applicability: It's Hard to Prove a Negative."

RFC3699 suggests looking mostly at the licensing statement, which in this case is:

"Reasonable and Non-Discriminatory License to All Implementers with Possible Royalty/Fee"

That's not generally considered a show-stopper. If it was, we'd have very few Proposed Standards in the IETF.

Regards
   Brian

On 03-Sep-21 22:29, [email-masked] wrote:
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6