Make application server network configuration more restrictive

[ilya-smirnov-berlin]

Problem description

The current API allows configuring the application server network with prefixes of any size.
As a result, an API consumer can set 0.0.0.0/0 or ::/0 without specifying ports. In this case, the selected QoD profile applies to all uplink and downlink traffic, regardless of the actual application.

This creates problematic behavior when the API consumer does not make a reasonable effort to identify a specific application server (for example, by resolving a domain name or configuring a sufficiently narrow network prefix).

Issues

1. End-user confusion

 When multiple applications share the same QoD-affected traffic, users may not understand why unrelated applications are influenced by a QoD profile intended for a single service.

2. Conflicts between API consumers

 If different API consumers (e.g. different companies) create QoD sessions for the same device, and one of them uses the entire address space or a very large network segment, other consumers may receive QoD conflict errors.
The current QoD implementation detects overlapping network filters between sessions and rejects configurations that are ambiguous.

Possible evolution

The documentation should explicitly restrict the allowed size of the application server network.

Proposed maximum network sizes:

• IPv4: /16 (65 536 addresses)
• IPv6: /32 (2^96 addresses)

This would encourage consumers to properly identify application servers while reducing unintended traffic sharing and session conflicts.

[jlurien]

Indeed 0.0.0.0/0 would mean all traffic or any destination, so the Qos Profile is applied to all traffic for the specified device. It would be equivalent to make applicationServer optional and define that when it is not specified, the QoS profile applies to all traffic. So far, this is allowed and afaik is what many consumers fill in the request. We should discuss if we'd like to forbid or restrict this behaviour at the API spec level.

[eric-murray]

The issue is that, if the API consumer wants to prioritise traffic to more than one application server IP address, where at least one is in the bottom half of the address space and at least one in the top half of the address space, then they currently have no choice but to request a /0 subnet, even where they only require as few as 2 application server IP addresses to be prioritised.

[ilya-smirnov-berlin]

This case with "distant" IPs can be covered by enabling ip address lists in #522

[eric-murray]

This case with "distant" IPs can be covered by enabling ip address lists in #522

OK. Let's wait until #522 is finalised before progressing this issue.

[eric-murray]

If the changes proposed for #522 are accepted, my proposal here would be to remove support for subnets completely (i.e. remove the existing ipv4Address and ipv6Address properties completely).

IPv4 subnets between /28 and /31 can be specified as a list of individual IP addresses in the new ipAddresses list. The maximum allowed size of that list could be increased if necessary.

I do not see any significant public internet use cases that require use of larger application server subnets, but can see that this might be a requirement for private networks, and there might be an IPv6 use case I am not aware of.