ARIN IPv4 transferinde hangi kurallar geçerli?
Kuzey Amerika bölgesindeki IPv4 transfer politikası değişiklikleri, bölgeler arası transferler üzerinden küresel adres piyasasını da etkileyebilir. ARIN, ABD, Kanada ve bazı Karayip ve Kuzey Atlantik bölgelerine hizmet veren bölgesel internet kayıt kurumudur. Bu rehber, IPv4 transferinin türünü, alıcının ihtiyaç değerlendirmesini ve devir hazırlığını ayırır. Bir hosting müşterisinin sağlayıcıdan IP kullanması, ARIN’e doğrudan transfer başvurusu yapmasıyla aynı işlem değildir.
Hosting ve ağ ekipleri, adres planlaması ile orta–uzun vadeli ağ stratejilerini etkileyen politika değişikliklerini değerlendirmeli. IPv4 adreslerinin transfer bedeli, onları teknik bir kaynağın yanı sıra bütçe planlamasının da önemli bir kalemi haline getiriyor. Dolayısıyla ARIN’in transfer kurallarındaki değişiklikler; fiyatlama, kapasite artış planları ve IPv6 geçiş takvimi açısından incelenmeli.
Tarih ve güncelleme notu: Yazının ilk yayın tarihi 25 Aralık 2025’tir. O tarihte yürürlükte olan NRPM 2025.1, 24 aylık ihtiyaç ölçütünü ve aşağıdaki temel transfer koşullarını zaten içeriyordu. ARIN-2025-2, 15 Aralık 2025’te kabul edildi; 3 Mart 2026’da yürürlüğe girdi. Değişiklik, 8.5.1’de dosyadaki RSA’nın “son iki sürümden biri” olma şartını kaldırıp güncellik değerlendirmesini ARIN iş uygulamalarına bıraktı. 4 Kasım 2026 tarihli kontrolde NRPM 2026.1 ve değişiklik kaydı esas alındı. Bu değişiklik, bütün transfer kurallarının yeni sıkılaştığı veya 24 ay şartının yeni getirildiği anlamına gelmez.
ARIN ve IPv4 transfer ekosisteminin kısa özeti
ARIN’in genel IPv4 serbest havuzu Eylül 2015’te tükendi. Bu, hiçbir adres edinme yolunun kalmadığı anlamına gelmez: uygun kuruluşlar transfer, geri dönen adresler için bekleme listesi veya özel amaçlı rezerv havuzlarının koşullarını değerlendirebilir. Bu seçeneklerin uygunluk ve süre kuralları farklıdır.
Bu yazıda ARIN’in IPv4 adres edinimiyle ilgili üç mekanizmasını ele alıyoruz:
- ARIN içi belirli alıcıya transfer (8.3): Kayıtlı kaynak kuruluş ile uygun alıcı arasında IPv4 devri.
- Inter-RIR transfer (8.4): Transferi kabul eden, karşılıklı ve uyumlu ihtiyaç temelli politikalara sahip RIR’lar arasındaki devir.
- Bekleme listesi (4.1.8): Uygun kuruluşlara geri dönen adreslerden dağıtım; bir 8.3 satın alma transferi değildir.
Şirket birleşmesi, satın alma veya yeniden yapılanma yoluyla 8.2 transferi ayrıca değerlendirilir. Alıcının, adresleri kullanan varlıkları veya kayıtlı kuruluşun tamamını edindiğini belgelemesi gerekir. Yeni kuruluşun RSA imzalaması ve kaynağın ihtilaflı olmaması gibi koşullar sürer; ancak 8.2 kapsamındaki kaynaklar transfer sırasında ihtiyaç temelli değerlendirmeye tabi tutulmaz. Sadece şirketin hukuki adı değişmişse ARIN’in ad değişikliği süreci uygulanabilir. ARIN transfer rehberi bu yolları ve istenen belgeleri ayırır.
- Hangi transfer türünün işleminize uyduğu
- Kaynak ve alıcı kuruluşun uygunluğu ile gerekli belgeler
- Uygulanıyorsa istenen blok boyutu ve kullanım projeksiyonu
- Inter-RIR işlemlerde hangi tarafın hangi RIR koşullarını karşılayacağı
Adres edinme seçeneklerinin genel çerçevesi için ARIN’de IPv4 adres edinme seçeneklerini ele alan rehberi inceleyebilirsiniz. Burada transfer türü, uygunluk ve süre koşullarına odaklanıyoruz.
Transfer türü, ihtiyaç değerlendirmesi ve kayıt koşulları
ARIN politikaları oldukça teknik bir dil kullanıyor. Burada, ağ yöneten ekiplerin günlük operasyonları açısından önemli başlıkları özetleyelim.
1. Belirli alıcının ihtiyaç ve blok boyutu koşulları
8.3 alıcıları ve 8.4 kapsamında ARIN bölgesine gelen transferlerin alıcıları NRPM 8.5 koşullarını karşılamalıdır. Kaynaklar operasyonel bir ağda kullanım amacıyla verilir; bir satış anlaşması tek başına transfer onayı değildir. 8.5.1’e göre alıcı, devredilecek kaynakları kapsayan RSA imzalar; ARIN iş uygulamalarına göre güncel RSA zaten dosyadaysa istisna uygulanır. Blok büyüklüğü ve varsa mevcut kullanım ölçütleri ayrıca kontrol edilir.
Genel koşulları okurken şu ayrımları koruyun:
- Asgari transfer: 8.5.3 uyarınca /24’tür. ARIN’den IPv4 tahsisi bulunmayan kuruluşlar 8.5.4’te bu asgari boyutta ilk tahsis için uygun sayılır; diğer koşullar ortadan kalkmaz.
- Daha büyük ilk blok veya ek blok: 8.5.5 kapsamında talep edilen büyüklüğün en az %50’sinin 24 ay içinde kullanılacağını gösteren belge gerekir.
- Mevcut kullanım: ARIN IPv4 tahsisi olan kuruluşlar 8.5.6 uyarınca ek adres almadan önce kümülatif bloklarının en az %50’sini verimli kullanmış olmalıdır; müşterilere yeniden tahsis/atama da hesaba katılır.
- Özel yollar: Yeniden numaralama için 8.5.5.1 ve 8.5.6.1; alternatif ek blok değerlendirmesi için 8.5.7 ayrı koşullar içerir. Tek bir yüzdeyi tüm başvurulara uygulamayın.
Beş yıllık iş planı bütçe açısından yararlı olabilir; 8.5.5’teki 24 aylık kullanım belgesinin yerine geçmez. Tahmini adres ihtiyacını müşteri ve servis büyümesiyle ilişkilendirin. Ağ şeması, IPAM tablosu veya ürün raporu hazırlık aracıdır; bu örneklerin hepsi her başvuru için ayrı ayrı zorunlu belge değildir.
2. Inter-RIR transferde karşılıklı uyumluluk
NRPM 8.4, transferi kabul eden ve karşılıklı, uyumlu ihtiyaç temelli politikalara sahip RIR’lar arasında işlem yapılmasına izin verir. Bir bölgede şirket veya ASN bulunması tek başına yeterli değildir:
- 8.3 kaynak kuruluşu güncel kayıtlı hak sahibi olmalıdır; 8.4 kaynak kuruluşu ise kaynaktan sorumlu RIR tarafından tanınan güncel hak sahibi olmalıdır. Her iki durumda da kaynakların statüsü hakkında ihtilaf bulunmamalıdır.
- ARIN dışındaki kaynak kuruluş, kayıtlı olduğu RIR’ın kaynak koşullarını karşılamalıdır.
- ARIN dışındaki alıcının koşullarını alıcı RIR belirler; ARIN’e gelen alıcı ise 8.5’i karşılamalıdır.
- ARIN kaynaklı 8.4 işleminde kaynak kuruluş, onaydan önceki 12 ayda ARIN’den IPv4 transferi/tahsisi/ataması almamış olmalıdır. Bir tarafın diğerini sahiplenmesi veya kontrol etmesi, ortak sahiplik/kontrol ve 8.2 işlemleri için metindeki istisnaları kontrol edin.
- 8.3’te de kaynak kuruluşun son 12 ayda ARIN’den transfer/tahsis/atama almaması koşulu vardır; 8.2 istisnası ve 8.5.5.1 kapsamında yeniden numaralama için ARIN’in verebileceği muafiyet ayrı düzenlenmiştir. Bu, her bloğun mutlaka yıllarca tutulması gerektiği şeklinde genellenemez.
- Özel havuzlar: 4.4 ve 4.10 dâhil rezerv havuzlarından verilen adres kaynakları, 8.3 ve 8.4 kapsamında transfere uygun değildir.
Bu durum, özellikle ARIN bölgesinde adresi olup başka bölgelerde altyapı işleten şirketleri yakından ilgilendiriyor. Farklı bölgesel kayıtların politikaları arasındaki uyumsuzluklar, transferin uygunluğunu veya tamamlanma süresini etkileyebilir ve ek operasyonel maliyet yaratabilir.
3. Bekleme listesi ve geri kazanılmış blokların yönetimi
NRPM 4.1.8 ve bekleme listesi rehberi, uygunluk ve dağıtım koşullarını açıklar. Aşağıdaki sınırlar 2025 arşivinde de bulunur:
- Bir kuruluşun aynı anda hak kazanabileceği toplam en büyük boyut /22’dir; kabul edeceği daha küçük boyutu /24’e kadar seçebilir. 4.4/4.10 özel kullanım alanı hariç toplam /20’den fazla IPv4 tutan kuruluşlar başvuramaz.
- Dağıtım, elde edilen blokların büyüklüğüne bağlı olarak ilk onaylanan talepten ilerler. Her kuruluşun tek onaylı talebi bulunabilir; sıra numarası kesin teslim tarihi değildir.
- Listeden verilen adresler, 8.2 hariç, 60 ay transfer edilemez. 8.3/8.4 kaynak kuruluşu IPv4 devrettikten sonra listeye 36 ay başvuramaz; alıcı uygulanıyorsa listeden çıkarılır ve 90 gün yeniden başvuramaz.
- 8.2 kaynağının 36 aylık liste kısıtında ana/bağlı şirket veya ortak sahiplik istisnası vardır. Listedeyken herhangi bir 8. bölüm transferinde kaynak olma başvurusu yapmak da 8.6 uyarınca listeden çıkarılmaya yol açar.
“Nasıl olsa sıraya yazıldık, bir noktada bize de blok düşer” diyerek yalnızca bekleme listesine güvenmek, kapasite planlamasını belirsiz bırakır. IPv4 ihtiyacını transfer piyasası + bekleme listesi + mevcut blok optimizasyonu seçeneklerini birlikte değerlendirerek planlamak daha sağlam bir yaklaşımdır.
4. Kayıt doğruluğu ve teknik kullanımın ayrılması
4 Mart 2025’te uygulanan ARIN-2024-2, kuruluş ve iletişim verisinin Whois’te toplanması/yayımlanmasını netleştirdi. Öneri mevcut uygulamanın açıklığa kavuşturulmasını amaçlar; yeni bir transfer sonrası güncelleme süresi veya adresin fiziksel yerini doğrulama sistemi getirdiği sonucu çıkarılamaz.
- Org ID, yetkili POC ve kaynak kaydındaki kuruluş bilgilerinin işlemle uyumunu kontrol edin.
- Whois/RDAP kayıt verisi sunar; trafiğin fiilen hangi veri merkezinden çıktığını veya tüm özel sözleşmeleri kanıtlamaz.
- BGP duyurusu, RPKI, reverse DNS ve IP itibarı için ayrıca teknik doğrulama yapın.
Doğru kayıtlar, yetkili kuruluşa ve kötüye kullanım iletişim noktasına ulaşmayı kolaylaştırır. Transfer onayı veya Whois kaydı; temiz IP itibarı, e-posta teslimi ya da kesintisiz yönlendirme garantisi değildir.
İşletme türüne göre planlama etkileri
Doğrudan kaynak sahibi olmak ile sağlayıcıdan adres kullanmak farklı sorumluluklar doğurur. Üç farklı işletme profilini ayrı ayrı ele alalım.
Küçük ve orta ölçekli işletmeler
Tipik senaryo: 1–3 adet dedicated sunucu veya orta boy bir VPS kümesi üzerinde çalışan bir e‑ticaret sitesi, kurumsal uygulama ya da SaaS paneli. Bu örnekte işletme, IP adreslerini hizmet aldığı hosting sağlayıcısı üzerinden kullanır; doğrudan ARIN transfer başvurusu yapmaz.
Bu grup için olası bütçe etkilerini şu başlıklarda değerlendirmek gerekir:
- IPv4 adres ücretleri, barındırma bütçesinde ayrıca izlenmesi gereken bir maliyet kalemidir; artış olup olmayacağı sağlayıcının fiyatlandırmasına bağlıdır.
- Paylaşımlı IPv4 yerine özel IPv4 talep etmek ek ücret doğurabilir; bunun paket fiyatına etkisi hizmet koşullarına bağlıdır.
- IPv6’yı destekleyen kullanım alanlarında IPv4 bağımlılığını azaltmak, gelecekteki ek adres ihtiyacını sınırlamaya yardımcı olabilir.
Yeni projelerde IPv6’yı en baştan mimariye dahil etmek, IPv4 bağımlılığını azaltmaya yardımcı olabilir. IPv4 kullanımını ise e‑posta teslimi, bazı entegrasyonlar ve geri uyumluluk gibi alanlarda, karşı uçların ve kullanıcıların erişim gereksinimlerine göre planlamak gerekir.
Büyük kurumsal ağlar ve operatörler
Büyük ISPlar, taşıyıcılar ve kurumsal ağlar için ARIN politikaları teknik ve finansal planlamada önemlidir. Özellikle:
- Yeni alınacak blokların büyüklüğü
- Eski blokların konsolidasyonu ya da elden çıkarılması
- Inter-RIR transferle farklı bölgelere adres taşıma planları
Büyük ağlar için blok büyüklüğü, mevcut kullanım, yeni servisler ve müşteri büyümesi aynı kapasite modelinde izlenmelidir. Trafik hacmi tek başına kaç IPv4 gerektiğini göstermez; adres ataması ve kullanımını da belgeleyin. Fazla alanı devretme veya daha küçük bloğa yeniden numaralama düşünülüyorsa ilgili kaynak koşulları, geçiş maliyeti ve istisnalar birlikte değerlendirilmelidir.
Hosting ve veri merkezi işletmecileri
Hosting ve veri merkezi işletmecileri, müşteri talepleri için kullanılabilir adresleri ve yeni kapasitenin nasıl sağlanacağını birlikte planlamalıdır. Hangi RIR kurallarının geçerli olduğu, kaynakların kaydı ve transferin yönüne bağlıdır; yalnız müşterinin veya sunucunun bulunduğu ülkeye bakarak karar verilmez.
Sağlayıcıyla veya kendi ağ ekibinizle şu konuları netleştirin:
- Yeni IP sağlama süresi: Müşteriye ilave IPv4 atamak gerektiğinde, gerekli onayları, süre belirsizliğini ve maliyeti önceden belirlemek.
- Blok segmentasyonu: Büyük blokları daha küçük parçalara bölerek farklı projelere tahsis etme stratejileri.
- IP itibarı ve temizlik: Transferle gelen blokların geçmişini inceleme ve gerekiyorsa temizlik (reputation cleanup) süreçleri.
Transferi operasyonel bir proje olarak planlamak için ARIN IP transferi ve operasyonel hazırlık yazısını da inceleyebilirsiniz.
IPv4 transferinin bütçesini nasıl planlamalı?
Transfer bütçesinde adres bedelini; işlem, kayıt, aracı, sözleşme incelemesi ve teknik geçiş maliyetlerinden ayırın. ARIN politika metni piyasa fiyatını belirlemez. Güncel bir teklif olmadan fiyatların sürekli arttığını veya bir kuralın doğrudan zam yarattığını varsaymayın; teklife tarih ve kapsam ekleyin.
IPv4 maliyeti ve adres seçenekleri rehberi, bütçe değerlendirmesini tamamlar. Çözüm seçeneklerini zaman ufkuna göre ayırabilirsiniz:
- Kısa vadeli çözümler: Mevcut blokların daha verimli kullanımı, NAT/CGNAT stratejileri, paylaşımlı IP modelleri.
- Orta vadeli çözümler: Yeni IPv4 transferleri için gerçekçi bütçe ayırma ve ARIN politikalarına uygun dokümantasyon hazırlama.
- Uzun vadeli çözümler: IPv6 geçiş planının işletme genelinde netleştirilmesi ve uygulamaya alınması.
Kullanılmayan bir bloğu hemen devredebileceğinizi veya satışının IPv6 projesini kesin finanse edeceğini varsaymayın. Önce kaynak uygunluğunu, aktif bağımlılıkları ve olası alıcı talebini inceleyin. Transfer kurallarının piyasadaki fiyatı hangi yönde değiştirdiği ayrı veri gerektirir.
Adres kıtlığını kapasite planıyla birlikte değerlendirmek için IPv4 tükenmesi ve hosting adres planı rehberini de kullanabilirsiniz. Transfer seçeneğini mevcut kullanımın iyileştirilmesi ve IPv6 hazırlığıyla birlikte değerlendirin.
IPv6 stratejisi ve gerçek IPv4 ihtiyacı
IPv6, uygun servislerde IPv4 bağımlılığını azaltabilir; fakat dual-stack bir uç nokta IPv4 adresini kullanmaya devam eder. IPv6 trafik payının artması kendiliğinden public IPv4 boşaltmaz. Özellikle içeride özel IPv4’ten IPv6’ya geçmek ile satın alınması gereken public adres sayısını azaltmak farklı sonuçlardır.
Yeni projelerde şu seçenekleri gerçek istemci ve uygulama bağımlılıklarıyla sınayın:
- IPv4 erişimi gereken yeni servislerde, destek doğrulandıktan sonra dual-stack (IPv4 + IPv6) kullanmak
- İç servisler, API trafiği ve servis–servis iletişimini mümkün olduğunca IPv6’ya kaydırmak
- Masaüstü ve mobil istemci erişiminde IPv6 kullanılabilirliğini takip etmek
Küresel IPv6 benimsemesinin gidişatını ve ağınızın hazır olup olmadığını merak ediyorsanız, IPv6 için ağ ve servis hazırlığını ele alan yazımıza mutlaka göz atın. Orada da vurguladığımız gibi, IPv6’ya hazırlık sadece router’larda birkaç ayar yapmak değil; adres planlamasından uygulama katmanına kadar uzanan bütünsel bir süreç.
Uygulama hazırlığı için VPS sunucularda IPv6 kurulum ve yapılandırma rehberini kullanabilirsiniz. Ürün/lokasyon desteği, yönlendirme, firewall, listener, TLS ve dış erişimi doğrulamadan AAAA yayımlamayın. Tasarrufu taşınan trafikle değil, artık ihtiyaç duyulmayan public IPv4 sayısı ve iki protokolü işletmenin maliyetiyle ölçün.
ARIN IPv4 transfer sürecine operasyonel bakış
Transfer türünü belirledikten sonra belgeleme, karşı tarafla koordinasyon ve teknik devralma için sorumlular atayın. Eksik yetkilendirme veya belgeler süreci geciktirebilir. ARIN onayını ve teknik kesintisizliği, sözleşmede varsayılmış bir tarih yerine ayrı tamamlanma koşulları olarak izleyin.
1. İhtiyaç analizi ve blok boyutu planlama
İlk adım, gerçekten ne kadar IPv4 adresine ihtiyaç duyduğunuzu akıllıca hesaplamak. Burada:
- Mevcut müşteri sayınız ve büyüme hızınız
- Planladığınız yeni servisler (örneğin ek veri merkezleri, yeni SaaS ürünleri vb.)
- NAT/CGNAT, paylaşımlı IP, reverse proxy gibi tekniklerle tasarruf potansiyeliniz
Bu verilerden, gerçekten ayrı public IPv4 gerektiren uçları belirleyin. Uygun web servisleri ortak bir IPv4 ve reverse proxy kullanabilir; modern TLS istemcilerinde SNI aynı IP üzerinde birden çok alan adını destekler. E-posta ve özel protokollerde gereksinim farklıdır. NAT/CGNAT seçerken inbound erişim, port tüketimi, log eşlemesi ve paylaşılan IP itibarı etkilerini test edin.
2. Dokümantasyon hazırlığı
Uygulanan politika maddesine göre bir ihtiyaç dosyası hazırlarken şu verilerden yararlanabilirsiniz:
- Mevcut adres kullanım oranları (subnet/subnet doluluk oranları)
- Müşteri sayıları, abonelik türleri ve büyüme eğrileri
- Orta vadeli (12–24 ay) kapasite planları ve yatırım projeksiyonları
- Transfer edilecek blokların ağ topolojinize nasıl entegre olacağını gösteren yüksek seviye şemalar
CRM, faturalama, IPAM ve ağ raporlarının farklı tarihlerden gelmesi kullanım hesabını çelişkili gösterebilir. Her veri kümesine tarih, kapsam ve sorumlu ekleyin; adres sayısını müşteri sayısı veya trafik miktarıyla karıştırmayın. ARIN’in başvurunuza özgü ek bilgi taleplerini aynı dosyada izleyin.
3. Hukuki ve sözleşmesel çerçeve
Transfer bedeli ve tarafların yükümlülükleri nedeniyle sözleşme çerçevesi de teknik hazırlık kadar önemlidir. Burada dikkat edilmesi gereken başlıklar:
- Alıcı ve satıcı arasında net bir transfer sözleşmesi (SPA – Sales & Purchase Agreement) yapmak
- İlgili işlemde ARIN’in istediği yetkilendirme belgeleri; örneğin 8.3 kaynak kuruluşu için imzalı ve noter tasdikli Officer Acknowledgement Letter
- Faturaların, vergi ve muhasebe süreçlerine uygun biçimde düzenlenmesi
- Transfer tamamlandıktan sonra olası itiraz ve geri çağırma senaryolarına ilişkin maddeler
Blok geçmişini inceleyip sözleşmede beyanları, inceleme süresini ve sorun çıkarsa izlenecek yolu açıkça belirleyin. Sözleşmeye IP itibarı maddesi eklemek, alıcı sistemlerin blocklist veya spam kararlarını değiştirmez. Kayıt devri, e-posta teslim edilebilirliğini garanti etmez.
4. Teknik devralma: RPKI, IRR ve reverse DNS
Teknik geçişi onaydan önce birlikte planlayın. ARIN’in kaynak kuruluş kontrol listesi, kaynak ROA’larının düzenlenmesini/silinmesini, geçersiz kalan IRR kayıtlarının güncellenmesini ve reverse DNS devrinin koordine edilmesini önerir. Alıcı yeni kayıtlarını hazırlamalı; eski ROA veya route kayıtlarının otomatik ve eksiksiz taşınacağını varsaymamalıdır.
- RPKI: Prefix, yetkili origin ASN ve maxLength değerlerini planlanan BGP duyurularıyla eşleştirin; ilgili doğrulama durumunu ve görünürlüğü kontrol edin. ASN’in mutlaka değişmesi gerekmez.
- IRR: IPv4 route nesnelerini ve ilgili kayıt yetkilerini doğrulayın; IPv6 route6 nesnesini sırf IPv4 transferi olduğu için değiştirmeyin.
- Reverse DNS: Delegasyon yetkisini ve gereken PTR kayıtlarını devralın; SMTP kullanılıyorsa ileri DNS ve posta kimliğini de kontrol edin.
- Çevre sistemleri: Firewall, DDoS koruma, WAF, rate limit, izleme ve müşteri atamalarını güncelleyin. Kontrollü duyuru, dış erişim testi ve geri alma planı olmadan geçişi bitmiş saymayın.
Kendi IP’sinden SMTP gönderen bir sunucuda PTR ve e-posta teslim edilebilirliği kontrolleri ayrıca gereklidir. PTR, tek başına SPF/DKIM/DMARC veya alıcı itibar değerlendirmesinin yerine geçmez; SMTP yanıtlarını ve başarısız teslimleri izleyin.
Hosting projesinde adres stratejisi
Sağlayıcıyla yapılacak planlamada üç başlığı somutlaştırın:
- IPv4 verimliliği: Paylaşımlı IP, NAT, reverse proxy veya CDN’nin hangi servislerde uygun olduğunu ve origin IPv4 ihtiyacının sürüp sürmediğini belirleyin.
- IPv6 desteği: Ürün ve lokasyon için tahsisi, prefix boyutunu, routing, PTR ve koruma kapsamını doğrulayın; her paket için aynı desteği varsaymayın.
- Adres planı: 12–24 aylık büyüme tahminini kullanım verisiyle ilişkilendirin; transfer uygunluğu ile uygulama geçiş sorumluluğunu ayrı kaydedin.
IPv4 fiyatlarının nereye gittiğini, gerçek maliyet hesabının nasıl yapılması gerektiğini merak ediyorsanız, IPv4 maliyeti ve alternatiflerini ele alan yazı, bu makaleyle birlikte iyi bir çerçeve sunacaktır.
Uygulanabilir aksiyon listesi
Transfer dosyası ve hizmet kapasitesi için aşağıdaki adımları kullanabilirsiniz. Buradaki 6–24 aylık işletme planlaması önerisi, her transfer türünde aynı hukuki bekleme süresi olduğu anlamına gelmez.
1. Mevcut IPv4 kullanımınızı ayrıntılı envanterleyin
- Tüm bloklarınızı (hangi RIR’dan geldiğine bakmaksızın) tek bir IPAM veya benzeri envanterde toplayın.
- Her subnet için doluluk oranlarını ve atanmamış IP sayısını çıkarın.
- Kullanılmıyor görünen adreslerde DNS, firewall, müşteri ve izleme bağımlılıklarını doğrulayın; kontrollü bırakma sürecinden sonra yeniden atayın.
2. 12–24 aylık büyüme senaryosu hazırlayın
- Satış, pazarlama ve ürün ekipleriyle konuşup gerçekçi bir müşteri büyüme eğrisi çıkarın.
- Yeni data center, ülke açılımı, büyük kampanyalar gibi adres ihtiyacını zıplatabilecek projeleri listeleyin.
- Bu büyümenin IPv4 ve IPv6 üzerindeki etkisini ayrı ayrı modelleyin.
3. IPv6’yı devreye alabileceğiniz alanları belirleyin
- İç servisler ve mikro servis trafiğinde IPv6 kullanımı için bir pilot planı çıkarın.
- IPv4 erişimi gereken web servislerinde IPv6 desteğini test ederek dual-stack seçeneğini değerlendirin.
- Uygulama loglarınızda IPv6 adreslerinin düzgün işlendiğinden emin olun.
4. Tutarlı bir kullanım ve belge dosyası hazırlayın
- IP tahsis ve kullanım kararlarının arkasındaki mantığı kısa dokümanlarla kayıt altına alın.
- CRM, faturalama ve ağ envanter verilerini mümkün olduğunca bir araya getirin.
- Olası bir ARIN ihtiyaç değerlendirmesinde, “neden bu kadar IP istiyorsunuz?” sorusuna kısa bir özet ve bunu destekleyen doğrulanabilir verilerle yanıt verin.
5. Transfer sürecinde size eşlik edecek teknik partner seçin
Teknik partner seçerken adres planlama, reverse DNS, RPKI ve IPv6 geçişindeki sorumlulukları yazılı netleştirin. Kim başvuruyu, kim kaynak belgelerini, kim BGP ve DNS geçişini yönetecek? Partnerin varlığı ARIN onayını veya daha hızlı tamamlanmayı garanti etmez. DCHost üzerinde proje planlıyorsanız ihtiyaçları ve ilgili ürünün destek kapsamını teklif aşamasında birlikte doğrulayın.
Transfer kararını doğru kapsam ve verilerle verin
ARIN IPv4 transferinde temel karar, işlemin 8.2, 8.3 veya 8.4 kapsamına girdiğini doğru belirlemektir. 2025-2’nin RSA değişikliği ile 2025’te zaten yürürlükte olan ihtiyaç, kaynak ve bekleme listesi kurallarını birbirine karıştırmayın. Başvuru tarihindeki güncel NRPM ve işlem rehberini tekrar kontrol edin.
İyi IP envanteri, gerçekçi projeksiyon ve test edilmiş IPv6 desteği gereksiz kapasite alımını azaltmaya yardımcı olabilir. Sonucu; public IPv4 gereksinimi, hizmet erişimi, teknik işletim yükü ve gerçek teklifler üzerinden değerlendirin. Protokol değişikliği veya politika başlığı tek başına tasarruf kanıtı değildir.
Özetle:
- Mevcut IPv4 kullanımınızı şeffaf biçimde görünür kılın.
- İşlem türünün koşullarını karşılayan kullanım belgelerini ve ayrı bütçe planını hazırlayın.
- Yeni projelerde IPv6 desteğini ve zorunlu IPv4 erişimini birlikte sınayın.
- Gerekiyorsa IPv4 transferi, reverse DNS, RPKI ve e‑posta altyapısı gibi konularda deneyimli bir ekiple birlikte hareket edin.
DCHost üzerinde yeni bir hosting veya sunucu projesi planlıyorsanız mevcut IPv4 ihtiyacınızı, istemci bağımlılıklarınızı ve IPv6 hedefinizi paylaşın. Teklifin IP tahsisi, destek sınırları ve teknik sorumluluklarını netleştirerek başlayın; ARIN transfer onayını hizmet teklifinden ayrı değerlendirin.
