Closed Bug 1190136 Opened 9 years ago Closed 8 years ago

Firefox should decide whether reuse connection separately for IPv4 and IPv6

Categories

(Core :: Networking: HTTP, defect)

Product:
Core
Component:
Networking: HTTP
Version:
38 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: iprok, Unassigned)

References

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0
Build ID: 20150802030602

Steps to reproduce:

Turn on spdy and ssl on the web-server. Tried nginx 1.6.2 and 1.8.0. Set up to virtual hosts (domain1 and domain2) on the same IP on this server.

Start fresh browser profile.

Check whether network.http.spdy.enabled.v3-1 is set to true.

Load https://domain1/
Load https://domain2/
and may be
click any link on domain2.


Actual results:

When firefox should make request for domain2, your web-server will receive request for domain1.
If you request domain2 first then requesting domain1 will send request for domain2.
If we turn network.http.spdy.enabled.v3-1 to false or change to any other browser (even FF on mobile) everything works ok.


Expected results:

Requests should go for correct domains.
It have begun after updating to firefox 38.1 (I use only ESR versions). Reverting back to 31.8 fixes the problem. I've tried on linux and OS X. Issue also exists on FF 39 version.
I can't reproduce this on any (nginx) server I know, that supports SPDY.
Please try to reproduce using a new profile: https://support.mozilla.org/kb/profile-manager-create-and-remove-firefox-profiles

