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...
„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.
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>