[
https://issues.apache.org/jira/browse/TS-1307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13411487#comment-13411487
]
Alan M. Carroll edited comment on TS-1307 at 9/19/12 7:12 AM:
--------------------------------------------------------------
The goal of this effort is to provide a higher degree of transparency for
connections through ATS, specifically so that connections to the origin server
can use (if possible) the same IP address family as the client connection.
To do this requires two parts, a configuration effort which permits
administrators control over the family selection logic for origin server
connections and the underlying implementation which makes this possible.
CONFIGURATION
For configuration there are three options of use to administrator - use IPv4,
use IPv6, or use the same family as the client connection. In addition the
ability to control the fail over from one of these to another is important. The
administrator is therefore provided three preferences (IPv4, IPv6, client)
which can be combined in a preference ordering. ATS then tries the families in
the order specified until success or all alternates have failed. For instance
the ordering "client;ipv4;ipv6" means try the family of the client connection
first, then IPv4, then IPv6, and then fail if none of those were successful. It
is presumed that connection to the origin server is the normal priority. For
this reason any ordering is extended by default to contain IPv4 followed by
IPv6 if these have not been specified. Therefore the ordering "client" is
functionally identical to "client;ipv4;ipv6" and the ordering "client;ipv6" is
equivalent to "client;ipv6;ipv4". This avoids problems with naive
administrators.
For administrators in more demanding environments it will not always be the
case that all of these options are valid, a special option "only" is provided
to terminate the ordering. For example the ordering "client;only" means try the
client connection family and if that does not work, fail. The ordering
"client;ipv4;only" means try IPv6 only for client connections that use it,
otherwise use only IPv4.
Note that only the first three preferences in an ordering are considered - any
preference beyond that is irrelevant as all possibilities will have been tried
before then.
To configure there a new global option is provided in records.config
'proxy.config.hostdb.ip_resolve'. The value is a string containing the
preference keywords "ipv4", "ipv6", "client", "only" separated by semi-colons,
to specify a preference ordering. This becomes the global default. If not
specified the global default "ipv4;ipv6;only" is used, which is the current
behavior. Beyond this the HTTP server port descriptor has been augmented to
have the keyword "ip-resolve" which uses the same string as the global option
to specify the same behavior for that port.
IMPLEMENTATION
The current version of HostDB has a single entry with a single address for each
host. The original work on IPv6 support simply changed the entry from IPv4 data
to a union that can contain an IPv4 or IPv6 address. The limitation of a single
address for a specific host remained. This presents a problem for supporting
client influence on the address family of the server connection if the origin
server supports both IP address families are both used by clients. The
implementation of HostDB and DNS had to be modified, the former quite
extensively, in addition to quite a lot of code cleanup.
At the implementation level the "client" preference is irrelevant, as any
actual client connection is IPv4 or IPv6. Therefore host name resolution is
trying one of these, then failing or trying the other. The client connection
address family servers only to select which of those four possibilities is
selected. This leads to two related but distinct types, the preference ordering
which is used for configuration logic, and the host resolution style which is
used to perform host name resolution.
* A set of types was added to describe a preference ordering, with types for
the preference and a type for the ordering. Two global defaults were added, one
which is read only to represent the built in default, and one modifiable to
store the value from the configuration. The later is initialized from the
hardwired default and updated if the configuration option is present.
* RecHttp and associated files were updated to support parsing and use of the
IP family preference ordering. The global option was added along with per
HttpProxyPort data to enable overrides per port. This data is passed through
the HttpAccept class to the HttpClientSession class. It is in HttpAccept the
change is made from a preference ordering to a resolution style because that is
the earliest point at which the client connection family is known and there is
no point in carrying the obsolete preference ordering further.
* Plugin API support was added to access the host resolution style in the
HttpClientSession. It can be retrieved and set to control the resolution on a
per transaction basis. A convenience function to set the transaction resolution
style from a preference ordering to a resolution style was added to provide
flexibility to the plugin implementation.
* The DNS resolution was changed to no longer fall back from one IP family to
another.
* HostDB was extensively modified.
** The SRV support was generalized to have four values - SRV, IPV4, IPV6, and
GENERIC, the latter serving to represent anything not of the first three types.
This in effect creates 4 spaces in the HostDB. This was judged to be a superior
solution to changing the HostDB records to contain per family addresses.
** Name resolution now attempts to resolve for a particular family, storing
this result in the HostDB. If that fails it restarts with the other family if
so configured. This takes advantage of the HostDB storing negative returns. For
instance if the resolution style is IPv6;IPv4 and a specific host has no IPv6
address the resolution will (after the first attempt) fail immediately for IPv6
and retrieve the IPv4 address without DNS processing. Note that the resolution
style is passed down per HostDB request, it is no longer retrieved from the
global configuration data directly by HostDB.
** The implementation required quite a bit of cleanup in the HostDB logic to
work. The largest changed involved the MD5 hash used as a GUID for each HostDB
entry. This was generated in multiple places from data that "happened" to be
available. More than one function had a large number of arguments simply to
make this available in unexpected places. To prevent chaos this data was
gathered up in to a single structure which can be passed around en masse,
making it much easier to ensure it is available where needed.
** Several class with complex construction / initialization were changed to
take Option structures instead of very long argument lists. This has worked
well for other classes which take numerous arguments of which only a subset are
used at any specific invocation. Arguments that were required for all
invocations were left as is and not placed in the options structure.
** The DNS interface from HostDB appears to only support IPv4. This is an
illusion caused by the overloading of the query type passed down. It is used
not only for IPv4 vs. IPv6 but also for T_PTR and T_SRV requests. Rather than
creating more complex logic at the call sites, the query type T_A is used for
both IPv4 and IPv6 requests and overridden during initialization based on the
host resolution style value in the options structure. This is admittedly
confusing but judged to be less so than other alternatives.
** Some instances of IpEndpoint were changed to IpAddr to reduce impedance in
situations where only the address was used.
** A few apparently unused functions / methods were removed.
** Const correctness was improved as needed.
** The HostDB version was changed.
ISSUES
* The implementation of the DNS timeout value is very ucnlear to me. While the
implementation suggests that it can be changed per transaction / DNS request,
it seems to be copied in to a global variable which is used for timeout checks.
* Although quite a bit of code redundancy was eliminated there is no small
amount remaining. Given the likely changes over the next 6 months it is
unlikely to be worth cleaning this up.
* The implementation of HostDBContinuation::refresh_MD5 was found by trial and
error. It seems like this will be a bad spot during testing.
NOTES
* The previous support for influencing the origin server address family was
completely non-functional. The configuration value was not set up in
RecordsConfig.cc and so was never read. It was removed without concern for
backwards compatibility as it is not any more broken now than it was then.
was (Author: amc):
The goal of this effort is to provide a higher degree of transparency for
connections through ATS, specifically so that connections to the origin server
can use (if possible) the same IP address family as the client connection.
To do this requires two parts, a configuration effort which permits
administrators control over the family selection logic for origin server
connections and the underlying implementation which makes this possible.
CONFIGURATION
For configuration there are three options of use to administrator - use IPv4,
use IPv6, or use the same family as the client connection. In addition the
ability to control the fail over from one of these to another is important. The
administrator is therefore provided three preferences (IPv4, IPv6, client)
which can be combined in a preference ordering. ATS then tries the families in
the order specified until success or all alternates have failed. For instance
the ordering "client;ipv4;ipv6" means try the family of the client connection
first, then IPv4, then IPv6, and then fail if none of those were successful. It
is presumed that connection to the origin server is the normal priority. For
this reason any ordering is extended by default to contain IPv4 followed by
IPv6 if these have not been specified. Therefore the ordering "client" is
functionally identical to "client;ipv4;ipv6" and the ordering "client;ipv6" is
equivalent to "client;ipv6;ipv4". This avoids problems with naive
administrators.
For administrators in more demanding environments it will not always be the
case that all of these options are valid, a special option "only" is provided
to terminate the ordering. For example the ordering "client;only" means try the
client connection family and if that does not work, fail. The ordering
"client;ipv4;only" means try IPv6 only for client connections that use it,
otherwise use only IPv4.
Note that only the first three preferences in an ordering are considered - any
preference beyond that is irrelevant as all possibilities will have been tried
before then.
To configure there a new global option is provided in records.config
'proxy.config.hostdb.ip_resolve'. The value is a string containing the
preference keywords "ipv4", "ipv6", "client", "only" separated by semi-colons,
to specify a preference ordering. This becomes the global default. If not
specified the global default "ipv4;ipv6;only" is used, which is the current
behavior. Beyond this the HTTP server port descriptor has been augmented to
have the keyword "ip-reslve" which uses the same string as the global option to
specify the same behavior for that port.
IMPLEMENTATION
The current version of HostDB has a single entry with a single address for each
host. The original work on IPv6 support simply changed the entry from IPv4 data
to a union that can contain an IPv4 or IPv6 address. The limitation of a single
address for a specific host remained. This presents a problem for supporting
client influence on the address family of the server connection if the origin
server supports both IP address families are both used by clients. The
implementation of HostDB and DNS had to be modified, the former quite
extensively, in addition to quite a lot of code cleanup.
At the implementation level the "client" preference is irrelevant, as any
actual client connection is IPv4 or IPv6. Therefore host name resolution is
trying one of these, then failing or trying the other. The client connection
address family servers only to select which of those four possibilities is
selected. This leads to two related but distinct types, the preference ordering
which is used for configuration logic, and the host resolution style which is
used to perform host name resolution.
* A set of types was added to describe a preference ordering, with types for
the preference and a type for the ordering. Two global defaults were added, one
which is read only to represent the built in default, and one modifiable to
store the value from the configuration. The later is initialized from the
hardwired default and updated if the configuration option is present.
* RecHttp and associated files were updated to support parsing and use of the
IP family preference ordering. The global option was added along with per
HttpProxyPort data to enable overrides per port. This data is passed through
the HttpAccept class to the HttpClientSession class. It is in HttpAccept the
change is made from a preference ordering to a resolution style because that is
the earliest point at which the client connection family is known and there is
no point in carrying the obsolete preference ordering further.
* Plugin API support was added to access the host resolution style in the
HttpClientSession. It can be retrieved and set to control the resolution on a
per transaction basis. A convenience function to set the transaction resolution
style from a preference ordering to a resolution style was added to provide
flexibility to the plugin implementation.
* The DNS resolution was changed to no longer fall back from one IP family to
another.
* HostDB was extensively modified.
** The SRV support was generalized to have four values - SRV, IPV4, IPV6, and
GENERIC, the latter serving to represent anything not of the first three types.
This in effect creates 4 spaces in the HostDB. This was judged to be a superior
solution to changing the HostDB records to contain per family addresses.
** Name resolution now attempts to resolve for a particular family, storing
this result in the HostDB. If that fails it restarts with the other family if
so configured. This takes advantage of the HostDB storing negative returns. For
instance if the resolution style is IPv6;IPv4 and a specific host has no IPv6
address the resolution will (after the first attempt) fail immediately for IPv6
and retrieve the IPv4 address without DNS processing. Note that the resolution
style is passed down per HostDB request, it is no longer retrieved from the
global configuration data directly by HostDB.
** The implementation required quite a bit of cleanup in the HostDB logic to
work. The largest changed involved the MD5 hash used as a GUID for each HostDB
entry. This was generated in multiple places from data that "happened" to be
available. More than one function had a large number of arguments simply to
make this available in unexpected places. To prevent chaos this data was
gathered up in to a single structure which can be passed around en masse,
making it much easier to ensure it is available where needed.
** Several class with complex construction / initialization were changed to
take Option structures instead of very long argument lists. This has worked
well for other classes which take numerous arguments of which only a subset are
used at any specific invocation. Arguments that were required for all
invocations were left as is and not placed in the options structure.
** The DNS interface from HostDB appears to only support IPv4. This is an
illusion caused by the overloading of the query type passed down. It is used
not only for IPv4 vs. IPv6 but also for T_PTR and T_SRV requests. Rather than
creating more complex logic at the call sites, the query type T_A is used for
both IPv4 and IPv6 requests and overridden during initialization based on the
host resolution style value in the options structure. This is admittedly
confusing but judged to be less so than other alternatives.
** Some instances of IpEndpoint were changed to IpAddr to reduce impedance in
situations where only the address was used.
** A few apparently unused functions / methods were removed.
** Const correctness was improved as needed.
** The HostDB version was changed.
ISSUES
* The implementation of the DNS timeout value is very ucnlear to me. While the
implementation suggests that it can be changed per transaction / DNS request,
it seems to be copied in to a global variable which is used for timeout checks.
* Although quite a bit of code redundancy was eliminated there is no small
amount remaining. Given the likely changes over the next 6 months it is
unlikely to be worth cleaning this up.
* The implementation of HostDBContinuation::refresh_MD5 was found by trial and
error. It seems like this will be a bad spot during testing.
NOTES
* The previous support for influencing the origin server address family was
completely non-functional. The configuration value was not set up in
RecordsConfig.cc and so was never read. It was removed without concern for
backwards compatibility as it is not any more broken now than it was then.
> Enable using client IP family for server connection
> ---------------------------------------------------
>
> Key: TS-1307
> URL: https://issues.apache.org/jira/browse/TS-1307
> Project: Traffic Server
> Issue Type: Improvement
> Components: Configuration, Network
> Affects Versions: 3.3.0
> Reporter: Alan M. Carroll
> Assignee: Alan M. Carroll
> Priority: Trivial
> Labels: dns, ipv6, net
> Fix For: 3.3.1
>
>
> Enable the IP address family of the client connection to control the IP
> address family of the server connection. Currently it can only be set
> globally to always prefer IPv4 or IPv6. This should be changed to preserve
> those options and add the ability to prefer the same family as the client
> connection. This should be configurably globally and be able to be overridden
> by port configuration and the plugin API.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