If you can still reproduce, you should try mozregression (https://mozilla.github.io/mozregression/) to find the exact change for your issue.

If you can't reproduce any more, you should check your settings and Add-Ons.
Some more info: 
Issue exists only when using ipv6. Turning off ipv6 on client helps.
if I use shift+reload page right domain is requested. But if I follow some link without shift+reload the issue returns.
I have tried on purely clean profiles on three OSes: windows 7, linux and OS X.

I can't repeat it on pure static vhosts, may be it somehow depends on cookies. But you can watch the issue on my server in such way:

Load 
https://test1.web-dev.pro - you should have page of the first site.
https://test2.web-dev.pro - you should have page of the second site.
https://redmine.web-dev.pro - you should get our redmine, if you get http-auth - it's already wrong vhost requested, try shift-reload. After visiting it the first and the second site can also begin to give me redmine or http-auth from another domain.
 5:47.69 LOG: MainThread Bisector INFO Narrowed nightly regression window from [2015-02-04, 2015-02-07] (3 days) to [2015-02-06, 2015-02-07] (1 days) (~0 steps left)
 5:47.70 LOG: MainThread Bisector INFO Got as far as we can go bisecting nightlies...
 5:47.70 LOG: MainThread Bisector INFO Last good revision: 7c5f187b65bf
 5:47.70 LOG: MainThread Bisector INFO First bad revision: f8ce4cf2e71d
 5:47.70 LOG: MainThread Bisector INFO Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=7c5f187b65bf&tochange=f8ce4cf2e71d

 5:47.70 LOG: MainThread Bisector INFO ... attempting to bisect inbound builds (starting from 4 days prior, to make sure no inbound revision is missed)
 5:49.88 LOG: MainThread Bisector INFO Getting inbound builds between 940118b1adcd and f8ce4cf2e71d
 6:45.52 LOG: MainThread Bisector INFO No inbound data found.
 6:45.52 LOG: MainThread Bisector INFO There are no build artifacts on inbound for these changesets (they are probably too old).

And I've simplified way to reproduce:
1) You should have ipv6 enabled on client
2) You should have network.http.spdy.enabled.v3-1 enabled (default) in your browser
3) Try https://redmine.web-dev.pro - should get redmine bug tracker.
4) Try https://mon.web-dev.pro - should get http auth to zabbix. If you get also redmine - you've reproduced issue and request was not sent to mon.web-dev.pro but to redmine.web-dev.pro.
Summary: Firefox requests incorrect domain when using SSL with SPDY 3.1 → Firefox requests incorrect domain when using SSL with SPDY 3.1 and IPv6
Most likely to be this commit https://hg.mozilla.org/mozilla-central/rev/5d7317e09ea1 , but I have not enough skill to revert it and try.
There was a change in bug 1129571 that might be relevant.
But I can't reproduce the issue here.
(In reply to sjw from comment #6)
> There was a change in bug 1129571 that might be relevant.
> But I can't reproduce the issue here.

You can't reproduce with ipv6 enabled and working or you have no ipv6?
I can discuss and make as much support as possible using xmpp - the same jid as my email.
If it's needed I can give access to virtual machine with ipv6 and firefox to reproduce the issue.
I'm using 6to4.
Can you reproduce with other browsers or have you tried curl?
(In reply to sjw from comment #9)
> I'm using 6to4.
> Can you reproduce with other browsers or have you tried curl?

6to4 under certain circumstances make ip6 less preferred then ip4 so seems that you're using ip4 to access to my server. Try https://test1.web-dev.pro/ip , it will give your ip4-address to you if I'm right.

I can't reproduce in any other browsers: chromium, konqueror, rekonq, curl, wget and so on. It only happens in FF and after revision that I point earlier.
I need you to look carefully at the spdy requests - the full origin is contained in each one (the host, port, and scheme). Are the wrong requests being made entirely, or are you just surprised which connections you are seeing those requests on?

I suspect it is the latter and you are seeing the spdy coalescing logic. If those hosts share an IP address and they are using SSL certs which are valid for each other (i.e. a wildcard, or both are listed through SAN) then the spdy logic lets you treat the servers as authoritative for both origins (and again, the request fully defines the origin).

Shift reload helps because it closes existing connections.

I just looked at test1.web-dev.pro, test2, and redmine and they all share the same IP address and use a certificate valid for *.web-dev.pro so I would expect them to be coalesced like you're seeing.

That's a feature - it saves you handshake time when you've already got an open spdy connection. You need to route by the full origin (again, included in the request) to make it work. If you wish to opt out, then either give each service a different address or give them certificates that are not valid for each other.

Starting in firefox 40 you can also return a "421" http error code in the case that you receive a request that you are not authoritative for and firefox will retry that request on a fresh connection.

https://groups.google.com/forum/#!topic/spdy-dev/UW0_X2GaMSQ
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → INVALID
(In reply to Patrick McManus [:mcmanus] from comment #11)
> I need you to look carefully at the spdy requests - the full origin is
> contained in each one (the host, port, and scheme). Are the wrong requests
> being made entirely, or are you just surprised which connections you are
> seeing those requests on?
> 
> I suspect it is the latter and you are seeing the spdy coalescing logic. If
> those hosts share an IP address and they are using SSL certs which are valid
> for each other (i.e. a wildcard, or both are listed through SAN) then the
> spdy logic lets you treat the servers as authoritative for both origins (and
> again, the request fully defines the origin).

I will look to headers more closely. But if you were right then
1) such issue was also with ipv4 but it's only with ipv6.
2) chromium, which is made by google, who also made SPDY doesn't have the issue with ipv6. 
So it seems that only firefox behaves so and it's behaviour is incorrect.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
the history around this in spdy is a little fuzzy (because spdy's documentation was an evolving project) but this has been codified in rfc 7540 section 9.1.1 and that was meant to reflect the spdy logic.
One more thing: most of the time issue happens with redmine.web-dev.pro which incorrectly loads mon.web-dev.pro and they have different IPv6 adresses (on the same web-server).
I've made double check with wireshark enabled. I can't (or don't know how to) watch hostname in SNI  headers cause I use DH and wireshark can't decrypt it even with server key. But dest ipv6-addresses are so:
1) The first request: https://redmine.web-dev.pro (*:2::7), all requests are done by FF to *:2::7.
2) The second request: https://mon.web-dev.pro (*:2::3), all requests are done by FF to *:2::7 also.

Even I can't see SNI headers I think Patrick is wrong.
(In reply to Ivan from comment #14)
> One more thing: most of the time issue happens with redmine.web-dev.pro
> which incorrectly loads mon.web-dev.pro and they have different IPv6
> adresses (on the same web-server).

from where I sit those two hosts have the same v4 address. Having a single overlapping address (of any type) is enough to identify them as poolable. (the fact that a different address is used is orthogonal and rather random.) They all use the same wildcard cert for *.web-dev.pro

(In reply to Ivan from comment #15)
> I've made double check with wireshark enabled. I can't (or don't know how
> to) watch hostname in SNI  headers cause I use DH and wireshark can't
> decrypt it even with server key. But dest ipv6-addresses are so:
> 1) The first request: https://redmine.web-dev.pro (*:2::7), all requests are
> done by FF to *:2::7.
> 2) The second request: https://mon.web-dev.pro (*:2::3), all requests are
> done by FF to *:2::7 also.

the fact that they are on the same connection should not be a problem (they satisfy the pooling requirements) - the origin is fully identifiable by the :host HEADER included in each one.
(In reply to Patrick McManus [:mcmanus] from comment #16)
> (In reply to Ivan from comment #14)
> > One more thing: most of the time issue happens with redmine.web-dev.pro
> > which incorrectly loads mon.web-dev.pro and they have different IPv6
> > adresses (on the same web-server).
> 
> from where I sit those two hosts have the same v4 address. Having a single
> overlapping address (of any type) is enough to identify them as poolable.
> (the fact that a different address is used is orthogonal and rather random.)
> They all use the same wildcard cert for *.web-dev.pro

Ok. I've tried competely removed ipv4 from web-server configs to make them not have overlapping adress (removed listen line for ipv4 adress from nginx.conf). Just the same issue. You don't mean that DNS A record shows the same IPv4 for them both, do you?

> 
> (In reply to Ivan from comment #15)
> > I've made double check with wireshark enabled. I can't (or don't know how
> > to) watch hostname in SNI  headers cause I use DH and wireshark can't
> > decrypt it even with server key. But dest ipv6-addresses are so:
> > 1) The first request: https://redmine.web-dev.pro (*:2::7), all requests are
> > done by FF to *:2::7.
> > 2) The second request: https://mon.web-dev.pro (*:2::3), all requests are
> > done by FF to *:2::7 also.
> 
> the fact that they are on the same connection should not be a problem (they
> satisfy the pooling requirements) - the origin is fully identifiable by the
> :host HEADER included in each one.

So, you want to tell me that firefox can send request to completely wrong IP just because that IP have correct certificate?
I've made a workaround: put all important virtual hosts to the same ipv6. But it's still workaround. 

I've read rfc 7540 section 9.1.1. I got the words:
> For TCP connections without TLS,
>   this depends on the host having resolved to the same IP address.

>   For "https" resources, connection reuse additionally depends on
>   having a certificate that is valid for the host in the URI.

Anyway it seems to be a huge problem and IPv6 addresses resolved should obviously be pooled separately from IPv4 addresses.

Seems that all other browsers do so.
Summary: Firefox requests incorrect domain when using SSL with SPDY 3.1 and IPv6 → Firefox should decide whether reuse connection separately for IPv4 and IPv6
So just once more correction for description of how to repeat:
1) Make two subdomains pointing for same ipv4 address (DNS A record) and different ipv6 addresses (DNS AAAA record).
2) Turn on two virtual hosts or even separate servers with SPDY with SSL with the same wildcard certificate valid to both of the subdomains. _Use only IPv6, no IPv4 in your web-server configs_.
3) Try to load the first subdomain, FF will do request to it's IPv6 address with correct 'host' field
4) Try to load the second, FF will reuse connection (because both subdomains resolve to the same IPv4 !) and send request to IPv6 address of the first subdomain with 'host' field of the second subdomain.

