{"id":24879,"date":"2026-10-06T11:06:11","date_gmt":"2026-10-06T11:06:11","guid":{"rendered":"https:\/\/atalnetworks.com\/?p=24879"},"modified":"2026-10-06T11:41:14","modified_gmt":"2026-10-06T11:41:14","slug":"rpki-ip-leasing-bgp","status":"publish","type":"post","link":"https:\/\/atalnetworks.com\/ar\/rpki-ip-leasing-bgp\/","title":{"rendered":"RPKI for IP Leasing: ROA, ASN & BGP Security Guide"},"content":{"rendered":"

Leasing an IPv4 or IPv6 prefix gives a customer the right to use that address space under the terms of the lease. It does not automatically give the customer control of the RPKI authority attached to the prefix.<\/span><\/p>\n

That distinction matters once the leased block is announced through BGP.<\/span><\/p>\n

For a leased prefix to pass Route Origin Validation, the BGP announcement needs to match the authorization published through RPKI. The prefix, origin ASN, and permitted prefix length must agree with an applicable Route Origin Authorization, or ROA.<\/span><\/p>\n

In a typical IP leasing deployment, the workflow looks like this:<\/span><\/p>\n

IP resource holder \u2192 leased prefix \u2192 origin ASN decision \u2192 ROA \u2192 IRR\/LOA \u2192 BGP announcement \u2192 Route Origin Validation \u2192 external monitoring<\/b><\/p>\n

If any part of that chain is wrong, a valid commercial lease can still produce an RPKI-invalid route.<\/span><\/p>\n

RPKI for IP Leasing at a Glance<\/b><\/h2>\n

RPKI provides a cryptographically verifiable way for an address holder to state which Autonomous System may originate a route for its address space.<\/span><\/p>\n

A ROA is a digitally signed object that allows an address-space holder to authorize an AS to originate one or more prefixes.<\/span><\/p>\n

For leased address space, several parties may be involved.<\/span><\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n
Component<\/b><\/td>\nMain Role<\/b><\/td>\n<\/tr>\n
IP resource holder<\/span><\/td>\nHolds or controls authority over the address resource<\/span><\/td>\n<\/tr>\n
Lessee<\/span><\/td>\nUses the leased IPv4 or IPv6 block<\/span><\/td>\n<\/tr>\n
Origin ASN<\/span><\/td>\nASN that originates the prefix into BGP<\/span><\/td>\n<\/tr>\n
ROA<\/span><\/td>\nAuthorizes the origin ASN for the prefix<\/span><\/td>\n<\/tr>\n
BGP<\/span><\/td>\nCarries the route announcement<\/span><\/td>\n<\/tr>\n
Route Origin Validation<\/span><\/td>\nCompares the BGP origin with RPKI data<\/span><\/td>\n<\/tr>\n
IRR<\/span><\/td>\nPublishes routing-policy information<\/span><\/td>\n<\/tr>\n
LOA<\/span><\/td>\nDocuments operational permission where required<\/span><\/td>\n<\/tr>\n
RIR<\/span><\/td>\nMaintains resource registration and RPKI services<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The central rule is simple:<\/span><\/p>\n

The ROA needs to authorize the ASN that actually originates the leased prefix in BGP.<\/b><\/p>\n

\"rpki-ip-leasing-responsibility-flow\"<\/h3>\n

What Is RPKI?<\/b><\/h2>\n

Resource Public Key Infrastructure, or RPKI, is a routing-security system built around cryptographically signed resource information.<\/span><\/p>\n

Its purpose is to let network operators answer a specific question:<\/span><\/p>\n

Is this ASN authorized by the address holder to originate this prefix?<\/b><\/p>\n

Network operators can use RPKI data to compare the origin ASN in a BGP route against the authorization published for that address space.<\/span><\/p>\n

RPKI deals with route origin.<\/span><\/p>\n

It does not:<\/span><\/p>\n

    \n
  • encrypt traffic<\/span><\/li>\n
  • verify every AS in the AS_PATH<\/span><\/li>\n
  • replace a firewall<\/span><\/li>\n
  • protect an application from DDoS attacks<\/span><\/li>\n
  • determine IP reputation<\/span><\/li>\n
  • replace normal BGP policy<\/span><\/li>\n<\/ul>\n

    Current RPKI deployment primarily checks the relationship between a prefix and its origin ASN.<\/span><\/p>\n

    What Is a Route Origin Authorization?<\/b><\/h2>\n

    A Route Origin Authorization is a signed RPKI object that states which ASN may originate specified IP prefixes.<\/span><\/p>\n

    A basic ROA contains three routing concepts operators need to understand.<\/span><\/p>\n

    Prefix<\/b><\/p>\n

    The IPv4 or IPv6 network being authorized.<\/span><\/p>\n

    Origin ASN<\/b><\/p>\n

    The Autonomous System permitted to originate that route.<\/span><\/p>\n

    Maximum permitted prefix length<\/b><\/p>\n

    An optional value that can permit more-specific routes.<\/span><\/p>\n

    A simple example might look conceptually like:<\/span><\/p>\n

    Prefix: \u00a0 \u00a0 \u00a0 203.0.113.0\/24<\/span><\/p>\n

    Origin ASN: \u00a0 AS64500<\/span><\/p>\n

    If AS64500 announces exactly <\/span>203.0.113.0\/24<\/span>, the announcement can match this authorization.<\/span><\/p>\n

    If several ASNs need permission to originate the same address space, separate ROAs can be used for those ASNs.<\/span><\/p>\n

    How RPKI Works With Leased IP Space<\/b><\/h2>\n

    IP leasing separates operational use from resource ownership.<\/span><\/p>\n

    A business may lease:<\/span><\/p>\n

    203.0.113.0\/24<\/span><\/p>\n

    and use that block for:<\/span><\/p>\n

      \n
    • \u062e\u0648\u0627\u062f\u0645 \u0645\u062e\u0635\u0635\u0629<\/span><\/li>\n
    • colocation infrastructure<\/span><\/li>\n
    • VPS platforms<\/span><\/li>\n
    • proxy infrastructure<\/span><\/li>\n
    • VPN infrastructure<\/span><\/li>\n
    • multi-site hosting<\/span><\/li>\n
    • customer networks<\/span><\/li>\n<\/ul>\n

      The lessee may operate the servers and BGP session, but the original resource holder may still control the RPKI certificate covering the prefix.<\/span><\/p>\n

      That means the lessee may not be able to create its own ROA directly.<\/span><\/p>\n

      A downstream organization using address space received from another provider may need the upstream resource provider to create the ROA on its behalf.<\/span><\/p>\n

      This distinction is central to leased-address deployments.<\/span><\/p>\n

      Commercial use of an IP block and cryptographic authority over that block are separate responsibilities.<\/b><\/p>\n

      Who Creates the ROA for a Leased Prefix?<\/b><\/h2>\n

      The party with RPKI authority over the resource normally creates the ROA, unless an applicable delegated RPKI arrangement gives another organization that authority.<\/span><\/p>\n

      Three operating models are common.<\/span><\/p>\n

      Resource Holder Creates the ROA<\/b><\/h3>\n

      This is a straightforward lease model.<\/span><\/p>\n

      The customer provides:<\/span><\/p>\n

        \n
      • leased prefix<\/span><\/li>\n
      • intended origin ASN<\/span><\/li>\n
      • planned announcement length<\/span><\/li>\n
      • required routing date<\/span><\/li>\n<\/ul>\n

        The resource holder creates the matching ROA.<\/span><\/p>\n

        RPKI Authority Is Delegated<\/b><\/h3>\n

        Some organizations operate delegated RPKI systems.<\/span><\/p>\n

        The technical model depends on the RIR, certificate hierarchy, resource status, and operating arrangement.<\/span><\/p>\n

        This setup gives the delegated party more control, but it also adds certificate and repository responsibilities.<\/span><\/p>\n

        Provider Manages the Routing Arrangement<\/b><\/h3>\n

        A customer may lease IP addresses without running a public ASN.<\/span><\/p>\n

        The hosting or network provider can originate the leased prefix from its own ASN where the commercial and routing arrangement permits it.<\/span><\/p>\n

        The ROA should then authorize the provider ASN.<\/span><\/p>\n

        Customer ASN vs Provider ASN<\/b><\/h2>\n

        The correct ASN in a ROA is determined by the actual BGP origin.<\/span><\/p>\n\n\n\n\n\n\n\n
        Routing Model<\/b><\/td>\nBGP Origin<\/b><\/td>\nROA Should Authorize<\/b><\/td>\n<\/tr>\n
        Customer originates route<\/span><\/td>\nCustomer ASN<\/span><\/td>\nCustomer ASN<\/span><\/td>\n<\/tr>\n
        Provider originates route<\/span><\/td>\nProvider ASN<\/span><\/td>\nProvider ASN<\/span><\/td>\n<\/tr>\n
        BYOIP platform originates route<\/span><\/td>\nPlatform-designated ASN<\/span><\/td>\nRequired platform ASN<\/span><\/td>\n<\/tr>\n
        Planned multi-origin design<\/span><\/td>\nSeveral ASNs<\/span><\/td>\nAppropriate authorization for each ASN<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

        Customer ASN Model<\/b><\/h3>\n

        A customer ASN makes sense when the customer controls its own routing.<\/span><\/p>\n

        Common use cases include:<\/span><\/p>\n

          \n
        • multihoming<\/span><\/li>\n
        • colocation<\/span><\/li>\n
        • independent routing<\/span><\/li>\n
        • multi-provider BGP<\/span><\/li>\n
        • several deployment locations<\/span><\/li>\n<\/ul>\n

          The customer should coordinate the route announcement with the address provider so the ROA authorizes the customer ASN.<\/span><\/p>\n

          Provider ASN Model<\/b><\/h3>\n

          A customer does not need a public ASN for every leased-IP deployment.<\/span><\/p>\n

          If the hosting provider originates the block, the ROA should authorize the provider’s ASN.<\/span><\/p>\n

          This arrangement is common when the customer uses the leased prefix but does not operate its own BGP routing policy.<\/span><\/p>\n

          \"customer-asn-vs-provider-asn-rpki\"<\/h3>\n

          ROA Prefix Length and maxLength<\/b><\/h2>\n

          maxLength<\/span> is one of the most common sources of RPKI configuration errors.<\/span><\/p>\n

          Suppose a ROA contains:<\/span><\/p>\n

          Prefix: \u00a0 \u00a0 \u00a0 203.0.113.0\/24<\/span><\/p>\n

          Origin: \u00a0 \u00a0 \u00a0 AS64500<\/span><\/p>\n

          and the network announces:<\/span><\/p>\n

          203.0.113.0\/24<\/span><\/p>\n

          That is a straightforward match.<\/span><\/p>\n

          Now assume the network later announces:<\/span><\/p>\n

          203.0.113.0\/25<\/span><\/p>\n

          The ASN may still be correct, but the <\/span>\/25<\/span> can become Invalid if the ROA does not permit a prefix that specific.<\/span><\/p>\n

          Avoid Unnecessary maxLength Values<\/b><\/h3>\n

          The safer approach is to keep ROA authorization aligned with the prefixes that are actually expected in BGP.<\/span><\/p>\n

          If the network will only announce:<\/span><\/p>\n

          203.0.113.0\/24<\/span><\/p>\n

          there may be no operational reason to authorize <\/span>\/25<\/span>, <\/span>\/26<\/span>, <\/span>\/27<\/span>, or other more-specific routes.<\/span><\/p>\n

          This reduces the number of routes that can be originated while still matching the authorization.<\/span><\/p>\n

          For stable routing, ROA design should match the real BGP announcement plan.<\/span><\/p>\n

          Simple Example<\/b><\/h3>\n

          ROA:<\/span><\/p>\n

          203.0.113.0\/24<\/span><\/p>\n

          Origin AS64500<\/span><\/p>\n

          BGP:<\/span><\/p>\n

          203.0.113.0\/24<\/span><\/p>\n

          Origin AS64500<\/span><\/p>\n

          Result:<\/span><\/p>\n

          Valid<\/b><\/p>\n

          If the same ROA does not allow <\/span>\/25<\/span> and BGP announces:<\/span><\/p>\n

          203.0.113.0\/25<\/span><\/p>\n

          Origin AS64500<\/span><\/p>\n

          the more-specific route can become:<\/span><\/p>\n

          Invalid due to prefix length<\/b><\/p>\n

          \"rpki-roa-maxlength-validation\"<\/h3>\n

          RPKI Valid, Invalid, and NotFound<\/b><\/h2>\n

          A BGP announcement can receive different validation states after comparison with RPKI data.<\/span><\/p>\n

          Terminology differs slightly across routing software and tools. You may see <\/span>Valid<\/b>, <\/span>Invalid<\/b>, and either <\/span>NotFound<\/b> \u0623\u0648 <\/span>Unknown<\/b>.<\/span><\/p>\n\n\n\n\n\n\n
          State<\/b><\/td>\nMeaning<\/b><\/td>\n<\/tr>\n
          Valid<\/span><\/td>\nAn applicable ROA authorizes the origin ASN and prefix length<\/span><\/td>\n<\/tr>\n
          Invalid<\/span><\/td>\nA covering ROA exists, but the ASN or prefix length conflicts with it<\/span><\/td>\n<\/tr>\n
          NotFound \/ Unknown<\/span><\/td>\nNo applicable ROA covers the route<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

          Valid<\/b><\/h3>\n

          Example:<\/span><\/p>\n

          ROA:<\/span><\/p>\n

          203.0.113.0\/24<\/span><\/p>\n

          AS64500<\/span><\/p>\n

           <\/p>\n

          BGP:<\/span><\/p>\n

          203.0.113.0\/24<\/span><\/p>\n

          Origin AS64500<\/span><\/p>\n

          The prefix and origin ASN agree with the authorization.<\/span><\/p>\n

          Invalid Because of Origin ASN<\/b><\/h3>\n

          Example:<\/span><\/p>\n

          ROA:<\/span><\/p>\n

          203.0.113.0\/24<\/span><\/p>\n

          AS64500<\/span><\/p>\n

           <\/p>\n

          BGP:<\/span><\/p>\n

          203.0.113.0\/24<\/span><\/p>\n

          Origin AS64501<\/span><\/p>\n

          The address range is covered, but the origin AS does not match.<\/span><\/p>\n

          Invalid Because of Prefix Length<\/b><\/h3>\n

          The ASN may match, but a route can still fail validation if it is more specific than the applicable ROA permits.<\/span><\/p>\n

          Example:<\/span><\/p>\n

          ROA:<\/span><\/p>\n

          203.0.113.0\/24<\/span><\/p>\n

          Origin AS64500<\/span><\/p>\n

          No authorization for \/25<\/span><\/p>\n

           <\/p>\n

          BGP:<\/span><\/p>\n

          203.0.113.0\/25<\/span><\/p>\n

          Origin AS64500<\/span><\/p>\n

          Result:<\/span><\/p>\n

          Invalid because of prefix length<\/b><\/p>\n

          NotFound Is Not the Same as Invalid<\/b><\/h3>\n

          NotFound or Unknown means no applicable ROA covers the route.<\/span><\/p>\n

          That is different from an announcement actively conflicting with a published authorization.<\/span><\/p>\n

          RPKI produces route-origin validation information. Network operators then decide how their routing policies handle the result.<\/span><\/p>\n

          LOA vs IRR Route Object vs ROA<\/b><\/h2>\n

          LOA, IRR, and ROA are often discussed together during IP leasing, but they solve different problems.<\/span><\/p>\n\n\n\n\n\n\n
          Item<\/b><\/td>\nMain Purpose<\/b><\/td>\nCryptographic RPKI Authorization<\/b><\/td>\n<\/tr>\n
          LOA<\/span><\/td>\nDocuments operational permission<\/span><\/td>\n\u0644\u0627<\/span><\/td>\n<\/tr>\n
          IRR route object<\/span><\/td>\nPublishes routing-policy information<\/span><\/td>\n\u0644\u0627<\/span><\/td>\n<\/tr>\n
          ROA<\/span><\/td>\nAuthorizes the BGP origin through RPKI<\/span><\/td>\n\u0646\u0639\u0645<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

          LOA<\/b><\/h3>\n

          A Letter of Authorization documents permission between organizations.<\/span><\/p>\n

          A hosting company or transit provider may request one before accepting an announcement.<\/span><\/p>\n

          An LOA does not make an RPKI-invalid route Valid.<\/span><\/p>\n

          IRR Route Object<\/b><\/h3>\n

          Internet Routing Registry records publish routing-policy data.<\/span><\/p>\n

          For IPv4 this commonly uses a <\/span>route<\/span> object.<\/span><\/p>\n

          For IPv6 it commonly uses a <\/span>route6<\/span> object.<\/span><\/p>\n

          Many network operators still use IRR data to build route filters.<\/span><\/p>\n

          ROA<\/b><\/h3>\n

          A ROA provides cryptographically verifiable route-origin authorization through RPKI.<\/span><\/p>\n

          A production IP leasing arrangement may use all three:<\/span><\/p>\n

          LOA for operational permission<\/b><\/p>\n

          IRR for routing-policy registration<\/b><\/p>\n

          ROA for cryptographic origin authorization<\/b><\/p>\n

          They are not interchangeable.<\/span><\/p>\n

          Practical Authorization and BGP Workflow<\/b><\/h2>\n

          A leased prefix should move through a controlled deployment sequence.<\/span><\/p>\n

            \n
          1. Confirm the exact IPv4 or IPv6 prefix.<\/span><\/li>\n
          2. Confirm the resource holder.<\/span><\/li>\n
          3. Identify who controls RPKI.<\/span><\/li>\n
          4. Decide which ASN will originate the route.<\/span><\/li>\n
          5. Confirm the exact BGP announcement lengths.<\/span><\/li>\n
          6. Prepare an LOA where required.<\/span><\/li>\n
          7. Create or update the IRR record.<\/span><\/li>\n
          8. Create or update the ROA.<\/span><\/li>\n
          9. Check that the authorization is visible.<\/span><\/li>\n
          10. Configure BGP.<\/span><\/li>\n
          11. Verify route visibility externally.<\/span><\/li>\n
          12. Check the RPKI validation state.<\/span><\/li>\n
          13. Monitor the prefix after launch.<\/span><\/li>\n<\/ol>\n

            The order matters.<\/span><\/p>\n

            Starting the new BGP announcement before the routing authorization is ready can produce an Invalid route or inconsistent reachability.<\/span><\/p>\n

            \"leased-ip-bgp-rpki-lifecycle\"<\/h3>\n

            IPv4 and IPv6 RPKI Considerations<\/b><\/h2>\n

            RPKI works with both IPv4 and IPv6.<\/span><\/p>\n

            IPv4 Leasing<\/b><\/h3>\n

            IPv4 leasing often involves:<\/span><\/p>\n

              \n
            • \/24<\/span> and larger public blocks<\/span><\/li>\n
            • customer ASN<\/span><\/li>\n
            • provider ASN<\/span><\/li>\n
            • route filters<\/span><\/li>\n
            • BGP origination<\/span><\/li>\n
            • reverse DNS<\/span><\/li>\n
            • IP reputation<\/span><\/li>\n
            • geolocation<\/span><\/li>\n<\/ul>\n

              Because IPv4 address space is scarce, address ownership, commercial use, and routing may involve several organizations.<\/span><\/p>\n

              IPv6 Leasing<\/b><\/h3>\n

              IPv6 uses a different addressing scale and subnet structure.<\/span><\/p>\n

              A leased IPv6 deployment may involve:<\/span><\/p>\n

                \n
              • \/48<\/span> or larger allocations where applicable<\/span><\/li>\n
              • customer ASN or provider ASN<\/span><\/li>\n
              • route6<\/span> IRR objects<\/span><\/li>\n
              • IPv6 BGP<\/span><\/li>\n
              • IPv6 ROAs<\/span><\/li>\n
              • routed subnets<\/span><\/li>\n<\/ul>\n

                The same RPKI rule still applies:<\/span><\/p>\n

                The live BGP origin and prefix length should match the published authorization.<\/b><\/p>\n

                Prevent Invalid Routes During an ASN Change<\/b><\/h2>\n

                Changing the origin ASN without changing RPKI authorization can cause a routing incident.<\/span><\/p>\n

                Suppose a prefix currently originates from:<\/span><\/p>\n

                AS64500<\/span><\/p>\n

                and will move to:<\/span><\/p>\n

                AS64510<\/span><\/p>\n

                Changing BGP first while leaving the old authorization untouched can cause the new route to become Invalid.<\/span><\/p>\n

                A safer sequence is:<\/span><\/p>\n

                Prepare authorization \u2192 verify publication \u2192 introduce new route \u2192 test visibility \u2192 withdraw old route \u2192 remove authorization no longer required<\/b><\/p>\n

                This sequencing is useful during:<\/span><\/p>\n

                  \n
                • hosting migrations<\/span><\/li>\n
                • transit changes<\/span><\/li>\n
                • customer ASN deployment<\/span><\/li>\n
                • colocation moves<\/span><\/li>\n
                • BYOIP changes<\/span><\/li>\n<\/ul>\n

                  Treat the ROA as part of the routing change, not as paperwork completed later.<\/span><\/p>\n

                  Plan for More-Specific Announcements<\/b><\/h2>\n

                  Networks may announce more-specific prefixes for:<\/span><\/p>\n

                    \n
                  • traffic engineering<\/span><\/li>\n
                  • multi-site routing<\/span><\/li>\n
                  • DDoS mitigation<\/span><\/li>\n
                  • migration<\/span><\/li>\n
                  • regional routing<\/span><\/li>\n<\/ul>\n

                    Those announcements must fit the RPKI policy.<\/span><\/p>\n

                    Do not use a broad <\/span>maxLength<\/span> simply because more-specific routes might be required one day.<\/span><\/p>\n

                    If an aggregate will be split, verify the intended more-specific routes before they are advertised.<\/span><\/p>\n

                    For example, if normal operation uses:<\/span><\/p>\n

                    203.0.113.0\/24<\/span><\/p>\n

                    but a planned mitigation service may announce:<\/span><\/p>\n

                    203.0.113.0\/25<\/span><\/p>\n

                    The authorization model needs to account for that routing plan before the mitigation event occurs.<\/span><\/p>\n

                    RPKI During Provider Migration<\/b><\/h2>\n

                    A provider migration can change several routing records at once.<\/span><\/p>\n

                    Current design:<\/span><\/p>\n

                    Old Provider<\/span><\/p>\n

                    \u00a0\u00a0\u00a0\u00a0\u00a0\u2193<\/span><\/p>\n

                    Old Origin ASN<\/span><\/p>\n

                    \u00a0\u00a0\u00a0\u00a0\u00a0\u2193<\/span><\/p>\n

                    Current ROA<\/span><\/p>\n

                    New design:<\/span><\/p>\n

                    New Provider<\/span><\/p>\n

                    \u00a0\u00a0\u00a0\u00a0\u00a0\u2193<\/span><\/p>\n

                    New Origin ASN<\/span><\/p>\n

                    \u00a0\u00a0\u00a0\u00a0\u00a0\u2193<\/span><\/p>\n

                    Updated ROA<\/span><\/p>\n

                    Do not manage BGP, IRR, and RPKI as unrelated tasks.<\/span><\/p>\n

                    Before the cutover, document:<\/span><\/p>\n

                      \n
                    • old origin ASN<\/span><\/li>\n
                    • new origin ASN<\/span><\/li>\n
                    • active ROA<\/span><\/li>\n
                    • required new authorization<\/span><\/li>\n
                    • IRR changes<\/span><\/li>\n
                    • route activation time<\/span><\/li>\n
                    • route withdrawal time<\/span><\/li>\n
                    • external visibility tests<\/span><\/li>\n
                    • rollback conditions<\/span><\/li>\n<\/ul>\n

                      If two ASNs need to originate the prefix during a planned transition, the RPKI configuration needs to permit that routing model.<\/span><\/p>\n

                      Can the Same Prefix Be Authorized for Multiple ASNs?<\/b><\/h2>\n

                      Yes, where the routing architecture requires it.<\/span><\/p>\n

                      Examples include:<\/span><\/p>\n

                        \n
                      • provider migration<\/span><\/li>\n
                      • multi-origin routing<\/span><\/li>\n
                      • cloud migration<\/span><\/li>\n
                      • DDoS mitigation arrangements<\/span><\/li>\n<\/ul>\n

                        A separate ROA can authorize each ASN that needs to originate the same address prefix.<\/span><\/p>\n

                        Old authorizations should not remain active without a routing reason.<\/span><\/p>\n

                        Every active authorization should map to an actual operating requirement.<\/span><\/p>\n

                        RPKI Risks Specific to IP Leasing<\/b><\/h2>\n

                        Leased prefixes create a responsibility boundary that directly held resources may not have.<\/span><\/p>\n

                        Watch for these problems:<\/span><\/p>\n

                          \n
                        1. The lessee assumes it controls the ROA when the resource holder does.<\/span><\/li>\n
                        2. The ROA contains the wrong customer or provider ASN.<\/span><\/li>\n
                        3. The customer changes ASN without requesting an RPKI update.<\/span><\/li>\n
                        4. maxLength<\/span> is too restrictive for planned more-specific routes.<\/span><\/li>\n
                        5. maxLength<\/span> permits more-specifics that are not required.<\/span><\/li>\n
                        6. IRR and RPKI data list different origin ASNs.<\/span><\/li>\n
                        7. Authorization remains after the lease has ended.<\/span><\/li>\n
                        8. BGP starts before a new ROA is visible.<\/span><\/li>\n
                        9. A provider migration begins without confirming route validation.<\/span><\/li>\n
                        10. Neither party has clearly accepted responsibility for routing updates.<\/span><\/li>\n<\/ol>\n

                          The right operational question is not only:<\/span><\/p>\n

                          Does this prefix have a ROA?<\/b><\/p>\n

                          It is:<\/span><\/p>\n

                          Does the current ROA authorize the exact route we plan to announce?<\/b><\/p>\n

                          Monitor Route Visibility and RPKI Validation<\/b><\/h2>\n

                          A BGP session showing Established does not prove that a leased prefix has the expected external reachability.<\/span><\/p>\n

                          Monitor the route itself.<\/span><\/p>\n

                          Track:<\/span><\/p>\n

                            \n
                          • whether the prefix is visible<\/span><\/li>\n
                          • observed origin ASN<\/span><\/li>\n
                          • RPKI validation state<\/span><\/li>\n
                          • actual BGP prefix length<\/span><\/li>\n
                          • unexpected more-specific routes<\/span><\/li>\n
                          • multiple origins<\/span><\/li>\n
                          • route visibility through several networks<\/span><\/li>\n
                          • current ROA information<\/span><\/li>\n<\/ul>\n

                            After any ROA change, check active announcements to make sure the expected prefixes remain correctly authorized.<\/span><\/p>\n

                            Use Several External Views<\/b><\/h3>\n

                            Do not rely only on the local router.<\/span><\/p>\n

                            Use independent route collectors, looking glasses, RPKI tools, or external probes where appropriate.<\/span><\/p>\n

                            A validation tool may show different error classes such as:<\/span><\/p>\n

                              \n
                            • Valid<\/span><\/li>\n
                            • Invalid ASN<\/span><\/li>\n
                            • Invalid prefix length<\/span><\/li>\n
                            • Unknown or NotFound<\/span><\/li>\n<\/ul>\n

                              That distinction helps identify whether the problem comes from the origin ASN or the prefix length.<\/span><\/p>\n

                              RPKI Deployment Workflow for Leased IP Space<\/b><\/h2>\n

                              A repeatable deployment process reduces coordination errors.<\/span><\/p>\n

                              Phase 1: Verify the Resource<\/b><\/h3>\n

                              Record:<\/span><\/p>\n

                                \n
                              • prefix<\/span><\/li>\n
                              • IPv4 or IPv6<\/span><\/li>\n
                              • resource holder<\/span><\/li>\n
                              • RIR<\/span><\/li>\n
                              • lease start<\/span><\/li>\n
                              • lease end<\/span><\/li>\n
                              • party controlling RPKI<\/span><\/li>\n<\/ul>\n

                                Phase 2: Define Routing<\/b><\/h3>\n

                                Record:<\/span><\/p>\n

                                  \n
                                • origin ASN<\/span><\/li>\n
                                • upstream ASN<\/span><\/li>\n
                                • deployment location<\/span><\/li>\n
                                • BGP peer<\/span><\/li>\n
                                • aggregate routes<\/span><\/li>\n
                                • more-specific routes<\/span><\/li>\n<\/ul>\n

                                  Phase 3: Prepare Authorization<\/b><\/h3>\n

                                  Prepare:<\/span><\/p>\n

                                    \n
                                  • ROA<\/span><\/li>\n
                                  • IRR route or route6 object<\/span><\/li>\n
                                  • LOA where required<\/span><\/li>\n<\/ul>\n

                                    Phase 4: Run Pre-Announcement Checks<\/b><\/h3>\n

                                    Confirm:<\/span><\/p>\n

                                      \n
                                    • correct prefix<\/span><\/li>\n
                                    • correct ASN<\/span><\/li>\n
                                    • correct prefix length<\/span><\/li>\n
                                    • suitable <\/span>maxLength<\/span><\/li>\n
                                    • ROA publication<\/span><\/li>\n
                                    • IRR alignment<\/span><\/li>\n<\/ul>\n

                                      Phase 5: Announce the Prefix<\/b><\/h3>\n

                                      Start the planned BGP route.<\/span><\/p>\n

                                      Phase 6: Verify Externally<\/b><\/h3>\n

                                      Check:<\/span><\/p>\n

                                        \n
                                      • route visibility<\/span><\/li>\n
                                      • origin ASN<\/span><\/li>\n
                                      • RPKI state<\/span><\/li>\n
                                      • reachability<\/span><\/li>\n<\/ul>\n

                                        Phase 7: Maintain Monitoring<\/b><\/h3>\n

                                        The route should remain checked throughout the lease rather than only during deployment.<\/span><\/p>\n

                                        Build a Rollback Plan<\/b><\/h2>\n

                                        RPKI and BGP changes should have rollback steps.<\/span><\/p>\n

                                        Document:<\/span><\/p>\n

                                          \n
                                        • previous ASN<\/span><\/li>\n
                                        • new ASN<\/span><\/li>\n
                                        • existing ROA<\/span><\/li>\n
                                        • replacement ROA<\/span><\/li>\n
                                        • BGP withdrawal process<\/span><\/li>\n
                                        • IRR rollback<\/span><\/li>\n
                                        • external route checks<\/span><\/li>\n
                                        • contact at the address provider<\/span><\/li>\n
                                        • conditions that trigger rollback<\/span><\/li>\n<\/ul>\n

                                          Do not remove a working authorization before the replacement routing state has been checked.<\/span><\/p>\n

                                          During a provider change, temporary overlap may be required depending on the architecture. Plan for overlap before the migration window starts.<\/span><\/p>\n

                                          Clean Up RPKI When an IP Lease Ends<\/b><\/h2>\n

                                          Lease termination is part of route security.<\/span><\/p>\n

                                          A sound termination workflow should:<\/span><\/p>\n

                                            \n
                                          1. Stop production use of the leased addresses.<\/span><\/li>\n
                                          2. Withdraw the BGP announcement.<\/span><\/li>\n
                                          3. Confirm externally that the route has disappeared.<\/span><\/li>\n
                                          4. Remove customer-specific IRR records where appropriate.<\/span><\/li>\n
                                          5. Remove or replace ROA authorization that is no longer needed.<\/span><\/li>\n
                                          6. Update reverse DNS and related operational records.<\/span><\/li>\n
                                          7. Record the end of the customer’s routing authorization.<\/span><\/li>\n<\/ol>\n

                                            Leaving a previous origin ASN authorized after the commercial relationship ends creates unnecessary routing permission.<\/span><\/p>\n

                                            The same process applies when a customer stops using only part of a larger leased allocation.<\/span><\/p>\n

                                            RPKI for Leased IP Space Checklist<\/b><\/h2>\n

                                            Before putting a leased IPv4 or IPv6 prefix into production, verify:<\/span><\/p>\n

                                              \n
                                            • exact prefix<\/span><\/li>\n
                                            • resource holder<\/span><\/li>\n
                                            • party controlling RPKI<\/span><\/li>\n
                                            • customer or provider origin ASN<\/span><\/li>\n
                                            • BGP announcement length<\/span><\/li>\n
                                            • ROA<\/span><\/li>\n
                                            • maxLength<\/span><\/li>\n
                                            • LOA requirements<\/span><\/li>\n
                                            • IRR object<\/span><\/li>\n
                                            • BGP configuration<\/span><\/li>\n
                                            • validation state<\/span><\/li>\n
                                            • route visibility<\/span><\/li>\n
                                            • external reachability<\/span><\/li>\n
                                            • monitoring<\/span><\/li>\n
                                            • migration sequence<\/span><\/li>\n
                                            • rollback plan<\/span><\/li>\n
                                            • lease-end cleanup process<\/span><\/li>\n<\/ul>\n

                                              A clear responsibility model helps both the lessor and lessee because many routing failures start with unclear ownership of a routing task.<\/span><\/p>\n

                                              Information Atal Networks Needs Before a BGP Announcement<\/b><\/h2>\n

                                              Before announcing leased address space, we need the routing design to be clear.<\/span><\/p>\n

                                              Prefix Information<\/b><\/h3>\n

                                              Provide:<\/span><\/p>\n

                                                \n
                                              • IPv4 or IPv6 prefix<\/span><\/li>\n
                                              • prefix size<\/span><\/li>\n
                                              • lease arrangement<\/span><\/li>\n
                                              • required announcement length<\/span><\/li>\n<\/ul>\n

                                                ASN Information<\/b><\/h3>\n

                                                Provide:<\/span><\/p>\n

                                                  \n
                                                • customer ASN, if used<\/span><\/li>\n
                                                • intended origin ASN<\/span><\/li>\n
                                                • provider ASN arrangement, if applicable<\/span><\/li>\n<\/ul>\n

                                                  Routing Information<\/b><\/h3>\n

                                                  We also need:<\/span><\/p>\n

                                                    \n
                                                  • deployment city or data center<\/span><\/li>\n
                                                  • BGP requirements<\/span><\/li>\n
                                                  • upstream arrangement<\/span><\/li>\n
                                                  • multihoming requirements<\/span><\/li>\n
                                                  • planned more-specific routes<\/span><\/li>\n
                                                  • BYOIP requirements<\/span><\/li>\n<\/ul>\n

                                                    Authorization Information<\/b><\/h3>\n

                                                    Include:<\/span><\/p>\n

                                                      \n
                                                    • current ROA state<\/span><\/li>\n
                                                    • required origin ASN<\/span><\/li>\n
                                                    • intended prefix lengths<\/span><\/li>\n
                                                    • IRR route or route6 object<\/span><\/li>\n
                                                    • LOA where required<\/span><\/li>\n<\/ul>\n

                                                      Change Information<\/b><\/h3>\n

                                                      For migrations, provide:<\/span><\/p>\n

                                                        \n
                                                      • planned cutover time<\/span><\/li>\n
                                                      • current provider<\/span><\/li>\n
                                                      • new routing arrangement<\/span><\/li>\n
                                                      • rollback requirement<\/span><\/li>\n
                                                      • technical contact<\/span><\/li>\n<\/ul>\n

                                                        Getting these details before the first announcement reduces the chance of BGP and RPKI configuration disagreeing.<\/span><\/p>\n

                                                        RPKI and IP Leasing With Atal Networks<\/b><\/h2>\n

                                                        Atal Networks provides IPv4, IPv6, and ASN leasing alongside dedicated hosting, private networking, BYOIP, and multihomed infrastructure options.<\/span><\/p>\n

                                                        For a leased prefix, we recommend defining the routing relationship before production use:<\/span><\/p>\n

                                                        prefix \u2192 origin ASN \u2192 ROA \u2192 IRR\/LOA \u2192 BGP \u2192 external validation<\/b><\/p>\n

                                                        This gives both parties a clear view of who manages each part of the deployment and makes later provider, ASN, or location changes easier to coordinate.<\/span><\/p>\n

                                                        Discuss your prefix, ASN, routing arrangement, deployment locations, and RPKI requirements with Atal Networks.<\/b><\/p>\n

                                                        \u0627\u0644\u0623\u0633\u0626\u0644\u0629 \u0627\u0644\u0634\u0627\u0626\u0639\u0629<\/b><\/h1>\n

                                                        What is RPKI for IP leasing?<\/b><\/h3>\n

                                                        RPKI for IP leasing is the use of cryptographically verifiable route-origin authorization for leased IPv4 or IPv6 address space. The applicable ROA should authorize the ASN that will originate the leased prefix through BGP.<\/span><\/p>\n

                                                        Who creates the ROA for leased IP addresses?<\/b><\/h3>\n

                                                        The organization with RPKI authority over the address resource normally creates the ROA unless that authority has been delegated through an applicable RPKI setup. Leasing a prefix does not automatically give the lessee RPKI authority.<\/span><\/p>\n

                                                        Can a leased IP block use my own ASN?<\/b><\/h3>\n

                                                        Yes, if the routing arrangement supports it. The resource holder should authorize the customer’s ASN for the intended prefix before the customer originates that route.<\/span><\/p>\n

                                                        Can the provider ASN originate a leased prefix?<\/b><\/h3>\n

                                                        Yes. If the provider originates the prefix, the ROA should authorize the provider ASN. This arrangement is common when the customer uses leased address space but does not operate its own public BGP ASN.<\/span><\/p>\n

                                                        What does ROA maxLength mean?<\/b><\/h3>\n

                                                        maxLength<\/span> sets the most-specific prefix length that the authorized ASN may originate under that ROA. It should match the real routing plan rather than permit more-specific routes that the network does not expect to advertise.<\/span><\/p>\n

                                                        Why does my leased prefix show RPKI Invalid?<\/b><\/h3>\n

                                                        Common causes include the wrong origin ASN or a BGP announcement that is more specific than the ROA permits. Compare the live BGP prefix and origin ASN with the active authorization.<\/span><\/p>\n

                                                        Is RPKI NotFound the same as Invalid?<\/b><\/h3>\n

                                                        No. NotFound, sometimes displayed as Unknown, generally means no applicable ROA covers the route. Invalid means a covering authorization exists but the announcement conflicts with it, such as an incorrect ASN or disallowed prefix length.<\/span><\/p>\n

                                                        What is the difference between LOA, IRR, and ROA?<\/b><\/h3>\n

                                                        An LOA documents permission between organizations. An IRR object publishes routing-policy data. A ROA provides cryptographically verifiable route-origin authorization through RPKI. A production IP leasing arrangement may use all three.<\/span><\/p>\n

                                                        Can the same prefix be authorized for multiple ASNs?<\/b><\/h3>\n

                                                        Yes. Separate ROAs can authorize several ASNs for the same prefixes where the routing design requires it. This can support provider migration, controlled multi-origin routing, cloud moves, or DDoS mitigation arrangements.<\/span><\/p>\n

                                                        Does RPKI work for IPv6?<\/b><\/h3>\n

                                                        Yes. ROAs support both IPv4 and IPv6 prefixes. The same origin-authorization principle applies, although IPv4 and IPv6 use different prefix sizes and network structures.<\/span><\/p>\n

                                                        Should the ROA be removed when an IP lease ends?<\/b><\/h3>\n

                                                        Authorization that is no longer required should be cleaned up as part of lease termination. Withdraw the BGP route first, confirm the routing change, then remove or update authorization according to the agreed operating process.<\/span><\/p>\n

                                                        Does RPKI secure the complete BGP AS path?<\/b><\/h3>\n

                                                        No. Widely deployed RPKI origin validation focuses on route origin. It checks whether the originating ASN is authorized for the prefix rather than verifying every AS in the full BGP path.<\/span><\/p>","protected":false},"excerpt":{"rendered":"

                                                        Leasing an IPv4 or IPv6 prefix gives a customer the right to use that address space under the terms of […]<\/p>\n","protected":false},"author":2,"featured_media":24882,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"default","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"set","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[1],"tags":[],"class_list":["post-24879","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-enterprise-grade-server"],"acf":[],"_links":{"self":[{"href":"https:\/\/atalnetworks.com\/ar\/wp-json\/wp\/v2\/posts\/24879","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/atalnetworks.com\/ar\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/atalnetworks.com\/ar\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/atalnetworks.com\/ar\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/atalnetworks.com\/ar\/wp-json\/wp\/v2\/comments?post=24879"}],"version-history":[{"count":3,"href":"https:\/\/atalnetworks.com\/ar\/wp-json\/wp\/v2\/posts\/24879\/revisions"}],"predecessor-version":[{"id":24887,"href":"https:\/\/atalnetworks.com\/ar\/wp-json\/wp\/v2\/posts\/24879\/revisions\/24887"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/atalnetworks.com\/ar\/wp-json\/wp\/v2\/media\/24882"}],"wp:attachment":[{"href":"https:\/\/atalnetworks.com\/ar\/wp-json\/wp\/v2\/media?parent=24879"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/atalnetworks.com\/ar\/wp-json\/wp\/v2\/categories?post=24879"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/atalnetworks.com\/ar\/wp-json\/wp\/v2\/tags?post=24879"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}