Extended communities can solve the problem for all ASNs issued today or likely to be issued in a very long time (at least 24 bits, more like 30 bits IIRC) even if Large communities are not widely supported yet. Extended communities are ubiquitous in most of the gear I’m familiar with.
Owen > On Feb 6, 2018, at 10:27 , Chris Woodfield <[email protected]> wrote: > > RFC8092 was published roughly a year ago. I can’t imagine that we’ll see > universal support for it anytime soon, and there’s plenty of gear out there > on the internet today that won’t be getting a software update to support it. > > I have encountered exactly this scenario, albeit on a private network, but I > can’t imagine this not being a real-world issue for multiple operators with > public 32-bit ASNs. > > -C > >> On Feb 6, 2018, at 10:08 AM, Owen DeLong <[email protected]> wrote: >> >> >>> On Feb 6, 2018, at 09:02 , [email protected] wrote: >>> >>> I agree that IP addresses and ASN's are not associated with each other to >>> the extent that changes in one, must trigger a change in the other. Thus, >>> I disagree that an ASN transfer must only occur on "clean" ASNs without any >>> associated IP networks. >>> >>> For example, I might have an ASN because I am multihomed. If at some >>> future date, I decide that I will from now on only use one upstream, I no >>> longer require an ASN. In that case, I could either return or transfer if >>> permitted my ASN to another organization who needs it, and nothing would >>> link that transfer to any IP resources that I hold. >>> >>> Based on comments, it appears that even with the technical progress in >>> making all the various systems work with a 32 bit ASN, cases still exist >>> that certain routing features only work properly with a 16 bit ASN. Thus >>> the proposal to allow transfers was in part to allow those needing a 16 bit >>> ASN to obtain one from someone who is not using it. >> >> I continue to hear this claim, but so far nobody has actually provided a >> real example of this. >> >> With the advent of LARGE communities (not to be confused with Extended >> communities), even the most pathologically perverse case of this issue has >> been solved. >> >>> If we decide to allow ASN transfers in the ARIN region, I do not think it >>> needs to be linked in any way to IP resource holdings. >> >> We already allow ASN transfers in the ARIN region. The question at hand is >> allowing ASN transfers into/out of the ARIN region from/to other RIRs. >> >> Owen >> >>> >>> Albert Erdmann >>> Network Administrator >>> Paradise On Line Inc. >>> >>> >>> >>> On Thu, 1 Feb 2018, Job Snijders wrote: >>> >>>> On Thu, Feb 01, 2018 at 06:21:06PM +0000, Roberts, Orin wrote: >>>>> You could, but then IPv6 routing/fragmentation becomes an issue. >>>> >>>> How so? >>>> >>>>> Unless when an ASN is transferred from ARIN all IP networks associated >>>>> to that ASN are revoked/removed/deleted from ARIN. ie. I can acquire >>>>> an ASN that currently exists at ARIN minus any associated IP networks, >>>>> move it to APNIC/RIPE, then associate IP networks from APNIC/RIPE. >>>>> >>>>> ~the same for the reverse. >>>>> >>>>> A proviso would then be, only a clean(ed) ASN can be transferred in/out. >>>> >>>> Why would one delete networks when an ASN is transferred? The IPs were >>>> assigned according to whatever policy was applicable at that moment. IP >>>> prefixes and ASNs are assigned independently from each other, according >>>> to different policices, and as such it is logical that they are >>>> transferable independently from each other. >>>> >>>> Kind regards, >>>> >>>> Job >>>> _______________________________________________ >>>> PPML >>>> You are receiving this message because you are subscribed to >>>> the ARIN Public Policy Mailing List ([email protected]). >>>> Unsubscribe or manage your mailing list subscription at: >>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>> Please contact [email protected] if you experience any issues. >>>> >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List ([email protected]). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact [email protected] if you experience any issues. >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List ([email protected]). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact [email protected] if you experience any issues. >> > _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
