Right. In fact "data destruction" itself can be implemented as "encryption" plus "throwing-away-the-key" plus (importantly!) "throwing-away-the-plaintext." If you don't throw away the plaintext after encryption, you're really missing an important step. ;)
"IP anonymization" is kind of a subset of "data destruction." We want to destroy some of the information — like, "is this address 127.0.0.2?" — but we want to preserve some of it — like, "is this one address in the same /24 subnet as this other one?". That's because we want to be able to say things like, "50% of our traffic comes from a single /24. Its anonymized name in this dataset is 28.238.72.0/24; we can't tell you what its real name is because we anonymized that away."
If your threat model includes things like "We really want not to be able to say things like that about our dataset," then obviously you should not use (only) anonymization. Because the whole point of anonymization is precisely to preserve the ability to say things like that about subnet structure, while anonymizing away the real addresses.
Perhaps it should have been called "IP pseudonymization." I would have said that ship has sailed, but after googling "ip pseudonymization" it seems like maybe precise terminology is trying to make a comeback due to things like the GDPR.
> In the General Court’s opinion [...] the identifiability of the data subject should be assessed taking into account the concrete possibilities of the third-party recipient to identify data subjects. As such, when sharing pseudonymous data, the same must be considered anonymous if the recipient has no means to re-identify data subjects.
> [S]ince the third-party recipient did not have access to the additional information capable of identifying the data subjects, nor could it in any way have acquired such access, the transmitted data should be considered anonymous data and not pseudonymous data.