I wish to underscore once more that only Firefox after changes pointed early behaves so strange.
> You don't mean that DNS A record shows the
> same IPv4 for them both, do you?
> 

dig mon.web-dev.pro

; <<>> DiG 9.9.5-9ubuntu0.2-Ubuntu <<>> mon.web-dev.pro
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14534
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 8192
;; QUESTION SECTION:
;mon.web-dev.pro.		IN	A

;; ANSWER SECTION:
mon.web-dev.pro.	1800	IN	A	144.76.202.239

;; Query time: 242 msec
;; SERVER: 192.168.16.9#53(192.168.16.9)
;; WHEN: Tue Aug 04 08:30:34 EDT 2015
;; MSG SIZE  rcvd: 60

/home/mcmanus/src/mozilla2/wd/mozilla-inbound>dig redmine.web-dev.pro

; <<>> DiG 9.9.5-9ubuntu0.2-Ubuntu <<>> redmine.web-dev.pro
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21024
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 8192
;; QUESTION SECTION:
;redmine.web-dev.pro.		IN	A

;; ANSWER SECTION:
redmine.web-dev.pro.	1800	IN	A	144.76.202.239

;; Query time: 171 msec
;; SERVER: 192.168.16.9#53(192.168.16.9)
;; WHEN: Tue Aug 04 08:30:43 EDT 2015
;; MSG SIZE  rcvd: 64
(In reply to Ivan from comment #18)
> 
> Anyway it seems to be a huge problem and IPv6 addresses resolved should
> obviously be pooled separately from IPv4 addresses.
> 

please help me understand your argument more. I don't understand why the version of IP used to contact the server makes a distinction here. If two servers both advertise a particular address, then they are advertising the same route and a link has been established - the certificate is used to ensure that they have permission to do so. I understand pooling in general makes some people uncomfortable at a high level, but I don't understand the v4/v6 specific concern at all. 

The core reason for this feature is to "undo" sharding used for http/1 and migrate the web to fewer connections.
(In reply to Patrick McManus [:mcmanus] from comment #20)
> 
> dig mon.web-dev.pro
> 
> ;; ANSWER SECTION:
> mon.web-dev.pro.	1800	IN	A	144.76.202.239
> redmine.web-dev.pro.	1800	IN	A	144.76.202.239

I've already get it after more closely reading of RFC. But it doesn't affect anything I've written after comment 18. What about separating IPv4 and IPv6 resolving while deciding whether reuse addresses. It seems completely illogical. 

> I don't understand why the version of IP used to contact the server makes a distinction here.

Version of IP doen't matter. But IPv6 and IPv4 should be separated. Do you clearly get that now FF decide what IPv6 address to use because of DNS A record of two hostnames are similar (I remember about the same cert, but let's try to discuss situation with SSL being forgotten)? It seems completely logical for me that two IP versions should be separated. If I use IPv6 and origin(s) has ipv6 I will not use IPv4 to make connection. Why do IPv4 take place in decision what IPv6 to use? I can have completely different IPv6 and IPv4 configuration of my hosts?

Just to be 100% clear: I just think that FF should not take care about any DNS A records while using IPv6 connection and vice versa - not care about DNS AAAA while using IPv4.

Just imagine situation (without SSL): 
1) I have some SPDY but not SSL site mydomain.org (I can according the standart).
2) I don't use IPv6 having A record for my domain (for example 1.2.3.4) and AAAA (1:2:3:4)
3) Some bad guy makes baddomain.org pointing to 1.2.3.4 (which doesn't belongs to bad guy but me) and 1:2:10:20 (which belongs to bad guy).
4) Using current logic if IPv6-enabled-client just visits somehow baddomain.org (fishing link or something) and then my domain, then all requests to my site on 1:2:3:4 will go to 1:2:10:20 with all sensitive data.
Yes, if I want to take sensitive data from my users I should give them SSL, but this world is not yet ideal so there are a lot of users and servers without SSL.
Oops, please read point 2 as:
2) I have A record for my domain (for example 1.2.3.4) and AAAA (1:2:3:4)
This is definitely a bug. Firefox should not pool different domains with different IPv6 addresses if the connection goes via IPv6, based on same IPv4 addresses. This is completely illogical.
Any progress here? Under some circumstances it makes SPDY completely unusable and even dangerous.
I'm going to wontfix this based on the previous discussion; but I'd like to make sure you also know about http respoonse code 451. That can be used if you do get a request on host you don't want to authoritatively respond for it (even though its in possession of a certificate for it). That will cause the request to be replayed on a new connection without pooling. hth.
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago → 9 years ago
Resolution: --- → WONTFIX
Patrick, please look at the following example :

