Re: [Rum] IPv6 support

"Olle E. Johansson" <oej@edvina.net> Fri, 12 March 2021 18:05 UTC

Return-Path: <oej@edvina.net>
X-Original-To: rum@ietfa.amsl.com
Delivered-To: rum@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8079C3A1832 for <rum@ietfa.amsl.com>; Fri, 12 Mar 2021 10:05:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVEFQaioSjM8 for <rum@ietfa.amsl.com>; Fri, 12 Mar 2021 10:05:36 -0800 (PST)
Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA0793A1941 for <rum@ietf.org>; Fri, 12 Mar 2021 10:05:36 -0800 (PST)
Received: from macbook-pro.webway.org (h-205-16.A165.corp.bahnhof.se [176.10.205.16]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 971A93FA; Fri, 12 Mar 2021 19:05:28 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: "Olle E. Johansson" <oej@edvina.net>
In-Reply-To: <6e181cd2-0e22-bd6b-1558-9b6796ea820c@alum.mit.edu>
Date: Fri, 12 Mar 2021 19:05:28 +0100
Cc: Olle E Johansson <oej@edvina.net>, rum@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <D9C677BC-3266-435A-B5E9-662A40B4A1A7@edvina.net>
References: <AEA553BF-3F7C-402B-B184-99224EC0AFD9@brianrosen.net> <1658FF38-1A4E-462D-BBD0-D3D807655DA3@edvina.net> <6e181cd2-0e22-bd6b-1558-9b6796ea820c@alum.mit.edu>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rum/4EuoRHqmaWfER1DW2vOqldNniLg>
Subject: Re: [Rum] IPv6 support
X-BeenThere: rum@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Relay User Machine <rum.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rum>, <mailto:rum-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rum/>
List-Post: <mailto:rum@ietf.org>
List-Help: <mailto:rum-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rum>, <mailto:rum-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Mar 2021 18:05:39 -0000


> On 12 Mar 2021, at 17:29, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
> 
> On 3/11/21 1:57 AM, Olle E. Johansson wrote:
>>> On 10 Mar 2021, at 22:08, Brian Rosen <br@brianrosen.net <mailto:br@brianrosen.net>> wrote:
>>> 
>>> 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?
>> 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.
> 
> 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.

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