Subject: Fwd: New Version Notification for draft-baker-6man-hbh-header-handling-01.txt

From: "Fred Baker (fred)" <[email-masked]>
Date: Sat, 6 Jun 2015 07:55:03 +0000

> Begin forwarded message:
> 
> From: <[email-masked]>
> Subject: New Version Notification for draft-baker-6man-hbh-header-handling-01.txt
> Date: June 6, 2015 at 12:43:55 AM PDT
> To: Fred Baker <[email-masked]>, Fred Baker <[email-masked]>
> 
> 
> A new version of I-D, draft-baker-6man-hbh-header-handling-01.txt
> has been successfully submitted by Fred Baker and posted to the
> IETF repository.
> 
> Name:		draft-baker-6man-hbh-header-handling
> Revision:	01
> Title:		IPv6 Hop-by-Hop Header Handling
> Document date:	2015-06-06
> Group:		Individual Submission
> Pages:		7
> URL:            https://www.ietf.org/internet-drafts/draft-baker-6man-hbh-header-handling-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-baker-6man-hbh-header-handling/
> Htmlized:       https://tools.ietf.org/html/draft-baker-6man-hbh-header-handling-01
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-baker-6man-hbh-header-handling-01
> 
> Abstract:
>   This note updates the IPv6 Specification (RFC 2460), specifically
>   commenting on the Hop-by-Hop Options Header (section 4.3) and option
>   format and handling (section 4.2).
> 
>   It also updates RFC 7045, which noted that RFC 2460 is widely
>   violated in this respect, but merely legitimized this situation with
>   a SHOULD.  The present document tries to address the issue more
>   fundamentally.
> 
>   It tries to address the issue.
> 
> 
> 
> 
> 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: Brian E Carpenter <[email-masked]>
Date: Sun, 07 Jun 2015 08:10:30 +1200

Thanks Fred. With those changes, I can parse the document a bit more
clearly, and I suggest the following:

OLD:
   More generally, in routers that implement a fast path, the processing
   of the Hop-by-Hop Extension Header (which must be performed by every
   router a packet transits) MUST be performed in the fast path unless
   there is a specific reason to punt to a slower path, including that
   corresponding software exists in the implementation and is configured
   to process the option.

NEW:
   More generally, in routers that implement a fast path, the processing
   of the Hop-by-Hop Extension Header (which RFC 2460 required in every
   router a packet transits) MUST be performed in the fast path unless
   there is a specific reason to punt to a slower path, including that
   corresponding software exists in the implementation and is configured
   to process the option. This replaces the first sentence of RFC 7045
   quoted in Section 1.

(I would suggest that rest of the quote from 7045 is still historically
accurate, but is qualified by the new Interoperation section.)

On the comment that someone else wrote, I prefer your "MUST ... unless"
formulation to "SHOULD ... unless". Logically they are pretty much
identical, but "MUST" is harder for a product manager to ignore.

Regards
   Brian

On 06/06/2015 19:55, Fred Baker (fred) wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Dennis Ferguson <[email-masked]>
Date: Sat, 6 Jun 2015 13:44:47 -0700

>> Name:		draft-baker-6man-hbh-header-handling

Fred,

I don't like the specification in section 2.1 very much since it seems
to be describing how something should be implemented in terms which
require (unstated) context to understand while still being a bit
vague about what that implementation is supposed to accomplish.  For
example, I don't know of a generic difference between "microcode"
and "software" but I'm quite confident they'll both be being executed
by hardware, so all of those terms aren't necessarily telling me anything.
Additionally, it isn't clear that a binary "fast path" and "slower path"
is a necessary feature of a router, but whatever there is it would be
surprising if processing packets with a hop-by-hop header weren't somehow
more costly to something than packets without that header since the former
seem to inherently require more work to be done and that is likely to have
a cost (in dollars if not in performance).

What I think this is requiring is that packets with a hop-by-hop header with
options which are of no interest to an application running on the router
be forwarded at a substantial fraction of the rate at which packets without
a hop-by-hop header can be processed.  If this is true then I wish it would
just say this is the requirement, without worrying too much about how this might
be accomplished but worrying more about the definition of an option that is
"of no interest to an application running on the router".  For example, for the
RA option the particular packets that might be of interest to an application
running on the router are identified most granularly by the presence of the
option and its particular value: are you asking that "not interesting" be
determined with that granularity, is it sufficient that RA packets are
found "not interesting" only when no protocol depending on the RA is in use,
or are you leaving it up to implementations (in which case you can't count on
anything better than the latter)?

It also seems that whatever granularity of "not interesting" is chosen for
router forwarding, it needs to be matched by firewall filter implementations.
When a RA packet is interesting it is usually because it is a routing protocol
packet and there needs to be a way to protect the routing protocols at the
network edge.  This is particularly true if you are now requiring networks not
interested in RA packets to forward them at a great rate since that has the
side effect of making those networks much more useful to attack neighbours
running routing protocols which do use RA packets.

Finally, I don't get the reason for all the MUST constraints in the very
generic discussion of adding things to in-flight packets in section 2.3, i.e.

   containing it.  The obvious implication is that other equipment in
   the network may not understand or implement the new option type.  As
   such, the Option Type value of such an option MUST indicate that it
   is to be skipped by a system that does not understand it.  Since, by
   definition, it is being updated in transit and not included in any AH
   or ESP integrity check if present, the Option Type MUST also indicate
   that it may be updated in transit, and so is excluded from AH and ESP
   processing.  By implication, such an Option Type MUST be of the form
   001XXXXX.

What if the router adding the option is doing so in the expectation that it
will be removed again by a router closer to the destination?  In this case
adding the option would seem to have no effect on end-to-end authentication,
since it wasn't there when the source sent it and will be undone before the
destination end sees it, and you might explicitly want a system which doesn't
understand the option to drop it if that indicates that someone made a mistake
and failed to remove the option when it should have been.  In this case a
01XXXXXX option type seems perfectly appropriate.  Don't these MUSTs need to
wait for the particulars of the protocol that depends on adding options to
packets?

Dennis Ferguson

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Sat, 6 Jun 2015 21:09:00 +0000

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Sat, 6 Jun 2015 21:48:38 +0000

> On Jun 6, 2015, at 1:10 PM, Brian E Carpenter <[email-masked]> wrote:
> 

This makes two changes:

s/must be performed by/RFC 2460 required in/
and
a\
This replaces the first sentence of RFC 7045 quoted in Section 1.

If you really want to mention RFC 2460 in every paragraph of the document, I'm OK with that, but I wonder whether the reader doesn't already have that focus pretty squarely in mind? What does it add here?

And I note that the requirement is not, with the document, in the past tense. The Extension Header must still be processed, the options in it must still be processed in order, and all that (which 7045 softened). I'm commenting on the implementation. So putting that requirement in the past tense doesn't make a lot of sense to me.

The added sentence, I suppose, makes the way in which this updates 7045 clear. That said, I'm not clear on what you claim had been being violated, and in what way this actually changes the specification. The statement in 2460 is

4.3  Hop-by-Hop Options Header

   The Hop-by-Hop Options header is used to carry optional information
   that must be examined by every node along a packet's delivery path.

which doesn't follow the 2119 rules ("must" is in lower case, which is something that gets debated a lot, but which is not MUST, and I note that 2460 doesn't point to 2119, so I see no reason to presume it - if we could simply presume it, nobody needs t refer to it in the text or bibliography), and doesn't say anything about how that "examination" is to take place. So something that punts them to a lower path is not in violation of the specification if the HBH options are in fact processed and processed in the sequence they come in the header (2460 section 4.2). It's just not as fast as one might prefer.

7045 says that (which you asked me to quote, and which you say is updated in this specification)

2.2.  Hop-by-Hop Options

   The IPv6 Hop-by-Hop Options header SHOULD be processed by
   intermediate forwarding nodes as described in [RFC2460].  However, it
   is to be expected that high-performance routers will either ignore it
   or assign packets containing it to a slow processing path.

I'll note that the "interoperation" section you asked me to add pretty much says this, in detail. Older routers might not operate on the HBH header. That might have ramifications.

What this document says, in 2.1, is that a modern router really has very little excuse for not being able to parse a PAD1 or PADN option in its fast path, and that punting a Router Alert or new option to the slower path at a point at which there is no slow path to punt it do violates common sense.

So I'm really scratching my head on the microscope-enhanced wordsmithing here. Not objecting, but Really Really Wondering.

> identical, but "MUST" is harder for a product manager to ignore.

Ack.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 07 Jun 2015 13:48:48 +1200

> If you really want to mention RFC 2460 in every paragraph of the document, I'm OK with that, but I wonder whether the reader doesn't already have that focus pretty squarely in mind? What does it ad…

Well, I am focused on the difference between 2460 and 7045; 2460 isn't the IPv6
standard; the standard is 2460 plus all its updates.

> And I note that the requirement is not, with the document, in the past tense. The Extension Header must still be processed, 

Well, no, that's the point. RFC 2460 says it must be processed, but RFC 7045
updates that to say it SHOULD be processed. You may dislike that, but that's the
current standard. You're proposing that we revert to MUST. That's a choice we
can make, but it is a reversion.

> the options in it must still be processed in order, and all that (which 7045 softened). I'm commenting on the implementation. So putting that requirement in the past tense doesn't make a lot of sense to me.

I don't care how it's wordsmithed. It's true that 2460 doesn't use the RFC 2119
convention, as you say below. So we need to be clear that we've changed
a must to a SHOULD and back to a MUST (if that's what the WG wants).

    Brian

---

From: Ole Troan <[email-masked]>
Date: Sun, 7 Jun 2015 22:34:59 +0200

> a hop-by-hop header can be processed.

could we reverse this?

RFC2460 text - NEW:
   The Hop-by-Hop Options header is used to carry optional information
   that MAY be examined by every node along a packet's delivery path.
   A node MUST NOT process the Hop-by-Hop options unless it is explicitly configured
   to do so.

cheers,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Sun, 07 Jun 2015 20:24:16 -0300

>    A node MUST NOT process the Hop-by-Hop options unless it is explicitly configured

FWIW, loved it. Minor comment: IIRC, RFC7045 is kind of an implicit "MAY
examine" for any EHs, IIRC (which, FWIW, is sensible and in touch with
reality).

Thanks!

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

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 08 Jun 2015 12:44:55 +1200

> examine" for any EHs, IIRC (which, FWIW, is sensible and in touch with

At first sight, I loved it too. However, an alternative formulation
occurred to me:

    The IPv6 header is used to carry information
    that MAY be examined by every node along a packet's delivery path.
    A node MUST NOT process the IPv6 header unless it is explicitly configured
    to do so.

So you see what a messy place this kind of language leads to.

    Brian