host_1.domain.com  resolving to IP_1 and IP_2
host_2.domain.com  resolving to IP_1 (only)

Both hosts are sharing the same wildcard SSL certificate.

Scenario :

1) opening https://host_1.domain.com/ and FF connects to the host using IP_2 address
2) now in the same window trying to open https://host_2.domain.com, but for some reason FF decides to reuse connection to IP_2, which is obviously WRONG, because it doesn't belong to host_2.domain.com

Just to clarify, IP_2 is v6 address and IP_1 is v4, but it shouldn't matter at all, because IP version should be irrelevant (as you mentioned before).


Current behaviour of FireFox is extremely dangerous - basically it can be easily exploited allowing to hijack any website or facilitate man-in-the-middle attacks.
Reopenning this bug cause not only me thinks that it's serious issue in firefox.
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
I feel like this is well discussed. This is not a mitm issue - the certificates are enforced and there are multiple ways to control the routing in the way you would like including 421 and not using wildcard certificates for a host that is not authoritative for the whole wildcard.
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago → 8 years ago
Resolution: --- → WONTFIX
It's not well discussed cause (and it's pity) you don't listen to anybody with opposite opinion. The usage of wildcard certificate isn't real reason to break RFC that tells us that "For TCP connections without TLS,
   this depends on the host having resolved to the same IP address. ... For "https" resources, connection reuse _additionally_ depends on
   having a certificate that is valid for the host in the URI." and IPv4 and IPv6 are completely different IPs to unite them in your way.

