Howdy, On 01.09.2024 01:06, Tobias Fiebig via address-policy-wg wrote:
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.
Aggregation of address assignment, not the GRT. Someone once said that the NCC is not the routing police.
I did not invent the 'routing police', multiple people use it, and it is meant as 'the NCC does not have the power to enforce routing decisions', not that they can't require aggregation. For the aggregation part I recommend reading ripe-399 'What is Aggregation?' and 'What is Deaggregation?'. If you plan on redefining the meaning of aggregation might as well start with that. If the purpose of the policy is to permit or encourage deaggregation, please state it clearly. Same as the intent of allowing networks similar to Freifunk to operate using PI, it might be in the discussions before however I cannot find this in the stated purposes.
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. See above; In that context, see for example Jori's message.
See Marco's message, he confirmed that the End Site can receive a larger assignment if the request justifies more /64s than what would fit in a /48, so this is not about aggregation at a single End Site.
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.
This point mixes 'end site' with 'end user holding multiple end sites'; In fact, the proposed change effectively reinforces a /48 _per end site_.
It does not mix anything, with the current policy each End Site can get a /48 (or more if justified). The fact that the NCC reserves up to a /46 for each /48 assigned allows for future growth of that End Site, just as the RFCs mentioned recommend. Could you point me to the paragraph reinforcing a /48 _per end site_?
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.
If these assignment holders qualify for a single larger assignment, they will currently already hold (or would be allowed to hold) one /48 per each of these end-sites. As such, there would not be a change in relation to the deaggregation of the GRT, with the difference of the database an assignment plan actually aggregating.
See Tore's messages about deaggregation. What would the benefits of this new 'DB Aggregation' be? Also keep in mind the 'one large inet6num and multiple route6: not matching the inet6num' problem that would be created.
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"?
While I agree that, in general, this information would be useful, it works on a selected premise of aggregating the GRT, not assigned space.
I would recommend working on that premise too, see above, ripe-399. Using some terms with different meaning to suit some goals is like speaking different languages.
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? It remains more defined than current terminology. Furthermore, it is definitely clear what is _not_ the same geographical end-site.
Current policy text is short and clear: - you can provide addresses (not prefixes) in order to let visitors connect to the assignment holder's network (wifi?) - you can connect a server or appliance (does not mention "static" addressing, but is that required? if my appliances are getting dynamic addresses they should not be allowed?) - you can also connect point-to-point with 3rd parties (that are not called 'ISPs', so could be ISPs, could be other End Users, could be anything). Proposed policy allows offering up to a /56 and limits point to point links to connect to 'other ISPs' instead of '3rd parties'.
- Allows /56 or longer to different entities without being considered a sub-assignment This, again, is a stated purpose, as a static use of, even, a static /128, to connect, e.g., a server to a network is--per the last impact assessment of the policy change that introduced the explicit permission to use addresses for connecting servers or appliances--is not permitted.
However, the current policy text allows 'connecting a server or appliance to an assignment holder's network and setting up point-to-point links with 3rd parties'. Perhaps not with a /56 (as that would be a sub-assignment), but you are saying it does not allow them at all.
- "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.
Still, at the moment, this is not permitted by the policy. In fact, if you'd want to use one /48 per end-site for an infrastructure, even if both end-sites had the same routing policy, you would be forced to use two /48s that are _not_ in the same /47. Been there, done that, argued for weeks.
If they are different End Sites how can they have the same routing policy? Please use the current definitions of terms such as 'Aggregation', 'End Site', or specify that you are using the redefined terms so we can speak the same language.
- "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.
Correct. Server in your rack, fine. PPPoE connection for an end-user: not fine.
I feel I'm creating a loop now, but: you say PPPoE is not ok, a CPE installed at different location for providing Internet is ok? (see below)
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
Correct. Because otherwise you could argue that the CPE is owned by an ISP, and, hence, each customer of theirs would be a different end-site.
I see nothing to argue here, providing Internet access at a different location is what an ISP does, installing/offering CPEs too. See above, providing Internet over PPPoE is not ok, providing Internet at a different location ok. Loopy.
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?
I would love to learn how you can create a 'different location' that is neither topologically not geographically different, without it being the same location.
I would love to learn that too, however, my comment was on the lines of 'why does it have to be specific geo/topo in one place and in the other place is ok to be generic?', sorry if it was not clear.
and /56 or longer to different entities. Is exchanging traffic and Internet routing information not what the Internet is?
While I am sure that some people actually speak iBGP between _all_ nodes in their network (I think Q runs a kubernetes cluster directly hooked into their iBGP), I am pretty sure not every link comes with a BGP session.
The proposed policy text mentions different entities. Unless you are referring to Q in the Star Trek way, running whatever protocols inside your cluster == your infrastructure so you would be allowed to use the whole /48. If you have multiple Q entities and assign them a /56 each that would be a sub-assignment under the current policy, no matter what protocol they use (i/eBGP, RIP, static, ...). Wikipedia reference: https://en.wikipedia.org/wiki/Q_(Star_Trek)
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?
Please provide quotes. At the moment, this reads a bit like a mix between 'stated text' and 'interpretation of text under specific premises';
Sure, here we go: - 'stated text' of Purpose for 2.6: "Explicitly prohibits using PI to connect remote End Sites of customers to the Internet, except for p2p links to other ISPs." Are the customers of an End User 'other ISPs'? Providing Internet at a different location and/or offering a CPE is not what an ISP does? - 'stated text' of proposed 2.9.2: "a single device with the main purpose of providing Internet access to a single End User / Customer from a location does not constitute an End Site of an assignment holder." If it does not constitute an End Site of the assignment holder it must constitute an End Site of the 'single End User / Customer', right? But providing Internet to customers at different End Sites is prohibited according to the Purpose of the proposed 2.6.
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.
How would two networks using only PI peer over a PNI?
See current policy text of 2.6: '... and setting up point-to-point links with 3rd parties'.
I am not aware of any implicit need to use LL for interconnectivity, could this be clarified?
See RFC4291.
Could you be more specific? Which section/paragraph of that RFC implies LL for interconnectivity? If you really really want a PNI without providing ptp to your peer, you could do this: 2001:db8:a::/48 - PI End User 1 2001:db8:b::/48 - PI End User 2 PI E U 1 - 2001:db8:a::a/128 - static route to 2001:db8:b::b/128 over that interface PI E U 2 - 2001:db8:b::b/128 - static route to 2001:db8:a::a/128 over that interface Each End User uses only addresses from their /48. Happily set up eBGP and exchange the best routing information available. Or any other protocol.
- 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.
Currently, applying reasoning clearly made in the context of PA assignments to PI leads to unintentional outcomes. PI and PA assignments are, necessarily, different. As such, they should be treated differently.
Currently 4 out of 5 RIRs have very similar definitions of an End Site. APNIC and LACNIC are the most similar to the RIPENCC wording, ARIN has a shorter but similarly in meaning definition (more strict). AFRINIC does not define the term although they use it. It is not clear to me why there should be created a difference between PA and PI End Sites. Why should a PI End Site have special treatment over a PA End Site? Is this worth creating major differences in the policy compared to the other RIRs? Could you please explain this need better? The main difference between PA and PI addresses is who assigns it: the LIR or the NCC. In theory both are supposed to perform the same checks before assigning space, and with the same definition of an End Site the same prefix length would be assigned. Secondary difference would be that you can keep the PI when changing LIRs/ISPs.
- 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.
Yes, and that is not so difficult:
Me selling Internet access to _a_ customer, who then does their thing -
not ok.
Me running an open wifi / freifunk (not a single end-user in terms of entity) -> ok.
You running an open wifi at your End Site - more than ok, great. You deploying an infrastructure that is both geographically and topologically different from your End Site in order to provide wifi (even for free) means you are an ISP. I think this is the current interpretation of the policy and also the "problem" you are trying to fix. I see this as a feature, even if run by volunteers, even if I would get paid to use it, it is still an ISP providing Internet access to people. Don't get me wrong, Freifunk is a cool thing, from a technical point of view what they do is amazing with the mesh stuff, but this does not change the fact that they provide Internet access to people just like an ISP would. Best, Radu