Job, and others,
We (ARIN) did receive the request in our suggestions portal late last week. We
will be reviewing the submission and posting updates on the ARIN public
website. A few contributors to this thread have used this vehicle to make
their own submissions for new features or product
Hi all,
On Sun, Jun 25, 2023 at 01:06:47PM -0500, Brian Knight via ARIN-PPML wrote:
> If I understand the below right, the assigner / upstream may delegate
> authority (create ROAs) to originate the route, but may not delegate
> management of that authority to the assignee.
>
> I'm saying it may
> On Jun 26, 2023, at 13:38, Brian Knight wrote:
>
> On 2023-06-25 14:10, Owen DeLong wrote:
>>> On Jun 25, 2023, at 11:06, Brian Knight wrote:
>>> Hi Owen,
>>> If I understand the below right, the assigner / upstream may delegate
>>> authority (create ROAs) to originate the route, but may no
On 2023-06-25 14:10, Owen DeLong wrote:
On Jun 25, 2023, at 11:06, Brian Knight
wrote:
Hi Owen,
If I understand the below right, the assigner / upstream may delegate
authority (create ROAs) to originate the route, but may not delegate
management of that authority to the assignee.
They mus
> On Jun 25, 2023, at 11:06, Brian Knight wrote:
>
> Hi Owen,
>
> If I understand the below right, the assigner / upstream may delegate
> authority (create ROAs) to originate the route, but may not delegate
> management of that authority to the assignee.
They must be able to delegate the ma
Hi Owen,
If I understand the below right, the assigner / upstream may delegate
authority (create ROAs) to originate the route, but may not delegate
management of that authority to the assignee.
I'm saying it may be helpful to have delegation of management as well.
If I, the assigner, could p
ROAs are supposed to turtle down. In the end ISPs will end up signing ROAs on
individual DHCP leases allowing packets from these addresses permitted through
other ISPs BCP39 filters when customers are multi-homed. We aren’t at this
stage yet but that is the future we all should be working too.
I would imagine you would defend this Owen. But I didn't misunderstand.
ROAs should be signed by organizations who receive IP space from the
RIR. They are the ones responsible for that IP space. If you let these
organizations re-assign to other Autonomous Systems you start to void
the RIR func
An assignee can’t create their own ROA, just as an ISP that gets a block from
ARIN needs ARIN to create their ROA (or at least to sign it).
The upstream must sign the ROA for it to be valid. That’s the whole point. The
upstream is delegating authority to originate the route.
Owen
> On Jun 23,
Fernando,
It is possible today for an org to create a route entry in the IRR for a
network reassigned to them by an LIR/ISP. The assignee has the control
over the route record, not the assigner.
Recognizing that the goals and mechanisms of IRR are similar but not
identical to RPKI, it would
Dear ARIN-PPML,
Hope this email finds you in good health!
Please see my comment below, inline...
Thanks.
Le 23/06/2023 à 18:03, August Yang via ARIN-PPML a écrit :
Current hosted RPKI implementations across all RIRs follow a
hierarchical structure, where access to manage ROAs terminates at t
On 2023-06-23 12:03, August Yang via ARIN-PPML wrote:
It's worth noting that this issue primarily stems from technical
constraints of the hosted RPKI implementation, rather than being a
direct policy matter related to NRPM.
Intentionally provocative, but semi-serious: can we use policy to forc
End user customers that connect via BGP are just as much in need of this (if
they consider RPKI important, note I do not) as any others BGP speaker.
If RPKI is to fulfill its purpose, then anyone who originates a prefix in BGP
should be able to get a properly chained ROA for that prefix showing
You fundamentally misunderstand the situation, then.
ROAs must be delegated according to the way networks are delegated. Lots of
ISPs get addresses from upstream ISPs who get them from upstream ISPs who get
them from ARIN.
In the case where IP addresses are delegated ARIN->ISP A->ISP B->ISP C,
On 2023-06-23 13:24, Fernando Frediani wrote:
I don't think this should be allowed to happen. ROAs are to be created
by organizations who receive the allocation from the RIR as ultimatelly
they remain responsible for that IP space. If they have allocated a
block to a customer they should be the
I don't think this should be allowed to happen. ROAs are to be created
by organizations who receive the allocation from the RIR as ultimatelly
they remain responsible for that IP space. If they have allocated a
block to a customer they should be the ones responsible for creating any
ROAs they n
Current hosted RPKI implementations across all RIRs follow a
hierarchical structure, where access to manage ROAs terminates at the
party directly allocated corresponding resources. IPv6 reverse DNS is
another example. If you've received a small IPv6 subnet through
reallocation, you may face sim
It is my understanding that the downstream Org cannot create RPKI ROAs
for Reallocated IP Networks. For example, 206.9.80.0/24 is reallocated
to me (OrgID WIKSTR-1), but I cannot make a ROA for it.
This is obviously suboptimal for adopting RPKI.
Is this something that we could fix with Policy
18 matches
Mail list logo
