Subject: [v6ops] Next steps for IPv6 EHs in Real World (draft-ietf-v6ops-ipv6-ehs-in-real-world)

From: Fernando Gont <[email-masked]>
Date: Wed, 06 May 2015 18:13:07 -0300

Folks,

Question to the wg:

Folks keep bringing up the reasons for which operators filter IPv6
packets with EHs (the reasons have been discussed on this mailing-list a
few times already). Something along these lines was present in Section
3 of
<https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-in-real-world-01>
but we removed that section in later revisions (prior to the wg call for
adoption of this document).

A number of folks have argued that we should reincorporate that section.
Me, I think it would be useful, but can live without reincorporating
that section...

It would be nice to hear from the wg about this. Thoughts?

Thanks!

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

---

From: Mark ZZZ Smith <[email-masked]>
Date: Thu, 7 May 2015 00:05:00 +0000 (UTC)

Hi,
I don't have a strong opinion on whether it should be reincorporated or not, as I haven't kept up with that discussion.
However, if it does get included, I think the following statement needs more clarification:
"Many IPv6 router implementations suffer from a negative performance   impact when IPv6 Extension Headers are employed."
Is this really the case? It seems to me that this is saying that "Many IPv6 router implementations" are inspecting EHs by default, which then means many routers are vulnerable to the EH based DoSes and other issues mentioned by default.
I'd expect routers by default to have just processed/forwarded IPv6 packets based on the fixed IPv6 header fields, ignoring EHs and allowing fast path forwarding, and to only start looking at EHs if configured to via ACLs etc.
I think the above statement is effectively implying that fast path forwarding of IPv6 isn't a default in many IPv6 router implementations, and I'd be quite surprised if that is true, which is why I think more clarification would be useful.
Regards,Mark.
      From: Fernando Gont <[email-masked]>
 To: "[email-masked]" <[email-masked]> 
Cc: "[email-masked]" <[email-masked]>; V6ops Chairs <[email-masked]>; Merike Kaeo <[email-masked]> 
 Sent: Thursday, 7 May 2015, 7:13
 Subject: [v6ops] Next steps for IPv6 EHs in Real World (draft-ietf-v6ops-ipv6-ehs-in-real-world)
   
Folks,

Question to the wg:

Thanks!

Best regards,

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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 07 May 2015 12:29:40 +1200

On 07/05/2015 12:05, Mark ZZZ Smith wrote:
> Is this really the case? 

I'm guessing that a more accurate statement would be
"Many IPv6 router implementations that also include some firewall functionality suffer..."
but I agree that it should be better substantiated.

My feeling is that describing the objective reasons why some routers behave
this way is a good idea. Otherwise, the reader is left with a mystery to solve.

   Brian

>It seems to me that this is saying that "Many IPv6 router implementations" are inspecting EHs by default, which then means many
routers are vulnerable to the EH based DoSes and other issues mentioned by default.

---

From: Mark ZZZ Smith <[email-masked]>
Date: Thu, 7 May 2015 01:41:27 +0000 (UTC)

Hi,
      From: Brian E Carpenter <[email-masked]>
 To: Mark ZZZ Smith <[email-masked]>; Fernando Gont <[email-masked]>; "[email-masked]" <[email-masked]> 
Cc: "[email-masked]" <[email-masked]>; V6ops Chairs <[email-masked]>; Merike Kaeo <[email-masked]> 
 Sent: Thursday, 7 May 2015, 10:29
 Subject: Re: [v6ops] Next steps for IPv6 EHs in Real World (draft-ietf-v6ops-ipv6-ehs-in-real-world)

/ I don't think I've come across a router that doesn't have some sort of firewall functionality (i.e., basic packet filters/ACLs), so I'm in particular interested in default behaviour.
/ My expectation is that hardware forwarding platforms forward IPv6 packets at the same rate out of the box, regardless of which EHs are present in the IPv6 packet, and would only resort to slow path processing of EHs if I configure the router to look beyond what is necessary to forward the IPv6 packet. That would usually only apply to a subset of packets, specified by source and/or destination IPv6 address, meaning that the majority of IPv6 packets will still be fast path forwarded. The above seems to be implying the default is the opposite of my expectation in many cases. 
/ Regards,Mark. 

  Brian

