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