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

Joe Abley jabley at hopcount.ca
Thu Jan 9 21:20:03 UTC 2014

On 2014-01-09, at 15:25, Chris Cowherd <chris at donuts.co> wrote:

> I think the benefits of concentrating on a single IP will reap fruit when they go searching the Internet for help. I do see your point on using but consider, there may actually be a machine there (its a stretch but could confuse engineers i.e. Why are you using a printer as an MTA?).
> 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.

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.

So, the specification suggests that for IPv6 there's only one address to play with, ::1/128.

The specification suggests that for IPv4 there's a /8 to play with, but at least one RFC concedes that it's possible for packets sent to destinations covered by 127/8 (but not to be sent to the network.

What studies exist to confirm that (say) won't attract network traffic from a host? What is the expected analogue to for IPv6, and what studies exist for how that traffic might be treated by a variety of hosts?

Agreed that using RFC1918 addresses as destinations is risk-prone (you'd think they ought to at least not leak from individual ASes, but observation suggests otherwise, hence AS112).

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

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

More information about the Collisions mailing list