Why Do Your v6 Connectivity Differ from v4?
Dear colleagues, Today I'd like to talk to you as a co-author of ASPA documents c [1] <https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-verification/> [2] <https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-profile/> which may greatly affect your operations. Of course, changing it for the better. Long story short: ASPA (autonomous system provider authorization) is a proposed RPKI object, that should greatly narrow the gap in routing security by adding the opportunity to verify AS_APTH and detect route leaks and AS_PATH manipulations. To make it work, you will need to create an ASPA record that represents a set of your upstream providers plus non-transparent RS. Now let's jump to the question that has already resulted in a holy war in the IETF mailing list. These days, for some strange reasons, networks may be dual-stacked. One might expect that upstream providers would be the same for v4 and v6, if the corresponding providers were also dual-stack. This statement is true for the majority of networks. However, a significant number of AS have different sets of providers in v4 and v6. I would be very grateful if engineers responsible for operating such a network could share their insights into whether it is just a mistake, whether it was done on purpose, or whether my model of peering relations produces incorrect results. To make life easier, here is a link <https://docs.google.com/spreadsheets/d/1MgoD64dBI-2yZhrz77RIf38osKpRl4e-wRkLOVN_qi0/edit?usp=sharing> to a Google spreadsheet. It shows customer-provider pairs from v4 that don't exist (or at least not visible) in v6. If you find your AS (or AS of your best friend!) in the 'Customer' column please share your story via email or catch me or Job Snijders in person during the RIPE meeting. As a final part of my motivation speech, I would like to remind you that routing security is not a burden of one or two enthusiasts, it always was and always will be a joint success or joint failure. -- Best regards, Alexander Azimov
On May 21, 2024, at 6:17 AM, Alexander Azimov <a.e.azimov@gmail.com> wrote:
Dear colleagues,
Today I'd like to talk to you as a co-author of ASPA documents c [1] [2] which may greatly affect your operations. Of course, changing it for the better.
Long story short: ASPA (autonomous system provider authorization) is a proposed RPKI object, that should greatly narrow the gap in routing security by adding the opportunity to verify AS_APTH and detect route leaks and AS_PATH manipulations.
To make it work, you will need to create an ASPA record that represents a set of your upstream providers plus non-transparent RS. Now let's jump to the question that has already resulted in a holy war in the IETF mailing list.
These days, for some strange reasons, networks may be dual-stacked. One might expect that upstream providers would be the same for v4 and v6, if the corresponding providers were also dual-stack. This statement is true for the majority of networks.
However, a significant number of AS have different sets of providers in v4 and v6. I would be very grateful if engineers responsible for operating such a network could share their insights into whether it is just a mistake, whether it was done on purpose, or whether my model of peering relations produces incorrect results.
To make life easier, here is a link to a Google spreadsheet. It shows customer-provider pairs from v4 that don't exist (or at least not visible) in v6. If you find your AS (or AS of your best friend!) in the 'Customer' column please share your story via email or catch me or Job Snijders in person during the RIPE meeting.
As a final part of my motivation speech, I would like to remind you that routing security is not a burden of one or two enthusiasts, it always was and always will be a joint success or joint failure.
I think that there’s also a perspective issue, it’s important that resources like RIPE RIS and Route-views get both v4 and v6 feeds from the community so it’s feasible to understand what the topology looks like. Some of this can be determined through RIPE Atlas and others can not, but the more views allows a much better understanding of the ecosystem. I have one provider I don’t use for outbound (for example) because they have a provider that is too strict with BCP-38 and would cause customer complaints as a consequence. - Jared
participants (2)
-
Alexander Azimov -
Jared Mauch