multistack migration issues

John Kennedy warlock@csuchico.edu
Fri, 11 Jul 1997 13:10:26 -0700


07/11/97 @ 01:09:53 PM (Friday)

  Does anyone have a good feel for all of the issues involved in supporting
applications across multistack (IPv4 & IPv6) platforms?

  For example, I've been hacking IPv6 support into 8.8.7.Beta2.  Along with
all the usual AF_INET -> AF_INET6 porting I ran into everyday situations like
DNS lookups.  For example, lets look at the typical "Received:" line:

	Received: from menkure.net.CSUChico.EDU
		(menkure.net.CSUChico.EDU [::ffff:132.241.66.6])
		by hircine.net.chico.ca.us (8.8.7.Beta2+ipv6/8.8.7.Beta2)
		with ESMTP id MAA25407 for <warlock@hircine.net.chico.ca.us>;
		Fri, 11 Jul 1997 12:04:25 -0700

  The first "menkure" is given to me in the EHLO.  The ::ffff:132.241.66.6
I get from the socket, but the 2nd menkure I actually create while trying
to verify if someone is forging or otherwise giving bad information.

  If this was just straight IPv4 or IPv6 you'd take the address, do a
reverse-lookup, forward-lookup the result and make sure the address you
started with matches one (of potentially many) from the forward-lookup.

  In this mixed environment, I was stuck.  I didn't have a reverse-lookup
for ::ffff:132.241.66.6 and, while I could bloat up DNS with all of my
local addresses, that doesn't do anything for the rest of the world.  In
my port, I decided to try it and, if it failed and the non-IPv4 portion
of ::ffff:132.241.66.6 was ::ffff:0, I'd try a regular IPv4 reverse-lookup
on the hostname.

  Is that what everyone is expected to do?


  I guess I'm just afraid that ::ffff:0/96 will become "non-unique".  IE,
when the final crunch comes someone is going to grab some networks and
there is going to be X's ::ffff:1.2.3.4 as well as Y's ::ffff:1.2.3.4
network out there, pretty much breaking IPv4/DNS as we know it.

  [By IPv4-DNS I mean DNS RRs made for the 32-bit world.]

  Give then ::ffff:0 is supposed to be a special address I don't think
that will happen but designer mentality changes more rapidly than
printed dead-tree (books).  (:  Most of what I read makes it sound as
if IPv6-ignorant ::ffff:0 hosts will be proxy-bait.

  If they are proxy-bait, IPv4-DNS should continue to linger for as long
as it's useful in its current capacity (no dupes).
								--- john