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

Mark ZZZ Smith <markzzzsmith@yahoo.com.au> Wed, 18 February 2015 00:49 UTC

Return-Path: <markzzzsmith@yahoo.com.au>
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 162C61A8846 for <v6ops@ietfa.amsl.com>; Tue, 17 Feb 2015 16:49:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.135
X-Spam-Level: ****
X-Spam-Status: No, score=4.135 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HK_RANDOM_REPLYTO=1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_NONE=-0.0001] 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 ICNuyegYzFmT for <v6ops@ietfa.amsl.com>; Tue, 17 Feb 2015 16:49:52 -0800 (PST)
Received: from nm41-vm10.bullet.mail.gq1.yahoo.com (nm41-vm10.bullet.mail.gq1.yahoo.com [67.195.87.149]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F64C1A90E5 for <v6ops@ietf.org>; Tue, 17 Feb 2015 16:49:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1424220590; bh=IGUeHcjEw1ofNj5q0BGSgnU9iu9iTgdfwrkgiPL6Y2E=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=JTFBVBnBSvsLXw+x/Lop3gyJUtChwNbD/YimhV18Pue2aCW81XdB/FHUrgMDapdqmTGH8REFP3ya0gJ7djy3UUXsohLZikUMhyJDp+PcTYFsINY3RD2JMll0rjBPI7QSNUIj9002cO7u6gJ0AdTyvz99gNjjp4AnzgM0CveSS4PY4whGCCNrSqBmzlmgEanSn/qCfsDeKgjeQU84Ew8ag06Y/DgOpdZf0IArtujOLTKkEUORt+2W7RU6Jlmk0G2dvnZEMfJM5fB4u+LJmHJStgvnhvs/T1BDokWdS7lnL/QL9NsLLyGeag6Gak00efyGZ9TcTGDCLzbSCPIxE2eU5Q==
Received: from [127.0.0.1] by nm41.bullet.mail.gq1.yahoo.com with NNFMP; 18 Feb 2015 00:49:50 -0000
Received: from [216.39.60.181] by nm41.bullet.mail.gq1.yahoo.com with NNFMP; 18 Feb 2015 00:46:51 -0000
Received: from [66.196.81.170] by tm17.bullet.mail.gq1.yahoo.com with NNFMP; 18 Feb 2015 00:46:50 -0000
Received: from [98.139.212.199] by tm16.bullet.mail.bf1.yahoo.com with NNFMP; 18 Feb 2015 00:46:50 -0000
Received: from [127.0.0.1] by omp1008.mail.bf1.yahoo.com with NNFMP; 18 Feb 2015 00:46:50 -0000
X-Yahoo-Newman-Property: ymail-4
X-Yahoo-Newman-Id: 642602.55517.bm@omp1008.mail.bf1.yahoo.com
X-YMail-OSG: 2VgUp.gVM1mbFGZp5aC2svUOM1ZxIDhoS694gmK6WBsyaEp7Qh1p848ERTHvY9z N01YtXXjxPNH7LmZWmamVfFgalO7vXQynoJ_fDk3gudOv8VPgEc6KI3jci40uo5a5IVZIaJunvuA fLPu_P2U1.VGO.h1qkO5QHWBTv5eQhu7c0Jx2mLObxbG0xVTx2tr8kNlfClfKumpAmcfi25rd3rW ShGWNLb3Ib.xK_i0BnZwfbxTytwsN6g5fgS1qSBJZgKgX7BiChJAGbtfuGC8XFm5rdpquvQobFJs nHDbWepm38s5ocyl7LgLrhaa8GFCSHBWCeBafxTsAUGI.CZ.QDesk6C_rfbJ3rIpvckOiEfIQqfw I5eeY5u_o.t14y4dV.g3x8Ex05aQ4YkGLe31ylgy_qoPiFzuw6FFbqeN8ej6WNKmWtC8BJhLiQd2 oI9HG_2MRP3TgtwcW5SIupTQa5WvI7z8IX4GC1fQ7KcqJxGPgtRa..eo8p7I0czRhnGrPSReZS4a VpB6NkS8IITiMpkbjveAUsWBEhp7XVcLIfpzgpvdXTouY4QmzRljLTYkbsMU7HQwnrPXXtJ4K21Z 8iZ50Wajo_lomRKqfEXYVtAU.j4_REwNSTQWw4A3sKlYkRqCxQSGj62pouebKJdroiSAKpLiQ8IF dyYAojL9AjH_IvOApd9HDgtydiOcBaS4nJimH6SBXuvErl55Ie5yte.J26uXBvmrB
Received: by 76.13.26.137; Wed, 18 Feb 2015 00:46:50 +0000
Date: Wed, 18 Feb 2015 00:46:22 +0000
From: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
To: Mark Andrews <marka@isc.org>
Message-ID: <390182967.10574.1424220382446.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: <20150217032029.87BA329A857B@rock.dv.isc.org>
References: <20150217032029.87BA329A857B@rock.dv.isc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/3Exq0Oz-RKGtpunq-IWfS1xVC30>
Cc: "v6ops@ietf.org" <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
Reply-To: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
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: Wed, 18 Feb 2015 00:49:55 -0000




----- Original Message -----
From: Mark Andrews <marka@isc.org>
To: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
Cc: David Conrad <drc@virtualized.org>; "v6ops@ietf.org" <v6ops@ietf.org>
Sent: Tuesday, 17 February 2015, 14:20
Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback-prefix-00.txt


In message <1733494631.8203276.1424140594033.JavaMail.yahoo@mail.yahoo.com>, Ma
rk ZZZ Smith writes:
> 
> 
> 
> 
> ________________________________
> From: Mark Andrews <marka@isc.org>
> To: Mark ZZZ Smith <markzzzsmith@yahoo.com.au> 
> Cc: David Conrad <drc@virtualized.org>; "v6ops@ietf.org" <v6ops@ietf.org> 
> Sent: Tuesday, 17 February 2015, 12:23
> Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback-p
> refix-00.txt
> 
> 
> 
> 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.
> 
> / Actually, 4.2BSD made added the '.1' as the default address, as the '0' the
> y'd originally chosen was the BSD broadcast address:
> 
> http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.2BSD/usr/src/sys/netinet/if_lo
> op.c

Yes, BSD squatted on the address.  I was well aware of the history.

>  For the most part no one uses the rest
> of 127.0.0.0/8 but it is useful to have available.
> 
> / I'm not sure I completely agree with the idea, however the NTP reference cl
> ock drivers use 127.127/16 addresses to make them available to the ntp daemon
> . I think this use is a bit different to what ICANN specified, as those addre
> sses only have local significance on the host that both the ntp daemon and th
> e reference clocks are attached to. Outside of that host they're unreachable 
> and have no meaning. Fortunately with millions of other addresses within 127/
> 8 there are plenty of others to use for other purposes on the host.

Yes, they have squatted on these address for internal uses.  The
only reason this doesn't cause issues is that for the most part
127.0.0.0/8 is not used.

/ How do you know "the most part 127.0.0.0/8 is not used"? I've used it for or seen it used for quite a number of purposes over the last 20 years. I wouldn't invest the 10s and perhaps more than 100 hours in writing an ID in my own time if I didn't see and hadn't seen a lot of value in the large address space that 127/8 provides that ::1/128 doesn't.


> 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.
> 
> 
> / I'm a bit confused by this. 127.0.0.2 traffic should not be leaking outside
>  of the host, as that is contrary to RFC990/RFC1122 rules. So the only risk o
> f collision is two users on the same host. That is of course possible, howeve
> r the great thing is that there are millions of other loopback addresses avai
> lable on the host that the users can choose from, and the ones in use can be 
> viewed with 'netstat -a -4 -n' or similar. Hosts have become pretty much sing
> le user too these days.

I have two different applications which have hard coded 127.0.0.2
port 2356 as the way to connect to them.  Which one gets to use
127.0.0.2 port 2356?  As I said the use of the rest of 127.0.0.0/8
needs to be negotiated.  No one and "rights" on any part of it.

/ So I have a number of responses/questions about this:

- Did you make up this example, because in my experience, it is more common for applications to at least allow specifying IP addresses to bind to if they don't allow changing port numbers.

- Clearly the two application writers didn't negotiate with anybody about their use of 
127.0.0.2 port 2356, because otherwise they wouldn't collide. 

- IOW, "As I said the use of the rest of 127.0.0.0/8 needs to be negotiated." is not true, proven by your own example.

- 127/8 address space is local to the host - it has a host local scope. Addressing scopes to me define domains of expected uniqueness, domains of administration and domains of reachability. If each host has its own 127/8 address space, then the only domains of uniqueness, administration and reachability for 127/8 addresses is the local host. Trying to place global significance on values within 127, as ICANN have attempted to do with 127.0.53.53, violates the host local scope of 127/8.



> / ::1/128 is pretty much single user use.
> 
> In IPv6 we had both link local and site local addresses from the
> get go.  These gave the operator addresses they could use.  They
> were also slightly more complicated than a GUA as you needed to
> specify scope.  We now have ULA addresses which gets rid of the
> need to specify scope.  Just like with 127.0.0.2 you need to negotiate
> the use of a address.
> 
> Reserving a new block of addressing in IPv6 will not stop the need
> to negotiate address use.
> 
> If you need truly automatic assignment you need to go to IANA or a
> RIR (e.g. ARIN and 100.64/10) and request a block for a specific
> 
> purpose.  There is no other way to do truly automatic.
> 
> / From my draft:
> 
> "9.  IANA Considerations
> 
> IANA is requested to allocate 0001::/32 from within 0000::/8 of the
> Internet Protocol Version 6 Address Space, for use as a larger
> loopback prefix for IPv6, as detailed in this memo, and to record it
> in the [IANA-IPV6REG]."

And 1::1 will have what automatic meaning?  Which application get
*exclusive* use of 1::1?

/ None, just like no application gets exclusive use of 127.0.0.1.

1::/32 would be scratch space.

/ Exactly. Another way to describe the difference between 127/8 and ::1/128 is that 127/8 provides millions of host local 'scratch space' addresses, where as ::1/128 provides none. 1::/32 provides plenty of scratch space of 64 IIDs, /64s and larger aggregates of /64s e.g., multiple /48s. 

We already have enough mechanisms to create scatch space.  If you
need a /32 then you can get one from ULA space.  There are 16M /32's
ULA blocks for local assignment.


/ You don't seem to understand the concept of ease of use due to ubiquity, despite repeated statements by myself and others that that would be the benefit of having a IANA defined larger loopback prefix for IPv6.

If a application needs reserved address space that will never collide
with anyone else then the vendor should request it from the RIR's
for the use of the application.  Even if 1::/32 is allocated it is
useless for that purpose.

/ Quite frankly, I'm starting to think you haven't read the draft. If you have, you've missed literally the first sentence of the abstract,

"During the *development and testing* of a network application, it can
be useful to run multiple instances of the application using the same
transport layer protocol port on the same development host, while
also having network access to the application instances limited to
the local host."


Mark

> Mark
> 
> In message <776573476.8036822.1424133091182.JavaMail.yahoo@mail.yahoo.com>, M
> ar
> k ZZZ Smith writes:
> > So the fundamental problem is 'configured like this'. It's a manual operati
> on
> >  to generate and apply a ULA. ULAs on loopbacks aren't going to well known 
> or
> >  ubiquitous.
> > 
> > If you want something to be used you need to make it easy, and the best way
>  t
> > o make something easy is to make it automatic.
> > 
> > The value in 127/8, ::1 and a larger IPv6 loopback prefix is that it is or 
> wo
> > uld be automatically configured by the OS, with operator intervention. It's
>  a
> > lways there, and always available to use. The 4.1c/2.9BSD people though the
> re
> >  was value in automatic configuration of the loopback address on a loopback
>  i
> > nterface, way back in 1982/1983:
> > 
> > http://minnie.tuhs.org/cgi-bin/utree.pl?file=2.9BSD/usr/net/sys/net/if_loop
> .c
> > 
> > http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.1cBSD/a/sys/netinet/if_loop.
> c
> > 
> > 
> > 
> > ----- Original Message -----
> > From: Mark Andrews <marka@isc.org>
> > To: David Conrad <drc@virtualized.org>
> > Cc: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>; "v6ops@ietf.org" <v6ops@iet
> f.
> > org>
> > Sent: Tuesday, 17 February 2015, 10:22
> > Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback
> -p
> > refix-00.txt
> > 
> > 
> > We don't need *more* reserved address for this.  This is from my
> > laptop and it has been configured like this for years.
> > 
> > Yes, I have a ULA site on my loopback interface.  If your loopback
> > interface does not support this it is broken.
> > 
> > 
> > Mark
> > 
> > lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
> >     options=3<RXCSUM,TXCSUM>
> >     inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 
> >     inet 127.0.0.1 netmask 0xff000000 
> >     inet6 ::1 prefixlen 128 
> >     inet 10.53.0.1 netmask 0xffffffff 
> >     inet6 fd92:7065:b8e:ffff::1 prefixlen 64 
> >     inet 10.53.0.2 netmask 0xffffffff 
> >     inet6 fd92:7065:b8e:ffff::2 prefixlen 64 
> >     inet 10.53.0.3 netmask 0xffffffff 
> >     inet6 fd92:7065:b8e:ffff::3 prefixlen 64 
> >     inet 10.53.0.4 netmask 0xffffffff 
> >     inet6 fd92:7065:b8e:ffff::4 prefixlen 64 
> >     inet 10.53.0.5 netmask 0xffffffff 
> >     inet6 fd92:7065:b8e:ffff::5 prefixlen 64 
> >     inet 10.53.0.6 netmask 0xffffffff 
> >     inet6 fd92:7065:b8e:ffff::6 prefixlen 64 
> >     inet 10.53.0.7 netmask 0xffffffff 
> >     inet6 fd92:7065:b8e:ffff::7 prefixlen 64 
> >     inet 10.53.0.8 netmask 0xffffffff 
> >     inet6 fd92:7065:b8e:ffff::8 prefixlen 64 
> >     inet 10.53.0.9 netmask 0xffffffff 
> >     inet6 fd92:7065:b8e:ffff::9 prefixlen 64 
> >     inet 10.53.0.10 netmask 0xffffffff 
> >     inet6 fd92:7065:b8e:ffff::10 prefixlen 64 
> > 
> > -- 
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

> 
> 
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org