---

From: [email-masked]
Date: Thu, 07 May 2015 07:53:51 +0200 (CEST)

> My expectation is that hardware forwarding platforms forward IPv6
> packets at the same rate out of the box, regardless of which EHs are
> present in the IPv6 packet, and would only resort to slow path
> processing of EHs if I configure the router to look beyond what is
> necessary to forward the IPv6 packet.

Note that there are hardware forwarding platforms which don't have a
"slow path". A packet is either forwarded in hardware, or it is not
forwarded at all (i.e. dropped).

Steinar Haug, AS 2116

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 07 May 2015 19:16:25 +1200

Hi Mark,
On 07/05/2015 13:41, Mark ZZZ Smith wrote:
> / I don't think I've come across a router that doesn't have some sort of firewall functionality (i.e., basic packet filters/ACLs), 

But there's a big difference between those two.

ACLs = just look at the addresses

basic packet filters = look at the 5-tuple, and the whole problem here
is that extracting the 5-tuple becomes hard with EH present, and impossible
with unknown EH present.

But I agree that the default is what needs to be right (see RFC 7045 again).

   Brian

> so I'm in particular interested in default behaviour.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 7 May 2015 07:45:42 +0000

> On May 7, 2015, at 12:05 PM, Mark ZZZ Smith <[email-masked]> wrote:
> 
> Hi,
> 
> "Many IPv6 router implementations suffer from a negative performance
>    impact when IPv6 Extension Headers are employed."
> 

If it is the case, I think we need a list of those routers that by default violate RFC 2460 by inspecting past the HbH header when they are not the destination of the packet.

What I have been trying to get Fernando to do is identify under what conditions that might be true, rather than paint all equipment from all vendors under all conditions with slime. If the router has a filter (ACL) that forces it to parse the headers to find a TCP header, and the parsing is dumped to a slower path, that would be an example, and would be a valid example to bring out. But I don’t accept sliming all equipment from all vendors under all circumstances. It’s not the case.

