Bulut, Yapay Zeka ve Barındırma Sağlayıcıları için IPv4 Stratejisi

Bulut platformları, yapay zekâ altyapısı operatörleri ve hosting sağlayıcıları zorlu bir ağ gerçeğiyle karşı karşıyadır: genel ağ bağlantısına olan talep artmaya devam ederken IPv4 adreslerinin arzı artmamaktadır.

Internet Assigned Numbers Authority, genel IPv4 arzının tükendiğini doğrulamaktadır. Buna rağmen müşteriler, kurumsal entegrasyonlar, eski uygulamalar, güvenlik araçları, API’ler ve ağ cihazları hâlâ IPv4 bağlantısına bağımlıdır. IPv6’nın benimsenmesi gereklidir, ancak bu durum IPv4 İnternetini destekleme konusundaki mevcut ihtiyacı ortadan kaldırmaz.

Bu nedenle altyapı sağlayıcıları için IPv4 yalnızca bir adres gereksinimi değildir. Aynı zamanda kapasite, süreklilik, güvenlik ve müşteri deneyimiyle ilgili bir konudur.

Sürdürülebilir bir IPv4 stratejisi beş soruya yanıt vermelidir:

1. Platform gerçekte ne kadar genel IPv4 kapasitesine ihtiyaç duyuyor?
2. Hangi iş yükleri özel IPv4 adresleri gerektiriyor?
3. Dağıtımı yavaşlatmadan yeni kapasite nasıl elde edilecek?
4. Yönlendirme, itibar, kötüye kullanım yönetimi ve yenilemeden kim sorumlu olacak?
5. IPv4 ve IPv6 uzun vadede birlikte nasıl çalışacak?

Bu rehber, bulut, yapay zekâ ve hosting sağlayıcılarının bu stratejiyi nasıl oluşturabileceğini açıklamaktadır.

IPv4 altyapı sağlayıcıları için neden kritik olmaya devam ediyor?

IPv4, 32 bitlik bir adres alanı kullanır. Bu teknik sınırlama, İnternete bağlı hizmetlerin süresiz olarak büyümesini destekleyemez. Kullanılabilir adres alanı artık mevcut tahsisler, transferler, kiralama, geri kazanım ve daha verimli kullanım yoluyla yönetilmektedir.

Bununla birlikte, çeşitli altyapı pazarlarında talep güçlü kalmaya devam etmektedir.

Bulut platformları

Genel bulut hizmetleri aşağıdaki amaçlar için IPv4 adreslerine ihtiyaç duyabilir:

- Sanal makineler ve bare-metal örnekleri
- Genel yük dengeleyiciler
- Yönetilen veritabanları ve uygulama ağ geçitleri
- Ağ adresi çevirisi ağ geçitleri
- Müşteri tarafından kontrol edilen güvenlik duvarları
- VPN ve uzaktan erişim hizmetleri
- Multi-cloud ve hibrit bulut bağlantısı

Müşteriler bir hizmet başlattıklarında çoğu zaman bir IPv4 endpoint’inin kullanılabilir olmasını bekler. Adres kapasitesi işlem kapasitesiyle aynı hızda büyüyemezse IPv4, gelir üreten altyapı üzerinde bir kısıt hâline gelir.

Yapay zekâ altyapısı

Yapay zekâ platformları kendi IPv4 gereksinimlerini oluşturur. GPU kümeleri dahili olarak özel adresleme kullanabilir, ancak genel adresler çoğu zaman aşağıdaki amaçlar için hâlâ gereklidir:

- Çıkarım API’leri
- Model sunum endpoint’leri
- Yapay zekâ geliştirme ortamları
- Müşteri panoları
- Veri alım ağ geçitleri
- Güvenli yönetim erişimi
- Üçüncü taraf sistemlerle entegrasyon
- Dağıtık veri işleme hizmetleri

Yapay zekâ ile ilişkili hızlı dağıtım döngüleri, tedarik hızını özellikle önemli hâle getirir. Bir platform, ağ ekibi kullanılabilir genel adres alanını beklediği için boşta kalan işlem kapasitesine sahip olmamalıdır.

Hosting ve veri merkezi hizmetleri

