Search RPD Archives
[rpd] New Proposal: Pv6 PI Clarification
JORDI PALET MARTINEZ
jordi.palet at consulintel.es
Fri Apr 12 08:36:03 UTC 2019
Hi Jaco,
El 12/4/19 10:27, "Jaco Kroon" <jaco at uls.co.za> escribió:
Hi,
On 2019/04/11 14:35, Lee Howard wrote:
>
> On 4/11/19 7:49 AM, Jaco Kroon wrote:
>> Hi,
>>
>> Use of ULA compared to RFC1918 addresses?
> There is little or no consensus around how to use ULA addresses.
Fair enough. I never even contemplated it's use myself, and frankly, I
agree that if you can get public space, you should use it. I suspect
one case where ULA would make sense if if you're receiving dynamic
In my opinion this is a misconception. There is no reason for using dynamic (which we call non-persistent, to avoid confusion with DHCP thing) in IPv6. I suggest to read RIPE690. Ideally you could use ULAs for internal communications, as done in homenet, but this is not available in general, unless you use OpenWRT.
delegations from upstream service provider(s) but still need addresses
to be stable (static) inside your organisation. Anyway, the addresses
are available for use by any organisation that would like to use them,
for whatever reason.
>>
>> Not objecting. Making IPv6 more freely available might just help
>> with uptake, which we really need.
>
> Among the reasons I have heard for delaying IPv6 deployment, I have
> never heard that IPv6 addresses were not freely available enough. Is
> it an issue for you or your organization?
No. As an LIR I've got a /32 of which we've currenly a handful of /48s,
for our own network use and a couple of dedicated point-to-point
business customers. The two primary issues we've got:
1. In some cases we're using IPC type connections for last-mile
connectivity, in this specific case this means two BGP connections onto
two different VRFs, one for uplink and one for downlink, and that only
supports IPv4 currently, in spite of having been pushing for IPv6 for a
while. Here we can get around it by establishing an L2TP connection
from the client back to us and then delegatin a /56 or even a /48 back
over the L2TP connection.
I guess this is a vendor specific issue ...
2. Tracking the delegations is turning out to be a further nightmare
with most of the routers that we've tested not informing our radius
server of delegations made by it to sessions. We've mostly tested with
MikroTik though and based on readins it looks like some other routers
I'm sorry to say that MikroTik, in terms of IPv6 support, is one of the worst vendors. We tried to help them, for free, for example, in the support of other transition mechanisms (such as IPv6-only and IPv4-as-a-Service), and they even didn't respond. They even confuse different protocols and use wrong naming (example 6to4 vs 6in4).
may be acting differently. This may also be why the providers
contemplated in (1) isn't currently supporting IPv6 towards us to begin
with. The exact scenario we tested: /64 allocated on router for PPPoE
connections, it'll happily inform us of the link-address assigned (/128)
but one doesn't need this as the link-local is perfectly adequate here
but it does help if you need to remotely log in on client-routers for
support, once link is established (radius auth and session start is
completed) the CPE will then request a delegation, we will then provide
a /56 - and we then really expect a form of session update to inform us
of the additionally delegated prefix, but we're unable to get hold of this.
Summary: On dedicated links - no issues, everything works well, because
pretty much the delegations are static towards the customer, and
tracking beyond that static delegation isn't our responsibility, for
dynamic delegations though where we need to for various reasons know
which prefixes were delegated to which customers at what times ... big
problem.
Again, vendor specific, there are many product in the market doing it correctly, never mind you use persistent and non-persistent prefixes for customers.
Kind Regards,
Jaco
>
> Lee
>
>>
>> Kind Regards,
>> Jaco
>>
>>
>> On 2019/04/11 13:13, JORDI PALET MARTINEZ via RPD wrote:
>>> Hi all,
>>>
>>> I think the problem statement is very clear and the solution as
>>> well, but as usual, I'm happy to clarify and work out if anyone find
>>> any issues.
>>>
>>> Thanks!
>>>
>>> Regards,
>>> Jordi
>>>
>>> El 11/4/19 13:03, "Ernest Byaruhanga" <ernest at afrinic.net> escribió:
>>>
>>> A new proposal has been received as follows:
>>> IPv6 PI Clarification:
>>> https://afrinic.net/policy/2019-v6-d1#proposal
>>> It removes conditions around the need to announce IPv6 PI
>>> space within 12 months of getting it, as required in CPM6.8.2
>>> *Plain text version below* :
>>> 1.0 Summary of the problem being addressed by this
>>> proposal
>>> By means of policy proposal “IPv6 PI Update”
>>> (AFPUB-2018-V6-004), the IPv6 Provider Independent (PI) space policy
>>> that provides IPv6 space for end-sites was revised/updated.
>>> This revision however overlooked a sentence in the previous
>>> section 6.8.2.v, which read:
>>> “The 'end-site' must show a plan to use and announce 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”.
>>> This text was retained under 6.8.2.iv.
>>> Of course, this doesn’t make sense because there are several
>>> possible cases, which are in the scope of this policy, that will not
>>> announce their IPv6 PI address space, such as:
>>> IXP’s LAN peering space.
>>> In IPv6 there is no private address space equivalent to the
>>> IPv4 one as per RFC1918, so if an organization needs IPv6 space for
>>> numbering a network or a set of them, even if those aren’t connected
>>> today to the Internet, the RIR should be able to provide that space.
>>> 2.0 Summary of how this proposal addresses the problem
>>> Simple rewording of the text to allow those cases that
>>> don’t need to announce their IPv6 PI space.
>>> 3.0 Proposal
>>> .....................................
>>> 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
>>
>> _______________________________________________
>> 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
_______________________________________________
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