[ipv6-tf] Odp: po debacie.

[Maciej Łopaciński]

Wysyłam jeszcze raz, bo poprzednio wysłany mail ma problem z polskimi
literkami.

>>> 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.
----------------------------------------------------------------------
>> http://link.interia.pl/f20a3 

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 będą
sumaryzowane do /32, czyli do poziomu alokacji przydzielanych LIRom. W
pierwotnych założeniach nie przewidywano alokacji typu PI. Brak alokacji
PI, spowodował, że 
żaden rozsądny dostawca treści nie wchodzi w IPv6. To zostało już
zauważone przez RIR'y i z wyjątkiem RIPE od niedawna przyznają one już
PI w IPv6. Jednak przydzielanie PI w IPv6 jest jak sprzedawanie
Niderlandów - przydzielane PI są /48, czyli zgodnie z przyjętymi
regułami zostaną one wyfiltrowane przez operatorów akceptujących
agregacje /32.  RIRy muszą się wreszcie zdecydować, czy globalny routing
IPv6 będzie /32 czy /48 i czy chcą w IPv6 dostawców treści czy nie.

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
   and one from their normal ISP.  Site A has prefix
2001:aaaa:aaaa::/48
   from the high-performance ISP and prefix 2007:0:aaaa::/48 from its
   normal ISP.  Site B has prefix 2001:bbbb:bbbb::/48 from the high-
   performance ISP and prefix 2007:0:bbbb::/48 from its normal ISP. 
All
   hosts in both sites register two addresses in the DNS.
".
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. W rozwiązaniu RFC3483 z propagacją DNSu problemy potrwają
tygodniami.
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. 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. 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. Dla dostawcy
treści oznacza to znaczne zmniejszenie możliwości optymalizacji kosztów
transmisji.



-- 
Agora TC Sp. z o.o., ul. Czerska 8/10, 00-732 Warszawa
Numer identyfikacji podatkowej / Polish VAT and tax ID no.: PL
899-244-52-28
Miejsce zarejestrowania / Place of registration: 
Sąd Rejonowy dla m. st. Warszawy / Regional Court for the Capital City
of Warsaw
Numer rejestru KRS / Registration no.: 105451
Kapitał zakładowy / Share capital: 50.000,00 zł.

Niniejsza wiadomość jest przeznaczona wyłącznie dla zamierzonego
adresata i może zawierać informacje o charakterze poufnym. W razie
stwierdzenia, że odbiorcą miała być inna osoba prosimy poinformować
nadawcę oraz niezwłocznie usunąć wiadomość. Wiadomość może nie stanowić
oficjalnego stanowiska spółki Agora TC i nie być związana z jej
działalnością.

This message is for the intended recipient only and it may contain
confidential information. If you receive this message in error, please
immediately delete it and notify the sender. This message may not
represent the official views of Agora TC and may not be related to its
business.