From Alison.WOOD at oregon.gov Thu Feb 1 09:51:30 2018 From: Alison.WOOD at oregon.gov (WOOD Alison * DAS) Date: Thu, 1 Feb 2018 14:51:30 +0000 Subject: [arin-ppml] Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers In-Reply-To: References: <5b901b94-f0b8-276b-2c9d-1b27bcb54442@arin.net> <10670B62-314D-469F-B43F-292C9D49E95C@semihuman.com> <20180131200722.GB87376@vurt.meerval.net> Message-ID: Thank you all for the excellent feedback on this draft. Considering James? suggestions, would the community prefer to take each point as a different proposal? They seem to be two different solutions to two different issues. Thanks! -Alison From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of james machado Sent: Wednesday, January 31, 2018 12:47 PM To: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers So we seem to have 2 "problems" for this draft if I am reading correctly. A) An Entity wishes to buy/sell/transfer one or more ASN(s) to another Entity without regard of the destination RIR. B) Entity with one or more ASN(s) wishes to move one or more ASN(s) to a new RIR, possibly complementing an IP move, to begin/continue operations in the destination RIR. James -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Thu Feb 1 11:40:27 2018 From: owen at delong.com (Owen DeLong) Date: Thu, 1 Feb 2018 08:40:27 -0800 Subject: [arin-ppml] Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers In-Reply-To: References: <5b901b94-f0b8-276b-2c9d-1b27bcb54442@arin.net> <10670B62-314D-469F-B43F-292C9D49E95C@semihuman.com> <20180131200722.GB87376@vurt.meerval.net> Message-ID: IMHO, yes. For A), I?m not sure I see the need to support these transactions. We don?t support them for IPv6 (nor do I think we want to). Sales of IPv4 addresses were a stop-gap to deal with a situation of scarcity, free pool exhaustion, and getting by until v6 is widely enough deployed. Hopefully they will eventually go away and we can return to more traditional forms of resource management. For B), I?m still not convinced. They can?t move their IPv6 resources (nor do I think we want to support doing so). The ability to move their IPv4 resources is largely an artifact of the same scarcity/free pool exhaustion described above. However, my objections to solving this particular problem are a bit less than my objections to solving problem A). Owen > On Feb 1, 2018, at 06:51 , WOOD Alison * DAS wrote: > > Thank you all for the excellent feedback on this draft. > > Considering James? suggestions, would the community prefer to take each point as a different proposal? They seem to be two different solutions to two different issues. > > Thanks! > > -Alison > > From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net ] On Behalf Of james machado > Sent: Wednesday, January 31, 2018 12:47 PM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers > > So we seem to have 2 "problems" for this draft if I am reading correctly. > > A) An Entity wishes to buy/sell/transfer one or more ASN(s) to another Entity without regard of the destination RIR. > > B) Entity with one or more ASN(s) wishes to move one or more ASN(s) to a new RIR, possibly complementing an IP move, to begin/continue operations in the destination RIR. > > James > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Thu Feb 1 11:42:35 2018 From: owen at delong.com (Owen DeLong) Date: Thu, 1 Feb 2018 08:42:35 -0800 Subject: [arin-ppml] Revised - Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers In-Reply-To: References: Message-ID: <5B5BB700-8438-4C5B-BDE2-BB5875034138@delong.com> As previously stated, IMHO, we should revise 8.5.4 to be consistent with 4.2.2. Owen > On Jan 31, 2018, at 13:18 , David Farmer wrote: > > There seems to be a bit of controversy on the direction to take this policy. Therefore as the shepherd, it would be helpful to hear from additional community members regarding this policy. > > Do you support or oppose the policy as written? > > Do you think the inconsistency described in the Problem Statement should be corrected? > > If yes, should it be corrected by revising by section 8.5.4 to be consistent with section 4.2.2, as proposed by the current text? > > Or, as an alternative by revising section 4.2.2 to be consistent with section 8.5.4? > > Are there other alternatives to correct the inconsistency to be considered? > > Other suggestions or comments? > > Your additional feedback and participation are appreciated, thank you. > > On Wed, Jan 24, 2018 at 7:42 AM, ARIN > wrote: > The following has been revised: > > * Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers > > Revised text is below and can be found at: > https://www.arin.net/policy/proposals/2017_9.html > > You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are: > > * Enabling Fair and Impartial Number Resource Administration > * Technically Sound > * Supported by the Community > > The PDP can be found at: > https://www.arin.net/policy/pdp.html > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Sean Hopkins > Policy Analyst > American Registry for Internet Numbers (ARIN) > > > > Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers > > Problem Statement: > > It was noted in the ARIN 40 Policy Experience Report, that there is an inconsistency in the initial block size for ISPs. Section 4.2.2 notes that the initial ISP block size should be /21 whereas the initial block size in 8.5.4 is noted as "minimum transfer size" which is effectively a /24. This causes ISP organizations to be approved for different initial block size depending on if they first apply for a transfer directly under section 8 or if they apply for a block under section 4. This policy is intended to clarify this issue, by setting a consistent ISP initial IPv4 block size. It was noted that ARIN staff current operational practice is to allow qualified ISPs an initial /21 for Section 8 transfers when they first apply and are approved under section 4. If an organization applies under section 8 first they are initially qualified for a /24; larger allocations require additional documentation as noted in 8.5.5. > > Policy statement: > > Replace section 8.5.4; > > 8.5.4. Initial block > > Organizations without direct assignments or allocations from ARIN qualify for the transfer of an initial IPv4 block, a /24 for assignments or a /24 up to a /21 for allocations. > > Comments: > > Timetable for implementation: Immediate > > Anything Else: > > The ARIN 40 Policy Experience Report is available at; > > Slides: https://www.arin.net/vault/participate/meetings/reports/ARIN_40/PDF/PPM/sweeting-policy-experience.pdf > > Transcript: https://www.arin.net/vault/participate/meetings/reports/ARIN_40/ppm1_transcript.html#anchor_5 > > Video: https://www.youtube.com/watch?v=QVsfVMG_6fA > > Slides 10 - 13, located in the video from 6:30 to 8:30, are the relevant portion of the report, questions from the audience follow. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 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 at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From job at ntt.net Thu Feb 1 11:55:54 2018 From: job at ntt.net (Job Snijders) Date: Thu, 1 Feb 2018 17:55:54 +0100 Subject: [arin-ppml] Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers In-Reply-To: References: <5b901b94-f0b8-276b-2c9d-1b27bcb54442@arin.net> <10670B62-314D-469F-B43F-292C9D49E95C@semihuman.com> <20180131200722.GB87376@vurt.meerval.net> Message-ID: <20180201165554.GJ1031@hanna.meerval.net> Hi, I do not see a reason to split them out. AS transfers are AS transfers, I don't think other regions have split them out either. In the end the motivation to move a resource is secondary to just having a process to accomodate whatever it is that end users want to do. Owen DeLong does raise an interesting point regarding IPv6 transfers, perhaps for feature parity that should be a transferable resource too. IPv6 transfers would of course be a separate proposal. Kind regards, Job On Thu, Feb 01, 2018 at 08:40:27AM -0800, Owen DeLong wrote: > IMHO, yes. > > For A), I?m not sure I see the need to support these transactions. We > don?t support them for IPv6 (nor do I think we want to). Sales of > IPv4 addresses were a stop-gap to deal with a situation of scarcity, > free pool exhaustion, and getting by until v6 is widely enough > deployed. Hopefully they will eventually go away and we can return to > more traditional forms of resource management. > > For B), I?m still not convinced. They can?t move their IPv6 resources > (nor do I think we want to support doing so). The ability to move > their IPv4 resources is largely an artifact of the same scarcity/free > pool exhaustion described above. However, my objections to solving > this particular problem are a bit less than my objections to solving > problem A). > > Owen > > > On Feb 1, 2018, at 06:51 , WOOD Alison * DAS wrote: > > > > Thank you all for the excellent feedback on this draft. > > > > Considering James? suggestions, would the community prefer to take each point as a different proposal? They seem to be two different solutions to two different issues. > > > > Thanks! > > > > -Alison > > > > From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net ] On Behalf Of james machado > > Sent: Wednesday, January 31, 2018 12:47 PM > > To: arin-ppml at arin.net > > Subject: Re: [arin-ppml] Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers > > > > So we seem to have 2 "problems" for this draft if I am reading correctly. > > > > A) An Entity wishes to buy/sell/transfer one or more ASN(s) to > > another Entity without regard of the destination RIR. > > > > B) Entity with one or more ASN(s) wishes to move one or more ASN(s) > > to a new RIR, possibly complementing an IP move, to begin/continue > > operations in the destination RIR. > > > > James From mike at iptrading.com Thu Feb 1 11:57:59 2018 From: mike at iptrading.com (Mike Burns) Date: Thu, 1 Feb 2018 11:57:59 -0500 Subject: [arin-ppml] Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers In-Reply-To: References: <5b901b94-f0b8-276b-2c9d-1b27bcb54442@arin.net> <10670B62-314D-469F-B43F-292C9D49E95C@semihuman.com> <20180131200722.GB87376@vurt.meerval.net> Message-ID: <00d501d39b7d$d07a7560$716f6020$@iptrading.com> Hello, The transfer logs at APNIC and RIPE indicate that inter-regional transfers have been completed. I consider that objective evidence of need for this functionality. Can somebody provide a downside to the approval of this policy? Staff work? The heavy lifting has already been provided by APNIC and RIPE. Is it important for us to determine every possible reason why people need this functionality? Shouldn?t our default position be trying to answer their need unless there is a reason not to? Regards, Mike From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong Sent: Thursday, February 01, 2018 11:40 AM To: WOOD Alison * DAS Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers IMHO, yes. For A), I?m not sure I see the need to support these transactions. We don?t support them for IPv6 (nor do I think we want to). Sales of IPv4 addresses were a stop-gap to deal with a situation of scarcity, free pool exhaustion, and getting by until v6 is widely enough deployed. Hopefully they will eventually go away and we can return to more traditional forms of resource management. For B), I?m still not convinced. They can?t move their IPv6 resources (nor do I think we want to support doing so). The ability to move their IPv4 resources is largely an artifact of the same scarcity/free pool exhaustion described above. However, my objections to solving this particular problem are a bit less than my objections to solving problem A). Owen On Feb 1, 2018, at 06:51 , WOOD Alison * DAS > wrote: Thank you all for the excellent feedback on this draft. Considering James? suggestions, would the community prefer to take each point as a different proposal? They seem to be two different solutions to two different issues. Thanks! -Alison From: ARIN-PPML [ mailto:arin-ppml-bounces at arin.net] On Behalf Of james machado Sent: Wednesday, January 31, 2018 12:47 PM To: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers So we seem to have 2 "problems" for this draft if I am reading correctly. A) An Entity wishes to buy/sell/transfer one or more ASN(s) to another Entity without regard of the destination RIR. B) Entity with one or more ASN(s) wishes to move one or more ASN(s) to a new RIR, possibly complementing an IP move, to begin/continue operations in the destination RIR. James _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ( ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hostmaster at uneedus.com Thu Feb 1 12:30:31 2018 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Thu, 1 Feb 2018 12:30:31 -0500 (EST) Subject: [arin-ppml] Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers In-Reply-To: <20180201165554.GJ1031@hanna.meerval.net> References: <5b901b94-f0b8-276b-2c9d-1b27bcb54442@arin.net> <10670B62-314D-469F-B43F-292C9D49E95C@semihuman.com> <20180131200722.GB87376@vurt.meerval.net> <20180201165554.GJ1031@hanna.meerval.net> Message-ID: 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. 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. 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. Albert Erdmann Network Administrator Paradise On Line Inc. On Thu, 1 Feb 2018, Job Snijders wrote: > Hi, > > I do not see a reason to split them out. AS transfers are AS transfers, > I don't think other regions have split them out either. In the end the > motivation to move a resource is secondary to just having a process to > accomodate whatever it is that end users want to do. > > Owen DeLong does raise an interesting point regarding IPv6 transfers, > perhaps for feature parity that should be a transferable resource too. > IPv6 transfers would of course be a separate proposal. > > Kind regards, > > Job > > On Thu, Feb 01, 2018 at 08:40:27AM -0800, Owen DeLong wrote: >> IMHO, yes. >> >> For A), I?m not sure I see the need to support these transactions. We >> don?t support them for IPv6 (nor do I think we want to). Sales of >> IPv4 addresses were a stop-gap to deal with a situation of scarcity, >> free pool exhaustion, and getting by until v6 is widely enough >> deployed. Hopefully they will eventually go away and we can return to >> more traditional forms of resource management. >> >> For B), I?m still not convinced. They can?t move their IPv6 resources >> (nor do I think we want to support doing so). The ability to move >> their IPv4 resources is largely an artifact of the same scarcity/free >> pool exhaustion described above. However, my objections to solving >> this particular problem are a bit less than my objections to solving >> problem A). >> >> Owen >> >>> On Feb 1, 2018, at 06:51 , WOOD Alison * DAS wrote: >>> >>> Thank you all for the excellent feedback on this draft. >>> >>> Considering James? suggestions, would the community prefer to take each point as a different proposal? They seem to be two different solutions to two different issues. >>> >>> Thanks! >>> >>> -Alison >>> >>> From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net ] On Behalf Of james machado >>> Sent: Wednesday, January 31, 2018 12:47 PM >>> To: arin-ppml at arin.net >>> Subject: Re: [arin-ppml] Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers >>> >>> So we seem to have 2 "problems" for this draft if I am reading correctly. >>> >>> A) An Entity wishes to buy/sell/transfer one or more ASN(s) to >>> another Entity without regard of the destination RIR. >>> >>> B) Entity with one or more ASN(s) wishes to move one or more ASN(s) >>> to a new RIR, possibly complementing an IP move, to begin/continue >>> operations in the destination RIR. >>> >>> James > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From job at ntt.net Thu Feb 1 12:40:09 2018 From: job at ntt.net (Job Snijders) Date: Thu, 1 Feb 2018 18:40:09 +0100 Subject: [arin-ppml] Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers In-Reply-To: References: <5b901b94-f0b8-276b-2c9d-1b27bcb54442@arin.net> <10670B62-314D-469F-B43F-292C9D49E95C@semihuman.com> <20180131200722.GB87376@vurt.meerval.net> <20180201165554.GJ1031@hanna.meerval.net> Message-ID: <20180201174009.GA56337@hanna.meerval.net> On Thu, Feb 01, 2018 at 12:30:31PM -0500, hostmaster at 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. > 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. > > 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. Kind regards, Job From oroberts at bell.ca Thu Feb 1 12:46:10 2018 From: oroberts at bell.ca (Roberts, Orin) Date: Thu, 1 Feb 2018 17:46:10 +0000 Subject: [arin-ppml] Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers In-Reply-To: <20180201174009.GA56337@hanna.meerval.net> References: <5b901b94-f0b8-276b-2c9d-1b27bcb54442@arin.net> <10670B62-314D-469F-B43F-292C9D49E95C@semihuman.com> <20180131200722.GB87376@vurt.meerval.net> <20180201165554.GJ1031@hanna.meerval.net> <20180201174009.GA56337@hanna.meerval.net> Message-ID: <2b9175759393431fae9cba9c7667a592@DG2MBX04-DOR.bell.corp.bce.ca> Question Has any other registry already adopted or implemented such a policy - Inter-regional ASN Transfers? Orin Roberts -----Original Message----- From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Job Snijders Sent: February-01-18 12:40 PM To: hostmaster at uneedus.com Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers On Thu, Feb 01, 2018 at 12:30:31PM -0500, hostmaster at 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. > 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. > > 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. Kind regards, Job _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From farmer at umn.edu Thu Feb 1 13:02:42 2018 From: farmer at umn.edu (David Farmer) Date: Thu, 1 Feb 2018 12:02:42 -0600 Subject: [arin-ppml] IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers Message-ID: 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, hostmaster at 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:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Thu Feb 1 13:03:56 2018 From: farmer at umn.edu (David Farmer) Date: Thu, 1 Feb 2018 12:03:56 -0600 Subject: [arin-ppml] Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers In-Reply-To: <2b9175759393431fae9cba9c7667a592@DG2MBX04-DOR.bell.corp.bce.ca> References: <5b901b94-f0b8-276b-2c9d-1b27bcb54442@arin.net> <10670B62-314D-469F-B43F-292C9D49E95C@semihuman.com> <20180131200722.GB87376@vurt.meerval.net> <20180201165554.GJ1031@hanna.meerval.net> <20180201174009.GA56337@hanna.meerval.net> <2b9175759393431fae9cba9c7667a592@DG2MBX04-DOR.bell.corp.bce.ca> Message-ID: Yes, APNIC and RIPE both allow inter-RIR transfers of ASNs. On Thu, Feb 1, 2018 at 11:46 AM, Roberts, Orin wrote: > Question > Has any other registry already adopted or implemented such a policy - > Inter-regional ASN Transfers? > > Orin Roberts > > > -----Original Message----- > From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Job > Snijders > Sent: February-01-18 12:40 PM > To: hostmaster at uneedus.com > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Draft Policy ARIN-2018-1: Allow Inter-regional > ASN Transfers > > On Thu, Feb 01, 2018 at 12:30:31PM -0500, hostmaster at 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. > > > 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. > > > > 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. > > Kind regards, > > Job > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at 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 at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From oroberts at bell.ca Thu Feb 1 13:21:06 2018 From: oroberts at bell.ca (Roberts, Orin) Date: Thu, 1 Feb 2018 18:21:06 +0000 Subject: [arin-ppml] IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers In-Reply-To: References: Message-ID: <47325565b96e4adaa6214be0f0d293da@DG2MBX04-DOR.bell.corp.bce.ca> 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-bounces at arin.net] On Behalf Of David Farmer Sent: February-01-18 1:03 PM To: Job Snijders Cc: arin-ppml at 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, hostmaster at 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:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Thu Feb 1 13:48:48 2018 From: farmer at umn.edu (David Farmer) Date: Thu, 1 Feb 2018 12:48:48 -0600 Subject: [arin-ppml] Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers In-Reply-To: References: <5b901b94-f0b8-276b-2c9d-1b27bcb54442@arin.net> <10670B62-314D-469F-B43F-292C9D49E95C@semihuman.com> <20180131200722.GB87376@vurt.meerval.net> <20180201165554.GJ1031@hanna.meerval.net> <20180201174009.GA56337@hanna.meerval.net> <2b9175759393431fae9cba9c7667a592@DG2MBX04-DOR.bell.corp.bce.ca> Message-ID: On Thu, Feb 1, 2018 at 12:03 PM, David Farmer wrote: > Yes, APNIC and RIPE both allow inter-RIR transfers of ASNs. > For further refrence here are the applicable policies; https://www.apnic.net/community/policy/resources#13.2.-Inter-RIR-ASN-transfers https://www.ripe.net/publications/docs/ripe-682#3-0-inter-rir-transfers Thanks. On Thu, Feb 1, 2018 at 11:46 AM, Roberts, Orin wrote: > >> Question >> Has any other registry already adopted or implemented such a policy - >> Inter-regional ASN Transfers? >> >> Orin Roberts >> >> >> -----Original Message----- >> From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Job >> Snijders >> Sent: February-01-18 12:40 PM >> To: hostmaster at uneedus.com >> Cc: arin-ppml at arin.net >> Subject: Re: [arin-ppml] Draft Policy ARIN-2018-1: Allow Inter-regional >> ASN Transfers >> >> On Thu, Feb 01, 2018 at 12:30:31PM -0500, hostmaster at 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. >> >> > 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. >> > >> > 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. >> >> Kind regards, >> >> Job >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to the ARIN >> Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at 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 at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> > > > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> > Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> > =============================================== > -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From jschiller at google.com Thu Feb 1 14:10:51 2018 From: jschiller at google.com (Jason Schiller) Date: Thu, 1 Feb 2018 14:10:51 -0500 Subject: [arin-ppml] Revised - Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers In-Reply-To: <5B5BB700-8438-4C5B-BDE2-BB5875034138@delong.com> References: <5B5BB700-8438-4C5B-BDE2-BB5875034138@delong.com> Message-ID: As previously stated, we should revise 4.2.2 to be consistent with 8.5.4. The changes proposed in 2016-3, 2016-4, 2016-5 were all part of a package that intended to: - create a slow start for transfers (double what you have) - 2016-3 - create a boot strapping for tranfers (first /24 with no justification) - 2016-5 - remove efficent utilization or immedate (30 day) need for ISP initial - 2016-4 - create a boot strapping for initial ISP (first /24 with no justification) - 2016-4 - sync initial ISP w/ no resources, desiring greater than /24 w/ transfers - 2016-4 It is my belief as one of the originators that there was no desire to remove the the time horizion requirement for ISP initial (except for a /24). It is my belief as one of the originators that there was no desire to remove the requirement that ISP with IPv4 space from their upstream need to demonstare efficent utilization. I beleive these are all a side effect of removing the 2.2.2 subsections. 2016-4 is not clear that the sub sections will be removed. On Thu, Feb 1, 2018 at 11:42 AM, Owen DeLong wrote: > As previously stated, IMHO, we should revise 8.5.4 to be consistent with > 4.2.2. > > Owen > > On Jan 31, 2018, at 13:18 , David Farmer wrote: > > There seems to be a bit of controversy on the direction to take this > policy. Therefore as the shepherd, it would be helpful to hear from > additional community members regarding this policy. > > Do you support or oppose the policy as written? > > Do you think the inconsistency described in the Problem Statement should > be corrected? > > If yes, should it be corrected by revising by section 8.5.4 to be > consistent with section 4.2.2, as proposed by the current text? > > Or, as an alternative by revising section 4.2.2 to be consistent with > section 8.5.4? > > Are there other alternatives to correct the inconsistency to be considered? > > Other suggestions or comments? > > Your additional feedback and participation are appreciated, thank you. > > On Wed, Jan 24, 2018 at 7:42 AM, ARIN wrote: > >> The following has been revised: >> >> * Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 >> ISP Transfers >> >> Revised text is below and can be found at: >> https://www.arin.net/policy/proposals/2017_9.html >> >> You are encouraged to discuss all Draft Policies on PPML. The AC will >> evaluate the discussion in order to assess the conformance of this draft >> policy with ARIN's Principles of Internet number resource policy as stated >> in the Policy Development Process (PDP). Specifically, these principles are: >> >> * Enabling Fair and Impartial Number Resource Administration >> * Technically Sound >> * Supported by the Community >> >> The PDP can be found at: >> https://www.arin.net/policy/pdp.html >> >> Draft Policies and Proposals under discussion can be found at: >> https://www.arin.net/policy/proposals/index.html >> >> Regards, >> >> Sean Hopkins >> Policy Analyst >> American Registry for Internet Numbers (ARIN) >> >> >> >> Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 >> ISP Transfers >> >> Problem Statement: >> >> It was noted in the ARIN 40 Policy Experience Report, that there is an >> inconsistency in the initial block size for ISPs. Section 4.2.2 notes that >> the initial ISP block size should be /21 whereas the initial block size in >> 8.5.4 is noted as "minimum transfer size" which is effectively a /24. This >> causes ISP organizations to be approved for different initial block size >> depending on if they first apply for a transfer directly under section 8 or >> if they apply for a block under section 4. This policy is intended to >> clarify this issue, by setting a consistent ISP initial IPv4 block size. It >> was noted that ARIN staff current operational practice is to allow >> qualified ISPs an initial /21 for Section 8 transfers when they first apply >> and are approved under section 4. If an organization applies under section >> 8 first they are initially qualified for a /24; larger allocations require >> additional documentation as noted in 8.5.5. >> >> Policy statement: >> >> Replace section 8.5.4; >> >> 8.5.4. Initial block >> >> Organizations without direct assignments or allocations from ARIN qualify >> for the transfer of an initial IPv4 block, a /24 for assignments or a /24 >> up to a /21 for allocations. >> >> Comments: >> >> Timetable for implementation: Immediate >> >> Anything Else: >> >> The ARIN 40 Policy Experience Report is available at; >> >> Slides: https://www.arin.net/vault/participate/meetings/reports/ARIN >> _40/PDF/PPM/sweeting-policy-experience.pdf >> >> Transcript: https://www.arin.net/vault/participate/meetings/reports/ARIN >> _40/ppm1_transcript.html#anchor_5 >> >> Video: https://www.youtube.com/watch?v=QVsfVMG_6fA >> >> Slides 10 - 13, located in the video from 6:30 to 8:30, are the relevant >> portion of the report, questions from the audience follow. >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> > > > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> > Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> > =============================================== > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at 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 at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at semihuman.com Thu Feb 1 14:22:15 2018 From: chris at semihuman.com (Chris Woodfield) Date: Thu, 1 Feb 2018 11:22:15 -0800 Subject: [arin-ppml] Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers In-Reply-To: <00d501d39b7d$d07a7560$716f6020$@iptrading.com> References: <5b901b94-f0b8-276b-2c9d-1b27bcb54442@arin.net> <10670B62-314D-469F-B43F-292C9D49E95C@semihuman.com> <20180131200722.GB87376@vurt.meerval.net> <00d501d39b7d$d07a7560$716f6020$@iptrading.com> Message-ID: <04E9BD09-83E3-4576-BA94-F9532FA94C90@semihuman.com> Hi Mike, I?d consider it very poor argument to promote a policy proposal solely based on its adoption in other RIRs. Various RIRs, and the regions they represent, often have unique, and sometimes conflicting requirements for management of internet resources, and as such we should be evaluating proposals on their merits. Adoption by other RIRs is one input for consideration, but should never be the primary input. The Policy Development Process requires that the proposal in question present a clear problem statement and come to a consensus as a community that the language being proposed solves that statement. As such, we must carefully consider both the problem statement, *and* the policy language proposed. This is the main motivation for the discussions you?re seeing re: the problem statement itself; we simply can?t adopt a policy based on a non-specific problem, and a simple apparent lack of downsides of adopting the proposed edit to the NRPM. As such, on the PPML we?ve seen several viable justifications for this proposal; I?d expect at least one, if not both, to eventually find its way into a modified problem statement, and once that?s done, we can discuss the proposal itself as to whether or not it solves the issue as proposed and the relative merits and costs thereof. Hope this helps, -Chris > On Feb 1, 2018, at 8:57 AM, Mike Burns wrote: > > Hello, > > The transfer logs at APNIC and RIPE indicate that inter-regional transfers have been completed. > I consider that objective evidence of need for this functionality. > > Can somebody provide a downside to the approval of this policy? > Staff work? The heavy lifting has already been provided by APNIC and RIPE. > > Is it important for us to determine every possible reason why people need this functionality? > Shouldn?t our default position be trying to answer their need unless there is a reason not to? > > Regards, > Mike > > > > > > > From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong > Sent: Thursday, February 01, 2018 11:40 AM > To: WOOD Alison * DAS > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers > > IMHO, yes. > > For A), I?m not sure I see the need to support these transactions. We don?t support them for IPv6 (nor do I think we want to). > Sales of IPv4 addresses were a stop-gap to deal with a situation of scarcity, free pool exhaustion, and getting by until v6 > is widely enough deployed. Hopefully they will eventually go away and we can return to more traditional forms of resource management. > > For B), I?m still not convinced. They can?t move their IPv6 resources (nor do I think we want to support doing so). The ability to move their IPv4 resources is largely an artifact of the same scarcity/free pool exhaustion described above. However, my objections to solving this particular problem are a bit less than my objections to solving problem A). > > Owen > >> On Feb 1, 2018, at 06:51 , WOOD Alison * DAS > wrote: >> >> Thank you all for the excellent feedback on this draft. >> >> Considering James? suggestions, would the community prefer to take each point as a different proposal? They seem to be two different solutions to two different issues. >> >> Thanks! >> >> -Alison >> >> From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net ] On Behalf Of james machado >> Sent: Wednesday, January 31, 2018 12:47 PM >> To: arin-ppml at arin.net >> Subject: Re: [arin-ppml] Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers >> >> So we seem to have 2 "problems" for this draft if I am reading correctly. >> >> A) An Entity wishes to buy/sell/transfer one or more ASN(s) to another Entity without regard of the destination RIR. >> >> B) Entity with one or more ASN(s) wishes to move one or more ASN(s) to a new RIR, possibly complementing an IP move, to begin/continue operations in the destination RIR. >> >> James >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at 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 at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jschiller at google.com Thu Feb 1 14:25:08 2018 From: jschiller at google.com (Jason Schiller) Date: Thu, 1 Feb 2018 14:25:08 -0500 Subject: [arin-ppml] Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers In-Reply-To: References: <5b901b94-f0b8-276b-2c9d-1b27bcb54442@arin.net> <10670B62-314D-469F-B43F-292C9D49E95C@semihuman.com> <20180131200722.GB87376@vurt.meerval.net> Message-ID: I aggree with Owen's view on this matter. There is nothing special about the specific set of numbers, just the right to use a set of number for a given prupose. There is no shortage of these types of numbers. I think our community rejected the arguement that somone couldn't make an ASN larger than 65535 work. That being said we should provide some flexibility in helping people transition between the old and new numbers. I don't beleive we need a policy around this. __Jason On Thu, Feb 1, 2018 at 11:40 AM, Owen DeLong wrote: > IMHO, yes. > > For A), I?m not sure I see the need to support these transactions. We > don?t support them for IPv6 (nor do I think we want to). > Sales of IPv4 addresses were a stop-gap to deal with a situation of > scarcity, free pool exhaustion, and getting by until v6 > is widely enough deployed. Hopefully they will eventually go away and we > can return to more traditional forms of resource management. > > For B), I?m still not convinced. They can?t move their IPv6 resources (nor > do I think we want to support doing so). The ability to move their IPv4 > resources is largely an artifact of the same scarcity/free pool exhaustion > described above. However, my objections to solving this particular problem > are a bit less than my objections to solving problem A). > > Owen > > On Feb 1, 2018, at 06:51 , WOOD Alison * DAS > wrote: > > Thank you all for the excellent feedback on this draft. > > Considering James? suggestions, would the community prefer to take each > point as a different proposal? They seem to be two different solutions to > two different issues. > > Thanks! > > -Alison > > *From:* ARIN-PPML [mailto:arin-ppml-bounces at arin.net > ] *On Behalf Of *james machado > *Sent:* Wednesday, January 31, 2018 12:47 PM > *To:* arin-ppml at arin.net > *Subject:* Re: [arin-ppml] Draft Policy ARIN-2018-1: Allow Inter-regional > ASN Transfers > > So we seem to have 2 "problems" for this draft if I am reading correctly. > > A) An Entity wishes to buy/sell/transfer one or more ASN(s) to another > Entity without regard of the destination RIR. > > B) Entity with one or more ASN(s) wishes to move one or more ASN(s) to a > new RIR, possibly complementing an IP move, to begin/continue operations in > the destination RIR. > > James > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at 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 at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Thu Feb 1 19:17:10 2018 From: farmer at umn.edu (David Farmer) Date: Thu, 1 Feb 2018 18:17:10 -0600 Subject: [arin-ppml] IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers In-Reply-To: <47325565b96e4adaa6214be0f0d293da@DG2MBX04-DOR.bell.corp.bce.ca> References: <47325565b96e4adaa6214be0f0d293da@DG2MBX04-DOR.bell.corp.bce.ca> Message-ID: 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-bounces at arin.net] *On Behalf Of *David > Farmer > *Sent:* February-01-18 1:03 PM > *To:* Job Snijders > *Cc:* arin-ppml at 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, hostmaster at 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:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> > Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> > =============================================== > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From narten at us.ibm.com Fri Feb 2 00:53:02 2018 From: narten at us.ibm.com (narten at us.ibm.com) Date: Fri, 02 Feb 2018 00:53:02 -0500 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201802020553.w125r3Hv024154@rotala.raleigh.ibm.com> Total of 32 messages in the last 7 days. script run at: Fri Feb 2 00:53:02 EST 2018 Messages | Bytes | Who --------+------+--------+----------+------------------------ 21.88% | 7 | 27.63% | 169157 | farmer at umn.edu 9.38% | 3 | 12.88% | 78835 | jschiller at google.com 9.38% | 3 | 7.02% | 42959 | jcurran at arin.net 6.25% | 2 | 9.69% | 59336 | chris at semihuman.com 6.25% | 2 | 8.93% | 54678 | owen at delong.com 9.38% | 3 | 4.96% | 30392 | job at ntt.net 6.25% | 2 | 7.37% | 45115 | oroberts at bell.ca 6.25% | 2 | 4.37% | 26761 | hvgeekwtrvl at gmail.com 6.25% | 2 | 3.81% | 23298 | hostmaster at uneedus.com 6.25% | 2 | 3.06% | 18719 | info at arin.net 3.12% | 1 | 3.86% | 23613 | mike at iptrading.com 3.12% | 1 | 2.52% | 15439 | alison.wood at oregon.gov 3.12% | 1 | 2.27% | 13881 | scottleibrand at gmail.com 3.12% | 1 | 1.64% | 10023 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 32 |100.00% | 612206 | Total From adudek16 at gmail.com Fri Feb 2 13:45:49 2018 From: adudek16 at gmail.com (Aaron Dudek) Date: Fri, 2 Feb 2018 13:45:49 -0500 Subject: [arin-ppml] IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers In-Reply-To: References: <47325565b96e4adaa6214be0f0d293da@DG2MBX04-DOR.bell.corp.bce.ca> Message-ID: 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-bounces at arin.net] On Behalf Of David >> Farmer >> Sent: February-01-18 1:03 PM >> To: Job Snijders >> Cc: arin-ppml at 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, hostmaster at 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:farmer at umn.edu >> Networking & Telecommunication Services >> Office of Information Technology >> University of Minnesota >> 2218 University Ave SE Phone: 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 at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > > > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 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 at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From hostmaster at uneedus.com Sat Feb 3 08:12:53 2018 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Sat, 3 Feb 2018 08:12:53 -0500 (EST) Subject: [arin-ppml] IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers In-Reply-To: References: <47325565b96e4adaa6214be0f0d293da@DG2MBX04-DOR.bell.corp.bce.ca> Message-ID: 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-bounces at arin.net] On Behalf Of David >>> Farmer >>> Sent: February-01-18 1:03 PM >>> To: Job Snijders >>> Cc: arin-ppml at 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, hostmaster at 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:farmer at umn.edu >>> Networking & Telecommunication Services >>> Office of Information Technology >>> University of Minnesota >>> 2218 University Ave SE Phone: 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 at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >> >> >> >> >> -- >> =============================================== >> David Farmer Email:farmer at umn.edu >> Networking & Telecommunication Services >> Office of Information Technology >> University of Minnesota >> 2218 University Ave SE Phone: 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 at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at 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 at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From scottleibrand at gmail.com Sat Feb 3 13:17:02 2018 From: scottleibrand at gmail.com (Scott Leibrand) Date: Sat, 3 Feb 2018 10:17:02 -0800 Subject: [arin-ppml] IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers In-Reply-To: References: <47325565b96e4adaa6214be0f0d293da@DG2MBX04-DOR.bell.corp.bce.ca> Message-ID: > On Feb 3, 2018, at 5:12 AM, hostmaster at 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-bounces at arin.net] On Behalf Of David >>>> Farmer >>>> Sent: February-01-18 1:03 PM >>>> To: Job Snijders >>>> Cc: arin-ppml at 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, hostmaster at 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:farmer at umn.edu >>>> Networking & Telecommunication Services >>>> Office of Information Technology >>>> University of Minnesota >>>> 2218 University Ave SE Phone: 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 at arin.net). >>>> Unsubscribe or manage your mailing list subscription at: >>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>> Please contact info at arin.net if you experience any issues. >>> >>> >>> >>> >>> -- >>> =============================================== >>> David Farmer Email:farmer at umn.edu >>> Networking & Telecommunication Services >>> Office of Information Technology >>> University of Minnesota >>> 2218 University Ave SE Phone: 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 at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at 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 at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at 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 at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From job at ntt.net Sat Feb 3 13:38:58 2018 From: job at ntt.net (Job Snijders) Date: Sat, 3 Feb 2018 18:38:58 +0000 Subject: [arin-ppml] IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers In-Reply-To: References: <47325565b96e4adaa6214be0f0d293da@DG2MBX04-DOR.bell.corp.bce.ca> Message-ID: <20180203183858.GD72622@vurt.meerval.net> On Sat, Feb 03, 2018 at 10:17:02AM -0800, Scott Leibrand wrote: > > On Feb 3, 2018, at 5:12 AM, hostmaster at 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 From chevykilla.14 at gmail.com Sat Feb 3 18:10:25 2018 From: chevykilla.14 at gmail.com (Chevy Killa) Date: Sat, 3 Feb 2018 18:10:25 -0500 Subject: [arin-ppml] IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers In-Reply-To: <20180203183858.GD72622@vurt.meerval.net> References: <47325565b96e4adaa6214be0f0d293da@DG2MBX04-DOR.bell.corp.bce.ca> <20180203183858.GD72622@vurt.meerval.net> Message-ID: <1D94B631-9018-4CA5-BAD3-B63051635D51@gmail.com> 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: Chevybrown at 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, hostmaster at 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 at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rudi.daniel at gmail.com Mon Feb 5 09:11:34 2018 From: rudi.daniel at gmail.com (Rudolph Daniel) Date: Mon, 5 Feb 2018 10:11:34 -0400 Subject: [arin-ppml] ARIN-PPML 2018-1 In-Reply-To: References: Message-ID: I need a small clarification. The Caribbean region has 3 RIRs St Lucia is ARIN, Trinidad is LACNIC and Martinique is RIPE If my base is arin and offer wholesale services to same geo. Region countries.. Trinidad (lacnic) and Martinique (Ripe), do i need 3 separate AS numbers? rd On 3 Feb 2018 14:17, wrote: Send ARIN-PPML mailing list submissions to arin-ppml at arin.net To subscribe or unsubscribe via the World Wide Web, visit http://lists.arin.net/mailman/listinfo/arin-ppml or, via email, send a message with subject or body 'help' to arin-ppml-request at arin.net Today's Topics: 1. Weekly posting summary for ppml at arin.net (narten at us.ibm.com) 2. Re: IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers (Aaron Dudek) 3. Re: IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers (hostmaster at uneedus.com) 4. Re: IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers (Scott Leibrand) ---------------------------------------------------------------------- Message: 1 Date: Fri, 02 Feb 2018 00:53:02 -0500 From: narten at us.ibm.com To: arin-ppml at arin.net Subject: [arin-ppml] Weekly posting summary for ppml at arin.net Message-ID: <201802020553.w125r3Hv024154 at rotala.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii Total of 32 messages in the last 7 days. script run at: Fri Feb 2 00:53:02 EST 2018 Messages | Bytes | Who --------+------+--------+----------+------------------------ 21.88% | 7 | 27.63% | 169157 | farmer at umn.edu 9.38% | 3 | 12.88% | 78835 | jschiller at google.com 9.38% | 3 | 7.02% | 42959 | jcurran at arin.net 6.25% | 2 | 9.69% | 59336 | chris at semihuman.com 6.25% | 2 | 8.93% | 54678 | owen at delong.com 9.38% | 3 | 4.96% | 30392 | job at ntt.net 6.25% | 2 | 7.37% | 45115 | oroberts at bell.ca 6.25% | 2 | 4.37% | 26761 | hvgeekwtrvl at gmail.com 6.25% | 2 | 3.81% | 23298 | hostmaster at uneedus.com 6.25% | 2 | 3.06% | 18719 | info at arin.net 3.12% | 1 | 3.86% | 23613 | mike at iptrading.com 3.12% | 1 | 2.52% | 15439 | alison.wood at oregon.gov 3.12% | 1 | 2.27% | 13881 | scottleibrand at gmail.com 3.12% | 1 | 1.64% | 10023 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 32 |100.00% | 612206 | Total ------------------------------ Message: 2 Date: Fri, 2 Feb 2018 13:45:49 -0500 From: Aaron Dudek To: David Farmer Cc: "Roberts, Orin" , "arin-ppml at arin.net" Subject: Re: [arin-ppml] IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers Message-ID: Content-Type: text/plain; charset="UTF-8" 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-bounces at arin.net] On Behalf Of David >> Farmer >> Sent: February-01-18 1:03 PM >> To: Job Snijders >> Cc: arin-ppml at 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, hostmaster at 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:farmer at umn.edu >> Networking & Telecommunication Services >> Office of Information Technology >> University of Minnesota >> 2218 University Ave SE Phone: 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 at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > > > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 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 at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. ------------------------------ Message: 3 Date: Sat, 3 Feb 2018 08:12:53 -0500 (EST) From: hostmaster at uneedus.com To: "arin-ppml at arin.net" Subject: Re: [arin-ppml] IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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-bounces at arin.net] On Behalf Of David >>> Farmer >>> Sent: February-01-18 1:03 PM >>> To: Job Snijders >>> Cc: arin-ppml at 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, hostmaster at 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:farmer at umn.edu >>> Networking & Telecommunication Services >>> Office of Information Technology >>> University of Minnesota >>> 2218 University Ave SE Phone: 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 at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >> >> >> >> >> -- >> =============================================== >> David Farmer Email:farmer at umn.edu >> Networking & Telecommunication Services >> Office of Information Technology >> University of Minnesota >> 2218 University Ave SE Phone: 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 at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at 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 at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > ------------------------------ Message: 4 Date: Sat, 3 Feb 2018 10:17:02 -0800 From: Scott Leibrand To: hostmaster at uneedus.com Cc: "arin-ppml at arin.net" Subject: Re: [arin-ppml] IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers Message-ID: Content-Type: text/plain; charset=utf-8 > On Feb 3, 2018, at 5:12 AM, hostmaster at 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-bounces at arin.net] On Behalf Of David >>>> Farmer >>>> Sent: February-01-18 1:03 PM >>>> To: Job Snijders >>>> Cc: arin-ppml at 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, hostmaster at 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:farmer at umn.edu >>>> Networking & Telecommunication Services >>>> Office of Information Technology >>>> University of Minnesota >>>> 2218 University Ave SE Phone: 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 at arin.net). >>>> Unsubscribe or manage your mailing list subscription at: >>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>> Please contact info at arin.net if you experience any issues. >>> >>> >>> >>> >>> -- >>> =============================================== >>> David Farmer Email:farmer at umn.edu >>> Networking & Telecommunication Services >>> Office of Information Technology >>> University of Minnesota >>> 2218 University Ave SE Phone: 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 at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at 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 at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at 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 at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. ------------------------------ Subject: Digest Footer _______________________________________________ ARIN-PPML mailing list ARIN-PPML at arin.net http://lists.arin.net/mailman/listinfo/arin-ppml ------------------------------ End of ARIN-PPML Digest, Vol 152, Issue 8 ***************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Mon Feb 5 09:38:09 2018 From: bill at herrin.us (William Herrin) Date: Mon, 5 Feb 2018 09:38:09 -0500 Subject: [arin-ppml] ARIN-PPML 2018-1 In-Reply-To: References: Message-ID: On Mon, Feb 5, 2018 at 9:11 AM, Rudolph Daniel wrote: > I need a small clarification. > The Caribbean region has 3 RIRs > > St Lucia is ARIN, Trinidad is LACNIC and Martinique is RIPE > If my base is arin and offer wholesale services to same geo. Region > countries.. Trinidad (lacnic) and Martinique (Ripe), do i need 3 separate AS > numbers? Hi Rudolph, Under ARIN rules, there is no need for separate AS numbers. I can't speak for RIPE or LACNIC rules, or for any rules imposed by your upstream network providers. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From sergio at lacnic.net Mon Feb 5 10:09:06 2018 From: sergio at lacnic.net (Sergio Rojas. . .) Date: Mon, 5 Feb 2018 12:09:06 -0300 Subject: [arin-ppml] ARIN-PPML 2018-1 In-Reply-To: References: Message-ID: <416e15fe-5236-1d36-7bda-4a10f0ba7f19@lacnic.net> Dear Rudolph, There is not a policy in the LACNIC manual that prohibit to announce IPv4/IPv6 ranges through ASNs allocated by other RIRs, of course the IPv4/IPv6 received by LACNIC must be used in Trinidad. Regards, Sergio Rojas. . . El 5/2/18 a las 11:38, William Herrin escribi?: > On Mon, Feb 5, 2018 at 9:11 AM, Rudolph Daniel wrote: >> I need a small clarification. >> The Caribbean region has 3 RIRs >> >> St Lucia is ARIN, Trinidad is LACNIC and Martinique is RIPE >> If my base is arin and offer wholesale services to same geo. Region >> countries.. Trinidad (lacnic) and Martinique (Ripe), do i need 3 separate AS >> numbers? > Hi Rudolph, > > Under ARIN rules, there is no need for separate AS numbers. I can't > speak for RIPE or LACNIC rules, or for any rules imposed by your > upstream network providers. > > Regards, > Bill Herrin > > > From farmer at umn.edu Mon Feb 5 10:11:27 2018 From: farmer at umn.edu (David Farmer) Date: Mon, 5 Feb 2018 09:11:27 -0600 Subject: [arin-ppml] ARIN-PPML 2018-1 In-Reply-To: References: Message-ID: On Mon, Feb 5, 2018 at 8:11 AM, Rudolph Daniel wrote: > I need a small clarification. > The Caribbean region has 3 RIRs > > St Lucia is ARIN, Trinidad is LACNIC and Martinique is RIPE > If my base is arin and offer wholesale services to same geo. Region > countries.. Trinidad (lacnic) and Martinique (Ripe), do i need 3 separate > AS numbers? > > rd > As I said previously; 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. So, there is no requirement for you to use more than one ASN, at least realted to the region an islands belong too. You may have other reasons to use diffrent ASNs, like you have no network interconnecting your seperate networks on each island, and have a seperate upstream provider on each island. By the way, both the RIPE and ARIN websites say Martinique its part of the ARIN region. https://www.arin.net/knowledge/rirs/ARINcountries.html https://www.ripe.net/participate/member-support/list-of-members/list-of-country-codes-and-rirs Thanks. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From adudek16 at gmail.com Mon Feb 5 13:55:33 2018 From: adudek16 at gmail.com (Aaron Dudek) Date: Mon, 5 Feb 2018 13:55:33 -0500 Subject: [arin-ppml] ARIN-PPML 2018-1 In-Reply-To: References: Message-ID: We ran an international network with a single ASN using addresses from ARIN, RIPE, and APNIC with no issues. Aaron On Mon, Feb 5, 2018 at 9:38 AM, William Herrin wrote: > On Mon, Feb 5, 2018 at 9:11 AM, Rudolph Daniel wrote: >> I need a small clarification. >> The Caribbean region has 3 RIRs >> >> St Lucia is ARIN, Trinidad is LACNIC and Martinique is RIPE >> If my base is arin and offer wholesale services to same geo. Region >> countries.. Trinidad (lacnic) and Martinique (Ripe), do i need 3 separate AS >> numbers? > > Hi Rudolph, > > Under ARIN rules, there is no need for separate AS numbers. I can't > speak for RIPE or LACNIC rules, or for any rules imposed by your > upstream network providers. > > Regards, > Bill Herrin > > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From daveid at panix.com Mon Feb 5 14:54:01 2018 From: daveid at panix.com (David R Huberman) Date: Mon, 5 Feb 2018 14:54:01 -0500 (EST) Subject: [arin-ppml] ARIN-PPML 2018-1 In-Reply-To: References: Message-ID: If I may, I'd like to try and re-focus the discussion of 2018-1 on the network engineering problem that prompted this draft proposal. The solution this draft policy proposal offers to the problem is where I think the real value is, and where I think PPML needs to focus. Since the publication of RFC1997 in the 1996, network engineers have utilized an extension of BGP called the BGP communities attribute to enginer traffic (to "shape traffic") in a desirable way. RFC1997 only supports the use of 2-byte ASNs. As the free pool of 2-byte ASNs began to shrink, a solultion was needed to enable networks labelled with 4-byte ASNs to utilize BGP community attributes. In 2010, a draft of Flexible Community attribute was discussed, but no working code was widely released. In 2016, a draft of Wide Comunity attributes was released, but also resulted in no working code. Finally, in February 2017, RFC8092 was published, and Large BGP Communities became the protocol standard for defining 4-byte AS numbers within the BGP community attribute. Working code exists for some equipment and software, is planned for other equipment and software, but the point is that RFC8092-compliant code is not prevelant in the DFZ. This is important because it means a network operator who wants to shape their traffic properly with BGP communities still needs a 2-byte ASN or it won't work. This proposal addresses the problem by allowing registrants of an unused or unwanted 2-byte ASN to transfer the registration to a network operator who needs one, all within the existing and community agreed-upon framework of Inter-RIR transfers. For this reason, I support draft policy proposal ARIN-2008-1. From apotter at hilcoglobal.com Mon Feb 5 16:12:01 2018 From: apotter at hilcoglobal.com (Potter, Amy) Date: Mon, 5 Feb 2018 21:12:01 +0000 Subject: [arin-ppml] Draft Policy 2017-03: Update to NPRM 3.6: Annual Whois POC Validation Message-ID: <62DD04C9CA033342B055D0C8BFE2A0FC013F3FB664@NB-EXCH10.hgag.hilcotrading.com> In response to the staff & legal assessment for 2017-3, we are proposing the following new language for subsection 3.6.5: 3.6.5 An invalid POC is restricted to payment and contact update functionality within ARIN Online. As a result, an organization without any valid POCs will be unable to access further functionalities within ARIN Online until at least one Admin or Tech POC validates that their information is accurate or modifies a POC to contain accurate information. ARIN STAFF & LEGAL ASSESSMENT Draft Policy ARIN-2017-03 Update to NPRM 3.6: Annual Whois POC Validation https://arin.net/policy/proposals/2017_3.html Date of Assessment: 3 January 2018 ___ 1. Summary (Staff Understanding) Draft Policy 2017-03 establishes the specific Whois Points of Contact (POCs) that are required to be verified annually. It further identifies which organizations are covered by this policy according to the type of resources that it holds i.e. direct assignments, direct allocations, AS numbers from ARIN (or one of its predecessor registries) or a reallocation from an upstream ISP. It specifically excludes reassignments made to downstream end user customers. DP 2017-03 defines the procedure to be followed to ensure the above specified POCs are verified through an email notification on an annual basis. It instructs ARIN staff to marked POC records deemed completely and permanently abandoned or otherwise illegitimate as invalid in Whois. It also directs action to be taken if an ADMIN or TECH POC has been marked invalid. ___ 2. Comments A. ARIN Staff Comments * 3.6.2 Specified Public Whois Points of Contact for Verification: Lists the 4 types of POCs that must be verified annually. This is very clear. * 3.6.3 Organizations Covered by this Policy: Clearly states qualifications for an Organization's POCs to require annual verification as well as those that do not require it. This is clear. * 3.6.4 Procedure for Verification: Describes the steps in the verification process. This is clear. * 3.6.5 Non-Responsive Point of Contact Records: This section is unclear regarding the scope of the impact to an organization having non-responsive POCs, as the phrase "any organization lacking a validated Admin or Tech POC will be unable to access the full suite of functionality" fails to specify the allowed/prohibited functionality for organizations lacking a valid contact. Absent further clarification, ARIN staff will interpret this to mean that an organization without at least one validated Admin or Tech POC will only be able to access payment and contact update functionality within ARIN Online, regardless of the contact used for access. For organizations that have at least one valid Admin or Tech contact, the organization will be able to access full functionality of ARIN Online, even if access is via one of its other non-responsive POCs. If instead the desired policy outcome is that only a validated Admin or Tech POC may access full ARIN Online functionality, then the policy text should be clarified to that effect. * The proposed policy does not impact ARIN's ability to provide ongoing registry services for number resources, only the ability of impacted organizations to make changes to their number resources and related services. * This policy could be implemented as written. B. ARIN General Counsel - Legal Assessment * There are no material legal issues regarding this proposal. ___ 3. Resource Impact Implementation of this policy would have minimal resource impact. It is estimated that implementation could occur within 3 months after ratification by the ARIN Board of Trustees. The following would be needed in order to implement: * Updated guidelines and internal procedures * Staff training * Minimal engineering work ___ 4. Proposal / Draft Policy Text Assessed Draft Policy ARIN-2017-3: Update to NPRM 3.6: Annual Whois POC Validation Version Date: 14 November 2017 Problem Statement: Many of the Point of Contacts listed in ARIN's public Whois database contain out-of-date and inaccurate contact information. Policy Statement: Current Text: 3.6 Annual Whois POC Validation 3.6.1 Method of Annual Verification During ARIN's annual Whois POC validation, an email will be sent to every POC in the Whois database. Each POC will have a maximum of 60 days to respond with an affirmative that their Whois contact information is correct and complete. Unresponsive POC email addresses shall be marked as such in the database. If ARIN staff deems a POC to be completely and permanently abandoned or otherwise illegitimate, the POC record shall be marked invalid. ARIN will maintain, and make readily available to the community, a current list of number resources with no valid POC; this data will be subject to the current bulk Whois policy. Proposed Revised Text: 3.6 Annual Validation of ARIN's Public Whois Point of Contact Data 3.6.1 Annual POC Verification ARIN will perform an annual verification of specific Points of Contact registered in the public Whois using the criteria and procedures outlined in sections 3.6.2, 3.6.3, and 3.6.4. 3.6.2 Specified Public Whois Points of Contact for Verification Each of the following Points of Contact are to be verified annually, and will be referred to as Point of Contact or POC throughout this policy, and should be understood to be both organization and resource POCs: - Admin - Tech - NOC - Abuse 3.6.3 Organizations Covered by this Policy This policy applies to every Organization that has a direct assignment, direct allocation, or AS number from ARIN (or one of its predecessor registries) or a reallocation from an upstream ISP. This includes but is not limited to upstream ISPs and their downstream ISP customers (as defined by NRPM 2.5 and 2.6), but not reassignments made to their downstream end user customers. 3.6.4 Procedure for Verification An annual email notification will be sent to each of the Points of Contact outlined in section 3.6.2 on an annual basis. Each Point of Contact will have up to sixty (60) days from the date of the notification in which to respond with an affirmative that their Whois contact information is correct and complete or to submit new data to correct and complete it. If after careful analysis, ARIN staff deems a POC to be completely and permanently abandoned or otherwise illegitimate, the POC record shall be marked invalid in Whois. 3.6.5 Non-Responsive Point of Contact Records Once a non-responsive POC has been marked invalid in the public Whois, any organization lacking a validated Admin or Tech POC will be unable to access the full suite of functionality within ARIN Online until the invalid POC(s) have either validated that their information is accurate or modified their POC to contain up-to-date information. Comments: Timetable for implementation: to be based upon discussions with ARIN's staff. -------------- next part -------------- An HTML attachment was scrubbed... URL: From job at instituut.net Thu Feb 1 13:29:52 2018 From: job at instituut.net (Job Snijders) Date: Thu, 1 Feb 2018 18:29:52 +0000 Subject: [arin-ppml] IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers In-Reply-To: <47325565b96e4adaa6214be0f0d293da@DG2MBX04-DOR.bell.corp.bce.ca> References: <47325565b96e4adaa6214be0f0d293da@DG2MBX04-DOR.bell.corp.bce.ca> Message-ID: <20180201182952.GR87376@vurt.meerval.net> 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 From hostmaster at uneedus.com Tue Feb 6 12:02:45 2018 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Tue, 6 Feb 2018 12:02:45 -0500 (EST) Subject: [arin-ppml] IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers In-Reply-To: <20180201182952.GR87376@vurt.meerval.net> References: <47325565b96e4adaa6214be0f0d293da@DG2MBX04-DOR.bell.corp.bce.ca> <20180201182952.GR87376@vurt.meerval.net> Message-ID: 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 +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 (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From owen at delong.com Tue Feb 6 13:08:12 2018 From: owen at delong.com (Owen DeLong) Date: Tue, 6 Feb 2018 10:08:12 -0800 Subject: [arin-ppml] IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers In-Reply-To: References: <47325565b96e4adaa6214be0f0d293da@DG2MBX04-DOR.bell.corp.bce.ca> <20180201182952.GR87376@vurt.meerval.net> Message-ID: > On Feb 6, 2018, at 09:02 , hostmaster at 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 +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 (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at 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 at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From owen at delong.com Tue Feb 6 13:10:35 2018 From: owen at delong.com (Owen DeLong) Date: Tue, 6 Feb 2018 10:10:35 -0800 Subject: [arin-ppml] IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers In-Reply-To: <20180201182952.GR87376@vurt.meerval.net> References: <47325565b96e4adaa6214be0f0d293da@DG2MBX04-DOR.bell.corp.bce.ca> <20180201182952.GR87376@vurt.meerval.net> Message-ID: 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 +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 (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From chris at semihuman.com Tue Feb 6 13:27:55 2018 From: chris at semihuman.com (Chris Woodfield) Date: Tue, 6 Feb 2018 10:27:55 -0800 Subject: [arin-ppml] IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers In-Reply-To: References: <47325565b96e4adaa6214be0f0d293da@DG2MBX04-DOR.bell.corp.bce.ca> <20180201182952.GR87376@vurt.meerval.net> Message-ID: <8F208363-9080-480F-85D3-4AA8925B6564@semihuman.com> 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 , hostmaster at 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 +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 (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at 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 at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at 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 at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From owen at delong.com Tue Feb 6 13:40:57 2018 From: owen at delong.com (Owen DeLong) Date: Tue, 6 Feb 2018 10:40:57 -0800 Subject: [arin-ppml] Draft Policy 2017-03: Update to NPRM 3.6: Annual Whois POC Validation In-Reply-To: <62DD04C9CA033342B055D0C8BFE2A0FC013F3FB664@NB-EXCH10.hgag.hilcotrading.com> References: <62DD04C9CA033342B055D0C8BFE2A0FC013F3FB664@NB-EXCH10.hgag.hilcotrading.com> Message-ID: <3C8B90F0-4F6E-4D9A-A0CD-606E6785778C@delong.com> +1 works for me. Owen > On Feb 5, 2018, at 13:12 , Potter, Amy wrote: > > In response to the staff & legal assessment for 2017-3, we are proposing the following new language for subsection 3.6.5: > > 3.6.5 > > An invalid POC is restricted to payment and contact update functionality within ARIN Online. As a result, an organization without any valid POCs will be unable to access further functionalities within ARIN Online until at least one Admin or Tech POC validates that their information is accurate or modifies a POC to contain accurate information. > > ARIN STAFF & LEGAL ASSESSMENT > Draft Policy ARIN-2017-03 > Update to NPRM 3.6: Annual Whois POC Validation > https://arin.net/policy/proposals/2017_3.html > > > Date of Assessment: 3 January 2018 > > ___ > 1. Summary (Staff Understanding) > > Draft Policy 2017-03 establishes the specific Whois Points of Contact (POCs) that are required to be verified annually. It further identifies which organizations are covered by this policy according to the type of resources that it holds i.e. direct assignments, direct allocations, AS numbers from ARIN (or one of its predecessor registries) or a reallocation from an upstream ISP. It specifically excludes reassignments made to downstream end user customers. DP 2017-03 defines the procedure to be followed to ensure the above specified POCs are verified through an email notification on an annual basis. It instructs ARIN staff to marked POC records deemed completely and permanently abandoned or otherwise illegitimate as invalid in Whois. It also directs action to be taken if an ADMIN or TECH POC has been marked invalid. > > ___ > 2. Comments > > A. ARIN Staff Comments > > * 3.6.2 Specified Public Whois Points of Contact for Verification: Lists the 4 types of POCs that must be verified annually. This is very clear. > * 3.6.3 Organizations Covered by this Policy: Clearly states qualifications for an Organization?s POCs to require annual verification as well as those that do not require it. This is clear. > * 3.6.4 Procedure for Verification: Describes the steps in the verification process. This is clear. > * 3.6.5 Non-Responsive Point of Contact Records: This section is unclear regarding the scope of the impact to an organization having non-responsive POCs, as the phrase "any organization lacking a validated Admin or Tech POC will be unable to access the full suite of functionality? fails to specify the allowed/prohibited functionality for organizations lacking a valid contact. Absent further clarification, ARIN staff will interpret this to mean that an organization without at least one validated Admin or Tech POC will only be able to access payment and contact update functionality within ARIN Online, regardless of the contact used for access. For organizations that have at least one valid Admin or Tech contact, the organization will be able to access full functionality of ARIN Online, even if access is via one of its other non-responsive POCs. If instead the desired policy outcome is that only a validated Admin or Tech POC may access full ARIN Online functionality, then the policy text should be clarified to that effect. > * The proposed policy does not impact ARIN?s ability to provide ongoing registry services for number resources, only the ability of impacted organizations to make changes to their number resources and related services. > * This policy could be implemented as written. > > B. ARIN General Counsel ? Legal Assessment > > * There are no material legal issues regarding this proposal. > > > ___ > 3. Resource Impact > > Implementation of this policy would have minimal resource impact. It is estimated that implementation could occur within 3 months after ratification by the ARIN Board of Trustees. The following would be needed in order to implement: > > * Updated guidelines and internal procedures > * Staff training > * Minimal engineering work > > ___ > 4. Proposal / Draft Policy Text Assessed > > Draft Policy ARIN-2017-3: Update to NPRM 3.6: Annual Whois POC Validation > > Version Date: 14 November 2017 > > Problem Statement: > > Many of the Point of Contacts listed in ARIN's public Whois database contain out-of-date and inaccurate contact information. > > Policy Statement: > > Current Text: > > 3.6 Annual Whois POC Validation > 3.6.1 Method of Annual Verification > During ARIN's annual Whois POC validation, an email will be sent to every POC in the Whois database. Each POC will have a maximum of 60 days to respond with an affirmative that their Whois contact information is correct and complete. Unresponsive POC email addresses shall be marked as such in the database. If ARIN staff deems a POC to be completely and permanently abandoned or otherwise illegitimate, the POC record shall be marked invalid. ARIN will maintain, and make readily available to the community, a current list of number resources with no valid POC; this data will be subject to the current bulk Whois policy. > > Proposed Revised Text: > > 3.6 Annual Validation of ARIN's Public Whois Point of Contact Data > 3.6.1 Annual POC Verification > ARIN will perform an annual verification of specific Points of Contact registered in the public Whois using the criteria and procedures outlined in sections 3.6.2, 3.6.3, and 3.6.4. > 3.6.2 Specified Public Whois Points of Contact for Verification > Each of the following Points of Contact are to be verified annually, and will be referred to as Point of Contact or POC throughout this policy, and should be understood to be both organization and resource POCs: > - Admin > - Tech > - NOC > - Abuse > 3.6.3 Organizations Covered by this Policy > This policy applies to every Organization that has a direct assignment, direct allocation, or AS number from ARIN (or one of its predecessor registries) or a reallocation from an upstream ISP. This includes but is not limited to upstream ISPs and their downstream ISP customers (as defined by NRPM 2.5 and 2.6), but not reassignments made to their downstream end user customers. > 3.6.4 Procedure for Verification > An annual email notification will be sent to each of the Points of Contact outlined in section 3.6.2 on an annual basis. Each Point of Contact will have up to sixty (60) days from the date of the notification in which to respond with an affirmative that their Whois contact information is correct and complete or to submit new data to correct and complete it. If after careful analysis, ARIN staff deems a POC to be completely and permanently abandoned or otherwise illegitimate, the POC record shall be marked invalid in Whois. > 3.6.5 Non-Responsive Point of Contact Records > Once a non-responsive POC has been marked invalid in the public Whois, any organization lacking a validated Admin or Tech POC will be unable to access the full suite of functionality within ARIN Online until the invalid POC(s) have either validated that their information is accurate or modified their POC to contain up-to-date information. > > Comments: > > Timetable for implementation: to be based upon discussions with ARIN's staff. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Tue Feb 6 13:53:01 2018 From: owen at delong.com (Owen DeLong) Date: Tue, 6 Feb 2018 10:53:01 -0800 Subject: [arin-ppml] ARIN-PPML 2018-1 In-Reply-To: References: Message-ID: I will note that there is also working code widely deployed for extended communities which do have formats which can work for all currently issued 32-bit ASNs. (RFCs 4360 and 7153) Owen > On Feb 5, 2018, at 11:54 , David R Huberman wrote: > > > If I may, I'd like to try and re-focus the discussion of 2018-1 on the network engineering problem that prompted this draft proposal. The solution this draft policy proposal offers to the problem is where I think the real value is, and where I think PPML needs to focus. > > Since the publication of RFC1997 in the 1996, network engineers have utilized an extension of BGP called the BGP communities attribute to enginer traffic (to "shape traffic") in a desirable way. > > RFC1997 only supports the use of 2-byte ASNs. As the free pool of 2-byte ASNs began to shrink, a solultion was needed to enable networks labelled with 4-byte ASNs to utilize BGP community attributes. > > In 2010, a draft of Flexible Community attribute was discussed, but no working code was widely released. In 2016, a draft of Wide Comunity attributes was released, but also resulted in no working code. Finally, in February 2017, RFC8092 was published, and Large BGP Communities became the protocol standard for defining 4-byte AS numbers within the BGP community attribute. > > Working code exists for some equipment and software, is planned for other equipment and software, but the point is that RFC8092-compliant code is not prevelant in the DFZ. This is important because it means a network operator who wants to shape their traffic properly with BGP communities still needs a 2-byte ASN or it won't work. > > This proposal addresses the problem by allowing registrants of an unused or unwanted 2-byte ASN to transfer the registration to a network operator who needs one, all within the existing and community agreed-upon framework of Inter-RIR transfers. > > For this reason, I support draft policy proposal ARIN-2008-1. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From bill at herrin.us Tue Feb 6 14:16:42 2018 From: bill at herrin.us (William Herrin) Date: Tue, 6 Feb 2018 14:16:42 -0500 Subject: [arin-ppml] Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers In-Reply-To: <5b901b94-f0b8-276b-2c9d-1b27bcb54442@arin.net> References: <5b901b94-f0b8-276b-2c9d-1b27bcb54442@arin.net> Message-ID: On Wed, Jan 31, 2018 at 2:20 PM, ARIN wrote: > Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers > > Problem Statement: > There is a need to allow RIR transfers of ASNs with RIRs with an equivalent > transfer policy. Hello, I OPPOSE the transfer of number resources to APNIC where restrictions by LIRS like China have the practical effect of a discordant, non-recpirocal transfer policy. I would support the transfer of AS numbers in the generic case if this discordant policy problem could be satisfactorily solved. I consider the discordant policy problem to be more significant than what I see as the relatively minor technical need for AS number transfers, especially across RIRs. For lack of any compelling reason to disallow it, I support AS number transfers within the ARIN region. > Policy Statement: > > Change the first sentence in section 8.4 from: > > "Inter-regional transfers may take place only via RIRs who agree to the > transfer and share reciprocal, compatible, needs-based policies." > > To: > > "Inter-regional transfers of IPv4 number resources and ASNs may take place > only via RIRs who agree to the transfer and share reciprocal, compatible > needs-based policies." I think this text is clumsy and it does not fit well with the rest of section 8.4 which focuses on IPv4 addresses. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From owen at delong.com Tue Feb 6 15:25:05 2018 From: owen at delong.com (Owen DeLong) Date: Tue, 6 Feb 2018 12:25:05 -0800 Subject: [arin-ppml] IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers In-Reply-To: <8F208363-9080-480F-85D3-4AA8925B6564@semihuman.com> References: <47325565b96e4adaa6214be0f0d293da@DG2MBX04-DOR.bell.corp.bce.ca> <20180201182952.GR87376@vurt.meerval.net> <8F208363-9080-480F-85D3-4AA8925B6564@semihuman.com> Message-ID: <18294769-563D-4A7E-8786-78AFD849D2D6@delong.com> 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 , hostmaster at 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 +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 (ARIN-PPML at arin.net). >>>> Unsubscribe or manage your mailing list subscription at: >>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>> Please contact info at 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 at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at 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 at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> > From job at ntt.net Tue Feb 6 15:31:32 2018 From: job at ntt.net (Job Snijders) Date: Tue, 6 Feb 2018 20:31:32 +0000 Subject: [arin-ppml] IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers In-Reply-To: <18294769-563D-4A7E-8786-78AFD849D2D6@delong.com> References: <47325565b96e4adaa6214be0f0d293da@DG2MBX04-DOR.bell.corp.bce.ca> <20180201182952.GR87376@vurt.meerval.net> <8F208363-9080-480F-85D3-4AA8925B6564@semihuman.com> <18294769-563D-4A7E-8786-78AFD849D2D6@delong.com> Message-ID: <20180206203132.GJ5974@vurt.meerval.net> 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 From chris at semihuman.com Tue Feb 6 16:13:05 2018 From: chris at semihuman.com (Chris Woodfield) Date: Tue, 6 Feb 2018 13:13:05 -0800 Subject: [arin-ppml] IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers In-Reply-To: <20180206203933.GK5974@vurt.meerval.net> References: <47325565b96e4adaa6214be0f0d293da@DG2MBX04-DOR.bell.corp.bce.ca> <20180201182952.GR87376@vurt.meerval.net> <8F208363-9080-480F-85D3-4AA8925B6564@semihuman.com> <20180206203933.GK5974@vurt.meerval.net> Message-ID: <7805AEC0-3788-4DBA-84C5-93BC82EE4F4B@semihuman.com> 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 > From narten at us.ibm.com Fri Feb 9 00:53:02 2018 From: narten at us.ibm.com (narten at us.ibm.com) Date: Fri, 09 Feb 2018 00:53:02 -0500 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201802090553.w195r3KG004086@rotala.raleigh.ibm.com> Total of 24 messages in the last 7 days. script run at: Fri Feb 9 00:53:02 EST 2018 Messages | Bytes | Who --------+------+--------+----------+------------------------ 20.83% | 5 | 21.38% | 91283 | owen at delong.com 4.17% | 1 | 21.99% | 93872 | rudi.daniel at gmail.com 8.33% | 2 | 6.39% | 27272 | adudek16 at gmail.com 8.33% | 2 | 6.22% | 26556 | hostmaster at uneedus.com 8.33% | 2 | 5.02% | 21445 | chris at semihuman.com 8.33% | 2 | 4.49% | 19152 | job at ntt.net 8.33% | 2 | 4.40% | 18796 | bill at herrin.us 4.17% | 1 | 7.13% | 30425 | apotter at hilcoglobal.com 4.17% | 1 | 5.37% | 22906 | chevykilla.14 at gmail.com 4.17% | 1 | 4.62% | 19718 | scottleibrand at gmail.com 4.17% | 1 | 3.91% | 16697 | farmer at umn.edu 4.17% | 1 | 2.46% | 10501 | narten at us.ibm.com 4.17% | 1 | 2.33% | 9946 | job at instituut.net 4.17% | 1 | 2.21% | 9436 | daveid at panix.com 4.17% | 1 | 2.07% | 8853 | sergio at lacnic.net --------+------+--------+----------+------------------------ 100.00% | 24 |100.00% | 426858 | Total From joewamuga at gmail.com Fri Feb 9 05:42:15 2018 From: joewamuga at gmail.com (Joe Mwangi) Date: Fri, 9 Feb 2018 13:42:15 +0300 Subject: [arin-ppml] subscription Message-ID: Am interested in the subscription Joseph. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevinpowell2005 at hotmail.com Fri Feb 9 09:40:44 2018 From: kevinpowell2005 at hotmail.com (Kevin Powell) Date: Fri, 9 Feb 2018 14:40:44 +0000 Subject: [arin-ppml] Net-Neutrality and its impact Message-ID: Any thoughts on the possible impact/implication of the move to end net neutrality, especially on developing countries like Jamaica and other Caribbean countries. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Fri Feb 9 11:46:33 2018 From: bill at herrin.us (William Herrin) Date: Fri, 9 Feb 2018 11:46:33 -0500 Subject: [arin-ppml] Net-Neutrality and its impact In-Reply-To: References: Message-ID: On Fri, Feb 9, 2018 at 9:40 AM, Kevin Powell wrote: > Any thoughts on the possible impact/implication of the move to end net > neutrality, especially on developing countries like Jamaica and other > Caribbean countries. The whole thing is a farce. QoS/traffic shaping is only used when the network is in bad shape to begin with, i.e. ripe to be picked off by competitors. Adjusting the rules about whether you're allowed to do traffic shaping won't impact the abysmal technical conditions that have to exist for it to be seriously considered. Peering policy has and has had a more substantial impact on network neutrality. All the big networks have closed peering policies. Everyone who doesn't meet the criteria of "we can't force them to pay and would look silly trying" gets roped in to the double-billing fraud where each packet must be paid for both by the content provider and the end user. And any existing peer who dares to defy us by accepting a high rate customer we want to fleece gets punished through the simple expedient of not upgrading the data rates on the peered connections. This was true under the FCC's so-called net neutrality and it remains true now that net neutrality has been revoked. So, this is off topic here; ARIN doesn't do routing and transit. NANOG is probably a better forum for its discussion. But you asked... Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From farmer at umn.edu Mon Feb 12 13:31:01 2018 From: farmer at umn.edu (David Farmer) Date: Mon, 12 Feb 2018 12:31:01 -0600 Subject: [arin-ppml] Revised - Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers In-Reply-To: References: Message-ID: I need more input from the community on this one. Unless you are one of the two people who has responded already, please take time to respond to the following questions. Thank you. On Wed, Jan 31, 2018 at 3:18 PM, David Farmer wrote: > There seems to be a bit of controversy on the direction to take this > policy. Therefore as the shepherd, it would be helpful to hear from > additional community members regarding this policy. > > Do you support or oppose the policy as written? > > Do you think the inconsistency described in the Problem Statement should > be corrected? > > If yes, should it be corrected by revising by section 8.5.4 to be > consistent with section 4.2.2, as proposed by the current text? > > Or, as an alternative by revising section 4.2.2 to be consistent with > section 8.5.4? > > Are there other alternatives to correct the inconsistency to be considered? > > Other suggestions or comments? > > Your additional feedback and participation are appreciated, thank you. > > On Wed, Jan 24, 2018 at 7:42 AM, ARIN wrote: > >> The following has been revised: >> >> * Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 >> ISP Transfers >> >> Revised text is below and can be found at: >> https://www.arin.net/policy/proposals/2017_9.html >> >> You are encouraged to discuss all Draft Policies on PPML. The AC will >> evaluate the discussion in order to assess the conformance of this draft >> policy with ARIN's Principles of Internet number resource policy as stated >> in the Policy Development Process (PDP). Specifically, these principles are: >> >> * Enabling Fair and Impartial Number Resource Administration >> * Technically Sound >> * Supported by the Community >> >> The PDP can be found at: >> https://www.arin.net/policy/pdp.html >> >> Draft Policies and Proposals under discussion can be found at: >> https://www.arin.net/policy/proposals/index.html >> >> Regards, >> >> Sean Hopkins >> Policy Analyst >> American Registry for Internet Numbers (ARIN) >> >> >> >> Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 >> ISP Transfers >> >> Problem Statement: >> >> It was noted in the ARIN 40 Policy Experience Report, that there is an >> inconsistency in the initial block size for ISPs. Section 4.2.2 notes that >> the initial ISP block size should be /21 whereas the initial block size in >> 8.5.4 is noted as "minimum transfer size" which is effectively a /24. This >> causes ISP organizations to be approved for different initial block size >> depending on if they first apply for a transfer directly under section 8 or >> if they apply for a block under section 4. This policy is intended to >> clarify this issue, by setting a consistent ISP initial IPv4 block size. It >> was noted that ARIN staff current operational practice is to allow >> qualified ISPs an initial /21 for Section 8 transfers when they first apply >> and are approved under section 4. If an organization applies under section >> 8 first they are initially qualified for a /24; larger allocations require >> additional documentation as noted in 8.5.5. >> >> Policy statement: >> >> Replace section 8.5.4; >> >> 8.5.4. Initial block >> >> Organizations without direct assignments or allocations from ARIN qualify >> for the transfer of an initial IPv4 block, a /24 for assignments or a /24 >> up to a /21 for allocations. >> >> Comments: >> >> Timetable for implementation: Immediate >> >> Anything Else: >> >> The ARIN 40 Policy Experience Report is available at; >> >> Slides: https://www.arin.net/vault/participate/meetings/reports/ARIN >> _40/PDF/PPM/sweeting-policy-experience.pdf >> >> Transcript: https://www.arin.net/vault/participate/meetings/reports/ARIN >> _40/ppm1_transcript.html#anchor_5 >> >> Video: https://www.youtube.com/watch?v=QVsfVMG_6fA >> >> Slides 10 - 13, located in the video from 6:30 to 8:30, are the relevant >> portion of the report, questions from the audience follow. >> > > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> > Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> > =============================================== > -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From daveid at panix.com Mon Feb 12 13:48:53 2018 From: daveid at panix.com (David R Huberman) Date: Mon, 12 Feb 2018 13:48:53 -0500 (EST) Subject: [arin-ppml] Revised - Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers In-Reply-To: References: Message-ID: David and PPML, David Farmer asked: > Do you support or oppose the policy as written? I oppose the policy as written. David Farmer also asked: > Do you think the inconsistency described in the Problem Statement > should be corrected? > > If yes, should it be corrected by revising by section 8.5.4 to be > consistent with section 4.2.2, as proposed by the current text? > > Or, as an alternative by revising section 4.2.2 to be consistent with > section 8.5.4? I think 8.5 adequately sets forth criteria for block size. 8.5.5 is especially "generous" (at least, compared to similar needs tests of the last 20 years of ARIN's existence), and is good "one size fits all" policy text. I also think staff are properly applying policy with their current procedures for dealing with any requests justified under 4.2.2 but fulfilled under section 8. I would be in favor of the AC abandoning 2017-9. David From bjones at vt.edu Tue Feb 13 11:36:58 2018 From: bjones at vt.edu (Brian Jones) Date: Tue, 13 Feb 2018 16:36:58 +0000 Subject: [arin-ppml] Revised - Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers In-Reply-To: References: Message-ID: On Mon, Feb 12, 2018 at 1:31 PM David Farmer wrote: > I need more input from the community on this one. Unless you are one of > the two people who has responded already, please take time to respond to > the following questions. > > Thank you. > > On Wed, Jan 31, 2018 at 3:18 PM, David Farmer wrote: > >> There seems to be a bit of controversy on the direction to take this >> policy. Therefore as the shepherd, it would be helpful to hear from >> additional community members regarding this policy. >> >> Do you support or oppose the policy as written? >> > I support the document as written. > >> Do you think the inconsistency described in the Problem Statement should >> be corrected? >> > Yes it should be corrected. > >> If yes, should it be corrected by revising by section 8.5.4 to be >> consistent with section 4.2.2, as proposed by the current text? >> >> Correct as suggested in 8.5.4. > Or, as an alternative by revising section 4.2.2 to be consistent with >> section 8.5.4? >> >> Are there other alternatives to correct the inconsistency to be >> considered? >> >> Other suggestions or comments? >> >> Whichever section is chosen it should be corrected in one or the other for clarity. As written in section 8.5.4 makes the most sense to me. > Your additional feedback and participation are appreciated, thank you. >> > >> On Wed, Jan 24, 2018 at 7:42 AM, ARIN wrote: >> >>> The following has been revised: >>> >>> * Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 >>> ISP Transfers >>> >>> Revised text is below and can be found at: >>> https://www.arin.net/policy/proposals/2017_9.html >>> >>> You are encouraged to discuss all Draft Policies on PPML. The AC will >>> evaluate the discussion in order to assess the conformance of this draft >>> policy with ARIN's Principles of Internet number resource policy as stated >>> in the Policy Development Process (PDP). Specifically, these principles are: >>> >>> * Enabling Fair and Impartial Number Resource Administration >>> * Technically Sound >>> * Supported by the Community >>> >>> The PDP can be found at: >>> https://www.arin.net/policy/pdp.html >>> >>> Draft Policies and Proposals under discussion can be found at: >>> https://www.arin.net/policy/proposals/index.html >>> >>> Regards, >>> >>> Sean Hopkins >>> Policy Analyst >>> American Registry for Internet Numbers (ARIN) >>> >>> >>> >>> Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 >>> ISP Transfers >>> >>> Problem Statement: >>> >>> It was noted in the ARIN 40 Policy Experience Report, that there is an >>> inconsistency in the initial block size for ISPs. Section 4.2.2 notes that >>> the initial ISP block size should be /21 whereas the initial block size in >>> 8.5.4 is noted as "minimum transfer size" which is effectively a /24. This >>> causes ISP organizations to be approved for different initial block size >>> depending on if they first apply for a transfer directly under section 8 or >>> if they apply for a block under section 4. This policy is intended to >>> clarify this issue, by setting a consistent ISP initial IPv4 block size. It >>> was noted that ARIN staff current operational practice is to allow >>> qualified ISPs an initial /21 for Section 8 transfers when they first apply >>> and are approved under section 4. If an organization applies under section >>> 8 first they are initially qualified for a /24; larger allocations require >>> additional documentation as noted in 8.5.5. >>> >>> Policy statement: >>> >>> Replace section 8.5.4; >>> >>> 8.5.4. Initial block >>> >>> Organizations without direct assignments or allocations from ARIN >>> qualify for the transfer of an initial IPv4 block, a /24 for assignments or >>> a /24 up to a /21 for allocations. >>> >>> Comments: >>> >>> Timetable for implementation: Immediate >>> >>> Anything Else: >>> >>> The ARIN 40 Policy Experience Report is available at; >>> >>> Slides: >>> https://www.arin.net/vault/participate/meetings/reports/ARIN_40/PDF/PPM/sweeting-policy-experience.pdf >>> >>> Transcript: >>> https://www.arin.net/vault/participate/meetings/reports/ARIN_40/ppm1_transcript.html#anchor_5 >>> >>> Video: https://www.youtube.com/watch?v=QVsfVMG_6fA >>> >>> Slides 10 - 13, located in the video from 6:30 to 8:30, are the relevant >>> portion of the report, questions from the audience follow. >>> >> -- >> =============================================== >> David Farmer Email:farmer at umn.edu >> Networking & Telecommunication Services >> Office of Information Technology >> University of Minnesota >> 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> >> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> >> =============================================== >> > > > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> > Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> > =============================================== > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjones at vt.edu Tue Feb 13 11:41:09 2018 From: bjones at vt.edu (Brian Jones) Date: Tue, 13 Feb 2018 16:41:09 +0000 Subject: [arin-ppml] IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers In-Reply-To: <7805AEC0-3788-4DBA-84C5-93BC82EE4F4B@semihuman.com> References: <47325565b96e4adaa6214be0f0d293da@DG2MBX04-DOR.bell.corp.bce.ca> <20180201182952.GR87376@vurt.meerval.net> <8F208363-9080-480F-85D3-4AA8925B6564@semihuman.com> <20180206203933.GK5974@vurt.meerval.net> <7805AEC0-3788-4DBA-84C5-93BC82EE4F4B@semihuman.com> Message-ID: 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 at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjones at vt.edu Tue Feb 13 11:46:13 2018 From: bjones at vt.edu (Brian Jones) Date: Tue, 13 Feb 2018 16:46:13 +0000 Subject: [arin-ppml] ARIN-PPML 2018-1 In-Reply-To: References: Message-ID: On Mon, Feb 5, 2018 at 2:54 PM David R Huberman wrote: > > If I may, I'd like to try and re-focus the discussion of 2018-1 on the > network engineering problem that prompted this draft proposal. The > solution this draft policy proposal offers to the problem is where I think > the real value is, and where I think PPML needs to focus. > > Since the publication of RFC1997 in the 1996, network engineers have > utilized an extension of BGP called the BGP communities attribute to > enginer traffic (to "shape traffic") in a desirable way. > > RFC1997 only supports the use of 2-byte ASNs. As the free pool of 2-byte > ASNs began to shrink, a solultion was needed to enable networks > labelled with 4-byte ASNs to utilize BGP community attributes. > > In 2010, a draft of Flexible Community attribute was discussed, but no > working code was widely released. In 2016, a draft of Wide Comunity > attributes was released, but also resulted in no working code. Finally, > in February 2017, RFC8092 was published, and Large BGP Communities became > the protocol standard for defining 4-byte AS numbers within the BGP > community attribute. > > Working code exists for some equipment and software, is planned for other > equipment and software, but the point is that RFC8092-compliant code is > not prevelant in the DFZ. This is important because it means a network > operator who wants to shape their traffic properly with BGP communities > still needs a 2-byte ASN or it won't work. > > This proposal addresses the problem by allowing registrants of an unused > or unwanted 2-byte ASN to transfer the registration to a network operator > who needs one, all within the existing and community agreed-upon framework > of Inter-RIR transfers. > > For this reason, I support draft policy proposal ARIN-2008-1. > > I support this proposal for the same reason given: ?This proposal addresses the problem by allowing registrants of an unused or unwanted 2-byte ASN to transfer the registration to a network operator who needs one, all within the existing and community agreed-upon framework of Inter-RIR transfers." ? Brian > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjones at vt.edu Tue Feb 13 11:48:00 2018 From: bjones at vt.edu (Brian Jones) Date: Tue, 13 Feb 2018 16:48:00 +0000 Subject: [arin-ppml] Draft Policy 2017-03: Update to NPRM 3.6: Annual Whois POC Validation In-Reply-To: <62DD04C9CA033342B055D0C8BFE2A0FC013F3FB664@NB-EXCH10.hgag.hilcotrading.com> References: <62DD04C9CA033342B055D0C8BFE2A0FC013F3FB664@NB-EXCH10.hgag.hilcotrading.com> Message-ID: I support this draft policy with the new language. ? Brian On Mon, Feb 5, 2018 at 4:12 PM Potter, Amy wrote: > In response to the staff & legal assessment for 2017-3, we are proposing > the following new language for subsection 3.6.5: > > > > 3.6.5 > > An invalid POC is restricted to payment and contact update functionality > within ARIN Online. As a result, an organization without any valid POCs > will be unable to access further functionalities within ARIN Online until > at least one Admin or Tech POC validates that their information is accurate > or modifies a POC to contain accurate information. > > > > *ARIN STAFF & LEGAL ASSESSMENT* > > *Draft Policy ARIN-2017-03* > > *Update to NPRM 3.6: Annual Whois POC Validation* > > https://arin.net/policy/proposals/2017_3.html > > > > > > *Date of Assessment: 3 January 2018* > > > > ___ > > *1. Summary (Staff Understanding)* > > > > Draft Policy 2017-03 establishes the specific Whois Points of Contact > (POCs) that are required to be verified annually. It further identifies > which organizations are covered by this policy according to the type of > resources that it holds i.e. direct assignments, direct allocations, AS > numbers from ARIN (or one of its predecessor registries) or a reallocation > from an upstream ISP. It specifically excludes reassignments made to > downstream end user customers. DP 2017-03 defines the procedure to be > followed to ensure the above specified POCs are verified through an email > notification on an annual basis. It instructs ARIN staff to marked POC > records deemed completely and permanently abandoned or otherwise > illegitimate as invalid in Whois. It also directs action to be taken if an > ADMIN or TECH POC has been marked invalid. > > > > ___ > > *2. Comments* > > > > A. ARIN Staff Comments > > > > * 3.6.2 Specified Public Whois Points of Contact for Verification: Lists > the 4 types of POCs that must be verified annually. This is very clear. > > * 3.6.3 Organizations Covered by this Policy: Clearly states > qualifications for an Organization?s POCs to require annual verification as > well as those that do not require it. This is clear. > > * 3.6.4 Procedure for Verification: Describes the steps in the > verification process. This is clear. > > * 3.6.5 Non-Responsive Point of Contact Records: This section is unclear > regarding the scope of the impact to an organization having non-responsive > POCs, as the phrase "any organization lacking a validated Admin or Tech POC > will be unable to access the full suite of functionality? fails to specify > the allowed/prohibited functionality for organizations lacking a valid > contact. Absent further clarification, ARIN staff will interpret this to > mean that an organization without at least one validated Admin or Tech POC > will only be able to access payment and contact update functionality within > ARIN Online, regardless of the contact used for access. For organizations > that have at least one valid Admin or Tech contact, the organization will > be able to access full functionality of ARIN Online, even if access is via > one of its other non-responsive POCs. If instead the desired policy > outcome is that only a validated Admin or Tech POC may access full ARIN > Online functionality, then the policy text should be clarified to that > effect. > > * The proposed policy does not impact ARIN?s ability to provide ongoing > registry services for number resources, only the ability of impacted > organizations to make changes to their number resources and related > services. > > * This policy could be implemented as written. > > > > *B. ARIN General Counsel ? Legal Assessment* > > > > * There are no material legal issues regarding this proposal. > > > > > > ___ > > *3. Resource Impact* > > > > Implementation of this policy would have minimal resource impact. It is > estimated that implementation could occur within 3 months after > ratification by the ARIN Board of Trustees. The following would be needed > in order to implement: > > > > * Updated guidelines and internal procedures > > * Staff training > > * Minimal engineering work > > > > ___ > > 4*. Proposal / Draft Policy Text Assessed* > > > > Draft Policy ARIN-2017-3: Update to NPRM 3.6: Annual Whois POC Validation > > > > *Version Date:* 14 November 2017 > > > > *Problem Statement:* > > > > Many of the Point of Contacts listed in ARIN's public Whois database > contain out-of-date and inaccurate contact information. > > > > *Policy Statement:* > > > > *Current Text*: > > > > 3.6 Annual Whois POC Validation > > 3.6.1 Method of Annual Verification > > During ARIN's annual Whois POC validation, an email will be sent to every > POC in the Whois database. Each POC will have a maximum of 60 days to > respond with an affirmative that their Whois contact information is correct > and complete. Unresponsive POC email addresses shall be marked as such in > the database. If ARIN staff deems a POC to be completely and permanently > abandoned or otherwise illegitimate, the POC record shall be marked > invalid. ARIN will maintain, and make readily available to the community, a > current list of number resources with no valid POC; this data will be > subject to the current bulk Whois policy. > > > > *Proposed Revised Text*: > > > > 3.6 Annual Validation of ARIN's Public Whois Point of Contact Data > > 3.6.1 Annual POC Verification > > ARIN will perform an annual verification of specific Points of Contact > registered in the public Whois using the criteria and procedures outlined > in sections 3.6.2, 3.6.3, and 3.6.4. > > 3.6.2 Specified Public Whois Points of Contact for Verification > > Each of the following Points of Contact are to be verified annually, and > will be referred to as Point of Contact or POC throughout this policy, and > should be understood to be both organization and resource POCs: > > - Admin > - Tech > - NOC > - Abuse > > 3.6.3 Organizations Covered by this Policy > > This policy applies to every Organization that has a direct assignment, > direct allocation, or AS number from ARIN (or one of its predecessor > registries) or a reallocation from an upstream ISP. This includes but is > not limited to upstream ISPs and their downstream ISP customers (as defined > by NRPM 2.5 and 2.6), but not reassignments made to their downstream end > user customers. > > 3.6.4 Procedure for Verification > > An annual email notification will be sent to each of the Points of Contact > outlined in section 3.6.2 on an annual basis. Each Point of Contact will > have up to sixty (60) days from the date of the notification in which to > respond with an affirmative that their Whois contact information is correct > and complete or to submit new data to correct and complete it. If after > careful analysis, ARIN staff deems a POC to be completely and permanently > abandoned or otherwise illegitimate, the POC record shall be marked invalid > in Whois. > > 3.6.5 Non-Responsive Point of Contact Records > > Once a non-responsive POC has been marked invalid in the public Whois, any > organization lacking a validated Admin or Tech POC will be unable to access > the full suite of functionality within ARIN Online until the invalid POC(s) > have either validated that their information is accurate or > modified their POC to contain up-to-date information. > > > > *Comments:* > > > > Timetable for implementation: to be based upon discussions with ARIN's > staff. > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjones at vt.edu Tue Feb 13 13:45:04 2018 From: bjones at vt.edu (Brian Jones) Date: Tue, 13 Feb 2018 18:45:04 +0000 Subject: [arin-ppml] Revised/Re-titled - Draft Policy ARIN-2017-8: Amend Community Networks In-Reply-To: References: <73e07de6-7271-2c1b-c1d6-0788c5d96c74@arin.net> Message-ID: Don?t know if I responded to this for sure but agree it should be advanced. ? Brian On Wed, Jan 31, 2018 at 3:33 PM David Farmer wrote: > Unless there are additional comments or suggestions, I plan to propose > this Policy is advanced to Recommended Draft Policy at the AC's February > meeting. > > Thanks > > On Wed, Jan 24, 2018 at 7:46 AM, ARIN wrote: > >> The following has been revised and re-titled: >> >> * Draft Policy ARIN-2017-8: Amend Community Networks >> >> Revised text is below and can be found at: >> https://www.arin.net/policy/proposals/2017_8.html >> >> You are encouraged to discuss all Draft Policies on PPML. The AC will >> evaluate the discussion in order to assess the conformance of this draft >> policy with ARIN's Principles of Internet number resource policy as stated >> in the Policy Development Process (PDP). Specifically, these principles are: >> >> * Enabling Fair and Impartial Number Resource Administration >> * Technically Sound >> * Supported by the Community >> >> The PDP can be found at: >> https://www.arin.net/policy/pdp.html >> >> Draft Policies and Proposals under discussion can be found at: >> https://www.arin.net/policy/proposals/index.html >> >> Regards, >> >> Sean Hopkins >> Policy Analyst >> American Registry for Internet Numbers (ARIN) >> >> >> >> >> >> Draft Policy ARIN-2017-8: Amend Community Networks >> >> Problem Statement: >> >> The Community Networks section of the NRPM has only been used once since >> implementation in January 2010. Proposal ARIN-2016-7, to increase the >> number of use cases, was abandoned by the Advisory Council due to lack of >> feedback. Proposal ARIN 2017-2, to remove all mention of community networks >> from NRPM met with opposition by the community. Many responded that the >> definition of "community network" was too narrow, which could be the reason >> for lack of uptake. >> >> In the discussion at ARIN 40, it was clear that more than just the >> definition of a community network needed revision and that community >> networks need to have allocations, not assignments. Additionally, community >> networks need to make reassignments to end-users in accordance with >> applicable policies. >> ?????? >> Policy statement: >> >> Replace section 2.11 with the following; >> >> 2.11 Community Network >> >> A community network is deployed, operated, and governed by its users, for >> the purpose of providing free or low-cost connectivity to the community it >> services. Users of the network or other volunteers must play a primary role >> in the governance of the organization, whereas other functions may be >> handled by either paid staff or volunteers. >> >> Rename section 6.5.9 and revise the last sentence as follows; >> >> 6.5.9. Community Network Allocations >> >> +1 > While community networks would normally be considered to be ISP type >> organizations under existing ARIN criteria, they tend to operate on much >> tighter budgets and often depend on volunteer labor. As a result, they tend >> to be much smaller and more communal in their organization rather than >> provider/customer relationships of commercial ISPs. This section seeks to >> provide a policy that is more friendly to those environments by allowing >> community network to receive a smaller allocation than other LIRs or >> commercial ISPs. >> >> +1 > Community networks may also qualify under section 6.5.2 as a regular LIR. >> >> Section 6.5.9.1 is not changing, but is included here for completeness; >> >> 6.5.9.1. Qualification Criteria >> >> To qualify under this section, a community network must demonstrate to >> ARIN's satisfaction that it meets the definition of a community network >> under section 2.11 of the NRPM. >> >> Replace section 6.5.9.2 and 6.5.9.3 with the following; >> >> 6.5.9.2. Allocation Size >> >> Community networks are eligible only to receive an allocation of /40 of >> IPv6 resources under this section. Community networks that wish to receive >> a larger initial allocation or any subsequent allocations must qualify as a >> regular LIR, see sections 6.5.2 or 6.5.3 respectively. >> >> 6.5.9.3. Reassignments by Community Networks >> >> Similar to other LIRs, Community networks shall make reassignments to >> end-users in accordance with applicable policies, in particular, but not >> limited to sections 6.5.4 and 6.5.5. However, they shall not reallocate >> resources under this section. >> >> Comments: >> >> Timetable for implementation: Immediate >> >> Anything Else: >> >> The rationale for restricting community networks that receive resources >> through this policy from making reallocations is that a /40 is a tiny IPv6 >> allocation and it does not seem reasonable to subdivide such a small >> allocation into even smaller reallocations. >> >> Also, the recommended size for reassignment is /48, to even the smallest >> end-users, and therefore a /40 only provides 256 such reassignments. >> >> I agree they should become or apply for or meet the criteria for a regular LIR to get a /36. > If a community network needs to make reallocations, maybe to other >> cooperating community networks in their area, they should apply as, or >> become, a regular LIR. As the smallest regular LIR, they would get a /36, >> allowing more than sufficient room to subdivide the allocation into several >> reasonable sized reallocations as necessary. >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > > > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> > Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> > =============================================== > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at linuxmagic.com Thu Feb 15 15:43:05 2018 From: michael at linuxmagic.com (Michael Peddemors) Date: Thu, 15 Feb 2018 12:43:05 -0800 Subject: [arin-ppml] Bringing this thread up again, ARIN whois inaccuracy reports.. Message-ID: https://www.arin.net/public/whoisinaccuracy/index.xhtml Our team has posted several cases following the prescribed procedures, and it would be helpful if ARIN would make tickets related to this publicly available, so the both the submitter, and the public have a transparent way to see that these types of issues are followed up on, or that some process is in place. Otherwise, the public will not continue to assist ARIN to help clean up this data. For instance: whois 174.96.186.64 NetRange:?????? 174.96.0.0 - 174.111.255.255 CIDR:?????????? 174.96.0.0/12 NetName:??????? RRMA NetHandle:????? NET-174-96-0-0-1 Parent:???????? NET174 (NET-174-0-0-0-0) NetType:??????? Direct Allocation OriginAS: Organization:?? Time Warner Cable Internet LLC (RRMA) RegDate:??????? 2009-02-26 Updated:??????? 2009-12-08 Ref:??????????? https://whois.arin.net/rest/net/NET-174-96-0-0-1 ... OrgAbuseRef:??? https://whois.arin.net/rest/poc/ABUSE10-ARIN # If you see inaccuracies in the results, please report at # https://www.arin.net/public/whoisinaccuracy/index.xhtml # Found a referral to ipmt.rr.com:4321. connect: Connection refused We are seeing more and more cases of references to 'rwhois' servers that have fallen off line, got broken, forgotten or simply do not exist. Those records of course should be updated.. (More importantly, the services should be available) Are there any initiatives to make inaccuracy reports more transparent? This would help greatly in helping ARIN deal with this issue. -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.dul at quark.net Thu Feb 15 19:32:11 2018 From: andrew.dul at quark.net (Andrew Dul) Date: Thu, 15 Feb 2018 16:32:11 -0800 Subject: [arin-ppml] Revised - Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers In-Reply-To: References: Message-ID: <4251124c-2fe6-2c0a-6942-769b0fe32eaa@quark.net> Notes inline On 2/12/2018 10:31 AM, David Farmer wrote: > I need more input from the community on this one.? Unless you are one > of the two people who has responded already, please take time to > respond to the following questions. > > Thank you. > > On Wed, Jan 31, 2018 at 3:18 PM, David Farmer > wrote: > > There seems to be a bit of controversy?on the direction to take > this policy.? Therefore as the shepherd,?it would be helpful to > hear from additional community?members regarding this policy.? > > Do you support or oppose the policy as written? > Oppose > > > Do you think the inconsistency described in the Problem Statement > should be corrected? > No > > If yes, should it be corrected by revising by section 8.5.4 to be > consistent with section 4.2.2, as?proposed by the current text? > > Or, as an alternative by revising section 4.2.2 to be?consistent > with section 8.5.4? > > Are there other alternatives to?correct the inconsistency to be > considered? > ? ? ? > Other suggestions or comments? > I authored this proposal to bring up the issue as noted in the policy experience report at the last meeting.?? While I initially believed this was an inconsistency that should be corrected, I no longer feel this is the case after weighing the discussion by other community members.?? I believe that the current transfer policy requirements for an initial block larger than a /24 as found in 8.5.5 are simple and can be easily accomplished by an organization which desires to transfer a block larger than a /24.? Adding additional complexity to the transfer policy is not desired to correct a small inconsistency with the largely obsolete section 4 allocation policy. I do however believe a discussion should be held at the next public policy meeting and if a solid direction cannot be found on this issue, the AC should abandon this draft. Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From narten at us.ibm.com Fri Feb 16 00:53:03 2018 From: narten at us.ibm.com (narten at us.ibm.com) Date: Fri, 16 Feb 2018 00:53:03 -0500 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201802160553.w1G5r35q015540@rotala.raleigh.ibm.com> Total of 13 messages in the last 7 days. script run at: Fri Feb 16 00:53:03 EST 2018 Messages | Bytes | Who --------+------+--------+----------+------------------------ 38.46% | 5 | 53.34% | 124262 | bjones at vt.edu 7.69% | 1 | 11.10% | 25854 | farmer at umn.edu 7.69% | 1 | 7.51% | 17493 | michael at linuxmagic.com 7.69% | 1 | 7.03% | 16375 | andrew.dul at quark.net 7.69% | 1 | 5.17% | 12037 | kevinpowell2005 at hotmail.com 7.69% | 1 | 4.56% | 10631 | narten at us.ibm.com 7.69% | 1 | 4.12% | 9586 | bill at herrin.us 7.69% | 1 | 3.69% | 8596 | joewamuga at gmail.com 7.69% | 1 | 3.48% | 8109 | daveid at panix.com --------+------+--------+----------+------------------------ 100.00% | 13 |100.00% | 232943 | Total From ndavis at arin.net Fri Feb 16 11:19:55 2018 From: ndavis at arin.net (Nate Davis) Date: Fri, 16 Feb 2018 16:19:55 +0000 Subject: [arin-ppml] Bringing this thread up again, ARIN whois inaccuracy reports.. In-Reply-To: References: Message-ID: Michael ? Thanks for the feedback. Can I ask that you submit the proposal, regarding making Whois inaccuracy tickets publicly available, through ARIN?s Consultation and Suggestion Process, https://www.arin.net/participate/acsp/acsp.html ? This is the preferred method for non-policy suggestions to ARIN. Regarding the RWhois item you mention, ARIN staff are working with the organization to correct the issue. Thanks for bringing this to our attention. Best Regards, Nate Davis Chief Operating Officer American Registry for Internet Numbers From: ARIN-PPML on behalf of Michael Peddemors Organization: LinuxMagic Inc. Date: Thursday, February 15, 2018 at 3:44 PM To: "arin-ppml at arin.net" Subject: [arin-ppml] Bringing this thread up again, ARIN whois inaccuracy reports.. https://www.arin.net/public/whoisinaccuracy/index.xhtml Our team has posted several cases following the prescribed procedures, and it would be helpful if ARIN would make tickets related to this publicly available, so the both the submitter, and the public have a transparent way to see that these types of issues are followed up on, or that some process is in place. Otherwise, the public will not continue to assist ARIN to help clean up this data. For instance: whois 174.96.186.64 NetRange: 174.96.0.0 - 174.111.255.255 CIDR: 174.96.0.0/12 NetName: RRMA NetHandle: NET-174-96-0-0-1 Parent: NET174 (NET-174-0-0-0-0) NetType: Direct Allocation OriginAS: Organization: Time Warner Cable Internet LLC (RRMA) RegDate: 2009-02-26 Updated: 2009-12-08 Ref: https://whois.arin.net/rest/net/NET-174-96-0-0-1 ... OrgAbuseRef: https://whois.arin.net/rest/poc/ABUSE10-ARIN # If you see inaccuracies in the results, please report at # https://www.arin.net/public/whoisinaccuracy/index.xhtml # Found a referral to ipmt.rr.com:4321. connect: Connection refused We are seeing more and more cases of references to 'rwhois' servers that have fallen off line, got broken, forgotten or simply do not exist. Those records of course should be updated.. (More importantly, the services should be available) Are there any initiatives to make inaccuracy reports more transparent? This would help greatly in helping ARIN deal with this issue. -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jschiller at google.com Fri Feb 16 12:12:40 2018 From: jschiller at google.com (Jason Schiller) Date: Fri, 16 Feb 2018 12:12:40 -0500 Subject: [arin-ppml] ARIN-PPML 2018-1 In-Reply-To: References: Message-ID: David, This is exactly the right question. To what extent is there working code to support AS numbers larger than 65535, and how costly/dfifficult is it to support them. We examined this very question when we passed 2009-6. The community concluded that there was really no technical reason why the larger ASNs could not work, and the adoption of 2007-19 was to put the community on notice that they had until 12/31/2009 to sort this out (about two years from when the community supported it). This was modified by 2009-6 to push back the action by one year. In April of 2014, the IANA asked for advice on this policy. It seemed there was an RIR who was out of 4-byte ASNs, but still had so many 2-byte ASNs that they did not qualify for additional 4-byte ASNs. The question was if it was in the best interest to hold the two-byte ASNs in reserve, and issue more 4-byte ASNs? Surely the intent was not to force them to burn through their existing 2-byte ASN holdings? This came to a crisis during the April ARIN meeting, and the communtiy was consulted at lenght. The ARIN community (at that time) mostly said there really wasn't a technical reason that made supporting the larger ASNs problematic. If you have a router that is less than 5 years old, just upgrade the code! The result was that the RIR should burn through the two byte ASNs, and IANA could not look the other way on two byte ASNs that were set aside. It was also noted that RIR could manage their two byte and four byte ASNs as they saw fit, but might need to ensure they did not set so many two-byte ASNs aside which could prevent them from getting additional four-byte ASNs. We also suggested that the IANA and the RIR could agree to take a fixed amount of their 1024 ASNs in two-byte, but if they did reach such an agreement, that it should be transparent. How are things different now? Where does the community currently stand on the question of how costly/dfifficult is it to support ASNs larger than 65535? ------------------------------- my take: I initially came at this from the same perspective the community had in 2009. This is just s simple software fix. Everyone agrees that there is no technical reason preventing the support of big ASNs. Anyone running BGP (or about to run BGP) surely has equipment that is current enough to run current code that supports big communities. But in discussions, some have pointed out, to not allow ASN transfers, supports the encumbants, and is a barrier to entry for a smaller ISP who has a four byte ASN. This transit provider may have a down stream customer with older hardware that cannot run code that suppots big communities. As a result, their down stream customer (with old gear) cannot participate in BGP TE as they cannot encode their upstream ISP's four-byte ASN into a big BGP community. Secondary to this, the same four-byte ASN using transit provider may want to purchase transit (or Peer) with a network that supports only two byte-ASN, and will not be able to BGP peer. I'm not sure how big a problem this is, and how costly / dfifficult is it to support big BGP communities in this space. My support or oppision to this proposal hinges on hearing answers to this question from those in the space descibed. ___Jason On Mon, Feb 5, 2018 at 2:54 PM, David R Huberman wrote: > > If I may, I'd like to try and re-focus the discussion of 2018-1 on the > network engineering problem that prompted this draft proposal. The solution > this draft policy proposal offers to the problem is where I think the real > value is, and where I think PPML needs to focus. > > Since the publication of RFC1997 in the 1996, network engineers have > utilized an extension of BGP called the BGP communities attribute to > enginer traffic (to "shape traffic") in a desirable way. > > RFC1997 only supports the use of 2-byte ASNs. As the free pool of 2-byte > ASNs began to shrink, a solultion was needed to enable networks labelled > with 4-byte ASNs to utilize BGP community attributes. > > In 2010, a draft of Flexible Community attribute was discussed, but no > working code was widely released. In 2016, a draft of Wide Comunity > attributes was released, but also resulted in no working code. Finally, in > February 2017, RFC8092 was published, and Large BGP Communities became the > protocol standard for defining 4-byte AS numbers within the BGP community > attribute. > > Working code exists for some equipment and software, is planned for other > equipment and software, but the point is that RFC8092-compliant code is not > prevelant in the DFZ. This is important because it means a network > operator who wants to shape their traffic properly with BGP communities > still needs a 2-byte ASN or it won't work. > > This proposal addresses the problem by allowing registrants of an unused > or unwanted 2-byte ASN to transfer the registration to a network operator > who needs one, all within the existing and community agreed-upon framework > of Inter-RIR transfers. > > For this reason, I support draft policy proposal ARIN-2008-1. > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at arin.net Tue Feb 20 15:07:18 2018 From: info at arin.net (ARIN) Date: Tue, 20 Feb 2018 15:07:18 -0500 Subject: [arin-ppml] Advisory Council Meeting Results - February 2018 Message-ID: In accordance with the Policy Development Process (PDP), the Advisory Council (AC) met on 15 February 2018. The AC has classified the following as an editorial update: * ARIN-2017-11: Reallocation and Reassignment Language Cleanup Per Part One, Section 3.1 of the PDP: "Changes to policy that are purely editorial and non-substantial in nature are outside the scope of the full Policy Development Process and may only be made with 30 days public notice followed by the concurrence of both the ARIN Advisory Council and ARIN Board of Trustees that the changes are non-substantial in nature." The editorial update review window is forthcoming and will be posted separately for discussion. Please note that the editorial update review window for ARIN-prop-251 is forthcoming, pending additional revision. Once revised, the proposed editorial changes will be posted separately for discussion. The AC has advanced the following Draft Policies to Recommended Draft Policy status (each will be posted separately): * ARIN-2017-3: Update to NPRM 3.6: Annual Whois POC Validation * ARIN-2017-8: Amend Community Networks * ARIN-2017-10: Repeal of Immediate Need for IPv4 Address Space (NRPM Section 4.2.1.6) The AC advances Draft Policies to Recommended Draft Policy status once they have been fully developed and meet ARIN's Principles of Internet Number Resource Policy. Specifically, these principles are: * Enabling Fair and Impartial Number Resource Administration * Technically Sound * Supported by the Community The AC is continuing to work on: * ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers * ARIN-2017-12: Require New POC Validation Upon Reassignment * ARIN-2017-13: Remove ARIN Review Requirements for Large IPv4 Reassignments/ Reallocations * ARIN-prop-251: Correct References to Rwhois * ARIN-prop-252: Clarification to ISP Initial Allocation and Permit Renumbering The PDP can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) From info at arin.net Tue Feb 20 15:09:09 2018 From: info at arin.net (ARIN) Date: Tue, 20 Feb 2018 15:09:09 -0500 Subject: [arin-ppml] Proposed Editorial Change to NRPM (Formerly Draft Policy ARIN-2017-11: Reallocation and Reassignment Language Cleanup) Message-ID: <4219c12f-a465-2c4f-86bf-4a72aa67b4ad@arin.net> On 15 February 2018 the ARIN Advisory Council (AC) has requested that Draft Policy ARIN-2017-11: Reallocation and Reassignment Language Cleanup be classified as an editorial update to the Number Resource Policy Manual (NRPM). The full text of the proposed editorial change is below and may be found at https://www.arin.net/policy/proposals/2017_11.html. The process for editorial updates to the NRPM is found in Part One, Section 3.1, paragraph 3 of the PDP: "Changes to policy that are purely editorial and non-substantial in nature are outside the scope of the full Policy Development Process and may only be made with 30 days public notice followed by the concurrence of both the ARIN Advisory Council and ARIN Board of Trustees that the changes are non-substantial in nature." The community review period will close on 23 March 2018. For convenience, a redline of the proposed changes to the current NRPM may be found at: https://www.arin.net/policy/proposals/attachments/2017_11_Redline.pdf The ARIN Number Resource Policy Manual may be found at: https://www.arin.net/policy/nrpm.html The ARIN Policy Development Process is available at: https://www.arin.net/policy/pdp.html Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) Proposed Editorial Change to NRPM (Formerly Draft Policy ARIN-2017-11: Reallocation and Reassignment Language Cleanup) 2.5. Allocate and Assign A distinction is made between address allocation and address assignment, i.e., ISPs are "allocated" address space as described herein, while end-users are "assigned" address space. Allocate - To allocate means to distribute address space to IRs for the purpose of subsequent distribution by them. Assign - To assign means to delegate address space to an ISP or end-user, for specific use within the Internet infrastructure they operate. Assignments must only be made for specific purposes documented by specific organizations and are not to be sub-assigned to other parties. Proposed Editorial Change: 2.5 Allocation, Assignment, Reallocation, Reassignment ? Allocation - Address space delegated to an organization directly by ARIN for the purpose of subsequent distribution by the recipient organization to other parties. Assignment - Address space delegated to an organization directly by ARIN for the exclusive use of the recipient organization. Reallocation - Address space sub-delegated to an organization by an upstream provider for the purpose of subsequent distribution by the recipient organization to other parties. Reassignment - Address space sub-delegated to an organization by an upstream provider for the exclusive use of the recipient organization. Make the following editorial changes to section 3.2: Current text: 3.2. Distributed Information Server Use Requirements[edit] The minimal requirements for an organization to setup a distributed information service to advertise reassignment information are: The distributed information service must be operational 24 hours a day, 7 days a week to both the general public and ARIN staff. The service is allowed reasonable downtime for server maintenance according to generally accepted community standards. The distributed information service must allow public access to reassignment information. The service may restrict the number of queries allowed per time interval from a host or subnet to defend against DDOS attacks, remote mirroring attempts, and other nefarious acts. The distributed information service must return reassignment information for the IP address queried. The service may allow for privacy protections for customers. For residential users, the service may follow ARIN's residential privacy policy that includes displaying only the city, state, zip code, and country. For all other reassignments, the service shall follow ARIN's privacy policy for publishing data in a public forum. The distributed information service may return results for non-IP queries. The distributed information service must respond to a query with the minimal set of attributes per object as defined by ARIN staff. The distributed information service may include optional attributes per object that are defined locally. The distributed information service must return results that are up-to-date on reassignment information. Proposed Editorial Change: 3.2. Distributed Information Server Use Requirements The minimal requirements for an organization to setup a distributed information service to advertise reassignment and reallocation information are: The distributed information service must be operational 24 hours a day, 7 days a week to both the general public and ARIN staff. The service is allowed reasonable downtime for server maintenance according to generally accepted community standards. The distributed information service must allow public access to reassignment and reallocation information. The service may restrict the number of queries allowed per time interval from a host or subnet to defend against DDOS attacks, remote mirroring attempts, and other nefarious acts. The distributed information service must return reassignment and reallocation information for the IP address queried. The service may allow for privacy protections for customers. For residential users, the service may follow ARIN's residential privacy policy that includes displaying only the city, state, zip code, and country. For all other reassignments and reallocations, the service shall follow ARIN's privacy policy for publishing data in a public forum. The distributed information service may return results for non-IP queries. The distributed information service must respond to a query with the minimal set of attributes per object as defined by ARIN staff. The distributed information service may include optional attributes per object that are defined locally. The distributed information service must return results that are up-to-date on reassignment and reallocation information. Make the following editorial changes to section 4.2: Current text: 4.2.1.1. Purpose ARIN allocates blocks of IP addresses to ISPs for the purpose of reassigning that space to their customers. Proposed Editorial Change: 4.2.1.1. Purpose ARIN allocates blocks of IP addresses to ISPs for the purpose of reassigning and reallocating that space to their customers. Current text: 4.2.3. Reassigning Address Space to Customers Proposed Editorial Change: 4.2.3. Reassigning and Reallocating Address Space to Customers Current Text: 4.2.3.1. Efficient utilization ISPs are required to apply a utilization efficiency criterion in providing address space to their customers. To this end, ISPs should have documented justification available for each reassignment. ARIN may request this justification at any time. If justification is not provided, future receipt of allocations may be impacted. Proposed Editorial Change: 4.2.3.1. Efficient utilization ISPs are required to apply a utilization efficiency criterion in providing address space to their customers. To this end, ISPs should have documented justification available for each reassignment and reallocation. ARIN may request this justification at any time. If justification is not provided, future receipt of allocations may be impacted. Current text: 4.2.3.4. Downstream customer adherence ISPs must require their downstream customers to adhere to the following criteria: 4.2.3.4.1. Utilization Reassignment information for prior allocations must show that each customer meets the 80% utilization criteria and must be available via SWIP / RWhois prior to your issuing them additional space. Proposed Editorial Changes: 4.2.3.4. Downstream customer adherence ISPs must require their downstream customers to adhere to the following criteria: 4.2.3.4.1. Utilization Reassignment and reallocation information for prior allocations must show that each customer meets the 80% utilization criteria and must be available via SWIP / RWhois prior to your issuing them additional space. Current text: 4.2.3.5. ARIN approval of reassignments/reallocations 4.2.3.5.1. /18 All extra-large ISPs making reassignments of a /18 or larger to a customer must first have these reassignments reviewed and approved by ARIN. 4.2.3.5.2. /19 Small to large ISPs making customer reassignments of a /19 or larger must first seek ARIN's approval. Proposed Editorial Changes: 4.2.3.5. ARIN approval of reassignments/reallocations 4.2.3.5.1. /18 All extra-large ISPs making reassignments or reallocations of a /18 or larger to a customer must first have these reassignments or reallocations reviewed and approved by ARIN. 4.2.3.5.2. /19 Small to large ISPs making customer reassignments or reallocations of a /19 or larger must first seek ARIN's approval. Current text: 4.2.3.7.1. Reassignment Information Each IPv4 assignment containing a /29 or more addresses shall be registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2. Reassignment registrations shall include each client's organizational information, except where specifically exempted by this policy. Proposed Editorial Changes: 4.2.3.7.1. Reassignment and Reallocation Information Each IPv4 reassignment or reallocation containing a /29 or more addresses shall be registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2. Reassignment and reallocation registrations shall include each client's organizational information, except where specifically exempted by this policy. Current text: 4.2.3.7.2.Assignments visible within 7 days All assignments shall be made visible as required in section 4.2.3.7.1 within seven calendar days of assignment. Proposed Editorial Changes: 4.2.3.7.2.Reassignments and Reallocations visible within 7 days All reassignments and reallocations shall be made visible as required in section 4.2.3.7.1 within seven calendar days of reassignment or reallocation. Current text: 4.2.4. ISP Additional Requests 4.2.4.1. Utilization percentage (80%) ISPs must have efficiently utilized all allocations, in aggregate, to at least 80% and at least 50% of every allocation in order to receive additional space. This includes all space reassigned to their customers. Proposed Editorial Changes: 4.2.4. ISP Additional Requests 4.2.4.1. Utilization percentage (80%) ISPs must have efficiently utilized all allocations, in aggregate, to at least 80% and at least 50% of every allocation in order to receive additional space. This includes all space reassigned or reallocated to their customers. Make the following editorial changes to section 6 to clarify language regarding current practices and requirements for reallocations and reassignments, and specifically to clarify that recording reallocation information is required where current language is ambiguous: Current text: 6.5.2.1(e) Initial Allocations to LIRs, Size For purposes of the calculation in (c), an LIR which has subordinate LIRs shall make such allocations according to the same policies and criteria as ARIN. In such a case, the prefixes necessary for such an allocation should be treated as fully utilized in determining the block sizing for the parent LIR. LIRs which do not receive resources directly from ARIN will not be able to make such allocations to subordinate LIRs and subordinate LIRs which need more than a /32 shall apply directly to ARIN. Proposed Editorial Changes: 6.5.2.1(e) Initial Allocations to LIRs, Size For purposes of the calculation in (c), an LIR which has subordinate LIRs shall make such reallocations according to the same policies and criteria as ARIN. In such a case, the prefixes necessary for such a reallocation should be treated as fully utilized in determining the block sizing for the parent LIR. LIRs which do not receive resources directly from ARIN will not be able to make such reallocations to subordinate LIRs and subordinate LIRs which need more than a /32 shall apply directly to ARIN. Current text: 6.5.2.2. Qualifications An organization qualifies for an allocation under this policy if they meet any of the following criteria: a. Have a previously justified IPv4 ISP allocation from ARIN or one of its predecessor registries or can qualify for an IPv4 ISP allocation under current criteria. b. Are currently multihomed for IPv6 or will immediately become multihomed for IPv6 using a valid assigned global AS number. In either case, they will be making reassignments from allocation(s) under this policy to other organizations. Provide ARIN a reasonable technical justification indicating why an allocation is necessary. Justification must include the intended purposes for the allocation and describe the network infrastructure the allocation will be used to support. Justification must also include a plan detailing anticipated assignments to other organizations or customers for one, two and five year periods, with a minimum of 50 assignments within 5 years. Proposed Editorial Changes: 6.5.2.2. Qualifications An organization qualifies for an allocation under this policy if they meet any of the following criteria: a. Have a previously justified IPv4 ISP allocation from ARIN or one of its predecessor registries or can qualify for an IPv4 ISP allocation under current criteria. b. Are currently multihomed for IPv6 or will immediately become multihomed for IPv6 using a valid assigned global AS number. In either case, they will be making reassignments or reallocations from allocation(s) under this policy to other organizations. Provide ARIN a reasonable technical justification indicating why an allocation is necessary. Justification must include the intended purposes for the allocation and describe the network infrastructure the allocation will be used to support. Justification must also include a plan detailing anticipated reassignments and reallocations to other organizations or customers for one, two and five year periods, with a minimum of 50 assignments within 5 years. Current text: 6.5.4. Assignments from LIRs/ISPs Assignments to end users shall be governed by the same practices adopted by the community in section 6.5.8 except that the requirements in 6.5.8.1 do not apply. Proposed Editorial Changes: 6.5.4. Reassignments from LIRs/ISPs Reassignments to end users shall be governed by the same practices adopted by the community in section 6.5.8 except that the requirements in 6.5.8.1 do not apply. Current text: 6.5.4.1. Assignment to operator's infrastructure An LIR may assign up to a /48 per PoP as well as up to an additional /48 globally for its own infrastructure. Proposed Editorial Changes: 6.5.4.1. Reassignment to operator's infrastructure An LIR may reassign up to a /48 per PoP as well as up to an additional /48 globally for its own infrastructure. Current text: 6.5.5. Registration ISPs are required to demonstrate efficient use of IP address space allocations by providing appropriate documentation, including but not limited to assignment histories, showing their efficient use. Proposed Editorial Changes: 6.5.5. Registration ISPs are required to demonstrate efficient use of IP address space allocations by providing appropriate documentation, including but not limited to reassignment and reallocation histories, showing their efficient use. Current text: 6.5.5.1. Reassignment information Each static IPv6 assignment containing a /64 or more addresses shall be registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2. Reassignment registrations shall include each client's organizational information, except where specifically exempted by this policy. Proposed Editorial Changes: 6.5.5.1. Reassignment information Each static IPv6 reassignment or reallocation containing a /64 or more addresses shall be registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2. Reassignment and reallocation registrations shall include each client's organizational information, except where specifically exempted by this policy. Current text: 6.5.5.2. Assignments visible within 7 days All assignments shall be made visible as required in section 4.2.3.7.1 within seven calendar days of assignment Proposed Editorial Changes: 6.5.5.2. Reassignments and Reallocations visible within 7 days All reassignments and reallocations shall be made visible as required in section 4.2.3.7.1 within seven calendar days of reassignment or reallocation. Current text: 12. Resource Review (...) 2. c) whenever ARIN has reason to believe that an organization is not complying with reassignment policies, or Proposed Editorial Changes: 12. Resource Review (...) 2. c) whenever ARIN has reason to believe that an organization is not complying with reassignment or reallocation policies, or From info at arin.net Tue Feb 20 15:10:12 2018 From: info at arin.net (ARIN) Date: Tue, 20 Feb 2018 15:10:12 -0500 Subject: [arin-ppml] Recommended Draft Policy ARIN-2017-10: Repeal of Immediate Need for IPv4 Address Space (NRPM Section 4.2.1.6) Message-ID: On 15 February 2018 the ARIN Advisory Council (AC) advanced the following Draft Policy to Recommended Draft Policy status: ARIN-2017-10: Repeal of Immediate Need for IPv4 Address Space (NRPM Section 4.2.1.6) The text of the Recommended Draft Policy is below, and may also be found at: https://www.arin.net/policy/proposals/2017_10.html You are encouraged to discuss all Recommended Draft Policies on PPML prior to their presentation at the next ARIN Public Policy Consultation (PPC). PPML and PPC discussions are invaluable to the AC when determining community consensus. The PDP can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers Recommended Draft Policy ARIN-2017-10: Repeal of Immediate Need for IPv4 Address Space (NRPM Section 4.2.1.6) AC assessment of conformance with the Principles of Internet Number Resource Policy: This recommended draft proposal is technically sound and is fair and impartial number policy. The draft policy removes the immediate need policy which is now inoperative as the IPv4 free pool is empty and ARIN does not have the ability to provide space within the 30 day requirement for which this policy was originally intended. Problem Statement: Section 4.2.1.6 of the ARIN Numbering Resource Policy Manual (NRPM) provides that an ISP having an immediate need for IPv4 address space that will be utilized within thirty days of a request may obtain a block of IPv4 address space of the size specified in section 4.2.1.6 from ARIN on an exceptional basis. However, as noted in the ARIN 40 Policy Experience Report, since IPv4 exhaustion, obtaining IPv4 addresses in this manner is no longer possible as a practical matter. Instead an ISP must join the waiting list and wait until it reaches the front of the queue to obtain any IPv4 address space, however long that may take. In effect, section 4.2.1.6 is non-operative. Accordingly, its continued presence in the NRPM is misleading and confusing. Policy Statement: Section 4.2.1.6 of the NRPM is hereby repealed and section number 4.2.1.6 is hereby retired. Section 4.3.4 - Remove phrase "Immediate need [4.2.1.6] or" Section 4.5, Item 7 - Remove phrase "unless the organization can demonstrate additional need using the immediate need criteria (4.2.1.6)" Comments: Timetable for implementation: Immediate Anything else: Given the constraints created by the exhaustion of IPv4 addresses, this proposal does not require any changes in the current ARIN practices for the allocation of IPv4 address space. From info at arin.net Tue Feb 20 15:11:55 2018 From: info at arin.net (ARIN) Date: Tue, 20 Feb 2018 15:11:55 -0500 Subject: [arin-ppml] Recommended Draft Policy ARIN-2017-8: Amend Community Networks Message-ID: On 15 February 2018 the ARIN Advisory Council (AC) advanced the following Draft Policy to Recommended Draft Policy status: ARIN-2017-8: Amend Community Networks The text of the Recommended Draft Policy is below, and may also be found at: https://www.arin.net/policy/proposals/2017_8.html You are encouraged to discuss all Recommended Draft Policies on PPML prior to their presentation at the next ARIN Public Policy Consultation (PPC). PPML and PPC discussions are invaluable to the AC when determining community consensus. The PDP can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers Recommended Draft Policy ARIN-2017-8: Amend Community Networks AC assessment of conformance with the Principles of Internet Number Resource Policy: This proposal is technically sound and enables fair and impartial number policy by redefining and classifying community networks as an LIR that may receive a smaller than normal allocation of IPv6, a /40. Except for the allocation size and a restriction on making reallocations, community networks will function like any other LIR. Community networks may also qualify as a regular LIR without any limits on size or reallocations. This revision addresses all concerns raised, and there appears to be ample support for the proposal by the community. Problem Statement: The Community Networks section of the NRPM has only been used once since implementation in January 2010. Proposal ARIN-2016-7, to increase the number of use cases, was abandoned by the Advisory Council due to lack of feedback. Proposal ARIN 2017-2, to remove all mention of community networks from NRPM met with opposition by the community. Many responded that the definition of "community network" was too narrow, which could be the reason for lack of uptake. In the discussion at ARIN 40, it was clear that more than just the definition of a community network needed revision and that community networks need to have allocations, not assignments. Additionally, community networks need to make reassignments to end-users in accordance with applicable policies. ?????? Policy statement: Replace section 2.11 with the following; 2.11 Community Network A community network is deployed, operated, and governed by its users, for the purpose of providing free or low-cost connectivity to the community it services. Users of the network or other volunteers must play a primary role in the governance of the organization, whereas other functions may be handled by either paid staff or volunteers. Rename section 6.5.9 and revise the last sentence as follows; 6.5.9. Community Network Allocations While community networks would normally be considered to be ISP type organizations under existing ARIN criteria, they tend to operate on much tighter budgets and often depend on volunteer labor. As a result, they tend to be much smaller and more communal in their organization rather than provider/customer relationships of commercial ISPs. This section seeks to provide a policy that is more friendly to those environments by allowing community network to receive a smaller allocation than other LIRs or commercial ISPs. Community networks may also qualify under section 6.5.2 as a regular LIR. Section 6.5.9.1 is not changing, but is included here for completeness; 6.5.9.1. Qualification Criteria To qualify under this section, a community network must demonstrate to ARIN's satisfaction that it meets the definition of a community network under section 2.11 of the NRPM. Replace section 6.5.9.2 and 6.5.9.3 with the following; 6.5.9.2. Allocation Size Community networks are eligible only to receive an allocation of /40 of IPv6 resources under this section. Community networks that wish to receive a larger initial allocation or any subsequent allocations must qualify as a regular LIR, see sections 6.5.2 or 6.5.3 respectively. 6.5.9.3. Reassignments by Community Networks Similar to other LIRs, Community networks shall make reassignments to end-users in accordance with applicable policies, in particular, but not limited to sections 6.5.4 and 6.5.5. However, they shall not reallocate resources under this section. Comments: Timetable for implementation: Immediate The rationale for restricting community networks that receive resources through this policy from making reallocations is that a /40 is a tiny IPv6 allocation and it does not seem reasonable to subdivide such a small allocation into even smaller reallocations. Also, the recommended size for reassignment is /48, to even the smallest end-users, and therefore a /40 only provides 256 such reassignments. If a community network needs to make reallocations, maybe to other cooperating community networks in their area, they should apply as, or become, a regular LIR. As the smallest regular LIR, they would get a /36, allowing more than sufficient room to subdivide the allocation into several reasonable sized reallocations as necessary. From info at arin.net Tue Feb 20 19:06:40 2018 From: info at arin.net (ARIN) Date: Tue, 20 Feb 2018 19:06:40 -0500 Subject: [arin-ppml] Recommended Draft Policy ARIN-2017-3: Update to NPRM 3.6: Annual Whois POC Validation Message-ID: On 15 February 2018 the ARIN Advisory Council (AC) advanced the following Draft Policy to Recommended Draft Policy status: ARIN-2017-3: Update to NPRM 3.6: Annual Whois POC Validation The text of the Recommended Draft Policy is below, and may also be found at: https://www.arin.net/policy/proposals/2017_3.html You are encouraged to discuss all Recommended Draft Policies on PPML prior to their presentation at the next ARIN Public Policy Consultation (PPC). PPML and PPC discussions are invaluable to the AC when determining community consensus. The PDP can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers Recommended Draft Policy ARIN-2017-3: Update to NPRM 3.6: Annual Whois POC Validation AC assessment of conformance with the Principles of Internet Number Resource Policy: This proposal is technically sound and enables fair and impartial number policy as it encourages more accurate Whois data collection by restricting organizations without at least one validated Admin or Tech POC from using ARIN Online services outside of payment and contact update functionalities. Problem Statement: Many of the Point of Contacts listed in ARIN?s public Whois database contain out-of-date and inaccurate contact information. Policy statement: Current Text: 3.6 Annual Whois POC Validation 3.6.1 Method of Annual Verification During ARIN's annual Whois POC validation, an email will be sent to every POC in the Whois database. Each POC will have a maximum of 60 days to respond with an affirmative that their Whois contact information is correct and complete. Unresponsive POC email addresses shall be marked as such in the database. If ARIN staff deems a POC to be completely and permanently abandoned or otherwise illegitimate, the POC record shall be marked invalid. ARIN will maintain, and make readily available to the community, a current list of number resources with no valid POC; this data will be subject to the current bulk Whois policy. Proposed Revised Text: 3.6 Annual Validation of ARIN's Public Whois Point of Contact Data 3.6.1 Annual POC Verification ARIN will perform an annual verification of specific Points of Contact registered in the public Whois using the criteria and procedures outlined in sections 3.6.2, 3.6.3, and 3.6.4. 3.6.2 Specified Public Whois Points of Contact for Verification Each of the following Points of Contact are to be verified annually, and will be referred to as Point of Contact or POC throughout this policy, and should be understood to be both organization and resource POCs: - Admin - Tech - NOC - Abuse 3.6.3 Organizations Covered by this Policy This policy applies to every Organization that has a direct assignment, direct allocation, or AS number from ARIN (or one of its predecessor registries) or a reallocation from an upstream ISP. This includes but is not limited to upstream ISPs and their downstream ISP customers (as defined by NRPM 2.5 and 2.6), but not reassignments made to their downstream end user customers. 3.6.4 Procedure for Verification An annual email notification will be sent to each of the Points of Contact outlined in section 3.6.2 on an annual basis. Each Point of Contact will have up to sixty (60) days from the date of the notification in which to respond with an affirmative that their Whois contact information is correct and complete or to submit new data to correct and complete it. If after careful analysis, ARIN staff deems a POC to be completely and permanently abandoned or otherwise illegitimate, the POC record shall be marked invalid in Whois. 3.6.5 Non-Responsive Point of Contact Records An invalid POC is restricted to payment and contact update functionality within ARIN Online. As a result, an organization without any valid POCs will be unable to access further functionalities within ARIN Online until at least one Admin or Tech POC validates that their information is accurate or modifies a POC to contain accurate information. Comments: Timetable for implementation: to be based upon discussions with ARIN's staff. From job at instituut.net Tue Feb 6 15:39:38 2018 From: job at instituut.net (Job Snijders) Date: Tue, 06 Feb 2018 20:39:38 -0000 Subject: [arin-ppml] IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers In-Reply-To: <8F208363-9080-480F-85D3-4AA8925B6564@semihuman.com> References: <47325565b96e4adaa6214be0f0d293da@DG2MBX04-DOR.bell.corp.bce.ca> <20180201182952.GR87376@vurt.meerval.net> <8F208363-9080-480F-85D3-4AA8925B6564@semihuman.com> Message-ID: <20180206203933.GK5974@vurt.meerval.net> 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 From daveid at panix.com Thu Feb 22 15:11:50 2018 From: daveid at panix.com (David R Huberman) Date: Thu, 22 Feb 2018 15:11:50 -0500 (EST) Subject: [arin-ppml] IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers In-Reply-To: <20180206203933.GK5974@vurt.meerval.net> References: <47325565b96e4adaa6214be0f0d293da@DG2MBX04-DOR.bell.corp.bce.ca> <20180201182952.GR87376@vurt.meerval.net> <8F208363-9080-480F-85D3-4AA8925B6564@semihuman.com> <20180206203933.GK5974@vurt.meerval.net> Message-ID: > 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. From farmer at umn.edu Thu Feb 22 19:11:39 2018 From: farmer at umn.edu (David Farmer) Date: Thu, 22 Feb 2018 18:11:39 -0600 Subject: [arin-ppml] Origin AS Semantics Message-ID: An interesting question came up on Tuesday in the ARIN IRR Roadmap at NANOG. Essentially, what is the intended semantics of Origin AS? See timestamp 20:14 to 21:04 in the following video; https://youtu.be/tsWq_LgNS5s Some background; Section 3.5 of the NRPM, originally Policy ARIN-2006-3, specifies the creation of what is now the "Origin AS" field in ARIN's registry, see; https://www.arin.net/policy/nrpm.html#three5 https://www.arin.net/policy/proposals/2006_3.html So back to the question; "are you allow to announce any more specifics based on the Origin AS?" Note the last sentence of section 3.5.1 says the following; This additional field will be used to record a list of the ASes that the user permits to originate address prefixes within the address block. While the policy doesn't formally specify the semantics for this field, based on the above sentence, I personally have to conclude that the policy intends that more specifics should be permitted based on the "Origin AS" filed. Does anyone read this differently? Do we need to further clarify this in the policy? Thanks. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Thu Feb 22 20:57:28 2018 From: owen at delong.com (Owen DeLong) Date: Thu, 22 Feb 2018 17:57:28 -0800 Subject: [arin-ppml] Origin AS Semantics In-Reply-To: References: Message-ID: <7726FF6A-BE60-43D2-AD2A-6513E8021B1C@delong.com> Seems pretty explicit to me. ??list of the Ages that the user permits to originate address prefixes within the address block.? So far, I?ve been unable to imagine any interpretation of ?within the address block? which would exclude more specifics. Owen > On Feb 22, 2018, at 4:11 PM, David Farmer wrote: > > An interesting question came up on Tuesday in the ARIN IRR Roadmap at NANOG. Essentially, what is the intended semantics of Origin AS? See timestamp 20:14 to 21:04 in the following video; > > https://youtu.be/tsWq_LgNS5s > > Some background; Section 3.5 of the NRPM, originally Policy ARIN-2006-3, specifies the creation of what is now the "Origin AS" field in ARIN's registry, see; > > https://www.arin.net/policy/nrpm.html#three5 > https://www.arin.net/policy/proposals/2006_3.html > > So back to the question; "are you allow to announce any more specifics based on the Origin AS?" > > Note the last sentence of section 3.5.1 says the following; > > This additional field will be used to record a list of the ASes that the user permits to originate address prefixes within the address block. > > While the policy doesn't formally specify the semantics for this field, based on the above sentence, I personally have to conclude that the policy intends that more specifics should be permitted based on the "Origin AS" filed. > > Does anyone read this differently? > > Do we need to further clarify this in the policy? > > Thanks. > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 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 at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From job at ntt.net Thu Feb 22 20:59:55 2018 From: job at ntt.net (Job Snijders) Date: Fri, 23 Feb 2018 01:59:55 +0000 Subject: [arin-ppml] Origin AS Semantics In-Reply-To: <7726FF6A-BE60-43D2-AD2A-6513E8021B1C@delong.com> References: <7726FF6A-BE60-43D2-AD2A-6513E8021B1C@delong.com> Message-ID: On Thu, 22 Feb 2018 at 20:58, Owen DeLong wrote: > Seems pretty explicit to me. > > ??list of the Ages that the user permits to originate address prefixes > within the address block.? > > So far, I?ve been unable to imagine any interpretation of ?within the > address block? which would exclude more specifics. > Agreed. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From narten at us.ibm.com Fri Feb 23 00:53:03 2018 From: narten at us.ibm.com (narten at us.ibm.com) Date: Fri, 23 Feb 2018 00:53:03 -0500 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201802230553.w1N5r3wl028439@rotala.raleigh.ibm.com> Total of 13 messages in the last 7 days. script run at: Fri Feb 23 00:53:03 EST 2018 Messages | Bytes | Who --------+------+--------+----------+------------------------ 38.46% | 5 | 34.89% | 64556 | info at arin.net 7.69% | 1 | 14.10% | 26085 | ndavis at arin.net 7.69% | 1 | 12.34% | 22830 | jschiller at google.com 7.69% | 1 | 9.83% | 18193 | owen at delong.com 7.69% | 1 | 8.28% | 15316 | farmer at umn.edu 7.69% | 1 | 5.78% | 10700 | job at instituut.net 7.69% | 1 | 5.37% | 9932 | narten at us.ibm.com 7.69% | 1 | 5.08% | 9407 | job at ntt.net 7.69% | 1 | 4.33% | 8019 | daveid at panix.com --------+------+--------+----------+------------------------ 100.00% | 13 |100.00% | 185038 | Total From caltland at mctvohio.com Fri Feb 23 10:02:14 2018 From: caltland at mctvohio.com (Christopher E. Altland) Date: Fri, 23 Feb 2018 15:02:14 +0000 Subject: [arin-ppml] Origin AS Semantics In-Reply-To: References: Message-ID: <587eee4ae5074f9fae8515b35a150cfb@mctvohio.com> I agree with this. Christopher Altland From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Farmer Sent: Thursday, February 22, 2018 7:12 PM To: ARIN-PPML List Subject: [arin-ppml] Origin AS Semantics An interesting question came up on Tuesday in the ARIN IRR Roadmap at NANOG. Essentially, what is the intended semantics of Origin AS? See timestamp 20:14 to 21:04 in the following video; https://youtu.be/tsWq_LgNS5s Some background; Section 3.5 of the NRPM, originally Policy ARIN-2006-3, specifies the creation of what is now the "Origin AS" field in ARIN's registry, see; https://www.arin.net/policy/nrpm.html#three5 https://www.arin.net/policy/proposals/2006_3.html So back to the question; "are you allow to announce any more specifics based on the Origin AS?" Note the last sentence of section 3.5.1 says the following; This additional field will be used to record a list of the ASes that the user permits to originate address prefixes within the address block. While the policy doesn't formally specify the semantics for this field, based on the above sentence, I personally have to conclude that the policy intends that more specifics should be permitted based on the "Origin AS" filed. Does anyone read this differently? Do we need to further clarify this in the policy? Thanks. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: