Nekaj časa je bilo zatišje tu na go6.si z novicami okrog A+P drafta, a v ozadju potekajo živahne razprave, trenutno je v obdelavi signalizacija. Priznam, nisem si mislil, da je za takšen RFC draft, kot je A+P potrebno toliko dela, razmišljanja, ur in pisanja, pa čeprav se počasi vedno bolj zavedam, da sodelujemo pri precej pomembnem projektu standarda in mehanizma za čimbolj neboleč prehod ISP-jev na IPv6…

Pri signalizaciji zahajamo v slepe ulice, saj vsak odgovor na vprašanje odpre dve novi vprašanji in problematika postaja že dokaj kompleksna. Najprej nas je intuicija zavedla v razmišljanje, da bi kontrolno polje ločili in podatkovnega polja in tako skozi 4in6 tunele med CPE in PRR spuščali samo podatke, signalizacijo pa izvajali preko IPv6 (DHCPv6) z dodatnimi opcijami. Ko je bila ta smer že dokaj dobro raztuhana jo uspe Randy obrniti na glavo z enim samim stavkom “can the transport always reach the other end outside of the tunnel?” Na, zdej pa mamo. Ne, ne more, vsaj v čisto vseh primerih ne. In če ne moremo reči da vedno lahko – potem ne more. V nekem trenutku se mi utrne tudi, da bi bila kontrola več hkratnih 4in6 tunelov na isti CPE preko DHCPv6 preveč kompleksna, da bi bila zadeva smiselna. Ekipa se strinja, back to drawing board.

Trenutno smo se odločili, da bo signalizacija še vedno modificiran DHCPv4 z dodatnimi opcijami “port-range” in “additional-allocation” znotraj tunela, še vedno pa si nismo čisto na jasnem, kako narediti “tunnel establishment” in “tunnel teardown”. Ena od možnosti je poriniti CPE-ju IPv6 naslov PRR-ja in v tem primeru CPE začne tunel, druga možnost je, da je CPE predkonfiguriran za sprejemanje tunelov in PRR začne tunel, tretja možnost je anycasted PRR IPv6 naslov, na katerega CPE naredi tunel (vedno isti naslov), skratka, tu poteka debata in pro-et-contra.

Prav tako se ukvarjamo s specifikacijo in opisom redundance PRR-ja. CARP/VRRP ali anycast? Kako zagotoviti sinhronizacijo vseh baz in stanj med njimi. Vedno več vprašanj je in ure razmišljanja in pisanja kar bežijo. Sedaj razumem, zakaj RFC avtorjev ni več in zakaj se RFC-ji ne množijo kot zajci 🙂

Pripravlja se tudi ena druga zanimiva zadeva, eminentna slovenska podjetja in organizacije so pristopile k projektu izdelave A+P POC-a (proof of concept), kar pomeni, da bomo v bite spravili enostaven port-range router, ki bo CPE-ju dodelil IP s port-rangeom in tako se bodo začeli prvi testi v realnem življenju, ki naj bi prinesel rezultate, katere vse aplikacije ne bodo delale brez dodatnih predelav in dodelav. Cisco bo tudi implementiral neke zametke A+P v svoje eksperimentalne firmware-e, a le naš POC bo tak, kot je treba in tudi iz njega zna nastati uporaben produkt, ki bo pokril precej širši spekter zahtev kot ostali, saj ga bomo implementirali v naslednjih fazah razvoja v celotni specifikaciji in ker sem soavtor RFC drafta ga bomo tudi sproti dodelali, kakor se bo miselnost drafta spreminjala, predvsem bo pa POC vir povratnih informacij, ali zadeve v draftu tudi zares delujejo v realnem življenju, kje so težave in kaj je treba spremeniti. Već o projektu bomo zapisali, ko bo vse uradno potrjeno in se bo projekt začel, do takrat pa moram detajle držati malenkost v megli 🙂

Začetek julija je že in -04 verzija bi že morala biti zunaj za “submission” na IETF, pa nimamo še nič konkretnega zapisanega novega, ker je še preveč vprašanj odprtih. Konec julija je IETF meeting v Stockholmu, upam da se ga bom lahko udeležil. Vse je odvisno od sponzorjev in financ zavoda go6. Nekaj članov že imamo, želel pa bi, da se še več organizacij in podjetij opogumi vsaj za bronasto članstvo in s tem nekaj prispevajo k našem prizadevanju za boljši digitalni jutri.

Jan Žorž

Vaš IP naslov (ali ste na IPv6 ?):
3.144.99.134

Comments(0)