Re: [Stackevo-discuss] some comments on draft-iab-protocol-transitions-05

Dave Thaler <> Tue, 21 February 2017 23:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 080281293DB for <>; Tue, 21 Feb 2017 15:15:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Status: No, score=-2.021 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, 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 Tecc9UI7Kjv7 for <>; Tue, 21 Feb 2017 15:15:31 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 58845128BA2 for <>; Tue, 21 Feb 2017 15:15:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wK8EI6hWe+uDLYya7znh8Lx2aHv5WecfUh5ISc2gwQ0=; b=lj8s1OOxCSP9Geue/HHSNWaKOP89V05nzOHSe/m8hnlZB2IybhPtQBlqJTyz5JucGMJSjWAgRiOOIWzEQ5qiGXeVcA5VAIgCeVrsE6uXyLJwfZzIMeK5yoLWAFqWDSoiPznHwBViQ0mQAK1wu1mpljWavdoWmiumO57UPrfLBdw=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.13; Tue, 21 Feb 2017 23:15:29 +0000
Received: from ([]) by ([]) with mapi id 15.01.0919.018; Tue, 21 Feb 2017 23:15:30 +0000
From: Dave Thaler <>
To: Tom Herbert <>, Joe Touch <>
Thread-Topic: [Stackevo-discuss] some comments on draft-iab-protocol-transitions-05
Thread-Index: AQHSa5QEaY3BT13uJ0KJZLVY6WnPgKEyYhWAgEH286A=
Date: Tue, 21 Feb 2017 23:15:29 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: [2001:4898:80e8:7::452]
x-ms-office365-filtering-correlation-id: 942dff22-3a3a-48ce-59f2-08d45aaf8734
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR03MB2268;
x-microsoft-exchange-diagnostics: 1; CY1PR03MB2268; 7:fzsiUofdOewxz8DYq2apZzzwB7K9L6QFbJBvbbM6i7xrdkyCv3rBrvJHPMTDKhzMdazJgKRi9cK/trdOqsxvVSukP06UEJ1oYCCRcObl+Rhss1y+MFcyos10HcZWFg5Oce5anzt6cZUN0pfchcnJnNc6IykLnsUc6mc2PUo+zhDAPYmv9ZQjjh/A5bclRMMkUqS96y9hlqS0LVY6rDuHPmrflSWqbTWXlPyXt1mtKxkqoiajWMWxjqgeLLQ7BUSIMUt9u6F6psuwwdW3Paf6Cs9pAW81XO4M11CcCYhmVzYDVieu5DzWBaTOknTdy/fLFrgYAnIWkPAU+7KkiW9XuL39WEQzasidxqdm4GTbrqE=
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123558025)(20161123564025)(20161123562025)(20161123555025)(6072148); SRVR:CY1PR03MB2268; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2268;
x-forefront-prvs: 0225B0D5BC
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39850400002)(39840400002)(39410400002)(39860400002)(199003)(377454003)(24454002)(13464003)(51914003)(189002)(106356001)(81166006)(105586002)(33656002)(8990500004)(8676002)(81156014)(4326007)(2906002)(102836003)(9686003)(3280700002)(106116001)(6116002)(74316002)(25786008)(6306002)(101416001)(50986999)(10290500002)(229853002)(305945005)(230783001)(76176999)(54356999)(189998001)(3660700001)(53546006)(10090500001)(122556002)(8936002)(53936002)(5005710100001)(6436002)(77096006)(2900100001)(6506006)(68736007)(97736004)(7696004)(99286003)(5660300001)(86612001)(55016002)(2950100002)(2171002)(86362001)(7736002)(6246003)(92566002)(38730400002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2268;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Feb 2017 23:15:29.8963 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2268
Archived-At: <>
Cc: "" <>
Subject: Re: [Stackevo-discuss] some comments on draft-iab-protocol-transitions-05
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IP Stack Evolution Discussion List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 21 Feb 2017 23:15:33 -0000

To circle back, I agree and have added a new "Extensibility" section to address
these comments and others, and I will post an update soon...

However much of the detailed technical discussion is actually in RFC 6709,
which is cited in the new section.

Thanks for the great feedback.


-----Original Message-----
From: Tom Herbert [] 
Sent: Tuesday, January 10, 2017 3:53 PM
To: Joe Touch <>
Cc:; Dave Thaler <>
Subject: Re: [Stackevo-discuss] some comments on draft-iab-protocol-transitions-05

On Tue, Jan 10, 2017 at 2:50 PM, Joe Touch <> wrote:
> Hi, Dave (et al.),
> I had some thoughts on this doc, summarized below. I hope they're useful.
> Joe
> -------
> The discussion of IPv4-6 transition might include a discussion of 
> paths not taken in IPv4, e.g., earlier versions included variable 
> length addressing.
> Regarding new features, it might be useful to discuss how options are 
> handled. We include them to future-proof a protocol, to ease the 
> transition to new features. However, we too often succumb to 
> commercial pressures to ignore this flexibility in favor of performance or economy.
> That's why IPv4 fragments are being dropped, why IPv6 options are now 
> limited in total length, and why options are generally deprecated for 
> traffic that expects to successfully traverse the Internet. It's also 
> how we're boxing ourselves into needing IPv-next rather than 
> augmenting what we have in our hands.
Agreed. The topic of extensibility to facilitate protocol transition needs more discussion. The principle to "Design for extensibility [RFC6709] so that things can be fixed up later." really doesn't seem to have worked out very well for either IPv4 (IP options) or IPv6 (ext. hdrs.) in practice.


> There are a few design lessons here that might be useful to point out. 
> A discussion of TLV vs. fixed tag encodings would be useful. Reasons 
> to put version IDs, or demuxing tags in most protocols would be useful 
> too (as we learned for the TCP Experimental option codepoints). It 
> might be useful to have a more detailed discussion of handling "TBD" 
> fields, e.g., when they MUST be set to X by legacy sources, MUST be ignored vs.
> discarded if not zero by legacy receivers, and when to use each strategy.
> I.e., we're constantly oscillating between considering a "thin waist"
> either ossification or stability; the former when we actually need new 
> capabilities (like more addresses), the latter when we actually want 
> things to work (like running DNS over HTTP). We need to understand 
> that to know whether and how we want to support transitions like these.
> ------
> _______________________________________________
> Stackevo-discuss mailing list