Re: [v6ops] Extension Headers / Impact on Security Devices
Ca By <cb.list6@gmail.com> Tue, 16 June 2015 13:08 UTC
Return-Path: <cb.list6@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 043AF1B342B for <v6ops@ietfa.amsl.com>; Tue, 16 Jun 2015 06:08:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.749
X-Spam-Level:
X-Spam-Status: No, score=-3.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1ld7hembzXD for <v6ops@ietfa.amsl.com>; Tue, 16 Jun 2015 06:08:20 -0700 (PDT)
Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E42141B3456 for <v6ops@ietf.org>; Tue, 16 Jun 2015 06:08:18 -0700 (PDT)
Received: by wicnd19 with SMTP id nd19so52620246wic.1 for <v6ops@ietf.org>; Tue, 16 Jun 2015 06:08:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6ERfw1CFvrCccnHCk/r1StxcMnMqxOW3GDGk2aqqFnI=; b=QPBJZWLqZEsldAIB46COfqJqPpH2cM+Gc4FB1zikooZPl/NqokyTcm5bWoP0gP2OGY zEiVeaiJRuKW+58NKVGIAh0qeBJUqpR1eCfSRl69Q9ejzRlEBQjs5WegRvx5143jDTuW RwFGn859cfLKZ15uRBdQD/S3VQJipfy99WAsfOzNPHVR6J5gTuGCmilErz9vBIuDQBYT pNIiJ+twbvWhvCBo0HwL0IUdf+HiFL64OT5mEoK1NUqQ4nDQH464jyqec/GsxLY7SNGV 4DB5Kw5TlMWEhD8JuUZ+uMcN3NfYvVPientMAokv4Y1pVXa1FYYOj9HmtGJ6x+y3D3pH Dosg==
MIME-Version: 1.0
X-Received: by 10.180.100.74 with SMTP id ew10mr44256260wib.12.1434460097520; Tue, 16 Jun 2015 06:08:17 -0700 (PDT)
Received: by 10.194.79.65 with HTTP; Tue, 16 Jun 2015 06:08:17 -0700 (PDT)
In-Reply-To: <283392813.4420641.1434431518036.JavaMail.yahoo@mail.yahoo.com>
References: <CAD6AjGTufBsW9pR37J-HJ7FV5o_UJTwrmPMRuuuP57ja3p19dQ@mail.gmail.com> <283392813.4420641.1434431518036.JavaMail.yahoo@mail.yahoo.com>
Date: Tue, 16 Jun 2015 06:08:17 -0700
Message-ID: <CAD6AjGQM_JSOKLaSS=ZwwYosOYSaU9AU687MCFfv5YWHRRRJcg@mail.gmail.com>
From: Ca By <cb.list6@gmail.com>
To: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
Content-Type: multipart/alternative; boundary="14dae9cc9c5a8ea8060518a244a0"
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/mQR04A9KwF88nuYRPJE5PX_jQnI>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] Extension Headers / Impact on Security Devices
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jun 2015 13:08:26 -0000
On Monday, June 15, 2015, Mark ZZZ Smith <markzzzsmith@yahoo.com.au> wrote: > > ------------------------------ > *From:* Ca By <cb.list6@gmail.com > <javascript:_e(%7B%7D,'cvml','cb.list6@gmail.com');>> > *To:* Eric Vyncke (evyncke) <evyncke@cisco.com > <javascript:_e(%7B%7D,'cvml','evyncke@cisco.com');>> > *Cc:* "v6ops@ietf.org <javascript:_e(%7B%7D,'cvml','v6ops@ietf.org');>" < > v6ops@ietf.org <javascript:_e(%7B%7D,'cvml','v6ops@ietf.org');>>; " > ipv6-wg@ripe.net <javascript:_e(%7B%7D,'cvml','ipv6-wg@ripe.net');>" < > ipv6-wg@ripe.net <javascript:_e(%7B%7D,'cvml','ipv6-wg@ripe.net');>> > *Sent:* Tuesday, 16 June 2015, 8:32 > *Subject:* Re: [v6ops] Extension Headers / Impact on Security Devices > > > > On Monday, June 15, 2015, Eric Vyncke (evyncke) <evyncke@cisco.com > <javascript:_e(%7B%7D,'cvml','evyncke@cisco.com');>> wrote: > > Enno, > > As you probably know, Cisco handles PSIRT issues with care, so, I have no > clue on this specific advisory. My own (educated) guess is that the packet > causing a LC reload is fully RFC 2460 compliant but unusual, so, probably > (a guess again) a combination of extension headers triggering a bug. > > In this specific case, I would not blame IPv6 or RFC 2460 but rather my > own company (even if the affected versions were quite old as new IOS-XR > versions appear to be immune to this bug). And I appreciate the humor in > your rhetorical question about which FW could protect a CRS... Air gap > probably :-) > > More generally, regarding the 'parsing of the header' and performance, my > understanding (and I am NOT a HW engineer) is that there are multiple ways > to parse the header chain: > - purely software in low-end devices, should have a marginal performance > impact > - specific ASIC in middle-end devices (read high end enterprise), probably > some limitations and heavy performance impact (but again within one > organization, so, easier to fix the root cause) > - a lot of specialized network processors in high-end devices (SP gears), > which is a similar case as the 'low-end device', performance impact but > marginal as parsing the chain of headers is not that hard after all _when_ > coded correctly > > As the extension headers are specific to IPv6, this is an area when we > will all learn (and have learned already) a lot of things... > > I respectfully disagree with your last sentence. Of course, destination > AS/host SHOULD only accept useful, known and legit ext headers; but, why > would an ISP filter on ext headers if they do not harm their own infra or > a customer infra? Do you envision an Internet where only TCP/443 and > UDP/43 would be accepted? > > Last point, the Internet will have to use IPv6 for 10 or 20 years at > least. If the IETF/ISP block all new _options_ in _existing_ extension > headers, then we will be stuck in 1997 for network innovation. While I do > not like taking security risks, I even fear more the lack of innovation. > > > > I keep hearing this and it is very bizarre to hear > > With regards to 1997, believing that there will be innovation in the > narrow waist of hour glass (network layer), that is very 1997. The network > layer is stable and boring.... Hence it being narrow. Innovation is > welcome everywhere except network in the e2e model > > / Absence of evidence is not evidence of absence. > > / Consider what the network and host situation was in 1997 (wired network > access, desktops outselling laptops, dialup Internet for residential, > corporates in total probably being the largest spenders on Internet access) > to today and the near future (wireless networks, smartphones/tablets being > the dominant Internet access device in some markets - and they're > multi-homed, M2M/IoT considered to be place where the greatest expansion of > Internet connected devices is going to occur in the near future.) > > / IPv6 has had relatively little adoption, and it is only starting to > increase quite rapidly in the last few years and that is mainly because of > mobile networks. There hasn't and still doesn't seem to be much thinking > about how IPv6's differences from IPv4's can be taken advantage of yet - an > "IPv4 first" or an "IPv4 == IPv6" mindset seems to be still very common (I > think the network virtualisation space is where this is might be most > prominent - I think most of the technologies they're inventing require fork > lift network upgrades, so the costs of deploying IPv6 at the same time > become a lot less significant. So if there is a "cheap" opportunity to > deploy IPv6, and IPv6 is going to be the long term network layer 3, why not > optimise for it now? That was the thinking behind my "Enhancing Virtual > Network Encapsulation with IPv6" draft) > > / We don't want to disable innovation opportunities that IPv6 may provide > before people have arrived at an "IPv6 first" or "IPv4 != IPv6" mindset. > > > I have heard those stories, i don't find them compelling. CB > > > Let's talk on Thursday at Silvia's IPv6 Conference in Zurich ;-) > > -éric > > On 11/06/15 11:58, "Enno Rey" <erey@ernw.de> wrote: > > > >the problem here is the definition of "normal IP packet" as of RFC2460. > >To illustrate this I just quote from today's Cisco advisory (Cisco IOS XR > >Software Crafted IPv6 Packet Denial of Service Vulnerability) on packets > >potentially crashing CRS-3 line cards: > > > >"The vulnerability is due to incorrect processing of an IPv6 packet > >carrying IPv6 extension headers that are valid but unlikely to be seen > >during normal operation. An attacker could exploit this vulnerability by > >sending such an IPv6 packet to an affected device that is configured to > >process IPv6 traffic. An exploit could allow the attacker to cause a > >reload of the line card, resulting in a DoS condition." > > > >two question come to mind here: > > > >- is a "valid but unlikely" extension header chain "normal"? > >- what ("combination of FW & IPS or whatever") would you put in front of > >a CRS? > > > >my (sad) expectation is that we'll see much more of these (types of) > >issues in the future. given the current level of freedom that the RFC2460 > >leaves (see also discussion/picture in > >http://www.insinuator.net/2015/06/is-ipv6-more-secure-than-ipv4-or-less/) > >"properly parsing an IPv6 packet, let alone in wire speed" seems a pretty > >much unsolvable task to me. > > > >That said I still fail to see any useful extension header besides AH&ESP > >(not even FH) to be transported in the Internet. > > > >best > > > >Enno > > > > > > > > > > > > > > > > If your firewall cannot implement this policy, then > >> it is time to change or to use a combination of FW & IPS or whatever. > >> > >> - network person: as I will live with IPv6 for the rest of my life, > >>then I > >> want a way to extend it and I need any packet to travel to my source to > >>my > >> destination. Any IPv6 packet should be able to traverse the > >> Internet/private network as long as its layer-3 header is valid > >> (filtering/dropping can be done exceptionally for good operational > >> reason). Did we remember the IPv4 teardrop attack? It is blocked by > >> default by most routers for years ;-) > >> > >> Bugs will plague us for ever... And make our life more complex than the > >> above description of course ;-) > >> > >> -??ric > >> > >> On 17/05/15 20:43, "Silvia Hagen" <silvia.hagen@sunny.ch> wrote: > >> > >> >Hi > >> > > >> >I keep stumbling about that "recommendational wording" in RFC 2460 > >> >everytime I teach it. > >> > > >> >Couldn't we update RFC2460 and make this list a strict order? > >> > > >> >I would want my firewall to notify me if the EHs in a packet do not > >> >follow the list. > >> >And limiting the number of possible EHs per packet might be a good > >>idea. > >> > > >> >Silvia > >> > > >> >-----Urspr??ngliche Nachricht----- > >> >Von: ipv6-wg [mailto:ipv6-wg-bounces@ripe.net] Im Auftrag von Benedikt > >> >Stockebrand > >> >Gesendet: Sonntag, 17. Mai 2015 18:39 > >> >An: ipv6-wg@ripe.net > >> >Betreff: Re: [ipv6-wg] Extension Headers / Impact on Security Devices > >> > > >> >Hi Enno and list, > >> > > >> >Enno Rey <erey@ernw.de> writes: > >> > > >> >> hope everybody had a great #RIPE70 meeting. We did! > >> >> Many thanks to the organizers and chairs! > >> > > >> >and thanks to the actual speakers as well the speakers we had to turn > >> >down due to time constraints, too:-) > >> > > >> >> If the chairs consider this appropriate we will happily give a > >> >> presentation on this stuff in Bucharest or at another occasion. > >> > > >> >Sounds good to me! > >> > > >> >> - looking at the "liberty" RFC2460 provides as for ext_hdrs (wrt to > >> >> their number, order[...] > >> > > >> >Actually, as far as I'm concerned that's the real core of the problem. > >> >Or more specifically, the first two lines of RFC 2460, section 4.1: > >> > > >> > When more than one extension header is used in the same packet, it > >>is > >> > recommended that those headers appear in the following order: > >> > > >> >followed on the next page by > >> > > >> > Each extension header should occur at most once, except for the > >> > Destination Options header which should occur at most twice (once > >> > before a Routing header and once before the upper-layer header). > >> > > >> >Note in particular that these are not even RFC 2119 "SHOULD" or > >> >"RECOMMENDED" and such. > >> > > >> >The impact here is actually at least twofold: > >> > > >> >- It is impossible to implement this as a simple pipeline architecture > >> > in hardware; at least for cases deviating from the "recommendations" > >> > above this effectively becomes either excessively complex to > >>implement > >> > in hardware or an invitation to DoS when implemented in software on > >>an > >> > otherwise hardware router. > >> > > >> >- As I understand it, at least some of the issues you have found are > >> > effectively based on violating the second paragraph quoted, making it > >> > impossible to come up with a lower bound on how long the header chain > >> > can actually get and therefore leading to the fragmentation related > >> > attacks and similar you have discovered. > >> > > >> >The original idea was that the extension headers are processed strictly > >> >in the order they occur, so one question to ask is if there is any > >>valid > >> >reason to violate these "recommendations" for other than malicious > >> >purposes. > >> > > >> > > >> >Cheers, > >> > > >> > Benedikt > >> > > >> >-- > >> >Benedikt Stockebrand, Stepladder IT > >>Training+Consulting > >> >Dipl.-Inform. http://www.stepladder-it.com/ > >> > > >> > Business Grade IPv6 --- Consulting, Training, Projects > >> > > >> >BIVBlog---Benedikt's IT Video Blog: > >>http://www.stepladder-it.com/bivblog/ > >> > > >> > > >> > > > >-- > >Enno Rey > > > >ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de > >Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 > > > >Handelsregister Mannheim: HRB 337135 > >Geschaeftsfuehrer: Enno Rey > > > >======================================================= > >Blog: www.insinuator.net || Conference: www.troopers.de > >Twitter: @Enno_Insinuator > >======================================================= > > > >_______________________________________________ > >v6ops mailing list > >v6ops@ietf.org > >https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org <javascript:_e(%7B%7D,'cvml','v6ops@ietf.org');> > https://www.ietf.org/mailman/listinfo/v6ops > > >
- [v6ops] Extension Headers / Impact on Security De… Enno Rey
- Re: [v6ops] Extension Headers / Impact on Securit… Brian E Carpenter
- Re: [v6ops] Extension Headers / Impact on Securit… Mark ZZZ Smith
- Re: [v6ops] Extension Headers / Impact on Securit… Gert Doering
- Re: [v6ops] Extension Headers / Impact on Securit… Brian E Carpenter
- Re: [v6ops] Extension Headers / Impact on Securit… Silvia Hagen
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Enno Rey
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Brian E Carpenter
- Re: [v6ops] Extension Headers / Impact on Securit… Ole Troan
- Re: [v6ops] Extension Headers / Impact on Securit… sthaug
- Re: [v6ops] Extension Headers / Impact on Securit… Nick Hilliard
- Re: [v6ops] Extension Headers / Impact on Securit… Fernando Gont
- Re: [v6ops] Extension Headers / Impact on Securit… Ted Lemon
- Re: [v6ops] Extension Headers / Impact on Securit… Gert Doering
- Re: [v6ops] Extension Headers / Impact on Securit… Joe Touch
- Re: [v6ops] Extension Headers / Impact on Securit… Joe Touch
- Re: [v6ops] Extension Headers / Impact on Securit… Ted Lemon
- Re: [v6ops] Extension Headers / Impact on Securit… Brian E Carpenter
- Re: [v6ops] Extension Headers / Impact on Securit… Brian E Carpenter
- Re: [v6ops] Extension Headers / Impact on Securit… Joe Touch
- Re: [v6ops] Extension Headers / Impact on Securit… Sander Steffann
- Re: [v6ops] Extension Headers / Impact on Securit… Mark ZZZ Smith
- Re: [v6ops] Extension Headers / Impact on Securit… Brian E Carpenter
- Re: [v6ops] Extension Headers / Impact on Securit… Tim Chown
- Re: [v6ops] Extension Headers / Impact on Securit… Eric Vyncke (evyncke)
- Re: [v6ops] Extension Headers / Impact on Securit… Silvia Hagen
- Re: [v6ops] Extension Headers / Impact on Securit… Nick Hilliard
- Re: [v6ops] Extension Headers / Impact on Securit… Mark ZZZ Smith
- Re: [v6ops] Extension Headers / Impact on Securit… Brian E Carpenter
- Re: [v6ops] Extension Headers / Impact on Securit… Brian E Carpenter
- Re: [v6ops] Extension Headers / Impact on Securit… Joe Touch
- Re: [v6ops] Extension Headers / Impact on Securit… Brian E Carpenter
- Re: [v6ops] Extension Headers / Impact on Securit… Joe Touch
- Re: [v6ops] Extension Headers / Impact on Securit… Brian E Carpenter
- Re: [v6ops] Extension Headers / Impact on Securit… Joe Touch
- Re: [v6ops] Extension Headers / Impact on Securit… Gert Doering
- Re: [v6ops] Extension Headers / Impact on Securit… Ray Hunter
- Re: [v6ops] Extension Headers / Impact on Securit… Tim Chown
- Re: [v6ops] Extension Headers / Impact on Securit… Joe Touch
- Re: [v6ops] Extension Headers / Impact on Securit… Brian E Carpenter
- Re: [v6ops] Extension Headers / Impact on Securit… Joe Touch
- Re: [v6ops] Extension Headers / Impact on Securit… Eric Vyncke (evyncke)
- Re: [v6ops] Extension Headers / Impact on Securit… Joe Touch
- Re: [v6ops] Extension Headers / Impact on Securit… Stefano Previdi (sprevidi)
- Re: [v6ops] Extension Headers / Impact on Securit… Stefano Previdi (sprevidi)
- Re: [v6ops] Extension Headers / Impact on Securit… Howard, Lee
- Re: [v6ops] Extension Headers / Impact on Securit… Fred Baker (fred)
- Re: [v6ops] Extension Headers / Impact on Securit… Fred Baker (fred)
- Re: [v6ops] Extension Headers / Impact on Securit… Joe Touch
- Re: [v6ops] Extension Headers / Impact on Securit… Enno Rey
- Re: [v6ops] Extension Headers / Impact on Securit… Eric Vyncke (evyncke)
- Re: [v6ops] Extension Headers / Impact on Securit… Ca By
- Re: [v6ops] Extension Headers / Impact on Securit… Mark ZZZ Smith
- Re: [v6ops] Extension Headers / Impact on Securit… Ca By
- Re: [v6ops] Extension Headers / Impact on Securit… Jen Linkova
- Re: [v6ops] Extension Headers / Impact on Securit… Joe Touch
- Re: [v6ops] Extension Headers / Impact on Securit… Brian E Carpenter
- Re: [v6ops] Extension Headers / Impact on Securit… Fred Baker (fred)
- Re: [v6ops] Extension Headers / Impact on Securit… Ca By
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Fred Baker (fred)
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Enno Rey
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Jen Linkova
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … sthaug
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Nick Hilliard
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Jen Linkova
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Jen Linkova
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … sthaug
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Enno Rey
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Jen Linkova
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Enno Rey
- Re: [v6ops] Extension Headers / Impact on Securit… Ca By
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Fred Baker (fred)
- Re: [v6ops] Extension Headers / Impact on Securit… Jen Linkova
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Enno Rey
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Brian Haberman
- Re: [v6ops] Extension Headers / Impact on Securit… Joe Touch
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Enno Rey
- Re: [v6ops] Extension Headers / Impact on Securit… Fred Baker (fred)
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Tore Anderson
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Brian Haberman
- Re: [v6ops] Extension Headers / Impact on Securit… Joe Touch
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Enno Rey
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Tore Anderson
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … sthaug
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Brian E Carpenter
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Warren Kumari
- Re: [v6ops] Extension Headers / Impact on Securit… Brian E Carpenter
- [v6ops] So what is or are the problem or problems… Mark ZZZ Smith
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … sthaug
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Brian Haberman
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Gert Doering
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Joe Touch
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Ole Troan
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … sthaug
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Ole Troan
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Enno Rey
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Mark ZZZ Smith
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Brian E Carpenter
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Warren Kumari
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Ronald Bonica
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Mark ZZZ Smith
- Re: [v6ops] Extension Headers / Impact on Securit… Fernando Gont
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Fernando Gont
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Brian Haberman