Return-Path: <owner-ips@ece.cmu.edu>
X-Sieve: cmu-sieve 2.0
Return-Path: <owner-ips@ece.cmu.edu>
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id h1QNDx106779
	for ips-outgoing; Wed, 26 Feb 2003 18:13:59 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id h1QNDtW06767
	for <ips@ece.cmu.edu>; Wed, 26 Feb 2003 18:13:56 -0500 (EST)
Received: by lion.ninthwonder.com (Postfix, from userid 1021)
	id 1D78E30706; Wed, 26 Feb 2003 18:13:55 -0500 (EST)
Date: Wed, 26 Feb 2003 16:06:29 +0000 (UTC)
From: wrstuden@wasabisystems.com
X-X-Sender: wrstuden@neverwinter.home-net.icnt.net
To: ips@ece.cmu.edu
Subject: Multi-address DNS name and SendTargets
Message-ID: <Pine.NEB.4.53.0302241704220.1124@neverwinter.home-net.icnt.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

We recently noticed an oddity with SendTargets and hostnames with both
IPv4 and v6 addresses.

Our config syntax for portals has a transport (tcp/tcp6, will have
scpt/scpt6 some day), a host name, and all the portal parameters.

Recently we set up a target to listen on an interface with both IPv4 and
IPv6 sockets. Each socket/portal had different target portal group tags.
The two sockets were both on an interface that has a DNS name that has
both an A and an AAAA record. Since we know exactly what address family we
want, we typed the same hostname into the config file.

The SendTargets code just prints hostnames (unless the "hostname" is a
inet6 portal and looks like an IPv6 numeric address in which case we add
the bracketing brackets). :-)

The rub is that the output of SendTargets looked weird:

TargetName=iqn.XXXX
TargetAddress=hostname,5	# this is the IPv4 portal
TargetAddress=hostname,6	# this is the IPv6 portal


I don't really see anything wrong done by the target, but I can see an
initiator might get VERY confused.

I think the best resolution of this "issue" is to add a note to
administrators to not configure portals with DNS names that resolve to
both ipv4 and v6 records if the target listens on both address families
(well, tcp & tcp6) and the portals have different TPGTs. Wow, that's a
mouthfull.

I guess the other thing to do is make initiators/discovery agents aware of
the fact that you can have a host name duplicated in TargetAddress
responses for a given node, and that that would probably indicate that
multiple address families are in use at once.

Take care,

Bill
