ICANN ICANN Email List Archives

[comments-name-collision-26feb14]


<<< Chronological Index >>>    <<< Thread Index >>>

If the IPv4 answer is 127.0.53.53 then what is the IPv6 answer? - While trivial; the lack of IPv6 support is something to consider

  • To: comments-name-collision-26feb14@xxxxxxxxx
  • Subject: If the IPv4 answer is 127.0.53.53 then what is the IPv6 answer? - While trivial; the lack of IPv6 support is something to consider
  • From: "Martin J. Levy" <martin@xxxxxxxxxxxxxx>
  • Date: Fri, 28 Mar 2014 23:33:59 -0700

At first I was thinking that a simplistic response of “Hey... why is there no 
v6 in this recommendation” was easy to state and walk away from. After a day or 
two, I realized that this is actually a real issue.

1) The simplistic original thought was: Why is ICANN promoting a v4 only 
solution by defining 127.0.53.53 and yet not defining an equivalent v6 address? 
Isn’t ICANN a pro-v6 entity? (Yes it is).

2) The v4 choice of 127.0.53.53 is very hard to replicate within v6 as the 
loopback was defined as ::1/128 (RFC2373). There is no room within that subnet 
for an additional address.

3) If you accept 127.0.53.53 as the method going forward to solve this 
solution; then which registry function under IANA keeps track of the “53.53” 
usage (what if some future http protocol design wants to use 80.80? etc etc).

4) Given that there is going to be a non-trivial number of IPv6-only devices in 
the field and hence a v4-only response is equivalent to a NXDOMAIN response. If 
the endpoint implements 464XLAT (RFC6877) then the 127.0.53.53 response creates 
far more traffic than intended, potentially with a DDoS result.

As I said; these were trivial thoughts. Since that time (and after reading 
Aaron Beck & Jason Fesler’s comments about Linux routing and more; I’ve come to 
my own thoughts that this is an absolute hack of the worse kind. The v6 issues 
are in fact unimportant as this should not even exist within the v4 world.

Why do I think this? While I now believe I understand the name collision issues 
addressed by SSAC, I simply can’t get my hear around coding into numerous 
end-point software subsystems the “127.0.53.53” address. The precedence set by 
this is non-trivial and this act could potentially open up the 127.*.*.* block 
(and its lack of v6 equivalent block) to all manner of “solutions” to real or 
artificial problems. While I highly respect the team that thought this solution 
up; I also respectfully state that it’s just not passing the “smell test”. Alas 
I know I'm failing because I can’t bring to the table an alternate solution.

Please accept these comments as a true concerns and maybe use the lack-of-IPv6 
to rethink the solution.

Yours,

Martin


  Martin J. Levy
  Network Strategy
  CloudFlare, Inc.





<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy