Vaka Analizleri

https://teamarin.net/2018/05/21/advice-migrating-ipv6-isp-environment/

21 Mayıs 2018

ISP Ortamında IPv6'ya Geçiş Önerileri

Mansour Ganji – Kıdemli Ağ Mühendisi

Vodafone Yeni Zelanda IPv6 Vaka Analizi

IPv6'ya geçiş sizi İnternetin bir sonraki aşamasına hazır hale getirecektir. İki yıl önc Vodafone Yeni Zelanda'daki tüm ev kullanıcıları için yerel IPv6 dağıtımı için ana ağ tasarım mühendisi ve proje ekibinin üyesiydim. Bu projenin bir sonucu olarak, IPv6 şu anda ev İnternet kullanıcılarının yaklaşık %80'ine dağıtılıyor. IPv6'yı benimsemenin kaçınılmaz olduğuna inanıyoruz ve uluslararası bir teknoloji şirketi olarak kullanıcılarımıza en son teknolojileri sağlamayı taahhüt ettik.

APNIC Labs'den alınan aşağıdaki grafik, Vodafone’un IPv6 dağıtım oranını gösteriyor ve bunu ülke düzeyindeki IPv6 benimseme oranıyla karşılaştırıyor.

IPv6'yı benimsemek, yeni bir dil öğrenmek gibidir. Mesele bir kelimeyi kaldırıp onu başka bir kelimeyle değiştirmek değildir. Öğrenilecek yeni yapılar ve denenecek şeyleri yapmanın farklı yolları vardır. Doğrudan IPv6 kullanan veya IPv6'yı teslim etmekle meşgul olan kişilerin zihniyetlerinde de yapılacak değişiklikler var. IPv4 ağlarında yerleşik olan ve IPv6 alanında tamamen bağlam dışı olan bazı kavramlar vardır. Örneğin NAT’lama, IPv6 ağlarında en iyi uygulama değildir. Her cihaz, genel olarak yönlendirilebilir bir IPv6 adresine sahip olacaktır. ARP, IPv6 için geçerli olmayan diğer örnektir. Bu farklılıklar anlaşıldıktan sonra, bir protokolü diğeriyle değiştirmek çok daha kolay olacaktır.

Geçiş stratejisi

IPv6 dağıtımında ilk ve belki de en önemli adım, bir geçiş stratejisine karar vermektir. Bir ISS'nin kendi özel kurulumuna, kullanıcı sayısına, IPv4 adres alanı kullanımına vb. göre seçebileceği çok sayıda seçenek vardır. Biz IPv6'yı, ikili yığınlı bir topolojide IPv4'e paralel olarak uygulamaya karar verdik.

Bizim için sonraki adım, IPv6 adreslerini son kullanıcılara nasıl tahsis edeceğimize karar vermekti. Her aboneye ne kadar büyüklükte IP bloğu tahsis edileceğini ve bunun dahili cihazlar tarafından kullanılacak bireysel /64 adreslere nasıl bölüneceğini belirlememiz gerekiyordu.

Daha sonraki ve en önemli adımlardan biri, abonelerimiz için sahip olduğumuz tüm erişim teknolojileriyle IPv6'nın kapsamlı bir şekilde test edilmesiydi. Bu aşamada, belirli türden erişim kurulumlarına özgü birçok zorlukla karşılaştık.

Son adım, IPv6'yı uluslararası ağ geçitleri, DNS, erişim ve ağ platformları gibi farklı ağ yapı taşlarında dağıtmaktı.

IPv6 ve şeffaf önbelleğe alma

IPv6 projemiz sırasında öğrendiğimiz önemli bir ders, şeffaf önbelleğe alma ile ilgilidir. Önbelleğe alma, içeriği kullanıcıya daha yakın bir yerde önbelleğe alarak son kullanıcılara daha iyi bir deneyim sağlamak için birçok hizmet sağlayıcı ve hatta kuruluş tarafından kullanılmaktadır. Şeffaf önbelleğe alma, bu sürecin kullanıcıların bakış açısından şeffaf olmasıdır. Kullanıcı internetten bir parça içerik talep eder ve içerik önbelleğe alma platformları tarafından sunulur, ancak kaynak ve hedef adresler sahtedir, bu nedenle kullanıcı, içeriğin kaynak IP adresiyle birlikte genel internet üzerindeki içeriği alır, ancak içeriğin sunulmasında önbelleği farketmez.

Bu, IPv6 kullanılırken sorunlara neden olabilir, çünkü IPv6 dünyasında, bir paket akışının kaynağı ve hedefi ICMP kullanılarak erişilebilir olmalıdır, böylece bir aygıt IPv6 paketini iletemediğinde, gönderene daha küçük paketler göndermesini bildirir. Ancak artık sahte adresler kullanan paketlerle, ICMP mesajları doğru cihaza ulaşamayacak; ve sonuç olarak bağlantıları koparabilecektir. Soruna geçici bir çözüm, MTU'yu IPv6 standardı tarafından izin verilen minimum 1280 bayt'a düşürmek olabilir. Ancak bizim durumumuzda, dinamik MTU keşfini sürdürmeye ve bunun yerine tüm IPv6 için önbellekleme platformlarını atlamaya karar verdik.

Tavsiyem

İlk başladığınızda, IP'leri tahsis etmeye nasıl başlayacağınıza dair stratejiler belirlemeyi deneyin. Bu olmadan, IPv6 tahsisleri yakında yönetilmesi çok zor olacak karmaşık bir duruma yol açabilir. Ayrıca, olabildiğince IP adresi yönetim platformlarını kullanın. IPv6'yı manuel olarak yönetmek veya elektronik tablolar kullanmak pratik değildir. DNS'ye özellikle dikkat etmek isteyeceksiniz. IPv6 ile her şeyin bir DNS kaydı olmalıdır. İnsanların IPv6 adreslerini hatırlamasını bekleyemezsiniz. Son olarak, ICMP'ye her yerde izin verilmesi çok önemlidir. Aksi takdirde, yol MTU keşfi çalışmayacaktır, bu da zayıf performansa ve hatta iletişim kesilmelerine neden olur.

“Herkesi ipv6 hakkında en az ipv4 hakkında bildikleri kadar öğrenmeye zorlayarak kuruluşunuzdaki ipv6 kültürünü büyütmelisiniz.” Mansour Ganji – Kıdemli Ağ Mühendisi

Size verebileceğim en iyi tavsiye, IPv6'yı hemen dağıtmaya başlamaktır. Süreci başlatmak için daha iyi bir zaman yok. Artık IPv6'yı desteklemeyen ekipman satın almayın. 2018'de her ekipman parçası IPv6 desteğine sahip olmalıdır. Herkesi IPv6 hakkında en azından IPv4 hakkında bildikleri kadar çok şey bilmeye davet ederek kuruluşunuzdaki IPv6 kültürünü büyütmenizi tavsiye ederim. İnsanlara IPv6 ile deney yapmanın eğlenceli yollarını öğretin ve bu onları kullanmaya devam etmeleri için cesaretlendirecektir.

https://teamarin.net/2018/10/23/a-model-for-advancing-ipv6-deployment-in-ren-and-higher-ed-networks/

23 Ekim 2018

REN ve Yüksek Öğrenim Ağlarında IPv6 Dağıtımını Geliştirmek İçin Bir Model

Lola Killey – IPv6 Program Yöneticisi, Merit Network

Merit Network’s IPv6 Hazırlık Programı

Merit Network Inc., Michigan eyaletinde bölgesel bir Araştırma ve Eğitim (REN) ağı işleten, kar amacı gütmeyen, üyelere ait bir kuruluştur. Merit, devlet üniversiteleri olan on iki yönetici üye kuruma sahiptir. Merit Network Inc. üyelerine internet servis sağlayıcısı olarak hizmet eder ve onlara IPv4 ve IPv6 adresleri sağlar.

Ekim 2017'de Merit, üyelerinin IPv4 adres kullanımlarını değerlendirdi ve yönetici üyelerin birçoğunun mevcut büyüme oranlarını sürdürmeleri halinde beş yıl içinde IPv4 adreslerinin tükenebileceğini belirledi. Merit, bu sonuçları yönetim kurulu üyelerine sundu ve kampüs ağlarında IPv6 dağıtımına başlamalarına veya ilerletmelerine yardımcı olacak bir program önerdi. Merit’in yönetim kurulu üyelerini temsil eden on iki CIO’nun tümü, uygun finansmanla birlikte IPv6 Hazırlık Programının oluşturulmasını onayladı.

IPv6 dağıtımı için geleneksel yaklaşım, ağ mühendislerinin IPv6 geçiş gecikmesi veya acil ağ performansı gereksinimlerini karşılamak için dağıtım stratejilerinin sorumluluğunu üstlenmesi olmuştur.

IPv6 geçişini geciktirme birçok nedenden ötürü galip geldi, ancak listenin başında uzman personel eksikliği ve uzun vadeli bir dağıtım stratejisine yatırım yapacak bütçeye sahip olmama yer alıyordu, bunların her ikisi de üst düzey BT yönetiminin yokluğuna işaret ediyor. Merit'in programı, BT personeli, liderlik eğitimi ve IPv6 dağıtım etkinlikleri için finansman ve CIO onayına sahip benzersiz bir yaklaşım kullanır. Sonuç olarak, Merit’in programı, geleneksel IPv6 dağıtımını engelleyen hususları- eğitim ve kampüs BT proje önceliklerini - doğrudan ele alır.

IPv6 Hazırlık Programı, IPv6 dağıtımını teşvik etmede üç yönlü yaklaşımı olarak eğitim, rehberlik ve topluluk oluşturmayı kullanır. Program, ağ uzmanlığı ve operasyonel katılımın sayısız düzeyi için bir eğitim müfredatı oluşturuyor. Müfredat, yönlendirme, adresleme, güvenlik, geçiş planlama, DNS, uygulamalar ve diğer konulara derinlemesine bir bakış sağlayan ağ mühendisleri ve sistem yöneticileri için dört günlük bir teknik eğitim dersi içerir. Eğitim müfredatı, CIO BT yöneticileri, BT kıdemli liderleri, BT yöneticileri ve yardım masası ekipleri için dersler sunar.

Program, kampüs teknoloji ekiplerinin kendi IPv6 dağıtım planlarını geliştirmek için kullanılabilecek ve mevcut IPv6 dağıtımlarını belgelemelerine yardımcı olacak bir değerlendirme kılavuzu oluşturdu. Merit’in kıdemli ağ mühendisleri, değerlendirmelerinde kampüs teknoloji ekipleriyle birlikte çalışacak ve yüksek öğrenim topluluğunda en iyi uygulama bilgilerini sağlayacaktır.

Program bilgilendirici atölye çalışmaları ve konferans oturumları sağladı ve eğitim ve destek topluluğunu oluşturmak için planlanmış eğitim sınıfları, daha fazla konferans oturumu ve üç ayda bir toplantılar içeriyor. Bu etkinlikler, eğitimde öğrenilen bilgileri pekiştirecek, aynı zamanda uyum ve kampüs IPv6 dağıtımı için bir bilgi tabanı oluşturacaktır. Merit'in yüksek öğretim üyelerinin birbirine benzer ve ilgili sorunları vardır, bu nedenle IPv6 teknolojisi ve dağıtımında Merit yönetici üye topluluğu oluşturmak, dağıtım başarıları için önemlidir.

Merit’in IPv6 Hazırlık Programı, Aralık 2019’da tamamlanacak iki yıllık bir pilot programdır. Merit, programın, ağlarında IPv6 dağıtımını teşvik etmek ve ilerletmek için yüksek öğretim ve REN toplulukları için bir model görevi göreceğini beklemektedir. Önümüzdeki yıl geliştikçe bu program hakkında daha fazla şey paylaşmayı dört gözle bekliyorum.

https://www.mythic-beasts.com/article/about

8 Temmuz 2020

Yalın IPv6 Barındırmayı Nasıl Gerçekleştiriyoruz?

Pete Stevens - Mythic Beasts

Mythic Beasts IPv6 Vaka Analizi

Mythic Beasts’in yalın IPv6 barındırma hizmeti sunmaya başlamasının üzerinden neredeyse beş yıl geçti ve hevesli erken benimseyenler için ilginç bir proje olarak başlayan çalışma çoğu barındırma gereksinimimiz için varsayılan haline geldi.

Yıllar içinde bunu mümkün kılan birkaç şey değişti:

·         SNI (Server Name Indication -  Sunucu Adı Göstergesi) desteği olmayan web tarayıcısı bulunan son önemli işletim sistemi Windows XP’nin kullanım ömrünün sona ermesi. SNI yalın IPv6 istemcilerine şifreli bağlantıları proxy üzerinden göndermemizi mümkün kılmaktadır.

·         Güvenli hizmetlerin yaygın olarak benimsenmesi. Bu, kendi proxy özelliklerine sahip olmayan (POP3 veya IMAP gibi) protokollerin SNI sayesinde şifrelenmiş şekilde proxy üzerinden gönderilebilmesini sağlamaktadır.

·         SSH port yönlendirme (port forwarder) gibi barındırma hizmetlerimizdeki gelişmeler.

Bu gönderi, yalnızca IPv6 barındırmayı nasıl gerçeğe dönüştürdüğümüzün hızlı bir özetini veriyor.

Bayt’ları almak

Yalın IPv6 barındırma sunucusunun halen daha yalın IPv4 istemcilerle konuşması gerektiği gerçeğinden kaçış yoktur, ancak artık hemen hemen tüm yaygın senaryolarda bunu yapmak için iyi bir çözüm var.

Web trafiği

Bu en yaygın gereksinimdir ve IPv4’den IPv6’ya proxy sunucumuz tarafından işlenebildiği için muhtemelen en kolay olanıdır. Proxy, çeşitli protokoller için trafiği kabul eden ve bunu yalın IPv6 sunucuya ileten hem IPv4 hem de IPv6 adreslerine sahip bir sunucu kümesidir.

Barındırılan web sitenin DNS’i, proxy.mythic-beasts.com'a ANAME veya CNAME kaydı aracılığıyla proxy sunucularımızı işaret etmektedir.

HTTP 1.1 protokolü bir IP adresi üzerinden birden çok web sitesini desteklemek üzere tasarlandığından şifrelenmemiş HTTP trafiğin proxy sunucu üzerinden gönderilmesi kolaydır.

Artık her yerde bulunan SNI desteği sayesinde HTTPS'nin de proxy sunucu üzerinden gönderilmesi kolaydır.

Proxy sunucumuz orijinal istemcinin IP adresini proxy'li bir bağlantı üzerinden iletmenin standart bir yolu olan proxy protokolünü de destekler. Proxy protokolü desteği artık NGINX ve Apache'nin standart bir özelliğidir.

IPv6 trafiği, proxy üzerinden IPv4 trafiğiyle aynı yolu izleyebilir (yukarıda gösterildiği gibi) veya web sitesi için AAAA kayıtlarını proxy sunucu yerine sunucuya işaret edecek şekilde ayarlayarak doğrudan barındırma sunucusuna yönlendirilebilir.

Bu, IPv6 trafiği için biraz daha doğrudan bir yol sağlar, ancak özellikle proxy protokolü kullanıyorsanız, sunucudaki yapılandırmayı biraz daha karmaşık hale getirebilir.

IMAP ve POP3

Bunların her ikisi de SNI sayesinde güvenli formlarında (IMAPS ve POP3S) proxy sunucu üzerinden kullanılabilir ve ne iyi ki bu güvenli varyantlar artık tüm popüler e-posta istemcileri için varsayılan seçimdir.

SSH

Müşterilerimiz sunucularını genellikle SSH aracılığıyla yönetmek ister ve her zaman IPv6 özellikli bir ağdan bağlanacaklarını garanti edemezler. SSH protokolü TLS / SSL üzerine kurulmamıştır, bu nedenle SNI desteği ve kendine ait eşdeğer özellikleri yoktur.

IPv4 adresine sahip bir ana bilgisayardan tüm sanal sunuculara ve Raspberry Pi sunucularına bir bağlantı noktası yönlendirme (port-forward) sağlayarak bu sorunu aşıyoruz. Böylece müşteriler standart olmayan bir bağlantı noktasındaki farklı bir ana bilgisayarla bağlantı kurabilir ve 22 numaralı bağlantı noktasındaki IPv6 sunucusuna iletilir. Ana bilgisayar ve bağlantı noktasının ayrıntıları müşteri kontrol panelimizde bulunabilir.

SMTP

SMTP biraz gariptir. İki yaygın senaryoda kullanılır:

1. "Gönderim", son kullanıcı istemcisinin kimliği doğrulanmış SMTP kullanarak giden postayı göndermesi

2. E-postanın sunucudan sunucuya teslimi.

Ortak kullanımda birden çok bağlantı noktası vardır:

·         25 - sunucudan sunucuya e-posta için standart bağlantı noktası

·         465 - SSL üzerinden SMTP için bir bağlantı noktası

·         587 - standart SMTP gönderim bağlantı noktası

Bağlantı noktası 25, bağlantı sırasında SSL / TLS kullanmaz, ancak STARTTLS komutu ile güvenli bir bağlantıya yükseltilebilir, bu SNI kullanılarak proxy yapılamayacağı anlamına gelir.

465 numaralı bağlantı noktasının, IANA tarafından güvenli SMTP için tahsis edilmiş, daha sonra STARTTLS lehine iptal edilmiş ve farklı bir hizmete tahsis edilmiş ve ardından RFC 8314 tarafından güvenli SMTP gönderimi için yeniden etkinleştirilmiş olan karışık bir geçmişi vardır. 465 numaralı bağlantı noktası proxy'miz tarafından desteklenir ve SMTP gönderimi için iyi bir seçimdir.

587 numaralı bağlantı noktası, geçmişte STARTTLS ile yalın SMTP (RFC 2476) idi, ancak SNI sayesinde proxy uygulanabilen varsayılan olarak SSL'ye (RFC 8314) taşınıyor. Proxy'miz, 587 numaralı bağlantı noktası trafiğinin şifrelenmiş olduğunu varsayar (çünkü değilse yararlı hiçbir şey yapamaz) ve STARTTLS yerine SSL / TLS kullanmanız koşuluyla SMTP gönderimi için de kullanılabilir.

Sunucudan sunucuya iletişimde, gelen postayı işlemek için çift yığınlı MX sunucularımızı kullanmak mümkündür.

Bu, en yüksek öncelikli MX kaydının yalnızca IPv6 sunucusuna ve ardından daha düşük öncelikli bir kaydın MX sunucularımıza işaret etmesi ile yapılabilir. Bu durumda yalın IPv4 sunucuları MX sunucularımıza iletim yapacak ve ardından bunu yalnızca IPv6 sunucunuza aktaracağız.

Bu, gelen postaya bağlantı süresi filtrelemesini yapamayacağınız anlamına geldiğinden mükemmel bir çözüm değildir.

MX sunucularımızın etki alanınız için postayı kabul edecek şekilde yapılandırılması gerekir. Şu anda, e-posta gönderim desteği ile yapılması gerekiyor.

Bayt’ları göndermek

Sunucunuzun yalnızca yalın IPv4 sunuculara giden bağlantılar yapması gerekebilir. Neyse ki bu, NAT64 çözümleyicilerimizi kullanarak basittir. Bunlar, herhangi bir AAAA kaydı olmayan bir ana bilgisayar için bir adres istendiğinde, ana bilgisayarın IPv4 adresiyle eşlenen bir IPv6 adresi sağlayacak olan DNS çözümleyicileridir. IPv6 adresi aslında NAT sunucularımızdan birinde bulunan ve daha sonra trafiği IPv4 adresine iletecek olan bir adrestir.

NAT sunucusunda IPv4 adresleri ile IPv6 adresleri arasında 1: 1 eşleme vardır - IPv6 ile tam 32 bit IPv4 adres alanının eşdeğerini tek bir sunucuya kolayca tahsis edebiliriz!

NAT64 hemen hemen her durumda çok iyi çalışır.

Herhangi bir NAT yapılandırmasında olduğu gibi, diğer kullanıcılarla bir IPv4 adresini paylaşıyorsunuz ve bu, IP tabanlı filtreleme veya hız sınırlama gerçekleştiren web siteler için sorunlara neden olabilir.

Çoğu sağlayıcı gibi, şimdi IPv4 adresleri için ücret alıyoruz, ancak diğer çoğu sağlayıcıdan farklı olarak bu bir vergidir, muhtemelen ödemeye ihtiyacınız yoktur.

Tüm sanal ve özel sunucularımızın yalnızca IPv6 sürümlerini sunuyoruz.

https://teamarin.net/2019/05/10/tier-1-providers-must-offer-ipv6/

10 Mayıs 2019

Tier 1 Sağlayıcılar IPv6 Sunmalıdır

Kevin Pack – Kıdemli Mühendis, Küresel IP Ağı, NTT

NTT küresel bir Tier 1 sağlayıcıdır. 100Gb’e kadar IP transit ve DDoS koruma hizmetleri sağlamaktayız. APNIC, ARIN, RIPE NCC ve LACNIC bölgelerinde hizmet vermekteyiz. Ağımız %100 IPv6 ile hizmet vermektedir.

IPv6 bir gerekliliktir

2000 yılından beri IPv6 sağlıyoruz. IPv6 uygulama kararı, 20 yıl önce omurga ağımızı işleten operasyon ekibimiz ve yönetimimizden geldi. IPv6'yı benimsememizin iki nedeni var:

1.      IPv4'ün tükenmesi kararın bir bölümünü oluşturdu. NTT’nin küresel varlığı göz önüne alındığında, IPv6'nın benimsenmesi bir seçenekten çok bir gerekliliktir.

2.      NTT'deki kültür yenilikçi ve sektörde lider olmaktır. IPv6'yı dağıtmak, herkesten önce yapmak istediğimiz bir şeydi.

Aynı provizyon ve işletme

IPv6 üzerinden sağladığımız hizmetler, blackhole routing /128, DDOS hizmetleri, kullanım grafiği vb. dahil olmak üzere IPv4 üzerinden sağladığımız hizmetlerle aynıdır. Esasen, IPv6, ağımız IPv4 ile aynı şekilde sağlanır ve çalıştırılır. Müşterilere bir /127 IP adresi atanır ve eş varsayılan seçeneklerle yapılandırılır. IPv4 ve IPv6 ile müşteriler bizden IPv4 için 600.000 veya IPv6 için 80.000 yönlendirme bilgisi içeren eksiksiz yönlendirme tabloları alabilirler. Veya esasen yalnızca bir varsayılan yol içeren daha küçük bir tablo olan NTT kaynaklı yönlendirme bilgileri almayı seçebilirler. Eğer müşteriler bizden IPv6 istiyorsa, onlara DNS için kolay bir sınır olan /64 veya /48 IP adresi vereceğiz. Erişim kontrol listeleri (ACL'ler), yönlendirme kayıtlarından, RPKI’lardan veya ARIN / LACNIC Whois'den oluşturulur. Bu filtreleri, yalnızca müşterilerin yönlendirme kaydında gönderdikleri nesnelere göre duyurmayı planladıkları şeyleri kabul etmemiz için kullanırız.

Birçok yönden IPv6, IPv4'ten daha kolaydır. Örneğin WAN’lar için /32 IP bloğumuzdan bir /64 IP bloğunu kullanıyoruz. IPv4’de farklı tahsisler için birçok /24 kullanıyoruz. Ayrıca müşterilerin ulaşılamayan güvenli WAN'lar atama seçeneği de vardır. Bizim için IPv6 adresleri IPv4 adreslerinden çok daha kolaydır. Farklı yerlerde /30 IP adresleri ayırmaktansa, /64 IP adresi bloğu ile hepsi atanabiliyor.

Küresel olarak, peering yaptıklarımızın yaklaşık %75'i IPv4 ve IPv6 kullanıyor. ARIN'deki NTT peer’larının %66’sı, RIPE NCC'dekilerin %85’i ve APNIC bölgelerindekilerin %74’ü IPv6 kullanıyor. Ağımızda, IPv6 kullanan ARIN tabanlı BGP müşterileri, RIPE NCC ve APNIC müşterilerinden daha azdır. ARIN'den bir IPv6 tahsisi almanın ne kadar kolay olduğu göz önüne alındığında, şirketler en azından gelecek için test etmek için ağlarında bunu etkinleştirmelidir.

Yol boyunca engeller

Karşılaştığımız en büyük engel, donanım satıcılarımızla ilgili yazılım sorunlarıydı. Diğer bir engel, NTTCOM yönlendirme kaydına IPv6 eklemenin hemen yapılmamasıydı. Birkaç ay boyunca manuel olarak yaptık ve sonra otomatik hale getirildi. Şimdi /48 yönlendirme nesnenizi gönderiyorsunuz ve yönlendiricilerimiz her gün akşam 21: 00'da güncelleniyor.

Çalışanları, engellerin aşılmasına yardımcı olmak için deneyimlerini paylaşmaya teşvik ediyoruz. Gruplar arası iletişim önemlidir. Müşteri tarafı bir sorun görürse, omurga tarafı bunun nasıl düzeltileceğini veya bunun üzerinden nasıl geçileceğini açıklayabilir. Ayrıca, nasıl yapılandırılacağı ve daha fazlası dahil olmak üzere IPv6 ile ilgili belgelere sahip geniş bir dahili wiki sitemiz var.

Tier 1 Sağlayıcılar IPv6 Sunmalıdır

Küresel bir internet sağlayıcısı olarak, müşterilerimize IPv6'yı sunmamız zorunludur. Tier 1 sağlayıcıların başka seçeneği yoktur. Müşterilerimiz IPv6'yı talep ediyor ve bu onu gerekli kılıyor. IPv6 aynı zamanda peer’larımızla olan ilişkimizin önemli bir parçasıdır. Bizim yapmamız gerektiği kadar onlar da yapmak zorundalar.

Benim bakış açıma göre, IPv6 dağıtımı kolay ve basittir. Örneğin, IPv4 önekleri için birden fazla yönlendirme bilgisi kaydetmek yerine, sadece /32 IP adresinizi kaydetmeniz gerekir ve biz otomatik olarak /48 adres bloğuna kadar kabul ederiz. Bu tamamen aynı şey. BGP aynıdır. Yönlendirme kaydı aynıdır. RPKI aynıdır. Tek fark, görünüşüdür.

https://teamarin.net/2019/02/04/demand-for-ipv6-warrants-development-efforts/

4 Şubat 2019

IPv6 Geliştirme Çabaları

Marc Aeberhard, VoIP Ürün Müdürü, Patton

Patton IPv6 Vaka Analizi

Patton IPv6'nın geldiğini gördü, bu yüzden şirketin buna hazır olması gerektiğini biliyorduk. IP üzerinden Ses (VoIP) ağ geçitleri ve eSBC'ler, ethernet uzantı çözümleri ve kablosuz yönlendiriciler için bir ağ ekipmanı üreticisiyiz. Uzmanlığımız, eski zaman bölmeli çoklama (TDM) ve seri sistemleri yeni nesil, IP tabanlı ses, veri ve multimedya teknolojileriyle birbirine bağlamaktır. Patton, VoIP müşteri tarafı ekipmanı işletim sisteminde ve donanım platformlarında IPv6'yı destekler. Şirket, 2011 yılında IPv6'yı destekleyecek donanımlar tasarlamaya başladı. Takip eden yıllarda, pazar talebinin kabiliyetlerde yetişmesini bekledik. Nihayet 2018'de, kurumsal ve taşıyıcı pazarlar IPv6 desteğini tamamlamak için gerekli geliştirme çabalarını garanti etmek için talebi artırdı. Küçük ve orta ölçekli işletmelere (KOBİ) hizmet veren birlikte çalıştığımız operatörlerin çoğu, ağlarında IPv6'yı benimsemeye başladı.

Başlangıç ​​olarak, mühendislik ekibi yapmak istedikleri ile Patton’un IPv6 stratejisinde işlerin nerede olduğu arasındaki boşlukları belirlemek için adım adım bir süreç geliştirdi. Geliştiriciler özellikleri, işlevleri, hizmetleri ve uygulamaları listeledi. Tedarik zincirindeki geçiş sorunlarını ele alabilecek ve nihai IPv6 planımızı tamamlamamızı sağlayabilecek mevcut unsurları değerlendirdiler. Süreç şuna çok benziyordu:

·        Geliştirme ortamı oluşturun: araçlar, test laboratuvarı, test ekipmanı vb.

·        Şartname Aşaması:

o   Minimum uygulanabilir ürünü, özellik yol haritasını, geliştirme aşamalarını, sürüm döngülerini belirleyin

o   Ağ topolojisini belirleyin

o   Cihaz yönetimi (yerel konfigürasyon)

o   Cihaz yönetimi hizmetleri (uzaktan yönetim, AAA, dosya yönetimi vb.)

o   IPv6 özellikleri / hizmetleri (yönlendirme, DHCPv6, IPv6 üzerinden DNS ve AAAA kaydı işleme)

o   Uygulamalar

·        Operasyonlarla İlgili Endişeleri Belirleyin

o   IPv6 geçiş mekanizmaları (ikili-yığın, NAT64, DNS64, 464XLAT, vb.)

o   IPv6 dönüşüm mekanizmaları (IPv4 <->IPv6)

·        Dağıtım kurulumu ve araçları

o   Aşamalandırma - dağıtım doğrulama, özellik testi, stres testi, sorun toplama

o   Üretim ortamı

Bugüne kadar, Patton IPv6 üzerinden gerekli tüm fonksiyonları desteklemektedir: SIP, DHCPv6, erişim kontrol listesi (ACL), alan adı sunucusu (DNS) istemcisi, SSH ve Telnet erişimi.

Patton, bulut hizmetini IPv6'yı desteklemek için özel olarak tasarladı.Bazı taşıyıcı müşterilerimiz, kurumsal oturum sınır denetleyicileri (eSBC) ve VoIP ağ geçitleri dahil olmak üzere, Patton VoIP müşteri tarafı cihazları üzerinde IPv6 dağıttı.

https://teamarin.net/2019/05/15/library-framework-setup-for-ipv6/

15 Mayıs 2019

Kütüphane IPv6 Kurulumu

Aaron G. Lusk, Ağ sistem Mühendisi, San Joaquin Valley Library System

San Joaquin Valley Kütüphane Sistemi IPv6 Vaka Analizi

San Joaquin Valley Kütüphane Sistemi (SJVLS) merkezi Kaliforniya'da bulunan bir ortak yetkili kurumdur ve biz IPv6'ya hazırız. Eyaletteki halk kütüphanelerinin yaklaşık% 10'u ortak bir ağa bağlı. Tüm ağ, üç ağ mühendisi, üç kütüphaneci ve bir yönetici tarafından yönetilmektedir. Bağlantımızı California’nın eyalet çapındaki eğitim ağı CENIC’den alıyoruz. Bize ağlarına doğru yedekli çift yığınlı bağlantılar sağlarlar. IPv6’ya sahip sekiz CENIC üyesinden biriyiz. Söyleyebileceğimiz kadarıyla, Kaliforniya'da IPv6 bağlantısı olan tek halk kütüphanesi sistemiyiz.

Bu CENIC merkez site haritasında görebileceğiniz gibi, sol üstte, fre-dis-sw-1'e bağlı on kütüphaneyiz. Ayrıca SJVLS ağ haritasını da görüntüleyebilirsiniz. Şubeleri IPv6 üzerinden izliyoruz, ve ana web sitemiz IPv6: www.sjvls.org

IPv6'yı dağıtmamızdaki en büyük motivasyon, ağımızı her gün kullanan halkın İnternet'in tamamına erişebilmesini sağlamaktı. IPv4 bağlantısını yakın zamanda kapatmayı planlamıyoruz ve o güne kadar her iki protokolü de çalıştıracağız.

Bir şirketin herkesin erişmek istediği yeni bir hizmeti yalnızca IPv6 üzerinden başlattığı bir gün gelecek; o güne hazır olmak ve gelecekte bununla mücadele etmek zorunda kalmamak istedik.

ARIN'den aldığımız IPv6 bloğumuz 2607: f380: 8C9 :: / 48'dir. IPv6 sunumumuzu Haziran 2017'de, hub sitemizden dokuzunu ikili yığın IPv6’ya geçirerek başlattık. Yirmi iki ay sonra 110 şubeden 84'ü ikili yığın IPv6’ya geçti. Altı yıl önce tüm ağ, Frame to ATM, iki DS3 ve tek bir 200Mbps İnternet bağlantısı üzerindeydi. Şimdi, 9 Gb/s birleşik iş hacmine sahip on adet ikili yığın İnternet bağlantısına sahibiz.

Ağımızdan çıkan trafiğin yaklaşık% 50'si IPv6 üzerindendir. Yalnızca YouTube'dan haftada yaklaşık 1 TB çekiyoruz ve bu trafiğin çoğu IPv6 üzerinden gerçekleşiyor. Hub siteleri arasındaki çekirdek ağımızda yaklaşık %98 IPv6 trafiğine sahibiz.

Şu anda en büyük engelimiz, kablosuz bulut sağlayıcımızın yeterli IPv6 desteğinin olmaması. Ne yazık ki, halk yalnızca kablosuz bağlantı ile bağlandığında IPv4 alabilir. SSID'lerimizden biri, köprü modunda olduğu için ikili-yığın IPv6 sahiptir, ancak bu SSID yalnızca personel içindir. Kablosuz ağımızın arkasındaki ağ ikili-yığın IPv6 sahiptir, bu nedenle bulut sağlayıcımız IPv6 desteği sağladığında hazır olacağız.

Tavsiyem

IPv6'yı her yerde ve her şeyde aynı anda etkinleştirmek konusunda endişelenmeyin; her şubede ve her hizmette IPv6'yı etkinleştirmemiz hala birkaç yılımızı alacak. Herkesin atması gereken ilk adım, IPv6 adreslerini ISS'lerinden veya doğrudan ARIN'den almaktır. Ardından bir adres planı oluşturun. Adres planınızı tamamladığınızda, elinizden geldiğince önceden hazırlık yapın.

Ağımızda IPv6'yı etkinleştirmeden önce, güvenlik duvarlarımızın, Active Directory ve DNS'in bu yeni IP adreslerini bildiğinden emin olduk. Bu, her şube için yeni IPv6 güvenlik duvarı kuralları oluşturmayı ve şube hazır olana kadar bu kuralları devre dışı bırakmayı içeriyordu. Tek başına bu adım bile bize sahada çok zaman kazandırdı. Ardından, IPv6'yı birkaç konumda veya yalıtılmış bir hizmette etkinleştirerek bir pilot program yapmayı düşünün. Artık IPv6 için çerçeve kurulumuna sahip olduğumuza göre, IPv6'yı bir şubeye dağıtmak, bir yönlendiriciyi değiştirmek ve birkaç ayarı güncellemek kadar basit.

Sprint Corporation, bir Amerikan telekomünikasyon şirketidir. 1 Nisan 2020'de T-Mobile US ile birleşmeden önce, 30 Haziran 2019 itibarıyla 54,3 milyon müşteriye hizmet veren ABD'deki dördüncü en büyük mobil şebeke operatörüydü. Şirket ayrıca kablosuz ses, mesajlaşma ve geniş bant da sunuyordu.

2 Ekim 2020

Sprint’in IPv6 Geçiş Mekanizmaları Yolculuğu

Ben Bittfield – IPv6 Ağ Uzmanı, Sprint

Sprint, son on yılda kablosuz ağlardaki başlıca tüm IP adresleme ve IPv6 geçiş tekniklerini uyguladı. Genel (public) IPv4, carrier-grade NAT ile özel (Private) IPv4, ikili yığın (dual stack) IPv4v6 (hem genel hem özel IPv4) ve son olarak NAT64 ile sadece-IPv6 (IPv6-only).

Sprint’in 55 milyon kullanıcılı kablosuz ağı için IPv4 uzun vadede sürdürülebilir değildi. Sprint’in yeterli genel IPv4 adresi yoktu ve RFC 1918 özel IP adresleme ihtiyaç olan on milyonlarca IP adresini karşılamıyordu. IPv6 geçiş mekanizmaları yıllar içinde olgunlaştıkça stratejilerimizde değişmiş olabilir ama aadece-IPv6’nın (IPv6-only) IP adreslemenin nihai hedefi olacağı uzun zamandır biliniyordu.

ABD’deki diğer tüm kablosuz taşıyıcılar carrier-grade NAT’a geçerken; Sprint 2000’li yılların sonlarında tüm müşteri cihazlarına internette yönlendirilebilir dinamik IPv4 adresleri atamaya devam ediyordu. Bir mobil işletmeci için bu çok daha az maliyetliydi.

Akıllı telefonlar kullanılmaya başlandıktan sonra ve IP adreslerin sürekli bağlantılı olarak tahsisli olması gerektiğinden, Sprint’in acilen farklı bir IP adresleme kullanması zorunluydu. Çünkü her bir telefonda genel IPv4 kullanılması artık sürdürülebilir değildi. Tam bu zamanda yani 2010’lu yılların başında kablosuz taşıyıcılarda IPv6 kullanımı oldukça yeniydi ve sadece Verizon Kablosuz bunu Kuzey Amerika’daki taşıyıcılar arasında uygulamaya geçirmişti. Oyunun sonunun IPv6 olduğunu bilmekle beraber, Sprint acil bir çözüm üretmeliydi ve az riskli ve maliyetli bir çözüm olan carrier-grade Nat IPv4 (CGN) uygulamasına geçildi. CGN uygulanmasının müşteriler üzerindeki etkisi çok azdı çünkü Sprint; CGN uygulamaya en son geçen kablosuz taşıyıcılardan birisiydi.

En başta, IPv6 adresleme yeniydi, büyüktü ve korkutucuydu, bu sebeple IPv6’yı ortalama bir mühendis için daha anlaşılır hale getirmek için ne yapılabiliyorsa o kadar iyi olacaktı.

Diğer geçiş yaklaşımlarının ve durum çalışmalarının tavsiye ettiği gibi Sprint çalışmaya şebekesinin omurgasından başladı. Bu durum; LTE ağ elemanlarından internete doğru kablosuz IP omurga ağının ikili yığın (dual stack) olmasını gerektiriyordu. Sprint bir kere daha basitlik için ikili yığın yöntemini seçti ve mevcut VLAN’ları yeniden kullanarak işleri kolaylaştırdı.

IPv6 çabamızda “Katman 2 değişikliği yok” şeklinde resmi olmayan bir sloganımız vardı. Mevcut ağ mimarisinde sadece IPv6 için yeni VLAN’lar oluşturmanın bir anlamı yoktu çünkü ağ geçidinden internete veya hizmet platformlarına doğru zaten bağlantı yolu vardı.

Tam bu dönemlerde; mobil kablosuz taşıyıcılarda sadece-IPv6 + NAT64 uygulanmasına başlanmamıştı, bu sebeple IPv6 geçiş tartışmaları ikili yığın IPv4v6 üzerine odaklanmıştı. Nihai hedefin sadece-IPv6 olduğu bilinmekle beraber, 464XLAT (RFC 6877) üzerinden sadece-IPv6 yeniydi ve daha kanıtlanmamıştı. Bu sebeple Sprint’in ilk tercihi daha az riskli olan ikili yığın IPv4v6 oldu.

İkili yığın IPv4v6 ile hem IPv4 hem de IPv6 adresleri aynı anda müşteri cihazlarına tanımlanıyordu. Cihazın karşı taraf internet bağlantısına DNS ile karar veriliyordu. Genellikle eğer web sitesinin bir IPv6 AAAA kaydı var ise cihaz içerik için IPv6 kullanılıyordu. Eğer bir AAAA kaydı yok ise ve DNS tarafından A kaydı cevabı dönülürse IPv4 kullanılıyordu. Genel konsept bu olsa da, bu Happy Eyeballs (RFC 6555)[1] algoritmasının basitleştirilmiş haliydi. Böylece çoğu durumda; ikili yığın IPv4v6 cihazı IPv6 içeriği mevcut ise IPv6 ip adresi ile bağlantıyı tercih etmekteydi. Bu da trafiğin kabaca 70/30 oranında IPv6 lehine bölünmesi ile sonuçlandı çünkü Google, YouTube, Facebook, Netflix vb. gibi yüksek miktarda içeriğin hepsi IPv6 etkindi.

Geriye dönüp bakıldığında, halen üretici nedenli sorunlardan dolayı önemli gecikmeler olduğu için; ikili yığın IPv4v6 akıllıca bir karardı. Sprint başlangıçta ikili yığın IPv4v6 uyumlu cihazlarını piyasaya sürmeyi 2013 yılında hedeflemişti ancak, üretici sorunları nedeniyle tam iki yıl ertelendi.

Tüm kusurlar veya gecikmeler için, Sprint ülke çapında tam hazırlık sağlanana kadar bekledi böylece kablosuz müşteriler ülke genelinde aynı deneyime ve IP adresi türüne sahip oldu. Nihayet tüm ağ ilişkili sorunlar çözüldükten sonra, Happy Eyeballs'un dayanıklılığı sayesinde en az müşteri sorunu olan veya hiç olmayan yeni çıkan telefon modellerinde ikili yığın IPv4v6 başlatıldı.

İkili yığın IPv4v6'yı başarıyla başlattıktan sonra Sprint, mühendislik çalışmalarını müşteri cihazlarına sadece-IPv6 + NAT64+DNS64 uygulamaya odakladı. Bu zamana kadar, T-Mobile ve Orange Polonya gibi diğer büyük operatörler 464XLAT üzerinden sadece-IPv6+NAT64+DNS64’ün büyük ölçekte uygulanmasına sahipti, diğer taşıyıcılarda bu yönde ilerliyordu.

464XLAT, NAT64 + DNS64 içeren yeni bir çözümdür, ancak aynı zamanda, sabit kodlanmış IPv4 adreslerine "sahte" bir IPv4 adresi aracılığıyla erişilebilirlik sağlamak için esasen kullanıcı son cihazlarında (bu durumda Android ve iOS) bir NAT46 istemci çevirmeni içerir. Bu DNS'nin devreye girmediği ve DNS64'ün eski IPv4 adreslemesine çeviriyi gerçekleştiremediği durumlar için uygulamaya / işletim sistemine sunulur.

Birkaç istisna dışında, Temmuz 2017'den sonra piyasaya sürülen tüm Sprint Android telefon modelleri yalnızca IPv6 kullanıyordu.

Sprint, sahadaki müşteri cihazlarını etkilemek istemediğinden, yalnız-IPv6'yı sadece yeni piyasaya sürülen telefon modellerinde uyguladı ve IPv4 / IPv4v6 dönüşümü için telefon upgrade’lerine güveniyordu. Birkaç ay içinde IPv4 adreslemede bir iyileşme görmeye başladık. IPv4 adreslemesinin zirvesine Nisan 2018'de ulaşıldı ve Aralık 2018'in sonlarında IPv6 çoğunluk oldu.

Ayrıca, Internet Society’nin "World IPv6 Launch"[2] web sitesine göre, Sprint kablosuzdan Google, Facebook vb. gibi IPv6 etkin içeriğe giden trafiğin yaklaşık% 90'ı IPv6'dır.

IPv6’nın benimsenmesi ağaç dikmek gibidir. Ağaç dikmenin en iyi zamanı 20 yıl önceydi. İkinci en iyi zaman ise şimdi. - Ben Bittfield, IPv6 Ağ Uzmanı, Sprint.

https://teamarin.net/2019/06/12/practical-steps-to-accelerate-ipv6-adoption/

12 Haziran 2019

IPv6 Geçişini Hızlandırmak İçin Pratik Adımlar

Matthew Wilder – Kıdemli Mühendis, TELUS

Telus IPv6 Uygulama İncelemesi

TELUS, Kanada'da müşterilerinin yararına IPv6'yı uygun ölçekte dağıtan ilk hizmet sağlayıcıydı. Kanada'daki en büyük telekomünikasyon şirketlerinden biri olan TELUS, 1,9 milyon ev İnternet abonesi ve 9,2 milyon kablosuz aboneye sahiptir. TELUS ev internet müşterilerinin %83'ü IPv6'ya sahiptir ve diğer %17 ise sadece müşteri tarafı cihazlarda (CPE) yazılım yükseltmesine ihtiyaç duymaktadır. Şahsen, IPv6 ile yaklaşık on yıllık deneyimim var ve TELUS'ta IPv6'yı uygulayan çok başarılı bir programın parçası olmaktan memnuniyet duyuyorum. Örnek olarak TELUS'u kullanarak, hizmet sağlayıcıların veya kendi IPv6 planlarını geliştiren kuruluşların IPv6 geçişini hızlandırmak için birkaç pratik adımı nasıl atabilecekleri konusunda size rehberlik edeceğim.

Büyümeye Hazır

TELUS, iki temel nedenden dolayı IPv6'yı uygulamıştır. Birincisi, sistemlerimizi geleceğe hazırlamaya devam etmek ve ikincisi, önümüzdeki yıllarda beklenen büyümeyi sağlamak.  John Curran'ın 2009 yılında bölgedeki kuruluşlara gönderdiği ve onlara yönetici desteğinin nereden geldiğini hatırlamak için harika bir eser olarak IPv4 tükenmesini bildiren mektubum halen geçerli. Bu mektup CEO'm tarafından alındı, notlarla birlikte CIO'muza, ardından CTO'muza iletildi. Bundan sonra omurga ağımızdan başlayıp dışa doğru hareket ederek, yerine oturtmamız gereken büyük kayaları belirlemek için bir program ekibi oluşturduk. Daha sonra hizmetlerimizi dikkate aldık ve zaman çizelgeleri oluşturduk. Bu planlamanın çoğu, IPv4 kıtlığına ilerlediğimiz bilgisine dayanıyordu. İş durumumuzun önemli bir parçası, o zamanlar piyasanın belirsiz bir unsur olması ve bu piyasa belirsizliğine bağlı kalmak istemiyor olmamızdı. Bugünün IPv4 fiyatları göz önüne alındığında, bu doğru karardı.

İnsanların beklemeyebileceği bir şey, IPv6'nın bir esneklik katmanı oluşturmasıdır. Bir içerik barındırıcısının IPv4 kesintisi olup olmadığı veya BGP saldırısı gibi IPv4 ile ilgili bir sorun varsa Iv6 alternatif bir yoldur.

“Gecikmedeki herhangi bir artış TCP verimini azaltır, NAT gecikmesini kaldırması sebebiyle ipv6'dan daha yüksek performans bekleyebilirsiniz. Matthew Wilder – TELUS”

IPv6 ile hem ev içi İnternet hem de mobil cihazlar için bir performans kazancı da vardır. Ev İnternetiniz ve müşteri tarafı cihazınız özel IP'nize bir ağ adresi çevirisi (NAT) işlevine sahiptir. Bu yolda gecikmeye neden olan bir işlem süresi perspektifi maliyeti vardır ve gecikmedeki herhangi bir artış TCP verimini azaltır. NAT gecikmesini kaldırarak, IPv6'dan daha yüksek performans bekleyebilirsiniz.

IPv6’ya Hazırlanmak

TELUS, 2015'ten beri ev İnternet aboneleri için IPv6'yı kullanmaktadır. IPv4 kıtlığı sorunuyla ilgili stresi azaltmak için bir NAT CGN hizmeti de sunmaya başladık. TELUS, kablosuz hizmet için de IPv6 sunmaktadır. Bu, seçmeli şekilde sunulur, bu nedenle bunu kademeli olarak artırıyoruz. Zamanlama açısından IPv6'ya öncelik verdik ve ardından IPv4 NAT'ı üstlendik. IPv6 projemiz birkaç yıl sürdü ve bu süre zarfında sermaye harcamasını ve insan kaynağı kapasitesini belirledik.

Hemen kendimize sorduk - müşteri tarafında IPv6 için ayıracağımız alt ağ öneği (prefix) nedir? Ev İnternet abonelerimiz için /56, kurumsal abonelerimiz için /48 ve mobil abonelerimiz için /64 seçtik. İhtiyaç duyulan IPv6 tahsisi ölçeğini ayarlamamıza yardımcı olan her önek için bir kullanım örneğimiz var.

Kanada'da ulusal bir taşıyıcı olarak kapsayacak geniş bir coğrafyaya sahibiz. Gecikmeyi azaltma çabalarımızın bir kısmı, IP adreslerimizi coğrafyaya eşlemeyi içerir. IP adresi gereksinimlerimize baktığımız için, /32'den /29'a genişleme istemek için ARIN'e geri döndük ve bu değişikliği güvence altına alabildik. Bölge başına ne kadar alana ihtiyaç duyulduğunu belirledik ve bölgeye göre daha küçük hale getirdik, böylece IPv6 bloklarımız için yönlendirmeyi optimize edebildik. /32, /48’in 64.000 veya /56’nın 16.000.000 son kullanıcısını kapsar. Daha sonra sürekli olarak yarım bayt sınırını kullandık (onaltılık karakterler).

“Zengin bir ara bağlantıya sahip olmak istiyorsanız, trafiğinizin küresel olarak değiş tokuş edilebilmesi için eşleme (peering) ilişkilerinizi hepsinin IPv6'nın etkin olduğundan emin olmak için denetleyin. Matthew Wilder – TELUS”

Ardından, IPv6 adres alanımızı peering ve transit ortaklarımıza anons ettik. Zengin bir ara bağlantıya sahip olmak istiyorsanız, trafiğinizin küresel olarak değiş tokuş edilebilmesi için eşleme (peering) ilişkilerinizi hepsinin IPv6'nın etkin olduğundan emin olmak için denetleyin. Bundan sonra IPv6'yı MPLS ağımızdaki tüm uç düğümlerimizde kullanıma sunmaya başladık. Omurga ağ yönlendirmesi işlevsel hale geldiğinde, peering ve transit gibi öğeleri etkinleştirdik. Ardından, DNS gibi paylaşılan altyapıları analiz ettik ve bağımsız hizmetlerimizin her biri için hizmet tasarımını tamamladık: evde İnternet, iş İnternet, sabit hizmetler ve kablosuz hizmetler.

Öğrenme Eğrisi

IPv6'ya uyum sağlamak için büyük bir ISP'nin büyük motorunu yağlamamız sezdik, bu nedenle insanların IPv6 ile gelen değişiklikleri yönetme rolleri için gerekli anlayışı kazanmalarına olanak tanıyan bir öğrenme modülü oluşturduk. Mühendislik ve hizmet tasarımını yapacak çekirdek ekip için hem eğitmen önderliğinde eğitim hem de ağ operasyonlarımızdan, ön saf teknik desteğine kadar herkesin zamanında öğrenmesi için birden fazla e-modül kullandık. Örneğin, BSS, OSS sistemleri ile çalışan BT'de çalışanların IPv6'nın farkında olması gerekir, böylece yapıya aşina olurlar ve ne bekleyeceklerini bilirler.

Olası sorunların önüne geçmek için attığımız diğer önemli adım, önce test ortamında dahili denemeler yapmaktı. Daha sonra, kullanıma başladığımızda, çalışanların hizmetlerini seçtiği ve her şeyin çalıştığından emin olmak için kontrol ettiği kullanıcı dostu bir deneme ile başladık. MTU'ların bozulmadığından ve DNS'ye erişimin çalıştığından emin olduk. Denememizde yakaladığımız bir şey, DNS'nin AAAA kayıtlarıyla yanıt verme yeteneğini tanımlamış olsak da, test siteleri henüz IPv6 üzerinden DNS’ye erişebilirliği etkinleştirmediğimizi gösterdi. Küçük, dahili testlerle başlama ve büyük üretim ölçeğine doğru büyüme yaklaşımımız sayesinde, süreç ilerledikçe potansiyel riskler azaldı.

IPv6'nın uygulanması sorunsuz ve tüketici için farkedilmezdi. Yıllar boyunca çevrimiçi forumlarımızda IPv6'ya ne zaman geçeceğimizi soran müşterilerimize artık kullanılabilir olduğunu söyledik. Bildirimde bulunduğumuz kişilerden biri arkadaş canlısı bir testçi bile oldu, bu yüzden denemek ve gemiye girmek için istekli birini dahil etmek harika bir şeydi.

Pratik Adımlar

TELUS'un IPv6'yı nasıl dağıttığını açıkladığıma göre, aşağıda hizmet sağlayıcıların veya kuruluşların IPv6'nın benimsenmesini hızlandırmak için atabilecekleri bazı pratik adımların kısa bir özeti vardır:

IPv6 Peering & Transit

·         Zengin IPv6 ara bağlantısı bir zorunluluktur

·         Mevcut tüm peering bağlantılarında IPv6'yı etkinleştirin

·         Sürecinizi güncelleyin

·         Transit bağlantılarda IPv6'yı etkinleştirin

·         IPv6 yönlendirme bilgilerinizi anons edin

Ağınızda IPv6

·         Omurga ağınızı aktif edin

·         MPLS ağınız var ise 6PE’yi dikkate alın

·         Uç noktalardan dışarıya doğru yalın IPv6

·         DNS ve diğer paylaşılan altyapılar

·         Hizmetler IPv6 erişiminden yararlanabilir

Hizmet Tasarımı

·         Dikkate alın:

o   Ağ standartları

o   Müşteri tarafı cihazları

o   OSS ve BSS sistemleri

·         Proof of concept

·         Mümkünse Geliştirme (Dev) ve operasyonların (Ops) birleşimi olan DevOps

Azar azar başla ve büyüt

·         İlk başta küçük artışlarla kullanıma sunun

o   Çalışanlarla başlayın, ardından dost müşterileri dahil edin

·         Sorunları erken tespit edin ve iyileştirin

·         Önce küçük ölçekte başarıyı kanıtlayın

·         Ölçeğinizi artırın

TELUS'ta bu süreç, IPv6'nın başarılı bir şekilde kullanıma sunulmasıyla sonuçlandı.

En büyük tavsiyem, kuruluşunuzdaki karar vericilerden IPv6 dağıtımını desteklemek için satın alma konusunda sorun yaşıyorsanız, IPv6 geçişi ile elde edebileceğiniz tüm faydaları geniş bir şekilde inceleyin. Hiçbir şeyi göz ardı etmeyin. Kuruluşunuz için kazanımlar görebileceğiniz fırsatları arayın, tahmin etmemiş olabileceğiniz faydalar vardır. İçinde IPv6 varken ağınız nasıl olacağını hayal edin.

Çalışanlara hizmet vermek için LAN'a sahip büyük bir kuruluşunuz varsa, sürekli olarak ölçeklendirme ve yeniden ölçeklendirme yaptığınız için muhtemelen IPv4 ile devam eden bir mücadelenin içindesiniz. Yeniden numaralandırma zordur, ancak bir IPv6 /64 ile ölçeklendirme son derece faydalıdır.

Uzun vadede, eğer herkes IPv6'ya geçerse, IPv4'ü aşamalı olarak kaldırmaya başlayabilir ve tek bir yığının avantajlarından tekrar faydalanabiliriz. Özetle, IPv6'yı benimsemek kuruluşunuza çeşitli faydalar sağlayacaktır, böylece aşamalı olarak sunma görevini üstlenenler hem kuruluşları hem de müşterileri için kazanımlar elde edeceklerdir.

https://teamarin.net/2018/12/20/agile-dual-stack-approach-to-campus-wide-ipv6-roll-out/

20 Aralık 2018

Çevik İkili - Kampüse Yığın Yaklaşımı - Geniş IPv6 Yayını

Tony Casciano – Ağ Mühendisi, University at Buffalo - SUNY

University at Buffalo IPv6 Vaka Analizi

University at Buffalo, 31.000'den fazla öğrencisi ve 8.600 tam zamanlı çalışanıyla New York Eyalet Üniversitesi (SUNY) sistemindeki en önemli okuldur. 2014 yılında, üst düzey BT liderliğimizin, merkezi BT ve kampüs çevresindeki departmanlardan CIO ve BT direktörlerinin yönlendirmesiyle IPv6 kampüs genelinde bir projeye başladık.

Kesintiyi önlemek

“Çevik ama metodik bir "ikili yığın" yaklaşımı aldık. Amacımız, mevcut IPv4 hizmetlerini kesintiye uğratmadan IPv6 hizmetlerini uygulamaktı.” Tony Casciano – Ağ Mühendisi, University at Buffalo

İlk büyük sunumumuz, o zamanlar daha az hizmeti destekleyen ve büyümeye hazır olan Wi-Fi içindi, bu da onu iyi bir test ortamı haline getirdi. Proje ilerledikçe, mevcut donanım ve yazılım çözümlerimizin yaşam döngüsünü göz önünde bulundurmak zorunda kaldık.

Grup projesi

Bu projede dört yıl boyunca çalışan, iki haftada bir toplanan özel BT ekiplerimiz vardı. Sistem Yöneticilerinden Yazılım Geliştiricilerine, Ağ Mühendislerine ve Masaüstü Destek Personeline kadar farklı alanlardan uzmanları dahil etmek çok önemliydi. BT yöneticilerimiz de bu gruplarla yakından ilgilendi, toplantılara sık sık katıldılar ve proje personeli için öncelikler belirlediler.

“Projenin her büyük adımında, ilerlememizi diğer BT personeline ve kampüs topluluğuna ilettik.” Tony Casciano – Ağ Mühendisi, University at Buffalo

Zaman ver

IPv6'ya hazır olmak, University of Buffalo’nun ağ iletişimi geleceği için büyük bir sigortaydı. IPv6'ya kullanımı arttıkça, yetişmek zorunda kalmayacaktık. Bunu acele şekilde yapmayı hayal bile edemem. Uygulama dönüşümlerini düşünmeden önce IPv6 ekibinin sayısız BT altyapısı sorununu çözmesi 1,5 yıl sürdü. Bu, yabancılar için uzun bir süre gibi görünebilir, ancak dünyanın en büyük anti-virüs sağlayıcısının University of Buffalo’nun IPv6 proje ekibine, tek tek IPv6 adreslerini filtreleyebilen bir anti-virüs yazılımı sürümü sağlaması bir yıl aldı.

Mevcut durum

Bugün, University of Buffalo’nun kurumsal hizmetlerinin neredeyse% 100'ü IPv6 özelliklidir ve University of Buffalo gelecek için konumlandırılmıştır. Yalnızca IPv6 hizmetlerini kullanmaya hazırız ve çok sayıda IP adres alanıyla, Nesnelerin İnterneti için de hazırız.

Ödevini yap

Benzer bir projeye başlayanlara tavsiyem: ödevini yap! Önceden pek çok hazırlık ve öğrenme yapmış olduğumuz için şanslıydık, bu olmasaydı projemiz bu kadar başarılı olamazdı.