A+P approach je IETF uradno uvrstil med nekaj podobnih predlogov, ki se ukvarjajo z začasno rešitvijo souporabe IPv4 naslovov med končnimi uporabniki ( Sharing of an IPv4 Address (shara) BOF )
http://trac.tools.ietf.org/bof/trac/wiki/SHARABOF
https://www.ietf.org/mailman/listinfo/shara
/jan
NRO (Number Resource Organisation) je objavila podatek, da je po njihovih statistikah rast IPv6 omrežij dosegla 300% v zadnjih dveh letih. NRO je organizacija, ki združuje vseh 5 RiR-ov.
http://forum.go6.si/index.php?topic=17.0
Tukaj bom dajal gor verzije A+P approach draftov, prosil bi za kaksen komentar.
/jan
go6.si je vstopil v proces so-oblikovanja RFC drafta A+P approach, avtorjev Randy Bush, Olaf Maennel, Nokia, T-mobile, Roma university, Columbia university in še nekaj eminentnih imen. Trenutno potekajo dogovori, da bi mojo malenkost zapisali med avtorje, zaenkrat smo pa prišli med “close collaboration”. -> Click “Read the article”
Včeraj sem na INFOSEKu v Novi Gorici odbrzel skozi svoje predavanje o IPv6, predvidenih problemih pri tranziciji ter zakaj nam bo zmanjkalo IPv4 naslovov. Opazil sem, da se je pojavila v dvorani zgroženost in mnenje se je začelo spreminjati iz “to se meni ne more zgoditi in me ne zanima” v “ojoj, imamo problem…”. Načeloma rabim za to prezentacijo kakšno uro in pol do dve uri, na konferenci sem pa imel na voljo samo 30 minut, tako da si lahko predstavljate, kakšen tempo skozi slajde je to bil.
/jan
Podobno vprašanje si je zastavil Randy Bush, ko je opazoval centralizacijo moči na ICANN-u. Z ostro kritiko je potem dosegel širši konsenz svojih ultimatov in ICANN “decentraliziral”.
Podobno vprašanje si zastavljam danes. Pregledal sem RIPE policy-announce mailing listo in šel prebrati policy proposal-e. Se opravičujem za grd izraz, ampak “za kozlat”. Vsi novi dokumenti in predlogi se ukvarjajo samo in izključno z razdelitvijo preostanka IPv4 naslovov. Kako bomo razdelili zadnje /8 med RIR-e, kako bodo RIR-i razdelili zadnji /8, realokacija resursov med RIR-i, kako preprečiti zlorabe, skratka leta in leta že zapravljamo energijo in ukvarjamo s tem, kako razdelit zadnje dele umirajoče pošasti IPv4 po imenu. Ne samo, da je bila ta pošast zgrešena že ob kreaciji, celo njen konec moramo pospremiti s prerekanjem in zapravljanjem energije, kdo bo koliko imel in “bohnedej” da bi sosed imel več. Ja, “za kozlat”.
Predlog je tudi, da /16 prihranimo un-allocated za “unknown”. Ja, super ideja, a trapasta hkrati. /16 je v svetovnem merilu manj kot nič in če bomo primorani to alokacijo uporabiti za nekaj, kar sedaj ne morem oziroma ne znamo predvidet pri migraciji in tranziciji na IPv6, potem je to absolutno in daleč premalo. Halo, T2 ima več kot /16 samo za access network, a se mi hecamo s temi številkami?
Zakaj ne bi v te namene rezervirali cel zadnji /8 ? Kdo ga bo pa pogrešal, oziroma kaj izgubimo? Nič, v veliki sliki prav nič. Morda si prihranimo 3 ali 4 mesece agonije pred točko oziroma datumom, ko bodo RIR-i nehali razdeljevati alokacije IPv4.
Sicer pa, simbolični datum je že določen, 10.10.2010. Če uspemo do takrat zdržati z IPv4 naslovnim prostorom, zakaj ne bi definirali, da na ta dan RIR-i nehajo alocirat IPv4 resurse in to je to? Kdor je dual-stacked pač je, ostali so si pa sami krivi?
Čisto preveč enega časa gre v nič za traparije, namesto da bi začeli kompletirati navodila in pravila za tranzicijo. Saj vem, to ni naloga RIR-ov. Vprašujem se, čigava pa je čisto zares? Vsem je kristalno jasno, da nimamo delujočega mehanizma za translacijo med obema svetovoma, vsem je jasno, da nihče ne ve natančno, kako bo tranzicija potekala, ja a se nam sploh sanja, kaj počnemo? Do sedaj so bila predlagana nekaksna pravila tranzicije, a še vedno nič zares uporabnega.
Najbrž ste iz zgoraj napisanega že ugotovili, da me to spravlja v precej slabo voljo. Najbrž bom podobna vprašanja postavil tudi v Dubaju. Mogoče.
Življenje slovenskih ISP-jev gre pa lepo naprej. Zajčki skačejo, lisičke se lovijo po travniku, ptički prepevajo na veji, potoček žubori in vse je v najlepšem redu. Tudi življenje ponudnikov vsebin gre po tem vzoru lepo naprej in tudi večina hosting providerjev ni izjema. Vse bo ostalo, le potoček bo presahnil in travnik ovenel. No harm done, da?
Jan Žorž
Najprej naj pozdravim novega registriranega člana go6.si spletne skupnosti, Matjaža Štrausa, strokovnjaka za IPv6 na ARNES-u. Njegove dolgoletne izkušnje na tem področju lahko veliko pripomorejo k uspešnejšemu izpolnjevanju idej in poslanstva inicijative go6.si. Zdravo, kako smo kaj? 🙂
Približuje se RIPE57 v Dubaju (26 – 31.10), kjer se spet pričakuje žolčna razprava na temo IPv6 in tranzicije. Tokrat se odpravljamo v številčnejši zasedbi, ekipa go6.si/Domenca bo štela 4 člane. Tukaj bomo poročali sproti o zanimivih temah, tudi kakšna slika se bo našla.
IETF meeting v Dublinu…
IETF meeting v Dublinu ni postregel s kakšnimi revolucionarnimi rešitvami translation (prevajalnih) mehanizmov. Bolj kot ne so se vsi zaplezali v detajle in rešujejo težave, katere so sproducirali s prejšnjimi rešitvami težav. Zanimivo, da kljub temu, da je IETF poslal NAT-PT na smetišče digitalne zgodovine, se ne pokaže interes za precej perspektivnejšo rešitev – pTRTd.
Agenda za RIPE57 se polni in s tem postaja vedno bolj zanimiva.
http://www.ripe.net/ripe/meetings/ripe-57/agendas/index.html
Lorenzo, “tiny little chef from Google” bo predstavil IPv6 razvoj na Googlu. To je treba definitivno slišati, sicer pa je Lorenzo kar “fejst poba” in se na večernih social eventih rad razgovori. V večini primerov nastane iz tega maratonska razprava, v katerih bolj detaljno razloži svoje poglede in izkušnje.
Kot ponavadi bo tu tudi Randy Bush. Spet si je izbral divji naslov “A+P Address Hack. The Revenge of the Stupid Core”. Sumim, da bo njegov prispevek poučen, ciničen, sarkastičen a hkrati zabaven.
Sultan Al Shamsi bo povedal, kako jim gre pri uvajanju IPv6 v Arabskih Emiratih. Tam ne bi smeli imeti večjih težav, vsaj tako se mi zdi. Morda se pa motim.
Sicer pa, agenda se polni.
Toliko zaenkrat, Jan Žorž
Spet se nekaj dogaja. Ravno sem končal s pisanjem članka za revijo Varnostni forum, ki naj bi bil uvod in hkrati vabilo na predavanje o IPv6 na konferenci Infosek 2008, ki bo v Novi Gorici.
Naslov predavanja bo “IPv6 ali Skorajšnja izčrpanost IPv4 naslovnega prostora; sociološki, politični, tržni ali tehnološki problem?”
Dobra novica je tudi to, da je go6.si iniciativo vsaj idejno podprla tudi Agencija za Pošto in elektronske komunikacije republike Slovenije (APEK). To nam daje novega zagona pri naših prizadevanjih za informiranje, ozaveščanje ter širjenje ideje pravilne, koordinirane in predvsem kontrolirane migracije slovenskih internetnih omrežij na IPv6 protokol.
Program konference in ostale informacije okrog predavanja si lahko ogledate na http://www.infosek.net/index.php?page=32
/jan
Danes sem po mailu dobil sledece ugotovitve, ki bodo načelno izhodišče debat na IETF meetingu v Dublinu. Nič kaj nisem navdušen… 🙁
All,
Recent discussions in the IETF indicate that the IPv4 and IPv6 co-existence solutions we have available will not be sufficient for all deployment scenarios which we expect to be necessary in the face of pressures due to upcoming IPv4 address space exhaustion (or "completion"). The INT, TSV and OPS ADs would like to discuss with the community the best way to proceed in chartering this work, with particular focus on solutions which seem both readily tractable and for which provide identifiable benefit.
Specifically, two initial steps appear as potential work items:
1. The ability to employ an IPv6-only network infrastructure by, say a cable or DSL operator, and still be able to serve subscriber networks that run on IPv4. This scenario was described in the Vancouver IETF V6OPS meeting [4], and it could be helpful in large networks where private RFC1918 IPv4 space is not sufficient to address all devices without resorting to overlays or NAT of the private space itself. We believe that this is something that can be implemented through the use of tunneling of IPv4 over IPv6. If the subscribers are in turn given private IPv4 address space, the tunnels would be connected to an IPv4 NAT device that serves multiple subscribers, potentially requiring a device that serves a very large number of translations as well as tunnels.
It is suggested that this is a work item that fits the SOFTWIRE WG, and the INT ADs will be sending off a recharter proposal for this WG to examine this particular problem space and develop a solution accordingly.
2. NAT-PT was deprecated for reasons described in RFC 4966. However, there are scenarios where some forms of translation may be necessary. In particular, the IAB noted in [1] that scenarios involving servers without public IPv4 addresses cannot be adequately handled with the existing mechanisms. Requirements on this issue have been discussed in V6OPS, and a problem statement document written [2]. One possible translation design with reduced scope from NAT-PT as defined in RFC 2766 has been discussed recently in the BEHAVE WG [3], but there are other possible designs as well [5]. In essence, these designs attempt to reduce the problems present in NAT-PT by various techniques, including limiting themselves to a simpler part of the overall problem, allowing some changes in IPv6 hosts, and generally being designed with a better knowledge of the issues in RFC4966. We believe that, on balance, the benefits outweigh the costs on developing a standard method for translation of IPv4 and IPv6. This will likely have a smaller scope, at least in the short term, than the original NAT-PT though it will inevitably share some of the same limitations.
We will discuss this design in two places at the upcoming meeting:
BEHAVE and INTAREA (two separate places because we feel it necessary to involve both the IP experts and people with a history of building address translators). For the moment, general architectural discussion should happen on the int-area@ietf.org list.
We would like to focus our discussions on whether the requirements scenario and architectural direction is sufficiently ready so that the work can be given to the protocol WGs. If the answer to these questions is yes, after the Dublin IETF the ADs will recharter the relevant working groups to do the work. V6OPS is already working on the requirements. We expect that the behave WG would be the primary solution discussion forum and produce the base translation specification. 6MAN and DNSEXT would in turn handle any IPv6 stack or DNS protocol impacts (including a DNS ALG, if needed).
- INT, OPS, and TSV ADs
[1] http://www.ietf.org/mail-archive/web/ietf/current/msg48436.html
[2] http://tools.ietf.org/html/draft-ietf-v6ops-nat64-pb-statement-req
[3] http://tools.ietf.org/id/draft-bagnulo-behave-nat64
[4] http://www.ietf.org/proceedings/07dec/slides/v6ops-5/sld1.htm
[5] http://tools.ietf.org/id/draft-xli-behave-ivi
Comments(2)