Subject: [Sipping] IPv6 addresses in Via received parameter

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 10 Apr 2006 10:42:13 -0500

Folks: Before the Dallas IETF, I had sent an email to gauge
consensus on whether the "received" parameter should have the
delimiters '[' and ']' when its content is an IPv6 address.
That is:

   Via: SIP/2.0/TCP foo.example.com;received=[2001::db8];branch=...

versus:

   Via: SIP/2.0/TCP foo.example.com;received=2001::db8;branch=...

RFC 3261 ABNF indicates the latter; i.e., without the delimiters.
However, there is some precedence for encapsulating literal IPv6
addresses in square brackets when it is contained in a URL (see
RFC 2732).  Furthermore, having a '[' is much amenable to the
parser since one can know at the outset that the received parameter
contains an IPv6 address.  The SIP IPv6 torture test draft has
the received encapsulated in the square brackets (see
draft-sipping-gurbani-ipv6-sip-02).

Can folks who have IPv6 implementations kindly post what their
behavior is?  Also, does anyone know how reSIProcate treats this?
With the SIPit coming up, I would like to see if we can reach a
consensus on this.  It would be good to know how the implementations
are treating this.

The link to my original post is given below, followed by another
link to a followup post on why having the IPv6 encapsulated in
square brackets may be more consistent with expectations.

http://www1.ietf.org/mail-archive/web/sipping/current/msg10341.html
http://www1.ietf.org/mail-archive/web/sipping/current/msg10373.html

Thanks,

- vijay

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

---

From: Adam Roach <[email-masked]>
Date: Mon, 10 Apr 2006 17:54:18 -0500

Vijay K. Gurbani wrote:

> ...

Resip currently does *not* use the brackets for v6 addresses on the
received parameter.

In practice, the received parameter is interpreted *almost* exclusively
by the entity that wrote it -- so interoperability shouldn't be as
substantially harmed by differing interpretations than might it first
appear.

Those entities using the received parameter as a kind of poor-man's STUN
may run into issues, but this problem should become increasingly rare as
people use actual STUN instead.

I'm inclined to leave it as is -- the current syntax, although vaguely
nonintuitive, is unambiguous and does not require two-pass parsing to
get right. (If there were a colon-delimited port number, that would make
it more difficult; but the received parameter never contains a port
number). And, as I've mentioned above, any implementation that gets this
this wrong will generally still interoperate, since the information in
the received parameter is generally no-one's business but the proxy who
generated it.

/a

---

From: "Frank Shearar" <[email-masked]>
Date: Tue, 11 Apr 2006 10:42:13 +0200

>    Via: SIP/2.0/TCP foo.example.com;received=2001::db8;branch=...

<snip>

> consensus on this.  It would be good to know how the implementations

The RNID stack doesn't allow IPv6 stuff yet because of a limit of the socket
library it uses, but it does support IPv6 addresses.

It's not onerous to the developer to use IPv6 addresses in the received
param (i.e., to leave out the []s), and as Adam Roach pointed out, the
grammar's unambiguous.

frank

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 11 Apr 2006 09:00:18 -0500

> Resip currently does *not* use the brackets for v6 addresses on the

OK ... good to know.  Thanks.

> substantially harmed by differing interpretations than might it first

That depends.  A proxy that inserts a received parameter and *then*
forwards the request to the next downstream server may cause some
concern to the receiving server.  The specific behavior we have
observed is that the next downstream server is unable to parse the
request because of the brackets in the topmost Via "received"
parameter that were added by the previous upstream entity.

> number). 

If most implementations do not use the brackets, then we can let
things stand as they are.  In the worst case, we can define a
torture test around this in the SIPPING IPv6 torture test
document that asks implementations to be tolerant of brackets
when receiving SIP messages.  It'll be good to get some data
from the upcoming SIPit on more implementation behavior.

Thanks,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Bell Laboratories, Lucent Technologies, Inc.
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Adam Roach <[email-masked]>
Date: Tue, 11 Apr 2006 09:02:30 -0500

> parameter that were added by the previous upstream entity.

Why are they parsing anything but the topmost Via header field? It seems 
a waste of processing time to parse the entire stack of Vias.

/a

---

From: Adam Roach <[email-masked]>
Date: Tue, 11 Apr 2006 09:11:51 -0500

(replying to my own message, below)

Adam Roach wrote:

> Why are they parsing anything but the topmost Via header field? It 
> seems a waste of processing time to parse the entire stack of Vias.

To make sure we're not talking past each other: if a proxy inserts a 
"received" parameter and then forwards the request WITHOUT ADDING ITS 
OWN VIA HEADER FIELD on top of the one that it tagged with "received", 
then it's broken. If a proxy is slapping "received" parameters on the 
topmost Via header field that they just added, then it is similarly broken.

Now, the *upstream* server may have some issues in parsing the Via 
header field in responses (and I called this out in my previous 
message), but the contents of the "received" parameter really shouldn't 
be of any concern to them (unless they're using the "received" parameter 
for STUN-like functionality, in which case I think the correct answer is 
"use STUN").

/a

---

From: Fredrik Thulin <[email-masked]>
Date: Tue, 11 Apr 2006 16:21:22 +0200

On Tuesday 11 April 2006 16:02, Adam Roach wrote:
...
> seems a waste of processing time to parse the entire stack of Vias.

Loop detection requires a proxy to do at least parsial parsing of all 
the Via headers, not only the first one.

I believe you are correct when you say it is a waste of processing power 
to parse the received parameter for anything but the top-most Via 
header in responses, but constructing a parser that only parses the 
received= parameter in the top Via (instead of all found) might be a 
waste as well, although the waste would be development time and not 
processing time.

To answer the request for information about implementation behaviour, my 
open source SIP stack (YXA) puts IPv6 addresses _without_ brackets in 
received= parameters when it receives a request over IPv6, but parses 
IPv6 addresses both with and without brackets when forwarding responses 
according to the received= in the top Via.

/Fredrik

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 11 Apr 2006 09:21:19 -0500

> a waste of processing time to parse the entire stack of Vias.

Some implementations that do loop detection tend to parse all
the Vias in an incoming request; the more intelligent ones tend
to scan for a Via they may have inserted earlier and only parse
that one.

Implementations, unfortunately, differ in how much of the Via
stack they will parse.  I want to ensure that, at the very least,
the implementations do not automatically reject a message because
of this particular issue.

Also -- and this just struck me after sending the email out --
there are a couple of postings on the list that make a case
for the current "received" parameter being broken as per the
ABNF.  Please see

http://www1.ietf.org/mail-archive/web/sipping/current/msg10788.html
http://www1.ietf.org/mail-archive/web/sipping/current/msg10373.html

Thanks,

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 11 Apr 2006 09:38:55 -0500

Frank Shearar wrote:

> The RNID stack doesn't allow IPv6 stuff yet because of a limit of the
> socket library it uses, but it does support IPv6 addresses.

Does it parse the received with the brackets as well as without?

> It's not onerous to the developer to use IPv6 addresses in the
> received param (i.e., to leave out the []s), and as Adam Roach
> pointed out, the grammar's unambiguous.

Adam correctly points out that not having the port number in the
received parameter makes this problem a little easier to deal with.
However, there have been a couple of posts on the list that
point out a bug in the 3261 ABNF.  Please see

It would be nice if we could reconcile this minor issue.

Thanks,

- vijay

---

From: Pekka Pessi <[email-masked]>
Date: Tue, 11 Apr 2006 14:37:46 +0300

>delimiters '[' and ']' when its content is an IPv6 address.

It should have. Beer should be served in bigger glasses, too.

>draft-sipping-gurbani-ipv6-sip-02).

As an example of slightly non-conforming implementation?

>behavior is?  

Accept both, generate format according to the RFC 3261 grammar (no
brackets). Actually we just extended the grammar for any header
parameter:

  generic-param /= token EQUAL IPv6address

>Also, does anyone know how reSIProcate treats this?

This was discussed during Stockholm SIPit 12, as far as I can
remember, and we noted that syntax for received breaks the
generic-param syntax, but that is what there is in spec, so it is
should be used. There was one implementation that did not generate
or accept the RFC3261 syntax, but they fixed they implementation
within a couple of hours, if I remember correctly.

The problem is that you are a bit late. It is written that way in
RFC 3261. Every RFC-3261-compliant device, supporting IPv6 or not,
must be able to handle Via lines containing the RFC3261-style
received parameter with naked IPv6address.

--Pekka

---

From: "Frank Shearar" <[email-masked]>
Date: Tue, 11 Apr 2006 19:33:56 +0200

> Does it parse the received with the brackets as well as without?

