Re: [Sip] Re: URI comparison rules - IPv6 addresses

Michael Thomas <mat@cisco.com> Wed, 21 November 2007 22:43 UTC

Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuyIY-0007SG-LZ; Wed, 21 Nov 2007 17:43:58 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IuyIX-0007Rx-2y for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 17:43:57 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuyIW-0007Ro-OS for sip@ietf.org; Wed, 21 Nov 2007 17:43:56 -0500
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuyIW-0005ZA-7Y for sip@ietf.org; Wed, 21 Nov 2007 17:43:56 -0500
Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-3.cisco.com with ESMTP; 21 Nov 2007 14:43:55 -0800
Received: from crabapple.local ([10.21.67.122]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id lALLGsMx018649; Wed, 21 Nov 2007 13:16:54 -0800
Message-ID: <4744B4AB.1040403@cisco.com>
Date: Wed, 21 Nov 2007 14:43:55 -0800
From: Michael Thomas <mat@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.666
MIME-Version: 1.0
To: "Vijay K. Gurbani" <vkg@alcatel-lucent.com>
Subject: Re: [Sip] Re: URI comparison rules - IPv6 addresses
References: <0JRV00ABOC070460@jes-fe1.zx.nl> <47448C1B.7000603@alcatel-lucent.com> <4744A284.9040009@cisco.com> <4744A651.9010306@alcatel-lucent.com> <4744A9E7.40306@cisco.com> <4744B18F.5080609@alcatel-lucent.com>
In-Reply-To: <4744B18F.5080609@alcatel-lucent.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1438; t=1195679815; x=1196543815; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mat@cisco.com; z=From:=20Michael=20Thomas=20<mat@cisco.com> |Subject:=20Re=3A=20[Sip]=20Re=3A=20URI=20comparison=20rules=20-=20IPv6=2 0addresses |Sender:=20 |To:=20=22Vijay=20K.=20Gurbani=22=20<vkg@alcatel-lucent.com>; bh=BlBlGrnDbGIro28FNanZER0EpkyMftpejpF1KAjStSk=; b=LqECLtfhd3GZ6klO/kcwnP/Zcw82osbiDuljxurIe+aoCCCyIDwTGtBSrMUr9dBDp2Tf2bqn RZxAfFvfsA4mAAUfZyhRXf1+MSRDDcABxG5DNoGWdTvqTwlqD4VhByJW;
Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Cc: sip <sip@ietf.org>, Brett Tate <brett@broadsoft.com>, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Vijay K. Gurbani wrote:
> Michael Thomas wrote:
>> Well, that's sort of my point: if you have something(s) writing URI's
>> for the same entity in different ways, it seems just as likely that they
>> might write them as sip:user@example.com and 192.0.2.128 as
>> they would by writing different representations of IPv6 addresses.
>> Here's another corner case: try multi-homed servers.
>
> Michael: Insofar as these URIs are used purely for routing purposes,
> I don't think it matters what the representation is.  But if they
> are used for identification purposes or for any other purpose (like
> including them in a hash for loop detection), then it matters what
> their representation is.

Sorry if I'm belaboring this Vijay. I definitely agree if that you're using
them as a locator, it doesn't matter. But for loop detection, wouldn't that
require that the same entity that wrote the via to write it in different 
ways
to foil the loop detector? It seems to me that either this is pathological
(ie, example.com and 192.0.2.128) or it's a non-problem because the
(same) entity shouldn't be writing it in different ways in the first place.


Put another way: If I want loop detection to work with things under my
control, I better make certain that the names are stringwise-identical, not
just route to the same identity. Which is not specific to IPv6, and thus
we shouldn't special case it.

       Mike


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip