[DNSOP] Re: [v6ops] Re: [EXTERNAL] New Version Notification for draft-jens-7050-secure-channel-00.txt

[Mark Andrews <[e-mail]>]

It sounds like a unified approach to opening sockets as it does all the work of filling out the sockaddr structure required to make the application work with different kernel configurations. 

getaddrinfo uses inet_pton internally.  You also don’t have to test command line inputs for address literals or have to worry about the different sockaddr elements on different OSs.

Now if you are passing raw peer address over the wire you can not use them directly. You need to use inet_ntop then getaddrinfo on the result but the application should have been doing that in case the kernel wanted to use mapped addresses exclusively anyway.
-- 
Mark Andrews

> On 27 Jun 2024, at 23:50, Philip Homburg <[e-mail]> wrote:
> 
> 
>> 
>> You use getaddrinfo
>> instead. That is the IPv6 way to handle address literals. That way
>> you get the mappings done for you.
> 
> That sounds like a rather poor approach. You never know which applications
> users want to run. And telling users that they have to replace inet_pton
> with getaddrinfo usually doesn't have a lot of effect.
> 
> RFC 3493 is also silent about a preference for using getaddrinfo over
> inet_pton when it comes to parsing IP address literals.