Whose ASN Goes on Your Leased IPv4 Prefix?

Saudações a toda a comunidade de Moçambique e aos membros do fórum!

Como especialista em tecnologia, trago hoje uma análise técnica detalhada sobre um tema crucial para administradores de redes, ISPs (Provedores de Internet) e sysadmins no nosso país, baseado no debate do tópico **"Whose ASN Goes on Your Leased IPv4 Prefix?"** (De quem é o ASN que vai no seu prefixo IPv4 alugado?).

Com a escassez global de endereços IPv4, o mercado de aluguer de blocos IP tornou-se uma realidade incontornável, inclusive para nós aqui em Moçambique. No entanto, surge sempre uma dúvida técnica complexa: **quando alugamos um prefixo IPv4, qual Autonomous System Number (ASN) deve ser associado a ele?**

Vamos dissecar os pontos principais deste cenário:

### 1. O Anúncio BGP e a Origem do ASN
Do ponto de vista de roteamento puro (BGP - *Border Gateway Protocol*), o prefixo IP deve ser anunciado pelo ASN da entidade que está realmente a utilizar a infraestrutura (o locatário/cliente).
* **Porquê?** Se o bloco IP vai rodar nos vossos servidores ou na vossa rede em Maputo, Beira ou Nampula, é o vosso ASN que deve originar o anúncio para garantir que o tráfego seja direcionado corretamente para a vossa rede.
* **O Requisito Técnica (LOA):** Para que isto aconteça, o dono do IP (locador) deve passar uma **LOA (Letter of Authorization)** e criar um **ROA (Route Origin Authorization)** no RIR correspondente (como a AFRINIC, no nosso caso em África), autorizando o vosso ASN a anunciar aquele bloco específico.

### 2. O Registo no WHOIS e RIR (Base de Dados)
Este é um ponto sensível. Quem deve constar como responsável pelo bloco nas bases de dados públicas (WHOIS)?
* O ideal é que o locador crie um **sub-alocamento** (sub-assignment) ou faça uma atualização do registo para associar o vosso ASN e os vossos contactos de abuso (Abuse POC) ao prefixo.
* Isto é vital para garantir que questões de **geolocalização** funcionem corretamente (evitando que os vossos utilizadores sejam identificados como estando noutro país) e para que os serviços de CDN (como Cloudflare ou Akamai) entreguem conteúdos de forma otimizada.

### 3. A Dor de Cabeça: Gestão de Abuso e Reputação
Este é o maior debate entre os especialistas. Se o locatário (quem aluga) usar os IPs para enviar spam, ataques DDoS ou outras atividades ilícitas:
* A má reputação vai afetar diretamente o ASN que anuncia o bloco.
* Se os IPs forem "sujos", o ASN do locador também pode sofrer danos colaterais na sua reputação global. Daí a importância de contratos bem amarrados e de uma monitoria rigorosa.

---

### Vamos debater este tema no webmastersmz.com!
Malta, esta é uma realidade que toca diretamente o crescimento das nossas infraestruturas em Moçambique. Como é que vocês têm lidado com o aluguer de IPs por cá? Têm tido dificuldades com a validação de LOAs junto dos vossos trânsitos IP? E a nossa relação com a AFRINIC neste aspeto?

Abri um espaço para nós debatermos isto a fundo. Deixem a vossa experiência, dúvidas e soluções lá no fórum **webmastersmz.com**. A vossa partilha é o que faz a nossa comunidade de TI crescer forte!

---

Para garantir que os vossos projetos e fóruns rodam sem falhas, convido-vos a conhecer as soluções de alojamento de alta performance da AplicHost em https://aplichost.com.

Whose ASN Goes on Your Leased IPv4 Prefix?



Tópico: Whose ASN Goes on Your Leased IPv4 Prefix?
Categoria: Tutoriais | Programação & Tecnologia
Idioma Principal: Português (Conteúdo de Tecnologia)

Descrição do Conteúdo / Informações:
-------------------------------------------------------------------------
You leased a /24. Something has to originate it in BGP. That something has an ASN attached, and if the wrong ASN is attached, your prefix gets dropped by every network running Route Origin Validation.

That is the entire problem. Here is how the four options differ at the object level.



The four origination paths


Path
Origin AS
Who creates what

Your own ASN + BGP
Yours
Owner issues LOA + route: + ROA, all naming your ASN

Upstream/host announces
Provider's
Same three objects, naming their ASN

