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

[Mark ZZZ Smith <[e-mail]>]

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

Mark,

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

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


>> 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.
> / 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
(ICANN CTO, but speaking only for myself)