Subject: [dispatch] Initial submission of draft-klatsky-dispatch-ipv6-impact-ipv4

From: "Klatsky, Carl" <[email-masked]>
Date: Thu, 6 Jun 2013 16:56:21 +0000

Hi,

The draft noted below was just submitted.  Soliciting feedback on the document and asking for direction on how proceed with this document.  Thanks.

Filename:            draft-klatsky-dispatch-ipv6-impact-ipv4

Revision:              00

Title:                      Interoperability Impacts of IPv6 Interworking with Existing IPv4 SIP Implementations

Creation date:   2013-06-04

Group:                  Individual Submission

Number of pages: 8

URL:             http://www.ietf.org/internet-drafts/draft-klatsky-dispatch-ipv6-impact-ipv4-00.txt

Regards,
Carl Klatsky

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 06 Jun 2013 13:35:39 -0400

Hi Carl,

This seems like a useful draft.
On a casual reading I only noticed one issue:

In section 3.10 you say that a 488 should be returned.
I suppose that is the worst case, but there may be less severe 
possibilities. For instance, if there are multiple m-lines with 
different addresses, it could simply reject those m-lines with addresses 
it can't use, and accept the m-lines it can use.

The 488 then becomes a plausible response if all the m-lines need to be 
rejected.

	Thanks,
	Paul

On 6/6/13 12:56 PM, Klatsky, Carl wrote:
> Hi,
>
> The draft noted below was just submitted.  Soliciting feedback on the
> document and asking for direction on how proceed with this document.
> Thanks.
>
> Title:                      Interoperability Impacts of IPv6
> Interworking with Existing IPv4 SIP Implementations
>
> URL:
> http://www.ietf.org/internet-drafts/draft-klatsky-dispatch-ipv6-impact-ipv4-00.txt
>
> Regards,
>
> Carl Klatsky
>
>
>
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Thu, 6 Jun 2013 17:45:43 +0000

Yeah, that is correct. This section seems to have an older version of the text. We will fix that in the next version of the document.

Regards,
 Rifaat

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Paul Kyzivat
> Sent: Thursday, June 06, 2013 1:36 PM
> To: [email-masked]
> Subject: Re: [dispatch] Initial submission of draft-klatsky-dispatch-
> ipv6-impact-ipv4
> 
> Hi Carl,
>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 7 Jun 2013 09:29:43 +0200

> The draft noted below was just submitted.  Soliciting feedback on the document and asking for direction on how proceed with this document.  Thanks.
Additional background information: This document is one result of the work done in the SIP Forum IPv6 working group.

/O

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 7 Jun 2013 17:02:19 -0400

The section 3.3 "IPv6 Address Handling in Contact Headers" will need some work or further thought.  For in-dialog requests: I assume (or hope) that any true Proxy that switches a request from IPv4 to IPv6 is session-stateful and inserts itself in a Record-Route in the dialog-forming request, so that in-dialog requests from the UAS/UAC always at least go through that Proxy.  The hard part is what to do with out-of-dialog requests trying to use the Contact... for example a REFER.  Sending the REFER to your outbound server, as the current text recommends, won't help if that server is also only IPv4.

Section 3.4. "IPv6 Address Handling in SDP Body" should just stipulate it's in a received SDP offer, not that it is in an INVITE per se - since the offer can come in a response to an offerless INVITE, or in an in-dialog UPDATE, for example.  In fact, I think theoretically it may be possible to receive one in an SDP answer too, in one of the ICE candidates form the far-end. (I don't recall if ICE advertised them all, or limited itself to same address family)

Section 3.6. "IPv6 Address Handling in 30x Redirect" says:
   The IPv4-only UAC should send its new request to its outbound SIP server
   without generating an error upon receipt of a 30x message with IPv6
   information.
For "endpoint" UAC's such as phones I guess that's a reasonable recommendation, but for gateways/app-servers and other UACs it's wrong - I mean it's basically changing what 3xx is supposed to mean/do.  If you got a 3xx with a contact that you can't reach/access, then you can't reach/access it - it's an error, for which you might have a local policy for what to do next other than fail the request.

Section 3.7. IPv6 Address Handling in REFER-based Transfer: ummm, this text doesn't help.  It basically just says "deal with it". :)

-hadriel

---

From: [email-masked] (Dale R. Worley)
Date: Sun, 9 Jun 2013 01:30:09 -0400 (EDT)

> From: Hadriel Kaplan <[email-masked]>
> 
> The section 3.3 "IPv6 Address Handling in Contact Headers" will need
> some work or further thought.  For in-dialog requests: I assume (or
> hope) that any true Proxy that switches a request from IPv4 to IPv6
> is session-stateful and inserts itself in a Record-Route in the
> dialog-forming request, so that in-dialog requests from the UAS/UAC
> always at least go through that Proxy.

Strictly speaking, a proxy can Record-Route itself without being
session-stateful.  The critical thing is that a proxy that switches
address families used in addressing may have to Record-Route itself to
ensure that in-dialog requests work.

> The hard part is what to do
> with out-of-dialog requests trying to use the Contact... for example
> a REFER.  Sending the REFER to your outbound server, as the current
> text recommends, won't help if that server is also only IPv4.

