[ipv6-tf] Odp: po debacie.

Maciej Łopaciński maciej.lopacinski w agoratc.pl
Czw, 26 Mar 2009, 13:50:55 CET


W dokumencie  "IPv6 Address Allocation and Assignment Policy Document
ID: ripe-450" zostało zapisane 
" 4.3. Minimum allocation
RIRs will apply a minimum size for IPv6 allocations to facilitate
prefix-based filtering.
The minimum allocation size for IPv6 address space is /32."

Taki zapis oznacza, że mniejsze alokacje nie powinny pojawić się w
Internecie i operator ma prawo je wyfiltrować. Co więcej nawet powinien
to wyfiltorwać, żeby zabezpieczyć swoje routery przed przepełnieniem
tablic routingu wynikającym z błędów konfiguracji u innych operatorów.

Z drugiej strony http://venus.gr.jp/opf-jp/opm14/jpopm14-5.pdf slajd
44.
"LACNIC
* LAC-2008-02: Provider Independent (PI)
IPv6 Assignments to End User
Organizations with PI IPv4 Assignments
[---]
* Assignment size to be greater or equal to /48 and
less than /32"

LACZNIC zatwierdził rozdawanie adresacji PI o rozmiarze pomiędzy /48, a
/32. Zgodnie z poliktyką ripe-450, taka alokacja może nie przejść przez
operatorów tranzytowych lub też będzie tranzytowana bardzo nieoptymalnie
(przez tych operatorów, którzy nie zabezpieczają swoich routerów). RIRy
niestety w zakresie PI mają bardzo niespójne polityki :-(


>>> Bartek Gajda <gajda w man.poznan.pl> 2009-03-26 13:06 >>>


pozwole dorzucic swoje trzy grosze, ze niektore RIRy sie juz
zdecydowaly
w powyzszej kwestii i sprawa przepuszczania /32 i /48 lezy w gestii
operatorow i ich filtrow na urzadzeniach:

http://www.space.net/~gert/RIPE/ipv6-filters.html 
inside 2001:500::/30, the lists permits /48s. This network block is
the
ARIN critical internet infrastructure microallocation  block, and ARIN
is assigning /48s directly to end networks (like root name servers).

z drugiej strony (jesli zle mowie, to niech mnie ktos poprawi), sprawa
filtrow BGP na routerze w mojej firmie jest moja sprawa i sam sobie
moge
wpuszczac co mi odpowiada zgosdnie z moim biznesem, a RIRy nie maja mi
nic do nakazywania w tej sprawie

pozdrawiam,

Bartek

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


_______________________________________________
ipv6-tf mailing list
ipv6-tf w pl.ipv6tf.org 
http://www.pl.ipv6tf.org/mailman/listinfo/ipv6-tf

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



Więcej informacji o liście ipv6-tf