Subject: Please review: 6MAN WG Adoption call: draft-baker-6man-hbh-header-handling-03

From: [email-masked]
Date: Sun, 18 Oct 2015 20:47:09 +0200

This message starts a two week 6MAN Working Group Last Call on adopting:

  Title           : IPv6 Hop-by-Hop Header Handling
  Authors     : F. Baker
  Filename   : draft-baker-6man-hbh-header-handling-03
  Pages       :
  Date          : 2015-10-6

  https://tools.ietf.org/html/draft-baker-6man-hbh-header-handling-03

as a working group item. Substantive comments and statements of support for adopting this document should be directed to the mailing list.  Editorial suggestions can be sent to the authors.  This adoption call will end on November 1st, 2015.

Regards,

Bob Hinden & Ole Trøan

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 19 Oct 2015 08:39:31 +1300

Hi,

Yes, I think the WG should adopt this topic. In particular, I support
the key recommendation:

> Packets containing the Hop-by-Hop Extension Header SHOULD be
> processed at substantially the same rate as packets that do not.

I do have a few comments on the current text:

> At this writing, there are several defined Hop-by-Hop options:

This list should probably mention the experimental options defined
in RFC 4727.

> 2.3.  Adding headers or options in transit

I have extreme doubts about this. I believe that RFC 2460 intended to
forbid this but was loosely worded ("extension headers are not processed
by any node along a packet's delivery path"). When the time comes, I will
argue  that 2460bis should correct this. In any case, if this section is
retained, it needs to discuss MTU issues. I don't see why that belongs
in the Security Considerations.

> 3.  Interoperation with RFC 2460

Should probably be adjusted to refer to 2460bis.

Regards
   Brian Carpenter

---

From: Fernando Gont <[email-masked]>
Date: Mon, 19 Oct 2015 21:23:09 -0300

Hi, All,

+1 to adoption and everything Brian noted, modulo one issue noted below:

> Should probably be adjusted to refer to 2460bis.

I'd say both 2460 and 2460bis.

Thanks!

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

---

From: Mark Smith <[email-masked]>
Date: Tue, 20 Oct 2015 22:05:16 +1100

On 19 October 2015 at 06:39, Brian E Carpenter
<[email-masked]> wrote:
> argue  that 2460bis should correct this.

I would also agree.

The unicast source address in a packet indicates the source of all
information in a packet - the packet originator.

If a device in the network adds information, such as extension
headers, the unicast source address value has lost some if its
meaning, because it now doesn't identify the source of all of the
contents of the packet.

The packet is now a "multi-source" packet, rather than a single or
"uni-source" packet, yet only the first of the packet content sources
is available in the packet's unicast source address field.

Any mechanisms that depend on a source address identifying the single
and original source of the packet, such as PMTUD, may now fail.

Encapsulation of the packet in another when information is added in
the network allows the multiple packet sources, and what was added by
each of them, to be easily determined. There is now no ambiguity as to
which single or unicast source added what to the packet.

Regards,
Mark.

> In any case, if this section is
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: <[email-masked]>
Date: Tue, 20 Oct 2015 13:34:15 +0000 (UTC)

>The unicast source address in a packet indicates the source of all information in a packet - the packet originator.

>If a device in the network adds information, such as extension headers, the unicast source address value has lost some if its meaning, because it now doesn't identify the source of all >of the contents of the packet.

>The packet is now a "multi-source" packet, rather than a single or "uni-source" packet, yet only the first of the packet content sources is available in the packet's unicast source >address field.

>Any mechanisms that depend on a source address identifying the single and original source of the packet, such as PMTUD, may now fail.

On networks today, you will see "third party reset".  That is, a middle box sending a reset to a destination address with what appears to be the unicast source address of the originator. But, it is not actually sent by that source address but by a box in the middle.  Just saying, the source address does not in all cases indicate the packet originator.  And, I am not talking about MITM.  This situation can happen today if there are too many retransmits, for example.

Not saying we want to perpetuate this kind of behavior.

---

From: Mark Smith <[email-masked]>
Date: Wed, 21 Oct 2015 11:37:58 +1100

>
> >If a device in the network adds information, such as extension headers,
the unicast source address value has lost some if its meaning, because it
now doesn't identify the source of all >of the contents of the packet.
> >The packet is now a "multi-source" packet, rather than a single or
"uni-source" packet, yet only the first of the packet content sources is
available in the packet's unicast source >address field.
>
> On networks today, you will see "third party reset".  That is, a middle
box sending a reset to a destination address with what appears to be the
unicast source address of the originator. But, it is not actually sent by
that source address but by a box in the middle.  Just saying, the source
address does not in all cases indicate the packet originator.  And, I am
not talking about MITM.  This situation can happen today if there are too
many retransmits, for example.
> Not saying we want to perpetuate this kind of behavior.

(Terse because I'm on a train)

We shouldn't, and if we get to the point where addresses are cryptography
authenticated, that won't work.

That is of course an example of source address spoofing. If you were to try
to trouble shoot that, without being aware there is a device in the network
spoofing source addresses, you'd spend a lot of time suspecting and
investigating a device that wasn't at fault.

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Thu, 29 Oct 2015 14:53:54 +0100

Hi,

> as a working group item. Substantive comments and statements of support for adopting this document should be directed to the mailing list.  Editorial suggestions can be sent to the authors.  This a…

I support adoption of the draft.

Some comments:
   Router Alert Option:  The IPv6 Router Alert Option [RFC2711]
      [RFC6398] is intended to force the punting of a datagram to
      software, in cases in which RSVP or other protocols need that to
      happen.

"to software" could be more precise, e.g., control plane software.
Usually, RAO is used to intercept signaling (control) packets. Moreover,
since a 16-bit value in the RAO header is used as codepoint for
the signaling application, the action may depend on the particular
value.

>> 2.1.  Hop-by_hop Options

>>   At this writing, there are several defined Hop-by-Hop options:

Since RFC 2460 only allows a single hbh extension header
within an IPv6 packet, the listed options cannot be used
at the same time, right?
However, I can consider scenarios where it makes sense to
actually combine those.

>>  2.2.  Changing options in transit

This is valuable in order to provide more explicit feedback for
congestion control as already mentioned.

>> 2.3.  Adding headers or options in transit

Indeed this may have a lot of difficult implications, so we need
to discuss whether this makes sense. Moreover, there is nothing said
about practical difficulties with the keeping the processing speed
at line rate when stuff is inserted. While I know that encapsulation
can be done at high speeds, I'm not sure about insertion of headers....

>> 5.  Security Considerations

I think that this needs more work and that at least Section 3
of RFC 6398 https://tools.ietf.org/html/rfc6398#section-3 is highly
relevant here. RAO packets are usually punted to the slow path
since it is the control plane. While it is clear that
draft-baker-6man-hbh-header-handling-03 wants to at least skip
unknown or unconfigured hbh extension headers at line speed,
I'm not sure that the control plane processing speed can
be that high...

Regards,
 Roland

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 29 Oct 2015 22:46:11 +0000

Hi chairs,
   I think this work is very important and I support adoption of this draft 
as a wg item.

Thanks
Suresh

---

From: Greg Daley <[email-masked]>
Date: Thu, 29 Oct 2015 23:11:29 +0000

Dear 6Man team,

I believe this should be a working group document.

Sincerely, 

Greg Daley
Solutions Architect
Logicalis Australia Pty Ltd

t +61 3 8532 4042
m +61 401 772 770
> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Monday, 19 October 2015 5:47 AM
> To: 6man WG
> Cc: 6man Chairs
> Subject: Please review: 6MAN WG Adoption call: draft-baker-6man-hbh-
> header-handling-03
> 
> as a working group item. Substantive comments and statements of support for
> adopting this document should be directed to the mailing list.  Editorial
> suggestions can be sent to the authors.  This adoption call will end on
> November 1st, 2015.
> 
> Regards,
> 
> Bob Hinden & Ole Trøan

---

From: [email-masked]
Date: Sun, 1 Nov 2015 15:12:16 +0900

The chairs conclude there is a consensus in the 6MAN working to have this draft become a working group draft.  The authors should submit the next version as a 6MAN working group document.

Thanks,
Bob & Ole