Subject: [Rum] IPv6 support

From: Brian Rosen <[email-masked]>
Date: Wed, 10 Mar 2021 16:08:21 -0500

We’re still having discussions on IPv6 mandatory to support.

ISTM that since some very important systems are IPv6 only, and most ISPs are supporting both, that it’s hard to not require support for it.  In the meeting Adam discussed using gateways and 4-in-6 support.  We need to decide what to do.  I point out that many SBCs are capable of being a fully functional B2BUA and media relay with IPv4 or IPv6 on either side.  Since it already rewrites addresses for both signaling and media it has no issues supporting IPv6 on one side and IPv4 on the other side.  I am checking on support for IPv6 addresses in US auditing/reporting CDRs and will report my findings shortly.  I would like to just require both sides to support IPv6, without saying how.  

Other thoughts?

Brian

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 10 Mar 2021 16:44:53 -0500

> ISTM that since some very important systems are IPv6 only, and most ISPs are supporting both, that it’s hard to not require support for it.  In the meeting Adam discussed using gateways and 4-in-6…

ISTM the question needs some broadening. There are multiple uses for IP 
addresses in sip - signaling and in media streams. Are we talking about 
mix and match here? How would we handle mixing IPv4 and IPv6 in O/A? I 
don't think we can get away with not discussing this.

	Thanks,
	Paul

---

From: Brian Rosen <[email-masked]>
Date: Wed, 10 Mar 2021 16:58:38 -0500

Agree, but think that all combinations should have the same rules, and so we need to be explicit that combinations are allowed, but if we say MUST for one, we’re saying MUST for the other.

Brian

> On Mar 10, 2021, at 4:44 PM, Paul Kyzivat <[email-masked]> wrote:
> 
> ISTM the question needs some broadening. There are multiple uses for IP addresses in sip - signaling and in media streams. Are we talking about mix and match here? How would we handle mixing IPv4 and IPv6 in O/A? I don't think we can get away with not discussing this.
> 
> 	Thanks,
> 	Paul
> 
> -- 
> Rum mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rum

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 10 Mar 2021 18:46:19 -0500

> Agree, but think that all combinations should have the same rules, and so we need to be explicit that combinations are allowed, but if we say MUST for one, we’re saying MUST for the other.

The issues are different for signaling and media. But media is the 
harder case. When you are generating an initial offer you don't know 
what the other side supports. There are several mechanisms for how to 
represent both in SDP. They are practically speaking mutually exclusive. 
So I think we need to choose one. The most recent one is ICE. In an 
initial offer with ICE you can choose either IPv4 or IPv6 as the default 
offer that will be used if the other side doesn't support ICE. It would 
be necessary to support ICE to support both v4 and v6. That is certainly 
a workable way to proceed, but is it an acceptable requirement.

I'm not aware of an alternative I would be comfortable proposing.

	Thanks,
	Paul

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 11 Mar 2021 07:57:43 +0100

> On 10 Mar 2021, at 22:08, Brian Rosen <[email-masked]> wrote:
> 
IPv6 has to get in.

Both IETF and the SIP forum has produced documents on dual stack behaviour and there’s a lot of potential
issues to be aware of there. SIPconnect 2.0 also added some helpful guidelines.

https://www.rfc-editor.org/rfc/rfc7984.html <https://www.rfc-editor.org/rfc/rfc7984.html>
https://www.sipforum.org/activities/technical-wg-overview-and-charter/ipv6-task-group-charter/ <https://www.sipforum.org/activities/technical-wg-overview-and-charter/ipv6-task-group-charter/>
https://tools.ietf.org/html/draft-klatsky-dispatch-ipv6-impact-ipv4-02 <https://tools.ietf.org/html/draft-klatsky-dispatch-ipv6-impact-ipv4-02>

https://www.sipforum.org/download/sipconnect-technical-recommendation-version-2-0/?wpdmdl=2818 <https://www.sipforum.org/download/sipconnect-technical-recommendation-version-2-0/?wpdmdl=2818>

/O

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 12 Mar 2021 11:29:06 -0500

On 3/11/21 1:57 AM, Olle E. Johansson wrote:
> 
> 
>> On 10 Mar 2021, at 22:08, Brian Rosen <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> ISTM that since some very important systems are IPv6 only, and most 
>> ISPs are supporting both, that it’s hard to not require support for 
>> it.  In the meeting Adam discussed using gateways and 4-in-6 support. 
>>  We need to decide what to do.  I point out that many SBCs are capable 
>> of being a fully functional B2BUA and media relay with IPv4 or IPv6 on 
>> either side.  Since it already rewrites addresses for both signaling 
>> and media it has no issues supporting IPv6 on one side and IPv4 on the 
>> other side.  I am checking on support for IPv6 addresses in US 
>> auditing/reporting CDRs and will report my findings shortly.  I would 
>> like to just require both sides to support IPv6, without saying how.
>>
>> Other thoughts?
> IPv6 has to get in.
> 

Thanks for the useful pointers.

> https://www.rfc-editor.org/rfc/rfc7984.html 
> <https://www.rfc-editor.org/rfc/rfc7984.html>
> https://www.sipforum.org/activities/technical-wg-overview-and-charter/ipv6-task-group-charter/ 
> <https://www.sipforum.org/activities/technical-wg-overview-and-charter/ipv6-task-group-charter/>
> https://tools.ietf.org/html/draft-klatsky-dispatch-ipv6-impact-ipv4-02 
> <https://tools.ietf.org/html/draft-klatsky-dispatch-ipv6-impact-ipv4-02>
> 
> https://www.sipforum.org/download/sipconnect-technical-recommendation-version-2-0/?wpdmdl=2818 
> <https://www.sipforum.org/download/sipconnect-technical-recommendation-version-2-0/?wpdmdl=2818>

We might want to consider section 15 of the last reference above as a 
pattern that might meet our needs.

	Thanks,
	Paul

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 12 Mar 2021 19:05:28 +0100

> On 12 Mar 2021, at 17:29, Paul Kyzivat <[email-masked]> wrote:
> 
>>> On 10 Mar 2021, at 22:08, Brian Rosen <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
> We might want to consider section 15 of the last reference above as a pattern that might meet our needs.

Yes, but at that point we declared ICE out of scope and as you pointed out, I think it’s very much IN
scope for RUE.

Have a nice weekend all!

/O

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 12 Mar 2021 13:25:11 -0500

> Yes, but at that point we declared ICE out of scope and as you pointed out, I think it’s very much IN

That gives us a couple of different ways forward to consider.

	Thanks,
	Paul