This repository has been archived by the owner on Apr 26, 2024. It is now read-only.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Default to the blacklisting reserved IP ranges. #8870
Default to the blacklisting reserved IP ranges. #8870
Changes from 2 commits
bab2732
9ccdd1d
d3d54e5
6a7991f
526dc0f
2896de2
5d38dc0
c7013fd
eeb3ef3
3cace62
d391a0d
107f2d2
1ad448b
ab996c9
b046db7
19b0964
df7885c
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not 100% sure where these came from? They seem to partially block "private" IP spaces, but not all, see https://github.com/netaddr/netaddr/blob/master/netaddr/ip/__init__.py#L1918-L1972 / RFC6890.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it was copied from the url_preview blacklist, which itself has evolved rather than being put together carefully (see #1198 for example). It might be a good time to consider if there are others we should add.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In addition to what is there we should probably add:
192.0.0.0/24
: IANA IPv4 Special Purpose Address Registry (RFC 5736)198.18.0.0/15
: Testing of inter-network communications between subnets (RFC 2544)0.0.0.0/8
: Broadcast message (RFC 1700)192.0.2.0/24
: TEST-NET examples and documentation (RFC 5737)198.51.100.0/24
: TEST-NET-2 examples and documentation (RFC 5737)203.0.113.0/24
: TEST-NET-3 examples and documentation (RFC 5737)I don't see why we would ever talk to multicast addresses:
239.0.0.0
-239.255.255.255
: Administrative Multicast224.0.0.0/4
: Multicast240.0.0.0/4
: Reserved for multicast assignments (RFC 5771)233.252.0.0/24
: Multicast test network234.0.0.0
-238.255.255.255
: Reserved multicast225.0.0.0
-231.255.255.255
: Reserved multicastff00::/8
: MulticastOnes we should modify:
fe80::/64
->fe80::/10
: link localOnes I'm unsure about:
192.88.99.0/24
: 6to4 anycast relays (RFC 3068)fec0::/10
: Site Local Addresses (deprecated - RFC 3879)ff00::/12
,::/8
,0100::/8
,0200::/7
,0400::/6
,0800::/5
,1000::/4
,4000::/3
,6000::/3
,8000::/3
,A000::/3
,C000::/3
,E000::/4
,F000::/5
,F800::/6
,FE00::/9
That's quite a big change though, what do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
generally I agree with adding all of those to the default value, but a few points:
0.0.0.0/32
is already special-cased (I can't quite remember the history there). Should we update that special-casing rather than add0.0.0.0/8
to the default here?::/8
there, given::1
is localhost)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe you're correct that those IPv6 addresses have just not been assigned yet, which is quite different.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like https://tools.ietf.org/html/rfc6890 is the proper reference to be using.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The list mentioned above looks sane to me.
IMO, we could and should add everything from the above lists, up to the "not yet assigned" addresses.
Regarding Site Local Addresses, RFC 3879 mentions that the block is not supposed to be reassigned except by future IETF action and that router implementations SHOULD prevent routing. Taking that into account, I don't see any downside in adding them to the default blacklist and it's nice from a defence in depth perspective, just in case there's a bad/old router implementation somewhere.
I think we can safely skip the "not yet assigned" addresses for now. On the topic of
::1
, I suppose the intent is that the entire::/8
block is unassigned, except for::1
which is treated as an exception and a special address.I can't think of anything else that should be added to the list at the moment.