This seems to go back to the usual practical advice, "Use GRUUs as
Contacts."  But that only works if the registrar that issues the GRUUs
is accessible via both IPv4 and IPv6.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Sun, 9 Jun 2013 01:30:28 -0400 (EDT)

> From: Paul Kyzivat <[email-masked]>
> 

At the least, the text needs to be changed to "receives a ... SDP offer
all of whose network addresses are not compatible ...", as there could
both be m= lines with IPv4 addresses and m= lines with IPv6
addresses.  But as Paul says, it's better to accept the lines you can
and reject the ones you can't.

BTW, what do real devices do when the receive an offer that contains
no m= line that it can accept?

Dale

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 10 Jun 2013 13:13:34 +0200

> and reject the ones you can't.
Right.
> no m= line that it can accept?
From SIPit, most of them send 488, but there are a few that sends other codes.

This was not from IPv6 tests, but tests with RTP/SAVPF. We reached consensus
that 488 was the recommended error code. From the SIPit 30 summary:

"We successfully set up calls between browsers with both video and audio over
both the proxy and the SBC. During the test, we invited a large set of SIP UA's
to test receiving INVITEs with these large SDPs to test how they responded. A
few ones responded incorrectly with "bad media type", one parsed via headers
and failed with a "400" message and most of the UA's correctly responded with a
"488" response code."

/O

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 Jun 2013 09:08:38 -0400

An alternative to 488 when no m-lines can be accepted is to accept the 
offer while rejecting all the m-lines. Then, send another offer 
indicating what you *can* do.

I've explored cases where that might be useful. But such behavior could 
also cause problems in forking scenarios. That can be minimized by only 
doing it with a reliable provisional followed by an UPDATE, so that it 
is still possible for the call leg to fail and forking to try someplace 
else. But its also a strategy that is only likely to be helpful in 
special cases - devices with unusual capabilities.

	Thanks,
	Paul

---

From: "Neelakantan, Neel" <[email-masked]>
Date: Tue, 25 Jun 2013 19:41:54 +0000

Section 3 should have a brief description about IPv6 address handling, where there could be IPv6 addresses on various SIP headers in the SIP message and provide a general approach to handle these.  All the subsections are special case of this general guideline.

In other words, it will be good to talk about URI portion which might have ipv6 headers and how this should be handled.

Additionally, from/to headers could have IPv6 address.

Thanks,
Neel.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Klatsky, Carl
Sent: Thursday, June 06, 2013 11:56 AM
To: [email-masked]'
Subject: [dispatch] Initial submission of draft-klatsky-dispatch-ipv6-impact-ipv4

Hi,

Revision:              00

Number of pages: 8

Regards,
Carl Klatsky

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 26 Jun 2013 10:13:41 +0200

> Additionally, from/to headers could have IPv6 address.
We tried to avoid listing ALL possibly headers that could have IPv6 headers, because that will be a moving target. We want to alert the developer with a few cases that we've seen in real life.

In the next release we're adding an appendix with more information about using IPv6 in the URI.

Thank you for your feedback.

/O

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 27 Jun 2013 13:00:43 -0400

> We tried to avoid listing ALL possibly headers that could have IPv6 headers, because that will be a moving target. We want to alert the developer with a few cases that we've seen in real life.

I agree we can't list them all (nor should we try), but the To/From in particular are mandatory headers and so commonly used for processing purposes that I think we should mention them explicitly. (I know I suggested that the To/From be listed before the draft got published into IETF, but there's no rule against repeating ourselves :)

-hadriel

---

From: "Neelakantan, Neel" <[email-masked]>
Date: Thu, 27 Jun 2013 17:03:42 +0000

See inline.

> From: Hadriel Kaplan [mailto:[email-masked]]
> Sent: Thursday, June 27, 2013 12:01 PM
> To: Olle E. Johansson
> Cc: Neelakantan, Neel; [email-masked]'
> Subject: Re: [dispatch] Initial submission of draft-klatsky-dispatch-ipv6-
> impact-ipv4
> 
> 
> > We tried to avoid listing ALL possibly headers that could have IPv6 headers,
> because that will be a moving target. We want to alert the developer with a
> few cases that we've seen in real life.
> >
> 
> I agree we can't list them all (nor should we try), but the To/From in particular
> are mandatory headers and so commonly used for processing purposes that I
> think we should mention them explicitly. (I know I suggested that the
> To/From be listed before the draft got published into IETF, but there's no
> rule against repeating ourselves :)
> 
[Neel] 

I agree that there is no need to catalog for every header.  However, there can be a generic section which covers about URI host portion where it can be a IPv6 address.  This way it is future proof and need not be repeated at all places.

Thanks,
Neel

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 27 Jun 2013 21:45:41 +0200

> I agree we can't list them all (nor should we try), but the To/From in particular are mandatory headers and so commonly used for processing purposes that I think we should mention them explicitly.…

Well, there are rules against repeating some headers... ;-)

Thanks for the feedback - again - Hadriel. We'll consider this for the next version.

/O