RE: Re: URI comparison rules - IPv6 addresses

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" <vkgalcatel-lucent.com>
Aan: "Gonzalo Camarillo" <Gonzalo.Camarilloericsson.com>
CC: "sip" <sipietf.org>; "Brett
Tate" <brettbroadsoft.com>
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://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

Jeroen van Bemmel wrote:
> Vijay,
> 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.al
catel-lucent.com/bell-labs


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

Vijay K. Gurbani wrote:
> Jeroen van Bemmel wrote:
>> Vijay,
>> 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.

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


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

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

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:usersip.example.com !=
sip:userexample.com.

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

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

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:userexample.com != sip:user192.0.2.128
even though DNS_lookup("example.com") =
"192.0.2.128".

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.al
catel-lucent.com/bell-labs


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

Vijay K. Gurbani wrote:
> Michael Thomas wrote:
>> 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".
>
> 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:usersip.example.com !=
sip:userexample.com.
>
> I suppose the rules for SIP URI comparisons are a bit
more stringent
> 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...
>> 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?
>
> 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:userexample.com != sip:user192.0.2.128
> 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:userexample.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.

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


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

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

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.al
catel-lucent.com/bell-labs


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

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:userexample.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://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

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
-- 
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.al
catel-lucent.com/bell-labs


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

   From: "Vijay K. Gurbani" <vkgalcatel-lucent.com>

   Jeroen van Bemmel wrote:
   > Vijay,
   > 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.

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


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip