[rpd] New Proposal: Pv6 PI Clarification

Thu Apr 11 17:50:24 UTC 2019

> We agree here, but for app developing it is an evil thing. We can find other words to mean is highly problematic and bad.

Certainly it’s an inconvenient and destructive thing for App developers…

Skype for example, is not so much a communications platform as a NAT traversal platform which brings communications along for the ride.

> 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.

Fair enough, but it does provide a de facto standard way of doing this.

To the best of my knowledge, there was noIETF  standard for IPv4 NAT until long after it was virtually ubiquitous.

>> 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”.

Well, you’ll need a resolver that will resolve external addresses, but there’s no reason your existing resolvers can’t do both unless you’ve configured things in some very strange way. Absent strange (and arguably stupid) deployments, simply adding GUA addresses into the existing ULA environment should, actually, suffice.

> Network renumbering, today, is not a feasible "easy" thing.

In the case where you are completely replacing one set of numbers with another, I will (in some, even most non-trivial cases) agree.

In the case where you are merely adding GUA to an existing ULA deployment and not removing any of the existing addressing, I will disagree. It’s quite trivial to deploy additional addressing schemes in IPv6. It’s much more difficult to deprecate the old addressing scheme.

> Yes, I've considered that case, and actually had this converstation with the staff before the formal submission.

OK.

> 
> 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.

Yes, but each of those sites is an end-site and the policy as written (both existing and proposed) creates each site as synonymous with organization, or, treats each organization as synonymous with site (which is arguably worse).

Thus, either you’re looking at multiple fees per organization (and multiple ORG records and multiple votes), or, worse, you’re looking at treating each such organization as a single end-site, leaving the impression the teach end-site isn’t necessarily entitled to a /48.

Thus, I would argue that you should get a /48 per site whether or not they can be aggregated. Obviously in this use case, ideally, you aggregate the annoucement(s), and the /48s should be issued on nibble boundaries and aggregation should be encouraged.

> 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.

In this case, as written, the policy implies that each site becomes an AfriNIC member (which means fee per site, vote per site, etc.).

> 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.

Sounds reasonable.

Thanks,

Owen

> 
> 
>    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