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

Ca By <cb.list6@gmail.com> Wed, 17 June 2015 04:52 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 5D8911B3BD9 for <v6ops@ietfa.amsl.com>; Tue, 16 Jun 2015 21:52:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.749
X-Spam-Level:
X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 QVMaltF2S8Xo for <v6ops@ietfa.amsl.com>; Tue, 16 Jun 2015 21:52:24 -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 315481B3BC2 for <v6ops@ietf.org>; Tue, 16 Jun 2015 21:52:23 -0700 (PDT)
Received: by wiga1 with SMTP id a1so127009054wig.0 for <v6ops@ietf.org>; Tue, 16 Jun 2015 21:52:22 -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=We9iW1BTh4GQBQmiN8AeCNvUBrIIzKPqwqqe19McuMQ=; b=rgMDgbvo+cNoqZMnpLFtsVdJKVXR9aAYv8bpgLpS28fZv5NMOJBWA0XZ//D1lFIVyb RHtoNURTuEMdvJS1WvWqmKN8vz4k5RC9XYusT6eI9V95gOp+tE18w6SRVVf2SxhkwHdg kcxhECj7encCuQWqWFOQ2ltKyfVOLkPJB7mz6tGgbymg36+bhja/EFNsGlvYrwLa7Zzj JWbgO3p1zhUDO+OVbaKsO6edaLD4/we+7iJYb7NWzL5Mu3OGLtsmFvoeVrigIGdmm1b9 kvwIQqzAlhbM+RpFEAKUURWLj9KMi+31y4Uc7iMEObAwwRStiVc4a60vqoG4s0wvJ4O7 3o0A==
MIME-Version: 1.0
X-Received: by 10.194.24.70 with SMTP id s6mr2112855wjf.25.1434516742684; Tue, 16 Jun 2015 21:52:22 -0700 (PDT)
Received: by 10.194.79.65 with HTTP; Tue, 16 Jun 2015 21:52:22 -0700 (PDT)
In-Reply-To: <8447882A-6B4B-4ABE-9BDF-5DA7AFE13AB1@cisco.com>
References: <20150515105406.GA3028@ernw.de> <87siav2m6p.fsf@stepladder-it.com> <F1D4404E5E6C614EB9D3083F4D15A7E7C4A92C@hex02> <D17F4C51.4ABB0%evyncke@cisco.com> <20150611165858.GT39827@ernw.de> <CAFU7BAR7m0sZsU9Rc=fUao32zaRE1=9XMBWjiL0AukehdpVpWQ@mail.gmail.com> <5580CC33.2080503@gmail.com> <8447882A-6B4B-4ABE-9BDF-5DA7AFE13AB1@cisco.com>
Date: Tue, 16 Jun 2015 21:52:22 -0700
Message-ID: <CAD6AjGSUPV_9EEQGCRHRpKe8Hejgx_CMPq6bEkCsK3v4qmgJgg@mail.gmail.com>
From: Ca By <cb.list6@gmail.com>
To: "Fred Baker (fred)" <fred@cisco.com>
Content-Type: multipart/alternative; boundary=047d7b4724d8df469d0518af7480
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/G0PKGfqOla_yNB9p_EBnXmznuxs>
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: Wed, 17 Jun 2015 04:52:25 -0000

On Tuesday, June 16, 2015, Fred Baker (fred) <fred@cisco.com> wrote:

>
> > On Jun 16, 2015, at 6:24 PM, Brian E Carpenter <
> brian.e.carpenter@gmail.com <javascript:;>> wrote:
> >
> > Personally I still think RFC 7045 is the most realistic on this point,
> > but Fred would like things to get better ;-).
>
> And I haven't finished with Dennis Ferguson's comment.
>
> Bottom line, if one accepts the present status quo as the state forever,
> then we should stop with RFC 7045, and (with Fernando) agree to deprecate
> all extension headers. I'd like to not do that, and the only way I see to
> not do that is to not accept the status quo.
>


So you build a bridge to nowhere?