[v6ops] I-D Action: draft-ietf-v6ops-ipv6-ehs-packet-drops-00 - Middleboxes
Vasilenko Eduard <vasilenko.eduard@huawei.com> Sat, 01 August 2020 16:45 UTC
Return-Path: <vasilenko.eduard@huawei.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
by ietfa.amsl.com (Postfix) with ESMTP id 8B1283A09B9
for <v6ops@ietfa.amsl.com>; Sat, 1 Aug 2020 09:45:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001,
RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001,
T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001]
autolearn=ham autolearn_force=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 6iZnLGop8wTZ for <v6ops@ietfa.amsl.com>;
Sat, 1 Aug 2020 09:45:53 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by ietfa.amsl.com (Postfix) with ESMTPS id 5E8253A09B4
for <v6ops@ietf.org>; Sat, 1 Aug 2020 09:45:53 -0700 (PDT)
Received: from lhreml726-chm.china.huawei.com (unknown [172.18.7.108])
by Forcepoint Email with ESMTP id 8B156B497D5BA98A2CF3
for <v6ops@ietf.org>; Sat, 1 Aug 2020 17:45:51 +0100 (IST)
Received: from msceml705-chm.china.huawei.com (10.219.141.144) by
lhreml726-chm.china.huawei.com (10.201.108.77) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
15.1.1913.5; Sat, 1 Aug 2020 17:45:51 +0100
Received: from msceml703-chm.china.huawei.com (10.219.141.161) by
msceml705-chm.china.huawei.com (10.219.141.144) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
15.1.1913.5; Sat, 1 Aug 2020 19:45:50 +0300
Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by
msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id
15.01.1913.007; Sat, 1 Aug 2020 19:45:50 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: "v6ops@ietf.org" <v6ops@ietf.org>
Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-ehs-packet-drops-00 -
Middleboxes
Thread-Index: AdZoI2lKdHlHBlB0SjKPL9qTTWGsSQ==
Date: Sat, 1 Aug 2020 16:45:50 +0000
Message-ID: <f65dff980756428e9aeec77fe87d8138@huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.205.215]
Content-Type: multipart/alternative;
boundary="_000_f65dff980756428e9aeec77fe87d8138huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/t89K72HSPHatDipyr790AOq_F1c>
Subject: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-ehs-packet-drops-00 -
Middleboxes
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Sat, 01 Aug 2020 16:45:57 -0000
Hi all, I am still not happy that middleboxes (Firewall, Load Balancer) are discarded as the reasons for EH drops. Tom (Herbert) is right that "FWs and middleboxes that insist on meddling in protocol layers beyond the networking layer where both the standard and the Internet architecture say they are not supposed to look at" But they are! We should not ignore the reality. It is especially evident that they are among reasons for EHs drops after response: > I would love to see the firewall device that is capable of processing ALL protocol headers in the IETF protocol suite! Reality is that firewalls can only process what they are programmed to process which is typically a very small subset of the possible protocols a host might want to use. It is not good to ignore/hide some type of drops that we do not like. Eduard -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: 31 июля 2020 г. 22:32 To: i-d-announce@ietf.org Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-ehs-packet-drops-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations WG of the IETF. Title : Operational Implications of IPv6 Packets with Extension Headers Authors : Fernando Gont Nick Hilliard Gert Doering Warren Kumari Geoff Huston Will (Shucheng) Liu Filename : draft-ietf-v6ops-ipv6-ehs-packet-drops-00.txt Pages : 16 Date : 2020-07-31 Abstract: This document summarizes the operational implications of IPv6 extension headers, and attempts to analyze reasons why packets with IPv6 extension headers may be dropped in the public Internet. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-ehs-packet-drops/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-ipv6-ehs-packet-drops-00 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-ipv6-ehs-packet-drops-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ v6ops mailing list v6ops@ietf.org<mailto:v6ops@ietf.org> https://www.ietf.org/mailman/listinfo/v6ops
- [v6ops] I-D Action: draft-ietf-v6ops-ipv6-ehs-pac… Vasilenko Eduard
- Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-ehs… Ole Troan
- Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-ehs… Brian E Carpenter
- Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-ehs… Fernando Gont