Cloud BYOIP
Cloud's, or yours on AWS
ROA naming cloud ASN (or yours via BYOASN) + RDAP proof

Third-party AS
Partner's
Same three objects, naming the partner's ASN

Three of the four need no ASN registered to you.



The rule


ROA.asID must equal the origin AS in the announcement. RFC 6811 gives three outcomes:

•
NotFound - no covering ROA. Still widely accepted, decreasingly so.

•
Valid - origin AS and prefix length both match.

•
Invalid - wrong origin AS, or announced prefix longer than maxLength. Dropped by every validating peer.

Invalid is the dangerous one because it fails partially. Peers doing ROV drop you, peers that do not still carry you, and the symptom looks like an application bug.



The failure I see most


Renter plans to get their own ASN later. Asks the IP owner to create the ROA against that future ASN now. Goes live with the host announcing from the host's AS.

ROA:          198.51.100.0/24  origin AS64496  maxLength 24
Announcement: 198.51.100.0/24  AS_PATH ... 64511
^^^^^ mismatch -> Invalid

Sequence it the other way. Decide the origin, then create the ROA.



Also watch maxLength


ROA:          203.0.113.0/22   origin AS64496  maxLength 22
Announcement: 203.0.113.0/24   origin AS64496
^^^ correct AS, too specific -> Invalid

Correct ASN is not sufficient. maxLength has to cover what you actually originate.



Verifying before you announce


RIPEstat works regardless of which RIR administers the block:

curl -s "https://stat.ripe.net/data/rpki-validation/data.json?resource=64496&prefix=198.51.100.0/24" \
| jq '.data.status, .data.validating_roas'

Anything other than "valid" means stop. For a local relying-party cache, use Routinator, rpki-client or FORT.

Note: the RIPE NCC RPKI Validator has been unmaintained since 1 July 2021 and the public instance was migrated to Routinator in September 2021. Plenty of tutorials still point at it.

Then confirm what the world actually sees:

whois -h whois.radb.net -- '-i origin AS64496'   # route objects
# plus RIPE RIS / BGPView / HE looking glass for the live AS_PATH



Cloud specifics


AWS commercial regions. ROA must authorise 16509 and 14618, maxLength 24 for IPv4. GovCloud (US) uses 8987. Authorisation is two-part: the ROA plus a self-signed X.509 certificate published in the RDAP remarks for the prefix.

AWS BYOASN. You are not forced onto Amazon's origin AS. Bring an ASN you hold:

aws ec2 provision-ipam-byoasn --ipam-id ipam-xxxx --asn 64496 --asn-authorization-context ...
aws ec2 associate-ipam-byoasn --asn 64496 --cidr 198.51.100.0/24
aws ec2 advertise-byoip-cidr --cidr 198.51.100.0/24 --asn 64496

The ROA then names your ASN, not Amazon's.

Azure Custom IP Prefix. Origin AS must be 8075 (public) or 8070 (US Gov). Parent IPv4 prefix must be /21 to /24. Two constraints that kill use cases outright: SMTP is not permitted from Azure BYOIP space, and you must decommission the range before modifying or deleting the ROA - otherwise Microsoft keeps advertising a prefix it is no longer authorised to originate.



Do you actually want your own ASN?


RIPE still requires multihoming. ripe-679 §2.0 is unambiguous, and proposal 2025-01 - which would have dropped all justification for a first ASN - was withdrawn on 6 July 2026. The old criteria stand.

You submit a routing policy in RPSL:

aut-num:  AS64496
import:   from AS64500 accept ANY
import:   from AS64501 accept ANY
export:   to AS64500 announce AS64496
export:   to AS64501 announce AS64496

Two upstreams in that object is not decoration. RIPE NCC may contact both to verify.

Single-homed with one /24? An ASN gets you EUR 50 per assignment, registry obligations, and a routing policy identical to your upstream's. Skip it until you are genuinely multihoming.



Pre-flight


• [ ] LOA names the announcing ASN

• [ ] route: object exists with correct origin:

• [ ] ROA correct on both asID and maxLength

• [ ] RPKI status valid

• [ ] Prefix visible from multiple vantage points, observed origin matches the ROA

• [ ] rDNS delegated

• [ ] Reputation checked on the block and the announcing ASN

Longer version with the full path-by-path breakdown, the RIPE policy history, and the LOA/IRR/ROA sequencing: https://ipbnb.com/blog/asn-to-announce-ipv4