Subject: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 11 Mar 2016 10:01:34 +0000

The authors of draft-gont-v6ops-ipv6-ehs-packet-drops would like v6ops to adopt draft-gont-v6ops-ipv6-ehs-packet-drops as a working group document. Yes or no?

https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-03
https://tools.ietf.org/rfcdiff?url2=draft-gont-v6ops-ipv6-ehs-packet-drops-03.txt

---

From: [email-masked]
Date: Fri, 11 Mar 2016 14:01:38 +0100

> The authors of draft-gont-v6ops-ipv6-ehs-packet-drops would like v6ops to adopt draft-gont-v6ops-ipv6-ehs-packet-drops as a working group document. Yes or no?

No.

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."

The reasons why packets are dropped, and the security / operational implications is already covered in some of the the numerous other documents on IPv6 EHs.

Best regards,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Fri, 11 Mar 2016 10:29:43 -0300

> The reasons why packets are dropped, and the security / operational implications is already covered in some of the the numerous other documents on IPv6 EHs.

Which ones? Specifically, which document covers the stuff that is in the
operational considerations section of our document?

-- 
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: Sat, 12 Mar 2016 08:13:11 +1300

I disagree with Ole. I think there is is useful factual information here
that should be published. "Solicit input from network operators and users
to identify operational issues with the IPv6 Internet" and "document IPv6
operational experience" are part of the WG charter.

The new "Future Work" section is also telling us that we aren't done yet
if we want to improve deployability.

    Brian

On 12/03/2016 02:01, [email-masked] wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: [email-masked]
Date: Sat, 12 Mar 2016 17:53:26 +0100

Brian,

Let me offer the contrarian view.

> operational experience" are part of the WG charter.

I've read through the document one more time. Would you be able to cite new and useful information in this document?
That isn't already described elsewhere...?

- Parsing EHs is and the consequence of having to walk the extension header chain is a well known problem.
  If the premise is that we want this to work well for arbitrary middleboxes, the solution space is empty.
- HBH headers is a well known problem. One draft in 6man as well as changes in 2460bis.
- The ECMP problem is well known. We tried to solve it with flow label, in practice the IP header has evolved to be 24 / 44 bytes respectively.
- The MTU attach is already described and resolved in 2460bis, 6145bis, 1918bis

> if we want to improve deployability.

Enforcing a cap on the extension header chain isn't going to make the slightest difference.
Vendors can build whatever you like, but are you willing to pay the price? Especially given that real, deployed applications aren't using EHs.
This reminds me of the ngtrans/softwires/v6ops/6man saga, where we had the belief that the reason IPv6 wasn't deployed was because we didn't have the right transition mechanism, or the right interface id generation mechanism or at least 3 different ways of assigning DNS recursive resolvers... History has shown us we were wrong.

Given that EHs are rarely used, all the time already invested into clarifying and tweaking them (we've publish 10+ documents on EHs already), is it really good use of the IETF's time to publish yet another document, that rehashes the same problems?

I think no. I think we should let the EH "problem" rest for a few years and see if it is anything worth revisiting in say 2020.

Best regards,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 13 Mar 2016 07:42:25 +1300

> That isn't already described elsewhere...?

The observational data, which for some reason people wanted to push into an Appendix.
For me that's the main point of the document.

> Enforcing a cap on the extension header chain isn't going to make the slightest difference.

I tend to agree on that specific point. But we need that restriction anyway
to reduce security risks.

> Given that EHs are rarely used, all the time already invested into clarifying and tweaking them (we've publish 10+ documents on EHs already), is it really good use of the IETF's time to publish yet…

Again, I believe that publishing the observational data is useful in itself. The rest
of the document is context.

> I think no. I think we should let the EH "problem" rest for a few years and see if it is anything worth revisiting in say 2020.

But then what do we do when people come along proposing to standardise more
extension headers? This document will be helpful, I believe.

I do agree with you that once this and the current drafts in 6man are resolved, there's
little point in doing more for now.

    Brian

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Sat, 12 Mar 2016 19:07:10 +0000

> On Mar 12, 2016, at 8:53 AM, [email-masked] wrote:
> 
> Given that EHs are rarely used

One specific point that worries me in this discuss is the indiscriminate reference to extension headers. One of the is the Security Header; I use the IPv4 variant of that (I believe along with UDP) when I use AnyConnect or Cisco CVO, which is to say "pretty much invariably". If the call is to deprecate extension headers, do we deprecate IPsec? What other instance of "baby vs bathwater" are there?

---

From: Fernando Gont <[email-masked]>
Date: Sat, 12 Mar 2016 16:21:54 -0300

On 03/12/2016 04:07 PM, Fred Baker (fred) wrote:
> One specific point that worries me in this discuss is the
> indiscriminate reference to extension headers. One of the is the
> Security Header; I use the IPv4 variant of that (I believe along with
> UDP) when I use AnyConnect or Cisco CVO, which is to say "pretty much
> invariably". If the call is to deprecate extension headers, do we
> deprecate IPsec? What other instance of "baby vs bathwater" are
> there?

I don't think anyone is calling to deprecate EHs... quite the opposite:
the idea is to try to make them deployable.

Regarding IPsec EHs, they are filtered in a similar ways as other EHs.
Hence it does make sense to reference the whole bunch as "extension
headers".

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 12 Mar 2016 16:18:44 -0300

Ole,

On 03/12/2016 01:53 PM, [email-masked] wrote:
>> I disagree with Ole. I think there is is useful factual information
>> here that should be published. "Solicit input from network
>> operators and users to identify operational issues with the IPv6
>> Internet" and "document IPv6 operational experience" are part of
>> the WG charter.
> 
> I've read through the document one more time. Would you be able to
> cite new and useful information in this document? That isn't already
> described elsewhere...?

Quite a few times in this discussion you argued that when use of the
Flow Label for ECMP is widely deployed, there would be no need for
routers/middle-boxes to process the EH chain. Among other things, this
document clarifies why that's not the case.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 12 Mar 2016 16:26:59 -0300

On 03/12/2016 01:53 PM, [email-masked] wrote:

> Enforcing a cap on the extension header chain isn't going to make the
> slightest difference. Vendors can build whatever you like, but are
> you willing to pay the price? Especially given that real, deployed
> applications aren't using EHs.

If that's your take, then I guess you should be arguing for deprecation.
Because the "EH" feature requires code, and that code has been the
source of trouble in a number of places (including evasion of security
controls, DoS vectors, and others).

I should note, though, that IPsec uses EHs...

Thanks,

---

From: Doug Barton <[email-masked]>
Date: Sat, 12 Mar 2016 12:19:24 -0800

> That isn't already described elsewhere...?

IPv6 has suffered from the "too many drafts" problem for over a decade. 
Assuming that the derivative material is given sufficient citations 
there is great value for implementors in a document that summarizes the 
current state of the art, combined with actual observations of said 
problems.

Doug

---

From: [email-masked]
Date: Sat, 12 Mar 2016 22:43:27 +0100

Brian,

[...]

> For me that's the main point of the document.

Which observational data are you thinking of?
I looked and couldn't find any, you aren't thinking of draft-ietf-v6ops-ipv6-ehs-in-real-world?

[...]

Best regards,
Ole

---

From: [email-masked]
Date: Sat, 12 Mar 2016 22:47:50 +0100

Fernando,

> document clarifies why that's not the case.

Sorry I don't get that, can you point that out to me?

Best regards,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Sat, 12 Mar 2016 19:15:40 -0300

Hi, Ole,

> Sorry I don't get that, can you point that out to me?

Sure.

This was your question:
<https://www.ietf.org/mail-archive/web/v6ops/current/msg21680.html>

This was e.g. Joel's response:
<https://www.ietf.org/mail-archive/web/v6ops/current/msg21685.html>

Section 4 (and subsections) of our document is all about that.

Every time the issue of EH packet drops comes up, discussion eventually
becomes about "but hey, why are you looking deep into the packet?". --
And a large part of our I-D talks exactly about that.

Thanks,

---

From: Tom Herbert <[email-masked]>
Date: Sat, 12 Mar 2016 14:32:40 -0800

> - The ECMP problem is well known. We tried to solve it with flow label, in practice the IP header has evolved to be 24 / 44 bytes respectively.

Where are these 24 / 44 byte IP headers described?

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 13 Mar 2016 15:47:28 +1300

> I looked and couldn't find any, you aren't thinking of draft-ietf-v6ops-ipv6-ehs-in-real-world?

Zut alors! (which Google translates to Norwegian as "Shucks!").
Yes, I was momentarily confused between the two documents, sorry.

That said, where else will an implementer or an operator find this collection
of information about operational practice or limitations?

    Brian

---

From: [email-masked]
Date: Sun, 13 Mar 2016 20:52:36 +0100

Tom,

> Where are these 24 / 44 byte IP headers described?

in every router / middlebox on the planet. (and somewhat tangential for any RFC describing shared IPv4 addresses)

e.g (from VPP):

/* Compute flow hash.  We'll use it to select which Sponge to use for this
   flow.  And other things. */
always_inline u32
ip6_compute_flow_hash (ip6_header_t * ip, u32 flow_hash_config)
{
    tcp_header_t * tcp = (void *) (ip + 1);
    u64 a, b, c;
    u64 t1, t2;
    uword is_tcp_udp = (ip->protocol == IP_PROTOCOL_TCP
			|| ip->protocol == IP_PROTOCOL_UDP);

    t1 = (ip->src_address.as_u64[0] ^ ip->src_address.as_u64[1]);
    t1 = (flow_hash_config & IP_FLOW_HASH_SRC_ADDR) ? t1 : 0;

    t2 = (ip->dst_address.as_u64[0] ^ ip->dst_address.as_u64[1]);
    t2 = (flow_hash_config & IP_FLOW_HASH_DST_ADDR) ? t2 : 0;

    a = (flow_hash_config & IP_FLOW_HASH_REVERSE_SRC_DST) ? t2 : t1;
    b = (flow_hash_config & IP_FLOW_HASH_REVERSE_SRC_DST) ? t1 : t2;
    b ^= (flow_hash_config & IP_FLOW_HASH_PROTO) ? ip->protocol : 0;

    t1 = is_tcp_udp ? tcp->ports.src : 0;
    t2 = is_tcp_udp ? tcp->ports.dst : 0;

    t1 = (flow_hash_config & IP_FLOW_HASH_SRC_PORT) ? t1 : 0;
    t2 = (flow_hash_config & IP_FLOW_HASH_DST_PORT) ? t2 : 0;

    c = (flow_hash_config & IP_FLOW_HASH_REVERSE_SRC_DST) ?
        ((t1<<16) | t2) : ((t2<<16) | t1);

    hash_mix64 (a, b, c);
    return (u32) c;
}

Best,
Ole

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 13 Mar 2016 20:54:39 +0000

[email-masked] wrote:
> in every router / middlebox on the planet. (and somewhat tangential
> for any RFC describing shared IPv4 addresses)
> 
> e.g (from VPP):

i.e. when the packet processor can see the tcp/udp ports, the flow hash
generally ends up being an n-tuple similar to:

fh(flowlabel, srcip, dstip, srcport, dstport)

In this case, protocol is also added in, but this value will be tied
tightly to similar srcport and dstport values, so its overall
contribution to entropy is low.

If the packet processor can't see the tcp/udp src/dst ports due to
excessive amounts of EHs, then this n-tuple drops to:

fh(flowlabel, srcip, dstip, 0, 0)

In practice, the flow label is often set to zero, giving:

fh(0, srcip, dstip, 0, 0)

The point of the draft is to note that excessive EHs will contribute to
a deterioration of entropy in flow hash inputs and that this has
operational consequences.

Nick

---

From: Tom Herbert <[email-masked]>
Date: Sun, 13 Mar 2016 13:59:10 -0700

Ole,

This is not the way it works for *every* middlebox on the planet. For
instance, in Linux we can deduce a flow hash from ports-- not just for
TCP and UDP but for SCTP, DCCP, UDP-lite, etc.--, GRE key ID, MPLS
entropy label, IPv6 flow label, SPI in AH and ESP, parse over
extension headers, and also can parse into several encapsulation
protocols to find L4 information (GRE, IPIP, IPv6/IP). See
http://lxr.free-electrons.com/source/net/core/flow_dissector.c#L121.

Even if I accepted that we are pragmatically limited with only ever
using TCP and UDP without extensions headers on the Internet, I will
never accept these as constraints in my private networks! We are and
will using other IP protocols, encapsulation, EH, etc. IPv6 flow label
is therefore a general solution; it works with any IP protocols we
might use, extension headers, etc., it is straightforward to add into
hash computation in devices. With the flow label, none my fabric
switches need to parse beyond the 40 byte IPv6 header in order to
provide ECMP.

Most of the arguments against extension headers seem to be because
they are difficult to parse, however the point of using flow label is
that it eliminates the need to parse extension headers in the first
place for the ECMP use case. It would be nice if this benefit was and
the need for flow label support were better enunciated in the draft.
IMO any opportunity we have to get intermediate devices to do less
deep packet parsing without loss of functionality is a good thing!

Tom

---

From: [email-masked]
Date: Sun, 13 Mar 2016 22:17:01 +0100

Tom,

> deep packet parsing without loss of functionality is a good thing!

Fully agree. Wouldn't it be nice.
I don't see how this particular draft helps here though.

Best regards,
Ole

---

From: Mark Smith <[email-masked]>
Date: Mon, 14 Mar 2016 10:05:03 +1100

>> for any RFC describing shared IPv4 addresses)

<snip>

> operational consequences.

So in the medium term, the specific use of LAG and/or ECMP to bundle
links, and their desire to look at transport layer headers, might
disappear. I came across work on "Flex Ethernet" the other day, and
one thing it seems to be looking to do is to solve the problem of link
bundling without the dependencies on layer 2/3/4 field values.

"What is FlexEthernet?"
http://www.ethernetsummit.com/English/Collaterals/Proceedings/2015/20150415_1C_Gustlin.pdf

"Flex Ethernet Implementation Agreement"
http://www.oiforum.com/wp-content/uploads/OIF-FLEXE-01.0.pdf

Regards,
Mark.

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 13 Mar 2016 23:30:17 +0000

> bundling without the dependencies on layer 2/3/4 field values.

flexethernet will solve a different set of problems to what we're talking about here. I don't see any point in the foreseeable future where lags and ecmp will stop being relevant. 

Nick

---

From: Fernando Gont <[email-masked]>
Date: Sun, 13 Mar 2016 20:44:45 -0300

> I don't see how this particular draft helps here though.

The reasons being the same I mentioned in my other email: IN the same
way as you did a while ago, there seems to be the assumption that the
only reason for which packets with EHs are dropped is because
middleboxes need the layer-4 information for ECMP, and that that would
away with widespread support for the FL.

Our I-D makes it clear that that is not the case.

I will re-ask my question: where else are these operation considerations
covered?

(You argued that they are covered elsewhere, but you never said where).

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 14 Mar 2016 13:51:25 +1300

On 14/03/2016 09:59, Tom Herbert wrote:
...
> the point of using flow label is

I'll be the least likely person on the planet to disagree with that,
but it is already part of the IPv6 standards (RFC6437 - see 2nd and 3rd
paragraphs of the Introduction) and has been in the IPv6 Node Requirements
since 2011 (RFC434).

    Brian

---

From: Mark Smith <[email-masked]>
Date: Mon, 14 Mar 2016 12:20:42 +1100

On 14 March 2016 at 10:30, Nick Hilliard <[email-masked]> wrote:
> flexethernet will solve a different set of problems to what we're talking about here.

So it might be worth enumerating all of them, as bullet #2 sounds like
the problem people are commonly solving with LAG and ECMP, and one
that has been mentioned in this discussion. From the Flex Ethernet
Implemention Agreement:

"5.3
Sample Applications
FlexE can support a variety of applications. A non-exhaustive list includes:
* Router to Transport Connection (more examples below).
* Intra-Data Center “Fat Pipe” application: bonded PHYs for flows exceeding the
PHY rate, or carrying traffic that doesn’t distribute efficiently with LAG.
* Generalized MLG applications, e.g., an n × 100G PHY as an umbilicus to a
satellite shelf of lower rate ports."

> I don't see any point in the foreseeable future where lags and ecmp will stop being relevant.
>

If there is a solution that costs the same or less than them, and
doesn't depend on the presence and/or distribution of layer 2/3/4
field values, I think they will stop or become far less relevant.

Those networks that rely on LAG or ECMP aren't general purpose any
more, as they've been optimised for certain link and upper layer
traffic profiles.

If you're originating the traffic, you're in control of the traffic
profile, so you can ensure the optimisation continues to work. If
you're not originating the traffic, there is always a risk the
optimisation will fail and there is nothing you can do to prevent it -
your customer probably believes they're getting X M/Gbps of any type
of traffic, rather than X M/Gbps of type Y traffic that you've
optimised for, and they'll probably be angry if you try to raise their
price to cover you increase bandwidth costs to deal with their
non-optimal traffic.

Getting the IETF to prohibit the non-optimal traffic avoids the
possibility of dealing with angry customers or increased network
costs. I don't think it is intentional, however I think that is what
is in effect happening here.

The optimisation is understandable, and is caused by the costs imposed
by Ethernet's 10x increments. FlexE seems to be specifically
addressing that problem, by supporting bundling and therefore smaller
link increments, without making assumptions about upper layer header
presence, location and field value distribution.

Regards,
Mark.

---

From: Tom Herbert <[email-masked]>
Date: Sun, 13 Mar 2016 18:54:45 -0700

Brian,

These are good descriptions flow label usage, but I don't see that
they set requirements as to 1) whether end host must/should/may send
non-zero flow labels with flow entropy 2) whether ECMP devices
must/should/may use non-zero flow labels as input to their hash, or 3)
if hosts use the flow label for EMCP must/should/may they parse any
deeper to extract additional L4 entropy. RFC6438 comes close and
answering #1, but that RFC is only applicable to tunnels.

Pertaining to this draft, there is an observation that flow labels
would obviate the need for middle boxes to parse the header chain,
however the draft also states historically neither end nodes nor
routers support. It seem like there should at least be a
recommendation in "Future work"  section on how to attain widespread
support flow label.

Thanks,
Tom

---

From: Warren Kumari <[email-masked]>
Date: Mon, 14 Mar 2016 03:01:55 +0000

> would obviate the need for middle boxes to parse the header chain,

I think I must have missed something somewhere / lost the plot -- which
draft is "this" draft? draft-gont-v6ops-ipv6-ehs-packet-drops?
I don't think that draft-gont-v6ops-ipv6-ehs-packet-drops says that at all
-- if the *only* thing that the middlebox is doing is load-balancing /
ECMP, then this may be true, but in many cases "middleboxes" (a term which
seems about as vague as "thingies") are doing many other things, including
filtering, encapsulation, translation, monitoring / measurement,
"optimization", prioritization, etc.

But, as I said, I suspect I've lost the plot somewhere along the line...
W

---

From: Tom Herbert <[email-masked]>
Date: Sun, 13 Mar 2016 20:10:56 -0700

On Sun, Mar 13, 2016 at 8:01 PM, Warren Kumari <[email-masked]> wrote:
> -- if the *only* thing that the middlebox is doing is load-balancing / ECMP,
> then this may be true, but in many cases "middleboxes" (a term which seems
> about as vague as "thingies") are doing many other things, including
Section 4.1.2 of draft-gont-v6ops-ipv6-ehs-packet-drops-03 discusses
ECMP. ECMP is a fundamental feature in switches, we currently rely it
on to get good load balancing across network fabrics.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 14 Mar 2016 00:35:03 -0300

On 03/14/2016 12:01 AM, Warren Kumari wrote:
> I don't think that draft-gont-v6ops-ipv6-ehs-packet-drops says that at
> all -- if the *only* thing that the middlebox is doing is load-balancing
> / ECMP, then this may be true, but in many cases "middleboxes" (a term
> which seems about as vague as "thingies") are doing many other things,
> including filtering, encapsulation, translation, monitoring /
> measurement, "optimization", prioritization, etc. 
> 

This is exactly why this document is needed.

Every time this discussion comes up, people seem to argue that if/when
support for the Flow Label is widespread, packets with EHs will be
passed -- as if ECMP was the sole reason for processing the EH chain.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 14 Mar 2016 16:39:23 +1300

On 14/03/2016 14:54, Tom Herbert wrote:
> non-zero flow labels with flow entropy 

RFC6437 seems clear enough to me:

  "It is therefore RECOMMENDED
   that source hosts support the flow label by setting the flow label
   field for all packets of a given flow to the same value chosen from
   an approximation to a discrete uniform distribution.  Both stateful
   and stateless methods of assigning a value could be used, but it is
   outside the scope of this specification to mandate an algorithm.  The
   algorithm SHOULD ensure that the resulting flow label values are
   unique with high probability."

> 2) whether ECMP devices
> deeper to extract additional L4 entropy.

Is that a matter for standardisation? Surely designers of ECMP or
other load balancing devices will use whatever they find works best?

> RFC6438 comes close and

Beyond what "node requirements" says? Such as what?

    Brian

---

From: Warren Kumari <[email-masked]>
Date: Mon, 14 Mar 2016 03:42:21 +0000

On Mon, Mar 14, 2016 at 11:10 AM Tom Herbert <[email-masked]> wrote:

> all
> ECMP,
> ECMP.

Nod.

> ECMP is a fundamental feature in switches,

Nod.

> we currently rely it

Yah, nod, nod, fully agree.

I see where the disconnect is now -- to me, switches are not "middleboxes",
they fall into their own bucket ("switches" :-P).
I think we are in violent agreement, we are just using different terms.

To me, middleboxes are IP devices which are not designed to more than just
packet forwarding / filtering - but this is a vague description, and more
of a "I know it when I see it" (kind of like the entertaining (?)
discussions of the difference between a bridge and a switch, or a L3 switch
and a router).

RFC 3234 ("Middleboxes: Taxonomy and Issues") has a much better definition
than mine :-P
W

---

From: Tom Herbert <[email-masked]>
Date: Mon, 14 Mar 2016 10:29:53 -0700

> other load balancing devices will use whatever they find works best?
I think it may be a matter for standardization in the sense that most
current ECMP implementations tend to only work with TCP and UDP
without options (i.e. this leads to the notion that IP has evolved to
have 24/44 byte headers as a de facto standard). This creates
interoperability with other standard protocols. Even if devices
perform ECMP on these alternate protocols based on just addresses this
is still not enough, without similar flow based load balancing  we
can't deploy alternate transport protocols/EH at scale. From that
point of view, the IPv6 flow label "works best" for ECMP and so the
three tuple hash (addresses and flow label) should be the recommended
method for ECMP devices to implement.

Also, point #3 is important. An end host sets the flow label with the
expectation that packets with the same 3-tuple will follow the same
path through the network. If routers do implement the flow label, but
also try to extract more entropy by trying to parse into the transport
layer, this breaks the host's expectation. This increases
nondeterminism resulting in out-of-order packets, drops, high variance
latency. IMO #3 should also be a recommendation for switches doing
ECMP.

Tom

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 14 Mar 2016 17:59:52 +0000

Tom Herbert wrote:
> From that point of view, the IPv6 flow label "works best" for ECMP
> and so the three tuple hash (addresses and flow label) should be the
> recommended method for ECMP devices to implement.

Tom,

Everyone agrees with this.  The problem is that core and leaf operators
are not in control of flow label generation at the edge, and many
operating systems do not bother to set the flow label.  In other words,
flow labels do not currently provide enough entropy to be useful for
flow hash generation in most instances.

Everyone understands that flow labels would help this problem.  This
draft is about what happens when the flow label is zero, which is the
case more often than not.

Nick

---

From: Tom Herbert <[email-masked]>
Date: Mon, 14 Mar 2016 11:12:16 -0700

> case more often than not.

Nick,

iOS already sends non-zero IPv6 flow labels, we have changed Linux
default to use IPv6 flow label so once Android rebases the kernel the
majority of IPv6 end hosts should be sending non-zero flow labels. It
is far easier and shorter time to change the software stacks to send
them than upgrading all the HW in the paths to use them productively.
But compared the problem of HW being able to efficiently parse
arbitrarily long header chains, I still think this is a very solvable
problem.

Tom

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 Mar 2016 09:29:52 +1300

On 15/03/2016 07:12, Tom Herbert wrote:
...
> them than upgrading all the HW in the paths to use them productively.

True, and upgrading the client stacks will break the chicken/egg
blockage in this case.

You don't mention Windows, which is still quite present in the market,
and for full impact servers need to be setting the flow label too.

Also, what algorithms are the various stacks using? It isn't just a matter
of setting any old non-zero value.

   Brian

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 14 Mar 2016 20:55:13 +0000

Tom Herbert wrote:
> default to use IPv6 flow label so once Android rebases the kernel
> the majority of IPv6 end hosts should be sending non-zero flow
> labels. It is far easier and shorter time to change the software
> stacks to send them than upgrading all the HW in the paths to use
> them productively.

I'm not disagreeing, but bear in mind that flow labels were defined over
20 years ago and they're still only used in a minority of cases.

All this is slightly beside the point, though - this is an informational
draft, simply noting reasons why packets with EHs are dropped.  The
reason we're writing the draft is that when you turn EHs on, you can
expect large-scale packet loss.  As far as the authors are concerned,
this is a bad thing.

Nick

---

From: Tom Herbert <[email-masked]>
Date: Mon, 14 Mar 2016 15:32:21 -0700

> of setting any old non-zero value.
- FreeBSD (and presumably iOS): sets the flow label for a new
connection using the ip6_randomflowlabel function. This calls
randomid() which implements a pseudo random number generator. Flow
label is saved in connection state for use in transmitted packets.
This automatic flow label generation is controlled by a socket option
and a sysctl.

- Linux (e.g. Android will): sets the flow label for new connections
(TCP or connected UDP socket) using prandom_u32 (pseudo random
number). The flow label for a connection may change if the connection
is failing in hopes of finding a better route-- either the networking
stack detects a bad route (i.e. TCP is retransmitting) or userspace
can request a route change if it has information about path quality.
So flow labels are not necessarily persistent which probably makes
flow label filtering a bad idea at least if persistence for the
lifetime of a connection is required for that (see
http://www.maths.tcd.ie/~dwmalone/p/ec2nd05.pdf). For cases with no
connection state (unconnected UDP, forward and encapsulate), the flow
label is generated by parsing the packet to determine a hash based on
L3/L4 information.

- Windows: I believe you mentioned that Windows 7 doesn't seem to have
support for setting flow labels. Maybe someone from Microsoft can
clarify this and let us know what the prospects are for getting flow
label support.

These describe use of stateless flow labels. There are also interfaces
to set specific stateful flow labels, but since on the wire there is
no distinction between stateful and stateless labels we need to assume
that stateful labels retain reasonable properties for stateless uses
like ECMP (as in sec. 3 of RFC6437), however there is no effort by the
stack to enforce any properties of stateful labels.

Tom

---

From: Joe Touch <[email-masked]>
Date: Mon, 14 Mar 2016 20:04:25 -0700

> 20 years ago and they're still only used in a minority of cases.

The same might be said for IPv6 itself:
https://eggert.org/meter/ipv6

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 Mar 2016 16:09:24 +1300

On 15/03/2016 11:32, Tom Herbert wrote:

...
> is failing in hopes of finding a better route

In that case, it really doesn't matter as far as ECMP or load balancing goes
if the flow label changes, since the path will be changing anyway.
(OK, it might matter for server load balancing at the destination,
but that is a corner case that has to be dealt with regardless.)

> -- either the networking
> flow label filtering a bad idea

It's a bad idea, period. If you are trying to detect malicious traffic
you will need DPI anyway.

> at least if persistence for the
> support for setting flow labels.

I couldn't find anything. Presumably it can be done by apps through the
Winsock API, but that isn't very useful.

> Maybe someone from Microsoft can

Please.
   Brian

---

From: Warren Kumari <[email-masked]>
Date: Tue, 15 Mar 2016 03:51:59 +0000

On Tue, Mar 15, 2016 at 2:12 AM Tom Herbert <[email-masked]> wrote:

> majority of IPv6 end hosts should be sending non-zero flow labels.

Yah, bring on the non-zero labels.

It is far easier and shorter time to change the software stacks to send
> them than upgrading all the HW in the paths to use them productively.

Goodness, yes.

> arbitrarily long header chains, I still think this is a very solvable

Yup. Ubiquitous flow labels will solve *one* of the issues with long header
chains, but in the remaining cases (my personal bugbear is filtering (for
dos and ingress / edge filters)) the hardware still need to be capable of
doing it (at line-rate).

 W

---

From: Warren Kumari <[email-masked]>
Date: Tue, 15 Mar 2016 06:36:19 +0000

> you will need DPI anyway.

... but, but, what if you are trying to use this to permit *good* traffic?!

You just *know* that if you provide the ability to filter on flow labels
that some silly monkey will invent some horrendous hack where you have to
portknock on the SSH port with the flowlabel set to 0xBAA. Or "firewall"
their corporate network to only allow flowlables of 0x123 (and provide a
client that sets the flowlabel on all packets sent to that network to
0x123).

Oh! Huh! Nftable provides the "ipv6 flowlabel" matching primitive.
And I can just stuff (0xBAA & IPV6_FLOWINFO_FLOWLABEL) into flr_label...

Oh no... I'm the stupid monkey here...

:-P

W

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 Mar 2016 19:57:53 +1300

Warren,

A 20-bit hash of the evil bit?

Regards
   Brian

---

From: Warren Kumari <[email-masked]>
Date: Tue, 15 Mar 2016 07:28:41 +0000

$ ipython
In [1]: import md5
In [2]: for evil_bit in [0,1]:
   ...:     print hex(int(md5.md5(chr(evil_bit)).hexdigest(), base=16) &
0x0fffff)
   ...:
0x59f71L
0x1df41L
In [3]:

Yup, that looks to be about how much entropy we currently see in
flow-labels... actually, a bit more...

<warren runs away, chortling manically>
W

---

From: [email-masked]
Date: Tue, 15 Mar 2016 11:12:10 +0100

Warren,

[...]

> Yup. Ubiquitous flow labels will solve *one* of the issues with long header chains, but in the remaining cases (my personal bugbear is filtering (for dos and ingress / edge filters)) the hardware still need to be capable of doing it (at line-rate).

I never understood from the draft what the other use cases were, but those are the ones? ingress/edge filters and DOS attacks?

from the perspective of a software forwarding path.
parsing the extension header chain is _always_ going to be slower than not doing it. that in itself can be considered opening your implementation up to DOS attacks, but oh well.

can ingress / edge filters be done in two stages? core routers only filter on SA/DA while whatever infrastructure function you need to reach apply deeper filters?

for DOS attacks, are those filters put in place dynamically? what does a typical attack look like? can you identify it without having to parse EHs? how often are you not able to identify it even when looking deep? any papers/reports on this?

Best regards,
Ole

PS: In BA we're trying to do a project on VPP for the IETF hackathon, if anyone is interested in implementing EH filtering / parsing and measure the performance impact on that, it would be very welcome. (VPP is a open source high performance software data plane running on commodity hardware.)

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 15 Mar 2016 22:54:48 +0000

[email-masked] wrote:
> from the perspective of a software forwarding path. parsing the 
> extension header chain is _always_ going to be slower than not doing 
> it. that in itself can be considered opening your implementation up 
> to DOS attacks, but oh well.

assuming that you're talking about routers with separate management and
forwarding planes, and that you're referring to packets being punted
from the regular forwarding plane to the management plane when they are
difficult to handle (e.g. large EH chains), you can assume that on
current large routers, this is as good as dropping the packet because
the disparity between the capacity of the forwarding plane and the
management plane is too large to be useful. No-one in their right mind
will let the management plane of a high end router chew up management
CPU by forwarding punted packets. It's pointless.

> can ingress / edge filters be done in two stages? core routers only 
> filter on SA/DA while whatever infrastructure function you need to 
> reach apply deeper filters?

Basically, no.  What might look to be legitimate traffic on core ingress
might only become visible as a ddos attack on the egress to the edge.
That's assuming that there is a clear-cut edge and core which there
often isn't.

> for DOS attacks, are those filters put in place dynamically?

yes - e.g. via flowspec.

> what does a typical attack look like?

they vary extremely widely; the smarter attacks will measure the effect
on the recipient site and vary the ddos traffic according to what
appears to work the best.  I.e. if one style of traffic appears not to
be having an impact, the traffic profile might change to something else
to see if that causes more trouble.

> can you identify it without having to parse EHs?

If someone attacks with ipv6 and there is a long enough EH chain to
cause the normal forwarding plane of a router to be unable to look far
enough into the packet to determine the L4 info, then the only real
option is to drop or rate limit (which is nearly equivalent to dropping
in the case of a ddos). There is insufficient parsing granularity on any
current equipment to be able to do much else.

> how often are you not able to identify it even when looking deep?
> any papers/reports on this?

No papers that I'm aware of.

Nick

---

From: [email-masked]
Date: Wed, 16 Mar 2016 11:50:14 +0100

Nick,

> CPU by forwarding punted packets. It's pointless.

no, I'm talking about behaviour just in the data plane (in my case one that runs entirely in software).
if the requirement is to look into the L4 header, then there will be a performance penalty for processing packets with extension headers. looking deeper into packets == more memory accesses.
long EHs could be used as a DOS attack against the router.

simple solution is to not look into the L4 obviously.

> current equipment to be able to do much else.

why wouldn't the ddos flowspec description include the EHs in that case and not depend on only the L4 information.

can we conclude that we don't know enough about ddos attacks to determine how they can be filtered?

cheers,
Ole

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 16 Mar 2016 11:24:37 +0000

[email-masked] wrote:
> if the requirement is to look into the L4 header, then there will be
> a performance penalty for processing packets with extension headers.
> looking deeper into packets == more memory accesses.

It's not viable to run high end networks on general purpose CPUs using
software forwarding.  At the very least, you need NPUs if not custom
hardware (asics, "merchant silicon", etc).

> simple solution is to not look into the L4 obviously.

That isn't a viable workaround.  Losing visibility of L4 information is
catastrophic from the point of view of ddos management.

> why wouldn't the ddos flowspec description include the EHs in that
> case and not depend on only the L4 information.

Because if you have full control of a compromised device, you can create
random EH chains on an ipv6 packet?

> determine how they can be filtered?

Not sure what you mean here.  People initiating DDoS attacks will do
anything if they think it will cause damage to the recipient host.  Does
that answer your question?

Nick

---

From: [email-masked]
Date: Wed, 16 Mar 2016 15:00:32 +0100

Nick,

> hardware (asics, "merchant silicon", etc).

that was pretty fundamentalistic.
as always it depends. if you're happy with a few 100Gs then you can do it on current commodity hardware.

> catastrophic from the point of view of ddos management.

I hear you are saying that, but it is difficult to know if that's correct or not without having access to data.
how did the ddos attack look like, then figure out what the possible mitigations are.

> that answer your question?

sure, I'm just saying that if the ddos mitigation requires lots of processing it will also cause damage to routers.

cheers,
Ole

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 16 Mar 2016 14:36:36 +0000

[email-masked] wrote:
> that was pretty fundamentalistic. as always it depends. if you're 
> happy with a few 100Gs then you can do it on current commodity 
> hardware.

which in turn depends completely on what features are enabled. in/out
packet forwarding is simple and can be done fast on commodity hardware
with software forwarding. When you turn on the sort of features that
you need on production networks (netflow, qos, filtering, etc)
forwarding throughput drops dramatically.

>> That isn't a viable workaround. Losing visibility of L4 information
>> is catastrophic from the point of view of ddos management.
> 
> I hear you are saying that, but it is difficult to know if that's 
> correct or not without having access to data.

Is it not obvious that if you're trying to selectively filter traffic to
a specific destination, that you need to be able to access L4 info?

Maybe take a look at some of the ddos presos at netops meetings (nanog /
ripe / apricot, etc)?  Do you need something more formal?

Nick

---

From: Tom Herbert <[email-masked]>
Date: Wed, 16 Mar 2016 08:48:39 -0700

> forwarding throughput drops dramatically.
But if we turn on the "wrong" features like the aforementioned EH's,
IP options, checksum in UDP encapsulation, or use some protocol that a
hardware device isn't designed for-- we can just as easily cause
packet forwarding throughout to drop in HW devices.

For basic packet forwarding (e.g. fabric switches) we'll still happily
use hardware, but flow based ECMP must be supported in these which is
why the flow label support in HW is critical. For more advanced
filtering, load balancing,  ddos mitigation we (large data center
operators at least) are trending toward software solutions on
commodity HW. Even if there is some performance difference with an
equivalent HW solution in terms of features, extensibility and lower
cost are driving factors.

In any case, on the Internet I don't think the differences between HW
and SW solutions are germane. We are bound to the least common
denominator which advances much more slowly than production networks.
Processing an unbounded chain of EHs is probably a problem for anyone
at this point.

Tom

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 16 Mar 2016 15:49:26 +0000

> Processing an unbounded chain of EHs is probably a problem for anyone

exactly, which is what this draft is attempting to document.

Nick

---

From: Tom Herbert <[email-masked]>
Date: Wed, 16 Mar 2016 09:25:35 -0700

> exactly, which is what this draft is attempting to document.
Nick, what is not clear to me from the draft is what purpose that
devices would have in parsing EH. Different purposes may imply
different mitigations to the parsing problem. I see at least four
possibilities:

1) To extract L4 entropy for ECMP. As discussed flow label eliminates
the need to parse in this case.
2) To perform L4 inspection for DDOS, stateful firewalls. The EH that
provides the header chain length seems potentially useful in this
case.
3) Handle/not handle HBH
4) Inspect other EHs for filtering.

