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

From: Edward Lewis <[email-masked]>
Date: Sun, 15 Feb 2015 17:08:28 +0000

If it pleases the chairs . . .

(I thought I sent this earlier but I don’t see it in the archives.
If it did go out, please forgive the repeat.)

Below is an announcement for yet-another--00 that I’d like to get some
feed back on.   From reading the charter to see if it would be appropriate
to mention the draft, I believe it is appropriate.  (Mindful that I’ve
been wrong before.)

Whether or not it is a candidate for WG adoption is another matter.  For
now, I’d appreciate thoughts on whether this is a ‘good idea’ to develop
or not.

Ed Lewis

On 2/12/15, 14:26, "[email-masked]" <[email-masked]>
wrote:

>
>A new version of I-D, draft-ipversion6-loopback-prefix-00.txt
>has been successfully submitted by Edward Lewis and posted to the
>IETF repository.
>
>Name:		draft-ipversion6-loopback-prefix
>Revision:	00
>Title:		Loopback Prefix for IPv6
>Document date:	2015-02-12
>Group:		Individual Submission
>Pages:		3
>URL:            
>http://www.ietf.org/internet-drafts/draft-ipversion6-loopback-prefix-00.tx
>t
>Status:        
>https://datatracker.ietf.org/doc/draft-ipversion6-loopback-prefix/
>Htmlized:      
>http://tools.ietf.org/html/draft-ipversion6-loopback-prefix-00
>
>
>Abstract:
>    The IPv6 address range of 0::/64 is reserved for loopback addresses.
>    This expands from the single loophack address already defined for
>IPv6,
>    ::1, to allow for a set of addresses to be used when packets are
>intended
>    to stay within a host system.  Multiple loopback addresses allow for
>    simultaneous varied uses of the loopback addresses as has proven,
>albeit
>    in limited ways, in IPv4.  And exception is made to accomodate the
>    ::0/128, already defined as The Unspecified Address.
>
>                  
>        
>
>
>Please note that it may take a couple of minutes from the time of
>submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>The IETF Secretariat
>

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sun, 15 Feb 2015 22:05:52 +0100

Hi Edward,

I reviewed your draft. You defined two use cases. I think in testing purposes, usually there is one target service (right?) and It is likely that only one loopback address is enough (there are many ports available) Is there a use case that in IPv4 more than one loopback addresses were in use concurrently to test the communication of a service?

For DNS purpose, I am not sure how this process is useful. Why to redirect the error messages to xx loopback address and then store somewhere for operators? How this process help the debugging of a service like DNS that is application? I think that now one can easily log the sender, receiver and the whole error message.  I still do not understand the purpose...

,
Best,
Hosnieh

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of Edward Lewis
> Sent: Sunday, February 15, 2015 6:08 PM
> To: [email-masked]
> Subject: [v6ops] FW: New Version Notification for draft-ipversion6-loopback-
> prefix-00.txt
> 
> to mention the draft, I believe it is appropriate.  (Mindful that I’ve been wrong
> before.)
> 
> Whether or not it is a candidate for WG adoption is another matter.  For now,
> I’d appreciate thoughts on whether this is a ‘good idea’ to develop or not.
> 
> Ed Lewis
> 
> >has been successfully submitted by Edward Lewis and posted to the IETF
> >repository.
> >
> >submission until the htmlized version and diff are available at
> >tools.ietf.org.
> >
> >The IETF Secretariat
> >

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 15 Feb 2015 22:29:57 -0800

> now, I’d appreciate thoughts on whether this is a ‘good idea’ to develop

IIRC this idea has come up at least once before, and maybe more (not sure
where - perhaps in v6ops?). I don't oppose it - in fact, I think it's a
good idea - but since the previous attempt(s) never came to anything, I
assume there was no consensus that this is useful.

If you choose ::/64 as your loopback prefix, then you're specifiying a
range that includes all IPv4-compatible addresses (::192.0.2.1) and all
IPv4-mapped addresses (::ffff:192.0.2.1) in addition to ::/128
(unspecified) and ::1/128 (loopback).

---

From: Erik Kline <[email-masked]>
Date: Sun, 15 Feb 2015 23:09:02 -0800

> where - perhaps in v6ops?). I don't oppose it - in fact, I think it's a good
> idea - but since the previous attempt(s) never came to anything, I assume
> there was no consensus that this is useful.

Yep.  1::/32.

https://tools.ietf.org/html/draft-smith-v6ops-larger-ipv6-loopback-prefix-04#section-3

---

From: Mark ZZZ Smith <[email-masked]>
Date: Mon, 16 Feb 2015 09:29:10 +0000 (UTC)

So the author of the new proposal is from ICANN. They're don't provide a reference, however they seem to proposing this use case as one purpose (the "ICANN's Controlled Interruption" referred to):

https://www.icann.org/resources/pages/name-collision-2013-12-06-en

"127.0.53.53
127.0.53.53 is a special IPv4 address that will appear in system logs alerting system administrators that there is potential name collision issue, enabling a quick diagnosis and remediation. The "53" is used as a mnemonic to indicate a DNS-related problem owing to the use of network port 53 for the DNS service."

Note that the above 127.0.53.53 address is not reserved in IANA's IPv4 special address registry. It should be, however as they didn't consult the IETF, it seems it also didn't go to IANA (a department of ICANN!). (
https://www.icann.org/en/system/files/files/name-collision-framework-30jul14-en.pdf)

I'd strongly object to them attempting to do the same thing with an larger IPv6 loopback prefix. A loopback prefix is local to the host it appears on, and is not globally unique. Consequently, all addresses within the prefix should be available for use on the local host for what ever purpose the local host or its user decides. There should be no hidden reserved values with special global meaning.

If ICANN want to do the above for IPv6, they should instead reserve a new IPv6 prefix, similar to how RFC6666 defines a special purpose discard prefix. There is plenty of IPv6 space to do so, rather than creating a single address exception out of a block of addresses that has or would have a well known expected purpose and behaviour.

Regards,
Mark (author of below)

----- Original Message -----
From: Erik Kline <[email-masked]>
To: Lorenzo Colitti <[email-masked]>
Cc: Edward Lewis <[email-masked]>; "[email-masked]" <[email-masked]>
Sent: Monday, 16 February 2015, 18:09
Subject: Re: [v6ops] FW: New Version Notification for draft-ipversion6-loopback-prefix-00.txt

