[ipv6-tf] Odp: po debacie.

Lukasz Stelmach stlman w poczta.fm
Wto, 24 Mar 2009, 23:06:00 CET


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Maciej *opaci*ski pisze:
>>>> Lukasz Stelmach <stlman w poczta.fm> 09-03-24 17:31 >>>
>> Jedno czego pan *opaci*ski nie potrafi* mi wyt*umaczy* to potrzeba
>> adresu PI w sytuacji gdy istnieje w IPv6 multi-homing (na poziomie
>> hostów) i algorytm dobierania adresów opisany w RFC 3484. Usilnie
>> obstawa* przy potrzebie manipulowania DNSem a co za tym idzie
>> nara*ania się na utratę **czno*ci z klientami ma*ych dostawców
>> nie potrafi*cych poprawnie skonfigurowa* DNSu u siebie.
> To szkoda, *e nie porozmawiali*my w kuluarach po
> konferencji. Postaram się jednak trochę to wyja*ni* dok*adniej.
> Po pierwsze twierdzi*em, *e jedynym rozs*dnym rozwi*zaniem dla
> dostawcy tre*ci jest protokó* routingu BGP i w*asna przestrze*
> adresowa. Wszystkie inne rozwi*zania s* protezami.
>
> IPv6 w obecnej formie zak*ada, *e routingi w sieciach operatorów
[...]
> wreszcie zdecydowa*, czy globalny routing IPv6 będzie /32 czy /48
> i czy chc* w IPv6 dostawców tre*ci czy nie.

Widać trzeba nad tym jeszcze popracować. Routowanie /48 i utrata
łączenia ścieżek routingu to spory problem. Z drugiej jednak strony,
liczba wpisów w tablicach nie skoczy z dnia na dzień więc nie jest
to problem nie do rozwiązania. Może RFC 2073 trzeba będzie odkurzyć.

> Je*li chodzi za* o RFC 3484. RFC opisuje do** uproszczony przyk*ad
> mutlihomingu, gdzie firma ma dostęp do dwóch operatorów. Zwró*my
> uwagę na ten fragment ze strony 19:
>
> "   Each site has two global prefixes, one from the   high-performance ISP
[...]
> ".

Tyle, że ten mechanizm nie dotyczy dostawców treści lecz ich
odbiorców bowiem to odbiorca nawiązuje z dostawcą połączenie.
Nawiązując je musi: wybrać jakiego adresu źródłowego i docelowego
użyje... OK chyba rozumiem problem.

> W przypadku dostawcy tre*ci, który ma kilka **czy tranzytowych
> i jest w kilku węz*ach peeringowych rozwi*zanie z RFC3484 wymaga
> utrzymywania dla ka*dej us*ugi adresów IPv6 z prefiksami od ka*dego
> z tych dostawców oraz odpowiednio wielu wpisów DNS'owych. Je*li
> z powodu awarii jednego z operatorów tranzytowych (np. flapowanie
> **cza) lub te* rozwi*zania z nim umowy, chcemy wy**czy* jedno z
> **czy tranzytowych, to musimy dokona* odpowiednich zmian w DNSie i
> zadba* o poprawn* propagacje tej zmiany. Z BGP i adresami PI jestem w
> stanie od**czy* operatora praktycznie bezbole*nie - u*ytkownicy będ*
> mieli problem przez kilkadziesi*t sekund.

A czasami godzina.

> W rozwi*zaniu RFC3483 z
> propagacj* DNSu problemy potrwaj* tygodniami.

To oznacza (to mało komercyjny sposób patrzenia na sprawy), że
problemem jest DNS a nie IP. Po coś w końcu są te TTLe w rekordach.

> Drug* kwesti*, która uniemo*liwa u*ycie RFC3484 jest asymetryczny
> routing. Pakiet przychodz*cy **czem od operatora A, nie musi wróci*
> tym samym **czem.

Tak było od zawsze w Internecie.

> Dostawca tre*ci wybiera **cze lepsze z jego
> punktu widzenia: np. ta*sze, mniej przeci**one.  Adresacja PI
> w IPv4 umo*liwia tego typu optymalizacje.

A podpięcie serwerów do (proszę wybaczyć jeżeli coś kręcę)
BGP i modyfikowanie im tą drogą metryk w tablicach routingu?

> Je*li  przejdziemy do
> IPv6, gdzie od ka*dego z ISP dostajemy inn* numerację IPv6 (inny
> prefix), to z du*ym prawdopodobie*stwem operator któremu zechcemy
> podrzuca* pakiety z adresacj* jego konkurenta, takich pakietów nie
> przyjmie.

To jest kwestia polityczna a nie techniczna. Jeżeli by się okazało,
że nie ma PI i albo wszyscy będą przepuszczać ruch od dostawców
albo spadną obroty/zyski to by problem zniknął.

> Dla dostawcy tre*ci oznacza to znaczne zmniejszenie
> mo*liwo*ci optymalizacji kosztów transmisji.

Zgadzam się jest to rozwiązanie *inne* niż do tej pory, a zatem
wymagające robienia czegoś od *nowa*. Rozumiem, że to *są* koszty.
Jest oczywistym, że przy dzisiejszym *modelu* dystrybucji treści
IPv6 niczego nie poprawia. A zatem przesiadka niczego nie wnosi
poza kosztami. Śmiem jednak twierdzić, że wszystkie potrzeby,
które dziś IPv4 z adresami PI zaspokaja IPv6 z multihomingiem
na poziomie interfejsów sieciowch też potrafi zaspokoić. Po coś
w końcu AGORA ma ten prefix ;-)

Dziękuję za wyjaśnienie mi problemu dostawców treści i adresów PI,
czego do tej pory nikt na tej liście, pomimo kilku dyskusji, nie
zdołał zrobić :-)

Na koniec tylko pozwolę sobie dodać, że jako "unijny podatnik"
widzę we wdrożeniu IPv6 ogromny potencjał rozwojowy, który
pozwoli mi z zyskiem wycofać mój wkład w ten proces.

- --
Było mi bardzo miło.               Czwarta pospolita klęska, [...]
>Łukasz<                 Już nie katolicka lecz złodziejska.  (c)PP


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknJWUcACgkQNdzY8sm9K9x6KwCfdU+iJ8jrvNdKltHnHzSQjMyk
AVQAn3GLdwAwyB6klWuuQG5/u2+pBVJ9
=xB7i
-----END PGP SIGNATURE-----


----------------------------------------------------------------------
10% zysku na lokacie bankowej z gwarancja BFG. Sprawdz!
http://clk.tradedoubler.com/click?p=74281&a=1586724&g=17879004

-------------- następna część ---------
A non-text attachment was scrubbed...
Name: stlman.vcf
Type: text/x-vcard
Size: 169 bytes
Desc: nie znany
URL: <http://www.pl.ipv6tf.org/pipermail/ipv6-tf/attachments/20090324/96dcbe2c/attachment.vcf>


Więcej informacji o liście ipv6-tf