Tell please how can we discuss the issue with some other developers of firefox? I think if it's really not the issue as you try to tell us than it will not be the problem.
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
the hosts in comment 27 do resolve to the same IP, IP_1. The RFC language says "resolve" it does not say "connect" and this is important. There are a number of load balancing services which leverage this property.. e.g. img1{A,B,C} img2{C,D,E} can be pooled together even on an existing connection to A assuming that connection covers img2 with an appropriate cert.

What's important here is that each request contains a full uri (which it does as this is only done with h2/spdy) and that the server can declare that misdirected with 421 and/or prevent it by using a more narrow certificate. Certs are free from letsencrypt so that's a pretty reasonable thing to do on a host that doesn't really serve the whole wildcarded domain.

The big picture is that names and certificates are more and more defining content, not ip addresses. pooling, alt-svc, proxies, etc are all playing a role in building a more scalable content centric network.

please don't change bugzilla flags unless you're working on the code. Thanks.

the dev-tech-network google group would be a place to discuss this if you'd like another forum.
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago → 8 years ago
Resolution: --- → WONTFIX
Patrick,

I'm sorry, but what you are saying doesn't makes any sense.  How it can be "Ok" for a browser to use connection to IP_2 for accessing web site if IP_2 doesn't listed neither as A or AAAA record in DNS for that host ?

Multiple web sites may share some IP addresses, especially on a shared Web hosting and/or in many different scenarios.

For example, Host_1 is heavy loaded web site, therefore it's have multiple A / AAAA records to load-balance the traffic.    

Host_2 have much less load, therefore hosted on just 1 host, which happens to be "shared" with Host_1

Server configuration is out of the scope as users might not be under control of web site owner or domain administrator.

I don't know what do you mean by "control the routing" (I don't see how routing is related at all to the issue), but advise forcing web server to answer "421" is pretty much like asking somebody else to work around your problem.

mozilla.org doesn't responds with "421" if asked to serve "google.com" page, why other's should ?

curl -I -k --resolve "google.com:443:63.245.215.20" https://google.com:443/
HTTP/1.1 403 Forbidden
Server: Apache
X-Backend-Server: bedrock4.webapp.scl3.mozilla.com


Here is another example for mitm:

User has Corporate CA installed in browser (as part of Enterprise policy, for example). Many corporates using Corporate CA for whatever reasons.

Step 1: Someone creates wildcard cert for *.com domain signed by this CA (for whatever reason, which might be legitimate)

Step 2: Attacker creating multiple AAAA records for a host "lets_hack_them.com", one of them pointing to a landing page on HACKERS_IP address (with cert installed), and another A record  similar to Google.com IP address (216.58.214.206 for example)

If user with FireFox browser will visit "lets_hack_them.com", then all future requests to "google.com" will be actually intercepted by attacker because FF will "reuse" connection to a rogue web site just because somebody added fake A record to "lets_hack_them.com" DNS zone ?

Why to allow browser sending request to an IP address which does NOT belong to a server in a first place ? Why you expect 3rd party web server to reply with "421" for requests to "google.com" domain, for example ?
By the way, you are clearly in violation of RFC 7540 Section 9.1.1