> Regards,
> Mark.
> <https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-in-real-world-01 <https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-in-real-world-01>>
> e-mail: [email-masked] <mailto:[email-masked]> || [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>
> 
>

---

From: [email-masked]
Date: Thu, 07 May 2015 09:58:53 +0200 (CEST)

> What I have been trying to get Fernando to do is identify under what conditions that might be true, rather than paint all equipment from all vendors under all conditions with slime. If the router has a filter (ACL) that forces it to parse the headers to find a TCP header, and the parsing is dumped to a slower path, that would be an example, and would be a valid example to bring out. But I don$,1ry(Bt accept sliming all equipment from all vendors under all circumstances. It$,1ry(Bs not the case.

Having argued for the need to inspect/skip past EHs to find TCP/UDP
headers: In my experience this is very much *explicitly configured*
behavior, not something the routers do by default.

Steinar Haug, AS 2116

---

From: Tim Chown <[email-masked]>
Date: Thu, 7 May 2015 09:20:00 +0100

Hi,

> On 7 May 2015, at 08:45, Fred Baker (fred) <[email-masked]> wrote:
> 
> 
>> On May 7, 2015, at 12:05 PM, Mark ZZZ Smith <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi,
>> 

The original point of the draft, which has perhaps been lost somewhat as discussion has drifted, was to handwave to an observable problem, to implicitly note there was an impact on applications/protocols using EHs, and to encourage more measurement/investigation of the problem.

I think the discussion we’re on now would be better put into a follow-up text, so we can ship the original problem statement. I suspect the follow-up will be more heavily debated, witness the (lack of) progression of https://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-02 <https://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-02>, but my preference would be to stop tinkering, to ship, and focus on a new document.

Tim

>> From: Fernando Gont <[email-masked] <mailto:[email-masked]>>
>> To: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>; V6ops Chairs <[email-masked] <mailto:[email-masked]>>; Merike Kaeo <[email-masked] <mailto:[email-masked]>>

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 7 May 2015 10:49:52 +0000

I would keep the 'reasons/explanations' in a separate document and keep
the 'facts/measurements' in this I-D.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 7 May 2015 13:26:04 +0200 (CEST)

> behavior, not something the routers do by default.

As stated before, all Cisco 6500/7600 with SUP720/RSP720 will as far as I 
know, slow-path packets with fragmentation header by default. As far as I 
know, fragmentation header is an extension header.

As per what Fernando wrote again initially, I still object to the word 
"filter" being used. Filter for me (still) conveys intent, which as far as 
I can tell, at least in the above case isn't the case.

So we need to be very much granular in our language. All extension headers 
are most likely not treated equaly, the length of the header chain might 
change how they are treated etc.

So basically, I want the entire document changed so that "filtering" is 
replaced by "being dropped" or similar wording that doesn't convey 
intent on behalf of the people running the device.

So, for instance, I would like the abstract to be changed to:

Abstract

    This document presents real-world data regarding the extent to which
    packets with IPv6 extension headers are dropped in the Internet (as
    measured in August 2014), and where in the network such drops
    occurs.  The aforementioned results serve as a problem statement that
    is expected to trigger operational advice on the packet handling of IPv6
    packets carrying IPv6 Extension Headers, so that the situation
    improves over time.  This document also explains how the
    aforementioned results were obtained, such that the corresponding
    measurements can be reproduced by other members of the community.

and just to be clear. I want EHs to work on the Internet. I support this 
document in all other aspects. I am just tired of all blame being 
historically put on "stupid ISPs" or "stupid administrators" who 
intentionally configure their equipment to do bad things, like drop "all 
ICMP packets", when in at least some cases, the ICMPs were not making it 
to the destination because of load balancers or ECMP routing would send 
the ICMP packet to the wrong place.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 May 2015 07:53:55 -0400

On May 7, 2015, at 7:26 AM, Mikael Abrahamsson <[email-masked]> wrote:
> 
> So basically, I want the entire document changed so that "filtering" is replaced by "being dropped" or similar wording that doesn't convey intent on behalf of the people running the device.

+1!

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 7 May 2015 12:09:01 +0000

> On May 7, 2015, at 11:26 PM, Mikael Abrahamsson <[email-masked]> wrote:
> 
> As stated before, all Cisco 6500/7600 with SUP720/RSP720 will as far as I know, slow-path packets with fragmentation header by default. As far as I know, fragmentation header is an extension header.

Even when it is not addressed to the router and no ACL is involved? I think you’ll find that the question doesn’t come up unless it is required to process the header chain.

Fernando’s statement
      "Many IPv6 router implementations suffer from a negative performance
       impact when IPv6 Extension Headers are employed.”
is hard to read as other than a blanket statement - "add an extension header, take the slow path". That statement means that routers are processing extension headers beyond the hop-by-hop header in every circumstance. I’m sorry, I can’t imagine why they would. In some cases (firewall functionality, ACLs, and packets addressed to the router), yes, but not every packet forwarded; doing so would be a violation of RFC 2460 and would be a waste of effort. That is what I have objected to. I would like to see an accurate statement, if there is going to be one. I’ll note Tim Chown’s comment in passing.

SUP720 is, by the way, beyond its shelf life. That doesn’t mean they aren’t out there, of course, but they’re not current product.

On SUP720 extension header processing: per http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8054d37d.html, dated 2006:

"Because the Hop-by-Hop EH must be fully processed, it is handled by the CPU and the IPv6 traffic that contains a Hop-by-Hop EH will go through the slow forwarding path. This rule applies to all vendors. Hardware forwarding is not feasible in this case."

http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8054d37d.html#wp9000161 (same paper, table 2), states that IPv6 with EH other than Hop-by-Hop, in the presence of an ACL looking at higher layer headers, is processed in hardware unless "Note: If the length of the extension header chain (sum of the lengths of all EH in the chain) is larger than the resources allocated in hardware, the packet is punted to the software path as explained later in this section.”

on the length issue:

"Due to the potential combinations and lengths of extension headers, the overall size of the chain will vary. In Cisco routers, when the size of the EH chain exceeds the resources allocated in HW and upper layer protocol filters are applied, the IPv6 traffic will be software switched by the Line-Card CPU. The packet shown in Figure 4 has a 72 bytes long EH chain, which means that a hardware forwarding platform that was designed to handle 64 bytes of EH data will have to software switch this packet. With the current IPv6 applications and services however, this would be an infrequent event. Moreover, packets with very long EH chains are generally control plane packets (such as the one depicted in Figure 4) which have a very low rate, so the impact on the router is not significant."

You can argue the rate implication. But the extension header had to be longer than 64 bytes to make it a question.

So, yes, there are cases in which it will need to software-switch a packet. It’s an end-of-life product, and "there are cases" is quite a bit different from "every packet"

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 07 May 2015 13:58:22 +0100

On 07/05/2015 13:09, Fred Baker (fred) wrote:
> So, yes, there are cases in which it will need to software-switch a
> packet. It’s an end-of-life product, and "there are cases" is quite a
> bit different from "every packet"

this has been extensively discussed in various places, including here.
PFC3 based products are basically broken in this regard and there is a
global configuration option on IOS to either forward all packets with EHs
unilaterally, drop them unilaterally or else punt them unilaterally - no
exceptions, and this will override anything defined in an ACL.  PFC3 cards
are EoL, but as you correctly point out, there are still a great many of
them in operation on the internet.

Other routers will have similar issues, but in edge cases rather than for
all EH packets.  Packet forwarding on routers is generally handled by
inspection of the first N bytes of a packet and making a decision on that.
 If the EH falls within this N bytes, then the router will probably be able
to make a decision about the EH.  If it doesn't fall within this N bytes,
then it won't be able to take that EH into account.

The issue here is to what degree can you have your cake and eat it, i.e.
rfc1925, section 7.  It is certainly possible to design hardware which will
inspect up to 65536 bytes of packet, but it will be expensive and there may
be performance implications in iterating through large numbers of EHs.  The
router vendors generally seem to have made a choice to build hardware which
can inspect up to a certain depth (e.g. 128 / 256 / 384 bytes), but no
further.  From an engineering stand-point, this is an acceptable compromise
for my requirements.  Other people may have different opinions.

Nick

---

From: Tim Chown <[email-masked]>
Date: Thu, 7 May 2015 14:41:53 +0100

> On 7 May 2015, at 12:53, Ted Lemon <[email-masked]> wrote:
> 

That’s a very good suggestion.

Tim

---

From: joel jaeggli <[email-masked]>
Date: Thu, 7 May 2015 16:09:39 +0100

> forwarded at all (i.e. dropped).

fast path or no path is in fact pretty common. slow path if it exists is
a trivial dos vector.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 7 May 2015 18:33:49 +0200 (CEST)

> Even when it is not addressed to the router and no ACL is involved? I think you’ll find that the question doesn’t come up unless it is required to process the header chain.

Yes, ALWAYS. At least that's my experience with SUP720. We didn't have any 
ACLs on the device where I saw the drops.

Oh, and reading 
http://mailman.nanog.org/pipermail/nanog/2011-September/040653.html I 
might be wrong and RSP720 isn't affected.

This is only a single example of devices that behave like that. I don't 
have experience with a lot of platforms so I don't know what other bad 
behaving platforms there are out there.

> is hard to read as other than a blanket statement - "add an extension 
> header, take the slow path". That statement means that routers are 
> processing extension headers beyond the hop-by-hop header in every 
> circumstance. I’m sorry, I can’t imagine why they would. In some cases 
> (firewall functionality, ACLs, and packets addressed to the router), 
> yes, but not every packet forwarded; doing so would be a violation of 
> RFC 2460 and would be a waste of effort. That is what I have objected 
> to. I would like to see an accurate statement, if there is going to be 
> one. I’ll note Tim Chown’s comment in passing.
>

Fair enough, but people are still using them.

> "Because the Hop-by-Hop EH must be fully processed, it is handled by the 
> CPU and the IPv6 traffic that contains a Hop-by-Hop EH will go through 
> the slow forwarding path. This rule applies to all vendors. Hardware 
> forwarding is not feasible in this case."
>
> "Due to the potential combinations and lengths of extension headers, the 
> overall size of the chain will vary. In Cisco routers, when the size of 
> the EH chain exceeds the resources allocated in HW and upper layer 
> protocol filters are applied, the IPv6 traffic will be software switched 
> by the Line-Card CPU. The packet shown in Figure 4 has a 72 bytes long 
> EH chain, which means that a hardware forwarding platform that was 
> designed to handle 64 bytes of EH data will have to software switch this 
> packet. With the current IPv6 applications and services however, this 
> would be an infrequent event. Moreover, packets with very long EH chains 
> are generally control plane packets (such as the one depicted in Figure 
> 4) which have a very low rate, so the impact on the router is not 
> significant."
>

>From my 2011 email:

    #platform ipv6 acl fragment hardware ?
      drop     Drop IPv6 fragments at hardware
      forward  Forward IPv6 fragments at hardware

As far as I can tell, the default is to slow-path, then you can configure 
it to either drop or forward without looking.

I don't have access to SUP720, but if you can get someone in the Cisco lab 
to verify that packets are not dropped when there is no ACL, I'll concede 
that point as a mistake on my part.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 7 May 2015 18:36:50 +0200 (CEST)

> fast path or no path is in fact pretty common. slow path if it exists is

Well, on some platforms slow path means it hits a control plane policer 
and might/will be dropped if the punted traffic is too high. That was the 
case when I experienced this, we had CoPP configured, so anything apart 
from a few megabit/s of IPv6 slow-pathed traffic was just dropped in 
hardware, meaning we threw away tens of megabits per second of IPv6 
packets with fragmentation headers (I discovered when I started looking 
into it).

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 07 May 2015 19:11:34 +0200

> It would be nice to hear from the wg about this. Thoughts?

I can live without reincorporating it as well.

But if you do, please tell that certain networks block protocol Mobile 
IPv6. This is not a good thing.

Why defining and implementing protocols if they are blocked on such 
large scale.

Alex

---

From: Ole Troan <[email-masked]>
Date: Thu, 7 May 2015 20:02:38 +0200

> and just to be clear. I want EHs to work on the Internet. I support this document in all other aspects. I am just tired of all blame being historically put on "stupid ISPs" or "stupid administrators" who intentionally configure their equipment to do bad things, like drop "all ICMP packets", when in at least some cases, the ICMPs were not making it to the destination because of load balancers or ECMP routing would send the ICMP packet to the wrong place.

I suspect there are both, misguided operators in some cases and broken gear in others.
let’s hear from the handful of operators that are identified as dropping EHs in transit and hear which one of those it is.

cheers,
Ole

---

From: Mark Andrews <[email-masked]>
Date: Fri, 08 May 2015 09:53:41 +1000

In message <[email-masked]>, Alexandru Petrescu writes:
> Le 06/05/2015 23:13, Fernando Gont a =E9crit :
> > Folks,
> >
> > Question to the wg:
> >

Because things change over time.  EDNS packets when they were
introduce in 1999 were rejected almost 100% of the time.  Now, 15+
years later, they are almost never rejected.

We are about to start added a EDNS option to every DNS request sent. [1]
About 10-15% of nameserver mishandle unknown EDNS options [2] despite
explicit instructions on how to handle them. [3]

Doing a EDNS version bump is even worse 20-40% of nameservers
mishandle EDNS packets with a unknown version.  A lot of that is
stupid firewall defaults and broken DDoS filtering services in front
of the nameservers.  When the packets get through to the nameserver
there is a similar level of mishandling as EDNS options. [2]

Despite these figures the next major release of named will be sending
EDNS queries with a EDNS option and we will ride out the misbehaviour.
I believe other nameserver vendors also intend to do similar.

[1] https://tools.ietf.org/html/draft-ietf-dnsop-cookies-01
[2] http://users.isc.org/~marka/summary.html
[3] http://tools.ietf.org/html/rfc6891#section-6.1.2

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mark ZZZ Smith <[email-masked]>
Date: Fri, 8 May 2015 00:14:46 +0000 (UTC)

Hi,
      From: Fred Baker (fred) <[email-masked]>
 To: Mark ZZZ Smith <[email-masked]> 
Cc: Fernando Gont <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>; V6ops Chairs <[email-masked]>; Merike Kaeo <[email-masked]> 
 Sent: Thursday, 7 May 2015, 17:45
 Subject: Re: [v6ops] Next steps for IPv6 EHs in Real World (draft-ietf-v6ops-ipv6-ehs-in-real-world)

Hi,

/ I definitely think describing the circumstances where this might happen for some implementations would be useful.
/ Thinking more about it, I think TCP and UDP headers are effectively theoretical EHs too, as their presence values are encoded in the same Next Header fields as normal EHs, and they can appear in the same packet locations as normal EHs. I'd be interested to know if fast path forwarding (hardware) might be doing more complex processing than just a HBH EH value check on the IPv6 Header Next Header field.
/ For example, the TCP and UDP headers are usually the ones people want to look at in more detail, so a simplistic implementation would punt all first EH HBH, TCP and UDP to slow path and fast path everything else. Of course, TCP and UDP traffic are the dominant types, so slow pathing TCP/UDP traffic by default would be non-optimal.

Folks,

Question to the wg:

Thanks!

Best regards,

---

From: Mark ZZZ Smith <[email-masked]>
Date: Fri, 8 May 2015 03:28:53 +0000 (UTC)

From: "[email-masked]" <[email-masked]>
 To: [email-masked] 
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked] 
 Sent: Thursday, 7 May 2015, 15:53
 Subject: Re: [v6ops] Next steps for IPv6 EHs in Real World (draft-ietf-v6ops-ipv6-ehs-in-real-world)

/ Agree, that sort of hardware in part is why I'm curious for more detail.

Steinar Haug, AS 2116

---

From: Mark ZZZ Smith <[email-masked]>
Date: Fri, 8 May 2015 04:12:19 +0000 (UTC)

Hi Brian,
 Sent: Thursday, 7 May 2015, 17:16
   
Hi Mark,

/ In my experience, "ACLs" have been capable of doing both levels of matching (in some implementations there are simple ACLs which only do addresses and 'extended' ACLs which can also do 5-tuple etc. matches.) I don't think I've come across a platform that just does address level ACLs.

/ Agree, that is the hard problem.
/ I think that while the control plane is reachable in-band by possibly malicious traffic sources, it is fundamentally impossible to completely protect it from various attacks from those malicious traffic sources. Even if ACLs/packet filters are used to validate addresses and upper layer protocol numbers, they won't protect against possible exploits in the protocol or implementations. That's certainly pretty obvious, I think the thing we need to remember is that "perfect protection" of the control plane is impossible to achieve in this situation.

  Brian

---

From: "Liushucheng (Will)" <[email-masked]>
Date: Sun, 10 May 2015 05:36:36 +0000

Hi all,

I agree with Tim here.
To be more concentrated, I think it’s better to keep the main focus of this document on the observed facts, then leave the rest to another document as a follow-up.

Regards,
Will (Shucheng LIU)

From: Tim Chown [mailto:[email-masked]]
Sent: Thursday, May 07, 2015 4:20 PM
To: Fred Baker (fred)
Cc: Mark ZZZ Smith; Fernando Gont; [email-masked]; [email-masked]; V6ops Chairs; Merike Kaeo
Subject: Re: [v6ops] Next steps for IPv6 EHs in Real World (draft-ietf-v6ops-ipv6-ehs-in-real-world)

Hi,

On 7 May 2015, at 08:45, Fred Baker (fred) <[email-masked]<mailto:[email-masked]>> wrote:

On May 7, 2015, at 12:05 PM, Mark ZZZ Smith <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

I think the discussion we’re on now would be better put into a follow-up text, so we can ship the original problem statement. I suspect the follow-up will be more heavily debated, witness the (lack of) progression of https://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-02, but my preference would be to stop tinkering, to ship, and focus on a new document.

Tim

Regards,
Mark.

________________________________
From: Fernando Gont <[email-masked]<mailto:[email-masked]>>
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>; V6ops Chairs <[email-masked]<mailto:[email-masked]>>; Merike Kaeo <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, 7 May 2015, 7:13
Subject: [v6ops] Next steps for IPv6 EHs in Real World (draft-ietf-v6ops-ipv6-ehs-in-real-world)

Folks,

Question to the wg:

Thanks!

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

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

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