Özel hosting, VPS, colocation, yönetilen altyapı ve uygulama hosting hizmetleri büyük ölçüde IPv4’e bağımlı olmaya devam etmektedir. Birçok müşteri en az bir kullanılabilir genel IPv4 adresi beklerken yönetilen güvenlik duvarları, yüksek erişilebilirlik, SSL sonlandırma ve özel cihazlar gibi hizmetler ek kapasite gerektirebilir.

Dolayısıyla IPv4 kullanılabilirliği; ürün paketlemesini, müşteri kazanımını, yeni lokasyonlara genişlemeyi ve her sunucu ya da sanal makinenin ekonomik değerini etkileyebilir.

IPv4’ü bir altyapı portföyü olarak değerlendirin

İlk adım, her adresi birbirinin yerine kullanılabilir olarak değerlendirmeyi bırakmaktır.

Etkili bir portföy, IPv4 gereksinimlerini iş yüküne, süreye, müşteri değerine ve arıza etkisine göre ayırır. Sağlayıcılar talebi dört geniş kategoriye ayırabilir:

- **Temel üretim kapasitesi:** Uzun ömürlü hizmetleri, kritik endpoint’leri, müşteri altyapısını ve yeniden numaralandırılması maliyetli iş yüklerini destekleyen adresler.
- **Büyüme kapasitesi:** Tahmini genişleme, yeni bölgeler, ek sunucular veya ürün lansmanları için ayrılan adresler.
- **Esnek kapasite:** Değişken veya daha kısa süreli talepler için kullanılan adresler.
- **Geçiş kapasitesi:** Geçişleri, satın almaları, yeniden numaralandırmayı veya dual-stack dağıtımını destekleyen adresler.

Bu sınıflandırma, işletmenin nerede maksimum sürekliliğe ihtiyaç duyduğunu ve nerede daha fazla operasyonel esnekliği kabul edebileceğini belirlemesine yardımcı olur.

Yüzlerce müşteri iş yükünü destekleyen bir üretim adresi, geçici geliştirme kapasitesiyle aynı kontroller altında temin edilmemelidir. Bir IPv4 düzenlemesinin maliyeti yalnızca adres başına aylık fiyatla değil, başarısızlığın maliyetiyle de karşılaştırılmalıdır.

IPv4 talebini iş faktörlerine göre tahmin edin

Altyapı sağlayıcıları IPv4 tahminlerini ölçülebilir ticari faaliyetlerle ilişkilendirmelidir.

Yararlı girdiler şunları içerir:

- Dağıtılacak sunucu, instance, tenant veya küme sayısı
- Beklenen müşteri büyümesi ve kayıp oranı
- Ürün başına ortalama adres tüketimi
- Bölgesel genişleme planları
- Özel IP ile paylaşımlı IP ürünlerinin oranı
- Yüksek erişilebilirlik için gerekli kapasite
- Mevcut bloklardaki kullanım ve parçalanma
- Ağ, broadcast, gateway veya operasyonel amaçlar için ayrılan adresler
- Bir adres yeniden tahsis edilmeden önceki karantina süresi
- Geçiş ve acil durum kapasitesi

Tahminler birden fazla zaman dilimini kapsamalıdır. 90 günlük sürekli bir operasyonel tahmin tedariki desteklerken 12 ila 24 aylık bir model yönetimin kiralama, satın alma, adres optimizasyonu ve IPv6 yatırımlarını değerlendirmesine yardımcı olur.

Ekipler ayrıca bir kapasite tamponu bulundurmalıdır. Kullanılabilir havuzun sıfıra ulaşmasını beklemek, normal büyümeyi acil bir tedarik sürecine dönüştürür.

Ne zaman kiralanacağına, satın alınacağına veya optimize edileceğine karar verin

Her sağlayıcıya uygun tek bir tedarik modeli yoktur. Büyük operatörlerin çoğu farklı yaklaşımların bir kombinasyonundan fayda sağlar.

Ölçeklenebilir ve sermaye açısından verimli büyüme için IPv4 kiralayın

Bir sağlayıcının aşağıdaki ihtiyaçları olduğunda kiralama uygun olabilir:

- Büyük bir ön satın alma yapmadan adres kapasitesi eklemek
- Yeni bir bölgeyi veya hizmeti hızlı bir şekilde başlatmak
- IPv4 taahhütlerini müşteri talebiyle eşleştirmek
- İşlem gücü, depolama, GPU ve ağ genişlemesi için sermayeyi korumak
- Parçalanmış bir adres sağlayıcı zincirini yönetmekten kaçınmak
- Uzun vadeli talep belirsizken esnekliği korumak

