Subject: draft-gont-6man-ipv6-opt-transmit-02

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 4 Nov 2015 03:12:30 +0100 (CET)

My comments at the mic was regarding the use of "standard IPv6 option".

What I don't understand is this:

Can an existing standard EH get a new option in the future?

If no, then I understand what the text is saying. If yes, then I think the 
text needs to change to say that we need to define "this option can't be 
in any other EH than X" in order for the device to be able to accept 
future standard options that might currently not be defined.

Right?

"A node that processes the contents of an extension header MUST
    discard the corresponding packet if it contains any defined options
    that are not meant for the extension header being processed.  This
    document requests IANA to add a new column to [IANA-IPV6-PARAM] to
    clearly mark the IPv6 Extension Header type(s) for which each option
    (defined by IETF Standards Action or IESG Approval) is valid."

This seems to already say this, but the registry is the other way around, 
it's saying what options are valid for each EH, but the node needs to act 
in reverse? My worry is that a vendor of middleboxes could take this list 
of "currently standard combinations of EH and options" and drop anything 
that is not in it, and 5 years into th efuture when there are new things 
standardized, these are not deployable because of these ossified 
middleboxes.

I still remember the ECN problem when those two bits that before was 
defined as being 00 all of a suddent were not 0 and were being dropped by 
firewalls.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 4 Nov 2015 15:48:58 +1300

Mikael,

On 04/11/2015 15:12, Mikael Abrahamsson wrote:
> If no, then I understand what the text is saying. If yes, then I think the text needs to change to say that we need to define
> "this option can't be in any other EH than X" in order for the device to be able to accept future standard options that might
> currently not be defined.
> 
> Right?
> 
> This seems to already say this, but the registry is the other way around, it's saying what options are valid for each EH, but
> the node needs to act in reverse? My worry is that a vendor of middleboxes could take this list of "currently standard
> combinations of EH and options" and drop anything that is not in it, and 5 years into th efuture when there are new things
> standardized, these are not deployable because of these ossified middleboxes.

Of course they could. Some of them definitely will. We have running code proof
of that - see below. Firewalls block innovation. That's why RFC 7045 bleats
on about making all these drops configurable.

> I still remember the ECN problem when those two bits that before was defined as being 00 all of a suddent were not 0 and were
> being dropped by firewalls.

That is actual worth studying a bit more closely. In RFC 791, those bits are
defined as "Bit  6-7:  Reserved for Future Use" and seem to be shown
as zero in the diagram. RFC 1349 says that bit 7 must be zero, and gives
a meaning to bit 6. RFC 1455 also gives a meaning to bit 6. In RFC 2474,
which should be old enough to influence firewall behaviour, all the above
is obsoleted and those bits are defined thus:

   A two-bit currently unused
   (CU) field is reserved and its definition and interpretation are
   outside the scope of this document.  The value of the CU bits are
   ignored by differentiated services-compliant nodes when determining
   the per-hop behavior to apply to a received packet.

In other words, nobody told the firewall people "these bits are evil
unless they are zero". The firewall people invented that for themselves.

  Brian

---

From: Fernando Gont <[email-masked]>
Date: Wed, 4 Nov 2015 12:31:41 +0900

> Can an existing standard EH get a new option in the future?

Yes.

> If no, then I understand what the text is saying. If yes, then I think
> the text needs to change to say that we need to define "this option
> can't be in any other EH than X" in order for the device to be able to
> accept future standard options that might currently not be defined.

The idea is that the validity check applies to standard options.

i.e., if option, say, 99, is specified for DO header, and you find it in
the HBH header, then you drop. OTOH, if you find an unrecognized option
then by default, you allow it.

Put another way, our document makes it clear which combinations are
known to be invalid, such that you can drop them. Other combinations
(e.g., new options) are by default, allowed.

> This seems to already say this, but the registry is the other way
> around, it's saying what options are valid for each EH, but the node
> needs to act in reverse? My worry is that a vendor of middleboxes could
> take this list of "currently standard combinations of EH and options"
> and drop anything that is not in it, and 5 years into th efuture when
> there are new things standardized, these are not deployable because of
> these ossified middleboxes.

That's certainly not the intent.

> defined as being 00 all of a suddent were not 0 and were being dropped
> by firewalls.

Exactly.. Where trying to help against that behaviour, in the same way
as RFC7045 did.

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 5 Nov 2015 01:06:16 +0100 (CET)

> The idea is that the validity check applies to standard options.

So this is where I get lost. Whenever you say "standard option", you mean 
"currently standard option", right? What happens to equipment manufactured 
according to current standard options that in 5 years will be exposed to 
options standardized in 3 years from now, but the equipment isn't updated?

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 13 Nov 2015 17:24:58 +1300

On 05/11/2015 13:06, Mikael Abrahamsson wrote:
> So this is where I get lost. Whenever you say "standard option", you mean "currently standard option", right? What happens to
> equipment manufactured according to current standard options that in 5 years will be exposed to options standardized in 3 years
> from now, but the equipment isn't updated?

That's why the behaviour when seeing an unrecognised option needs to be configurable,
exactly as RFC 7045 requires for unrecognised extension headers. But yes, with
a default deny policy, new options can't be deployed. See the [Heller] reference
in RFC 7045. This is unfixable.

   Brian