Allow more control over application server IP address specification

[eric-murray]

Problem description
Currently, the application server IP address(es) can be specified as a single IPv4 subnet and/or a single IPv6 subnet. For an established connection, where the application server IP address is already known, this is fine. Or if it intended to apply the QoS profiles to a whole subnet, this is also fine.

But if it is desired to create a QoS session that would apply to a connection once established between a device and a given application server, it is generally not possible to restrict the QoS session in advance to those IP addresses that the application server might use.

The device will be allocated the required application server IP address by DNS. It is normal for DNS entries to resolve to a small set of IP addresses (maybe 2 or 3), and DNS randomises the order in which these are returned to allow for load balancing.

So the possible set of IP addresses can be known in advance. But the QoS session can only be established in advance by specifying the minimum subnet that includes all possible IP addresses that the application server might use. This can be a very large subnet indeed.

Possible evolution
Allow more flexibility in specifying application server IP addresses by allowing an FQDN for application server to be specified, e.g.

  ...
  "applicationServer": {
    "fqdn": "example.com"
  },
  ...

This solution is non-breaking. In this case, all IP addresses returned by DNS for "example.com" would be included in the QoS session. Note that:

• the QoS profile would therefore apply to any application using these IP addresses, and not just example.com
• this solution also only works for application servers that have a public DNS entry.

Alternative solution
Alternatively, allow an array of IP subnets (IPv4 and/or IPv6) to be specified, e.g.

  ...
  "applicationServer": {
    "ipAddresses": ["2600:1406:5e00:6::17ce:bc1b","2600:1406:5e00:6::17ce:bc12","2600:1408:ec00:36::1736:7f31","2600:1408:ec00:36::1736:7f24","2600:1406:bc00:53::b81e:94ce","2600:1406:bc00:53::b81e:94c8","23.220.75.232/32","23.215.0.138/32","23.215.0.136/32","23.192.228.84/32","23.192.228.80/32","23.220.75.245/32"]
  },
  ...

This solution could be non-breaking (by keeping existing ipv4Address and ipv6Address options), or could be breaking by dropping these options.

Additional context