MUST is an aspiration

Mark Smith <markzzzsmith@gmail.com> Thu, 12 September 2019 02:19 UTC

Return-Path: <markzzzsmith@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C89D212012D for <ipv6@ietfa.amsl.com>; Wed, 11 Sep 2019 19:19:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.498
X-Spam-Level:
X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 sI8ks7WtK6iX for <ipv6@ietfa.amsl.com>; Wed, 11 Sep 2019 19:19:29 -0700 (PDT)
Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (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 5A117120098 for <6man@ietf.org>; Wed, 11 Sep 2019 19:19:29 -0700 (PDT)
Received: by mail-ot1-x336.google.com with SMTP id t6so11354195otp.2 for <6man@ietf.org>; Wed, 11 Sep 2019 19:19:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=zhvtYSS9Lo3kCLTa24u2eZA0RWMwbb5avohPLobiuTY=; b=dnnv8I12Q5/CGiv/G4aoDElphsgeuCuEgNTWVHKhrwQULM5Yq4wMPZzoRlefRcQlMI jg77tDuCCh1XzwVTnnDOMFmziGqlVos0w02WXxcY72jpO43hrRBWIPF0lu7y4X04Y7DO Dyu2QrTpLYkpR5SXeQ6zNmZlBB4a9CcZfvZszWxDyGkeoVhEsAseGMzWRCuzfbful0dq 1bB+8lwkws767uIEFp0Q/bygOusnAtrxtq4dwyUTmhbyvR2hopByywGpiVpMT67vUJmA 6qHJiVydycNpwZd2rsEteXO9dlYjoqe/RLtEiv9mhgT84Ylwqt22QZpUupuRlb2kETB+ /vWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=zhvtYSS9Lo3kCLTa24u2eZA0RWMwbb5avohPLobiuTY=; b=in7mGes/2JI5hnM5h95x6eqCuQUEfxV3nKy7WrH4H+lIXJ5jcl2/THZyLpTxWVGwTH IEdR4OFVhjcdJ8m8oGWMHmIjDa1vmDZ5QmAvf8pqAumgx2cSnaXP+mz/tqt+UtwDGhNd WqdqoTSJunsL1osgzIxzl3wXWho3rb+X8h5dXoSSpD7y8mEOgr8q5FQKoJPSD3M8TYcu i9FH3ZTqY6lysDSCTiewt2L5egGbGOhomw7SsJMzAVb0/6oc1yKgulx4vusp3ElNNOiG qtg3S7Q9Nzh7CmZU0uvod1GPO/9hYIXvt9Dvs5/xKbc8VusenPi2PJizaQXpi4lUH/wF hJVA==
X-Gm-Message-State: APjAAAX3N29CLNq/TMUWjcPsl88Zxno7ENP/19iSE20sv4E3/GPUW3kT qubY5gHzIM4NaRqAEGO42kapK6J5r+etLQLox6jvcVie
X-Google-Smtp-Source: APXvYqwpIyzlsDBJ58lm1IroKAG3G9xWr5BVCt/m5P3IT1qBEm1M78pQpEFKPA+emtW0DmT7ETpAyd5/wpS8sxvcH1A=
X-Received: by 2002:a05:6830:1e7b:: with SMTP id m27mr6991777otr.74.1568254768552; Wed, 11 Sep 2019 19:19:28 -0700 (PDT)
MIME-Version: 1.0
From: Mark Smith <markzzzsmith@gmail.com>
Date: Thu, 12 Sep 2019 12:19:17 +1000
Message-ID: <CAO42Z2zLwzDB0iDqBQsnWTFMaO7g8_3GUoyrMsOj0qLZrQogVA@mail.gmail.com>
Subject: MUST is an aspiration
To: 6MAN <6man@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000065a295059251c4ea"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/vW5uOZeQnP2HHbO_uhBTD76Df5M>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Sep 2019 02:19:31 -0000

We're seeing drafts that keep saying the inserted EH MUST be removed at
network egress, and therefore then use that to justify saying EH insertion
is fine.

I'd like to meet the people who have developed protocol implementations
that are and always will be bug free, never partially fail, and are always
100% configured correctly.

If they don't exist (they don't), then such a MUST in an RFC is an
aspiration. It's a theoretical goal, one that in practice has been proven
not to be 100% true in similar scenarios where things "MUST" not leak  (RFC
1918 leaks, route leaks, DNS PTR lookup for private addresses etc.)

Identifying packets with inserted EHs to then remove the EH is more
complicated that DA matching, which would be used with EH addition through
encapsulation. More complexity results in more likelihood of bugs and more
failure modes.

MUST is aspirational for DA matching (due to bugs, misconfiguration etc.),
it is even more so for complex EH insertion/subtraction operations.

If an additional IPv6 packet header causes too much overhead when used to
add local network information to an existing packet transiting a domain,
then IPv6 is the wrong tool for the job.

IPv6 packet headers are large because IPv6 addresses are large, and they're
large because they need to uniquely identify all devices attached to the
global IPv6 Internet.

For additional supplemental information limited to the local network, the
devices that only need to receive it is limited to those within the local
network that is adding the supplemental information. The only addressing
requirement here is to be able to uniquely identify the devices within the
network that will be adding and processing the local network's supplemental
information.

A much smaller encapsulation, to carry the local network supplimentary
information,  with much smaller addresses can be used, such as MPLS or IPv4.

IPv6 would be fine to use without modification if it didn't cause
unacceptable problems. Apparently does, motivating EH insertion to reduce
overhead. It's not the right tool for the job if its architecture has to
compromised to suit.