Change Details

Known issues: - `PhutilIPAddress` only supports IPv4. - `PhutilCIDRBlock` only supports IPv4. - 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. - Possibly need to deal with this junk in URIs? `http://[2001:db8:85a3:8d3:1319:8a2e:370:7348]/` - 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 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. - 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.

Known issues: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. - Possibly need to deal with this junk in URIs?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 store or write remote addresses in some cases: push loguse 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., user activity logimport a Macro from a host with a raw IPv6 address. - We use `gethostnamebyl()` to resolve hostnames, access log,but this can only resolve IPv4 addresses. SSH log.The failure mode is that these requests are rejected, These should be updated to use the preferred display form for addressesso this is safe, so `1::1` and `1:0::1` are not different addressesbut you can't import a Macro from an IPv6 host with no IPv4 address. For cluster support: - Not yet clear what issues may exist.