Change Details

There are three general parts to IPv6 support: - **Inbound Requests**: Accepting requests from clients using IPv6. For example, a user visits `https://phabricator.mycompany.com/` over IPv6. - **Outbound Requests**: Sending requests to IPv6 hosts. For example, a user tries to import a calendar event or an image macro from `https://ipv6-image-macros.com/cat.jpg`, where that host is IPv6-only. - **Intracluster Requests**: Running Phabricator in a cluster on hosts in IPv6-only mode. State of the world: | Request Type | Status | Notes |---|---|---| | **Inbound** | {icon check color=green} Supported | Phabricator should be able to receive requests from IPv6 clients. | **Outbound** | {icon times color=red} Mostly Not Supported | Phabricator can not make outbound HTTP requests to IPv6 hosts yet (SSH probably works). | **Intracluster** | {icon question color=blue} Unknown | No one expressed interest in running an IPv6-only cluster yet. At the time of writing (Dec 2016) we haven't seen requests for outbound or intracluster support, so we don't have active plans to pursue them in the near term. I expect to pursue them as IPv6 is more widely adopted. --- For inbound support: [x] `PhutilIPAddress` only supports IPv4. [x] `PhutilCIDRBlock` only supports IPv4. [x] Double-check for remaining callers to `ip2long()` + integer IP address storage, and/or short address fields in the database. I believe we removed all of these already in anticipation of IPv6 support. [x] We store or write remote addresses in some cases: push log, user activity log, access log, SSH log. These should be updated to use the preferred display form for addresses, so `1::1` and `1:0::1` are not different addresses. For outbound support: - Broadly, IPv6 URIs may appear in this general form: `http://[2001:db8:85a3:8d3:1319:8a2e:370:7348]/` - We use PHP's `parse_url()` in `PhutilURI`, which can not parse IPv6 addresses as raw hostnames in URIs. The failure mode is that these requests are rejected, so this is safe, but you can't, e.g., import a Macro from a host with a raw IPv6 address. - We use `gethostnamebyl()` to resolve hostnames, but this can only resolve IPv4 addresses. The failure mode is that these requests are rejected, so this is safe, but you can't import a Macro from an IPv6 host with no IPv4 address. For cluster support: - Not yet clear what issues may exist.

There are three general parts to IPv6 support: - **Inbound Requests**: Accepting requests from clients using IPv6. For example, a user visits `https://phabricator.mycompany.com/` over IPv6. - **Outbound Requests**: Sending requests from Phabricator to external IPv6 hosts. For example, a user tries to import a calendar event or an image macro from `https://ipv6-image-macros.com/cat.jpg`, where that host is IPv6-only. - **Intracluster Requests**: Running Phabricator in a cluster on hosts in IPv6-only mode. State of the world: | Request Type | Status | Notes |---|---|---| | **Inbound** | {icon check color=green} Supported | Phabricator should be able to receive requests from IPv6 clients. | **Outbound** | {icon times color=red} Mostly Not Supported | Phabricator can not make outbound HTTP requests to IPv6 hosts yet (SSH probably works). | **Intracluster** | {icon question color=blue} Unknown | No one expressed interest in running an IPv6-only cluster yet. At the time of writing (Dec 2016) we haven't seen requests for outbound or intracluster support, so we don't have active plans to pursue them in the near term. I expect to pursue them as IPv6 is more widely adopted. --- For inbound support: [x] `PhutilIPAddress` only supports IPv4. [x] `PhutilCIDRBlock` only supports IPv4. [x] Double-check for remaining callers to `ip2long()` + integer IP address storage, and/or short address fields in the database. I believe we removed all of these already in anticipation of IPv6 support. [x] We store or write remote addresses in some cases: push log, user activity log, access log, SSH log. These should be updated to use the preferred display form for addresses, so `1::1` and `1:0::1` are not different addresses. For outbound support: - Broadly, IPv6 URIs may appear in this general form: `http://[2001:db8:85a3:8d3:1319:8a2e:370:7348]/` - We use PHP's `parse_url()` in `PhutilURI`, which can not parse IPv6 addresses as raw hostnames in URIs. The failure mode is that these requests are rejected, so this is safe, but you can't, e.g., import a Macro from a host with a raw IPv6 address. - We use `gethostnamebyl()` to resolve hostnames, but this can only resolve IPv4 addresses. The failure mode is that these requests are rejected, so this is safe, but you can't import a Macro from an IPv6 host with no IPv4 address. For cluster support: - Not yet clear what issues may exist.

There are three general parts to IPv6 support: - **Inbound Requests**: Accepting requests from clients using IPv6. For example, a user visits `https://phabricator.mycompany.com/` over IPv6. - **Outbound Requests**: Sending requests tofrom Phabricator to external IPv6 hosts. For example, a user tries to import a calendar event or an image macro from `https://ipv6-image-macros.com/cat.jpg`, where that host is IPv6-only. - **Intracluster Requests**: Running Phabricator in a cluster on hosts in IPv6-only mode. State of the world: | Request Type | Status | Notes |---|---|---| | **Inbound** | {icon check color=green} Supported | Phabricator should be able to receive requests from IPv6 clients. | **Outbound** | {icon times color=red} Mostly Not Supported | Phabricator can not make outbound HTTP requests to IPv6 hosts yet (SSH probably works). | **Intracluster** | {icon question color=blue} Unknown | No one expressed interest in running an IPv6-only cluster yet. At the time of writing (Dec 2016) we haven't seen requests for outbound or intracluster support, so we don't have active plans to pursue them in the near term. I expect to pursue them as IPv6 is more widely adopted. --- For inbound support: [x] `PhutilIPAddress` only supports IPv4. [x] `PhutilCIDRBlock` only supports IPv4. [x] Double-check for remaining callers to `ip2long()` + integer IP address storage, and/or short address fields in the database. I believe we removed all of these already in anticipation of IPv6 support. [x] We store or write remote addresses in some cases: push log, user activity log, access log, SSH log. These should be updated to use the preferred display form for addresses, so `1::1` and `1:0::1` are not different addresses. For outbound support: - Broadly, IPv6 URIs may appear in this general form: `http://[2001:db8:85a3:8d3:1319:8a2e:370:7348]/` - We use PHP's `parse_url()` in `PhutilURI`, which can not parse IPv6 addresses as raw hostnames in URIs. The failure mode is that these requests are rejected, so this is safe, but you can't, e.g., import a Macro from a host with a raw IPv6 address. - We use `gethostnamebyl()` to resolve hostnames, but this can only resolve IPv4 addresses. The failure mode is that these requests are rejected, so this is safe, but you can't import a Macro from an IPv6 host with no IPv4 address. For cluster support: - Not yet clear what issues may exist.