Re: [Rum] IPv6

[Ed Sayers <[e-mail]>]

Hi Brian,

I am sure this is a bit rough and could do with a tidy up. I think it covers it though:

“
The RUM client MUST support RFC-6052 and RFC-7050 in order to synthesize routable IPv6 addresses. For example, when IPv4 addresses are seen in SIP signalling or SDP but IPv6 addresses are needed by the client.
“


Ed Sayers
Endpoint SDK Team Lead
Purple, a Division of ZP Better Together, LLC
purplevrs.com<https://purplevrs.com/>

[Purple is DEI certified!]
The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message.




From: Brian Rosen <[e-mail]>
Sent: 31 August 2021 11:23
To: Olle E. Johansson <[e-mail]>
Cc: Ed Sayers <[e-mail]>; Paul Kyzivat <[e-mail]>; [e-mail]
Subject: Re: [Rum] IPv6

While I would be willing to work on such a document and as sipvore chair I sure it would be a welcome draft, as author and co-chit here I don’t want a mis ref to it holding up our document.

So, I am happy to include those RFCs as requirements. If you want to suggest any text beyond just making them required, I’d be happy to include it, and we can then work on a more general draft.

Brian

On Tue, Aug 31, 2021 at 6:05 AM Olle E. Johansson <[e-mail]<mailto:[e-mail]>> wrote:


> On 31 Aug 2021, at 11:53, Ed Sayers <[e-mail]<mailto:[e-mail]>> wrote:
>
> Hi,
>
> I have separated out IPv6 as a topic.
>
> We all know that IPv6 is the way to go, and also necessary as the IPv4 address range has all but dried up.
> However, the transition to IPv6 across the World has not been an easy one and is definitely not 'just SIP'.
>
> It is also very true to say that IPv6 needs to be embraced on endpoints; US mobile phone carriers were forced to start using IPv6 for handsets a long time ago.
> However, huge swathes of the Internet remain IPv4, because adding IPv6 to Infrastructure is not such as easy task to tackle, and because those IP addresses rarely change compared to endpoints.
>
> Again, we all agree - IPv6 is the way to go. But, IPv4, NAT64 and DNS64 are going to be needed for a long time to come.
> For many use-cases, DNS64 and NAT64 hide the transition back to the IPv4 Internet when not supported by Infrastructure.
> But, as we know, SDP include IP addresses that DNS64 and NAT64 cannot see and will not translate.
>
> Therefore, we'd like to propose for consideration that a RUM endpoint must also support the following RFCs as a possible fall back to aid the necessary transition to IPv6 over time:
> * RFC-6052 - IPv6 Addressing of IPv4/IPv6 Translators
> * RFC-7050 - Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis

What makes this special for RUM? Isn’t this support needed for all SIP implementations? If this is needed for transition, I would love to see these in a  generic document for SIP - how to implement it, considerations for SIP and offer/answer as well as security considerations.