Others?

Do you have any sense as to which of these would applicable/required
in the Internet?

Thanks,
Tom

---

From: [email-masked]
Date: Wed, 16 Mar 2016 18:38:12 +0100

Nick,

> exactly, which is what this draft is attempting to document.

making processing of extension headers hard was considered by Steve to be a feature.

that's well known. it just isn't clear to me what you are trying to achieve with this draft?
on one hand it alludes to why L4 information might be required in the network, on the other it says why routers aren't able to process the EH chain...

Best regards,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Wed, 16 Mar 2016 15:09:47 -0300

Hi, Ole,

> making processing of extension headers hard was considered by Steve to be a feature.

So what?

That "feature" makes them impossible to deploy.

> on one hand it alludes to why L4 information might be required in the network, on the other it says why routers aren't able to process the EH chain...

We go back to square one all the time.

Please let me summarize:

1) Packets with EHs are drpped because middleboxes and routers, in
practice, need to obtain layer-4 information

2) Why do they need such layer-4 information? -- Because of the reasons
stated in our I-D.

Everytime this topic comes up, you argue that processing layer-4
information is not necessary, or ask why ops people do that.

This document answers that question, so that this gets clarified, and we
can move on to improve the current state of affairs.

Otherwise, we live pretending that EHs are deployable, when they are not.

Looking to the other side, or pretending that the problem doesn't exist
doesn't help to solve problems.

The goal of publishing this document is so that we don't have to rehash
the same discussion every time the topic of EHs come up.
-- 
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: Thu, 17 Mar 2016 07:59:37 +1300

On 17/03/2016 07:09, Fernando Gont wrote:
...
> the same discussion every time the topic of EHs come up.

Agreed.

   Brian

---

From: [email-masked]
Date: Thu, 17 Mar 2016 09:45:49 +0100

> the same discussion every time the topic of EHs come up.

If your goal was to avoid rehashing discussions about EHs then I think you would have been a lot more successful by not publishing this document.

There is no single common view on EHs that apply to all circumstances. Which is why I have strong doubts that whatever you write in this document will make any difference (not that I understand from this document what difference (as in recommendations) it is actually trying to make).

I think Alvaro's comment on draft-ietf-v6ops-ipv6-ehs-in-real-world also could apply to this draft:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-ehs-in-real-world/ballot/

If the working group is set on its path on publishing EH related documents, I'll shut up.

Best regards,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Thu, 17 Mar 2016 08:23:44 -0300

On 03/17/2016 05:45 AM, [email-masked] wrote:
>> 
>> The goal of publishing this document is so that we don't have to
>> rehash the same discussion every time the topic of EHs come up.
> 
> If your goal was to avoid rehashing discussions about EHs then I
> think you would have been a lot more successful by not publishing
> this document.

"Avoid rehashing a discussion" != "not ever talking about something".

Every time we talked about EHs, you asked the same question: "why do you
need to obtain the layer-4 information, if you're supposed to just fwd
packets?"

This document answers that question, among other things.

You also noted that "all this is well known" (which then I don't follow
why you asked the question in the first place), and that this stuff is
covered elsewhere -- but even when it was asked a couple of times, you
never said *where* it is covered.

> There is no single common view on EHs that apply to all
> circumstances.

I haven't seen any operator saying that what is said in our document is
incorrect.

What are the "other" views that supposedly do not agree with the one
stated in our document?

I get the impression that discussions on EHs are unpopular, because
people don't like to admit when there's a problem. But being n
engineering group, I think we better admit problems and do our best to
come up with solutions, than pretend there's no problem at all.

---

From: [email-masked]
Date: Thu, 17 Mar 2016 13:23:02 +0100

Fernando,

> come up with solutions, than pretend there's no problem at all.

the problems are well known, just that there aren't any solutions. so it is pretty pointless to continue to talk about the perceived problem ad infinitum.

cheers,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Thu, 17 Mar 2016 10:02:02 -0300

On 03/17/2016 09:23 AM, [email-masked] wrote:
> the problems are well known, just that there aren't any solutions. 

If the probems are well-known, why does the discussion revolve around
"why we need to find layer-4 information"? It has been asked at least
three times where else this is covered, and still you haven't mentioned
where.

When it comes to solutions, our I-D points a way forward.

Cheers,

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 17 Mar 2016 22:42:08 +0900

> need to obtain the layer-4 information, if you're supposed to just fwd

I disagree with the characterization of the problem. Intermediate routers
don't typically need to find the layer-4 header. If operators configure
them to do so, then such operators are also free to configure the boxes to
drop the packets if they can't find the layer-4 header.

As regards ACLs: the extension headers are a part of the packet just like
any other, and security policies can do whatever they wish with them. You
can certainly define a security policy that allows no extension headers at
all if you wish.

As regards hashing: traversing the whole length of the extension header
chain only to provide flow-based hashing is a bad use of processing power.
(If it's implemented in hardware, it's might also be a bad use of die
space, enercy, customer money, etc.) Using the flow label is much better.
So perhaps we should recommend that if hosts emit packets with extension
headers, they should also randomize the flowlabel.

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 17 Mar 2016 15:45:36 +0000

[email-masked] wrote:
> circumstances. Which is why I have strong doubts that whatever you
> write in this document will make any difference (not that I
> understand from this document what difference (as in recommendations)
> it is actually trying to make).

It has been pointed out numerous times - both to you and to others -
that this document is explicitly not making recommendations.  It's only
making observations and attempting to provide explanations for those
observations.

Nick

---

From: Fernando Gont <[email-masked]>
Date: Thu, 17 Mar 2016 12:44:33 -0300

On 03/17/2016 10:42 AM, Lorenzo Colitti wrote:
> On Thu, Mar 17, 2016 at 8:23 PM, Fernando Gont <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> I disagree with the characterization of the problem. Intermediate
> routers don't typically need to find the layer-4 header. If operators
> configure them to do so, then such operators are also free to configure
> the boxes to drop the packets if they can't find the layer-4 header.

That's not the point this I-D is making. What it is saying is that even
if you don't want to drop EHs, you may have to do so, for the reasons
noted in the I-D.

---

From: Tom Herbert <[email-masked]>
Date: Thu, 17 Mar 2016 09:35:56 -0700

> if you don't want to drop EHs, you may have to do so, for the reasons
I think the I-D presents a good arguments for why packets with EHs are
dropped and establishes that will intermediate devices commonly need
layer-4 "information". But this does not necessarily mean that
intermediate devices need to access the layer-4 header to get required
information (as the flow label demonstrates), nor has it been
established that they have to always parse the full header chain to
find the layer 4 header (the offset option
https://tools.ietf.org/html/draft-zhang-6man-offset-option-01 could be
used).

Section 8 make recommendations on action to take. In particular there
is a fair amount of detail on arbitrarily capping the length of
extension headers chain- this seems to assume that devices must parse
the full header chain to get layer-4 information they need. So I would
view this as one possible technique to evaluate, but it seems like
other alternatives (like the offset option) to explore should be
mentioned here also, or maybe this recommendation should be taken out.

Tom

---

From: joel jaeggli <[email-masked]>
Date: Thu, 17 Mar 2016 13:45:04 -0700

> the problems are well known, just that there aren't any solutions. 

I'm pretty sure that isn't an acceptable answer in the long run. If one
belives that we should be offering guidance to implementors and
operators such that filtering is either less a persistent violation of
expections or ceases to be an issue in the long term. simply pretending
that the issue doesn't exist is a pretty bad message to developers.

