Re: [arin-ppml] IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers
yes, there are real-world issues for 32-bit ASN users today related to communities. If I'd have to do a greenfield deployment of a new transit network today, using a 16-bit ASN would be a blocking requirement due to BGP communities. I imagine that for a number of years to come 16-bit ASNs will be more desirable than 32-bit ASNs. Exactly this. I left my former $dayjob at the end of November 2017 at a $hugecompany building a greenfield network at cloud scale. It was not possible for us to use 32-bit ASNs and do TE'ing the way we wanted to. Because it was a $hugecompany, we were able to grab a 16-bit ASN from other parts of the company and use it instead. But we tried 32-bit, and it failed to meet our basic network architecture requirements. ___ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues.
Re: [arin-ppml] IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers
On Tue, Feb 06, 2018 at 10:27:55AM -0800, Chris Woodfield 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. It'll be end of 2018 for general available software on the majority of platforms - and for a company like NTT, a deployment of configurations that use large community are likely to be in 2019 or maybe even 2020. I don't intend this statement as a roadmap announcement, but rather to illustrate the timescale. I'm tracking large community support here: http://largebgpcommunities.net/implementations/ > 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. yes, there are real-world issues for 32-bit ASN users today related to communities. If I'd have to do a greenfield deployment of a new transit network today, using a 16-bit ASN would be a blocking requirement due to BGP communities. I imagine that for a number of years to come 16-bit ASNs will be more desirable than 32-bit ASNs. Kind regards, Job ___ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues.
Re: [arin-ppml] IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers
On Tue, Feb 6, 2018 at 4:13 PM Chris Woodfield wrote: > And I’d point to the evidence of a transfer market specifically for 16-bit > ASNs as good evidence of this. > > That said, I’d like to understand better the relative imbalance of supply > and demand for these resources in the various RIR regions before I form a > conclusion as to whether that imbalance justifies a policy change to > resolve. > > +1 Chris’s sentiments about better understanding the imbalances of supply and demand for these resources in the various RIR regions before discussing policy changes. — Brian > -C > > > On Feb 6, 2018, at 12:39 PM, Job Snijders wrote: > > > > On Tue, Feb 06, 2018 at 10:27:55AM -0800, Chris Woodfield 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. > > > > It'll be end of 2018 for general available software on the majority of > > platforms - and for a company like NTT, a deployment of configurations > > that use large community are likely to be in 2019 or maybe even 2020. > > I don't intend this statement as a roadmap announcement, but rather to > > illustrate the timescale. > > > > I'm tracking large community support here: > http://largebgpcommunities.net/implementations/ > > > >> 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. > > > > yes, there are real-world issues for 32-bit ASN users today related to > > communities. If I'd have to do a greenfield deployment of a new transit > > network today, using a 16-bit ASN would be a blocking requirement due to > > BGP communities. I imagine that for a number of years to come 16-bit > > ASNs will be more desirable than 32-bit ASNs. > > > > Kind regards, > > > > Job > > > > ___ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact i...@arin.net if you experience any issues. ___ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues.
Re: [arin-ppml] IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers
And I’d point to the evidence of a transfer market specifically for 16-bit ASNs as good evidence of this. That said, I’d like to understand better the relative imbalance of supply and demand for these resources in the various RIR regions before I form a conclusion as to whether that imbalance justifies a policy change to resolve. -C > On Feb 6, 2018, at 12:39 PM, Job Snijders wrote: > > On Tue, Feb 06, 2018 at 10:27:55AM -0800, Chris Woodfield 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. > > It'll be end of 2018 for general available software on the majority of > platforms - and for a company like NTT, a deployment of configurations > that use large community are likely to be in 2019 or maybe even 2020. > I don't intend this statement as a roadmap announcement, but rather to > illustrate the timescale. > > I'm tracking large community support here: > http://largebgpcommunities.net/implementations/ > >> 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. > > yes, there are real-world issues for 32-bit ASN users today related to > communities. If I'd have to do a greenfield deployment of a new transit > network today, using a 16-bit ASN would be a blocking requirement due to > BGP communities. I imagine that for a number of years to come 16-bit > ASNs will be more desirable than 32-bit ASNs. > > Kind regards, > > Job > ___ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues.
Re: [arin-ppml] IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers
On Tue, Feb 06, 2018 at 12:25:05PM -0800, Owen DeLong wrote: > Extended communities can solve the problem for all ASNs issued today This simply is not true. Kind regards, Job ___ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues.
Re: [arin-ppml] IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers
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 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 wrote: >> >> >>> On Feb 6, 2018, at 09:02 , hostmas...@uneedus.com 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 +, 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 (ARIN-PPML@arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues. >>> ___ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact i...@arin.net if you experience any issues. >> >> ___ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact i...@arin.net if you experience any issues. >> > ___ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). Unsubscribe or manage your mailing list subscription at: http://list
Re: [arin-ppml] IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers
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 wrote: > > >> On Feb 6, 2018, at 09:02 , hostmas...@uneedus.com 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 +, 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 (ARIN-PPML@arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact i...@arin.net if you experience any issues. >>> >> ___ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact i...@arin.net if you experience any issues. > > ___ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact i...@arin.net if you experience any issues. > ___ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues.
Re: [arin-ppml] IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers
Job, I mostly agree with you. There is, however, one issue with the way ARIN does things. On ARIN whois records, there is a field for “Origin AS”. In the event that an organization transfers out an AS that is listed on their blocks as “Origin AS”, you’d like to think that the organization in question would clean that up, but my bet is it’s an opportunity for database degradation and if we can somehow automate safety checks on that, I think it’s worth while. I think the right answer is probably for ARIN to implement business logic that does not permit the transfer of an ASN that is listed on any block as an “Origin AS” unless that block is also simultaneously being transferred to the same entity. Owen > On Feb 1, 2018, at 10:29 , Job Snijders wrote: > > On Thu, Feb 01, 2018 at 06:21:06PM +, 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 (ARIN-PPML@arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact i...@arin.net if you experience any issues. ___ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues.
Re: [arin-ppml] IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers
> On Feb 6, 2018, at 09:02 , hostmas...@uneedus.com 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 +, 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 (ARIN-PPML@arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact i...@arin.net if you experience any issues. >> > ___ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact i...@arin.net if you experience any issues. ___ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues.
Re: [arin-ppml] IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers
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. 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. 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 +, 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 (ARIN-PPML@arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues. ___ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues.
Re: [arin-ppml] IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers
On Thu, Feb 01, 2018 at 06:21:06PM +, 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 (ARIN-PPML@arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues.
Re: [arin-ppml] IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers
I’ve been trying to leave group for a while, but I’ve been unsuccessful thus far, can someone assist? Regards Chevaughn F.D Brown Youth Member of Parliament St Catherine West Central National Youth Parliament Jamaica Chairman| Old Harbour CDC Youth Council Parish Coordinator| National Youth Parliament Jamaica Public Relations Officer| Old Harbour CDC Caribbean Youth Environment Network Mobile: 1 876 472 9054 Email: chevybr...@live.com IG: chevykil SC: chevykil Skype: chevybrown_2 Disclaimer: This email and any attachments are confidential, may be subject to the provisions of the Official Secrets Act and must not be disclosed to or used by anyone other than the intended recipient. Unauthorized use, disclosure, distribution or copying is prohibited and may be unlawful. If you are not the intended recipient, please notify the sender and then delete this email. This email is sent over a public network and its completeness or accuracy cannot be guaranteed. You should carry out your own virus check before opening attachments. We do not accept liability for any loss or damage caused by software viruses. > On Feb 3, 2018, at 1:38 PM, Job Snijders wrote: > > On Sat, Feb 03, 2018 at 10:17:02AM -0800, Scott Leibrand wrote: >>> On Feb 3, 2018, at 5:12 AM, hostmas...@uneedus.com wrote: >>> 1) A company is relocating its headquarters from a location served >>> by an RIR, to another location served by a different RIR, and wants >>> everything in their new home region. >>> >>> 2) A company decides to buy another company with few assets, but >>> holds a 16 bit ASN in another RIR region. They then want to bring >>> that ASN back to ARIN so they can add it to their registration plan. >>> This is similar to M&A of companies with IPv4 addresses as assets, >>> since they can not get a 16 bit ASN directly from ARIN. >>> >>> 3) They have so much equipment scattered around the world with the >>> old ASN, that they do not want to renumber just because their >>> headquarters moved to a region served by a different RIR. If the >>> region moved to is ARIN, in most cases they can save money by >>> putting the moved ASN on their registration plan with their address >>> space. >>> >>> In any case, if ARIN allows transfers, it is highly unlikely that >>> that policy would ever be applied to anything other than a 16 bit >>> ASN as there are plenty of 32 bit ASN's available in all regions. >> >> All three scenarios apply equally to 16 and 32 bit ASNs. If it’s >> easier for everyone involved to transfer an ASN between RIRs along >> with any IPv4 resources, there’s no reason to renumber (which requires >> cooperation from BGP peers). > > I'd like to emphasize that renumbering ASNs can be a very cumbersome and > expensive venture (be it a 16-bit or 32-bit ASN). There are notable > public examples of M&As where the integration and renumbering of related > ASNs took years. > > Just because there is no shortage of 32-bit ASNs in another region > doesn't imply I'd be willing to absorb the cost of renumbering an ASN. > > Kind regards, > > Job > ___ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact i...@arin.net if you experience any issues. ___ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues.
Re: [arin-ppml] IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers
On Sat, Feb 03, 2018 at 10:17:02AM -0800, Scott Leibrand wrote: > > On Feb 3, 2018, at 5:12 AM, hostmas...@uneedus.com wrote: > > 1) A company is relocating its headquarters from a location served > > by an RIR, to another location served by a different RIR, and wants > > everything in their new home region. > > > > 2) A company decides to buy another company with few assets, but > > holds a 16 bit ASN in another RIR region. They then want to bring > > that ASN back to ARIN so they can add it to their registration plan. > > This is similar to M&A of companies with IPv4 addresses as assets, > > since they can not get a 16 bit ASN directly from ARIN. > > > > 3) They have so much equipment scattered around the world with the > > old ASN, that they do not want to renumber just because their > > headquarters moved to a region served by a different RIR. If the > > region moved to is ARIN, in most cases they can save money by > > putting the moved ASN on their registration plan with their address > > space. > > > > In any case, if ARIN allows transfers, it is highly unlikely that > > that policy would ever be applied to anything other than a 16 bit > > ASN as there are plenty of 32 bit ASN's available in all regions. > > All three scenarios apply equally to 16 and 32 bit ASNs. If it’s > easier for everyone involved to transfer an ASN between RIRs along > with any IPv4 resources, there’s no reason to renumber (which requires > cooperation from BGP peers). I'd like to emphasize that renumbering ASNs can be a very cumbersome and expensive venture (be it a 16-bit or 32-bit ASN). There are notable public examples of M&As where the integration and renumbering of related ASNs took years. Just because there is no shortage of 32-bit ASNs in another region doesn't imply I'd be willing to absorb the cost of renumbering an ASN. Kind regards, Job ___ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues.
Re: [arin-ppml] IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers
> On Feb 3, 2018, at 5:12 AM, hostmas...@uneedus.com wrote: > > I can only really think of three: > > 1) A company is relocating its headquarters from a location served by an RIR, > to another location served by a different RIR, and wants everything in their > new home region. > > 2) A company decides to buy another company with few assets, but holds a 16 > bit ASN in another RIR region. They then want to bring that ASN back to ARIN > so they can add it to their registration plan. This is similar to M&A of > companies with IPv4 addresses as assets, since they can not get a 16 bit ASN > directly from ARIN. > > 3) They have so much equipment scattered around the world with the old ASN, > that they do not want to renumber just because their headquarters moved to a > region served by a different RIR. If the region moved to is ARIN, in most > cases they can save money by putting the moved ASN on their registration plan > with their address space. > > In any case, if ARIN allows transfers, it is highly unlikely that that policy > would ever be applied to anything other than a 16 bit ASN as there are plenty > of 32 bit ASN's available in all regions. All three scenarios apply equally to 16 and 32 bit ASNs. If it’s easier for everyone involved to transfer an ASN between RIRs along with any IPv4 resources, there’s no reason to renumber (which requires cooperation from BGP peers). -Scott >> On Fri, 2 Feb 2018, Aaron Dudek wrote: >> >> Why would there be a need for a company to transfer an ASN between RIRs? >> >> >>> On Thu, Feb 1, 2018 at 7:17 PM, David Farmer wrote: >>> I'm not sure what you are asking, but there are no technical or policy >>> requirements, at least that I'm aware of, that an ASN only routes address >>> blocks from the same registry. In other words, a RIPE ASN can route ARIN IP >>> blocks and vice versa. >>> >>> But this does bring up an interesting question; we have the IRR consultation >>> going on, what should happen to IRR objects when ASNs or IP blocks are >>> transferred to another RIRs? >>> >>> My point was this policy is about ASN transfers if we want to talk about >>> IPv6 transfers that would be a different policy, and therefore should be a >>> different thread. It makes it easier to discern the support for a policy if >>> side threads are split out. >>> >>> Thanks >>> >>>> On Thu, Feb 1, 2018 at 12:21 PM, Roberts, Orin wrote: >>>> >>>> You could, but then IPv6 routing/fragmentation becomes an issue. >>>> >>>> >>>> >>>> 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. >>>> >>>> >>>> >>>> Orin Roberts >>>> >>>> >>>> >>>> From: ARIN-PPML [mailto:arin-ppml-boun...@arin.net] On Behalf Of David >>>> Farmer >>>> Sent: February-01-18 1:03 PM >>>> To: Job Snijders >>>> Cc: arin-ppml@arin.net >>>> Subject: Re: [arin-ppml] IPv6 Transfers (was :Draft Policy ARIN-2018-1: >>>> Allow Inter-regional ASN Transfers >>>> >>>> >>>> >>>> First, let's move IPv6 transfers out of the ASN transfers thread. >>>> >>>> >>>> >>>> On Thu, Feb 1, 2018 at 11:40 AM, Job Snijders wrote: >>>> >>>> On Thu, Feb 01, 2018 at 12:30:31PM -0500, hostmas...@uneedus.com wrote: >>>>> I would be opposed to allowing inter regional IPv6 Transfers. >>>>> >>>>> One of the main benefits of IPv6 over IPv4 is the reduction of routing >>>>> table size. Allowing inter regional transfers would start the road to >>>>> larger routing tables. >>>> >>>> I'd appreciate evidence that allowing interregional transfers leads to >>>> larger routing tables. Administrative resource management is somewhat >>>> orthogonal to BGP announcements. Whether the resource is managed by
Re: [arin-ppml] IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers
I can only really think of three: 1) A company is relocating its headquarters from a location served by an RIR, to another location served by a different RIR, and wants everything in their new home region. 2) A company decides to buy another company with few assets, but holds a 16 bit ASN in another RIR region. They then want to bring that ASN back to ARIN so they can add it to their registration plan. This is similar to M&A of companies with IPv4 addresses as assets, since they can not get a 16 bit ASN directly from ARIN. 3) They have so much equipment scattered around the world with the old ASN, that they do not want to renumber just because their headquarters moved to a region served by a different RIR. If the region moved to is ARIN, in most cases they can save money by putting the moved ASN on their registration plan with their address space. In any case, if ARIN allows transfers, it is highly unlikely that that policy would ever be applied to anything other than a 16 bit ASN as there are plenty of 32 bit ASN's available in all regions. Albert Erdmann Network Administrator Paradise On Line Inc. On Fri, 2 Feb 2018, Aaron Dudek wrote: Why would there be a need for a company to transfer an ASN between RIRs? On Thu, Feb 1, 2018 at 7:17 PM, David Farmer wrote: I'm not sure what you are asking, but there are no technical or policy requirements, at least that I'm aware of, that an ASN only routes address blocks from the same registry. In other words, a RIPE ASN can route ARIN IP blocks and vice versa. But this does bring up an interesting question; we have the IRR consultation going on, what should happen to IRR objects when ASNs or IP blocks are transferred to another RIRs? My point was this policy is about ASN transfers if we want to talk about IPv6 transfers that would be a different policy, and therefore should be a different thread. It makes it easier to discern the support for a policy if side threads are split out. Thanks On Thu, Feb 1, 2018 at 12:21 PM, Roberts, Orin wrote: You could, but then IPv6 routing/fragmentation becomes an issue. 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. Orin Roberts From: ARIN-PPML [mailto:arin-ppml-boun...@arin.net] On Behalf Of David Farmer Sent: February-01-18 1:03 PM To: Job Snijders Cc: arin-ppml@arin.net Subject: Re: [arin-ppml] IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers First, let's move IPv6 transfers out of the ASN transfers thread. On Thu, Feb 1, 2018 at 11:40 AM, Job Snijders wrote: On Thu, Feb 01, 2018 at 12:30:31PM -0500, hostmas...@uneedus.com wrote: I would be opposed to allowing inter regional IPv6 Transfers. One of the main benefits of IPv6 over IPv4 is the reduction of routing table size. Allowing inter regional transfers would start the road to larger routing tables. I'd appreciate evidence that allowing interregional transfers leads to larger routing tables. Administrative resource management is somewhat orthogonal to BGP announcements. Whether the resource is managed by RIR A vs RIR B bears no direct relation to the BGP announcements and routing tables. I agree, Inter-RIR transfers doesn't itself imply that the routing table will grow. However, the high level allocations from IANA to the RIRs which are fairly clean in IPv6 today will become fragmented, and likely seriously fragmented if their is signifigant inter-RIR transfers of IPv6. By itself this isn't necessarily a problem, however, IPv6 allocations and assignments have been made in a way to allow most of them to be enlarged in place. If an allocation is transfered this is no longer easily possilbe to expand the alloation in place. We allowed a lot of this in IPv4 because of shortages of addresses. This is not in fact true in the IPv6 world. Growth in address use in IPv4 resulted in most networks having more than one block of addresses. From what I understand, sparse assigment methods are being used in IPv6, allowing those few networks that actually had to grow beyond their original allocation to grow into blocks of space right next to the space they already occupy, helping to keep the routing tables smaller. During the time we were discussing 2017-5, I asked how may ARIN members had grown beyond their original block of IPv6 addresses, and I believe the answer was zero. It is by no means zero, I know of seveal allocations that have been expanded. IPv6 allows for a host to use more than one address and network. This makes multihoming or renumbering a lot simpler than it was in the IPv4 world. I can
Re: [arin-ppml] IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers
Why would there be a need for a company to transfer an ASN between RIRs? On Thu, Feb 1, 2018 at 7:17 PM, David Farmer wrote: > I'm not sure what you are asking, but there are no technical or policy > requirements, at least that I'm aware of, that an ASN only routes address > blocks from the same registry. In other words, a RIPE ASN can route ARIN IP > blocks and vice versa. > > But this does bring up an interesting question; we have the IRR consultation > going on, what should happen to IRR objects when ASNs or IP blocks are > transferred to another RIRs? > > My point was this policy is about ASN transfers if we want to talk about > IPv6 transfers that would be a different policy, and therefore should be a > different thread. It makes it easier to discern the support for a policy if > side threads are split out. > > Thanks > > On Thu, Feb 1, 2018 at 12:21 PM, Roberts, Orin wrote: >> >> You could, but then IPv6 routing/fragmentation becomes an issue. >> >> >> >> 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. >> >> >> >> Orin Roberts >> >> >> >> From: ARIN-PPML [mailto:arin-ppml-boun...@arin.net] On Behalf Of David >> Farmer >> Sent: February-01-18 1:03 PM >> To: Job Snijders >> Cc: arin-ppml@arin.net >> Subject: Re: [arin-ppml] IPv6 Transfers (was :Draft Policy ARIN-2018-1: >> Allow Inter-regional ASN Transfers >> >> >> >> First, let's move IPv6 transfers out of the ASN transfers thread. >> >> >> >> On Thu, Feb 1, 2018 at 11:40 AM, Job Snijders wrote: >> >> On Thu, Feb 01, 2018 at 12:30:31PM -0500, hostmas...@uneedus.com wrote: >> > I would be opposed to allowing inter regional IPv6 Transfers. >> > >> > One of the main benefits of IPv6 over IPv4 is the reduction of routing >> > table size. Allowing inter regional transfers would start the road to >> > larger routing tables. >> >> I'd appreciate evidence that allowing interregional transfers leads to >> larger routing tables. Administrative resource management is somewhat >> orthogonal to BGP announcements. Whether the resource is managed by RIR >> A vs RIR B bears no direct relation to the BGP announcements and routing >> tables. >> >> >> >> I agree, Inter-RIR transfers doesn't itself imply that the routing table >> will grow. However, the high level allocations from IANA to the RIRs which >> are fairly clean in IPv6 today will become fragmented, and likely seriously >> fragmented if their is signifigant inter-RIR transfers of IPv6. By itself >> this isn't necessarily a problem, however, IPv6 allocations and assignments >> have been made in a way to allow most of them to be enlarged in place. If >> an allocation is transfered this is no longer easily possilbe to expand the >> alloation in place. >> >> >> >> > We allowed a lot of this in IPv4 because of shortages of addresses. >> > This is not in fact true in the IPv6 world. Growth in address use in >> > IPv4 resulted in most networks having more than one block of >> > addresses. From what I understand, sparse assigment methods are being >> > used in IPv6, allowing those few networks that actually had to grow >> > beyond their original allocation to grow into blocks of space right >> > next to the space they already occupy, helping to keep the routing >> > tables smaller. During the time we were discussing 2017-5, I asked >> > how may ARIN members had grown beyond their original block of IPv6 >> > addresses, and I believe the answer was zero. >> >> >> >> It is by no means zero, I know of seveal allocations that have been >> expanded. >> >> >> >> > IPv6 allows for a host to use more than one address and network. This >> > makes multihoming or renumbering a lot simpler than it was in the IPv4 >> > world. I can simply provide more than one router and associated >> > network block for each provider, and allow the hosts to obtain an >> > address on each of them and to route between them as they see fit. I >> > can also deprecate one of the availabl
Re: [arin-ppml] IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers
I'm not sure what you are asking, but there are no technical or policy requirements, at least that I'm aware of, that an ASN only routes address blocks from the same registry. In other words, a RIPE ASN can route ARIN IP blocks and vice versa. But this does bring up an interesting question; we have the IRR consultation going on, what should happen to IRR objects when ASNs or IP blocks are transferred to another RIRs? My point was this policy is about ASN transfers if we want to talk about IPv6 transfers that would be a different policy, and therefore should be a different thread. It makes it easier to discern the support for a policy if side threads are split out. Thanks On Thu, Feb 1, 2018 at 12:21 PM, Roberts, Orin wrote: > You could, but then IPv6 routing/fragmentation becomes an issue. > > > > 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. > > > > Orin Roberts > > > > *From:* ARIN-PPML [mailto:arin-ppml-boun...@arin.net] *On Behalf Of *David > Farmer > *Sent:* February-01-18 1:03 PM > *To:* Job Snijders > *Cc:* arin-ppml@arin.net > *Subject:* Re: [arin-ppml] IPv6 Transfers (was :Draft Policy ARIN-2018-1: > Allow Inter-regional ASN Transfers > > > > First, let's move IPv6 transfers out of the ASN transfers thread. > > > > On Thu, Feb 1, 2018 at 11:40 AM, Job Snijders wrote: > > On Thu, Feb 01, 2018 at 12:30:31PM -0500, hostmas...@uneedus.com wrote: > > I would be opposed to allowing inter regional IPv6 Transfers. > > > > One of the main benefits of IPv6 over IPv4 is the reduction of routing > > table size. Allowing inter regional transfers would start the road to > > larger routing tables. > > I'd appreciate evidence that allowing interregional transfers leads to > larger routing tables. Administrative resource management is somewhat > orthogonal to BGP announcements. Whether the resource is managed by RIR > A vs RIR B bears no direct relation to the BGP announcements and routing > tables. > > > > I agree, Inter-RIR transfers doesn't itself imply that the routing table > will grow. However, the high level allocations from IANA to the RIRs which > are fairly clean in IPv6 today will become fragmented, and likely seriously > fragmented if their is signifigant inter-RIR transfers of IPv6. By itself > this isn't necessarily a problem, however, IPv6 allocations and assignments > have been made in a way to allow most of them to be enlarged in place. If > an allocation is transfered this is no longer easily possilbe to expand the > alloation in place. > > > > > We allowed a lot of this in IPv4 because of shortages of addresses. > > This is not in fact true in the IPv6 world. Growth in address use in > > IPv4 resulted in most networks having more than one block of > > addresses. From what I understand, sparse assigment methods are being > > used in IPv6, allowing those few networks that actually had to grow > > beyond their original allocation to grow into blocks of space right > > next to the space they already occupy, helping to keep the routing > > tables smaller. During the time we were discussing 2017-5, I asked > > how may ARIN members had grown beyond their original block of IPv6 > > addresses, and I believe the answer was zero. > > > > It is by no means zero, I know of seveal allocations that have been > expanded. > > > > > IPv6 allows for a host to use more than one address and network. This > > makes multihoming or renumbering a lot simpler than it was in the IPv4 > > world. I can simply provide more than one router and associated > > network block for each provider, and allow the hosts to obtain an > > address on each of them and to route between them as they see fit. I > > can also deprecate one of the available networks, and all new > > connections will be made using the remaining networks and routes. > > This allows easy renumbering. > > > > It is not a big hardship to renumber in IPv6 unlike IPv4, so I would > > like to not end up with lots of exceptions in the routing tables, and > > to keep the registration records simpler. > > You are describing a very specific deployment model. We cannot assume > that every deployment uses that model, nor build policy based on that > assumption. My own experience tells me that r
Re: [arin-ppml] IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers
You could, but then IPv6 routing/fragmentation becomes an issue. 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. Orin Roberts From: ARIN-PPML [mailto:arin-ppml-boun...@arin.net] On Behalf Of David Farmer Sent: February-01-18 1:03 PM To: Job Snijders Cc: arin-ppml@arin.net Subject: Re: [arin-ppml] IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers First, let's move IPv6 transfers out of the ASN transfers thread. On Thu, Feb 1, 2018 at 11:40 AM, Job Snijders mailto:j...@ntt.net>> wrote: On Thu, Feb 01, 2018 at 12:30:31PM -0500, hostmas...@uneedus.com<mailto:hostmas...@uneedus.com> wrote: > I would be opposed to allowing inter regional IPv6 Transfers. > > One of the main benefits of IPv6 over IPv4 is the reduction of routing > table size. Allowing inter regional transfers would start the road to > larger routing tables. I'd appreciate evidence that allowing interregional transfers leads to larger routing tables. Administrative resource management is somewhat orthogonal to BGP announcements. Whether the resource is managed by RIR A vs RIR B bears no direct relation to the BGP announcements and routing tables. I agree, Inter-RIR transfers doesn't itself imply that the routing table will grow. However, the high level allocations from IANA to the RIRs which are fairly clean in IPv6 today will become fragmented, and likely seriously fragmented if their is signifigant inter-RIR transfers of IPv6. By itself this isn't necessarily a problem, however, IPv6 allocations and assignments have been made in a way to allow most of them to be enlarged in place. If an allocation is transfered this is no longer easily possilbe to expand the alloation in place. > We allowed a lot of this in IPv4 because of shortages of addresses. > This is not in fact true in the IPv6 world. Growth in address use in > IPv4 resulted in most networks having more than one block of > addresses. From what I understand, sparse assigment methods are being > used in IPv6, allowing those few networks that actually had to grow > beyond their original allocation to grow into blocks of space right > next to the space they already occupy, helping to keep the routing > tables smaller. During the time we were discussing 2017-5, I asked > how may ARIN members had grown beyond their original block of IPv6 > addresses, and I believe the answer was zero. It is by no means zero, I know of seveal allocations that have been expanded. > IPv6 allows for a host to use more than one address and network. This > makes multihoming or renumbering a lot simpler than it was in the IPv4 > world. I can simply provide more than one router and associated > network block for each provider, and allow the hosts to obtain an > address on each of them and to route between them as they see fit. I > can also deprecate one of the available networks, and all new > connections will be made using the remaining networks and routes. > This allows easy renumbering. > > It is not a big hardship to renumber in IPv6 unlike IPv4, so I would > like to not end up with lots of exceptions in the routing tables, and > to keep the registration records simpler. You are describing a very specific deployment model. We cannot assume that every deployment uses that model, nor build policy based on that assumption. My own experience tells me that renumbering IPv6 is as much work as renumbering IPv4. I also have to agree, the work involed in renumbering is very similar between IPv6 and IPv4. The diffrence is IPv6 has explicitly condiered renumbering and it is possilbe to renumber IPv6 without a flag day on the local subnet. Whereas with IPv4 each subnet requires a flag day to change from the old to the new addressing. So I would charterize the diffrence in renumbering in IPv6 verses IPv4, as the impact on an operational network is less with renumber in IPv6, its a far more graceful change with IPv6, but the sheer amount of operational work is comparable between renumbering in IPv6 and IPv4. Kind regards, Job -- === David Farmer Email:far...@umn.edu<mailto:email%3afar...@umn.edu> Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SEPhone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 === ___ PPML You are receiving this message because you are subscribed
Re: [arin-ppml] IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers
First, let's move IPv6 transfers out of the ASN transfers thread. On Thu, Feb 1, 2018 at 11:40 AM, Job Snijders wrote: > On Thu, Feb 01, 2018 at 12:30:31PM -0500, hostmas...@uneedus.com wrote: > > I would be opposed to allowing inter regional IPv6 Transfers. > > > > One of the main benefits of IPv6 over IPv4 is the reduction of routing > > table size. Allowing inter regional transfers would start the road to > > larger routing tables. > > I'd appreciate evidence that allowing interregional transfers leads to > larger routing tables. Administrative resource management is somewhat > orthogonal to BGP announcements. Whether the resource is managed by RIR > A vs RIR B bears no direct relation to the BGP announcements and routing > tables. > I agree, Inter-RIR transfers doesn't itself imply that the routing table will grow. However, the high level allocations from IANA to the RIRs which are fairly clean in IPv6 today will become fragmented, and likely seriously fragmented if their is signifigant inter-RIR transfers of IPv6. By itself this isn't necessarily a problem, however, IPv6 allocations and assignments have been made in a way to allow most of them to be enlarged in place. If an allocation is transfered this is no longer easily possilbe to expand the alloation in place. > > We allowed a lot of this in IPv4 because of shortages of addresses. > > This is not in fact true in the IPv6 world. Growth in address use in > > IPv4 resulted in most networks having more than one block of > > addresses. From what I understand, sparse assigment methods are being > > used in IPv6, allowing those few networks that actually had to grow > > beyond their original allocation to grow into blocks of space right > > next to the space they already occupy, helping to keep the routing > > tables smaller. During the time we were discussing 2017-5, I asked > > how may ARIN members had grown beyond their original block of IPv6 > > addresses, and I believe the answer was zero. > It is by no means zero, I know of seveal allocations that have been expanded. > > IPv6 allows for a host to use more than one address and network. This > > makes multihoming or renumbering a lot simpler than it was in the IPv4 > > world. I can simply provide more than one router and associated > > network block for each provider, and allow the hosts to obtain an > > address on each of them and to route between them as they see fit. I > > can also deprecate one of the available networks, and all new > > connections will be made using the remaining networks and routes. > > This allows easy renumbering. > > > > It is not a big hardship to renumber in IPv6 unlike IPv4, so I would > > like to not end up with lots of exceptions in the routing tables, and > > to keep the registration records simpler. > > You are describing a very specific deployment model. We cannot assume > that every deployment uses that model, nor build policy based on that > assumption. My own experience tells me that renumbering IPv6 is as much > work as renumbering IPv4. > I also have to agree, the work involed in renumbering is very similar between IPv6 and IPv4. The diffrence is IPv6 has explicitly condiered renumbering and it is possilbe to renumber IPv6 without a flag day on the local subnet. Whereas with IPv4 each subnet requires a flag day to change from the old to the new addressing. So I would charterize the diffrence in renumbering in IPv6 verses IPv4, as the impact on an operational network is less with renumber in IPv6, its a far more graceful change with IPv6, but the sheer amount of operational work is comparable between renumbering in IPv6 and IPv4. > Kind regards, > > Job -- === David Farmer Email:far...@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SEPhone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 === ___ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues.
