[Collisions] "controlled interruption" - 127/8 versus RFC1918 space

Jeff Schmidt jschmidt at jasadvisors.com
Fri Jan 10 01:51:36 UTC 2014

Hia, Warren:

I just responded to this issue over at DI but in a nutshell we don't want
to "cause" traffic to leave the host/LAN/enterprise.  We don't know what
it will contain, and it might contain sensitive/protected data, which
makes this much more complicating.  Using 127/8 or 1918 space eliminates
that can o' worms and is the more conservative approach in this dimension
we believe.


On 1/9/14 5:20 PM, "Warren Kumari" <warren at kumari.net> wrote:

>On Thu, Jan 9, 2014 at 8:01 PM, Wayne MacLaurin <Wayne at demandmedia.com>
>> Hi folks.. I posted a longer reply on Domainincite but basically, if we
>>are going to accept that returning something other than NXDOMAIN is ok,
>>why don¹t we just make it useful  and avoid the Internet sleuthing for
>>the true meaning of
>> Get ICANN to host a nice informative website and point the IPs there..
>>If its not a human, its not going to work anyway.  If it is a human,
>>then we have ICANN¹s backing as to the how and why and what can be done
>>to fix the problem.
>Yup, that was part of the original proposal (and personally what I
>like the most) -- a web page that says:
>"Whoops, you probably didn't intend to get here -- hare are a bunch of
>resources to explain the issue."
>Same thing can be implemented for a whole heap-o-other protocols, like
>SMTP, Telnet/SSH, etc (I made a list somewhere).
>Apart from providing feedback to the user this also allows *much*
>better monitoring of the issue -- serving a A record gives you no real
>visibility into who is actually affected (just their NS) -- having the
>client connect gives you way more information about who and number.
>The big bugaboo here is what happens with the data -- but presumably
>ICANN could have a reasonable privacy policy...
>> Wayne
>> On Jan 9, 2014, at 4:25 PM, David Conrad <drc at virtualized.org> wrote:
>>> Joe,
>>> On Jan 9, 2014, at 1:20 PM, Joe Abley <jabley at hopcount.ca> wrote:
>>>>> To an engineer, is unusual enough to alert them as well
>>>>>as not send them chasing down non-problems.
>>>> A correct host implementation will not send datagrams to the network
>>>>with a source or destination address within 127/8 [RFC1700] or ::1/128
>>>>[RFC 4291].
>>> Yep.
>>>> However, it's not obvious what implementations do in real life.
>>>>RFC3330 comments that the IPv4 loopback address is "ordinarily
>>>>implemented using only", for example.
>>> I'm told Linux implements loopback as 127/8, but don't have one handy
>>>to test myself.
>>> MacOSX appears to time out going to anything in 127/8 other than
>>> FreeBSD 8.2 and 9.1 says "sendto: can't assign requested address"
>>>> The goal of the work that triggered this thread is to keep traffic
>>>>triggered by the disappearance of NXDOMAIN responses for QNAMEs
>>>>subordinate (or identical) to new gTLDs local, ideally on the same
>>>>host that originated them, to avoid mysterious service failures or
>>>>information leakage.
>>> Err, not really. The goal is to interrupt service so people will
>>>notice and fix it, along the lines of registrations being dropped.
>>>Keeping traffic local and avoiding information leakage are side
>>>benefits. The choice of was just to maybe provide an
>>>additional bit of information to folks who look at the log files on the
>>>machines that all of a sudden stopped working the way they used to
>>>(assumes the address connections are being attempted to are logged) and
>>>reduce the risk that there is actually a listener for a future
>>>connection attempt at
>>>> So, the specification suggests that for IPv6 there's only one address
>>>>to play with, ::1/128.
>>> Yep.
>>>> What studies exist to confirm that (say) won't attract
>>>>network traffic from a host?
>>> Sorry, don't understand the question -- unsure what 'attract network
>>>traffic' means. Do you mean whether anyone has looked to see if hosts
>>>will accept traffic off the wire at (say)
>>>> What is the expected analogue to for IPv6,
>>> Doesn't explicitly exist (of course). As mentioned, the intent is to
>>>hopefully provide a bit of help to folks who are unaware of the
>>>situation and who are trying to track down the problem. Personally I'd
>>>think for the purposes of this effort, we could squat on ::53 given the
>>>small likelihood that 0::0/122 will be allocated in the foreseeable
>>>future, but I can see that this position might be ... controversial
>>>> and what studies exist for how that traffic might be treated by a
>>>>variety of hosts?
>>> Just to clarify, the assumption is a scenario like:
>>> - Application (probably through a resolver) sends an A query to newly
>>>delegated "mumble.abley".
>>> - Name server for mumble.abley returns
>>> - Application attempts to open a connection to
>>> - Connection attempt fails, logging "connection attempt to
>>>'mumble.abley' ( didn't return NXDOMAIN: launch the
>>> - In the radioactive wasteland that remains, archeologists uncover the
>>>machine and look at the log file, notice and say "Eureka!
>>>That's what happened! Damn you DNS search path!"
>>> Now, with that assumption, what traffic are you talking about?  The
>>>connection attempt by the application to
>>>> [I like the out-of-boxness of the thinking that triggered all of
>>>>this, but I don't see it going anywhere. Quite aside from the
>>>>legal-economic difficulties in rebuilding the new gTLD aircraft in
>>>>flight alluded to earlier,
>>> Err, what legal-economic difficulties?
>>>> I think the ideas here involve unproved assumptions (e.g. wrt
>>>>, are IPv4-centric and are likely to lead to more
>>>>headaches than they solve.]
>>> Could you be explicit in the headaches you see?
>>> Thanks,
>>> -drc
>>> _______________________________________________
>>> Collisions mailing list
>>> Collisions at lists.dns-oarc.net
>>> https://lists.dns-oarc.net/mailman/listinfo/collisions
>> Please NOTE: This electronic message, including any attachments, may
>>include privileged, confidential and/or inside information owned by
>>Demand Media, Inc. Any distribution or use of this communication by
>>anyone other than the intended recipient(s) is strictly prohibited and
>>may be unlawful.  If you are not the intended recipient, please notify
>>the sender by replying to this message and then delete it from your
>>system. Thank you.
>> _______________________________________________
>> Collisions mailing list
>> Collisions at lists.dns-oarc.net
>> https://lists.dns-oarc.net/mailman/listinfo/collisions
>Collisions mailing list
>Collisions at lists.dns-oarc.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4376 bytes
Desc: not available
URL: <http://lists.dns-oarc.net/pipermail/collisions/attachments/20140110/c5c01bb7/attachment.bin>

More information about the Collisions mailing list