NAT64 support

[jml5qh]

Is there any native support for dealing with NAT64 translation? Apple is requiring this support in apps: Apple documentation

[Sebastian Dröge-3]

On Mon, 2016-12-19 at 18:38 -0800, jml5qh wrote:
> Is there any native support for dealing with NAT64 translation? Apple
> is
> requiring this support in apps:  Apple documentation
> <https://developer.apple.com/library/content/documentation/Networking
> InternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfo
> rtheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html
> #//apple_ref/doc/uid/TP40010220-CH213-SW23>  

What exactly does this require from the application? Just not using any
IPv4 addresses directly, but instead using hostnames and IPv6
addresses? What exactly does Apple require?

Generally this should all work fine already, but there might be usage
of (or references to) now "forbidden" APIs nonetheless. Do you know
what exactly is a problem?

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[jml5qh]

I believe using host names will work. However the issue comes in some cases where you can't use hostnames for streaming (ex: connecting directly to an IP camera) and must instead pass an IPv4 literal. Here is what Apple specifies you must do. I tried this with udpsink and I'm having issues connecting.

Use System APIs to Synthesize IPv6 Addresses

If your app needs to connect to an IPv4-only server without a DNS hostname, use getaddrinfo to resolve the IPv4 address literal. If the current network interface doesn’t support IPv4, but supports IPv6, NAT64, and DNS64, performing this task will result in a synthesized IPv6 address.

Listing 10-1 shows how to resolve an IPv4 literal using getaddrinfo. Assuming you have an IPv4 address stored in memory as four bytes (such as {192, 0, 2, 1}), this example code converts it to a string (such as "192.0.2.1"), uses getaddrinfo to synthesize an IPv6 address (such as a struct sockaddr_in6 containing the IPv6 address "64:ff9b::192.0.2.1") and tries to connect to that IPv6 address.

On Tue, Dec 20, 2016 at 5:35 AM Sebastian Dröge <[hidden email]> wrote:

On Mon, 2016-12-19 at 18:38 -0800, jml5qh wrote:

> Is there any native support for dealing with NAT64 translation? Apple

> is

> requiring this support in apps:  Apple documentation

> <https://developer.apple.com/library/content/documentation/Networking

> InternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfo

> rtheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html

> #//apple_ref/doc/uid/TP40010220-CH213-SW23>  



What exactly does this require from the application? Just not using any

IPv4 addresses directly, but instead using hostnames and IPv6

addresses? What exactly does Apple require?



Generally this should all work fine already, but there might be usage

of (or references to) now "forbidden" APIs nonetheless. Do you know

what exactly is a problem?



--

Sebastian Dröge, Centricular Ltd · http://www.centricular.com_______________________________________________

gstreamer-devel mailing list

[hidden email]

https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[jml5qh]

One other issue I found was with udpsrc. It defaults to using the unresolved IPv4 address. If you are on a network that is doing NAT64, it does not work unless you manually specify the unresolved IPv6 address. Is there a way to make udpsrc automatically choose IPv6 if you are on a NAT64 network?

On Tue, Dec 20, 2016 at 7:16 AM, Joel Loeshelle <[hidden email]> wrote:

I believe using host names will work. However the issue comes in some cases where you can't use hostnames for streaming (ex: connecting directly to an IP camera) and must instead pass an IPv4 literal. Here is what Apple specifies you must do. I tried this with udpsink and I'm having issues connecting.

Use System APIs to Synthesize IPv6 Addresses

If your app needs to connect to an IPv4-only server without a DNS hostname, use getaddrinfo to resolve the IPv4 address literal. If the current network interface doesn’t support IPv4, but supports IPv6, NAT64, and DNS64, performing this task will result in a synthesized IPv6 address.

Listing 10-1 shows how to resolve an IPv4 literal using getaddrinfo. Assuming you have an IPv4 address stored in memory as four bytes (such as {192, 0, 2, 1}), this example code converts it to a string (such as "192.0.2.1"), uses getaddrinfo to synthesize an IPv6 address (such as a struct sockaddr_in6 containing the IPv6 address "64:ff9b::192.0.2.1") and tries to connect to that IPv6 address.

On Tue, Dec 20, 2016 at 5:35 AM Sebastian Dröge <[hidden email]> wrote:

On Mon, 2016-12-19 at 18:38 -0800, jml5qh wrote:

> Is there any native support for dealing with NAT64 translation? Apple

> is

> requiring this support in apps:  Apple documentation

> <https://developer.apple.com/library/content/documentation/Networking

> InternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfo

> rtheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html

> #//apple_ref/doc/uid/TP40010220-CH213-SW23>  



What exactly does this require from the application? Just not using any

IPv4 addresses directly, but instead using hostnames and IPv6

addresses? What exactly does Apple require?



Generally this should all work fine already, but there might be usage

of (or references to) now "forbidden" APIs nonetheless. Do you know

what exactly is a problem?



--

Sebastian Dröge, Centricular Ltd · http://www.centricular.com_______________________________________________

gstreamer-devel mailing list

[hidden email]

https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Sebastian Dröge-3]

On Tue, 2016-12-20 at 19:44 -0500, Joel Loeshelle wrote:
> One other issue I found was with udpsrc. It defaults to using the
> unresolved IPv4 address. If you are on a network that is doing NAT64,
> it does not work unless you manually specify the unresolved IPv6
> address. Is there a way to make udpsrc automatically choose IPv6 if
> you are on a NAT64 network?

Ok, so what is required here is to actually "resolve" IPv4 addresses to
their IPv6 equivalent. That's not implemented and also seems rather
silly to do. If such translation is required the network layer could as
well do that.

For making this work without source changes, you would have to provide
the corresponding IPv6 address directly instead of an IPv4 address. It
might make sense to add support for this somehow though, please file a
bug about that with all the details.

Unconditionally doing that will break things on other platforms though.

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[jml5qh]

Thanks Sebastian. That makes sense. Is there anyway for udpsrc to automatically default to the unresolved IPv6 address? For example, the equivalent of passing localhost if you wanted to get 127.0.0.1 for IPv4 and ::1 for IPv6?

On Wed, Dec 21, 2016 at 2:51 AM, Sebastian Dröge <[hidden email]> wrote:

On Tue, 2016-12-20 at 19:44 -0500, Joel Loeshelle wrote:
> One other issue I found was with udpsrc. It defaults to using the
> unresolved IPv4 address. If you are on a network that is doing NAT64,
> it does not work unless you manually specify the unresolved IPv6
> address. Is there a way to make udpsrc automatically choose IPv6 if
> you are on a NAT64 network?

Ok, so what is required here is to actually "resolve" IPv4 addresses to
their IPv6 equivalent. That's not implemented and also seems rather
silly to do. If such translation is required the network layer could as
well do that.

For making this work without source changes, you would have to provide
the corresponding IPv6 address directly instead of an IPv4 address. It
might make sense to add support for this somehow though, please file a
bug about that with all the details.

Unconditionally doing that will break things on other platforms though.

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel