Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-ehs-packet-drops-00 - Admin Policy

Mark Smith <> Mon, 03 August 2020 11:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 007403A0E96 for <>; Mon, 3 Aug 2020 04:36:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.927
X-Spam-Level: *
X-Spam-Status: No, score=1.927 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.626, HK_RANDOM_FROM=0.998, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rn2SoruMp_JY for <>; Mon, 3 Aug 2020 04:36:02 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 87AEB3A0E94 for <>; Mon, 3 Aug 2020 04:36:02 -0700 (PDT)
Received: by with SMTP id o72so22055075ota.11 for <>; Mon, 03 Aug 2020 04:36:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IFnvzz5P6B2ppIC+9LZ/Jw+HC/K+GYIHlnNlkrGnPnA=; b=scjQ+djOeKywjAJ703lt7x1M4Lfbd02TdWOPjHvBIRoPYcyo3+R162A4f5inv6Rl2X lRaPa77fAULkyOc6mgltEsJ2ZdssU93+lbWdJpNJSOepIJONtgxzxuJWkbEmES45P9ut M+dY/bVxxnFcdhxTWFbHL11FbZDguyJyxe+OFAWiyvw67ZNJTV/cW4BHG/HdzCgPhbTb BoF7gUhIREVyjzJKrft+cNYzH/3rLEW0CrGIUkGkQtDdvYtQLf7/g0cYOYbzrSgdVSsk RXv4FX1k7PUglziRQFrQBiINpahb+agM6bYcg7QYKsxrCEpq0QDE+hxQykMXAeabm9HR LGDg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IFnvzz5P6B2ppIC+9LZ/Jw+HC/K+GYIHlnNlkrGnPnA=; b=sUqSjYbj9oN7L+gVclaA8Rrq0bvrufZF4OvQKMOgeF9C+Qa4KN65c7Ks5bOM2wnXC1 jrKIltZlvwmS7Lf0ues6MlmKLkY1g4smDjOnBxXXP4CVx3L0QyXugk19Ftl6RwLPx3gy XYigtvMPulgqgCTOBxKbFimmix1rQ2/xCpmEfFFk7P9RdixfYSv9w68Ot5nEgiGDnk+S bF8CPV238yErY6RRZxu0MmbFlIzHw5+cWm8/jUq6zWL+wOCkJtimnRtebsottwINgMd8 /zWc1pGqbbNgp4C20i6x6auJ2Qtfiq7PohGRYlCIydF04LyHoWutLd+HJ5NgYLIQfW8P XC0Q==
X-Gm-Message-State: AOAM530yTgc607DtWHXN4t0aOtPiqex6mf56hqhcLYOAY7gpSMeuwSAR 4EBrwojrWqek9tbltzKzjKzDZorjdRVe4glo+FQ=
X-Google-Smtp-Source: ABdhPJy4ZmZ5nzHY/+gb8fT+WyYbaIlWksM2JTURJGPWLbVyqs+EXe52EudyA0FPKF5W7Rvh/qHmCzfxjlVbV7IbZmE=
X-Received: by 2002:a9d:2661:: with SMTP id a88mr13588995otb.74.1596454561751; Mon, 03 Aug 2020 04:36:01 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Mark Smith <>
Date: Mon, 3 Aug 2020 21:35:50 +1000
Message-ID: <>
To: Fernando Gont <>
Cc: Vasilenko Eduard <>, v6ops list <>
Content-Type: multipart/alternative; boundary="0000000000000da73505abf78b7e"
Archived-At: <>
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-ehs-packet-drops-00 - Admin Policy
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 03 Aug 2020 11:36:04 -0000

On Mon, 3 Aug 2020, 20:26 Fernando Gont, <> wrote:

> Hello, Eduard,
> On 1/8/20 14:02, Vasilenko Eduard wrote:
> > I know from discussion with some carriers that some of them filter out
> EHs intentionally
> > To avoid any problems discussed in this draft.
> > It is definitely the reason for EHs drops, but non-technical. It is
> probably "Absence of use case".
> Ultimately, there are technical reasons behind such drops: i.e., any of
> the subsections from Section 6.
> Most likely, if EHs were innocuous, even if there wasn't a use case,
> folks could let them through.
> While it is true that there are not many use cases for EHs, there are at
> least to important ones: fragmentation

I expect many network operators drop fragments because they were taught to
do ACLs/packet filters similar to the following:

permit tcp any any eq http
permit udp any any eq dns
deny ip any any

I was back in the day.

The focus is limited to "this is specifically what you need to do to make
what you want to do to make it work" rather than also, "here are the other
issues with what you're doing that you might need to consider".

The fact that the above does what was exactly what was expected e.g. allows
web access, gives an impression that it is 100% correct, and therefore
reinforces that there isn't anything else to consider.

It's only if you either go deeper into how the protocols work e.g. PMTUD,
or break something and have to work out how to fix it, do you learn and
realise issues with examples like above.

It's quite a while since I've looked at any, from what I remember,
practical network operation books and manuals are the same.

Network firewall admins can be a bit worse in the sense that they can be
more paranoid about blocking things they don't understand enough or don't
trust e.g. blocking all of ICMP by default.

I don't think it is as commonly  calculated as people here might think.
It's more "teach just enough to make it work".

and IPsec's ESP. And these two
> get dropped, too.

See above. Unless why ESP and AH should be allowed is taught, it's deny by

> > Additional risk and additional processing capacity should have the
> reward. It is just business.
> Indeed.
> As noted, even for cases where there's a use case (e.g. IPsec ESP), or
> fragmentation (see the numbers for fragment drops for the case of DNS
> servers), packets with EHs are still dropped.
> (me thinking out loud, and asking for more thoughts, if you wish)
> Thanks,
> --
> Fernando Gont
> e-mail: ||
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> _______________________________________________
> v6ops mailing list