Re: [netmod] 6021 ipv4-prefix

tom petch <> Thu, 02 May 2019 09:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C9A6C120159 for <>; Thu, 2 May 2019 02:06:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.249
X-Spam-Status: No, score=0.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, LOTS_OF_MONEY=0.001, RATWARE_MS_HASH=2.148, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xCBE3PBLGUvb for <>; Thu, 2 May 2019 02:06:52 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 881B112001E for <>; Thu, 2 May 2019 02:06:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mF1G13dBwhYY/CsRpkIVjKMeWQHTta/omDqX95zkNb0=; b=XS+mMdBmC8sXmCaOuWY9OGXf945+DqWMEtETdRvkOocbQ5t1yuoXp5KMtixxWIe09DibFg1GDRAXR8Km0Rh6Rp15NCuC4HsDMD4WW+lMnVJEROOaieRZXDEV7FuXoVeqsqv0lVH1Zu3vfmUVpNLpg5LHV5yJt2G03DlE0AQ8hak=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.7; Thu, 2 May 2019 09:06:49 +0000
Received: from ([fe80::41a4:68a9:d620:d42b]) by ([fe80::41a4:68a9:d620:d42b%3]) with mapi id 15.20.1878.004; Thu, 2 May 2019 09:06:49 +0000
From: tom petch <>
To: Juergen Schoenwaelder <>, Mikael Abrahamsson <>
CC: "" <>
Thread-Topic: [netmod] 6021 ipv4-prefix
Thread-Index: AQHVAMZf50mA7zDduEuOBh3Lqw5YqA==
Date: Thu, 02 May 2019 09:06:49 +0000
Message-ID: <031e01d500c5$e41a8c00$>
References: <> <> <> <> <> <> <> <> <> <> <>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-clientproxiedby: LO2P265CA0011.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:62::23) To (2603:10a6:802:20::28)
authentication-results: spf=none (sender IP is );
x-ms-exchange-messagesentrepresentingtype: 1
x-mailer: Microsoft Outlook Express 6.00.2800.1106
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 16aa6986-79c6-429e-9611-08d6cedd820f
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:VI1PR07MB6079;
x-ms-traffictypediagnostic: VI1PR07MB6079:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:6790;
x-forefront-prvs: 0025434D2D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(376002)(39860400002)(136003)(396003)(51444003)(13464003)(189003)(199004)(386003)(84392002)(3846002)(86362001)(61296003)(68736007)(6506007)(25786009)(4326008)(5660300002)(2906002)(44716002)(62236002)(66066001)(6436002)(6116002)(6486002)(966005)(6512007)(86152003)(9686003)(6306002)(44736005)(50226002)(476003)(26005)(71190400001)(52116002)(486006)(81816011)(81686011)(8936002)(316002)(6246003)(76176011)(110136005)(446003)(478600001)(71200400001)(305945005)(64756008)(66446008)(81166006)(14454004)(8676002)(81156014)(73956011)(1556002)(66556008)(66476007)(66946007)(256004)(53936002)(102836004)(99286004)(7736002)(4720700003)(186003)(14496001)(229853002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB6079;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: mTsI3p5rCYIZ0cmz4Git+4cMr8IMYxnI2yp5e3hByRnmpp0dTEeVt7JoFc9cY3JxDLVv7jE/xqW4/slU9jF/otidRCghuWeTeWYENnpiE0kqw2ZfgY6AL/v+i5zVD39GeiAZwc99UhNJHsYNkeaIn6LlyChNni5Yi+n8tiY/6OoFCIKdo+TdLpFdXR8Eo9dokltUFHKwXr7+q12THfZU3OqfFIGzgjBd3ok2FMF8ocrwLoZhMYO/8vl49W9AmYZEAfeN7hjxb8wdkDk7AWbZMVnWpPTMRe9KcjIydOM3mdfWtIgia7VZbMBxK/UDRdJNKC2TBDeMYZQnzWjRbYoKGvCRB3zJ1Bw4crMOh82DV1xkJCbVbeCAhQ7tKZyw3KxrytRG/cE9/tUW3zyIFMvl6lFdxxIpW2ZtF3awGK7azeM=
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 16aa6986-79c6-429e-9611-08d6cedd820f
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 May 2019 09:06:49.4761 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB6079
Archived-At: <>
Subject: Re: [netmod] 6021 ipv4-prefix
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 02 May 2019 09:06:56 -0000

----- Original Message -----
From: "Juergen Schoenwaelder" <>
Sent: Wednesday, May 01, 2019 12:17 PM

> On Wed, May 01, 2019 at 10:55:38AM +0200, Mikael Abrahamsson wrote:
> >
> > So while you seem to think I am not reading your text, it seems to
me you're
> > not reading what I am saying either. You're not responding to the
points I
> > am trying to make anyway.
> >
> >
> >
> > This talks about *values*. If you drop bits in IPv6-prefix, then
it's not
> > the same *value* anymore.
> I personally do take the standpoint that irrelevant bits do not matter
> for the value of a prefix, i.e., and are
> two different representations for the same prefix. You seem to take
> the standpoint that and are different
> prefixes since bits that are irrelevant do differ.
> Apparently there are different views that people have concerning
> prefixes. I think I have seen the following three alternatives:
> a) non-prefix bits that are set to one are illegal in a prefix
> b) non-prefix bits are irrelevant but they need to be preserved
> c) non-prefix bits are irrelevant, ignore them and the canonical
>    representation has non-prefix bits set to zero
> The RFC 6991 definitions do c). If there is consensus that c) is
> wrong, we need to deprecate the definitions and create new ones after
> finding consensus on either b) or a).

And I think that c) is the correct answer (and would be for those not
involved in netmod but who have experience of the IETF - did I hear 'be
liberal in what you accept'?)

I have worked with systems that made every effort to find a reason not
to accept something that had been input, and I have worked with systems
that bend over backwards to accept something a bit flaky; different
developers have different cultures but I have always found the culture
of the IETF to be very clear on this point.  Mac, Linux and Windows have
different cultures.

There is a caveat and it is that the context must be clear.  Randy cited
' ... 1234567.89 and if it
subsequently chooses to display it as "1.234.567,89 USD" '
Well, where he is, may be, but not here where it could be

1.234.567,89 Euro
1,234,567.89 Euro
123456789 Yen
or ...
depending on the locale.

Going back to
then the meaning is clear as long as it is unambiguous that it is a
prefix and not more; as has been commented on (a lot of messages ago),
this could be a compound object, specifying
address+ mask
address + prefix + prefix length
so it matters that the context is clear, both for the object instance
and for the organisation doing the specification.

Tom Petch

> System/kernel interfaces seem to show different behaviours. My Linux
> box seems to do a), my MacOS box seems to do c). The system/kernel
> interfaces likely all do the same if all non-prefix bits are zero,
> i.e., when the system receives data in the canonical format.
> Option b) seems to be the most expensive to implement (your server may
> have to clear non-prefix bits before pushing the prefix into the
> kernel and it needs to map data received from the kernel back to a
> prefix that has unused bits preserved in the datastore). Hence, for me
> the choice is between a) and c) and given that we have c) already
> defined for years, my first preference is to just keep things as they
> are.
> /js
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <>
> _______________________________________________
> netmod mailing list