Support of RFC9164 Semantic Tags for IP Addresses/Prefixes

[kc2rxo]

Things to check first

• I have searched the existing issues and didn't find my feature already requested there

Feature description

RFC9164 changes the semantic tags for IP Addresses and prefixes. See the RFC for specific details.

TLDR: Instead of 260 and 261 there is now semantic tags 52 (for IPv4) and 54 (for IPv6). Each tag supports a combination of full address and prefix forms. The originals are deprecated.

Use case

IANA has, per RFC9164, marked the original semantic tags as deprecated in favor of the RFC9164 tags.

While I am unsure of how much these new tags are used in the wild, I am currently proposing their use in various documents for the Drone Remote ID Protocol (DRIP). For some examples see this document, Section 9 and Appendix A.

[agronholm]

I think these new tags are a perfect fit for the ipaddress module.

[kc2rxo]

I've done a little bit of work on this, just to see how this could be done before integration and have come up with the following code:

import cbor2
import ipaddress

ip4a = ipaddress.IPv4Address("192.0.2.1")
ip4n = ipaddress.IPv4Network("192.0.2.0/24")
ip4n_pl = ip4n.prefixlen
ip4n_addr = ip4n.network_address.packed[:int(ip4n_pl / 8)]

ip4_addr = cbor2.CBORTag(52, ip4a.packed)
ip4_pfix = cbor2.CBORTag(52, [ip4n_pl, ip4n_addr])
ip4_iface = cbor2.CBORTag(52, [ip4a.packed, 24, 'eth0'])

print(ip4_addr)
print(ip4_pfix)
print(ip4_iface)

ip6a = ipaddress.IPv6Address("2001:0db8:1234:deed:beef:cafe:face:feed")
ip6n = ipaddress.IPv6Network("2001:db8:1234::/48")
ip6n_pl = ip6n.prefixlen
ip6n_addr = ip6n.network_address.packed[:int(ip6n_pl / 8)]

ip6_addr = cbor2.CBORTag(54, ip6a.packed)
ip6_pfix = cbor2.CBORTag(54, [ip6n_pl, ip6n_addr])
ip6_iface = cbor2.CBORTag(54, [ip6a.packed, 56, 'eth1'])

print(ip6_addr)
print(ip6_pfix)
print(ip6_iface)

It should be worth noting that the interface (ipX_iface) definition the zone element (final element) can be either a string, integer or not present at all. The order of the array elements dictates the form you are encoding/decoding.

On the topic of the optional zone identifier, how would this be handled? It looks like the scope_id of ipaddress.IPv6Address is what would be expected but I have never seen or used this function before. The ipaddress documentation doesn't even mention it for IPv4Address. Perhaps it could be ignored for now and only the address and prefix forms of RFC9164 are supported?

To match the examples in RFC9164 I had to extract the address manually from the CIDR notation and perform a slice of the packed address to remove excess value not required in CBOR, thus resulting in the ipX_addr values. This is probably bad practice but I do not see a clean way to get the value required from ipaddress objects.

Obviously the CBORTag's above would be used in a call of encode_semantic() resulting in the desired bytes for the new tags.

[kc2rxo]

@agronholm -- is there any preference or desire for this still?

I can get a PR together for the address and prefix forms of RFC9164 but still unsure the best way to handle the interface form.

[agronholm]

Yeah, I'm interested, just haven't had the bandwidth for this project.

[kc2rxo]

Let me pull a PR together then to get some review on with that I can do then maybe some discussion can occur around the support of the interface form.

[agronholm]

Can you enlighten me about that problem? It's not obvious to me from reading the earlier messages in this issue.

[kc2rxo]

So the interface form has the following options (examples taken from RFC9164):

54([h'fe8000000000020202fffffffe030303', 64, 'eth0'])
54([h'fe8000000000020202fffffffe030303', 64, 42])
54([h'fe8000000000020202fffffffe030303', null, 42])

Where the first element is the packed address as a bstr, the second element is the prefix length as a uint or null and the third element is a zone identifier being either a uint or a tstr.

This maps directly to the IPv4Interface and IPv6Interface objects of ipaddress to obtain the first two elements. The zone ID is the scope_id and only part of the IPv6Address object and only as a string not integer. See: https://docs.python.org/3/library/ipaddress.html.

Hence my original opinion that this library for now only supports the Address and Network forms until the ipaddress module supports the use of scope_id in IPv4 per RFC4001. We also have the question of the optionality of the prefix length, I believe that the IPv*Network classes require a prefix length, thus would never be null in case a user of this library wants it to be. This particular option might be moot and just inaccessible without building the tag yourself.

[agronholm]

So your examples would map to:

• IPv6Interface("fe80:0000:0000:0202:02ff:ffff:fe03:0303%eth0/64")
• IPv6Interface("fe80:0000:0000:0202:02ff:ffff:fe03:0303%42/64")
• IPv6Interface("fe80:0000:0000:0202:02ff:ffff:fe03:0303%42")

So is there a problem with encoding or decoding these objects?

[kc2rxo]

I guess the question I am asking is do we only support the use of this form for IPv6 only then?
That is fine with me and can be documented as such.

[agronholm]

Scope IDs are not a thing on IPv4?

[kc2rxo]

Not according to the current documentation in the ipaddress module no.

[agronholm]

OK so let me change the question: is there a raw tag value we would not know how to properly decode?

[kc2rxo]

If the decoder obtained an IPv4 interface tag, we would have to drop the zone_id as the ipaddress module doesn't currently support it.

Otherwise the decoder should have no issues mapping into the ipaddress module objects.

If that behavior is fine I can go ahead and make the PR for this adding encoder/decoder support.

[agronholm]

I very much doubt anyone reasonably expects an IPv4 interface tag with a zone id to translate to anything useful, so ignoring it is perfectly valid.