Re: [v6ops] Extension Headers / Impact on Security Devices

Nick Hilliard <> Thu, 21 May 2015 15:00 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E14D61A6FF1 for <>; Thu, 21 May 2015 08:00:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XlmaMDOnWfqf for <>; Thu, 21 May 2015 08:00:26 -0700 (PDT)
Received: from ( [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6BDB41A6FEB for <>; Thu, 21 May 2015 08:00:26 -0700 (PDT)
X-Envelope-To: <>
Received: from crumpet.local ( [] (may be forged)) (authenticated bits=0) by (8.15.1/8.14.9) with ESMTPSA id t4LF0Nxg073213 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <>; Thu, 21 May 2015 16:00:24 +0100 (IST) (envelope-from
X-Authentication-Warning: Host [] (may be forged) claimed to be crumpet.local
Message-ID: <>
Date: Thu, 21 May 2015 16:00:23 +0100
From: Nick Hilliard <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
References: <> <> <> <> <> <EMEW3|c91cdcfda9ced16fe59fdbc4171372c9r4J9EO03tjc||> <> <F1D4404E5E6C614EB9D3083F4D15A7E7C53DA4@hex02>
In-Reply-To: <F1D4404E5E6C614EB9D3083F4D15A7E7C53DA4@hex02>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [v6ops] Extension Headers / Impact on Security Devices
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 21 May 2015 15:00:29 -0000

Your summary is not correct.  The problems with EHs have been discussed
extensively on this mailing list.  Please see the archives for what the
problems are.


On 21/05/2015 15:38, Silvia Hagen wrote:
> So to summarize:
> EH such as destination option and fragment is no issue in the Internet and must not be filtered, nor analyzed, simply forwarded in hardware based on the information in the IPv6 header.
> And what the administrator does within his administrative domain is up to his choice and the Internet needs not care about it
> Is that correct?
> If yes, what is the problem?
> If that is how it is supposed to work we need to educate people that feel that EHs must be filtered in the Internet.
> Now hop-by-hop is obviously diffferent. But is it needed in the Internet? Again, what I do internally, nobody out there cares.
> Silvia
> -----Ursprüngliche Nachricht-----
> Von: v6ops [] Im Auftrag von Eric Vyncke (evyncke)
> Gesendet: Mittwoch, 20. Mai 2015 14:29
> An: Tim Chown; Joe Touch
> Cc:
> Betreff: Re: [v6ops] Extension Headers / Impact on Security Devices
> On 20/05/15 10:14, "Tim Chown" <> wrote:
>> The other question is what existing work is being done that relies on 
>> the correct (desired) operation of EHs? The two that would spring out 
>> would be segment routing and sfc, at least one of which is using the 
>> existing Routing Header. If such protocols are constrained to specific 
>> administrative domains then their successful operation I would assume 
>> is down to specific EH handling in the equipment in that domain, and 
>> its capabilities, rather than (undesired) operator filtering somewhere 
>> between sender and receiver.
> The primary use case of segment routing is indeed within a single administrative domain, so, EH does not cause a problem.
> OTOH, this whole discussion is pretty close to having a discussion on whether an ISP should block everything which is neither UDP nor TCP? Or block currently-unallocated TCP/UDP ports? (and I appreciate that there are differences of course).
> To Enno's original point: it is fair for a destination domain to handle (permit, drop, log, inspect) incoming (or outgoing BTW) packets based on
> layer-4 ports, layer-4 protocols or extension headers. This is their own responsibility
> -éric
> _______________________________________________
> v6ops mailing list
> _______________________________________________
> v6ops mailing list