Hi Owen,
El 27/3/19 18:04, "Owen DeLong" <[email protected]> escribió:
> On Mar 27, 2019, at 09:41 , JORDI PALET MARTINEZ via ARIN-PPML
<[email protected]> wrote:
>
> Hi Owen,
>
> Just found a couple of examples that I was sure I've read recently.
>
> 1) ARIN
> 9. Out of Region Use -> at least /44 in region.
This is taken out of context…
NRPM section 9 speaks ONLY of out of region use with respect to the extent
to which it can be considered justified utilization when applying for
additional ARIN resources. If you need more resources in the ARIN region, and
you have significant out-of-region resource utilization, then likely the right
thing to do is obtain resources from the other RIRs in question and repatriate
your ARIN resources to meet that need.
-> Which then is my point. It makes sense to keep those resources in the other
RIR, and if necessary because a re-organization so to avoid renumbering. If we
do as you indicate above, I need to renumber the out-of-region resources.
If you believe that ARIN’s out of region use policy should be more liberal,
then propose policy to achieve that. Transfers are not, IMHO, the way to
resolve this perceived issue.
>
> What if an end-user has only a /48?
>
If you have only a /48 and are using a significant fraction of it outside
of the ARIN region, then the logical thing to do if you need more space is to
apply to the RIR where you have that need and then use those resources
appropriately.
-> it may be unplanned, but you want to avoid renumbering, this is the point.
> What if they aren't longer in ARIN region at all, and want to move the DC
to another region?
Then they should obtain IPv6 resources in that region and renumber into
resources applicable to that region. If you’re moving an entire company,
renumbering your IP addresses is the least of the difficulties in that process.
-> I think you're missing my previous explanation. It may be a DC with VMs. You
don't move "hardware" just the VMs from on DC to another. There are no
difficulties to do that.
>
> 2) LACNIC
> 1.11 Principles for Proper Administration and Stewardship
> The numbering resources under the stewardship of LACNIC must be
distributed among organizations legally constituted within its service region
[COVERAGE] and mainly serving networks and services operating in this region.
External clients connected directly to main infrastructure located in the
region are allowed.
You seem to be having difficulty with the definition of “primarily” vs.
“exclusively”. Your interpretation is more in line with “exclusively”, but the
word in the actual policy is “primarily”.
-> There is no "primarily" in that text. If you refer to "mainly", we had this
discussion in LACNIC and there were some ideas to indicate that a really big %
need to be "in" the region. If there is a relocation, you're taking all the
resources to another region (or most of them).
> 4.5.1.2. IPv6 allocation to a LIR or ISP without a previous IPv4
allocation from LACNIC
> To qualify for an initial allocation of IPv6 address space, an
organization must:
> Offer IPv6 services to clients or self-owned/related entities (including
departments and/or sites) physically located in the region covered by LACNIC
within a period not longer than 24 months.
Yes… To qualify, you have to offer services in the LACNIC region. Not
exclusively, not solely, but you do have to serve customers in region. I’m not
seeing how this precludes use of the addresses elsewhere for customers
elsewhere in addition to using them within the region.
> So again, if this is a relocation, that will not be met.
Again, for relocation, IMHO, renumber into the new region. If you are
relocating an entire enterprise, regardless of size, applying new numbers to
the new location is beneficial in most cases and certainly the least of the
disruptions that comes with such a move.
-> repeating myself, in some cases you just simple sync VM into another DC.
> I can keep looking in other regions policies, but I think many of them
have similar texts that indicate that the resources must be used in the region
(at least a portion), or something equivalent.
Yes… You have to use at least some fraction of the resources in the region
where you got them. That doesn’t seem unreasonable to me, and I don’t see that
as a problem. Certainly not a problem we should be solving in this way.
> In the case of a relocation, this will not be possible.
Right, but in the case of a relocation, you should be getting new numbers
from your new RIR, IMHO, so I don’t see this as a use case for inter-RIR
transfers. In fact, I see it as a very good reason to oppose the proposal.
-> I don't agree. If it is posible for IPv4, it should be also for IPv6.
Owen
>
> Regards,
> Jordi
>
>
>
> El 27/3/19 16:51, "Owen DeLong" <[email protected]> escribió:
>
> Please cite an example of this. I do not believe that to be the case
for IPv6 in any RIR.
>
> Owen
>
>
>> On Mar 27, 2019, at 07:15 , JORDI PALET MARTINEZ via ARIN-PPML
<[email protected]> wrote:
>>
>> In some RIRs, the policies only allow you to use the addresses (or most
of them), in that region.
>>
>> Regards,
>> Jordi
>>
>>
>>
>> El 27/3/19 13:38, "ARIN-PPML en nombre de Roberts, Orin"
<[email protected] en nombre de [email protected]> escribió:
>>
>> Opposed - the simple view.
>>
>> Why is the need for an IPv6 "Inter-regional" policy justifiable?
>>
>> IPv6 addresses are/were meant to be used in global architecture by
design; I remember an early selling feature being the scope for inter-planetary
expansion.
>> Therefore, the five RIR's should only have policies for equitable
distribution based on the technicality and legalities of their various zones.
>>
>> In my opinion, once distributed, those addresses should default back
to IANA to manage under a single global policy. The RIR's can then continue to
manage the distribution/routing records on behalf of IANA.
>>
>> It seems to me, that by placing policy restrictions on IPv6 addresses,
we are saddling this wonderful protocol with IPv4 design limitations.
>>
>> Orin Roberts
>> Bell Canada
>>
>>
>> -----Original Message-----
>> From: ARIN-PPML <[email protected]> On Behalf Of
[email protected]
>> Sent: March-26-19 6:23 PM
>> To: [email protected]
>> Subject: Re: [arin-ppml] Draft Policy ARIN-2019-4: Allow
Inter-regional IPv6 Resource Transfers
>>
>> I am opposed.
>>
>> IPv6 policies have been designed from the beginning to limit the
growth of the global routing tables. Policies such as sparse assignment help
with this goal, as well as the development of means to renumber with relative
ease, compared to IPv4. This is because more than one upstream can be
advertised at the same time and in the same network. A RFC compliant host will
by default assign addresses in each subnet that it hears router advertisements
and spread its outgoing traffic between the available upstream routers. Unlike
IPv4, we are nowhere near exhaust, and there is no need to get into the legacy
transfer issue with IPv6. I would perfer to allow each IPv6 block assigned to
a RIR to remain 100% under the control of that RIR. If transfers are possible,
this fact alone can be used to defeat the trust anchor.
>>
>> It is unclear to me what the trust anchor problem actually is, and why
it needs to lead to the explosion of the IPv6 DFZ because of transfers. If
there is an issue of ARIN policy regarding trust anchors compared to other
RIR's, this policy should instead be addressed instead of allowing transfers as
a work around to a bad ARIN policy.
>>
>> Ideally, IPv6 blocks should be obtained from the upstream ISP/LIR and
they should be routed to the default route, with only one route per ISP/LIR.
>> Since the "normal" site assignment is a /48, unlike IPv4, there is no
shortage of address space for any use without involvement of ARIN or other RIR.
If one needs to be multihomed, each host can have an address from each
available upstream, providing availability to each host from more than one
network.
>>
>> Albert Erdmann
>> Network Administrator
>> Paradise On Line Inc.
>>
>> On Tue, 26 Mar 2019, ARIN wrote:
>>
>>> On 21 March 2019, the ARIN Advisory Council (AC) accepted
"ARIN-prop-263:
>>> Allow Inter-regional IPv6 Resource Transfers" as a Draft Policy.
>>>
>>> The Draft Policy text is below and can be found at:
>>> https://www.arin.net/participate/policy/drafts/2019_4/
>>>
>>> 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/participate/policy/pdp/
>>>
>>> Draft Policies and Proposals under discussion can be found at:
>>> https://www.arin.net/participate/policy/drafts/
>>>
>>> Regards,
>>>
>>> Sean Hopkins
>>> Policy Analyst
>>> American Registry for Internet Numbers (ARIN)
>>>
>>>
>>>
>>> Draft Policy ARIN-2019-4: Allow Inter-regional IPv6 Resource Transfers
>>>
>>> Problem Statement:
>>>
>>> There is an operational need to allow RIR transfers of IPv6 resources
>>> between RIRs with an equivalent transfer policy. ARIN’s RPKI Trust
>>> Anchor (TA) is measurably less widely deployed than TAs from other
>>> RIRs. As a consequence, RPKI ROAs published through ARIN offer less
>>> value. Operators seeking to extract the most value from their
>>> investment in IPv6 would benefit from the ability to transfer IPv6
>>> resources to RIRs with more widely deployed RPKI Trust Anchors.
>>>
>>> Policy Statement:
>>>
>>> Change the first sentence in section 8.4 from:
>>>
>>> “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.”
>>>
>>> To:
>>>
>>> “Inter-regional transfers of Internet number resources may take place
>>> only via RIRs who agree to the transfer and share reciprocal,
>>> compatible needs-based policies.”
>>>
>>> Comments:
>>>
>>> Timetable for implementation: Immediate
>>> _______________________________________________
>>> ARIN-PPML
>>> You are receiving this message because you are subscribed to the ARIN
>>> Public Policy Mailing List ([email protected]).
>>> Unsubscribe or manage your mailing list subscription at:
>>> https://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact [email protected] if you experience any issues.
>>>
>> _______________________________________________
>> ARIN-PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List ([email protected]).
>> Unsubscribe or manage your mailing list subscription at:
>> https://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact [email protected] if you experience any issues.
>>
>>
>>
>>
>> **********************************************
>> IPv4 is over
>> Are you ready for the new Internet ?
>> http://www.theipv6company.com
>> The IPv6 Company
>>
>> This electronic message contains information which may be privileged or
confidential. The information is intended to be for the exclusive use of the
individual(s) named above and further non-explicilty authorized disclosure,
copying, distribution or use of the contents of this information, even if
partially, including attached files, is strictly prohibited and will be
considered a criminal offense. If you are not the intended recipient be aware
that any disclosure, copying, distribution or use of the contents of this
information, even if partially, including attached files, is strictly
prohibited, will be considered a criminal offense, so you must reply to the
original sender to inform about this communication and delete it.
>>
>>
>>
>> _______________________________________________
>> ARIN-PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List ([email protected]).
>> Unsubscribe or manage your mailing list subscription at:
>> https://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact [email protected] if you experience any issues.
>
>
>
>
>
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
>
> This electronic message contains information which may be privileged or
confidential. The information is intended to be for the exclusive use of the
individual(s) named above and further non-explicilty authorized disclosure,
copying, distribution or use of the contents of this information, even if
partially, including attached files, is strictly prohibited and will be
considered a criminal offense. If you are not the intended recipient be aware
that any disclosure, copying, distribution or use of the contents of this
information, even if partially, including attached files, is strictly
prohibited, will be considered a criminal offense, so you must reply to the
original sender to inform about this communication and delete it.
>
>
>
> _______________________________________________
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List ([email protected]).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact [email protected] if you experience any issues.
**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company
This electronic message contains information which may be privileged or
confidential. The information is intended to be for the exclusive use of the
individual(s) named above and further non-explicilty authorized disclosure,
copying, distribution or use of the contents of this information, even if
partially, including attached files, is strictly prohibited and will be
considered a criminal offense. If you are not the intended recipient be aware
that any disclosure, copying, distribution or use of the contents of this
information, even if partially, including attached files, is strictly
prohibited, will be considered a criminal offense, so you must reply to the
original sender to inform about this communication and delete it.
_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
