Subject: [Sip] URI comparison rules - IPv6 addresses

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 21 Nov 2007 11:17:01 +0200

Hi,

Brett brought this up in the SIP Implementors mailing list. The
following IPv6 addresses are supposed to be equivalent:

[::ffff:192.0.2.128] and [::ffff:c000:280]
[2001:db8::9:1] and [2001:db8::9:01]
[0:0:0:0:0:FFFF:129.144.52.38] and [::FFFF:129.144.52.38]

Now, let's say I need to compare sip:user1@[::ffff:192.0.2.128] and
sip:user1@[::ffff:c000:280]. Should we consider these URIs to be
equivalent or not?

My proposal is that we clarify that IPv6 address comparison happens at
the binary level, not at the textual level. We could log a bug against
RFC3261, and try and add such a clarification to the IPv6 transition
document (I will need to ask the ADs whether or not we can add this in
AUTH48).

Cheers,

Gonzalo

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Wed, 21 Nov 2007 11:11:59 +0100

Whatever the merits of this, please do not suggest using a SIPPING document to change the SIP protocol. We are getting too many of these odd updates spread around in too many documents. If this really is a bug in RFC 3261, then use the essential corrections process we are working on to change this.

Regards

Keith

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]] 
> Sent: Wednesday, November 21, 2007 9:17 AM
> To: sip
> Cc: Brett Tate
> Subject: [Sip] URI comparison rules - IPv6 addresses
> 
> Hi,
> 
> Brett brought this up in the SIP Implementors mailing list. 
> The following IPv6 addresses are supposed to be equivalent:
> 
> [::ffff:192.0.2.128] and [::ffff:c000:280] [2001:db8::9:1] 
> and [2001:db8::9:01] [0:0:0:0:0:FFFF:129.144.52.38] and 
> [::FFFF:129.144.52.38]
> 
> sip:user1@[::ffff:c000:280]. Should we consider these URIs to 
> be equivalent or not?
> 
> My proposal is that we clarify that IPv6 address comparison 
> happens at the binary level, not at the textual level. We 
> could log a bug against RFC3261, and try and add such a 
> clarification to the IPv6 transition document (I will need to 
> ask the ADs whether or not we can add this in AUTH48).
> 
> Cheers,
> 
> Gonzalo
> 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 21 Nov 2007 12:53:50 +0200

Hi,

it is not really a bug. It is a clarification.

Cheers,

Gonzalo

---

From: [email-masked]
Date: Wed, 21 Nov 2007 08:45:28 -0500

Hi, 
Yes, this seems like a very good clarification to make -- one of those 
"obvious" things that could easily get different interpretations or just 
lazy programming causing issues.  At minimum should be clarified for 
sipping-v6-transition.   If that could be done in RFC process, then it 
would obviously be better.  Likely a correction would also be warranted in 
base SIP; unsure.

And yes, those addresses are equivalent.  Saying it is done "at binary 
level" implies implementation, so I would not say that.  Some words like 
"expanded form" might be more appropriate.  But the comparison needs to 
account for all variations of notation on both IPv6 and IPv4 addresses 
(there are lots more than noted below of course). 

BTW, I notice this was not posted on SIPPING.  Even though most of us 
probably watch both, suggest it get put there also since it is the home of 
sipping-v6 ... perhaps aft this mini-debate settles. 

-- Peter

Gonzalo Camarillo <[email-masked]>
21.11.07 04:17
 
        To:     sip <[email-masked]>
        cc:     Brett Tate <[email-masked]>
        Subject:        [Sip] URI comparison rules - IPv6 addresses

Hi,

Cheers,

Gonzalo

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 21 Nov 2007 09:37:22 -0600

> document (I will need to ask the ADs whether or not we can add this in

Gonzalo: My only concern that I had mentioned to Brett as
well was that this should not be construed as endorsing the
notion of multiple representations of the IPv6 address in
SIP signaling.  This may cause problems in normal SIP operations.

Consider a proxy that uses the sent-by address in a loop detection
mechanism.  If it gets a looped request but the upstream proxy
had now put a different representation of the IP address, then
the proxy will not recognize that as a loop.  Admittedly, the
upstream proxy should not be inserting different representations
of the same IP address in each request (unless, of course it is
malicious; but then if it is malicious, it could probably do
damage by other means.)

Now, regarding where to put it: in v6-transition or in a SIP
essential fix, here are some thoughts.  Insofar as we are talking
about URI comparison, this clarification is probably best put
in S19.1.4 (URI Comparison) of rfc3261.  We already have a
SIP essential fix document that fixes the IPv6 ABNF in rfc3261
(http://tools.ietf.org/html/draft-gurbani-sip-ipv6-abnf-fix-00);
this clarification could be tacked on in that draft if the WG
agrees.  Thoughts?

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 21 Nov 2007 18:23:01 +0200

Hi Vijay,

if this document becomes a WG item, I agree it would be the perfect 
place to document this issue.

Cheers,

Gonzalo

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 21 Nov 2007 13:50:49 -0600

> place to document this issue.

OK; good.  draft-gurbani-sip-ipv6-abnf-fix has been reviewed
and okayed by at least one member of the SIP WG on the list.  Things
will be much clearer after the Vancouver IETF.  Then, if the chips
fall in place, Brett and I will ensure that the text for URI
comparison gets in.

Thanks,

- vijay