Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added isreserved to validate reserved ASN numbers #3

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

biafra
Copy link

@biafra biafra commented Oct 15, 2018

A simple validation for completeness. Check if it's a reserved ASN number by:

RFC 7300 => 65535 and 4294967295
RFC 4893 => 23456

Thank you!

@lochiiconnectivity
Copy link
Owner

Thanks for the merge request.

"Reserved" is an interesting term, here you are only meaning it to include the definition of RFC4893/7300, but actually, RFC5398 "reserves" a block of ASN16 for documentation, and you could argue that the private range is also reserved (for private use) , you could also argue that zero is reserved because it can not be used.

I would rather if we had a reserved check, it checked for all of these as well (basically, anything that can't be used as a public AS number)

@biafra
Copy link
Author

biafra commented Oct 16, 2018

Thanks for the quick response! I was not aware of RFC5398. "Reserved" was more like "do not use these for anything". So, the private range was not to be include in this.

I have this necessity for validations of AS numbers in a provision tool and therefore I can accept public and private ASN. Just not the please-do-not-use ones.

What do you think of having a "ispublic" with all the ranges except: private and my previous idea of "reserved" ? So, we could validate AS number with ispublic and isprivate knowing it would ignore ranges from RFC 7300,4893 and 5398 (anyone missing?)

Thank you!

@lochiiconnectivity
Copy link
Owner

I'm not sure we could define public properly though, AS_TRANS , would that appear in there? it's neither private, nor public!

@biafra
Copy link
Author

biafra commented Oct 21, 2018

In terms of provision for instance 23456 should never be used! It's not a private one neither a "public" one. In terms of configuration it would always be an "automatic" conversion when you need it to configure a peer as number to a 32 bits asn from a 16 bits asn only router.

So, anyone could use "ispublic" and "isprivate" to guarantee the use of and allocation of AS numbers. For configurations audits of a network you just have to had AS_TRANS to the previous tests because you may have that AS number configured on your network. Or you don't add it if your AS domain network is full 32 bits!

Am I missing anything ?

@lochiiconnectivity
Copy link
Owner

Yes, I agree, I think what I'm saying is that I support the original idea of a method for checking if an ASN is reserved. Once we have this method, we can also have a method to check for public, which just needs to check if the ASN is not reserved or private (so it's a convenience method basically)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants