Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard

Suresh Krishnan <> Sat, 11 February 2017 06:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E8D071293F9 for <>; Fri, 10 Feb 2017 22:26:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, 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 (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ucm49_Wv-vO5 for <>; Fri, 10 Feb 2017 22:26:51 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c08::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 966FE127735 for <>; Fri, 10 Feb 2017 22:26:51 -0800 (PST)
Received: by with SMTP id 96so42446295uaq.3 for <>; Fri, 10 Feb 2017 22:26:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MNvM1RAwHw+YnBzDJdQ8hXGnJik2CbsIhjIuxOy6cw8=; b=JSkeor5Zleaw9prie4JxBU1aBBINXjjLQwmBzwb+49t2f/NPfrgKWAwBoB8/4fstYB Kb6F2IFbBf1ncKZQV7vkiRH2ul3l5clSQV9MnkTQHKlTUhQA2KJMk1WDTBYJPUloauro ufuzOs/FFyydvQwBEePYnJNIwNsSHR0sLjm60ipCAKubux83pfC0zID8OLfyc+vDAFnq iXhB1CL+6XZ6EO+oQu+QDfEe96axQyxDHWhU5d3wiZT7Eb6qkgJLL+VOGZ2GvGpVgUEf cSskxg3DdLbcJ18CzwSgSizKPbsA+j5oAieo9fauOAgEqKKm0q6U0Yk2IzGz+tMJRCwD UdUg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MNvM1RAwHw+YnBzDJdQ8hXGnJik2CbsIhjIuxOy6cw8=; b=UfQbbU3rgZ7/TsOVvGn52hdl93GTh4gLa/ImCRCmI6HaCLmEQnHmaGCs18VItTqsdk uQISsx73gt3CNvfXalPuIdCbRt2CK0ck/E9uQUKiozNAX2X0LLyE5lF1bixdf+zLs2ei Vj8Ye4tUl2VXJmiFOwNeQPJB8gQ24WMTer9PKk5xMOSSSgUXdcYkYFPynLz2M1aXQJGc 5ueXpH4rvAYfN7JZgvQSpNGNwPbgLaZBZmRytHbtxQ4M3DKDb32PSf/p2AgB4x3gJb9S pyXbQXNj4bVF1BLH/97umZ4DOQO4RZz8fUvBKmVkGf0++t/S18Q7oJy6bzUrjaMi/35N Vzrw==
X-Gm-Message-State: AMke39lmwyhBns4UyMrpJ/WSt7v6iobYzR6jJYXSr2ixfKDy1z0rdQDiF0uekm+vQ3JsMVE23kNt248qBKKrpw==
X-Received: by with SMTP id f3mr5584550uaf.37.1486794410554; Fri, 10 Feb 2017 22:26:50 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Fri, 10 Feb 2017 22:26:49 -0800 (PST)
Received: by with HTTP; Fri, 10 Feb 2017 22:26:49 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <00af01d27e11$fe539500$> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Suresh Krishnan <>
Date: Sat, 11 Feb 2017 01:26:49 -0500
Message-ID: <>
Subject: Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard
To: Randy Bush <>
Content-Type: multipart/alternative; boundary=94eb2c048440b1fce205483b4ca7
Archived-At: <>
Cc: IETF Discussion list <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 11 Feb 2017 06:26:53 -0000

Hi Randy,

On Feb 10, 2017 10:23 PM, "Randy Bush" <> wrote:

just to get down a level from meta-

> If the right answer is to allow packet modifications that break PMTUD
> and IPsec/AH, let's do it, but let's also say we're doing it.

obvious imiho

> I happen to think it's the wrong answer, but that's my problem.

i share it, but this is at the border of my expertise.  i have this
fantasy of pmtu actually working before i retire.  i realize it is

> Leaving the text open to interpretation would make a mockery of
> promoting it to Standard.

agree.  but v6 specs seem to like wussing out and leaving the
opportunity to do wrong things.  i'll bet you a reuben at the corned
beef factory in chicago that the next try at the addressing architecture
still does not *unambiguously* state cidr except for slaac.

Do you mean the affinity for a 64 bit IID for addresses? If so, this has
been widely explored and documented in RFC7421. I agree with you that this
is hard to get out of given the state of implementations. I am not sure how
this draft (rfc2460bis) is related to that though.