Re: [Rum] IPv6

[Paul Kyzivat <[e-mail]>]

On 9/1/21 10:09 AM, Ed Sayers wrote:
> Hi Paul,
> 
> This doesn't save work. It allows the client to do something that the server cannot do.
> This provides the mechanism to cover a wider range of scenarios and a greater chance of ensuring success.
> 
> As I think Olle already indicated previously, it is assumed that clients are already capable of doing this. But, it is not called out anywhere..

I'm not getting it. Can you explain further?

Everything begins with the RUE registering with the server. As long as 
the server offers both v4 and v6 in its DNS entry then the client will 
be able to complete that the registration using whichever it has. Then 
signaling for calls, in both directions. will reuse the TLS connection 
from registration.

For media both ends can offer whichever of v4 or v6 they are using for 
signaling.

So NAT64/DNS64 isn't required.

What am I missing?

	Thanks,
	Paul

> Ed Sayers
> Endpoint SDK Team Lead
> Purple, a Division of ZP Better Together, LLC
> 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: Paul Kyzivat <[e-mail]>
> Sent: 01 September 2021 15:06
> To: Ed Sayers <[e-mail]>; Brian Rosen <[e-mail]>
> Cc: Olle E. Johansson <[e-mail]>; [e-mail]
> Subject: Re: [Rum] IPv6
> 
> On 9/1/21 8:18 AM, Ed Sayers wrote:
>> Hi Brian,
>>
>> This only affects the client side, because it is the client may be
>> behind a NAT64/DNS64. The server cannot determine those
>> network-specific mappings.
> 
> Does it really make sense to ask the client to do extra work in order to save work on behalf of the server? If we ask the server to support both then the clients will be able to use whatever kind of addresses they are able to obtain.
> 
> 	Thanks,
> 	Paul
> 
>> **
>>
>> *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:* 01 September 2021 13:16
>> *To:* Ed Sayers <[e-mail]>
>> *Cc:* Olle E. Johansson <[e-mail]>; Paul Kyzivat
>> <[e-mail]>; [e-mail]
>> *Subject:* Re: [Rum] IPv6
>>
>> Wouldn’t this apply to both sides?
>>
>> Brian
>>
>>
>>
>>      On Sep 1, 2021, at 4:43 AM, Ed Sayers <[e-mail]
>>      <mailto:[e-mail]>> wrote:
>>
>>      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 supportRFC-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/>
>>
>>      	
>>
>>      <image001.jpg>
>>
>>      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] <mailto:[e-mail]>>
>>      *Sent:*31 August 2021 11:23
>>      *To:*Olle E. Johansson <[e-mail] <mailto:[e-mail]>>
>>      *Cc:*Ed Sayers <[e-mail] <mailto:[e-mail]>>;
>>      Paul Kyzivat <[e-mail] <mailto:[e-mail]>>;
>>      [e-mail] <mailto:[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>
>>           >>>   <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
>>          <https://www.ietf.org/mailman/listinfo/rum>
>>           >
>>           > --
>>           > Rum mailing list
>>           >[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
>>          <https://www.ietf.org/mailman/listinfo/rum>
>>
>