> so it is pretty pointless to continue to talk about the perceived problem ad infinitum.
> 
> cheers,
> Ole
> 
> 
>

---

From: [email-masked]
Date: Thu, 17 Mar 2016 22:09:30 +0100

Joel,

> that the issue doesn't exist is a pretty bad message to developers.

let me ask differently.

how is this "problem" any different from:
 - "unknown" L4 header
 - IPsec encryption
 - L4 encryption (it's all port 443)
 - tunnels

Cheers,
Ole

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 17 Mar 2016 21:48:32 +0000

>  - L4 encryption (it's all port 443)

none of "unknown" L4 headers, L4 encryption or tunnels are subject to
the catastrophic levels of packet loss as measured in
draft-ietf-v6ops-ipv6-ehs-in-real-world.  ipv6 ipsec wasn't measured in
that draft - it would probably have been useful if there were some easy
way to measure this.

It's not ok for the IETF to sit on its hands and pretend that this isn't
a protocol problem.  The EH mechanism as it stands is unworkable which
is causing breakage on production networks.  This needs attention from
the IETF because EHs provide core ipv6 functionality and without this
functionality, IPv6 is crippled as a protocol.

Nick

---

From: joel jaeggli <[email-masked]>
Date: Thu, 17 Mar 2016 14:53:58 -0700

> how is this "problem" any different from:

unknown is rather different than unfound if you're actually attempting
to parse the header chain. you still have a binary decision to make with
respect to forwarding or not.

>  - L4 encryption (it's all port 443)

Because if you filter any of these three that's generally the product of
a deliberate policy enforcement action rather than due to a collateral
damage from another decision.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 17 Mar 2016 22:29:34 +0000

> functionality, IPv6 is crippled as a protocol.

</chair>

I'm scratching my head on both of those statements. Help me out, if you would.

In there first statement, you assert that we're looking at a protocol problem. We may be, but that's not obvious to me. There is an issue with HBH headers, or at least with their implementation, which we are looking at in draft-ietf-6man-hbh-header-handling. Nalini Elkins has a problem with the lack of a counterpart to the IPv4 ident field, which she wants to address with a Destination Option in draft-ietf-ippm-6man-pdm-option. Several folks have issues with fragmentation and reassembly (draft-bonica-6man-frag-deprecate), but that is more about security policy and perceived application designer laziness than about issues with the header; it in fact fragments and reassembles if used for that purpose, and AFAIK is widely implemented.

You go on to say that IPv6 Extension Headers implement core functionality. I'll agree that the Security Header is core; I go to work using one of a couple of VPN technologies, and packet layer encryption is central to both. I'm hard pressed to say that the other headers are core; we don't use options in IPv4, and we don't seem to need these headers to make it work. Speaking wearing my protocol-droid hat, if I walk through a list of extension headers (HBH, Routing, Fragment, Destination Options, Security) I haven't heard anyone say "the protocol is incorrect; we need to move these bits over there and add these other bits somewhere else, or define some different processing algorithm". The only one we have deprecated is RH0, and even there, the issue isn't that RH0 can't be used to implement what in IPv4 we would call a Loose Source Route and Record; it's that even in IPv4 we decided that having that option was a security nightmare.

If we're looking at a protocol problem, we should be able to describe proposed changes to the protocol to fix it. I'm not hearing such things described, apart from draft-wkumari-long-headers.

Is the issue addressed in draft-wkumari-long-headers what we're talking about? If so, can we discard the bluster in tone and say that? Is there another issue? Can we describe it?

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 18 Mar 2016 09:10:33 +0900

>From the point of view of security, I don't see a difference. Not found
should be treated as unknown anyway.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 18 Mar 2016 09:12:36 +0900

On Fri, Mar 18, 2016 at 6:48 AM, Nick Hilliard <[email-masked]> wrote:

> draft-ietf-v6ops-ipv6-ehs-in-real-world.

And this is a protocol problem because...? IPv4 protocols other than TCP,
UDP and ICMP are probably subject to even more catastrophic loss than
extension headers, but we're not talking about fixing them.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 18 Mar 2016 16:33:45 +1300

On 18/03/2016 02:42, Lorenzo Colitti wrote:
...
> headers, they should also randomize the flowlabel.

We did: Proposed Standard RFC 6437 in 2011.

We also recommended that middleboxes should correctly process
extension headers: Proposed Standard RFC 7045 in 2013.
We have forbidden too-long header chains: RFC 7112 in 2014.
We're fixing the requirements for hop-by-hop options in 6man.

I see this draft (and the one on the IESG ballot) as being
operational commentaries on the consequences of those RFCs
being ignored.

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Fri, 18 Mar 2016 05:29:50 -0300

On 03/17/2016 09:10 PM, Lorenzo Colitti wrote:
> On Fri, Mar 18, 2016 at 6:53 AM, joel jaeggli <[email-masked]
> <mailto:[email-masked]>> wrote:
> 

Dropping as a result of unfound is unintended effect. That's the point.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 18 Mar 2016 21:20:03 +0900

> Dropping as a result of unfound is unintended effect. That's the point.

I don't think that's a useful argument. If you don't know what you're
doing, everything is unintended.

I think we should assume that network administrators know that EHs exist
and that they are making explicit decisions on whether to filter them or
not, based on the capabilities of their hardware.

If an admin configures a policy that says "from next-header tcp" and
doesn't care to check the documentation as to whether that means "the next
header after the IPv6 header is TCP" or "the last header in the chain is
TCP"... well, they get what they deserve

No different from someone who writes a policy that says "allow port 80" to
protect a webserver and is surprised when anyone can talk to any port on
the webserver by sending packets with a source port of 80.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 18 Mar 2016 10:28:56 -0300

On 03/18/2016 09:20 AM, Lorenzo Colitti wrote:
> On Fri, Mar 18, 2016 at 5:29 PM, Fernando Gont <[email-masked]

Isn't that the point we're making in our document??

> doesn't care to check the documentation as to whether that means "the
> next header after the IPv6 header is TCP" or "the last header in the
> chain is TCP"... well, they get what they deserve

This is not what we're saying in the I-D.

What we are saying is that, based on the usual capabilities of routers,
a guy does now what he is doing and that has read the documentation,
cannot do what he's meaning to do. Hence he has to resort to dropping
packets that he's not really meaning to drop.

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 18 Mar 2016 15:59:14 +0000

Fred Baker (fred) wrote:
> In there first statement, you assert that we're looking at a protocol
> problem. We may be, but that's not obvious to me.

for non-trivial EH chains, most people seem to be acknowledging that
start-to-end EH chain walking is too difficult for vendors to implement
in silicon and is too expensive to handle in software.  Vendors could
implement it, but the cost-to-return ratio doesn't work.

If the ietf designs a protocol which is too difficult / expensive for
vendors to implement or where the cost-to-return doesn't work, then the
problem lies with the protocol definition, not with the vendors' lack of
inclination to implement it.

> There is an issue
> with HBH headers, or at least with their implementation, which we are
> looking at in draft-ietf-6man-hbh-header-handling.

hbh is a separate issue and we should probably park that for this
discussion.

> Nalini Elkins has
> a problem with the lack of a counterpart to the IPv4 ident field,
> which she wants to address with a Destination Option in
> draft-ietf-ippm-6man-pdm-option. Several folks have issues with
> fragmentation and reassembly (draft-bonica-6man-frag-deprecate), but
> that is more about security policy and perceived application designer
> laziness than about issues with the header; it in fact fragments and
> reassembles if used for that purpose, and AFAIK is widely
> implemented.

The ipv6-ehs-in-real-world draft notes that if you attach a
fragmentation extension header to a packet, it stands a good chance of
being dropped on the floor.  Protocols don't work when they are dropped
by the network.  This matters for frags / ipsec.

> You go on to say that IPv6 Extension Headers implement core
> functionality. I'll agree that the Security Header is core; I go to
> work using one of a couple of VPN technologies, and packet layer
> encryption is central to both. I'm hard pressed to say that the other
> headers are core;

ipsec and fragmentation are the two EHs that concern me.  Other people
may have other opinions.  Personally, I see no future for either RH or
HBH headers, but that is a personal opinion.

> some different processing algorithm". The only one we have deprecated
> is RH0, and even there, the issue isn't that RH0 can't be used to
> implement what in IPv4 we would call a Loose Source Route and Record;
> it's that even in IPv4 we decided that having that option was a
> security nightmare.

agreed.  IPv4 options stopped working in the mid 90s but no-one noticed
because they didn't do anything very important.  The result is that
there is plenty of silicon being sold today which is unable to forward
packets with ipv4 options, and no-one cares.

> If we're looking at a protocol problem, we should be able to describe
> proposed changes to the protocol to fix it. I'm not hearing such
> things described, apart from draft-wkumari-long-headers.
> 
> Is the issue addressed in draft-wkumari-long-headers what we're
> talking about? If so, can we discard the bluster in tone and say
> that? Is there another issue? Can we describe it?

The draft deliberately avoids prescription of a fix. First, there are a
lot of people in this WG claiming that there isn't a problem in the
first place and second, the authors want to try to get consensus that
there is a problem before prescribing a fix.

The authors have discussed this offline and feel that if the WG came to
a consensus that there is a problem, that it would be better to poll the
WG about potential fixes or workarounds.

Personally, I think there is a problem and that the problem could be
helped in the long term by drastically reining in the EH chain limits
prescribed in 7112 (namely, 1280 bytes).

If there are minimum acceptable limits imposed, then the obvious choices
would either to limit by the number of headers or the number of octets
used for headers.  The latter would be much simpler to implement.
Gaining consensus on a reasonable value for either would be very
difficult because the IETF has a long history of having difficulties
settling on what are ultimately arbitrary numbers.  From a practical
point of view, vendor input might be advisable, but I fear this is
bikeshed territory.

draft-wkumari-long-headers discourages EHs completely.  Personally, I
don't think this is workable because of ipsec / fragmentation requirements.

draft-zhang-6man-offset-option is also not ideal.  From a technical
point of view, it is difficult to implement due to packet lookahead
limitations in silicon.  Also the IPR statement allows retaliatory
infringement action, which some people may have issues with.

Nick

---

From: [email-masked]
Date: Fri, 18 Mar 2016 19:34:38 +0100

Nick,

> by the network.  This matters for frags / ipsec.

Fragment drop probability is not significantly different between IPv6 and IPv4.

https://labs.ripe.net/Members/emileaben/ripe-atlas-packet-size-matters
  "We measure that about 8.5% to 9% of RIPE Atlas probes have problems with fragmentation in IPv4, and 10% of probes have fragmentation problems in IPv6. The IPv6 number agrees with a study that was performed by NLNetLabs in 2012, at which point the number of deployed RIPE Atlas probes was considerably smaller then now. In the meantime NLNetLabs have resumed their work on fragmentation, and the RIPE NCC is closely cooperating with this effort to better inform the Internet operations and research communities on this issue."

Which might be more of an argument against fragmentation at the network layer than EHs in particular.

Best regards,
Ole

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Mon, 21 Mar 2016 06:09:37 +0000

After a week's debate, with 13 people posting, I am hard pressed to say that there is a consensus in support of the adoption of this draft.

> On Mar 11, 2016, at 2:01 AM, Fred Baker (fred) <[email-masked]> wrote:
>

---

From: Fernando Gont <[email-masked]>
Date: Mon, 21 Mar 2016 13:20:48 +0100

> Which might be more of an argument against fragmentation at the network layer than EHs in particular.

How do you explain the drop rate of all other EHs?

---

From: Gert Doering <[email-masked]>
Date: Mon, 28 Mar 2016 20:38:44 +0200

Hi,

On Wed, Mar 16, 2016 at 06:38:12PM +0100, [email-masked] wrote:
> that's well known. 

Well, the advertising literature for IPv6 claims that the EHs are there
to make processing *easier*...

Maybe we should just document this formally "the IETF considers the
difficulties caused by EHs a feature, so feel free to drop them if that
annoys you, or stay with IPv4" and go on?

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Joe Touch <[email-masked]>
Date: Mon, 28 Mar 2016 14:29:15 -0700

> to make processing *easier*...

The alternative in IPv4 is unstructured header extensions, which are
harder to handle.

In IPv6, at least the HBH and E2E headers are separated.

Note, however, that the idea of an offset to "jump" to the transport
header makes no sense. There's no rule that HBH header lengths never
change in transit, which means you just end up with another field that
might be inconsistent with the actual header.

Better to admit that something that runs at the speed of an endpoint
should be setting a flow label.

Joe

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Mon, 28 Mar 2016 21:36:28 +0000

> might be inconsistent with the actual header.

Don't tell the 6man chairs. They think that changing the length of a HBH header (or any header) in transit would be a problem, and I can confirm that in the event that there is an AH header in the packet. We had that discussion in 6man at IETF 94.

---

From: Joe Touch <[email-masked]>
Date: Mon, 28 Mar 2016 14:40:21 -0700

On 3/28/2016 2:36 PM, Fred Baker (fred) wrote:
> Don't tell the 6man chairs. They think that changing the length of a
> HBH header (or any header) in transit would be a problem, and I can
> confirm that in the event that there is an AH header in the packet. We
> had that discussion in 6man at IETF 94.

It should not be a problem because it is not prohibited. I agree that it
probably IS a problem, but that just means more devices that claim
compliance inaccurately.

This isn't going to be fixed by OPS or 6MAN docs. IMO, we really need to
start talking about compliance certification.

Joe

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 29 Mar 2016 11:21:07 +1300

> Don't tell the 6man chairs. They think that changing the length of a HBH header (or any header) in transit would be a problem, and I can confirm that in the event that there is an AH header in the…

In any case, that issue is foreseen in
https://tools.ietf.org/html/draft-zhang-6man-offset-option-01#section-6

By the way, would an incorrect offset option be any more harmful
than an incorrect IHL (with a correponding checksum) in IPv4?

  Brian

---

From: Tom Herbert <[email-masked]>
Date: Mon, 28 Mar 2016 15:41:23 -0700

> than an incorrect IHL (with a correponding checksum) in IPv4?
I would speculate that someone might use the offset option to spoof
the transport header. The idea would be that an attacker would use the
options to spoof the transport header inside some other EH. So a FW
might inspect the fake header and and end host would process the real
one. A solution for this would be that end hosts need to validate the
option is correct.

Tom

---

From: Joe Touch <[email-masked]>
Date: Mon, 28 Mar 2016 16:30:43 -0700

> https://tools.ietf.org/html/draft-zhang-6man-offset-option-01#section-6

Simple counterexample - quickstart (RFC4782).

Intermediate routers are allowed to indicate they do not support the
option by *deleting* it.

Note that routers that do this have no idea about the proposed
offset-option, so this will interfere with the calculated offset.

That's one example. I wonder how many other existing IPv6 HBH headers
are *not prohibited* from changing length, being added, or being deleted
en-route.

Joe

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Mon, 28 Mar 2016 23:44:37 +0000

> On Mar 28, 2016, at 4:30 PM, Joe Touch <[email-masked]> wrote:
> 
> 
> 

There's deleting and deleting. One could move any succeeding options forward 8 bytes (not six, as the document says), shorten the HBH header by 8 bytes, remove the HBH option entirely if it is now empty perhaps, and move everything else forward by 8+ bytes as well. Or, one could overwrite the quickstart option with an 8 byte PAD option. Guess which one I would do...

---

From: Joe Touch <[email-masked]>
Date: Mon, 28 Mar 2016 16:50:48 -0700

On 3/28/2016 4:44 PM, Fred Baker (fred) wrote:
> There's deleting and deleting. One could move any succeeding options
> forward 8 bytes (not six, as the document says), shorten the HBH header
> by 8 bytes, remove the HBH option entirely if it is now empty perhaps,
> and move everything else forward by 8+ bytes as well. Or, one could
> overwrite the quickstart option with an 8 byte PAD option. Guess which
> one I would do...

There are many ways that COULD work, but unfortunately there are as many
that won't.

The trouble happens when (not if) this jump option is part of a header
that is modified by an endpoint that knows the old option and not this
jump one. There's no rule that requires that HBH headers be modified in
a way that won't affect offsets, and unless the offset is
mandatory-to-support for intermediate devices, the situation gets worse
as new options are added.

Joe

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 29 Mar 2016 13:12:06 +1300

>> Intermediate routers are allowed to indicate they do not support the

I find it disturbing that we published an RFC suggesting that, which
is IMNSHO inconsistent with the intent, if not the words, in RFC2460. My
distress is increased by the fact that I ballotted No Objection to it
at the time. The Gen-ART reviewer picked up the issue but it was only
partially fixed. Fortunately it's only Experimental.

> There's deleting and deleting. One could move any succeeding options forward 8 bytes (not six, as the document says), shorten the HBH header by 8 bytes, remove the HBH option entirely if it is now…

Yes, and if overwriting with a PAD had been mandated in the RFC, we wouldn't
be discussing this example.

>> are *not prohibited* from changing length, being added, or being deleted

Yes. It's a bug in RFC2460 that this ambiguity arises.

   Brian

---

From: Joe Touch <[email-masked]>
Date: Mon, 28 Mar 2016 17:15:17 -0700

> Yes. It's a bug in RFC2460 that this ambiguity arises.

I took it as a feature. IMO, the idea of a chain enables this feature,
and I don't think it should be so quickly dismissed as potentially useful.

I appreciate that not everyone agrees, though.

Joe

---

From: Mark Smith <[email-masked]>
Date: Tue, 29 Mar 2016 13:25:17 +1100

> and I don't think it should be so quickly dismissed as potentially useful.

So I think the question to ask about such a packets is what does the source
address now mean when it arrives?

Deleting information from the packet means the source address is
responsible for all the field values, but it isn't possible to know that
some was deleted on the way.

Adding/updating is far more ambiguous. The source address really just now
means that the specified device decided to send a packet and that is it.
There is no way to tell what was in the original packet - everything else
could have been added or replaced along the way.

RH0 allowed updating in the network, however it preserved and carried the
list of devices that updated the destination address.

> I appreciate that not everyone agrees, though.

I wouldn't want to be troubleshooting those sorts of packets if I don't
know and can't be sure if the source address of the packet is the creator
of all of its contents.

I think tunneling is the correct approach for "modifying" packets in the
network, because it completely preserves the semantics of the inner
packet's fields.

Regards,
Mark.

---

From: Joe Touch <[email-masked]>
Date: Mon, 28 Mar 2016 19:59:22 -0700

On 3/28/2016 7:25 PM, Mark Smith wrote:
> 
> On 29 Mar 2016 11:15 AM, "Joe Touch" <[email-masked]
> <mailto:[email-masked]>> wrote:
>>
>>
>>
> So I think the question to ask about such a packets is what does the
> source address now mean when it arrives?
> 
> responsible for all the field values,

That's provably not true, as per the RFC I cited previously.

> but it isn't possible to know that some was deleted on the way.
> 
> Adding/updating is far more ambiguous.

Route headers are updated too.

> The source address really just
> now means that the specified device decided to send a packet and that is
> it. There is no way to tell what was in the original packet - everything
> else could have been added or replaced along the way.

If that matters, it's up to the other layers to decide. That's partly
why TCP and UDP include a subset of the IP header values in their
checksum, but also why they do not include the entirety of the IP header
including options.

...
> network, because it completely preserves the semantics of the inner

Encapsulation does that too, when honored as it is defined.

Joe

---

From: [email-masked]
Date: Tue, 29 Mar 2016 10:31:05 +0200

> I appreciate that not everyone agrees, though.

It does break PMTUD though.

Best regards,
Ole

---

From: Mark Smith <[email-masked]>
Date: Tue, 29 Mar 2016 20:37:34 +1100

> It does break PMTUD though.

Which I think is because of an expectation that the device identified in
the packet source address (the "sender") is responsible for creating the
whole packet. It can't be a "unicast source address" field if there are
multiple sources of the information in the packet.

It also breaks troubleshooting methods and assumptions about the source
address field that have been true for IPv6, IPv4 and many, if not all, past
layer 3 protocols.

One perspective on tunneling is that when it modifies the packet, it adds
another source address field to record that another device,  other than the
original packet source device, has made additions to the packet.

Regards,
Mark.

---

From: [email-masked]
Date: Tue, 29 Mar 2016 11:51:32 +0200

> Which I think is because of an expectation that the device identified in the packet source address (the "sender") is responsible for creating the whole packet. It can't be a "unicast source address" field if there are multiple sources of the information in the packet.
> 
> It also breaks troubleshooting methods and assumptions about the source address field that have been true for IPv6, IPv4 and many, if not all, past layer 3 protocols.
> 
> One perspective on tunneling is that when it modifies the packet, it adds another source address field to record that another device,  other than the original packet source device, has made additions to the packet.

indeed, and is why 2460 bis states:
   "Extension headers must never be inserted by any node other than the
   source of the packet.  IP Encapsulation must be used to meet any
   requirement for inserting headers, for example, as defined in
   [RFC2473]."

cheers,
Ole

---

From: Mark Smith <[email-masked]>
Date: Tue, 29 Mar 2016 21:18:19 +1100

On 29 Mar 2016 8:51 PM, <[email-masked]> wrote:
> > Which I think is because of an expectation that the device identified
in the packet source address (the "sender") is responsible for creating the
whole packet. It can't be a "unicast source address" field if there are
multiple sources of the information in the packet.
> >
> > One perspective on tunneling is that when it modifies the packet, it
adds another source address field to record that another device,  other
than the original packet source device, has made additions to the packet.
>    requirement for inserting headers, for example, as defined in

I suppose given Joe's example experimental RFC, 2460bis should also be
explicit about EHs not being able to be deleted on the trip too.

Regards,
Mark.

---

From: Joe Touch <[email-masked]>
Date: Tue, 29 Mar 2016 08:40:26 -0700

> It does break PMTUD though.

Only increasing the length would break PMTUD, but that's already
deprecated in favor of PLMTUD - which would still work.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 29 Mar 2016 08:43:44 -0700

On 3/29/2016 2:37 AM, Mark Smith wrote:
> 
> On 29 Mar 2016 7:31 PM, <[email-masked]
> <mailto:[email-masked]>> wrote:
>>
> address field that have been true for IPv6, IPv4 and many, if not all,
> past layer 3 protocols.

I presume then that you're then arguing that NATs shouldn't exist? (I'd
be glad if that were the case, but it's clear it's not).

> than the original packet source device, has made additions to the packet.

Yes, but encapsulation performs a very similar function. That's why we
try very hard to avoid cross-layer dependencies (though the idea of a
pseudoheader in the checksum of transports breaks this) and why
intermediate devices shouldn't be peeking past layer 3.

So again, I'm interested to see this perspective on the "sanctity of the
header chain" when nearly every other presumably "immutable" field of
the header has been the subject of modification.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 29 Mar 2016 08:44:56 -0700

On 3/29/2016 3:18 AM, Mark Smith wrote:
> 
> On 29 Mar 2016 8:51 PM, <[email-masked]
>> > Which I think is because of an expectation that the device
> identified in the packet source address (the "sender") is responsible
> for creating the whole packet. It can't be a "unicast source address"
> field if there are multiple sources of the information in the packet.
>> >
>> > It also breaks troubleshooting methods and assumptions about the
> source address field that have been true for IPv6, IPv4 and many, if not
> all, past layer 3 protocols.
>> >

And that only HBH MAY be modified (i.e., E2E MUST NOT be modified).

However, this is also going to require more than an assertion in a -bis
doc; it requires issuing updates to every dependent doc that isn't
compliant.

Joe

---

From: [email-masked]
Date: Tue, 29 Mar 2016 20:13:17 +0200

Joe,

> deprecated in favor of PLMTUD - which would still work.

in 6man we're in the process of moving RFC1981 to Internet Standard.
in your view, what should we do with this document?

Best regards,
Ole

---

From: Joe Touch <[email-masked]>
Date: Tue, 29 Mar 2016 12:24:59 -0700

> in your view, what should we do with this document?

I wasn't aware we were still bothering differentiating tracks within
standards-track (does anyone really care?), but if we are, then we might
reconsider whether to shift this to IS.

IS indicates a level of confidence that I think we don't have, given the
level to which ICMPs are filtered and the potential of the techniques in
that RFC to result in blackholes if not otherwise addressed.

Finally, I am astounded that this change would occur in 6man. This is
not an IPv6-specific doc . Any such change should happen in INTAREA IMO.
IETF WGs have some serious issues with the concept of scope, IMHO.

Joe

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 29 Mar 2016 19:30:25 +0000

> On Mar 29, 2016, at 12:24 PM, Joe Touch <[email-masked]> wrote:
> 
> 
> 

Perhaps. https://tools.ietf.org/html/rfc6410

> IETF WGs have some serious issues with the concept of scope, IMHO.

RFC 1981 is specific to IPv6. RFC 4821, as you say, is about TCP and transports that operate like it.

---

From: Mark Smith <[email-masked]>
Date: Wed, 30 Mar 2016 06:53:45 +1100

> be glad if that were the case, but it's clear it's not).

Yes.

> intermediate devices shouldn't be peeking past layer 3.

I agree that encapsulation/tunnelling is performing that function. I'm
observing that when tunnelling occurs an additional source address
field is added that records the identity of the device that added the
tunnelling encapsulation. That address and the tunnelling protocol
creates a very clear boundary between what the original host sent and
what has been added and by whom during tunnelling/encapsulation.

> the header has been the subject of modification.

So when packets are modified while they travel through the network,
the identity of the modifier isn't recorded, which makes
troubleshooting harder if the modifications fail. So my philosophy is
that packet modification in the network should be minimised as much as
possible, even though some fields are mutable because they're not
covered by e.g, TCP or UDP pseudoheader checksums.

That really only leaves the hop count field as one that is always
going to be modified. I think Flow label and TC are the other two that
are mutable. In the case of flow label, there are fairly strict rules
on when they can be modified by the network (if FL=0). TC has no
strict rules, however within in a network the devices that may modify
TC are usually limited to the edge and are well known as performing
that role, making them easier to identify if they're broken.

Regards,
Mark.

---

From: Joe Touch <[email-masked]>
Date: Tue, 29 Mar 2016 14:16:54 -0700

On 3/29/2016 12:30 PM, Fred Baker (fred) wrote:
> RFC 1981 is specific to IPv6.

Sorry - text was too small and I mapped this to 1191. Agreed- this is IPv6.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 29 Mar 2016 14:29:28 -0700

PS  - what misdirected me was the idea that this would go to IS when it
referred to an outdated version of the IPv6 spec. Given it predates
RFC2460, it seems odd to have it go IS.

Joe

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 29 Mar 2016 21:55:47 +0000

I would assume the reference needs to be updated, just as 2460bis is an update.

> On Mar 29, 2016, at 2:29 PM, Joe Touch <[email-masked]> wrote:
>

---

From: Fernando Gont <[email-masked]>
Date: Tue, 29 Mar 2016 23:31:37 +0200

> that RFC to result in blackholes if not otherwise addressed.

One could easily s/ICMPs/EHs/ in your statement....

> not an IPv6-specific doc . Any such change should happen in INTAREA IMO.

Why so? I think 6man is where the IPv6 std track expertise is.

Thanks,