Subject: [v6ops] ULA and IPv4 - draft-liu-v6ops-ula-usage-analysis

From: Christopher Palmer <[email-masked]>
Date: Tue, 5 Nov 2013 02:50:27 +0000

Section 3.3 of the draft:

"  As described in section 2.2.2 of [RFC5220]<http://tools.ietf.org/html/rfc5220#section-2.2.2>, when an enterprise has

   IPv4 Internet connectivity but does not yet have IPv6 Internet

   connectivity, then the enterprise chose ULA for site-local IPv6

   connectivity. Each employee host will have both an IPv4 global or

   private address and a ULA. Here, when this host tries to connect to

   an outside node that has registered both A and AAAA records in the

   DNS, the host will choose AAAA as the destination address and the ULA

   for the source address according to the IPv6 preference of the

   default address selection policy [RFC3484<http://tools.ietf.org/html/rfc3484>]. This will clearly result
   in a connection failure."

This is only true if the ULA is configured on a host that also has a default route The enterprise can avoid any issues by simply configuring a scoped route on hosts (say, only for the ULA prefix). If a network does not provide connectivity to the IPv6 Internet, it should not advertise ::/0.

I think it's useful to discuss that configuration route, which is possible today with a vast majority of hosts and just works.

Modifying the prefix policy table is not suitable at scale. And the DNS preference logic alluded to in section 3.3 is highly ambiguous.

---

From: Tim Chown <[email-masked]>
Date: Tue, 5 Nov 2013 02:58:50 +0000

The 3484’s in that chunk of text should be 6724’s.

Tim

On 5 Nov 2013, at 02:50, Christopher Palmer <[email-masked]> wrote:

> “  As described in section 2.2.2 of [RFC5220], when an enterprise has
>    default address selection policy [RFC3484]. This will clearly result
>    in a connection failure.”
>  
> I think it’s useful to discuss that configuration route, which is possible today with a vast majority of hosts and just works.
>  
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Christopher Palmer <[email-masked]>
Date: Tue, 5 Nov 2013 03:10:45 +0000

The majority of in-the-wild hosts are running 3484, so as an operational document I think it's reasonable to discuss the issue as it exists with those machines.

Even with 6724 - hosts configured as described in 3.3 may still attempt a ULA -> Native IPv6 connection. That connection will just not be preferred over IPv4 -> IPv4.

I'd argue that's still non-ideal. If the enterprise hosts in question do not have access to the IPv6 Internet, they should not be configured with a default route - thus they would *never* attempt connectivity.

Overprovisioning effective IPv6 connectivity is a painful topic.
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tim Chown
Sent: Monday, November 4, 2013 6:59 PM
To: [email-masked]
Subject: Re: [v6ops] ULA and IPv4 - draft-liu-v6ops-ula-usage-analysis

The 3484's in that chunk of text should be 6724's.

Tim

On 5 Nov 2013, at 02:50, Christopher Palmer <[email-masked]<mailto:[email-masked]>> wrote:

Modifying the prefix policy table is not suitable at scale. And the DNS preference logic alluded to in section 3.3 is highly ambiguous.
_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Mark ZZZ Smith <[email-masked]>
Date: Tue, 5 Nov 2013 11:32:58 -0800 (PST)

>________________________________
> From: Christopher Palmer <[email-masked]>
>To: Tim Chown <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Tuesday, 5 November 2013 2:10 PM
>The majority of in-the-wild hosts are running 3484, so as an operational document I think it’s reasonable to discuss the issue as it exists with those machines. 
> 
>Even with 6724 – hosts configured as described in 3.3 may still attempt a ULA -> Native IPv6 connection. That connection will just not be preferred over IPv4 -> IPv4. 
> 
>I’d argue that’s still non-ideal. If the enterprise hosts in question do not have access to the IPv6 Internet, they should not be configured with a default route – thus they would *never* attempt connectivity.
> 

Even if the hosts do have a default route, the network shouldn't (or at some point shouldn't). At that point, the router should generate an ICMPv6 Destination Unreachable, which will cause the host to switch to IPv4.

I tested this a few years ago and the switch over was both sub-second and not noticeable (under Linux with Firefox and/or Chrome).

