Re: Additional Documentation Prefixes (was Re: AD Evaluation : draft-ietf-6man-ra-pref64-06)

Suresh Krishnan <> Mon, 04 November 2019 01:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 140B5120072 for <>; Sun, 3 Nov 2019 17:05:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1pV2aVUi5k4F for <>; Sun, 3 Nov 2019 17:05:22 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C999F12008A for <>; Sun, 3 Nov 2019 17:05:21 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=eDqgUrLdx5C4ie901L09Y8jiJr7HiNrAFJvJW9jIixTCtT+W6G9YV1Gr5R+QF0WNVGpSblbxryfycSy3uSamRJRFn7b07XHpBVu2wHqLR50QMCc70QqQBW6x2/a2CfmXTjmxfDmYVV4usMTmrL5LEcQd+jfNW8oWLoRkincZyNoVfZtS/CtT/S4XxjCFJVrrH8JTAAs/8d1SPT1G7KKXcaPgcj9RN3LpOd7UZgFAFwDWyWFIGDlY3Zq8801WUX+l7ox8iWiHrdzd8ZZiK/zGmjZ5lCSr0kPpVhiyhpW3teTE5LGGddgMfMUnvcFqFWUQdTW5sul5f6LkGwO3IQA4Nw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DUu9bFYoudn/gnSmT1wBPmZsEWCuqJjuqfaW6SPhze4=; b=NDCMIOA0p+ciFXY5EZcrrRVDiwnqFRh6hwLVU+vEuIaDeR9ugrdZNuYcpY+o3oJzrFUYyrFlnnhWCmTWYP/SKU+4rWbj5bni9J4TePlnqCL2ps/225VYusXIiyZs5uErMjq0oEAKLC/Yjh8DRgSbDJ5NU6+hKZIyO6W1af2soOCwy3wFuEGtAPsENmw9igii29biX3u4rhA71Vr0FGjB8tPjLea+ScnzNm5wLPkADl9DF77CH865YdsSHjEHxnFbu1nhBXRsv1aaqZQeBifx0QH1i1U13fOtjXsW1pPu44Wx2fFkQYULaU6cRcbR1iHZxCEC267nxnz2nlWNAtGaIA==
ARC-Authentication-Results: i=1; 1; spf=pass; dmarc=pass action=none; dkim=pass; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DUu9bFYoudn/gnSmT1wBPmZsEWCuqJjuqfaW6SPhze4=; b=GxfH/AVZGQBdFGHyOcMcfkbIYWqEvOcsrkOs/t8J7r5W4d9tTBlB73ZvYaSub5B7mt9HXR4eri6wttr7vl5eL4aTusULkpJQjm3RMapdRP5JhBb1F24HsCf9N+JICUdmvNLc4ZPDs9E/oQ+OyBPTzpTylf21Y9fINNDSDUWgSj0=
Received: from YQXPR01MB3640.CANPRD01.PROD.OUTLOOK.COM ( by YQXPR01MB2358.CANPRD01.PROD.OUTLOOK.COM ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2408.24; Mon, 4 Nov 2019 01:05:20 +0000
Received: from YQXPR01MB3640.CANPRD01.PROD.OUTLOOK.COM ([fe80::8841:176d:82ca:842f]) by YQXPR01MB3640.CANPRD01.PROD.OUTLOOK.COM ([fe80::8841:176d:82ca:842f%2]) with mapi id 15.20.2408.024; Mon, 4 Nov 2019 01:05:19 +0000
From: Suresh Krishnan <>
To: Brian E Carpenter <>
CC: Mark Smith <>, Michael Richardson <>, IETF IPv6 Mailing List <>
Subject: Re: Additional Documentation Prefixes (was Re: AD Evaluation : draft-ietf-6man-ra-pref64-06)
Thread-Topic: Additional Documentation Prefixes (was Re: AD Evaluation : draft-ietf-6man-ra-pref64-06)
Thread-Index: AQHVkdGmbpEIAXTBR06W8NLDQ1uxdKd5scWAgAAlf4CAADK2gIAAA52AgAAmn4A=
Date: Mon, 4 Nov 2019 01:05:19 +0000
Message-ID: <>
References: <> <> <27802.1572732078@localhost> <> <24180.1572801507@localhost> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 455531b7-dc21-4c88-a043-08d760c31002
x-ms-traffictypediagnostic: YQXPR01MB2358:
x-microsoft-antispam-prvs: <YQXPR01MB2358D29C2EFB0DDBEA059CCFB47F0@YQXPR01MB2358.CANPRD01.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0211965D06
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(136003)(346002)(366004)(39840400004)(189003)(199004)(66066001)(6246003)(102836004)(229853002)(476003)(5660300002)(4326008)(66574012)(256004)(11346002)(14444005)(6506007)(446003)(6116002)(7736002)(305945005)(508600001)(25786009)(2906002)(3846002)(54906003)(186003)(76176011)(53546011)(6486002)(6436002)(486006)(6512007)(26005)(71200400001)(71190400001)(2616005)(8676002)(81166006)(81156014)(316002)(8936002)(66946007)(99286004)(64756008)(66446008)(76116006)(91956017)(66556008)(66476007)(33656002)(6916009)(36756003)(14454004)(80792005)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:YQXPR01MB2358; H:YQXPR01MB3640.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: DR7aamir1qR14k8TRlFV/JznFG/nDxW/KAxFJiZBvNPIgX0+MjYxtHDvLNHtUwKMWPdwr7KIPHUb2oZ/oROexOceE5IMW/LfPEpZhwDXzIg8VzisVcXLjaZSXpz514kcI0Q9/g3H1XUuq18/GxVMrwDbMgvQH+4hYw6H3qg26iFEsof9+g7NlZwL1qi9vMji+p5tqP3wgCCfPN0cJbaJhRUbD7S05lktNkM1351JQGWhdo7/ojyPSTE2XVVorGG3+exYWjukexqWvxmfZ4e+o914j8JwldcJZ/OmkqkpgIlBJkNgNFsIGLyqVDqbymBqbH+LPAMvwaOFiDQSlCQ/XroGgXUSWoWdnzWj7A9uQn88aFbawgfRhUmJeWo58360jYT6a482r9ESYtFE5fxExoxm+SeXgF5z8gyejX8j4c/1yd4j+IjDY4W1/AgETT4p
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <782751B4816402409E72497E32080B50@CANPRD01.PROD.OUTLOOK.COM>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 455531b7-dc21-4c88-a043-08d760c31002
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2019 01:05:19.8472 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 47d58e26-f796-48e8-ac40-1c365c204513
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 4tSSr8qKGZBaPR8+Vwy6ZrCG0PkSDxpFlq6y011mEdlDRwMkmCL/mxOFu/lnwQ0T5VAht9+r0in7drWzZ/Je7A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQXPR01MB2358
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 04 Nov 2019 01:05:24 -0000

> On Nov 3, 2019, at 5:47 PM, Brian E Carpenter <> wrote:
> On 04-Nov-19 11:34, Mark Smith wrote:
>> On Mon, 4 Nov 2019, 06:33 Brian E Carpenter, < <>> wrote:
>>    On 04-Nov-19 06:18, Michael Richardson wrote:
>>> Suresh Krishnan < <>> wrote:
>>    ...
>>>      >> I'd also like to have three or four additional IPv6 documentation prefixes,
>>>      >> plus some documentation space from ULA-R and ULA-C.
>>>      > What is ULA-R? Did you mean ULA-L? If so, it would be a pain to reserve
>>>      > something now since we also need to update RFC4193 to make sure that
>>>      > the Random “Global ID”s will not collide with the reserved prefixes. If
>>>      > ULA-C does take off, this would be a good idea to do something like
>>>      > this.
>>> I guess L=1 is why you call it ULA-L. I have known it as ULA-Random.
>>> We are both talking about RFC4193 though.  So such a document would need to
>>> update RFC4193.
>>    I think this is a bad and pointless idea. Pointless because it is 100% OK
>>    to use any RFC4193 prefix as an example, since by definition it will never
>>    be used on the Internet, and the chance of collision on a given ULA site
>>    is 1 in 2**40 (and who cares anyway?). Bad because it means that millions
>>    of existing boxes that can generate ULA prefixes would be non-conformant
>>    and, seriously, is any vendor going to update date their firmware for this?
>> I redacted my ULA in examples in a presentation I did recently. That made it impossible to type in and for somebody to duplicate.
>> If the goal is ensure people can't try to use these example addresses on real networks, then perhaps using invalid addresses in the document with a note that they're examples and invalid on purpose is a better idea.
>> For example, using non-hexidecimal letters, with a note about them being substitutes for 'a' through 'f'.
>> E.g.
>> 2001:db8:xxxx:yyyy::zzz1
> Yes, that makes sense, and could be applied to link-local and RFC1918
> addresses too. It's a much less fiddly solution.

+1. Agree that this could be a good solution, I think the idea is to use not very realistic prefixes that people can just cut and paste into real configurations.