Search RPD Archives
[rpd] New Proposal: Pv6 PI Clarification
JORDI PALET MARTINEZ
jordi.palet at consulintel.es
Thu Apr 11 21:23:21 UTC 2019
El 11/4/19 20:20, "Owen DeLong" <owen at delong.com> escribió:
> On Apr 11, 2019, at 10:54 AM, Mark Elkins <mje at posix.co.za> wrote:
>
> I'll side with the Owen rewrite - keeping things simple.
>
> However - I don't quite understand part V:
>
> V. The organization must show a plan to use the IPv6 provider independent address space at each of the end-sites for which addresses are obtained within twelve (12) months.
>
> Shouldn't the plan be provided up front with the application? So why 12 months? As far as I can see, if a small organisation can prove the "(iii) need for the IPv6 PI address space" then the plan could be really simple - just connecting the company LAN to two different ISP's (or something similar). So why allow for a delay providing the plan? I think (v) is unnecessary.
The plan should be for use within 12 months. The presentation of the plan should be up front.
If you have wording which would resolve this ambiguity, I (and I’m sure Jordi as well) welcome an editorial suggestion.
I think this will made it (and is comparable to what exist in other RIRs):
iv. The organization must deploy the IPv6 provider independent address space at each of the end-sites, for which addresses are obtained, within twelve (12) months.
Is that reasonable? Or a big organization may need more time to deploy IPv6 in all the end-sites?
I've redrafted the full policy section 6.8, as the use of end-user organization requires some additional changes. Anyway, I think it makes sense to wait for the impact analysis before an official submission.
Owen
>
> please correct me.
>
> Otherwise I like this.
>
> On 2019/04/11 16:20, JORDI PALET MARTINEZ via RPD wrote:
>> Hi Owen,
>>
>> El 11/4/19 15:59, "Owen DeLong" <owen at delong.com> escribió:
>>
>> > On Apr 11, 2019, at 5:10 AM, JORDI PALET MARTINEZ via RPD <rpd at afrinic.net> wrote:
>> >
>> > Hi Jako,
>> >
>> > I understand that it is easy to believe that ULA is equivalent to RFC1918, but is not.
>> Indeed, unlike RFC-1918, which was necessary to support address conservation through NAT, ULA offers no such benefit
>> and as such, the disadvantages of even having it generally outweigh its benefits, IMHO.
>> > Furthermore, with IPv4 private addresses, you can use a standard protocol called NAT, which is an evil. We want to avoid repeating IPv4 mistakes, right?
>> NAT is not evil. NAT is an unfortunate tragedy which was necessitated
>>
>> We agree here, but for app developing it is an evil thing. We can find other words to mean is highly problematic and bad.
>>
>> by a shortage of numbers in IPv4 and a subsequent failure to deploy IPv6 in a timely manner. Fortunately, there is no need for such a solution in IPv6 and hopefully through education and discussion, we can eventually return to a true peer-to-peer internet with an end-to-end addressing model that enables all direct communications permitted by administrative policy. NAT is a technology I wish we had never invented, but it was done with the best of intents and there is no legitimate denial that it has (temporarily) provided some relief of a pain point inherent in IPv4.
>> Unfortunately, there are a lot of misconceptions that have become “conventional wisdom” on the subject of NAT.
>> NAT is not a security tool. Indeed, the difficulty of identifying the actual participating host across NAT boundaries is antithetical to security.
>> NAT is not a way to simplify multihoming. BGP needs to be demystified. There’s no reason we cannot develop routers and standards which would allow simple end-site multihoming to be done in an automated fashion using DHCP-PD and autonomous configurations of BGP amongst cooperating organizations.
>> > In IPv6 you don't have a STANDARD protocol for an equivalent functionality as NAT.
>> This isn’t entirely true. NPT is a standard which has (RFC 6296)
>>
>> RFC6296 is not a standard document, it is and Experimental RFC, which is not something defined to be deployed in the global Internet. This means among other things that there is no guarantee of interoperability among different implementations.
>>
>> provides equivalent functionality to IPv4 NAT for most practical purposes. While it does not provide the many to one address conservation/address sharing mechanisms inherent in the most widely deployed form of NAT (which is more accurately called NAPT, Network Address and Port Translation), the only benefit of NAPT over stateless static NAT is that it helps relieve the address shortage problem. Since that problem doesn’t exist in IPv6, there’s no need for that aspect of NAPT and thus simple stateless NAT based on translation of only the prefix is sufficient for virtually any practical purpose.
>> > If you use ULA for a network that you believe is disconnected for "ever" from Internet, and tomorrow you need to connect it, you need to renumber. There is no need for that, because in IPv6 we don't have a scarcity problem (and will not have in several hundred years - so most probably we will replace the protocol with something else, but not because address exhaustion), so it doesn't make sense to be so restrictive.
>> You do not need to renumber. You can achieve what you want by
>>
>> If you have services, including DNS, based on the ULA addresses in an internal network you need to do "something". I call it renumbering not just in the sense of replacing/adding addresses. If you use GUA, you can have an internal DNS and then just need to make sure that it is also public if you, at some point, want to make the GUA addresses no longer just "internal".
>>
>> simply adding GUA to the hosts in question. I agree that ULA is an unnecessary waste of time, but, nonetheless, we should not spread disinformation and fear about it. We should honestly describe the actual tradeoffs and realities. We should strive to educate operators and then let them make informed decisions.
>>
>> Network renumbering, today, is not a feasible "easy" thing.
>> I do think the proposal can be improved. I believe that there is a further problem with the existing language which is preserved in the proposal. Namely both the current language and the proposal conflate the idea of end-site and organization.
>> Specifically the text which requires an end-site to become an AfriNIC end-user member.
>> It is possible that a single organization (which should only require (and only be eligible for) a single AfriNIC membership may have several end sites. Consider, for example, a bank which operates a network connecting it’s many branches throughout the region. Such an entity is not (necessarily) an LIR, but, may well be an End-User which has a multitude of end sites. Such an entity should, under a single ORG ID and a single AfriNIC end user membership be able to obtain resources (/48) for each of its end sites.
>>
>> Yes, I've considered that case, and actually had this converstation with the staff before the formal submission.
>>
>> I'm going to review the wording right now, but I think it is supported. An organization with multiples sites, will probably fall in one of two cases:
>> 1) Multiple sites connected with L2 and using BGP to their upstreams (a bank, a multi-campus university, etc.), will be able to obtain a prefix length sufficient to accommodate the entire number of sites, hopefully in the nibble boundary and announce a single aggregated prefix.
>> 2) Multiple sites not connected among them and being announced as "different" networks, for example, even with different ISPs. Should request a single /48 for each site.
>> Of course, there is also a possible mix case among 1 and 2 above.
>> Fees are out of scope for the policy process, so the board should set fees accordingly, and I have no problem with there being a fee increase as the number of end site assignments increases (though I do not believe there should necessarily be a linear correlation of those increases). (For example, in the ARIN region, the amount of space increases exponentially compared to the fee increase.)
>> Agree.
>> As such, I propose the following rewrite:
>> 6.8.2 Assignment Criteria
>> Assignment target — End-user organizations which provide services for their administrative organizations’ network, regardless of their size.
>> Assignment criteria:
>> I. The organization must not be an LIR.
>> II. The organization must be or become an AfriNIC End User Member.
>> III. The organization must justify the number of end-sites and the need for Provider Independent addressing.
>> IV. Absent additional justification, it shall be assumed that each end-site inherently justifies issuance of a /48.
>> V. The organization must show a plan to use the IPv6 provider independent address space at each of the end-sites for which addresses are obtained within twelve (12) months.
>> VI. To the extent practicable, the organization should aggregate any announcements of prefixes issued under this policy so as to minimize global routing table growth.
>>
>> I think I fully agree with this change.
>>
>> I just started a track-of-changes in my v2 draft, but will wait a few days for more inputs and the impact analysis of the actual version, to avoid missing anything else.
>>
>> Owen
>> >> .....................................
>> >> Proposed (New) CPM content:
>> >>
>> >> 6.8.2 Assignment Criteria
>> >> Assignment target - End-sites which provide services for a single administrative organisations' network, regardless of their size.
>> >> Assignment criteria:
>> >> i. The end-site must not be an LIR
>> >> ii. The end-site must become an AFRINIC End User Member and pay the normal AFRINIC fee for its membership category
>> >> iii. The end-site must justify the need for the IPv6 PI address space.
>> >> iv. The end-site must show a plan to use the IPv6 provider independent address space within twelve (12) months.
>> >> v. The IPv6 provider independent address space, if announced by the end-site should not be disaggregated.
>> >> .....................................
>> >>
>> >> Current CPM content (to be replaced by the proposed text above)
>> >>
>> >> 6.8.2 Assignment Criteria
>> >> Assignment target - End-sites which provide Public Internet services for a single administrative organisations' network, regardless of their size.
>> >> Assignment criteria:
>> >> i. The end-site must not be an LIR
>> >> ii. The end-site must become an AFRINIC End User Member and pay the normal AFRINIC fee for its membership category
>> >> iii. The end-site must justify the need for the IPv6 PI address space.
>> >> iv. The end-site must show a plan to use the IPv6 provider independent address space within twelve (12) months. After that period, if not announced, the assigned IPv6 PI address space should be reclaimed and returned to the free pool by AFRINIC.
>> >> v. The IPv6 provider independent address space to be announced by the end-site should not be disaggregated.
>> >> .....................................
>> >>
>> >>
>> >> 4. References
>> >>
>> >> Other RIRs have already accommodated this requirement in their policies:
>> >> - APNIC: 10.1.4. Provider Independent IPv6 assignment
>> >> https://www.apnic.net/community/policy/resources#Part%203:%20IPv6%20Policy
>> >> - ARIN: 6.5.8.1. Initial Assignment Criteria
>> >> https://www.arin.net/participate/policy/nrpm/#6-5-8-direct-assignments-from-arin-to-end-user-organizations
>> >> - LACNIC: 4.5.4.2 Direct assignment of portable IPv6 addresses to End sites not having portable IPv4 addresses previously assigned by LACNIC
>> >> https://www.lacnic.net/684/2/lacnic/4-ipv6-address-allocation-and-assignment-policies
>> >> - RIPE: IPv6 Provider Independent (PI) Assignments
>> >> https://www.ripe.net/publications/docs/ripe-707#IPv6_PI_Assignments
>> >>
>> >>
>> >> --
>> >>
>> >> (Sent on co-chairs behalf)
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> **********************************************
>> >> 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.
>> >>
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> RPD mailing list
>> >> RPD at afrinic.net
>> >> https://lists.afrinic.net/mailman/listinfo/rpd
>> >
>> >
>> >
>> >
>> > **********************************************
>> > 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.
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > RPD mailing list
>> > RPD at afrinic.net
>> > https://lists.afrinic.net/mailman/listinfo/rpd
>>
>>
>>
>> **********************************************
>> 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.
>>
>>
>>
>>
>> _______________________________________________
>> RPD mailing list
>> RPD at afrinic.net
>> https://lists.afrinic.net/mailman/listinfo/rpd
>
> --
> Mark James ELKINS - Posix Systems - (South) Africa
> mje at posix.co.za Tel: +27.128070590 Cell: +27.826010496
> For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za
>
>
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net
> https://lists.afrinic.net/mailman/listinfo/rpd
_______________________________________________
RPD mailing list
RPD at afrinic.net
https://lists.afrinic.net/mailman/listinfo/rpd
**********************************************
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.
More information about the RPD
mailing list