Re: [OPSEC] (no subject)

["Scharf, Michael" <[e-mail]>]

> > Reviewer: Michael Scharf
> > Review result: Ready
> >
> > This document has been reviewed as part of the transport area review
> team's
> > ongoing effort to review key IETF documents. These comments were
> written
> > primarily for the transport area directors, but are copied to the
> document's
> > authors and WG to allow them to address any issues raised and also to
> the IETF
> > discussion list for information.
> >
> > When done at the time of IETF Last Call, the authors should consider
> this
> > review as part of the last-call comments they receive. Please
> > always CC tsv-art at ietf.org if you reply to or forward this review.
> >
> > I have reviewed draft-ietf-opsec-ipv6-eh-filtering-06. There are no
> apparent
> > transport issues. The proposed filtering could slow down the
> deployment of
> > experimental protocols that use IPv6 options, but the tradeoffs are
> explained
> > in the document.
> 
> Did you notice that Section 3.5.5 advises discarding IPv6 packets whose
> Next
> Header value is unknown -- i.e., IPv6 packets with unknown EHs **or**
> unknown
> transport protocols?  Even for an IPv6 core router in the open
> Internet?

Given the widespread deployment of NAT/NAPT and firewalls, which will typically drop packets with unknown transport protocols by default (AFAIKT), I have doubts that implementing the suggested policy in IPv6 core routers changes the overall situation significantly. 

Unfortunately, the reality is that it is today challenging to deploy new transport protocols in the Internet, no matter what this informational document writes.

> If not, would that fact change your assessment of this document?

I should perhaps have better highlighted the impact on unknown transport protocols. Yet, the real-world impact on transport protocols is IMHO small.

As a side note, if the document headed for BCP, I would be more concerned.
 
> As I noted in my own last call comments, I think that a more nuanced
> approach
> is called for (e.g., as set forth in Section 4.4.5 for unknown option
> values).

I will not disagree with using a more nuanced approach.

Michael