Yep.  1::/32.

_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Erik Kline <[email-masked]>
Date: Mon, 16 Feb 2015 18:39:00 +0900

> If ICANN want to do the above for IPv6, they should instead reserve a new IPv6 prefix, similar to how RFC6666 defines a special purpose discard prefix. There is plenty of IPv6 space to do so, rathe…

Ah, then perhaps they could even just use 0100::53:53 (or 0100::35:35).

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 16 Feb 2015 11:46:25 +0000

On 16/02/2015 09:39, Erik Kline wrote:
>> If ICANN want to do the above for IPv6, they should instead reserve a
>> new IPv6 prefix, similar to how RFC6666 defines a special purpose
>> discard prefix. There is plenty of IPv6 space to do so, rather than
>> creating a single address exception out of a block of addresses that
>> has or would have a well known expected purpose and behaviour.
> 

Or not.  There isn't a shortage of candidate ipv6 prefixes, so why squat on
the discard prefix?

Nick

---

From: Edward Lewis <[email-masked]>
Date: Mon, 16 Feb 2015 13:03:19 +0000

On 2/16/15, 4:29, "Mark ZZZ Smith" <[email-masked]> wrote:

>...They're don't provide a reference, however they seem to proposing this
>use case as one purpose (the "ICANN's Controlled Interruption" referred
>to):
>

My apologies.   I uploaded the wrong edition of the -00 I have on disk,
the one I meant to upload had a reference to that and a few other
(insignificant) edits.  But no matter - the draft covered the point and
feedback so far has been useful.

Ed Lewis
Yes, I now work for ICANN ;)

PS - The reference to the previous attempt to do this is useful to have.
And I was aware of the IPv4 mapped addresses, but misread where they were
in the address space.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 16 Feb 2015 16:08:24 +0000

After checking the mail archives, I see where that ratholed.

On 2/16/15, 4:29, "Mark ZZZ Smith" <[email-masked]> wrote:

>If ICANN want to do the above for IPv6, they should instead reserve a new
>IPv6 prefix, similar to how RFC6666 defines a special purpose discard
>prefix. There is plenty of IPv6 space to do so, rather than creating a
>single address exception out of a block of addresses that has or would
>have a well known expected purpose and behaviour.

It’s not just ICANN (which I noted in the version of the draft that was
*supposed* to be posted).  The use case is evident in applications that
want to signal some meaning/semantic in the address (kind of a overt
covert channel) and then want the other end to not make use of the
address.  Another example (beyond name collision) is DNS black lists:

127.0.0.1 - whitelist -> trusted
127.0.0.2 - blacklist -> block
127.0.0.3 - yellowlist -> mix

What these cases need is not a loopback per se, the misconception had been
from IPv4 co-mingling loopback and the ability to create the "overt covert
channel."

Back to the drawing board...

---

From: David Conrad <[email-masked]>
Date: Mon, 16 Feb 2015 15:04:00 -0800

Mark,

> Note that the above 127.0.53.53 address is not reserved in IANA's IPv4 special address registry. It should be,

Could you explain why?

