Closed hildjj closed 5 years ago
Better parsing for the options is welcome. Not sure about parsing the CIDR in this module. I'd suggest returning just the parsed string instead (I'd like to eventually get rid of the ip
dependency because it is unmaintained and for the IPv6 case, full of bugs).
Nod, I'm ok pushing the CIDR calculation to the caller, and just using the sourcePrefixLength to select the number of IP bytes to send.
I wonder if it's worth starting a new project to replace ip
. Seems like a thing that's needed.
Light usage of ip
like this is fine.
Yes, a ip/cidr library similar to Python's netaddr
is on my wishlist as well. So far, I've been keeping on top of things using https://github.com/whitequark/ipaddr.js and https://github.com/silverwind/cidr-tools mostly.
ipaddr.js
at least appears to be actively maintained and have unit tests.
Anything else you'd like to see on this before I send a PR? Want it squashed?
README
needs to be updated with the new format. Also left a comment on the option names. Other than that, I'd say go ahead and submit.
Better support for "popular" EDNS0 options from the IANA list. I've the start of a patch for ECS that allows this:
on parse, you get this:
note that the data field is retained for backward compatibility.
If this approach makes sense and is interesting to the maintainers, I'll send a PR eventually with support for all of the options in the IANA list that have RFCs that are clear enough to make sense to me, including tests.