Re: [sipcore] IPv6 in the sip core wg

[Paul Kyzivat <[e-mail]>]

Vijay,

On 12/13/13 11:26 AM, Vijay K. Gurbani wrote:
> On 12/13/2013 10:17 AM, Olle E. Johansson wrote:
>> The problem is really that RFC 3263 repeats "A or AAAA" - which means
>> that if we follow RFC 3263 verbatim we won't have both IPv4 and IPv6
>> addresses to connect to. I have not claimed that it talks about how
>> we connect.
>
> I am sorry to keep interjecting rfc6157 here, but it does say to perform
> name lookup using getaddrinfo(), which, if rfc3484 is adhered to will
> produce an ordered list of IPv6/IPv4 destination addresses.

It's ok to keep bringing it up, because it seems to be relevant.

I just glanced through it to refresh my memory. It seems to cover, at 
least implicitly, some of the same scope. But that part of the draft 
appears to have been somewhat of an afterthought.

I find the following problematic:

"IPv6-only or dual-stack clients MUST use the newer getaddrinfo() name 
lookup function, instead of gethostbyname()."

It is a normative statement to use a particular API function as an 
alternative to a different API function. But there was never a 
requirement to use "gethostbyname", so the "instead" isn't meaningful, 
and we shouldn't be requiring use of any particular API functions. It 
would make a lot more sense if it had a MUST on the algorithms in 3484.

(I no doubt participated in the WGLC on this document, so I have only 
myself to blame for not complaining about this earlier.)

Since that is now an RFC, I guess we should assume that people will "do 
the right thing" if those APIs don't work for them, and follow the 
intent of the RFC.


>> It seems like no one can say whether this text is normative or not,
>> which really means we have to clarify this, since developers will be
>> (or already am) confused on how to implement properly.
>
> Sure, rfc6157 does not update rfc3263 so this point may be lost in the
> noise.  To be sure, I am not against adding a milestone to better
> specify this behaviour; all I am pointing out is that more than rfc3263
> may be impacted.

At the very least, we should include that in the scope of the work.
Here is a revised milestone:

     May 2014  WGLC of procedures to supplement RFC3263 and RFC6157 for
     dual-stack client and server handling of SIP URIs containing domain
     names (PS)

	Thanks,
	Paul

> Cheers,
>
> - vijay