Variable address prefix length?

[banburybill]

• Section 7.5.3: It's very good that the BlockTables "ip-address" items can be truncated by prefix length, but we have actually run into cases that call for /variable/ truncation (i.e., more precision in some subnets than in others), especially true given that a single table holds both client and server address data. What would you think about representing addresses not as direct byte strings, but rather as variable-length arrays or maps—index 0 encoding the prefix as a byte string, and optional index 1 (when present) encoding a prefix-length override? Or, if the extra size per address is too much, at least allowing such representations via polymorphism (byte string for default prefix-length, array/map for non-default)?

https://mailarchive.ietf.org/arch/msg/dnsop/OADqnhAq-Q3GA9JVde1JDmvLNwo

[banburybill]

Extra size on each address is too much of a penalty on our main anticipated use cases.

Polymorphism is an interesting idea. It does (space-wise) penalise the prefix length override option, but if this is required feels a promising approach. The question is whether there is demand for this use case to justify the additional complexity. It could be implemented as a custom extension for closed systems.

So far we've not had other feedback on this suggestion following our comments on the list or the WG at IETF101. We've therefore not attempted to incorporate this into the latest draft.

[banburybill]

• This format in its present state can work for my organization, but the second gap in particular means we'll be manually hacking around those deficiencies by e.g. representing 192.0.2.0/24 as 192.0.2.0/32 in order to fully specify 198.51.100.42/32.

https://mailarchive.ietf.org/arch/msg/dnsop/in-7bC5T7NHkaMfWuUSQFoyQQCg