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

From: Jeroen van Bemmel <[email-masked]>
Date: Wed, 21 Nov 2007 19:17:38 +0100

Vijay,
It's not only IPv6: what about 127.0.0.1 versus 127.000.000.1?

Regards,
Jeroen

-----Oorspronkelijk bericht -----
Van: "Vijay K. Gurbani" <[email-masked]>
Aan: "Gonzalo Camarillo" <[email-masked]>
CC: "sip" <[email-masked]>; "Brett Tate" <[email-masked]>
Verzonden: 21-11-07 16:37
Onderwerp: [Sip] Re: URI comparison rules - IPv6 addresses

Gonzalo Camarillo wrote:
> 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).

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

_______________________________________________
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: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 21 Nov 2007 13:50:51 -0600

> It's not only IPv6: what about 127.0.0.1 versus 127.000.000.1?

Jeroen: Pedantically speaking, you are probably right.  But
in practice we do not generally see leading zeros in an IPv4
octet.

IPv6, with its compressed notation and the need to represent
hybrid addresses (like IPv4-mapped IPv6 addresses) makes the
representation issue more acute.  For instance, the low-order
32 bits of an IPv4-mapped IPv6 address can be represented using
the familiar dotted-decimal notation, or they can be represented
using the IPv6 colon-separated notation.

But your point is well taken: if we put some text about the
binary equivalence of different textual representations of an
IPv6 address, I guess we should do so for IPv4 as well.

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: Michael Thomas <[email-masked]>
Date: Wed, 21 Nov 2007 13:26:28 -0800

> IPv6 address, I guess we should do so for IPv4 as well.

Doesn't this sort of slide down the slippery slope of understanding
the semantics of the URI for comparison? For example, why can't
you make the same kind of argument for www.example.com and
example.com since they're pretty much synonymous these days?
And for that matter what about comparing example.com and, oh
say, its A(AAA) record? They're the "same", FSVO "same".

Maybe I missed the first post, but is it realistic that something(s)
producing URI's for the same target would create their name in
different manners? And if it is, why wouldn't it be as much of a
problem with the IP address name and a real fqdn?

       Mike

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 21 Nov 2007 15:42:41 -0600

Michael Thomas wrote:
> the semantics of the URI for comparison? For example, why can't you
> make the same kind of argument for www.example.com and example.com
> since they're pretty much synonymous these days? And for that matter
> what about comparing example.com and, oh say, its A(AAA) record?
> They're the "same", FSVO "same".

Mike: Our domain is restricted to SIP URIs.  In other words,
while DNS-wise, www.example.com = example.com, this does not carry
into SIP; i.e., sip:[email-masked] != sip:[email-masked].

I suppose the rules for SIP URI comparisons are a bit more stringent
than DNS equivalence of names, aliases, and their resulting addresses.

> different manners?

No, not realistic, but entirely probable.

> And if it is, why wouldn't it be as much of a problem with the IP
> address name and a real fqdn?

Because, SIP URI wise, sip:[email-masked] != sip:[email-masked]
even though DNS_lookup("example.com") = "192.0.2.128".

Thanks,

- vijay

---

From: Michael Thomas <[email-masked]>
Date: Wed, 21 Nov 2007 13:57:59 -0800

> than DNS equivalence of names, aliases, and their resulting addresses.

This of course leads us into the mysterious rat hole of what constitutes
"same", but...
> even though DNS_lookup("example.com") = "192.0.2.128".

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:[email-masked] and 192.0.2.128 as
they would by writing different representations of IPv6 addresses.
Here's another corner case: try multi-homed servers.

Let me put it another way: if there is something dire that happens if
two different representations of the same identity can't be compared
as equal, then your problem runs much deeper than the special IPv6
case.

       Mike

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 21 Nov 2007 16:30:39 -0600

> 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.

Thanks,

- vijay

---

From: Michael Thomas <[email-masked]>
Date: Wed, 21 Nov 2007 14:43:55 -0800

> including them in a hash for loop detection), then it matters what

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

---

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

Michael Thomas wrote:
> 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.

Right, precisely what I wrote in an earlier email in this thread:

   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.)

> 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.

Agreed.

- vijay

---

From: [email-masked]
Date: Wed, 21 Nov 2007 18:43:01 -0500

From: "Vijay K. Gurbani" <[email-masked]>

Even worse, in some places, including some early RFCs, the leading
zero is used to indicate that the octet is represented in octal!

But I think Jeroen's point is actually well-taken, when comparing
representations of IP addresses (not DNS names), the comparison is
implicitly of the address represented, not the textual
representation.  And this applies in IPv4 as well as IPv6.

In regard to loop detection, there are two approaches:  (1) Whatever
attempts to detect loops can canonicalize the addresses before
comparing them or whatever.  (2) Since there are a limited number of
likely representations of any address, having different entities use
different representations will only delay loop detection, not prevent
it.  And loops will be detected even if address comparisons have
occasional false negatives.

Dale

---

From: Michael Thomas <[email-masked]>
Date: Wed, 21 Nov 2007 15:58:26 -0800

> occasional false negatives.
Given that a particular IP address might serve many, many different
URI's (think about the outsourced case), I doesn't seem to me that this
would be a very good assumption. It might be perfectly reasonable for
a method to traverse from IP address A and then back through IP address
A again without being a loop since it might be outsource1.com through
outsource2.com which is legal, right? This case certainly comes up with
email and is actually really common(*).

It seems that the conclusion of Vijay and my violent agreement is that
the entity inserting the URI better keep things consistent as the loop
detector ought to just consider these things as opaque blobs.

       Mike

(*) modulo DNSBL considerations.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 23 Nov 2007 11:33:29 -0500

[email-masked] wrote:
> comparing them or whatever. 

I agree with all the above.

> (2) Since there are a limited number of

While the number is *limited*, the limit is pretty large.

Consider an IPv4 address where each of the components requires only two 
digits. Then each can be represented two ways - with two digits or 
three. That means there are 16 different valid representations of the 
address. Of course it would be much worse for Ipv6 addresses.

Port numbers are worse. The syntax for the port number is 1*DIGIT. So a 
port number can be represented with *any* number of leading zeros.

Bottom line - I think you can't rely on exhausting all the permutations 
of hostport before detecting a loop.

	Thanks,
	Paul

---

From: [email-masked]
Date: Fri, 23 Nov 2007 12:18:19 -0500

From: Michael Thomas <[email-masked]>

But if sip:[email-masked] is turned into sip:[email-masked],
it hasn't looped yet.  It's only when the latter gets turned into
sip:[email-masked] again that there's a loop.  And in any case,
these are DNS names, not IP addresses, so they're not relevant to the
question at hand.

(Amusingly, "..." is a legitimate user-part in a SIP URI.)

Dale

---

From: [email-masked]
Date: Fri, 23 Nov 2007 12:21:03 -0500

From: Paul Kyzivat <[email-masked]>

True, but I expect in practice there will be no cases with more than 3
representations of the same address used by any one SIP agent unless
it's deliberately trying to defeat loop detection.  That case is
ameliorated by (1) a malicious agent would have to handle the message
"every time around the loop", which would place a high burden on it,
and (2) loops will eventually be detected by Max-Forwards in any case.

Dale