Subject: FW: New Version Notification for draft-bonica-6man-unrecognized-opt-02.txt

From: Ron Bonica <[email-masked]>
Date: Sun, 22 Jul 2018 19:54:08 +0000

Please review...

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Sunday, July 22, 2018 3:49 PM
To: Ron Bonica <[email-masked]>; John Leddy <[email-masked]>
Subject: New Version Notification for draft-bonica-6man-unrecognized-opt-02.txt

A new version of I-D, draft-bonica-6man-unrecognized-opt-02.txt
has been successfully submitted by Ron Bonica and posted to the IETF repository.

Name:		draft-bonica-6man-unrecognized-opt
Revision:	02
Title:		The IPv6 Unrecognized Option
Document date:	2018-07-22
Group:		Individual Submission
Pages:		7
URL:            https://tools.ietf.org/html/draft-bonica-6man-unrecognized-opt-02

Abstract:
   This document describes a method by which a source node can determine
   whether the underlying network can a) convey a packet that contains
   IPv6 destination options from itself to a destination node, and b)
   convey an ICMPv6 Parameter Problem message in the reverse direction.

   In order to support this method, this document defines a new IPv6
   option, called the Unrecognized option.  Implementation of the
   Unrecognized option is a trivial exercise, because the Unrecognized
   option elicits the same behavior from all nodes, regardless of
   whether they recognize the option.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: 神明達哉 <[email-masked]>
Date: Thu, 26 Jul 2018 10:57:23 -0700

At Sun, 22 Jul 2018 19:54:08 +0000,

> URL:            https://tools.ietf.org/html/draft-bonica-6man-unrecognized-opt-02

The idea makes sense to me.  One quick comment:

- I think the draft should be more specific about the option length
  rather than (implicitly) leave it to the implementation.  In fact, I
  don't see why it's not the obvious choice of '0'.

--
JINMEI, Tatuya

---

From: Fernando Gont <[email-masked]>
Date: Fri, 27 Jul 2018 14:49:59 +0200

Hello, Ron,

Overall, I support the proposal.

Some quick comments:

* I'd change the name of the option. Text such as

 "because the Unrecognized
  option elicits the same behavior from all nodes, regardless of
  whether they recognize the option."

while understandable, sounds akward.

* Section 3:
Do you need the option not be variable length?

* Meta:
Based on RFC7872, it is clear that EH size has an impact on the
probability of the packet being dropped. So you might want to add this
parameter to the "probe protocol". In essense, it would end up something
like PMTUD, but for options. PMOS (Path Maximum Option Size? :-) )

* Section 5, security considerations:
I'd include some work of the security implications of EHs 8e.g.,
possible performance impact).

Thanks!

Cheers,
Fernando

On 07/22/2018 09:54 PM, Ron Bonica wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Fernando Gont <[email-masked]>
Date: Fri, 27 Jul 2018 14:52:05 +0200

>   don't see why it's not the obvious choice of '0'.

While underspecified in the current doc, the option size that has an
impact on packet drops. So a node might be able to convey a DO of, say 8
bytes to the destination, but not one of, say, 512-bytes.

The ability to convey options to a given destination is hence, f(EH size).

Thanks!

Cheers,

---

From: 神明達哉 <[email-masked]>
Date: Fri, 27 Jul 2018 11:47:10 -0700

At Fri, 27 Jul 2018 14:52:05 +0200,

> bytes to the destination, but not one of, say, 512-bytes.

Yeah, I imagined that kind of intent, too.  And I wouldn't be opposed
to making the length variable per se.  But my point is that IMO such a
discussion should be explicitly included in the draft instead of
leaving it to reader/implementer's imagination.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 28 Jul 2018 08:31:09 +1200

> leaving it to reader/implementer's imagination.

I agree, and there's another point that occurred to me, previously
mentioned in an off-list comment:

>> However, if someone
>> sends a long (256 byte) option whose data is all zero, that option
>> will be very compressible, if any hops on the path apply compression.
>> The fact that a compressed packet gets through might conceal the fact
>> that a longer one would fail for some reason.
>> 
>> If you buy that, then the option data should be randomized, which makes
>> it much less compressible.

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Fri, 27 Jul 2018 22:19:31 +0200

> leaving it to reader/implementer's imagination.

Totally agree.

In fact, if the size is taking into account, one might need a probe
strategy (e.g., start low to quickly find out if small options get
there, and then increase option size to see if/when packets start ot get
dropped for larger options?)

Thanks,

---

From: Ron Bonica <[email-masked]>
Date: Sat, 28 Jul 2018 20:19:18 +0000

Hi Fernando,

Thanks for the review. Comments inline....

                            Ron

> From: Fernando Gont <[email-masked]>
> Sent: Friday, July 27, 2018 5:50 AM
> To: Ron Bonica <[email-masked]>; 6man <[email-masked]>
> Subject: Re: FW: New Version Notification for draft-bonica-6man-
> unrecognized-opt-02.txt
> 
> Hello, Ron,
> 

I am also starting to dislike the name. Can you think of a better one?

Since we use the option to probe paths, maybe we should call it the "Probe" option?

                                                          Ron

> Based on RFC7872, it is clear that EH size has an impact on the probability of
> the packet being dropped. So you might want to add this parameter to the
> "probe protocol". In essense, it would end up something like PMTUD, but for
> options. PMOS (Path Maximum Option Size? :-) )
> 
> 

As you state above, we might want to use this option to determine how large a DO a path can convey. So, we should probably:

- leave the Option data as variable length
- add some text to the draft explaining why we did this

> I'd include some work of the security implications of EHs 8e.g., possible
> performance impact).
> 

Because nodes that recognize this options behave identically to nodes that don't recognize it. There is no new behavior. When there isn't any new behavior, can there be any security considerations?

If you can think of one, I would be happy to document it.

                                                   Ron

> > Subject: New Version Notification for
> > draft-bonica-6man-unrecognized-opt-02.txt
> >
> >
> > URL:            https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__tools.ietf.org_html_draft-2Dbonica-2D6man-2Dunrecognized-2Dopt-
> 2D02&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=G-
> 03L8TpSQ0UWt_a_2MmZWksOitAeQhBH06vNXS-
> xFY&s=zYDxhhlOQF6rLi5WzpM5KC7gKX4v4RqznK3OUbFqVDY&e=
> >
> >
> > Abstract:
> > Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at tools.ietf.org.
> >
> > The IETF Secretariat
> >
> > Administrative Requests:
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mail
> > man_listinfo_ipv6&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzo
> > CI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=G-
> 03L8TpSQ0UWt_a_2M
> > mZWksOitAeQhBH06vNXS-
> xFY&s=WAkiKPb2X5Yb_dOCgi3GHMuA2mlbygkfX3HmOWCUWhs
> > &e=
> e-mail: [email-masked] || [email-masked] PGP Fingerprint:
> 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> 
>