This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/address-policy-wg@ripe.net/
[address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
- Previous message (by thread): [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
- Next message (by thread): [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Maximilian Wilhelm
max at rfc2324.org
Wed Nov 8 18:18:25 CET 2017
Anno domini 2017 JORDI PALET MARTINEZ scripsit: Hi, > Ok, here is it then. Hopefully we have a lot of fun and good noise ;-) (that's music?) > The main idea is to allow what Max (and many other people) needs in PI, but not having restrictions. > > For that, what I’m proposing is: > > 1) Change the actual definition of Assign in 2.6, to: > 2.6. 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 organisations and are not to be sub-assigned to other parties, with the exception of Provider Independent (PI). > > 2) Remove last paragraph in 7. IPv6 Provider Independent (PI) Assignments > So, REMOVE: The PI assignment cannot be further assigned to other organisations. > > Rationale: > > a. Arguments Supporting the Proposal > This proposal will avoid the situations of breaking existing policy when a network using PI is using the addressing space for point-to-point links or in cases such as providing connectivity to employee or visitor devices (BYOD), hot-spots, and similar situations. > At this way, regardless of if a single /128 or /64 is sub-assigned, and independently of what technology is used for that (SLAAC, DHCPv6, DHCPv6-PD), the restriction is no longer an issue. > > b. Arguments Opposing the Proposal > It can be argued that this proposal could increase the number of PI request to RIPE NCC. > > Mitigation/counter-argument: This is not an issue and should not be considered as a “bad-effect”. > > The resulting policy could be used to circumvent the allocation policy, avoiding creating a LIR. > > Mitigation/counter-argument: This seems not to have sense as there must be a justification process anyway, and because the starting point is /48, an ISP willing to connect customers, will really want to be an LIR. Furthermore, if we want to be restrictive on this, we could add a limitation that the maximum sub-assignment can be /64. > Thoughts? I like the idee, but I'm totally with Nick on this one: It's a much larger change - which I support - but don't think, that we can get this implemented into policy in the near future. So I propose to *now* implement my proposal with the smaller change and then get the bold move of lifting more restrictions or even lifting the distinction between PI/PA going. I think it's safe to predict that if we shift to your approach right now, we will still be discussing this on the next RIPE meeting, or even the one after that as the area of things touched by this change is considerably larger, as pointed out by others already. That way we solve the real time problem - which we all agree on, right? - right now and make PI great again, and then have time to make the world and even better place afterwards. :-) Best Max
- Previous message (by thread): [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
- Next message (by thread): [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]