A connection can be reused as long as the origin server
   is authoritative (Section 10.1).  For TCP connections without TLS,
   this depends on the host having resolved to the same IP address

I'm sure "the same IP address" means the SAME IP address that you are connected to already.  Not just "another shared IP address"
Hi Yuri,

about "routing" I apologize for being unclear. I am referring to http level (l7) request routing - not packet routing. There are lots of times requests are routed to hosts other than what the origin defaults would imply - that doesn't make it wrong. Proxies are the obvious example. Alt-Svc is another example and the spdy/http2 coalescing we are talking about here is a third.

(In reply to Yuri from comment #32)
> Patrick,
> 
> I'm sorry, but what you are saying doesn't makes any sense.  How it can be
> "Ok" for a browser to use connection to IP_2 

because three opt-in conditions are met - h2, certificate coverage, and dns configuration.

> 
> mozilla.org doesn't responds with "421" if asked to serve "google.com" page,
> why other's should ?

mozilla.org uses a certificate valid for www.mozilla.org and mozilla.org only. A connection to it for google.com, if for example DNS was compromised, would fail at the TLS level. Mozilla cannot obtain a certificate for google.com from a CA in the PKI.

DNS is not part of the security model of the web. Nor is IP routing. They are both necessary for stuff to work, but if attacked (and they are insecure after all) the security of https:// should not be compromised.

> 
> curl -I -k --resolve "google.com:443:63.245.215.20" https://google.com:443/

because you used the -k option, and disregarded the certificate configuration, that is not a variant of https that firefox will speak. If you lose the -k the transaction will fail correctly - that is a security failure not a case of misdirection.

> 
> Here is another example for mitm:

in summary - you are trusting a CA that is sharing its private keys with an attacker. That's going to get you owned. Your focus is on the mechanics of that happening via a DNS configuration and http/2 instead of hijacking DNS or TCP routing - but all of those things are equally untrusted. The security breach happened when you trusted a CA that shared its keys with the attacker (perhaps they are one in the same?) - which untrusted pawn was maneuvered to seal the deal is not really interesting because another one can always be found.


(In reply to Yuri from comment #33)
> By the way, you are clearly in violation of RFC 7540 Section 9.1.1
> 
> A connection can be reused as long as the origin server
>    is authoritative (Section 10.1).  For TCP connections without TLS,
>    this depends on the host having resolved to the same IP address
> 
> I'm sure "the same IP address" means the SAME IP address that you are
> connected to already.  Not just "another shared IP address"

The word is resolved. That's not a mistake - resolution returns sets.
Two questions then.

1) If you sure you read RFC right, why FF is the ONLY browser that behaves like that ?

2) Assuming you are right - why FF does NOT behave the same in pure IPv4 configuration ?  Why this behaviour is enforced only in mixed IPv6 + IPv4 ?

   Following your logic you must implement the same flow for IPv4 only environment.

You examples for "alternative" are not clear.
In case of proxy it's either SPECIFIC configuration made by a user or "transparent" proxy, which actually hijacks the traffic - out of the scope here.

For ALT-SVC  destination is advertised by the ORIGINAL host, which is authoritative. Besides, "Clients MUST have reasonable assurances that the alternative service is under control of and valid for the whole origin".
hi - re 1 I can't really speak for other implementations other than to say they all seem within the bounds of standards to be.

re 2 - the same thing does indeed happen in all v4 (or should) - there is nothing in that algorithm that is even aware of whether the addresses are v4, v6, or mixed.
(In reply to Patrick McManus [:mcmanus] from comment #36)

Ok.

Same RFC, Section 9.1

Clients SHOULD NOT open more than one HTTP/2 connection to a given
   host and port pair, where the host is derived from a URI, a selected
   alternative service [ALT-SVC], or a configured proxy.


host_1.domain.com  resolving to IP_1 and IP_2
host_2.domain.com  resolving to IP_1 (only)


The only "host and port pair" that can derive from a host uri https://host_2.domain.com/  is IP_1:443, so FF should not reuse it's existing connection to IP_2
the language you are referring to discourages making additional connections - it is not convincing to cite it as evidence that we should be making additional connections :)

in any event I disagree with your interpretation of derived.
You need to log in before you can comment on or make changes to this bug.