[ipv6-tf] SixXS POP

Grzegorz.Banasiak w ipv6.cbr.tpsa.pl Grzegorz.Banasiak w ipv6.cbr.tpsa.pl
Śro, 21 Lip 2004, 11:13:44 CEST


On Tue, Jul 20, 2004 at 10:56:00AM +0200, Marcin Gondek wrote:

> > Jesli sie zsumuje ilosc statycznych tuneli zakladanych w takich wezlach jak ICM, 
> > POZMAN, XS26, ITK (www.ipv6.pl), to powinnismy uzyskac liczbe rzedu 1k.
> 
> Tak, tylko wszędzie trzeba się "bawić" -> prosić ludzi i mieć kontakty.

Nie zgodze sie. http://www.ipv6.cbr.tpsa.pl/podlaczenie.html -> jasno
okreslona procedura. Nie widze tam miejsca na "kontakty" i "proszenie sie",
chociaz nasz disclaimer moze zniechecac. Zalozenie tunelu po uwaznym
przeczytaniu regul to 1 list (podobnie delegacja rDNS). Nie sadze, zeby byla to
jakas wielka bariera dla "user community".

> > To jest mysle sedno sprawy - content, a wlasciwie jego brak dla IPv6. Kolejny 
> > POP SixXS chyba tego nie poprawi.
> 
> Tak, ale zaszkodzić też nie zaszkodzi.

Byc moze nie. Postawmy sie jednak na miejscu operatora, ktory chcialby znac
odpowiedzi na nastepujace pytania:

- Na ile elastycznie mozna okreslac reguly alokacji adresow?
  Powiedzmy, ze operator ma opracowana strategie dla IPv6 i chcialby, aby
  przydzielona pula adresow byla w ogolnosci funkcja adresu IPv4 klienta, a
  nie po prostu kolejna pula z przestrzeni przypisanej do POPa. Tunele to w
  koncu mechanizm przejsciowy, po ktorym powinno sie dac kiedys w
  przyszlosci rozsadnie posprzatac.

- Czy dane do autentykacji uzytkownikow moglyby byc pobierane ze zrodla
  zewnetrznego, np. serwera LDAP?

- Czy operator bedzie mogl zadac pieniedzy za taka usluge (to czy ma to
  sens biznesowy to osobna kwestia)?

- Czy operator bedzie mogl dokonac korekt/przerobek w oprogramowaniu
  sterujacym POPem?

- Operator chcialby miec np. 3 POPy i automatycznie okreslac, ktory
  powinien obsluzyc danego klienta. Co wtedy?

- Co z redundancja/bezpieczenstwem? Pada serwer tunelujacy i...

Niestety info na stronach SixXS jest dosyc skape, ale rozumiem, ze jest to
produkt typu plug and play z ograniczonymi mozliwosciami developmentu po
stronie operatora (domysl).

> > Obserwuje to na przykladzie CBR-TPSA. Obecnie mamy skonfigurowanych ~100 tuneli. 
> > Odsetek aktywnych - okolo 30% (moze mniej - nie mierzymy na biezaco). Sumaryczny 
> > ruch z tuneli nie przekracza 10kB/s. Dominuje IRC.
> 
> Bo nie ma panelu po WWW żeby móc cośtam zmienić. Przecież pisanie listu
> z każdą pierdołą mija się z celem.

Utrudnia, ale "mija sie z celem" to IMHO za duzo powiedziane.

> Kolejnym plusem SixXS jest to, że obsluguje dynamiczne końce tunelu, co
> akurat Pana powinno ucieszyć (Neostrada)

Tak, przyznaje. Sam zreszta napisalem, ze to plus w poprzednim liscie.

BTW: Jak napisales, z SixXs korzysta jakies 150 polskich uzytkownikow. Czy
twoim zdaniem liczba ta ulegnie znaczacej zmianie, jezeli POP pojawi sie w
Polsce?

> > Wedlug mnie, w polskiej sieci publicznej IPv6 wykorzystywany jest po to, aby 
> > mozna bylo zaimponowac komus na kanale IRC i pokazac sie z blyskotliwa nazwa 
> > domenowa (bo zazwyczaj z tunelem przychodzi delegacja rDNS). Chcialbym sie mylic ;)
> 
> Mylisz się, ja akurat mam inne podejście, może jestem wyjątkiem.

Obawiam sie, ze nie jestes "reprezentatywny". Mam takie pytanie: co obecnie
daje ci protokol IPv6 czego nie daje ci IPv4?

> Nie prawda, mam lepsze transfery po v6.
> W moim wypadku easynet ma własny natywny szkielet po europie aż do USA i
> ten szkielet nie jest zapchany, dlatego przeważnie mam max.

Gratuluje w takim razie, chociaz dla contentu w Polsce juz tak nie bedzie,
nieprawdaz?

PING whois.ripe.net (193.0.0.135) 56(84) bytes of data.
64 bytes from 193.0.0.135: icmp_seq=1 ttl=245 time=26.9 ms

PING whois.ripe.net(2001:610:240:0:193::202) 56 data bytes
64 bytes from 2001:610:240:0:193::202: icmp_seq=1 ttl=59 time=183 ms

PING 6bone.net (206.123.31.124) 56(84) bytes of data.
64 bytes from 206.123.31.124: icmp_seq=1 ttl=47 time=125 ms

PING www.6bone.net(3ffe:b00:c18:1::10) 56 data bytes
64 bytes from 3ffe:b00:c18:1::10: icmp_seq=1 ttl=60 time=251 ms

PING orange.kame.net (203.178.141.194) 56(84) bytes of data.
64 bytes from 203.178.141.194: icmp_seq=1 ttl=44 time=300 ms

PING www.kame.net(2001:200:0:8002:203:47ff:fea5:3085) 56 data bytes
64 bytes from 2001:200:0:8002:203:47ff:fea5:3085: icmp_seq=1 ttl=54 time=343 ms

PING noc.sixxs.net (213.197.29.32) 56(84) bytes of data.
64 bytes from 213.197.29.32: icmp_seq=1 ttl=45 time=55.9 ms

PING www.sixxs.net(2001:838:1:1:210:dcff:fe20:7c7c) 56 data bytes
64 bytes from 2001:838:1:1:210:dcff:fe20:7c7c: icmp_seq=1 ttl=58 time=40.0 ms

Dostrzegam regule, z ktorej wylamuje sie nomen omen SixXS. :)

-- 
Grzegorz Banasiak
IPv6 Project
Polish Telecom Research & Development Department



Więcej informacji o liście ipv6-tf