Re: [v6ops] New Version Notification for draft-ipversion6-loopback-prefix-00.txt

t.petch <ietfc@btconnect.com> Thu, 19 February 2015 10:42 UTC

Return-Path: <ietfc@btconnect.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D43DD1A8AC2 for <v6ops@ietfa.amsl.com>; Thu, 19 Feb 2015 02:42:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.598
X-Spam-Level:
X-Spam-Status: No, score=0.598 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_15=0.6, SPF_HELO_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1j59G3gxfzvG for <v6ops@ietfa.amsl.com>; Thu, 19 Feb 2015 02:42:14 -0800 (PST)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0709.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::709]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 649331A8AAC for <v6ops@ietf.org>; Thu, 19 Feb 2015 02:42:12 -0800 (PST)
Received: from pc6 (81.151.167.59) by AMXPR07MB056.eurprd07.prod.outlook.com (10.242.67.151) with Microsoft SMTP Server (TLS) id 15.1.87.18; Thu, 19 Feb 2015 10:41:46 +0000
Message-ID: <034e01d04c30$66fde1c0$4001a8c0@gateway.2wire.net>
From: t.petch <ietfc@btconnect.com>
To: Mark Andrews <marka@isc.org>
References: <20150216232213.3123C29A61F1@rock.dv.isc.org> <776573476.8036822.1424133091182.JavaMail.yahoo@mail.yahoo.com> <20150217012326.698E829A71C4@rock.dv.isc.org> <024f01d04b68$49ae8340$4001a8c0@gateway.2wire.net> <20150218111024.DCF1A29E9E3B@rock.dv.isc.org>
Date: Thu, 19 Feb 2015 10:15:41 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [81.151.167.59]
X-ClientProxiedBy: DB4PR05CA0033.eurprd05.prod.outlook.com (25.160.40.43) To AMXPR07MB056.eurprd07.prod.outlook.com (10.242.67.151)
Authentication-Results: isc.org; dkim=none (message not signed) header.d=none;
X-Microsoft-Antispam: UriScan:;
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB056;
X-Microsoft-Antispam-PRVS: <AMXPR07MB0564890DF45B37D85A29E82BE2D0@AMXPR07MB056.eurprd07.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005003); SRVR:AMXPR07MB056;
X-Forefront-PRVS: 0492FD61DD
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(51704005)(377454003)(61296003)(62236002)(23756003)(86362001)(40100003)(77156002)(62966003)(66066001)(42186005)(122386002)(47776003)(116806002)(93886004)(230783001)(44716002)(92566002)(46102003)(87976001)(110136001)(33646002)(77096005)(81686999)(19580395003)(50986999)(19580405001)(76176999)(84392001)(50466002)(14496001)(50226001)(44736004)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB056; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en;
X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB056;
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Feb 2015 10:41:46.7595 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB056
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/2o73NyXPUL6WZpgMUBkraiYYX_E>
Cc: v6ops@ietf.org
Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback-prefix-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Feb 2015 10:42:17 -0000

--- Original Message -----
From: "Mark Andrews" <marka@isc.org>
Sent: Wednesday, February 18, 2015 11:10 AM

> In message <024f01d04b68$49ae8340$4001a8c0@gateway.2wire.net>et>, t.petch
<ietfc@btconnect.com> writes:
> > ----- Original Message -----
> > From: "Mark Andrews" <marka@isc.org>
> > Sent: Tuesday, February 17, 2015 1:23 AM
> >
> > > The fundemental reason for 127.0.0.0/8 was to give each node a
> > > addresses block they could use. 127.0.0.1 evolved as the
"standard"
> > > loopback address over time.  For the most part no one uses the
rest
> > > of 127.0.0.0/8 but it is useful to have available.  That said any
> > > use of the rest of 127.0.0.0/8 has to be negotiated between the
> > > users.  You can't just grab 127.0.0.2 and hope that no one else is
> > > using it for IP traffic.
> >
> > Mark
> >
> > I would refer you to RFC5782 and RFC6471 for a discussion on the use
of
> > 127.0.0.2 (and ::FFFF:7F00:2 ).
>
> RFC5782 Informational.
> RFC6471 Informational.
>
> And they actually grabbed namespaces in the DNS not addresses.
> Neither of them use those "addresses" for IP traffic which
> is what the proposed reservation of the block is about.
>
> The only reason 127.0.0.2 etc. are use for rbls is that it
> was possible to get sendmail to do a address lookup from
> sendmail.cf without hacking the code.  They returned values
> are tokens not addresses despite them being encoded in
> A/AAAA records.
>
> Raising RFC5782 and RFC6471 is a Red Herring.

Mark

Classifying those two RFC as Informational is a subtlety that those
reading this e-mail will understand but most will not (as I am reminded
of when I have seen manufacturers cite conformance to Internet
Drafts:-).   I am sure that if I looked hard enough I would find these
RFC being cited as if they were Standards, let alone a BCP.  And note
the title of RFC6471

'overview of Best email dns-based list (DNSBL) Operational Practices '
(my capitalisation).

As I recall, the reason why it is not a BCP, when it is a BCP in all but
name, is political, that the BCP stream is owned by the IETF and that
RFC is not a product of the IETF.

So, rightly or wrongly, the IETF has implicitly endorsed a usage of
127.0.0.n, where n is a small number, and it would be foolish, IMHO, to
endorse a separate usage.  (For some reason, the choice of percent for
interface identifiers, when percent was already spoken for in URIs,
comes to mind).

Last I heard, IPv6 is different, that the number of MX is small, the
namespace is enormous and so while ::FFFF:7F00:2 was posited, it is
unlikely to gain much traction.

Tom Petch

> Mark
>
> > Perhaps those RFC should have included an IANA Considerations:-(
> >
> > Tom Petch
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org