multistack migration issues

[Pedro Marques]

>>>>> "John" == John Kennedy <warlock@csuchico.edu> writes:

    John> 07/11/97 @ 01:09:53 PM (Friday) Does anyone have a good feel
    John> for all of the issues involved in supporting applications
    John> across multistack (IPv4 & IPv6) platforms?

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

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

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

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

That is exactly what you should do.

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

A reverse lookup for ::ffff:132.241.66.6 can only be a query for
6.66.241.132.in-addr.arpa.

    John>   Is that what everyone is expected to do?

Use getnameinfo(). At least NRL's version does correctly recognize mapped
addresses and makes the PTR query to the in-addr.arpa name space.

  Pedro.