...proto že stojí za starou bačkoru a přináší (krom vyřešení nedostatku adres) jenom samé nevýhody a nevyřešené věci....
Ja mam dojem, ze vzdy kdyz se neco k IPv6 vymysli, vzapeti se to "zavrhne". Ani se nedivim, ze nastup IPv6 jde tak pomalu - kazda firma si rozmysli investici do nestabilni technologie, ktera muze byt za pul roku "zavrzena" a nefunkcni.
6to4 apod. jsou jen provizorni mechanismy. Ono se to totiz vystribri casem. I kdyby to mel byt 1 obecne prijaty navrh na 20 spatnych. I to je evoluce. Postupne vznika IPv6 Internet a ten IPv4 zacne stejne pomalu mizet. Zadna velka revoluce, ani zadny velky krach. A potrva to roky...
U IPv4 se takhle laborovalo skoro 20 let. Problemem IPv6 je samotny mnozstvi uzivatelu a az desiva setrvacnost.
„Ja mam dojem, ze vzdy kdyz se neco k IPv6 vymysli, vzapeti se to "zavrhne". Ani se nedivim, ze nastup IPv6 jde tak pomalu - kazda firma si rozmysli investici do nestabilni technologie, ktera muze byt za pul roku "zavrzena" a nefunkcni.“
Hmm, takže problémy se 6to4 jako argument proti IPv6. To je přinejmenším úsměvné.
Spíš bych řekl, že rušení 6to4 je jasným důkazem, že se pomalu ale jistě opouští experimentální fáze, a řeší se jak to doopravdy nasadit. Tedy přechod od dlouhodobě testovaného prototypu k reálné implementaci.
Nicméně, ať si každá firma dělá co chce. Microsoft vzal otěže protlačování IPv6 na sebe, takže další propagace netřeba.
Je celkem skoda ze vsichni zatracuji teredo (rfc4380) jenom proto ze to je vynalez microsoftu. Prakticka zkusenost (tj predevsim p2p) je takova ze stateless protokoly 6to4 a jeho stejne bezmocny bratricek 6rd mu nemuzou ani zdaleka konkurovat bavime-li se o robustnosti pro BFU.
Dale nechapu narazku na anycast - ten preci danemu ISP dava kontrolu nad trafficem vzdy - od toho je to anycast. Alespon v pripade tereda to funguje jak ma. Jediny rozdil mezi 6to4 a 6rd je ze adresa anycastove relay je volitelna stejne jako prefix pod kterym je tunel videt v internetu.
Dale mne trochu mrzi, hlavne tedy od pera satrapy, ze problemy s MTU hazi do jednoho pytle s ipv4 svetem. Moc dobre totiz vi ze MTU discovery funguje u v6 tcp jinak - mss se ridi mtu na strane puvodce spojeni, takze staci mit na tunelovem interfacu mtu 1420 a problemy nejsou. Ty nastanou az kdyz mi ISP postavi do cesty nejakou zhovadilost stylu 6rd ktera se tvari jako nativni v6 i kdyz se jedna o tunel :)
> Moc dobre totiz vi ze MTU discovery funguje u v6 tcp jinak - mss se ridi mtu na strane puvodce spojeni, takze staci mit na tunelovem interfacu mtu 1420 a problemy nejsou.
A ono se v IPv4 MSS nenastavuje na strane puvodce spojeni, podle odchozicho interface?
Problem samozrejme muze nastat, ne sice v pripade, kdy je pres 6to4 pripojen jen jediny pocitac, ale pokud si takto nekdo pripoji celou sit (kde pak ma vetsi MTU). Samozrejme ten problem muze nastat jen v pripade, ze nekdo pitome blokuje ICMP.
> Moc dobre totiz vi ze MTU discovery funguje u v6 tcp jinak - mss se ridi mtu na strane puvodce spojeni, takze staci mit na tunelovem interfacu mtu 1420 a problemy nejsou.
A ono se v IPv4 MSS nenastavuje na strane puvodce spojeni, podle odchozicho interface?
Problem samozrejme muze nastat, ne sice v pripade, kdy je pres 6to4 pripojen jen jediny pocitac, ale pokud si takto nekdo pripoji celou sit (kde pak ma vetsi MTU). Samozrejme ten problem muze nastat jen v pripade, ze nekdo pitome blokuje ICMP.
....., ze nekdo pitome blokuje ICMP.
Bohuzial zakaz ICMP spominaju na skoleniach firewallistou. A kazdy pologenius ako prve zakaze ICMP na kompletku.
Byl by nejaky priklad firmy a skoleni, kde se toto deje? Pro zajimavost, komu se vyhnout..
jj, to musi byt skoleni jak noha, povoleny ICMP je zaklad jakkoli rozumne nastaveny site.
To jsem si oddechl, myslel jsem že mám na to zvrhlý názor a jak vidím tak nejsem sám.
Whereas there has been considerable controversy regarding draft-ietf-v6ops-6to4-to-historic, the v6ops chairs and document author have agreed to the following course of action:
- the V6OPS WG will withdraw its request to publish draft-ietf-v6ops-6to4-to-historic
- The author will introduce a new draft, intended for standards track publication. The new draft will update RFCs 3056 and 3068. It will say that if 6-to-4 is implemented, it must be turned off by default.
- In order for the new draft to be published, it must achieve both V6OPS WG and IETF consensus
If anyone objects to this course of action, please speak up soon.
Ron
<Speaking as OPS Area AD>