IPv6 literals & URLSession host addresses

We have a need to use IPv6 literals in URLSession host addresses at times. This has its roots in issues with load balancing, and which hosts share what information, and it isn't something we can work around right now.

The IPv6 literal we're using was returned in the session metrics of a previous URLSession as the remote address of that connection.

What are the formatting requirements for that, if any? I.e., if we're setting

"61:ff4a::7a81:5002" // Not the real address :-)

As the host part of a URLComponents(), then what's sent is

61%3aff4a%3a%3a7a81%3a5002

Which is kind of what I'd expect since it's escaping it.

If we set

"[61:ff4a::7a81:5002]"

Which is what's specified in RFC-2732 then we get a host-not-found error

Is there somewhere in the documentation about how we can use an IPv6 literal as a URLSession host address?

In Supporting IPv6 DNS64/NAT64Networks the advice is "don't", but that's not one of our options...

Is there somewhere in the documentation about how we can use an IPv6 literal as a URLSession host address?

To my knowledge no. I suspect the reason for this is due to the fact that we do not want IP addresses v4 or v6 specified when composing a URL. Rather we encourage connecting by hostname to avoid trust issues and so that our lower level libraries can handle all of the DNS machinery for you.

Encouraging hostname connections is fine, but sometimes literals are needed. Documentation to support that would be good.

Is this something that used to work but is now failing on, say, iOS 16?

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Yes. Pre-iOS 16 we were just setting the IPv6 literal and it was working.

With iOS 16.0.3 customers saw that IPv6 was not working at all. It looks like that may have been partly an Apple issue, because there was other commentary about this on the net with other applications, and some of the problems went away with 16.1. This caused a lot of confusion about just whose bug it was :-)

With 16.1 we see that if we set an IPv6 literal without [] around it in the URL components host field then the resulting URL (components.url) has an empty host:

https:///<rest of request path>

When we set [] around the literal then we get a proper request:

https://[<IPv6 literal]/<rest of request path>

We do have it working at the moment on pre-iOS 16 & iOS 16.1+ by checking to see if the host in final URL is empty. We didn't want to do a check for OS version since we weren't sure exactly which one gave which behavior.

We didn't want to do a check for OS version since we weren't sure exactly which one gave which behavior.

Understandable.

I’m going to recommend that you open a DTS tech support incident about this. I’d love to investigate this properly, but I don’t have time for that in the the context of DevForums.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

IPv6 literals &amp; URLSession host addresses
 
 
Q