*cough* It does now. Prior, it'd reject such messages with a useful
Reason-Phrase in the response. (The stack's not very "liberal in what you
accept".)

> http://www1.ietf.org/mail-archive/web/sipping/current/msg10373.html

Yes, and when I wrote my Via parsing routines it struck me that this is one
of the few (maybe even the only) place where IPv6 ADDRESSES are used instead
of REFERENCES. But as Jeroen points out (in the latter link) we'd want to
quote the reference, so we'd have ';received="[::1]"'. I guess it's cleaner
from an implementation point of view, but it is uglier from an aesthetic
point of view.

As Pekka Pessi points out though, RFC 3261 is written, so any SIP stack that
implements it will have to accept IPv6 addresses anyway.

> It would be nice if we could reconcile this minor issue.

As you say, at the least it'd be good to see a torture test showing that a
stack can handle a reference in the "received" parameter. Something that
says 'treat an IPv6 reference in a "received" parameter as though it was an
IPv6 address, i.e., strip the []s from the gen-value before you parse it.'

frank

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 11 Apr 2006 12:42:57 -0500

> It should have. Beer should be served in bigger glasses, too.

Yes, I don't think you will have problems establishing consensus
around the beer-and-the-glass part ;-)

> brackets). 

That is probably what should be the case if we decide to leave
the ABNF as-is.

> received parameter with naked IPv6address.

RFC 3261 has ambiguities - this is one of them, probably the
most benign, but an ambiguity nonetheless.  With a little work,
this can be easily sorted out in one of the following ways:

   (1) Have the sipping IPv6 torture test document update the
   IPv6 ABNF (although, this will require it to be a standards-
   track document, and not an informational).

   (2) Open and maintain a bug in bugs.sipit.net, pointing new
   developers to the appropriate behavior.

   (3) Write a quick draft updating the IPv6 ABNF in RFC 3261.

   (4) Agree that we will leave the representation of the
   received parameter as-is in RFC 3261, but put leniency torture
   tests around this in the sipping IPv6 torture test document.

Any preferences?

Thanks,

- vijay

---

From: Pekka Pessi <[email-masked]>
Date: Tue, 11 Apr 2006 23:39:09 +0300

>   developers to the appropriate behavior.

What is the bug there? Should we have 

1) via-received = "received" EQUAL (IPv4address / IPv6reference)

2) via-received = "received" EQUAL (IPv4address / IPv6address / IPv6reference)

3) gen-value /= IPv6address

4) both 2 and 3 above?

>   tests around this in the sipping IPv6 torture test document.

Hm, meaning that everyone should accept both IPv6address and
IPv6reference in the via-received? 

--Pekka

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 11 Apr 2006 15:59:14 -0500

> 1) via-received = "received" EQUAL (IPv4address / IPv6reference)

Yes, this one.

> IPv6reference in the via-received? 

Yes, although this means that the ABNF is implicitly your
(2) from the list above; i.e.,

2) via-received = "received" EQUAL (IPv4address / IPv6address /
                                     IPv6reference)

However, agreeing to leave the representation of the "received"
parameter as-is is skirting around this issue.  I would rather
we normatively chose (1), and colloquially specified that (2) is
allowed from a leniency viewpoint.

Thanks,

- vijay

---

From: Pekka Pessi <[email-masked]>
Date: Wed, 12 Apr 2006 00:18:11 +0300

>allowed from a leniency viewpoint.

I could live with this, if (2) is explicitly mentioned and allowed
for 3261-compatibility, like

via-received = "received" EQUAL (IPv4address / IPv6reference)

via-received-ip6-3261-compatible = "received" EQUAL IPv6address

--Pekka

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 12 Apr 2006 00:05:55 +0200

Hi Frank

> quote the reference, so we'd have ';received="[::1]"'.

Actually, I wasn't suggesting that. The '[' ']' characters would effectively 
serve as quotes, using both '"' and '[' would be superfluous (and some would 
say less preferred "[aesthetically]" speaking)

The approach of extending "gen-value" to include IPv6 addresses (gen-value 
/= IPv6address) is less appealing to me. That would cause the parser to 
accept much more than it should.

Another reason to use the '[' ']' syntax is RFC2732: 
http://www.ietf.org/rfc/rfc2732.txt. It does the same thing for much the 
same reasons

Regards,

jeroen

---

From: knarayan <[email-masked]>
Date: Tue, 11 Apr 2006 17:12:42 +0000

In a controlled/secured networks there may be the need to parse all the vias 
and take action like logging as part of the session and also for detection of 
unexpected behavior etc. 
Just a thought.

Kasturi

On Tuesday 11 April 2006 14:02, Adam Roach wrote:
> Sip-implementors mailing list
> [email-masked]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

---

From: "Frank Shearar" <[email-masked]>
Date: Wed, 12 Apr 2006 10:49:20 +0200

> say less preferred "[aesthetically]" speaking)

Ah OK, my apologies, I misread you then.

For me and my stack, RFC 3261 says "it takes an address" and, in the
interests of accepting liberally, my stack'll treat references as addresses.

frank