Subject: [v6ops] Revision of "Why operators drop IPv6 packets with EHs" (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-01.txt)

From: Fernando Gont <[email-masked]>
Date: Thu, 15 Oct 2015 09:43:40 -0300

Folks,

We have revised our I-D "Operational Implications of IPv6 Packets with
Extension Headers".

The new revision is available at:
<https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet-drops-01.txt>

This version hopefully addresses at least part of the comments received
from Eric Vyncke.

Your feedback will be very appreciated.

Thanks!

Best regards,
Fernando

-------- Forwarded Message --------
Subject: New Version Notification for
draft-gont-v6ops-ipv6-ehs-packet-drops-01.txt
Date: Thu, 15 Oct 2015 05:37:05 -0700
From: [email-masked]
To: Gert Doering <[email-masked]>, Nick Hilliard <[email-masked]>,
Shucheng LIU (Will) <[email-masked]>, Gert Doering
<[email-masked]>, Warren Kumari <[email-masked]>, Will Liu (Shucheng)
<[email-masked]>, Fernando Gont <[email-masked]>, Nick
Hilliard <[email-masked]>, Fernando Gont <[email-masked]>, Warren
Kumari <[email-masked]>

A new version of I-D, draft-gont-v6ops-ipv6-ehs-packet-drops-01.txt
has been successfully submitted by Fernando Gont and posted to the
IETF repository.

Name:		draft-gont-v6ops-ipv6-ehs-packet-drops
Revision:	01
Title:		Operational Implications of IPv6 Packets with Extension Headers
Document date:	2015-10-15
Group:		Individual Submission
Pages:		14
URL:
https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet-drops-01.txt
Status:
https://datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-ehs-packet-drops/
Htmlized:
https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-01
Diff:
https://www.ietf.org/rfcdiff?url2=draft-gont-v6ops-ipv6-ehs-packet-drops-01

Abstract:
   This document summarizes the security and operational implications of
   IPv6 extension headers, and attempts to analyze reasons why packets
   with IPv6 extension headers may be dropped in the public Internet.

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: Tom Herbert <[email-masked]>
Date: Thu, 15 Oct 2015 08:18:30 -0700

> Your feedback will be very appreciated.
Hi Fernado,

In section 4.1.3:

"As layer-4 port information increases the entropy of the hash, it is
highly desirable to use it where possible."

IMO, the use of IPv6 flow label for ECMP as described in RFC6438 is a
much better solution to target. The flow label can provide the
equivalent of layer-4 entropy without requiring devices to parse the
transport layer. This will work not only with extension headers
present, as well as other "unusual" protocols that devices may not or
cannot parse like GRE, IPIP, ESP, etc. Major OSes are now setting flow
labels for entropy, and AFAIK some switch and NIC vendors now have
support to use flow label as input to ECMP hash. It might be worth it
to mention this alternative in the draft.

Thanks,
Tom

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Fernando Gont <[email-masked]>
Date: Thu, 15 Oct 2015 12:32:57 -0300

Hi, Tom,

Thanks so much for your prompt feedback! Please find my comments in-line...

On 10/15/2015 12:18 PM, Tom Herbert wrote:
> cannot parse like GRE, IPIP, ESP, etc.

I agree with this. But my understanding was that implementations we're
still setting this to 0 -- that's why this wasn't mentioned as an option.

> Major OSes are now setting flow

I guess that mean Linux, Mac OS, *BSD, and MS Windows?

If you know of anything we can reference regarding this change, that
would be awesome. -- I will try to perform some tests myself, anyway.

Thanks so much!

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

---

From: Tom Herbert <[email-masked]>
Date: Thu, 15 Oct 2015 09:08:20 -0700

> would be awesome. -- I will try to perform some tests myself, anyway.
Mac OS (and BSD) is already deployed with setting non-zero flow labels
which we have verified. Starting with Linux 4.3 flow labels will be
set by default. I don't know about Windows.

Within the data center network we view the use of flow labels for ECMP
as a critical feature since it eliminates one barrier we have to
deploying extension headers or new/alternative protocols. Switches
should not need to parse the transport layer for packet forwarding,
only edge devices will need to parse transport headers to implement
security.

Tom