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

[Edward Lewis <[e-mail]>]

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

> On 16/02/2015 19:30, Lorenzo Colitti wrote:
>> On Tue, Feb 17, 2015 at 11:27 AM, Falcon Darkstar Momot
>> <[e-mail]> wrote:
>>> 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.

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