A number of RBLs use localhost addresses as flags to designate different forms of block lists (e.g., https://www.spamhaus.org/zen/). Do you believe those should be registered in the IANA IPv4 special address registry?

> If ICANN want to do the above for IPv6, they should instead reserve a new IPv6 prefix, similar to how RFC6666 defines a special purpose discard prefix.

OK.  However, for clarity, this isn't specifically about "Controlled Interruption" or what ICANN "wants". It is about trying to have the same sort of facility that is available in IPv4 for IPv6.

Is there some reason I'm unaware of why IPv6 does not have a loopback prefix that allows a network of more than one host like IPv4?

Thanks,
-drc
(ICANN CTO, but speaking only for myself)

---

From: Mark ZZZ Smith <[email-masked]>
Date: Mon, 16 Feb 2015 23:16:53 +0000 (UTC)

----- Original Message -----
From: Edward Lewis <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: 
Sent: Tuesday, 17 February 2015, 3:08
Subject: Re: [v6ops] FW: New Version Notification for draft-ipversion6-loopback-prefix-00.txt

It’s not just ICANN (which I noted in the version of the draft that was
*supposed* to be posted).

/ ICANN should know better than pretty much anybody else about how to do something properly and most certainly be leading by example. ICANN has no ability to claim ignorance on how Internet specifications are developed and reviewed, and how IANA reserves special purpose values.

  The use case is evident in applications that
want to signal some meaning/semantic in the address (kind of a overt
covert channel) and then want the other end to not make use of the
address.  Another example (beyond name collision) is DNS black lists:

/ These addresses do not have this semantic meaning to me, because I do not deal with DNS black lists (and don't think they're a great way to solve the spam problem anyway).

/ This problem is all about signalling colliding names or other semantics in DNS, so DNS is where the problem is best solved, rather than at the IP address layer. The best people to talk to then are the IETF DNS working group (dnsop wg), as they're the experts on DNS. RCODE YXDOMAIN, "Some name that ought not to exist, does exist." at face value sounds like the right one to use, if not, they can assign a new RCODE with corresponding specifications.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 17 Feb 2015 10:22:12 +1100

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: [email-masked]

---

From: Mark ZZZ Smith <[email-masked]>
Date: Tue, 17 Feb 2015 00:23:16 +0000 (UTC)

________________________________
From: David Conrad <[email-masked]>
To: Mark ZZZ Smith <[email-masked]> 
Cc: "[email-masked]" <[email-masked]> 
Sent: Tuesday, 17 February 2015, 10:04
Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback-prefix-00.txt

Mark,

Could you explain why?

/ Yes. If they're supposed to have global and universal meaning, they should be an global registry of some form. Are, for example, spamhaus the global authority on the semantic meaning of 127/8 addresses? Are they the global authority on the semantic meaning of 127/8 addresses when performing DNS blacklisting? 

/ What specific facility? I agree with having a larger IPv6 loopback prefix because of the reasons I outlined in the larger loopback ID I wrote a few years ago. I don't agree with then punching "global" holes in that host-local address space for specific meaning for specific application protocols. By themselves, IP addresses do not have any application semantics - they're either an end-point identifier or locator.

/ Other people here would know far better than I would however it is likely just that 127/8 seemed excessive in the context of IPv4 addresses running out. As for why 127/8 was a /8, I went looking for some explanation while writing that ID. Here's a summary of what I found:

- RFC790, "Assigned Numbers", September 1981, first listed (Class A) 127 as reserved. Previously it had been listed as Unassigned in RFC776, "Assigned Numbers",  January 1981.

- RFC990, "Assigned Numbers", November 1986, first described the loopback operation:

         "The class A network number 127 is assigned the "loopback"
         function, that is, a datagram sent by a higher level protocol
         to a network 127 address should loop back inside the host.  No
         datagram "sent" to a network 127 address should ever appear on
         any network anywhere."

- Going by the early TCP-IP mailing list archives (http://www-mice.cs.ucl.ac.uk/multimedia/misc/tcp_ip/), it seems that Class A 127 being used as a loopback network first occurred on 4.x releases of BSD unix.

- The first email to that list was a complaint about them leaking from Dave Mills (I think Dave is also the original NTP person):

4-Apr-86 11:36:40-PST,697;000000000001
Received: from USC-ISID.ARPA by SRI-NIC.ARPA with TCP; Fri 4 Apr 86 11:31:03-PST
Date:  4 Apr 1986 14:29:47 EST
From: [email-masked]
Subject: Martians go home
To:   [email-masked]

Folks,

I just caught a beta-4.3bsd coughing up ICMP Source Quench and claiming
its address to be 127.0.0.1, but truly was on a net-128.5 subnet. This
is yet again evidence supporting the well-travelled axiom that says
to resist the urge to encroach on the net-address space as a substitute
for intra-host routing mechaniss. I would like to suggest that
a new net be conceived called DEAD-LETTER with net number 127.0. Volunteers
are invited to submit gateways to that net.

Dave

- The earliest dated BSD source code code file that I found for a loopback interface with a 127 address was in 2.9BSD, although according to the website 2.9BSD was released later than 4.2BSD.

http://minnie.tuhs.org/cgi-bin/utree.pl?file=2.9BSD/usr/net/sys/net/if_loop.c

- What looks to be a datestamp that file seems to be "82/06/20" or June 1982.

- Classes within IPv4 addresses were defined somewhere between RFC760 (January 1980) and RFC791 (September 1981).

- As mentioned before, in RFC776, January 1981, 127 was unassigned, where as in RFC790, September 1981, it became reserved. So the above source code is all around the time that Classes within IPv4 addresses were being defined, and I suspect that the BSD people chose to use unassigned 127 for their loopback prefix before Classes B and C existed (i.e., all IPv4 addresses had 'Class A' structure'), which is why it is (now) so large.

Regards,
Mark.

Thanks,
-drc

---

From: Mark ZZZ Smith <[email-masked]>
Date: Tue, 17 Feb 2015 00:31:31 +0000 (UTC)

So the fundamental problem is 'configured like this'. It's a manual operation 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 to 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 would be automatically configured by the OS, with operator intervention. It's always there, and always available to use. The 4.1c/2.9BSD people though there was value in automatic configuration of the loopback address on a loopback interface, way back in 1982/1983:

http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.1cBSD/a/sys/netinet/if_loop.c

----- Original Message -----
From: Mark Andrews <[email-masked]>
To: David Conrad <[email-masked]>
Cc: Mark ZZZ Smith <[email-masked]>; "[email-masked]" <[email-masked]>
Sent: Tuesday, 17 February 2015, 10:22
Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback-prefix-00.txt

Mark

---

From: Erik Kline <[email-masked]>
Date: Tue, 17 Feb 2015 09:49:40 +0900

I was wondering about maybe an update/doc that merged this use case?

I was in favor of your loopback prefix, as I recall (it would be
especially handy if any application should implicitly bind to
1::${RAND96} /without/ any special permissions), but I can't recall
the opposition at the time.

/me re-reads/

Ah, yeah it turns out the use cases I wanted it for are exactly the
ones that were opposed by others at the time (the implicit delivery of
all packets to destinations in this prefix is /technically/ new
behaviour).  Sad panda.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 17 Feb 2015 10:09:03 +0900

> interface does not support this it is broken.

Forgive me, but that seems a bit silly. If you're going to assign an IPv6
address range to your loopback interface, why not make that address
predictable?

The value of the loopback prefix is not that it's routed to loopback. It's
that *everybody knows* it's always routed to loopback.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 17 Feb 2015 12:23:25 +1100

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.

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.

Mark

In message <[email-masked]>, Mar
k ZZZ Smith writes:
> So the fundamental problem is 'configured like this'. It's a manual operation
>  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 there
>  was value in automatic configuration of the loopback address on a loopback i
> nterface, way back in 1982/1983:
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 17 Feb 2015 10:26:49 +0900

> purpose.  There is no other way to do truly automatic.

There is. Just make the block big enough and pick addresses out of it at
random.

---

From: Mark ZZZ Smith <[email-masked]>
Date: Tue, 17 Feb 2015 02:12:38 +0000 (UTC)

Well, it was actually a completely new prefix (but similar to ::1/128 to make easy to remember ('1' at the front verses '1' at the end), so I think new behaviour is fine. I did propose slightly different loopback/forwarding processing for this new 1::/32 prefix to match how 127/8 is processed, different to the current ::1/128 rules:

5.2.  Router Rules
   IPv4 loopback packet processing rules for routers, specified in   [RFC1812], by default prohibited forwarding of packets with 127/8   destinations, other than those originated locally and returned back   to the router itself.  A software switch could be provided to disable   this prohibition.  This special case of allowing forwarding of   packets towards 127/8 destinations has been taken advantage of by   [RFC4379], for MPLS troubleshooting purposes.  An equivalent function   for IPv6 is provided by using the IPv4-Mapped IPv6 prefix of ::ffff:

Smith                    Expires August 24, 2013                [Page 7] Internet-Draft        A Larger IPv6 Loopback Prefix        February 2013

   127.0.0.0/104.
   The existing ::1/128 packet processing rules for routers are the same   as those for IPv6 hosts [RFC4291].
   For the new larger loopback prefix, the IPv6 router processing rules   are changed to match those of IPv4, to suit future uses similar to   the MPLS troubleshooting case.
      From: Erik Kline <[email-masked]>
 To: Mark ZZZ Smith <[email-masked]> 
Cc: David Conrad <[email-masked]>; "[email-masked]" <[email-masked]> 
 Sent: Tuesday, 17 February 2015, 11:49
 Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback-prefix-00.txt

/me re-reads/

---

From: Falcon Darkstar Momot <[email-masked]>
Date: Mon, 16 Feb 2015 19:15:48 -0700

> / This problem is all about signalling colliding names or other semantics in DNS, so DNS is where the problem is best solved, rather than at the IP address layer. The best people to talk to then ar…
I suggest that perhaps the best way to handle this is not to use A or
AAAA records at all, but rather TXT records with specific text in the
tag (or request an entirely new RRtype, called something like MXTRUST). 
Allocating a large swath of IPv6 address space, even though we have a
lot of it, seems like exactly the wrong thing to do here -- addresses
are addresses, not tags.

--
--Falcon Darkstar Momot
--Shadytel

---

From: David Conrad <[email-masked]>
Date: Mon, 16 Feb 2015 18:19:21 -0800

Mark,

> Yes. If they're supposed to have global and universal meaning, they should be an global registry of some form. Are, for example, spamhaus the global authority on the semantic meaning of 127/8 addresses? Are they the global authority on the semantic meaning of 127/8 addresses when performing DNS blacklisting?

Sorry, your "yes" confuses me. I don't believe Spamhaus' use of 127/8 is intended to have global or universal meaning: they are understood by the folks who make use of Spamhaus RBLs. Nor do I think Spamhaus assuming global authority for the semantic meaning of 127/8 or even when performing DNS blacklisting.

Now, if Spamhaus wrote an RFC that says "if you want to use DNS to identify specific RBL sub-types, the address 127.0.0.2 means type X, .3 means type Y, etc." and other blacklist providers thought that was useful, I could see a point for listing those addresses in an IANA registry, however I don't think there's sufficient interest and it wouldn't be Spamhaus being the global authority, that would still rest with the IANA.

> / What specific facility?

Sorry, I was speaking of the general loopback network functionality.

> I agree with having a larger IPv6 loopback prefix because of the reasons I outlined in the larger loopback ID I wrote a few years ago.

I wasn't aware of that earlier effort.  Thanks for the reference. Interesting reading.

> I don't agree with then punching "global" holes in that host-local address space for specific meaning for specific application protocols.

I gather then that you disagree with Spamhaus' use of 127/8 as flags for particular RBLs?

> By themselves, IP addresses do not have any application semantics - they're either an end-point identifier or locator.

A philosophical point, but I'd go further and say that by themselves, IP addresses are just integers -- the semantics, including end point identification and/or routing location, are imposed by the applications (including host and router software) that make use of them.

Regards,
-drc

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 17 Feb 2015 11:23:57 +0900

> lot of it, seems like exactly the wrong thing to do here -- addresses

That doesn't make sense. A /64 *is* a large swath of IPv6 address space.
And there are lots of them.

---

From: Falcon Darkstar Momot <[email-masked]>
Date: Mon, 16 Feb 2015 19:27:45 -0700

On 16/02/2015 19:23, Lorenzo Colitti wrote:
> On Tue, Feb 17, 2015 at 11:15 AM, Falcon Darkstar Momot
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> That doesn't make sense. A /64 *is* a large swath of IPv6 address
> space. And there are lots of them.

The point is that they're addresses, not tags.  Why would you allocate
addresses that have absolutely no purpose in relation to routing?

If a use case (involving routing) for multiple loopback addresses is
evident, I'd say this makes sense, but I just don't see it.  DNS RBL
tagging is not such a use case.

--
--Falcon Darkstar Momot
--Shadytel

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 17 Feb 2015 11:30:27 +0900

> addresses that have absolutely no purpose in relation to routing?

That's what we did in IPv4 with 127.0.0.0/8. As a proportion to the size of
the IPv4 address pool, that's way more space than we're talking about here.

> tagging is not such a use case.

Pointing network  at addresses inside 127.0.0.0/8 is a very reliable way to
cause said applications to fail fast without emitting any packets. We don't
have a way to do that in IPv6 except pointing them at ::1.

---

From: Falcon Darkstar Momot <[email-masked]>
Date: Mon, 16 Feb 2015 19:33:29 -0700

On 16/02/2015 19:30, Lorenzo Colitti wrote:
> On Tue, Feb 17, 2015 at 11:27 AM, Falcon Darkstar Momot
>     The point is that they're addresses, not tags.  Why would you
>     allocate addresses that have absolutely no purpose in relation to
>     routing?
>
>
> That's what we did in IPv4 with 127.0.0.0/8 <http://127.0.0.0/8>. As a
> proportion to the size of the IPv4 address pool, that's way more space
> than we're talking about here.
>  
>
>     If a use case (involving routing) for multiple loopback addresses
>     is evident, I'd say this makes sense, but I just don't see it. 
>     DNS RBL tagging is not such a use case.
>
>
> Pointing network  at addresses inside 127.0.0.0/8 <http://127.0.0.0/8>
> is a very reliable way to cause said applications to fail fast without
> emitting any packets. We don't have a way to do that in IPv6 except
> pointing them at ::1.

How about discard, 0100::/64 as per RFC6666?  This seems rather more
explicit than using loopback as discard.

---

From: Mark ZZZ Smith <[email-masked]>
Date: Tue, 17 Feb 2015 02:36:34 +0000 (UTC)

Sent: Tuesday, 17 February 2015, 12:23

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' they'd originally chosen was the BSD broadcast address:

http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.2BSD/usr/src/sys/netinet/if_loop.c

 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 clock 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 addresses only have local significance on the host that both the ntp daemon and the 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.

That said any

/ 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 of collision is two users on the same host. That is of course possible, however the great thing is that there are millions of other loopback addresses available 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 single user too these days.

/ ::1/128 is pretty much single user use.

/ 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]."

Mark

---

From: Mark Andrews <[email-masked]>
Date: Tue, 17 Feb 2015 14:20:28 +1100

In message <[email-masked]>, Ma
rk ZZZ Smith writes:
> / Actually, 4.2BSD made added the '.1' as the default address, as the '0' the
> y'd originally chosen was the BSD broadcast address:
> 

Yes, BSD squatted on the address.  I was well aware of the history.
 
> / 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.

> / 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.

> loopback prefix for IPv6, as detailed in this memo, and to record it

And 1::1 will have what automatic meaning?  Which application get
*exclusive* use of 1::1?  1::/32 would be scratch space.

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.

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.

Mark

> > Cc: Mark ZZZ Smith <[email-masked]>; "[email-masked]" <v6ops@iet
> f.
> > org>
> > Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback
> -p
> > refix-00.txt
> > 
> >

---

From: Mark Andrews <[email-masked]>
Date: Tue, 17 Feb 2015 15:39:12 +1100

In message <CAKD1Yr0JZ735RWO=[email-masked]>
> have a way to do that in IPv6 except pointing them at ::1.

Packets to from fe80::1%lo0 only go over the loopback interface.

Mark

---

From: Mark Andrews <[email-masked]>
Date: Tue, 17 Feb 2015 15:29:11 +1100

In message <CAKD1Yr3xoBydCWyvnqearUY4LyObhgjnB=[email-masked]>
> There is. Just make the block big enough and pick addresses out of it at

And you still need to have a strategy to deal with collisions.  You
also need to be able to communicate the resulting address to all
components that need to know it.

I still see no benefit between picking a random block in 1::/32 vs
picking a random block in fd00::/8.  In both cases you have to deal
with collisions.

Mark

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 17 Feb 2015 19:35:36 +0900

> Packets to from fe80::1%lo0 only go over the loopback interface.

But fe80::1%lo0 doesn't work on my machine because my loopback interface is
called lo, not lo0. And you can't put fe80::1%lo0 in DNS, either. 127.x.y.z
doesn't have those problems.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 17 Feb 2015 19:39:45 +0900

On Tue, Feb 17, 2015 at 1:29 PM, Mark Andrews <[email-masked]> wrote:

> And you still need to have a strategy to deal with collisions.

bind() and EADDRINUSE?

> You also need to be able to communicate the resulting address to all

127.0.0.0/8 has that problem too, but people seem to find it useful.

> picking a random block in fd00::/8.

But while a ULA block only works on the machine where it's configured,
127.0.0.0/8 is present on every machine.

> In both cases you have to deal with collisions.
>

With a decent random number generator, the probability of a collision is
infinitesimally low unless you start generating millions of them.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 17 Feb 2015 12:43:28 +0000

From: Lorenzo Colitti <[email-masked]<mailto:[email-masked]>>
Date: mardi 17 février 2015 02:09
The value of the loopback prefix is not that it's routed to loopback. It's that *everybody knows* it's always routed to loopback.

Indeed. Clarity always wins, this is why I tend to like this I-D (albeit it should be rewritten).

BTW, the choice of ::/64 is probably not the best choice as it includes the deprecated ::/96 for IPv4-compatible IPv6 address.

-éric

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 17 Feb 2015 12:48:49 +0000

From: Falcon Darkstar Momot <[email-masked]<mailto:[email-masked]>>
Date: mardi 17 février 2015 03:33

How about discard, 0100::/64 as per RFC6666?  This seems rather more explicit than using loopback as discard.

EV> then what about nodes having routes for 100::/64 to /dev/null? Such as peering routers? :-)

-éric

---

From: Edward Lewis <[email-masked]>
Date: Tue, 17 Feb 2015 14:33:29 +0000

On 2/16/15, 21:33, "Falcon Darkstar Momot" <[email-masked]> wrote:

>> <[email-masked]> wrote:
>> Pointing network  at addresses inside 127.0.0.0/8 <http://127.0.0.0/8>  is a
>> very reliable way to cause said applications to fail fast without emitting
>> any packets. We don't have a way to do that in IPv6 except pointing them at
>> ::1.

I’ve carved up this thread a bit because it contains a case of protocol
engineering vs. protocol operations conflict.

Yes, architecturally, I find the use of encoding messages in addresses
rather appalling.  What I called “overt covert” channels are cute tricks
that are just that, tricks.  The more of these one tries to support in an
architecture, the more difficult it is to fully exercise innovation in the
architecture.  (My background is tied to DNS, and this is pretty evident
there.)

OTOH, operationally, the Internet Protocol stack is a challenge to manage.
The basic definition of Internet Protocols haven’t left a lot of hooks for
management and operations, having been born in the days before there was a
lot of experience upon which to draw lessons and thus requirements.  (Again,
very evident in DNS.)  Operators have over time had to work with what they
have, some of their choices present challenges to architectural models.

I’d be out of my depth to rationalize why DNSBL’s do what they do.  I can
imagine a few reasons (or excuses depending on one’s perspective) and I am
tempted to add some conjecture.  But that would be wrong on the list.

For controlled interruption, the uphill battle was passively coercing the
installed base to be caught in the trap (as systems errantly sending
unintended queries).  The way to do this is to tap into the address record
lookups.  The backchannel is the operations use of logs - where the
‘connection to 127.0.53.53 failed’ would appear.  Controlled interruption
includes other record types, including a TXT record which has a short
message.

The goal is two fold.  One is to get a message back.  Two is to have the
node not leak anymore than it already has.  (IMHO, the idea of wanting a
loopback is a bit overreaching, the goal is not to have the node
successfully send anything within itself.)

Way back (1998+/-) when DNSSEC was being developed, I wanted to ‘get a
message back’ and thought I’d be able to depend on SNMP - a nice
architectural thing to, but that wasn’t achievable.  (There’s no real good
back channel for DNSSEC detection of failures - it’s still actively
discussed on mailing lists.)  That’s just an example of the challenge of
getting ‘a message back.’  (The analogy here is a bit weak, DNSSEC wanted to
reach the administrator of the node with the failure, for controlled
interruption and DNSBL’s have different relationships.)

The suggestion to use the discard block is an interesting one, but it
doesn’t quite attain the goal of preventing leakage.  The goal is to have
the node not even generate the datagram, as opposed to having a recipient
know to discard it.  It’s not a bad suggestion, but the mere fact the action
is taken at the recipient means there’s that much leakage.  (Of course, I
don’t know what existing implementations would do with the address block
I’ll propose to mean ‘don’t even make this datagram’.)

---

From: Edward Lewis <[email-masked]>
Date: Tue, 17 Feb 2015 14:55:41 +0000

On 2/17/15, 7:43, "Eric Vyncke (evyncke)" <[email-masked]> wrote:

>BTW, the choice of ::/64 is probably not the best choice as it includes
>the deprecated ::/96 for IPv4-compatible IPv6 address.

I agree on both counts (needs rewriting and a different block is needed).

What I’m thinking of writing is a draft to set aside 7F::/64 (because 0x7F
is 127 in decimal) and set:

Source - - - - - - - - False
Destination  - - - - - False
Forwardable  - - - - - False
Global - - - - - - - - False
Reserved-by-Protocol - True

These are the same values as for 127.0.0.0/8 in RFC 6890.

The question remains for me, whether the Protocol should make this a
loopback or refuse to create the datagram.  By “make this a loopback” I
mean specify that one of the addresses should by default be ‘ifconfiged’
to the loopback interface and the -prefixlen 64 route be added too.

---

From: David Farmer <[email-masked]>
Date: Tue, 17 Feb 2015 09:06:08 -0600

> On Feb 16, 2015, at 17:04, David Conrad <[email-masked]> wrote:
> 
> Mark,
> 

No, but nothing says I have to use any of those RBLs either, their use is completely voluntary, I locally choose to use those semantics or not.  As long as I don't query those RBLs I can ignore those semantics.  And, there at least is an informational RFC discussing this use too, RFC5782. 

However, the very name given to the technique "controlled interruption", makes it quite clear there is nothing voluntary about it.  ICANN is applying this semantics to me and everyone else.  Now I'll admit, if I'm getting this I chose to locally use a unassigned TLD.  While I personally think that is an extremely bad idea, nothing explicitly said it was invalid either.   Personally I think the old saying, "two wrongs don't make a right", applies to this one.  But that's mostly spilt milk, maybe slightly sour spilt milk, but spilt none the less. :)

On the other hand, the way this address talked about on ICANN's website "Special IP Address (127.0.53.53)" at the very least sure sounds a lot like it belongs in the registry discussed above, even if it probably doesn't.  Maybe a disclaimer saying that is just a loopback address like any other in 127.0.0.0/8 and that it may have other legitimate local uses too, would be in order.   

> Is there some reason I'm unaware of why IPv6 does not have a loopback prefix that allows a network of more than one host like IPv4?

Yea, there is a reason, we couldn't develop consensus for it.  And, from what I've heard on this thread so far, I don't think that has really changed.  However, I personally support working on this, for the little that's probably worth.

As a tactical response, any reason you couldn't use the IPv6 address ::FFFF:7900:3535 (::FFFF:127.0.53.53) or generate a ULA prefix for IPv6 "controlled interruption"?  You've already spilt the milk anyway. :)

-- 
===============================================
David Farmer                          Email: [email-masked]
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
===============================================

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 17 Feb 2015 16:43:55 +0000

On Feb 16, 2015, at 8:09 PM, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:

+1.

By the way, another use case for a loopback block is in http://tools.ietf.org/html/rfc7439#section-3.4.2

Thanks,

— Carlos.

---

From: Andrew 👽 Yourtchenko <[email-masked]>
Date: Tue, 17 Feb 2015 17:51:52 +0100

> all packets to destinations in this prefix is /technically/ new

Would borrowing a /64 out of fe80::/10 work ?

fe80:dead:dead:dead::/64 ?

Given the special status of fe80::/10 at least there is a high chance
that the packets would not randomly leak into the wire from the
"legacy" hosts. And most of the unmodified stacks will even reject
attempts to assign an address from such prefix, which will take care
of potential overlap.

--a

---

From: joel jaeggli <[email-masked]>
Date: Tue, 17 Feb 2015 09:24:52 -0800

I'm not going to comment on the merits of this spefic proposal at this
time. one thing catches my however which is that mappings between v4 and
v6 addresses used for the same  purpose make very a little sense 7f::
doesn't have a meaning becasue of some magical congruence with 127
decimal and makes no particular sense in the absence of v4.

although this draft contends with a particular aspect of mapping between
v4 and v6 and is sadly expired I think it's instructive as to intuiting
meaning from equivalence:

https://tools.ietf.org/html/draft-itojun-v6ops-v4mapped-harmful-02

Beyond that  in general we should leave the actual assignment of special
use-prefixes to iana as stewards, we request that they be allocated.
they assign them.

---

From: Falcon Darkstar Momot <[email-masked]>
Date: Tue, 17 Feb 2015 17:33:11 -0700

On 17/02/2015 07:33, Edward Lewis wrote:
> On 2/16/15, 21:33, "Falcon Darkstar Momot" <[email-masked]
>>         The point is that they're addresses, not tags.  Why would you
allocate addresses that have absolutely no purpose in relation to routing?
>>
>>
>>     Pointing network  at addresses inside 127.0.0.0/8
<http://127.0.0.0/8> is a very reliable way to cause said applications
to fail fast without emitting any packets. We don't have a way to do
that in IPv6 except pointing them at ::1.
>     How about discard, 0100::/64 as per RFC6666?  This seems rather
more explicit than using loopback as discard.
>
>
> I’ve carved up this thread a bit because it contains a case of
protocol engineering vs. protocol operations conflict.
rather appalling.  What I called “overt covert” channels are cute tricks
that are just that, tricks.  The more of these one tries to support in
an architecture, the more difficult it is to fully exercise innovation
in the architecture.  (My background is tied to DNS, and this is pretty
evident there.)
>
> OTOH, operationally, the Internet Protocol stack is a challenge to
manage.  The basic definition of Internet Protocols haven’t left a lot
of hooks for management and operations, having been born in the days
before there was a lot of experience upon which to draw lessons and thus
requirements.  (Again, very evident in DNS.)  Operators have over time
had to work with what they have, some of their choices present
challenges to architectural models.
>
> I’d be out of my depth to rationalize why DNSBL’s do what they do.  I
can imagine a few reasons (or excuses depending on one’s perspective)
and I am tempted to add some conjecture.  But that would be wrong on the
list.
>
> For controlled interruption, the uphill battle was passively coercing
the installed base to be caught in the trap (as systems errantly sending
unintended queries).  The way to do this is to tap into the address
record lookups.  The backchannel is the operations use of logs - where
the ‘connection to 127.0.53.53 failed’ would appear.  Controlled
interruption includes other record types, including a TXT record which
has a short message.
>
> The goal is two fold.  One is to get a message back.  Two is to have
the node not leak anymore than it already has.  (IMHO, the idea of
wanting a loopback is a bit overreaching, the goal is not to have the
node successfully send anything within itself.)
message back’ and thought I’d be able to depend on SNMP - a nice
architectural thing to, but that wasn’t achievable.  (There’s no real
good back channel for DNSSEC detection of failures - it’s still actively
discussed on mailing lists.)  That’s just an example of the challenge of
getting ‘a message back.’  (The analogy here is a bit weak, DNSSEC
wanted to reach the administrator of the node with the failure, for
controlled interruption and DNSBL’s have different relationships.)
> The suggestion to use the discard block is an interesting one, but it
doesn’t quite attain the goal of preventing leakage.  The goal is to
have the node not even generate the datagram, as opposed to having a
recipient know to discard it.  It’s not a bad suggestion, but the mere
fact the action is taken at the recipient means there’s that much
leakage.  (Of course, I don’t know what existing implementations would
do with the address block I’ll propose to mean ‘don’t even make this
datagram’.)

While it is possible to envision a DNSBL being queried for relay
addresses to use internally to a host as part of mail routing, what I
understand is that the DNSBL is not necessarily dispositive (in
spamassassin it certainly isn't), and so the MTA or its spam filter
makes the query but processes the returned A record as a tag in nearly
every case.  Certainly, using a DNSBL to get a next hop is operationally
disadvantageous if the DNSBL is not working correctly, and could even be
used to man-in-the-middle mails.

So, while someone might be using DNSBL queries to route mail, it doesn't
seem like either the normal or correct thing to do.  It would be
interesting to hear from a DNSBL operator on this topic, if for no other
reason than to ask why they do as they do with 127.0.0.0/8 addresses.

This quandary is not illuminated in RFC5782, the DNSBL RFC.  However, we
do there specify (perhaps inelegantly) in section 2.4 that DNSBLs are to
return A records for queries against IPv6 addresses just as they would
for IPv4.  The TXT record is used only for a comment (perhaps this is
why it is not used as a tag).  Why a new RRtype is not requested I could
not say.

On a different topic, I may have misspoke when recommending ipv6 discard
for this purpose - since it is intended for RTBH, it doesn't prevent
leakage at all (quite the opposite).  Nor does link-local, since the
traffic may be leaked across a link.  The documentation prefix would,
but it is not appropriate to apply non-documentation semantics to
documentation addresses.

Loopback does not prevent leakage.  A local listener could still receive
the traffic, and that local process may be running with whatever
credentials.  It is as weak for this purpose as link-local.

::/128 would definitely prevent leakage.  This is only one address, and
it does have the meaning "unspecified" if memory serves, which seems
exactly what one might want if they would rather the packet not even be
generated.

If someone needs a set of addresses, we'd need to assign a prefix
(perhaps 100:1::/64?) for that, since nothing else fills that role, but
it's difficult to find a use case that isn't architecturally abhorrent. 
Then again, if that is what it takes to prevent people from using other
things (such as loopback) for this purpose, that's exactly what we
should do.

---

From: Mark ZZZ Smith <[email-masked]>
Date: Wed, 18 Feb 2015 00:46:22 +0000 (UTC)

----- Original Message -----
From: Mark Andrews <[email-masked]>
To: Mark ZZZ Smith <[email-masked]>
Cc: David Conrad <[email-masked]>; "[email-masked]" <[email-masked]>
Sent: Tuesday, 17 February 2015, 14:20
Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback-prefix-00.txt

/ 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.

/ 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.

*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. 

/ 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.

/ 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

---

From: Mark ZZZ Smith <[email-masked]>
Date: Wed, 18 Feb 2015 01:04:10 +0000 (UTC)

Which I also referenced in my draft on this topic. I also suggested slightly changed forwarding rules for my proposed larger and different loopback prefix that would support using native IPv6 addresses for this MPLS purpose rather than an IPv4-mapped IPv6 address.

"5.2.  Router Rules

IPv4 loopback packet processing rules for routers, specified in
[RFC1812], by default prohibited forwarding of packets with 127/8
destinations, other than those originated locally and returned back
to the router itself.  A software switch could be provided to disable
this prohibition.  This special case of allowing forwarding of
packets towards 127/8 destinations has been taken advantage of by
[RFC4379], for MPLS troubleshooting purposes.  An equivalent function
for IPv6 is provided by using the IPv4-Mapped IPv6 prefix of ::ffff:

Smith                    Expires August 24, 2013                [Page 7]

Internet-Draft        A Larger IPv6 Loopback Prefix        February 2013

127.0.0.0/104.

The existing ::1/128 packet processing rules for routers are the same
as those for IPv6 hosts [RFC4291].

For the new larger loopback prefix, the IPv6 router processing rules
are changed to match those of IPv4, to suit future uses similar to
the MPLS troubleshooting case."

________________________________
From: Carlos Pignataro (cpignata) <[email-masked]>
To: Lorenzo Colitti <[email-masked]> 
Cc: "[email-masked]" <[email-masked]> 
Sent: Wednesday, 18 February 2015, 3:43
Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback-prefix-00.txt

+1.

Thanks,

— Carlos.

---

From: David Conrad <[email-masked]>
Date: Tue, 17 Feb 2015 17:43:05 -0800

Mark,

> 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.

No it doesn't.  In fact, the whole reason 127/8 was chosen was precisely because it was guaranteed to be "host local" scope, in an effort to ensure (as much as anything on the Internet can be ensured, which unfortunately isn't 100%) that traffic destined to the answer returned by an "A" query for a newly delegated top-level domain wouldn't leak and thus constitute "controlled exfiltration" (to use Verisign's terminology).

