IETF Logo Mail Archive

Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text

Jeroen Massar <jeroen@massar.ch> Wed, 22 April 2015 07:33 UTC

Return-Path: <jeroen@massar.ch>
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 E0B4F1B32E1 for <v6ops@ietfa.amsl.com>; Wed, 22 Apr 2015 00:33:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 1HPaFK_H5ylK for <v6ops@ietfa.amsl.com>; Wed, 22 Apr 2015 00:33:35 -0700 (PDT)
Received: from bastion.ch.unfix.org (citadel.ch.unfix.org [IPv6:2001:1620:20b0::50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B70F1B32DC for <v6ops@ietf.org>; Wed, 22 Apr 2015 00:33:24 -0700 (PDT)
Received: from kami.ch.unfix.org (kami.ch.unfix.org [IPv6:2001:1620:f42:99:7256:81ff:fea5:2925]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id B299C10038A25; Wed, 22 Apr 2015 07:33:21 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1429688001; bh=RVm3yIVAVyG1ak8tV7OdIsROxoyADhQ84/S0lkIY63o=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=p3TultB5zwb1iN7SNsrkj5grZUTRaW9pACCjZFatH6lnOaCyTll0d2m59BiDZTk/l 61Y7r/ooUacwK0CzfsGC0FsWEtFqp3kuxLC6G3Dx7JcJnGXFknXEyTMqbpdMMbTsBj 4aYqjCuukVN0mrVHG+1WpIP84X+zx4nzzJMw7vgAE65lzXhm0SmIwunFS+1TiFgzLn eL9sh2BfwFCTfK+6aiMi8qmgXjV4gtrigJgaFmPGuKhyfYJfXPpLKFuRzMr/gV9sRG Tdz6u9Z/VnkpOj6CU4p9qr+UEWk/k3MgTLeMehnecEdThgP5K/YY8kWfO2z5XScYvP LNhhB9D/wFa1g==
Message-ID: <55374EC1.2020708@massar.ch>
Date: Wed, 22 Apr 2015 09:33:21 +0200
From: Jeroen Massar <jeroen@massar.ch>
Organization: Massar
MIME-Version: 1.0
To: sthaug@nethelp.no
References: <1358113193.2147388.1429685168609.JavaMail.yahoo@mail.yahoo.com> <20150422.091227.74668510.sthaug@nethelp.no> <55374C42.7030908@massar.ch> <20150422.093102.41714241.sthaug@nethelp.no>
In-Reply-To: <20150422.093102.41714241.sthaug@nethelp.no>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/smMxjdznr95mxkvKp9U_RTDWG4M>
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
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: Wed, 22 Apr 2015 07:33:37 -0000

On 2015-04-22 09:31, sthaug@nethelp.no wrote:
>>> I see no reason to deprecate IPv6 EHs. But I need 
>>>
>>>  [IPv6 Fixed Hdr] + [IPv6 EHs] + [L4 Hdr] <= hardware inspection limit
>>>
>>> in order for the router hardware to be able to filter based on TCP/UDP
>>> headers at line rate.
>>
>> The nasty answer to such a statement is: increase your hardware
>> inspection limit.
> 
> And that will probably happen - as part of regular equipment upgrade
> cycles.

Changing a protocol that is trying be deployed for 20+ years already is
not going to happen quicker than the above ;)

>> But the easier one, that works today is that very likely your DNS
>> servers recursing IP space is dedicated.
>>
>> Hence, any packet headed toward those addresses is "private" and should
>> not get an answer.
>>
>> Thus, instead of doing filtering on L4, why not just not route those
>> packets at all (L3)? Don't even have to firewall it.
> 
> The world is not that simple.

Then please define the real problem you are trying to solve.

Your statement was that you have a private DNS server that you do not
want reachable from the outside.

Hence, not routing packets from $outside solves your problem.

Greets,
 Jeroen

v2.23.0 | Report a Bug | By Email