Hi,
I agree with others that this changes too many things at once and might
have unexpected consequences, so I suggest it is split into multiple
proposals. i.e. this is to allow guest WiFis, this is to allow hosting,
this redefines End Sites, this is to allow larger than /48s, etc.
By reading the current and proposed policy I notice some confusing usage
of more/less specific, larger or shorter prefixes in the current policy,
perhaps this is something to clarify in the future.
As I read it, the current version of the proposal complicates the policy
instead of clarifying, adds impossible to verify requirements, uses new
and undefined terms and has some contradictions, while the clear outcome
is making it easier to obtain larger than /48 assignments based on
routing requirements instead of address usage. One such contradiction is
related to the aggregation as one of the stated purposes of the proposal
while the text explicitly allows announcing separate prefixes from the
assignment (de-aggregation), and it seems phrased for a very specific
and complex use-case.
I am surprised by the cases of assigning multiple /48s for the same End
Site that would otherwise be aggregated that were mentioned in the
thread, is there an example of such case with some more details? I am
unable to find any. This should be fixed, however I see no issue with
assigning based on usage.
A /48 is a one-size-fits-all default for End-Sites (RFC3177/6177),
except for *very large subscribers*, a /48 has 256 x /56 or 65536 x /64,
and one /64 has *a lot* of addresses available for connecting devices.
With the current proposed text I do not foresee a queue of PI holders
seeking to aggregate, but a queue of PI holders seeking single larger
assignments to de-aggregate.
Perhaps some numbers from the NCC would help? Such as how many PI
assignments are there (if multiple /48s are in the same ticket this is
not necessarily visible in the DB).
xxxx /48s PI
yyyy /46s PI
zzzz multiple /48s PI in the same ticket for use at the same location
(that could be aggregated)
And maybe some reasons for multiple /48s such as "different End Sites"?
Here is a breakdown of what I found debatable or confusing:
New 2.6
- Introduces the term "geographical End Site" that is undefined and
impossible to verify. Is my building number +/-1 the same geographical
End Site? Is the geographical limit set by the range of the WiFi? The
NCC service region?
- Allows /56 or longer to different entities without being considered a
sub-assignment
- "using more specific prefixes from a less specific assignment for
different parts of the same infra does not constitute a sub-assignment"
=> This is already covered by the first paragraph, for me it is expected
to use more specific prefixes inside your infra, while announcing the
aggregate to the Internet, this is what the assignment is for.
- "any other use of a prefix ... to connect a separate End Site of
another entity to the Internet always constitutes a prohibited
sub-assignment"
=> So it is not allowed to use any prefix up to /128 to connect a
separate End Site of another entity to the Internet. But it is allowed
to "provide connectivity to another entity", not a device or multiple
devices but an "entity". It is not allowed if it is a separate End Site.
The proposed 2.9 says that a device placed at a different location (CPE)
for the purpose of providing Internet access to a single user is not a
different End Site (is the device/CPE something you can touch or is this
SDN-way?). So providing Internet access at a different location (in this
case not geographical or topological) to a single user is allowed. Is
the single user an entity?
More confusion adds up since the paragraphs above allow /64 or longer to
connect to other ISPs for the purpose of "exchanging traffic and
Internet routing information", and /56 or longer to different entities.
Is exchanging traffic and Internet routing information not what the
Internet is?
How is an ISP defined in this context? Since providing Internet to a
single user (even at a different location) is allowed but being an ISP
is not. Is not providing Internet access what an ISP does?
But this can go on up to the meaning of life, the universe and
everything and we will only get /42s from that point on.
Usually when providing *services*, the ISP assigns the range for the
interconnection from their address space, not the End User (PI holder),
this change would make the PI holder an ISP while disallowing them to be
an ISP at the same time.
I am not aware of any implicit need to use LL for interconnectivity,
could this be clarified?
New 2.9
- Introduces yet another undefined term: the "topological location"
2.9.2
- Different routing policies are defined in a complicated manner as they
do not traverse other End Sites of the same assignment holder, unless
there is a loss of outbound connectivity where a prefix from the
assignment is used (so they do not traverse unless they traverse). This
explicitly allows de-aggregating the PI prefix and using the
de-aggregated sub-prefixes at different locations.
- Adds impossible to verify things such as L2s between End Sites. Trust
me, this is L2.
- Differentiate between End Sites in PI and allocation cases: providing
different definitions of the same term adds confusion while the benefits
of defining End Sites differently are not clear.
- Clarify that L2, clarify that aggregates or prepends do not merge
routing policies: These are impossible to verify claims, RIPE NCC is not
the Routing Police or L2 Police.
- Make explicit that placing a single device at another geographical
location with the main purpose of providing a single End User with
Internet access does not make that location an End Site of an assignment
holder. This suggests that using parts of the assignment for providing
Internet access to customers at different locations from the End Site is
ok, however it is prohibited by the new 2.6.
New 5.4
5.4.2 Assignments from IPv6 allocations
=> In my opinion this paragraph would encourage/permit de-aggregation of
assignments from allocations (PA) based on routing requirements.
The original version is pretty clear that it refers to assignments "from
their LIR or ISP" and there is no room for interpretation if this is
referring to PI, so no changes are required to the policy text here.
New 7.1
The very short, to the point, minimum assignment size of /48 is replaced
by a very long and interpretable text.
- Introduces a new term "special purpose PI assignment" that may deviate
from generic PI assignment criteria
- "to avoid fragmentation" the new text adds routing policies as
permitted justification for shorter prefixes and explicitly allows more
specific prefixes of PI space (de-aggregation of PI).
7.1.3 adds a reevaluation mechanism for previous assignments in order to
provide contiguous address space, however that will be de-aggregated due
to routing requirements and/or multiple End Sites. Contiguous address
space makes sense for aggregation purposes (single prefix announced).
In my opinion this does not resolve the discussions around what
constitutes an End Site, and things such as L2 connectivity are
impossible to objectively verify by external parties.
The current policy does not in fact disagree with RIPE-451 (IPv6 Address
Space Policy For IXPs) since that is IXP address space, not IXP PI (even
though it is subject to contractual requirements similar to PI).
The consideration that a /44 would stop de-aggregation to /48s
contradicts the text from the proposed changes - different routing
policies are let's say hard to implement if only the aggregate is
announced, and, given that PI networks are comparatively small (as the
proposed text says) they most likely fit in the /48 default.
Radu
On 27.08.2024 17:10, Leo Vegoda wrote:
Dear Working Group,
This is a reminder that we need your input on this policy proposal.
If you support the proposal in principle, please say so on this list.
If you disagree with the proposal, please explain the problem you seel.
Many thanks,
Leo Vegoda, for the Address Policy WG co-chairs
On Tue, 13 Aug 2024 at 05:17, Angela Dall'Ara <[email protected]> wrote:
Dear colleagues,
A new RIPE Policy Proposal, 2024-01, "Revised IPv6 PI Assignment Policy"
is now available for discussion.
This proposal aims to define End Sites and requirements for “IPv6 PI
Assignments” and “Assignments from IPv6 Allocations”, clarifies
permitted use cases and introduces IPv6 PI issuance at the Nibble
boundary and new principles for aggregation and registration.
You can find the full proposal at:
https://www.ripe.net/community/policies/proposals/2024-01
As per the RIPE Policy Development Process (PDP), the purpose of the
Discussion Phase is to discuss the proposal and provide feedback to the
proposer.
Taking in consideration the holiday period, the Address Policy WG Chairs
decided to allow five weeks for this initial phase.
At the end of the Discussion Phase, the proposer, with the agreement of
the WG Chairs, will decide how to proceed with the proposal.
The PDP document can be found at:
https://www.ripe.net/publications/docs/ripe-781
We encourage you to review this proposal and send your comments to
[email protected] before 18 September 2024.
Kind regards,
Angela Dall'Ara
Policy Officer
RIPE NCC
-----
To unsubscribe from this mailing list or change your subscription options,
please visit:
https://mailman.ripe.net/mailman3/lists/address-policy-wg.ripe.net/
As we have migrated to Mailman 3, you will need to create an account with the
email matching your subscription before you can change your settings.
More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
-----
To unsubscribe from this mailing list or change your subscription options,
please visit:
https://mailman.ripe.net/mailman3/lists/address-policy-wg.ripe.net/
As we have migrated to Mailman 3, you will need to create an account with the
email matching your subscription before you can change your settings.
More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
-----
To unsubscribe from this mailing list or change your subscription options,
please visit:
https://mailman.ripe.net/mailman3/lists/address-policy-wg.ripe.net/
As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings.
More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