Unfortunately, as IPv6 does not appear to have a direct analog to IPv4's loopback prefix, we simply punted figuring the number of v6 only sites that would be querying new gTLDs to be minimal (at least for the current crop of new gTLDs).

> Quite frankly, I'm starting to think you haven't read the draft.

Well, it did expire 18 months ago. Perhaps a refresh is warranted?  I, for one, would support moving it forward (albeit I'm not entirely sure a /32 is warranted: I'd think a /64 would be sufficient for "host local" scope).  And don't worry, I'd be supporting it for loopback functionality, not for the "flag" function we used 127.0.53.53 for (I've been convinced there are better ways to do that in IPv6) :).

Regards,
-drc

---

From: Mark ZZZ Smith <[email-masked]>
Date: Wed, 18 Feb 2015 03:11:28 +0000 (UTC)

----- Original Message -----
From: David Conrad <[email-masked]>
To: Mark ZZZ Smith <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: Tuesday, 17 February 2015, 13:19
Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback-prefix-00.txt

Mark,

/ So the trouble I have with what Spamhaus and ICANN are doing/have done with 127/8 is to place semantic meaning on certain 127/8 values that they expect other parties to accept. Because 127/8 is local to a host, or has host local scope, the domain of semantic meaning for addresses within it are limited to each individual host. Different hosts should be able to have different semantic meaning, or no semantic meaning at all for their own local 127/8 address space.

This means that Spamhaus and ICANN have now prevented other parties from placing their own semantic meaning on those values. If I started using 127.0.53.53 on a host, and it was exposed to somebody else, they might think it is somehow being used in relation to the ICANN DNS function. If at any time I'm told I can't use that address on my host, "because it is *the* DNS name collision address" (as a Google search apparently shows) it really means that one of the addresses within 127/8 doesn't belong to my host any more. I'm being forced to accept a semantic value defined by somebody else for an address that is actually mine to define on my host (and define differently or not at all on each my hosts.)

I have suffered from this sort of problem with RFC1918 addresses. At one of the ISPs I worked at we were getting wholesale ADSL services being delivered via L2TP from the very large incumbent carrier. They had chosen to give their L2TP Access Concentrators IP addresses from a variety of /24s from within 172.16/12. To be able to use those LACs inside your network successfully you couldn't be using that address space yourself, or you had to renumber out of it. Yet this is *private* address space, private to each network, so each network should be able to use it for their own purposes. That incumbent carrier had in effect made that private space 'public' to their customers, and were taking away their customers ability to use that space for their own private purposes.

We were highly amused when we received an email from them to all to all of their ISP customers saying "is anybody using 172.xyz/24" prefix?

Another example is that Microsoft chose to use locally assigned IEEE MAC addresses for their server load balancing addresses, rather than getting their own IEEE OUI - clearly they could have afforded the cost, although they might have already had one. They've in effect taken away the right of other people to use those addresses for what ever they want - which is their right because they're supposed to be 'locally assigned'.

The moral of the story is to keep private values and meanings private and local values and meanings  local.

The only alternative way to give back people's ability to place local semantic meaning on local addresses/identifiers is to add some context information, expressing how defined that semantic meaning. For example, if there was a way to present the Spamhaus and ICANN defined 127/8 addresses in DNS as "127.0.0.1@Spamhous" or "127.0.53.53@ICANN" or similar, then the ambiguity would be gone, and the whole of the host-local 127/8 address space would be available to the host. Of course, that isn't possible with A or AAAA records, which is why it is not an option.

Regards,
Mark.

Regards,
-drc

---

From: Mark ZZZ Smith <[email-masked]>
Date: Wed, 18 Feb 2015 03:16:14 +0000 (UTC)

Hmm, regarding the comment about not reading the draft, apologies for that, I thought I was responding to somebody else who I thought should have read the draft before because of their previous objections.

In my latest email to you I've explained why I think designating semantic meaning on local values and then expecting other external parties to respect those in effect now non-local values causes problems.

----- Original Message -----
From: David Conrad <[email-masked]>
To: Mark ZZZ Smith <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: Wednesday, 18 February 2015, 12:43
Subject: Re: [v6ops] New Version Notification for draft-ipversion6-loopback-prefix-00.txt

Mark,

Regards,
-drc

---

From: t.petch <[email-masked]>
Date: Wed, 18 Feb 2015 10:27:00 +0000

----- Original Message -----
From: "Mark Andrews" <[email-masked]>
To: "Mark ZZZ Smith" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, February 17, 2015 1:23 AM

Mark

I would refer you to RFC5782 and RFC6471 for a discussion on the use of
127.0.0.2 (and ::FFFF:7F00:2 ).

Perhaps those RFC should have included an IANA Considerations:-(

Tom Petch

> In message
<[email-masked]>, Mar
> > nterface, way back in 1982/1983:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=2.9BSD/usr/net/sys/net/if_l
oop.c
http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.1cBSD/a/sys/netinet/if_lo
op.c
> > Cc: Mark ZZZ Smith <[email-masked]>; "[email-masked]"
<v6ops@ietf.
> > Subject: Re: [v6ops] New Version Notification for
draft-ipversion6-loopback-p

---

From: Mark Andrews <[email-masked]>
Date: Wed, 18 Feb 2015 22:10:24 +1100

> 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

---

From: t.petch <[email-masked]>
Date: Thu, 19 Feb 2015 10:15:41 +0000

--- Original Message -----
From: "Mark Andrews" <[email-masked]>
Sent: Wednesday, February 18, 2015 11:10 AM

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

---

From: Mark ZZZ Smith <[email-masked]>
Date: Fri, 20 Feb 2015 02:30:34 +0000 (UTC)

<snip>

Mark

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.

/ So it seems now that 127.0.0.1 on loopback interfaces, since 1982, is now incorrect because it is 'separate usage' and needs to be changed.

/ The IETF has explicitly said those RFCs are Informational. If the IETF then chooses to treat those documents implicitly as standards (by accepting that low 127.0.0.n addresses are only for the purpose of DNSBLs), then there is no value in any of the other more rigorous IETF standards processes. Everything should be published as Informational instead, and there is no need for working groups etc. ...

/ If some people don't understand or aren't aware of what the categories of RFCs are, that doesn't mean those category labels are useless - they're just useless to people who don't understand them. To some extent it is the IETF's problem, as there should be more education about the IETF process/statues etc. However, the IETF abandoning or ignoring those labels on RFCs doesn't solve the problem for which they exist, it makes the problem worse. 

  (For some reason, the choice of percent for
interface identifiers, when percent was already spoken for in URIs,
comes to mind).

Tom Petch