Re: [sipcore] IPv6 in the sip core wg

[Cullen Jennings <[e-mail]>]

Well from a milestone point of view there is a big difference between we need the change an existing RFC (i.e. update) or we need to define a new RFC that tells developers who want to implement the new RFC what they need to do. 

I think what is needed here is the later item and not the update. I have asked about this a bunch of times and and I always get answers that suggest that a new document is needed but it does not need to replace or update 3263. It needs to be a new document that provides more detailed advice. If we are going to say this updates something, I want to be convinced first that there is something that is wrong and needs to be changed. I'm fine with the idea that ore detailed specifications are needed to do something like happy eyeballs for SIP but I don't think that requires an update of 3263. 


On Dec 10, 2013, at 12:21 PM, Olle E. Johansson <[e-mail]> wrote:

> 
> On 10 Dec 2013, at 12:14, Cullen Jennings <[e-mail]> wrote:
> 
>> 
>> On Dec 10, 2013, at 9:59 AM, Paul Kyzivat <[e-mail]> wrote:
>> 
>>> June 2014  Updated procedures for dual-stack server handling of SIP
>>>  URIs containing domain names
>> 
>> Before we use update, can someone tell me what normative text of the current RFCs need to be changed?
>> 
> 
> That's part of the problem, RFC 3263 is not very clear to me in indicating what exactly is normative. If you read our draft, you will see that we point to a few sections that clearly says that a UA needs to look up "A or AAAA" records, which has been proven wrong and doesn't follow the intention of the DNS SRV RFC. If this was unintentional or normative, I don't know, but it's written enough times to cause issues in implementations and have been copied to other documents, like the MSRP RFC.
> 
> We need to clarify that a SIP implementation needs to follow the DNS SRV RFC and look up all addresses for a host name (ipv4, IPv6 or future address families) and test them all before moving to the next priority and host.
> 
> I've checked this with members of the IETF DNS directorate two times now, and they agree with this.
> 
> When we clarified/updated/extended/informed the audience - developers - about this, we need to get down to how to connect - serially, in parallell, in reverse random order controlled by the phases of the moon or other planets - or simply Happy Eyeballs. But even with TCP, doing happy eyeballs like in HTTP would not work unless we have both A and AAAA records. RFC 3263 doesn't really indicate that.
> 
> Someone else needs to help out to clarify to me what is really normative in 3263 and what the relationship between 3263 and RFC 2782 really is - if RFC 2782 is the normative one and RFC 3263 just can be seen as a happy story that points to 2782 without making any normative changes, we might have to clarify that in an informational document and move on to connection setup in a dual stack world. If RFC 3263 changes the behaviour intended by 2782 and really forces a developer to select A or AAAA records, then we need to change that behaviour.
> 
> Either way, we have work to do in ths wg.
> /O