Ancak bir IPv4 kiralaması, altyapı bağımlılığı olarak değerlendirilmelidir. Sağlayıcının adresler üzerindeki mülkiyeti veya kontrolü, yenileme koşulları, yönlendirme desteği, kayıt kuruluşundaki durumu ve operasyonel yetenekleri önemlidir.

LARUS, kontrolü altındaki adres havuzundan doğrudan birinci taraf IPv4 kiralama hizmeti sunmaktadır. Mevcut hizmet yapısı, müşterilerin yalnızca kapasite kiralamasını seçmesine veya yönlendirme geçerliliği, RPKI/ROA hazırlığı, ters DNS, kötüye kullanım süreçleri, coğrafi konum desteği, yanıt taahhütleri ve yenileme kesinliği gibi alanları kapsayan süreklilik kontrolleri eklemesine olanak tanır.

Mülkiyet sermaye stratejisine uyduğunda satın alın

Satın alma; öngörülebilir, kalıcı ihtiyaçları olan ve transfer, kayıt kuruluşu, uyumluluk, yönlendirme, güvenlik ve yaşam döngüsü yükümlülüklerini yönetebilecek kaynaklara sahip kuruluşlar için uygun olabilir.

Satın alma fiyatı kararın yalnızca bir parçasıdır. Alıcılar aşağıdakileri değerlendirmelidir:

- Bölgesel İnternet Kayıt Kuruluşu gereksinimleri
- Mülkiyet ve transfer belgeleri
- Adres geçmişi ve itibarı
- Yönlendirme yetkilendirmesi
- Devam eden kayıt kuruluşu sorumlulukları
- Dahili yönetişim
- Yetersiz kullanılan alanı elde tutmanın gelecekteki maliyeti

Mülkiyet uzun vadeli ekonomik değer sağlayabilir, ancak aynı zamanda idari ve kayıt kuruluşuyla ilgili sorumlulukları işletme şirketi içinde yoğunlaştırır.

Optimize existing space before adding capacity

Sağlayıcılar mevcut tahsislerini düzenli olarak aşağıdakiler açısından denetlemelidir:

- Kullanılmayan müşteri tahsisleri
- Gereğinden büyük alt ağlar
- Terk edilmiş geliştirme ortamları
- Hizmet sonlandırıldıktan sonra elde tutulan adresler
- Yinelenen rezervasyonlar
- Zayıf tahsis kayıtları
- Verimli yeniden tahsisi engelleyen parçalanma

Optimizasyon faydalıdır, ancak sınırları vardır. Adreslerin aşırı agresif şekilde yeniden kullanılması operasyonel yükü artırabilir ve adresler uygun inceleme ve karantina olmadan müşteriler arasında taşınırsa itibar sorunları oluşturabilir.

İhtiyaç duyduğundan daha fazla IPv4’e sahip kuruluşlar kullanılmayan kaynakları satmayı da değerlendirebilir. LARUS, IPv4 adres alanının doğrudan birinci taraf alıcısı olarak faaliyet göstermekte ve bir kuruluşun bir bloğu satıp hâlâ ihtiyaç duyduğu kapasiteyi geri kiraladığı yapıları desteklemektedir.

Sürekliliği tedarik sürecinin bir parçası hâline getirin

Yalnızca adreslerin mevcut olması, bir bloğu üretime hazır hâle getirmez.

Kiralanan veya satın alınan IPv4 alanı hizmete alınmadan önce sağlayıcı aşağıdakileri doğrulamalıdır:

- Adresleri sağlayan tarafın bunu yapma yetkisine sahip olması
- İzin verilen kullanımın açıkça belgelenmiş olması
- Gerekli önekin sağlayıcının ASN’sinden duyurulabilmesi
- Route Origin Authorization kayıtlarının oluşturulup sürdürülebilmesi
- Ters DNS’in devredilebilmesi veya yönetilebilmesi
- Gerektiğinde coğrafi konum kayıtlarının düzeltilebilmesi
- Kötüye kullanım bildirimleri için belirlenmiş bir yanıt sürecinin bulunması
- Yenileme ve sonlandırma koşullarının iş yüküyle uyumlu olması
- Adreslerin iade veya yeniden numaralandırma sürecinin anlaşılmış olması
- Destek eskalasyon yollarının ve yanıt beklentilerinin belgelenmiş olması

Amaç, sözleşme ile canlı ağ arasındaki bağımlılıkların sayısını azaltmaktır.

Birinci taraf tedarikin önemli olmasının nedenlerinden biri budur. Birden fazla aracı üzerinden kiralama, operasyonel bir sorun ortaya çıktığında mülkiyet, yetkilendirme, yenileme ve sorumluluk konusunda belirsizlik yaratabilir. LARUS, kiralama modelini doğrudan birinci taraf ilişkisi olarak konumlandırmaktadır ve temel kaynak ile süreklilik katmanından sorumlu olmaya devam etmektedir.

Yönlendirmeyi RPKI ve ROA ile koruyun

Geçerli bir ticari anlaşma otomatik olarak güvenli bir yönlendirme yapılandırması oluşturmaz.

Resource Public Key Infrastructure veya RPKI, bir kaynak sahibinin bir otonom sistemin belirli bir öneki duyurmasına izin vermesini sağlar. Ortaya çıkan Route Origin Authorization, izin verilen kaynak ASN’yi ve maksimum önek uzunluğunu tanımlar. ROA’ların teknik rolü IETF’nin RPKI spesifikasyonlarında açıklanmaktadır.

Bulut, yapay zekâ ve hosting sağlayıcıları için onboarding süreci aşağıdakileri içermelidir:

1. Kaynak ASN’nin doğrulanması
2. İlgili ROA’nın oluşturulması veya güncellenmesi
3. Yetkilendirilmiş önek uzunluğunun kontrol edilmesi
4. Üretim kullanımından önce rotanın doğrulanması
5. Geçersiz veya beklenmeyen duyuruların izlenmesi
6. Herhangi bir yönlendirme geçişinden önce yetkilendirmenin güncellenmesi
7. Offboarding sonrasında eski yetkilendirmenin kaldırılması

RPKI; rota izleme, önek filtreleri, belgelenmiş değişiklik kontrolü ve hassas yönlendirme değişiklikleri için çok taraflı doğrulama ile birlikte kullanılmalıdır.

İtibarı operasyonel bir varlık olarak yönetin

Bir IPv4 adresi teknik olarak yönlendirilebilir olsa bile itibarı kötüyse ticari olarak kullanılamaz hâle gelebilir.

Bulut ve hosting ortamları spam, kimlik bilgisi kötüye kullanımı, kötü amaçlı yazılım, tarama, phishing ve diğer yasaklı faaliyetlerin sık hedefidir. Yapay zekâ platformları ayrıca otomatik hesap oluşturma, proxy kötüye kullanımı, scraping veya onaylanmamış toplu faaliyetlerle ilgili ek risklerle karşılaşabilir.

Sağlayıcılar hem yeni gelen adres alanının geçmişini hem de yeni müşterilerin davranışını değerlendirmelidir.

Pratik bir itibar programı şunları içerir:

- Dağıtım öncesi ilgili itibar kaynaklarının kontrol edilmesi
- Açık kabul edilebilir kullanım politikaları
- Müşteri kimliği ve risk kontrolleri
- Anormal trafiğin otomatik olarak tespit edilmesi
- Özel kötüye kullanım iletişim kişileri
- Kanıta dayalı olay yönetimi
- Yeniden tahsis öncesi adres karantinası
- Doğru ileri ve ters DNS
- Coğrafi konum ve itibar kayıtlarını düzeltmeye yönelik süreçler
- Düzeltici faaliyetlerin belgelenmesi

İtibar, yalnızca onboarding sırasında yapılan tek seferlik bir kontrol değildir. Adresin tüm yaşam döngüsü boyunca yönetilmelidir.

Paylaşımlı IPv4’ü seçici olarak kullanın

NAT ve carrier-grade NAT genel adres tüketimini azaltabilir, ancak iş yüküne göre uygulanmalıdır.

Paylaşımlı IPv4; dışa giden müşteri trafiği, dahili hizmetler, geliştirme ortamları ve benzersiz bir inbound endpoint gerektirmeyen iş yükleri için iyi çalışabilir. Carrier-grade NAT için ayrılan paylaşımlı adres alanı [RFC 6598] içinde tanımlanmıştır.

Müşterilerin aşağıdaki ihtiyaçları olduğunda özel genel IPv4 hâlâ gerekli olabilir:

- Gelen bağlantılar
- Kararlı allowlist kullanımı
- Müşteri kontrollü DNS
- Bağımsız e-posta itibarı
- NAT üzerinden düzgün çalışmayan protokoller
- Doğrudan sunucu yönetimi
- Uyumluluk gereksinimlerine dayalı trafik ayrımı
- Barındırılan bir hizmet için benzersiz endpoint

Amaç her ne pahasına olursa olsun adres paylaşımını en üst düzeye çıkarmak olmamalıdır. Sağlayıcılar her ürüne adres verimliliği, gözlemlenebilirlik, desteklenebilirlik ve müşteri deneyimi arasında kabul edilebilir bir denge sağlayan mimariyi kullanmalıdır.

IPv4’ün ortadan kalkacağını varsaymadan IPv6’yı benimseyin

IPv6, adres kıtlığının uzun vadeli çözümüdür. Her bulut, yapay zekâ ve hosting sağlayıcısının aktif bir IPv6 yol haritası bulunmalıdır.

Bu yol haritası şunları içerebilir:

- Dual-stack yönetim ve müşteri ağları
- Yük dengeleyiciler ve API’ler için IPv6 desteği
- IPv6 destekli Kubernetes ve container platformları
- IPv6 izleme, loglama ve güvenlik kontrolleri
- Müşteri belgeleri ve geçiş araçları
- IPv6 destekli DNS ve otomatik provisioning
- Faturalama ve adres yönetim sistemlerinde IPv6 desteği

Ancak dual-stack, ekiplerin her iki protokolü de güvence altına alması, izlemesi, sorunlarını gidermesi ve belgelemesi gerektiği için operasyonel karmaşıklığı artırabilir. Bu nedenle IPv6’nın benimsenmesi yalnızca bir adres tahsis çalışması değil, bir mühendislik programı olarak ele alınmalıdır.

Öngörülebilir gelecekte birçok sağlayıcının entegre bir stratejiye ihtiyacı olacaktır: ölçek ve mimari modernizasyon için IPv6, evrensel erişilebilirlik ve müşteri uyumluluğu için güvenilir IPv4.

Bir IPv4 kontrol düzlemi oluşturun

Bir sağlayıcı büyüdükçe elektronik tablolar ve gayriresmî ticket iş akışları riskli hâle gelir. IPv4 kapasitesi entegre bir kontrol düzlemi veya IP adres yönetim sistemi üzerinden yönetilmelidir.

Sistem en azından aşağıdakileri takip etmelidir:

- Önek ve adres envanteri
- Mülkiyet veya kiraya veren bilgileri
- Bölge ve RIR
- ASN ve yönlendirme durumu
- ROA durumu
- Müşteri veya iş yükü tahsisi
- Ters DNS yetkisi
- Coğrafi konum
- İtibar olayları
- Kiralama başlangıç, yenileme ve bitiş tarihleri
- Kullanım oranı
- Karantina ve yeniden tahsis geçmişi

Ticari ve ağ kayıtları birbiriyle uyumlu olmalıdır. Yalnızca satın alma ekibinin gelen kutusunda bulunan bir yenileme tarihi operasyonel bir risktir.

Kapasite eşikleri, sözleşme son tarihleri, ROA sürelerinin sona ermesi, yönlendirme değişiklikleri veya müşteri geçişleri işlem gerektirmeden çok önce uyarılar oluşturulmalıdır.

Pratik bir IPv4 stratejisi kontrol listesi

Bulut, yapay zekâ ve hosting sağlayıcıları adres stratejilerini oluştururken aşağıdaki kontrol listesini kullanabilir:

- Adres talebini iş yüküne ve arıza etkisine göre segmentlere ayırın
- 90 günlük ve uzun vadeli kapasite tahminleri oluşturun
- Minimum rezerv eşikleri belirleyin
- Mevcut kullanımı denetleyin ve gerçekten kullanılmayan alanı geri kazanın
- Süre, sermaye ve riske göre kiralama veya satın almayı seçin
- Tedarikçinin yetkisini ve ticari zinciri doğrulayın
- Yenileme, sonlandırma ve yeniden numaralandırma koşullarını belgeleyin
- Dağıtımdan önce itibarı doğrulayın
- Uygun ROA’ları oluşturun ve izleyin
- rDNS, coğrafi konum ve kötüye kullanım yönetimi sorumluluklarını belirleyin
- Destek taahhütlerini hizmet arızasının maliyetiyle eşleştirin
- IPv4 uyumluluğunu korurken IPv6’yı sistematik olarak devreye alın
- Ağ, müşteri ve ticari envanterleri senkronize tutun
- Şirket yeni bir bölge, ürün veya büyük müşteri dağıtımı başlattığında stratejiyi yeniden gözden geçirin

IPv4 kapasitesi büyümeyi desteklemeli, sınırlamamalıdır

Bulut, yapay zekâ ve hosting sağlayıcıları için IPv4 kıtlığı tek bir satın alma, geçici bir kiralama veya IPv6 duyurusuyla çözülemez. Kapasite planlama, tedarik, yönlendirme, itibar, güvenlik, yenilemeler ve protokol modernizasyonunu birbirine bağlayan bir işletim modeli gerektirir.

En güçlü strateji, işletmenin ne kadar IPv4’e ihtiyaç duyduğunu, hangi hizmetlerin gerçekten buna ihtiyaç duyduğunu, adreslerin nereden geldiğini, nasıl korunduğunu ve talep veya tedarikçiler değişirse ne olacağını bildiği stratejidir.

LARUS, altyapı sağlayıcılarını doğrudan birinci taraf IPv4 kiralama ve Continuity Assurance ile desteklemektedir. Capacity Only, Production, Enterprise ve Critical seçenekleri kuruluşların operasyonel kontrolleri her dağıtımın önemine göre ayarlamasına olanak tanır.

Blok boyutu, dağıtım coğrafyası, ASN gereksinimleri, yönlendirme, süreklilik veya yenileme ihtiyaçlarını görüşmek için LARUS ile iletişime geçin veya sales@larus.net adresine e-posta gönderin.

Sıkça sorulan sorular

1. Bulut sağlayıcıları neden hâlâ IPv4’e ihtiyaç duyuyor?

Bulut sağlayıcıları IPv4’e ihtiyaç duyar çünkü birçok kullanıcı, kurumsal ağ, uygulama, cihaz ve üçüncü taraf entegrasyonu yalnızca IPv6 üzerinden henüz erişilebilir değildir. Genel IPv4 endpoint’leri daha geniş İnternet genelinde uyumluluğu korur.

2. IPv4 kiralama üretim altyapısı için uygun mudur?

Evet, ancak kiralama uygun yetkiyi, yönlendirme desteğini, yenileme koşullarını, itibar kontrollerini ve operasyonel sorumlulukları içermelidir. Üretim iş yükleri, arıza maliyetlerine göre uygun bir süreklilik seviyesiyle eşleştirilmelidir.

3. Yapay zekâ platformları genel IPv4 adreslerini nasıl kullanır?

Yapay zekâ platformları genel IPv4’ü çıkarım API’leri, panolar, geliştirme ortamları, veri ağ geçitleri, iş ortağı entegrasyonları ve güvenli yönetim için kullanabilir. Dahili GPU trafiği çoğu zaman özel veya IPv6 ağlarında kalabilir.

4. Bir hosting şirketi IPv4 kiralamalı mı yoksa satın mı almalı?

Yanıt talep süresine, sermaye kullanılabilirliğine, dahili uzmanlığa ve istenen esnekliğe bağlıdır. Kiralama hızlı ve sermaye açısından verimli büyümeyi destekleyebilirken satın alma istikrarlı uzun vadeli ihtiyaçlar için uygun olabilir. Birçok sağlayıcı her ikisini de kullanır.

5. IPv6, IPv4 stratejisine olan ihtiyacı ortadan kaldırır mı?

Henüz değil. IPv6 uzun vadeli ölçek için gereklidir, ancak sağlayıcıların IPv4’e bağımlı müşterileri ve sistemleri desteklemeye devam etmesi gerekir. Dual-stack stratejisi geleceğe hazırlık ile mevcut uyumluluğu birleştirir.

6. Bir IPv4 sağlayıcısı adres kapasitesinin yanı sıra neleri desteklemelidir?

Üretim sağlayıcıları yönlendirme yetkilendirmesini, RPKI/ROA operasyonlarını, ters DNS’i, coğrafi konumu, itibarı, kötüye kullanım yanıtını, destek taahhütlerini, yenileme kesinliğini ve açık eskalasyon prosedürlerini dikkate almalıdır.