I think where people might be thinking this is a bigger issue an it is is because there was one particular IPv6 CPE that didn't generate ICMP Destination Unreachables when it didn't have IPv6 Internet connectivity. This showed up around the time of RFC6204 being finalised, and I think people didn't completely realise it was an implementation issue, rather than a flaw in IPv6 operation.

One thing that could influence this switch over performance is ICMPv6 Destination Unreachable rate limiting on the originating router. Assuming for the moment that ICMPv6 behaviour is the same as ICMPv4s in this regard, it might be worth either advising to raise the rate specifically for ICMPv6 Destination Unreachables, and perhaps revising the ICMPv6 RFCs to have a higher rate specifically for ICMPv6 Destination Unreachables.

ICMPv6 Destination Unreachables are fundamentally unreliable though, which is why I think the happy-eyeballs approach is much better, and should be used in more applications. I really agree with Fred Baker's draft:

Happier Eyeballs
http://tools.ietf.org/html/draft-baker-happier-eyeballs-00.html

Regards,
Mark.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 6 Nov 2013 04:37:21 +0900

> http://tools.ietf.org/html/draft-baker-happier-eyeballs-00.html

Great. We can't be bothered to get things right in the network, so we just
tell hosts to try everything all the time in the hope that something will
work.

It's very easy to say "we should just have smarter algorithms", especially
if we expect that someone other than ourselves will be writing those
algorithms, but I have yet to see a proposal that's sanely implementable,
high performance, and low load (even considering the fact that you'd have
to completely overhaul the socket API and app the apps using it before you
could deploy it).

---

From: Mark Andrews <[email-masked]>
Date: Wed, 06 Nov 2013 07:25:43 +1100

In message <CAKD1Yr1qqTDdzAcmhUL=dA86DG=HyjDU=[email-masked]>
> tell hosts to try everything all the time in the hope that something will

While devices should return unreachables we all know that there are
error conditions where that does not happen even when they are
configured to do so.  If you have multihomed servers then the clients
should be failing over faster than they tradionally have.  We spend
BILLIONS dealing with clients that do not fall over fast enough.

> to completely overhaul the socket API and app the apps using it before you

You can have fast failover using the current socket APIs.  For TCP
is is relatively trivial, just use a non-blocking connect call.
For UDP it is a little harder but not impossible.  DNS servers have
been dealing with multihomed services for decades.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mark ZZZ Smith <[email-masked]>
Date: Tue, 5 Nov 2013 12:26:47 -0800 (PST)

> From: Lorenzo Colitti <[email-masked]>
>To: Mark ZZZ Smith <[email-masked]> 
>Cc: Christopher Palmer <[email-masked]>; Tim Chown <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Wednesday, 6 November 2013 6:37 AM
>On Wed, Nov 6, 2013 at 4:32 AM, Mark ZZZ Smith <[email-masked]> wrote:
>
>Happier Eyeballs
>Great. We can't be bothered to get things right in the network, so we just tell hosts to try everything all the time in the hope that something will work.
>

Networks can lose packets, regardless of whether they're IPv4 or IPv6.

I don't think the problem happy eyeballs is solving isn't really any different to the problem where multiple IPv4 A records are returned and a client has to walk through them until it succeeds. Fortunately that seems to be reliable enough that end users don't have to wait for connection timeouts as the returned list of A records is walked through. But if they were (are?) waiting, then happy-eyeballs for only IPv4 would also be beneficial.

The happy eyeballs technique could be considered to be another form of retransmission to recover from packet loss. A host has to recover from packet loss whether it is within a single protocol, or across multiple ones used by and for the same application.

>
>It's very easy to say "we should just have smarter algorithms", especially if we expect that someone other than ourselves will be writing those algorithms, but I have yet to see a proposal that's sanely implementable, high performance, and low load (even considering the fact that you'd have to completely overhaul the socket API and app the apps using it before you could deploy it).
>

I think Multipath TCP fills that gap, as it is transparent to applications, unless they start directly dealing with IPv4/IPv6 addresses. I think the combination of Multipath TCP and happy-eyeballs at initial MPTCP connection establishment (to bring up multiple subflows concurrently) would be even better.

Regards,
Mark.