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

David Conrad drc at virtualized.org
Fri Jan 10 00:25:22 UTC 2014


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


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


> 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 missiles!"
- 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?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.dns-oarc.net/pipermail/collisions/attachments/20140109/ce2ee24d/attachment.pgp>

More information about the Collisions mailing list