/O
>
>
> Ed Sayers
> Endpoint SDK Team Lead
> Purple, a Division of ZP Better Together, LLC
> purplevrs.com<http://purplevrs.com>
>
> The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message.
>
>
>
>
> -----Original Message-----
> From: Rum <[e-mail]<mailto:[e-mail]>> On Behalf Of Brian Rosen
> Sent: 30 August 2021 22:24
> To: Paul Kyzivat <[e-mail]<mailto:[e-mail]>>
> Cc: Chad Leeper <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
> Subject: Re: [Rum] IPv6 and encryption
>
> I don’t think there are ANY alternatives to SRTP.  There are alternatives to DTLS-SRTP.  There are moves within the IETF to deprecate SDES, specifically.  There is push back on that, but it’s an ongoing discussion because SDES isn’t secure enough.   Since all providers I know about anchor media, this only affects the initial hop.  Users really want to hear that their media is protected end to end (at least hop by hop) but our document doesn’t require that.  Again, we need a STANDARDS based solution, and we have to live within the constraints the IETF has for new standards with respect to security.  Like nearly every organization, the IETF is much more security conscious than it was, and won’t tolerate bad security although it often recognizes the necessity for backwards compatibility as long as it’s not to a known insecure mechanism.
>
> I really think this is a “step up to the bar” thing.  We’ve spent lots of time and cycles implementing things that turn out not to be secure enough, and we have to move forward on things that are.  DTLS-SRTP is one of those things, as is IPv6.
>
> Brian
>
>
>> On Aug 30, 2021, at 5:06 PM, Paul Kyzivat <[e-mail]<mailto:[e-mail]>> wrote:
>>
>> Chad,
>>
>> Welcome to the RUM WG!
>>
>> On 8/30/21 11:51 AM, Chad Leeper wrote:
>>> - While WebRTC w/ SRTP/DTLS (encryption) is an excellent idea going forward, it can't be a "MUST" requirement.  I agree with Roger Slusser that mandating compliance using MUST requires providers to implement significant development to change over to what RUM is specifying.
>>
>> The requirements in this doc will apply only to devices that claim to conform to it. Presumably you could continue to support your existing devices using whatever mechanisms they currently use. So the implementation burden is only on the server side, not the legacy device side. (Of course the FCC will have a say in this.)
>>
>> One motivation for the webrtc requirement is so that a RUE can be built on top of WebRTC. E.g., it can be a server that supports deaf users using any device with a browser. Such a server is effectively just signaling gateway that can establish a p2p link between the browser and the VRS provider server. (It does have to transcode RTT, but that is less of a burden.)
>>
>> When defining a specification for an interface that is to be implemented by independent parties it is necessary for essential functions to have at least one mandatory to implement mechanism. Currently there are no standards for connecting a RUE to a provider, so we need to pick *something* to be mandatory to implement. If you have an alternative for the media you would prefer, then please make a specific proposal.
>>
>>> - We should keep any new privacy requirements very minimal at this time.  While companies in the EU have already created their systems in compliance with the GDPR, most of the world hasn't created an equivalent yet.  So what may look like an easy change to EU implementers may be a dramatic change for others.
>>
>> I don't think we have said much about privacy of retained data. But we are concerned that the media and signaling be private between the RUE and the provider. That is a low bar these days. It is unlikely that anything less could be approved. I expect the FCC will agree.
>>
>> If you have an alternate proposal that achieves that then make a proposal we can discuss.
>>
>>      Thanks,
>>      Paul
>>
>>> On Fri, Aug 27, 2021 at 3:16 PM Paul Kyzivat <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>> wrote:
>>>   Providers,
>>>   My request below to Roger should have been broader. You all seem to
>>>   have
>>>   the same issue. I encourage any/all of you to make an alternative
>>>   proposal here. Just saying "we don't like what is there" isn't helpful
>>>   without an alternative.
>>>            Thanks,
>>>            Paul
>>>   On 8/26/21 5:40 PM, Paul Kyzivat wrote:
>>>> Roger,
>>>>
>>>> On 8/26/21 3:30 PM, Roger Slusser wrote:
>>>>
>>>>> Most providers already support encryption and IPV6 on a limited
>>>   scope,
>>>>> not necessarily the way it is defined in RUM spec. Mandating
>>>>> compliance using MUST requires providers to discard sometimes huge
>>>>> amounts of development to change over to what RUM is specifying.
>>>   The
>>>>> push back is not about doing these things it is about the loss of
>>>>> time, effort and money to do them in the way RUM mandates with
>>>   MUSTs.
>>>>
>>>> Do you think there is something else we could write in this spec
>>>   that
>>>> covers encryption and IPv6 in a way that is less burdensome for
>>>> providers while remaining interoperable with all providers?
>>>>
>>>> If so, can you please spell it out?
>>>   --     Rum mailing list
>>>   [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
>>>   https://www.ietf.org/mailman/listinfo/rum
>>>   <https://www.ietf.org/mailman/listinfo/rum>
>>
>> --
>> Rum mailing list
>> [e-mail]<mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/rum
>
> --
> Rum mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/rum
> --
> Rum mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/rum