Subject: [dispatch] draft-johansson-sip-dual-stack: reason to alter RFC 3263?

From: Brett Tate <[email-masked]>
Date: Mon, 24 Jun 2013 11:10:10 +0000

Hi,

Concerning draft-johansson-sip-dual-stack, my comment is that the draft should provide better justification to alter RFC 3263.

As indicated within section 4, SRV records can be used to better control if both IPv6 and IPv4 should be tried prior to the next set of IPv6 and IPv4 addresses.  As far as I know, the main reason to alter RFC 3263 would be for a better experience when SRV is not supported.  What are the other reasons?

There are various SRV, A, and AAAA DNS combinations already deployed based upon RFC 3263.  Is the draft going to provide guidelines about the transition from devices/networks based upon RFC 3263 to those based upon the draft?

For instance if the network is currently configured to attempt A or AAAA to device before advancing to next SRV location, this draft would cause the dual stack device to attempt both A and AAAA before advancing to next SRV location; this could introduce unintended extra delays during call setup.  How would the dual stack device know if the DNS configuration was based upon RFC 3263 or this draft?

Thanks,
Brett

This email is intended solely for the person or entity to which it is addressed and may contain confidential and/or privileged information. If you are not the intended recipient and have received this email in error, please notify BroadSoft, Inc. immediately by replying to this message, and destroy all copies of this message, along with any attachment, prior to reading, distributing or copying it.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 24 Jun 2013 13:18:48 +0200

> As indicated within section 4, SRV records can be used to better control if both IPv6 and IPv4 should be tried prior to the next set of IPv6 and IPv4 addresses.  As far as I know, the main reason t…
To prepare for a happy-eyeballs solution. Right now if a device looks up IPv6 and not IPv4 it may fail miserably.  The "or" should not be there.

We've proven at SIPit that UAs have no failover or a 32 second (64*T1) timeout before retrying with another address family. To be able to fail over to the other network flow, you need to resolve the addresses.

> There are various SRV, A, and AAAA DNS combinations already deployed based upon RFC 3263.  Is the draft going to provide guidelines about the transition from devices/networks based upon RFC 3263 to…
It doesn't change the records, it change how the UA looks them up.

> 
> For instance if the network is currently configured to attempt A or AAAA to device before advancing to next SRV location, this draft would cause the dual stack device to attempt both A and AAAA before advancing to next SRV location;
Yes.

> this could introduce unintended extra delays during call setup.
How?

>  How would the dual stack device know if the DNS configuration was based upon RFC 3263 or this draft?
I don't follow you here.  What's the difference in DNS configuration?

Are you suggesting that if we're in the situation that forced Happy Eyeballs - a working IPv4 and an IPv6 tunnel that is closed by the firewall we should try IPv6, fail, then move to the next priority when the DNS publishes both A and AAAA records for the name we're looking up?

The "how to set up a connection" issues will be targeted by a separate draft. We do need to look into a Happy Eyeballs solution for UDP and have so far not succeeded. Any help is appreciated.

/O

> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: Brett Tate <[email-masked]>
Date: Mon, 24 Jun 2013 12:47:03 +0000

> > As indicated within section 4, SRV records can be used 
> > to better control if both IPv6 and IPv4 should be tried 
> > prior to the next set of IPv6 and IPv4 addresses.  As 
> > far as I know, the main reason to alter RFC 3263 would 
> > be for a better experience when SRV is not supported.
> > What are the other reasons?
>
> To prepare for a happy-eyeballs solution. Right now if a 
> device looks up IPv6 and not IPv4 it may fail miserably.  
> The "or" should not be there.
>
> We've proven at SIPit that UAs have no failover or a 
> 32 second (64*T1) timeout before retrying with another 
> address family. To be able to fail over to the other 
> network flow, you need to resolve the addresses.

If the device cannot failover, the device still cannot failover after this becomes an RFC unless the reason was because it did not support SRV.

The slow failover is not unique to IPv6 switch to IPv4.  It can occur during the failover between IPv4 addresses.  Many vendors use a timer to failover more quickly; if needed, the timer can become standardized for use.

> > There are various SRV, A, and AAAA DNS combinations 
> > already deployed based upon RFC 3263.  Is the draft 
> > going to provide guidelines about the transition from 
> > devices/networks based upon RFC 3263 to those based
> > upon the draft?
>

It changes how they get used.  More specifically, it would alter the attempted order of where requests get sent.

For instance, DNS SRV, AAAA, and A results indicate to try 1) Bv4 or Bv6, 2) Cv4, and 3) Bv4.  Assuming number 1 was because of the RFC 3263 "A or AAAA record lookup" snippet that is being changed by this draft, the attempted order changes because of the draft to be 1) Bv4 or Bv6, 2) Bv4 or Bv6, 3) Cv4, and 4) Bv4.

NOTE: the above reflects the DNS results without the optimization to bypass a previously tried location.  With the optimization, there would be no "4) Bv4".

> >  How would the dual stack device know if the DNS 
> > configuration was based upon RFC 3263 or this draft?
>

The difference is attempted order (and potentially number of locations) based upon the SRV, AAAA, and A results.

> Are you suggesting that if we're in the situation that 
> forced Happy Eyeballs - a working IPv4 and an IPv6 tunnel 
> that is closed by the firewall we should try IPv6, fail, 
> then move to the next priority when the DNS publishes both 
> A and AAAA records for the name we're looking up?

Per RFC 3261, yes it moves to the next SRV record of the same or lower priority.  This may or may not be the same attempted order and number of locations that are being caused the draft.

If the admin knows that the failure is typically caused by maintenance or overload, why would they want to try both AAAA and A to the same server before advancing to the next server?  The admin would need to adjust the DNS configuration per the draft to produce the same desired result they were getting with RFC 3263.

Thanks,
Brett

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 24 Jun 2013 14:57:33 +0200

> For instance, DNS SRV, AAAA, and A results indicate to try 1) Bv4 or Bv6, 2) Cv4, and 3) Bv4.  Assuming number 1 was because of the RFC 3263 "A or AAAA record lookup" snippet that is being changed…
I've left it quite open - deliberately - in this draft how the connections should happen, since I believe that has to be solved in another document. Maybe that's wrong.

I do believe we need to use a Happy Eyeballs-like solution so that we connect
to 1) Bv4 and Bv6, 2 Cv4, 3 Bv4

The problem with http was that it took 19 seconds for a web browser to try another address family. 
In SIP, with default timers (which hopefully is not used), it will take 32 seconds. This is definitely not a happy situation.

> The difference is attempted order (and potentially number of locations) based upon the SRV, AAAA, and A results.
Assuming that we don't try IPv4 and IPv6 at the same time.

> If the admin knows that the failure is typically caused by maintenance or overload, why would they want to try both AAAA and A to the same server before advancing to the next server?  The admin wou…
YOu are assuming that the AAAA and A records are the very same server. That may not be the case at all.

Thanks for your feedback. Much food for thought.
/O