Re: [BEHAVE] [v6ops] New features in Legacy IPv4 (was Re: protocols without need for ALG ?)

David Farmer <> Thu, 13 August 2015 23:10 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id AA38E1ACE9C for <>; Thu, 13 Aug 2015 16:10:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.308
X-Spam-Status: No, score=-4.308 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bLFTzoWGNoDX for <>; Thu, 13 Aug 2015 16:10:03 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B9F9A1ACEA2 for <>; Thu, 13 Aug 2015 16:10:03 -0700 (PDT)
Received: from ( []) by (UMN smtpd) with ESMTP (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128/128); for <>; Thu, 13 Aug 2015 18:10:02 -0500 (CDT)
X-Umn-Remote-Mta: [N] [] #+LO+TS+TR
X-Umn-Classification: local
Received: by iodv127 with SMTP id v127so52545280iod.3 for <>; Thu, 13 Aug 2015 16:10:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:from:subject:date:to; bh=Bvco0VYDlQLitTJR3dXPEuufX8vB0XE6y/dDvdgrJhI=; b=L9108dyPiNDhFgEmkyGD0+3aEtaFraCcDdJ7O0znwTxLFmRr5ko3bXLC9+eUmEL+lo m6rcyNchJfUVrdWQINIDRzNcq/4iNgM85qDLhgQqcEJttZJqHTyCCdeSviUgcQI4pyBq LxqXSCn7fj3QssuFpD8zjsq885djUEcipsV5w=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:references:in-reply-to:mime-version:content-type :message-id:content-transfer-encoding:cc:from:subject:date:to; bh=Bvco0VYDlQLitTJR3dXPEuufX8vB0XE6y/dDvdgrJhI=; b=T1urnJURNbbEOZxeWwqNIHydCspeXXnx4Gt7aAlAY7vZBum2NQDbKQhMsEfsTBsx/G 3RLKviCLx3iiE1CNde+yvR5DRS7cC9R2OKExLOlCQzZeWV0+XH48eJXMTZoID2cWPW+k 9VI3k9SG3ygLbkCJvcF2ejMr/gTvrvAAUfQLvlnM6YFu4GggvdKEpmmWQDjiQLXbZszj fodp3pnQysWoW7C911VR3kB2taSNfWPXDg1GIkxqih9N2wztb6P1WrkrAIQ1ADcIcEUx ZS07/meF3ULFb6Ur+g5d1FafJ07+7Yzldq2tzW72ojKjDd0MvEvlAGHAXjJeKPNmV2zZ ncKg==
X-Gm-Message-State: ALoCoQnTHBQycw1YKGtLJxRkraaHvqbl0rnd3vAvNYFbGZ1WNm6ZaoXsd/xKuXamk6YYQgZruJmGsK3Es6gUw5bI9XCVfdh71UVs9jupULF2EOK6pbFkQOT5yiHKjfI8dwjagxVrPSJs
X-Received: by with SMTP id m84mr13223695iod.115.1439507401943; Thu, 13 Aug 2015 16:10:01 -0700 (PDT)
X-Received: by with SMTP id m84mr13223658iod.115.1439507401490; Thu, 13 Aug 2015 16:10:01 -0700 (PDT)
Received: from ?IPv6:2607:ea00:107:2001:78f5:b369:4b3f:b093? ([2607:ea00:107:2001:78f5:b369:4b3f:b093]) by with ESMTPSA id 85sm2608519iot.6.2015. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Aug 2015 16:09:59 -0700 (PDT)
References: <> <> <> <>
In-Reply-To: <>
Mime-Version: 1.0 (1.0)
Content-Type: multipart/alternative; boundary=Apple-Mail-A24E6951-7022-40DC-8A03-80AE2926966F
Message-Id: <>
Content-Transfer-Encoding: 7bit
X-Mailer: iPad Mail (12H143)
From: David Farmer <>
Date: Thu, 13 Aug 2015 18:09:58 -0500
To: "Howard, Lee" <>
Archived-At: <>
Cc: Ca By <>, "" <>, Mark Smith <>, "" <>
Subject: Re: [BEHAVE] [v6ops] New features in Legacy IPv4 (was Re: protocols without need for ALG ?)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 13 Aug 2015 23:10:05 -0000

> On Aug 12, 2015, at 08:25, Howard, Lee <> wrote:
>>>> Is it time to resurrect this draft and push it forward? It doesn't
>>>> explicitly prohibit work of the type proposed in the above drafts, but
>>>> I'd
>>>> like to think that  the current language strongly discourages it.
>>>> Wes George
>>> Yes.  We clearly see that folks need the message to be unambiguous
>> Deprecating IPv4 would do the trick. Doesn't mean you can't use it,
>> doesn't mean it can't continue to be fixed, just means that it has
>> become the legacy Internet protocol.
> I searched in vain for an IETF definition of ³Deprecated,² although I did
> find some examples.
> I found a definition of ³Historic² (sort of) in rfc2026 and an old
> clarifying draft draft-yevstifeyev-genarea-historic-03.
> All of those words seem to suggest that the deprecated/historic/obsolete
> protocol could still be used, but to be careful with it. I¹d call it a
> SHOULD NOT, meaning don¹t unless you have a really good reason.
> I would be delighted if somebody has pointers to better definitions.
> This work would need to happen in 6man or intarea WG, I think. I therefore
> offer no opinion here.

From RFC 7526 "Deprecating the Anycast Prefix for 6to4 Relay Routers", Section 2;

> In this document, the word "deprecate" and its derivatives are used only in their generic sense of "criticize or express disapproval" and do not have any specific normative meaning. A deprecated function might exist in the Internet for many years to allow backwards compatibility.

I personally think it is best for the word to not have a normative meaning, and leave it to plain English.  If you want/need to normatively tell someone something similar use "SHOULD NOT use", "MUST NOT use", or maybe "SHOULD NOT continue development" as appropriate.  

Although this subject seems like excellent fodder for an update to RFC6919. :)

David Farmer                          Email:
Office of Information Technology
University of Minnesota    
2218 University Ave SE         Phone: +1-612-626-0815
Minneapolis, MN 55414-3029   Cell: +1-612-812-9952