LMS i wsparcie dla ipv6
Witam. Czy ktokolwiek orientuje sie, czy dziala juz jakas wersja/modul ipv6 dla LMS'a nawet w wersji komercyjnej? W zasadzie potrzeba jest implementacji zdefiniowania podsieci ipv6 i mozliwosci 'przypisania' prefixu do cpe/routera abonenta aby podac to w atrybucie radiusa do koncentratora pppoe. Pozdrawiam.
My też na to czekamy, ale z tego co wiem nic jeszcze takiego nie powstało :(
W dniu 29 grudnia 2013 21:51 użytkownik Łukasz Matys lukasz@e-matys.comnapisał:
Witam. Czy ktokolwiek orientuje sie, czy dziala juz jakas wersja/modul ipv6 dla LMS'a nawet w wersji komercyjnej? W zasadzie potrzeba jest implementacji zdefiniowania podsieci ipv6 i mozliwosci 'przypisania' prefixu do cpe/routera abonenta aby podac to w atrybucie radiusa do koncentratora pppoe. Pozdrawiam.
-- Matys Łukasz mobile: (+ 48) 504257944 _______________________________________________ lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
W dniu 29 grudnia 2013 21:56 użytkownik Sławomir Paszkiewicz paszczus@gmail.com napisał:
My też na to czekamy, ale z tego co wiem nic jeszcze takiego nie powstało :(
Potwierdzam, czekamy czekamy
W dniu 2014-01-01 20:05, Marcin napisał(a):
W dniu 29 grudnia 2013 21:56 użytkownik Sławomir Paszkiewicz paszczus@gmail.com napisał:
My też na to czekamy, ale z tego co wiem nic jeszcze takiego nie powstało :(
Potwierdzam, czekamy czekamy
Testowałem ostatnio IPv6 i generalnie w temacie funkcjonalności tej adresacji jest lipa, działają strony z grupy google, poza tym pomijając mało znaczące strony reszta nie działa, więc po co pośpiech wdrożenia funkcjonalności na już ;) ?.
W dniu 1 stycznia 2014 21:42 użytkownik Piotr Polok toplek@polok.pl napisał:
Testowałem ostatnio IPv6 i generalnie w temacie funkcjonalności tej adresacji jest lipa, działają strony z grupy google, poza tym pomijając mało znaczące strony reszta nie działa, więc po co pośpiech wdrożenia funkcjonalności na już ;) ?.
chociaż by dlatego, że UKE na nas to wymusza, od 1 czerwca 2012 każdy operator musi dać klientowi możliwość uzyskania adresacji ipv6.
W dniu 2014-01-01 21:47, Marcin napisał(a):
W dniu 1 stycznia 2014 21:42 użytkownik Piotr Polok toplek@polok.pl napisał:
Testowałem ostatnio IPv6 i generalnie w temacie funkcjonalności tej adresacji jest lipa, działają strony z grupy google, poza tym pomijając mało znaczące strony reszta nie działa, więc po co pośpiech wdrożenia funkcjonalności na już ;) ?.
chociaż by dlatego, że UKE na nas to wymusza, od 1 czerwca 2012 każdy operator musi dać klientowi możliwość uzyskania adresacji ipv6.
Jest ku temu jakaś podstawa prawna, czy to jest po prostu prośba prezesa UKE ?
W dniu 1 stycznia 2014 21:56 użytkownik Piotr Polok toplek@polok.pl napisał:
Jest ku temu jakaś podstawa prawna, czy to jest po prostu prośba prezesa UKE ?
Taka sama podstawa prawna jak robienie raportu SIIS, czyli przekazywanie danych, które po kliknięciu "wyślij" robią się danymi publicznymi i każdy może o nie UKE poprosić a te musi je podać - ot taka podstawa prawna.
W dniu 2014-01-01 22:01, Marcin napisał(a):
W dniu 1 stycznia 2014 21:56 użytkownik Piotr Polok toplek@polok.pl napisał:
Jest ku temu jakaś podstawa prawna, czy to jest po prostu prośba prezesa UKE ?
Taka sama podstawa prawna jak robienie raportu SIIS, czyli przekazywanie danych, które po kliknięciu "wyślij" robią się danymi publicznymi i każdy może o nie UKE poprosić a te musi je podać - ot taka podstawa prawna.
Reasumując niema wymogu wdrożenia IPv6 ;).
W dniu 2014-01-01 22:05, Piotr Polok pisze:
W dniu 2014-01-01 22:01, Marcin napisał(a):
W dniu 1 stycznia 2014 21:56 użytkownik Piotr Polok toplek@polok.pl napisał:
Jest ku temu jakaś podstawa prawna, czy to jest po prostu prośba prezesa UKE ?
Taka sama podstawa prawna jak robienie raportu SIIS, czyli przekazywanie danych, które po kliknięciu "wyślij" robią się danymi publicznymi i każdy może o nie UKE poprosić a te musi je podać - ot taka podstawa prawna.
Reasumując niema wymogu wdrożenia IPv6 ;).
Powiedz jeszcze, że SIIS olewasz?? Niestety IPV6 powinniśmy posiadać. Potem to i chociazby nat (ew. tunel) z tego zrobić, ale mieć trzeba ;(
W dniu 2014-01-02 07:46, Arturz napisał(a):
W dniu 2014-01-01 22:05, Piotr Polok pisze:
W dniu 2014-01-01 22:01, Marcin napisał(a):
W dniu 1 stycznia 2014 21:56 użytkownik Piotr Polok toplek@polok.pl napisał:
Jest ku temu jakaś podstawa prawna, czy to jest po prostu prośba prezesa UKE ?
Taka sama podstawa prawna jak robienie raportu SIIS, czyli przekazywanie danych, które po kliknięciu "wyślij" robią się danymi publicznymi i każdy może o nie UKE poprosić a te musi je podać - ot taka podstawa prawna.
Reasumując niema wymogu wdrożenia IPv6 ;).
Powiedz jeszcze, że SIIS olewasz?? Niestety IPV6 powinniśmy posiadać. Potem to i chociazby nat (ew. tunel) z tego zrobić, ale mieć trzeba ;(
Nie ma znaczenia czy olewam czy nie, jak dla mnie pośpiechu niema gdyż i tak jest to bezużyteczne na ten moment.
W dniu 02.01.2014 08:02, Piotr Polok pisze:
W dniu 2014-01-02 07:46, Arturz napisał(a):
W dniu 2014-01-01 22:05, Piotr Polok pisze: Powiedz jeszcze, że SIIS olewasz?? Niestety IPV6 powinniśmy posiadać. Potem to i chociazby nat (ew. tunel) z tego zrobić, ale mieć trzeba ;(
Nie ma znaczenia czy olewam czy nie, jak dla mnie pośpiechu niema gdyż i tak jest to bezużyteczne na ten moment.
Właśnie dlatego wdrożenie IPv6 trwa bez mała 10 lat :)
W dniu 2014-01-02 08:36, Robert Rakowski napisał(a):
W dniu 02.01.2014 08:02, Piotr Polok pisze:
W dniu 2014-01-02 07:46, Arturz napisał(a):
W dniu 2014-01-01 22:05, Piotr Polok pisze: Powiedz jeszcze, że SIIS olewasz?? Niestety IPV6 powinniśmy posiadać. Potem to i chociazby nat (ew. tunel) z tego zrobić, ale mieć trzeba ;(
Nie ma znaczenia czy olewam czy nie, jak dla mnie pośpiechu niema gdyż i tak jest to bezużyteczne na ten moment.
Właśnie dlatego wdrożenie IPv6 trwa bez mała 10 lat :)
Problemem nie są wdrożenia po stronie nazwijmy to hostów, tylko po stronie serverów, gdyż jeśliby ta adresacja działała po stronie serverów to naturalną rzeczą byłaby migracja ISP na IPv6 i tym sposobem pozbycie się NATów, naturalnie jedno wymusiło by drugie ;) ...
W dniu 02.01.2014 09:00, Piotr Polok pisze:
W dniu 2014-01-02 08:36, Robert Rakowski napisał(a):
W dniu 02.01.2014 08:02, Piotr Polok pisze:
W dniu 2014-01-02 07:46, Arturz napisał(a):
W dniu 2014-01-01 22:05, Piotr Polok pisze: Powiedz jeszcze, że SIIS olewasz?? Niestety IPV6 powinniśmy posiadać. Potem to i chociazby nat (ew. tunel) z tego zrobić, ale mieć trzeba ;(
Nie ma znaczenia czy olewam czy nie, jak dla mnie pośpiechu niema gdyż i tak jest to bezużyteczne na ten moment.
Właśnie dlatego wdrożenie IPv6 trwa bez mała 10 lat :)
Problemem nie są wdrożenia po stronie nazwijmy to hostów, tylko po stronie serverów, gdyż jeśliby ta adresacja działała po stronie serverów to naturalną rzeczą byłaby migracja ISP na IPv6 i tym sposobem pozbycie się NATów, naturalnie jedno wymusiło by drugie ;) ...
Teraz spójrz z punktu widzenia utrzymania serwera, i ISP/hostingu utrzymującego infrastrukturę. Po co wdrażać IPv6 skoro użytkownicy i tak się łączą po IPv4 :).
W dniu 2014-01-02 09:56, Robert Rakowski napisał(a):
W dniu 02.01.2014 09:00, Piotr Polok pisze:
W dniu 2014-01-02 08:36, Robert Rakowski napisał(a):
W dniu 02.01.2014 08:02, Piotr Polok pisze:
W dniu 2014-01-02 07:46, Arturz napisał(a):
W dniu 2014-01-01 22:05, Piotr Polok pisze: Powiedz jeszcze, że SIIS olewasz?? Niestety IPV6 powinniśmy posiadać. Potem to i chociazby nat (ew. tunel) z tego zrobić, ale mieć trzeba ;(
Nie ma znaczenia czy olewam czy nie, jak dla mnie pośpiechu niema gdyż i tak jest to bezużyteczne na ten moment.
Właśnie dlatego wdrożenie IPv6 trwa bez mała 10 lat :)
Problemem nie są wdrożenia po stronie nazwijmy to hostów, tylko po stronie serverów, gdyż jeśliby ta adresacja działała po stronie serverów to naturalną rzeczą byłaby migracja ISP na IPv6 i tym sposobem pozbycie się NATów, naturalnie jedno wymusiło by drugie ;) ...
Teraz spójrz z punktu widzenia utrzymania serwera, i ISP/hostingu utrzymującego infrastrukturę. Po co wdrażać IPv6 skoro użytkownicy i tak się łączą po IPv4 :).
Migracja musi się zacząć od strony serverów, gdyż nie będzie takiego klienta który będzie chciał internet na IPv6 bo większość internetu po prostu nie będzie działać. Tutaj jest pole do popisu dla UKE aby wymusiła działanie na zarządzających serverami ;). Jednak zgadzam się jest to trochę patowa sytuacja.
Patrząc od strony jakiejś racjonalności to rozwiązaniem byłoby przydzielanie klientowi podwójnej adresacji równolegle IPv4 oraz IPv6. Wtedy można by powiedzieć że po naszej (ISP) stronie IPv6 jest wdrożone choć funkcjonalności nie ma ;).
Wszystko oczywiście zależy od przyjętej koncepcji konfiguracji sieci, jednak z różnych powodów technicznie wydaje się to trudne/skomplikowane do wdrożenia, no chyba że jest jakiś prosty i mało obciążający maszyny pomysł, którego nie widzę ...
W dniu 02.01.2014 10:15, Piotr Polok pisze:
W dniu 2014-01-02 09:56, Robert Rakowski napisał(a):
W dniu 02.01.2014 09:00, Piotr Polok pisze:
W dniu 2014-01-02 08:36, Robert Rakowski napisał(a):
Problemem nie są wdrożenia po stronie nazwijmy to hostów, tylko po stronie serverów, gdyż jeśliby ta adresacja działała po stronie serverów to naturalną rzeczą byłaby migracja ISP na IPv6 i tym sposobem pozbycie się NATów, naturalnie jedno wymusiło by drugie ;) ...
Teraz spójrz z punktu widzenia utrzymania serwera, i ISP/hostingu utrzymującego infrastrukturę. Po co wdrażać IPv6 skoro użytkownicy i tak się łączą po IPv4 :).
Migracja musi się zacząć od strony serverów, gdyż nie będzie takiego klienta który będzie chciał internet na IPv6 bo większość internetu po prostu nie będzie działać. Tutaj jest pole do popisu dla UKE aby wymusiła działanie na zarządzających serverami ;). Jednak zgadzam się jest to trochę patowa sytuacja.
Patrząc od strony jakiejś racjonalności to rozwiązaniem byłoby przydzielanie klientowi podwójnej adresacji równolegle IPv4 oraz IPv6. Wtedy można by powiedzieć że po naszej (ISP) stronie IPv6 jest wdrożone choć funkcjonalności nie ma ;).
Wszystko oczywiście zależy od przyjętej koncepcji konfiguracji sieci, jednak z różnych powodów technicznie wydaje się to trudne/skomplikowane do wdrożenia, no chyba że jest jakiś prosty i mało obciążający maszyny pomysł, którego nie widzę ...
Przyznam od jakiegoś czasu przygotowuję się do przydzielania podwójnej adresacji. Większym problemem niż po co i jak po stronie ISP może być po stronie klienta. Większość znanych mi routerów domowych ma takie wsparcie dla ipv6, że najwyżej markerem na obudowie można skonfigurować. :)
W dniu 2014-01-02 11:05, Robert Rakowski napisał(a):
W dniu 02.01.2014 10:15, Piotr Polok pisze:
W dniu 2014-01-02 09:56, Robert Rakowski napisał(a):
W dniu 02.01.2014 09:00, Piotr Polok pisze:
W dniu 2014-01-02 08:36, Robert Rakowski napisał(a):
Problemem nie są wdrożenia po stronie nazwijmy to hostów, tylko po stronie serverów, gdyż jeśliby ta adresacja działała po stronie serverów to naturalną rzeczą byłaby migracja ISP na IPv6 i tym sposobem pozbycie się NATów, naturalnie jedno wymusiło by drugie ;) ...
Teraz spójrz z punktu widzenia utrzymania serwera, i ISP/hostingu utrzymującego infrastrukturę. Po co wdrażać IPv6 skoro użytkownicy i tak się łączą po IPv4 :).
Migracja musi się zacząć od strony serverów, gdyż nie będzie takiego klienta który będzie chciał internet na IPv6 bo większość internetu po prostu nie będzie działać. Tutaj jest pole do popisu dla UKE aby wymusiła działanie na zarządzających serverami ;). Jednak zgadzam się jest to trochę patowa sytuacja.
Patrząc od strony jakiejś racjonalności to rozwiązaniem byłoby przydzielanie klientowi podwójnej adresacji równolegle IPv4 oraz IPv6. Wtedy można by powiedzieć że po naszej (ISP) stronie IPv6 jest wdrożone choć funkcjonalności nie ma ;).
Wszystko oczywiście zależy od przyjętej koncepcji konfiguracji sieci, jednak z różnych powodów technicznie wydaje się to trudne/skomplikowane do wdrożenia, no chyba że jest jakiś prosty i mało obciążający maszyny pomysł, którego nie widzę ...
Przyznam od jakiegoś czasu przygotowuję się do przydzielania podwójnej adresacji. Większym problemem niż po co i jak po stronie ISP może być po stronie klienta. Większość znanych mi routerów domowych ma takie wsparcie dla ipv6, że najwyżej markerem na obudowie można skonfigurować. :)
u nas wszyscy klienci mają dzierżawione od nas routery Mikrotika, więc ze wsparciem IPv6 niema problemu, ale i tak technicznie jest to trudne: -musiałyby być 2 koncentratory PPPoE jeden co rozdaje IPv4, drugi IPv6, -shapper który tnie klientom pasmo musiałby ciąć po adresie MAC, niezależnie od tego jaki ma adres IP, -klient musiałby mieć 2 klienty PPPoE pobierające adresy z różnych 'service', -routing na urządzeniu klienta musiałby wiedzieć jakie zasoby sieciowe są dostępne na IPv4 a jakie po IPv6, tak aby wiedzieć gdzie kierować ruch.
wygląda na to że ostatni wymóg dyskwalifikuje tą koncepcję, czy masz jakiś inny pomysł na to ?
W dniu 02.01.2014 11:24, Piotr Polok pisze:
W dniu 2014-01-02 11:05, Robert Rakowski napisał(a):
Przyznam od jakiegoś czasu przygotowuję się do przydzielania podwójnej adresacji. Większym problemem niż po co i jak po stronie ISP może być po stronie klienta. Większość znanych mi routerów domowych ma takie wsparcie dla ipv6, że najwyżej markerem na obudowie można skonfigurować. :)
u nas wszyscy klienci mają dzierżawione od nas routery Mikrotika, więc ze wsparciem IPv6 niema problemu, ale i tak technicznie jest to trudne: -musiałyby być 2 koncentratory PPPoE jeden co rozdaje IPv4, drugi IPv6, -shapper który tnie klientom pasmo musiałby ciąć po adresie MAC, niezależnie od tego jaki ma adres IP, -klient musiałby mieć 2 klienty PPPoE pobierające adresy z różnych 'service', -routing na urządzeniu klienta musiałby wiedzieć jakie zasoby sieciowe są dostępne na IPv4 a jakie po IPv6, tak aby wiedzieć gdzie kierować ruch.
wygląda na to że ostatni wymóg dyskwalifikuje tą koncepcję, czy masz jakiś inny pomysł na to ?
Dlaczego uważasz, że przycinanie prędkości trzeba robić po adresie MAC? Skoro używasz mikrotik możesz do kolejki przypisać dwa adresy IP, w Linuksie jak sądzę podobnie. Natomiast PPPoE faktycznie komplikuje konfigurację sieci. Jednak Tobie przy Mikrotiku jest łatwiej - tam zdołasz uruchomić (chyba;) dwóch klientów pppoe, na cudzie internetu domowego czyli tplinku można o tym zapomnieć. Poza tym, co dalej z komputerami będącymi za tym routerem, przecież mikrotik nie ma infrastruktury NAT dla IPv6, więc pppoe dla routera się za bardzo nie sprawdzi. Musiałbyś routować jakąś niewielką pulę adresów do każdego z klientów, i na jego routerze już przydzielać do komputerów.
W dniu 2014-01-02 11:36, Robert Rakowski napisał(a):
W dniu 02.01.2014 11:24, Piotr Polok pisze:
W dniu 2014-01-02 11:05, Robert Rakowski napisał(a):
Przyznam od jakiegoś czasu przygotowuję się do przydzielania podwójnej adresacji. Większym problemem niż po co i jak po stronie ISP może być po stronie klienta. Większość znanych mi routerów domowych ma takie wsparcie dla ipv6, że najwyżej markerem na obudowie można skonfigurować. :)
u nas wszyscy klienci mają dzierżawione od nas routery Mikrotika, więc ze wsparciem IPv6 niema problemu, ale i tak technicznie jest to trudne: -musiałyby być 2 koncentratory PPPoE jeden co rozdaje IPv4, drugi IPv6, -shapper który tnie klientom pasmo musiałby ciąć po adresie MAC, niezależnie od tego jaki ma adres IP, -klient musiałby mieć 2 klienty PPPoE pobierające adresy z różnych 'service', -routing na urządzeniu klienta musiałby wiedzieć jakie zasoby sieciowe są dostępne na IPv4 a jakie po IPv6, tak aby wiedzieć gdzie kierować ruch.
wygląda na to że ostatni wymóg dyskwalifikuje tą koncepcję, czy masz jakiś inny pomysł na to ?
Dlaczego uważasz, że przycinanie prędkości trzeba robić po adresie MAC? Skoro używasz mikrotik możesz do kolejki przypisać dwa adresy IP, w Linuksie jak sądzę podobnie. Natomiast PPPoE faktycznie komplikuje konfigurację sieci. Jednak Tobie przy Mikrotiku jest łatwiej - tam zdołasz uruchomić (chyba;) dwóch klientów pppoe, na cudzie internetu domowego czyli tplinku można o tym zapomnieć. Poza tym, co dalej z komputerami będącymi za tym routerem, przecież mikrotik nie ma infrastruktury NAT dla IPv6, więc pppoe dla routera się za bardzo nie sprawdzi. Musiałbyś routować jakąś niewielką pulę adresów do każdego z klientów, i na jego routerze już przydzielać do komputerów.
Akurat nie używam MT do przycinania pasma.
Na ten moment jedyną sensowną koncepcją wdrożenia IPv6 jest jego równoległa implementacja z IPv4 per klient, jak na ten moment nie ma sensownego rozwiązania aby to skutecznie zrobić bo implikuje to zbyt wiele problemów a największym problemem jest to jak kierować ruchem, trzeba by wiedzieć jakie zasoby są aktualnie dostępne na IPv6, a jakie nie, więc podtrzymuję pierwotną opinię w tym temacie ;).
A ja kolejny raz zadam naiwne pytanie dlaczego? Przecież te zasoby same się identyfikują zwracając w DNS rekord "AAAA" obok zwykłego "A".
W dniu 2 stycznia 2014 11:49 użytkownik Piotr Polok toplek@polok.plnapisał:
W dniu 2014-01-02 11:36, Robert Rakowski napisał(a):
W dniu 02.01.2014 11:24, Piotr Polok pisze:
W dniu 2014-01-02 11:05, Robert Rakowski napisał(a):
Przyznam od jakiegoś czasu przygotowuję się do przydzielania podwójnej adresacji. Większym problemem niż po co i jak po stronie ISP może być po stronie klienta. Większość znanych mi routerów domowych ma takie wsparcie dla ipv6, że najwyżej markerem na obudowie można skonfigurować. :)
u nas wszyscy klienci mają dzierżawione od nas routery Mikrotika, więc ze wsparciem IPv6 niema problemu, ale i tak technicznie jest to trudne: -musiałyby być 2 koncentratory PPPoE jeden co rozdaje IPv4, drugi IPv6, -shapper który tnie klientom pasmo musiałby ciąć po adresie MAC, niezależnie od tego jaki ma adres IP, -klient musiałby mieć 2 klienty PPPoE pobierające adresy z różnych 'service', -routing na urządzeniu klienta musiałby wiedzieć jakie zasoby sieciowe są dostępne na IPv4 a jakie po IPv6, tak aby wiedzieć gdzie kierować ruch.
wygląda na to że ostatni wymóg dyskwalifikuje tą koncepcję, czy masz jakiś inny pomysł na to ?
Dlaczego uważasz, że przycinanie prędkości trzeba robić po adresie
MAC? Skoro używasz mikrotik możesz do kolejki przypisać dwa adresy IP, w Linuksie jak sądzę podobnie. Natomiast PPPoE faktycznie komplikuje konfigurację sieci. Jednak Tobie przy Mikrotiku jest łatwiej - tam zdołasz uruchomić (chyba;) dwóch klientów pppoe, na cudzie internetu domowego czyli tplinku można o tym zapomnieć. Poza tym, co dalej z komputerami będącymi za tym routerem, przecież mikrotik nie ma infrastruktury NAT dla IPv6, więc pppoe dla routera się za bardzo nie sprawdzi. Musiałbyś routować jakąś niewielką pulę adresów do każdego z klientów, i na jego routerze już przydzielać do komputerów.
Akurat nie używam MT do przycinania pasma.
Na ten moment jedyną sensowną koncepcją wdrożenia IPv6 jest jego równoległa implementacja z IPv4 per klient, jak na ten moment nie ma sensownego rozwiązania aby to skutecznie zrobić bo implikuje to zbyt wiele problemów a największym problemem jest to jak kierować ruchem, trzeba by wiedzieć jakie zasoby są aktualnie dostępne na IPv6, a jakie nie, więc podtrzymuję pierwotną opinię w tym temacie ;).
-- pozdrawiam Piotr Polok
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
W liście datowanym 2 stycznia 2014 (11:53:11) napisano:
RR> A ja kolejny raz zadam naiwne pytanie dlaczego? Przecież te RR> zasoby same się identyfikują zwracając w DNS rekord "AAAA" obok zwykłego "A".
tez mi sie tak wydaje ... jesli bede mial wylacznie ipv6 to chyba nie oznacza to ze nie bede mogl sie polaczyc z hostep ktory ma wylacznei ipv4 ? Myle sie ?
Neostrada ma tylko ipv6 i jakos to dziala ... :-?
pozdrawiam,
W dniu 2014-01-02 11:56, Arkadiusz Szlękowski napisał(a):
W liście datowanym 2 stycznia 2014 (11:53:11) napisano:
RR> A ja kolejny raz zadam naiwne pytanie dlaczego? Przecież te RR> zasoby same się identyfikują zwracając w DNS rekord "AAAA" obok zwykłego "A".
tez mi sie tak wydaje ... jesli bede mial wylacznie ipv6 to chyba nie oznacza to ze nie bede mogl sie polaczyc z hostep ktory ma wylacznei ipv4 ? Myle sie ?
Neostrada ma tylko ipv6 i jakos to dziala ... :-?
Raczej jest to jako opcje, a nie jedyna możliwość, jak klient ma w miarę nowe urządzenie to może sobie przełączyć na IPv6, wtedy adresy które nie są dostępne przez IPv6 przechodzą przez jakiegoś NATa czy proxy który ma IPv4.
Jak już wcześniej pisałem na razie nie widzę prostych rozwiązań, ale może wiecie coś więcej, jak TP robi to pewnie jakoś się to da, pytanie tylko jakie problemy implikuje ...
W liście datowanym 2 stycznia 2014 (12:13:58) napisano:
Neostrada ma tylko ipv6 i jakos to dziala ... :-?
PP> Raczej jest to jako opcje, a nie jedyna możliwość, jak klient ma w miarę PP> nowe urządzenie to może sobie przełączyć na IPv6, wtedy adresy które nie PP> są dostępne przez IPv6 przechodzą przez jakiegoś NATa czy proxy który ma PP> IPv4.
Tez mi sie tak wydaje ... ciekawy jest mechanizm, ktory wie jaki adres ktoredy puscic lub jak z poziomu ipv6 osiagnac bez problemu ipv4. Proxy moim zdaniem odpada w ich wykonaniu.
pozdrawiam,
W dniu 2014-01-02 11:53, Rafał Ramocki napisał(a):
A ja kolejny raz zadam naiwne pytanie dlaczego? Przecież te zasoby same się identyfikują zwracając w DNS rekord "AAAA" obok zwykłego "A".
a i fajnie, czyli jest punkt zaczepienia, a to teraz ja zadam naiwne pytanie ;), a czy taki inteligentny router jak MT umie sobie z tym poradzić i skierować ruch tam gdzie trzeba ?
Wg mojej wiedzy, jeżeli router jest dual-stack i obsługuje jednocześnie IPv6 i IPv4 to on nie ma co się zastanawiać. stosy v4 i v6 są (powinny być) od siebie odseparowane. Jak odbiera pakiet IPv6 to idzie w IPv6 jak v IPv4 to ma iść w IPv4. Konwersje są wg mojej wiedzy możliwe, ale chyba w tym kontekście nie są wymagane.
W dniu 2 stycznia 2014 12:01 użytkownik Piotr Polok toplek@polok.plnapisał:
W dniu 2014-01-02 11:53, Rafał Ramocki napisał(a):
A ja kolejny raz zadam naiwne pytanie dlaczego? Przecież te zasoby
same się identyfikują zwracając w DNS rekord "AAAA" obok zwykłego "A".
a i fajnie, czyli jest punkt zaczepienia, a to teraz ja zadam naiwne pytanie ;), a czy taki inteligentny router jak MT umie sobie z tym poradzić i skierować ruch tam gdzie trzeba ?
-- pozdrawiam Piotr Polok _______________________________________________ lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
W dniu 02.01.2014 12:16, Rafał Ramocki pisze:
Wg mojej wiedzy, jeżeli router jest dual-stack i obsługuje jednocześnie IPv6 i IPv4 to on nie ma co się zastanawiać. stosy v4 i v6 są (powinny być) od siebie odseparowane. Jak odbiera pakiet IPv6 to idzie w IPv6 jak v IPv4 to ma iść w IPv4. Konwersje są wg mojej wiedzy możliwe, ale chyba w tym kontekście nie są wymagane. _____________________________________________ lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
Możesz doprecyzować jaki mechanizm konwersji masz na myśli? Nat ruchu ipv6 do ipv4?
Mam na myśli, RFC 6144 i 6145, NAT64 i DNS64. Poza tym z na screenshotach neostrady widać, że to IPv6 tam to nie jest chyba samo v6, a dual-stack 6 i 4: http://www.orange.pl/kid,4002234817,id,4003556177,title,Neostrada-protokol-i...
W dniu 2 stycznia 2014 12:22 użytkownik Robert Rakowski < robert@actus-info.pl> napisał:
W dniu 02.01.2014 12:16, Rafał Ramocki pisze:
Wg mojej wiedzy, jeżeli router jest dual-stack i obsługuje jednocześnie IPv6 i IPv4 to on nie ma co się zastanawiać. stosy v4 i v6 są (powinny być) od siebie odseparowane. Jak odbiera pakiet IPv6 to idzie w IPv6 jak v IPv4 to ma iść w IPv4. Konwersje są wg mojej wiedzy możliwe, ale chyba w tym kontekście nie są wymagane. _____________________________________________ lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
Możesz doprecyzować jaki mechanizm konwersji masz na myśli? Nat ruchu ipv6 do ipv4?
-- pozdrawiam Robert Rakowski tel:717187464
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
W dniu 2014-01-02 12:16, Rafał Ramocki napisał(a):
Wg mojej wiedzy, jeżeli router jest dual-stack i obsługuje jednocześnie IPv6 i IPv4 to on nie ma co się zastanawiać. stosy v4 i v6 są (powinny być) od siebie odseparowane. Jak odbiera pakiet IPv6 to idzie w IPv6 jak v IPv4 to ma iść w IPv4. Konwersje są wg mojej wiedzy możliwe, ale chyba w tym kontekście nie są wymagane.
A tu by było jakieś światełko w tunelu, czyli chcesz powiedzieć że jeżeli server DNS obsługuje też wpisy IPv6, to wtedy jeśli istnieje nazwa dostępna po IPv6 to odpowie adresem IPv6, a jeśli nie to odpowie adresem IPv4.
Testowałeś to ?
W dniu 2014-01-02 12:01, Piotr Polok pisze:
W dniu 2014-01-02 11:53, Rafał Ramocki napisał(a):
A ja kolejny raz zadam naiwne pytanie dlaczego? Przecież te zasoby same się identyfikują zwracając w DNS rekord "AAAA" obok zwykłego "A".
a i fajnie, czyli jest punkt zaczepienia, a to teraz ja zadam naiwne pytanie ;), a czy taki inteligentny router jak MT umie sobie z tym poradzić i skierować ruch tam gdzie trzeba ?
Albo Ty albo Twój dostawca musi wiedzieć o routingu do IPV6. Zatem na routerze głównym masz ipv4 i ipv6 i znasz np. bgp lub masz tunel ipv6. Ale IMHO posiadanie bgp z ipv4 /6 jest rozsądnym rozwiązaniem ;( Jak masz "nie swoje" ip, to wypadało by zapytać dostawcę czy "przepuści" twoje ipv6 w świat....
Ja pod koniec miesiaca będę odpalał bgp dla IPV6, zoabczymy ja kto bedzie działało tylko do testów. Potem sie zobaczy ;(
W dniu 02.01.2014 12:25, Arturz pisze:
W dniu 2014-01-02 12:01, Piotr Polok pisze:
W dniu 2014-01-02 11:53, Rafał Ramocki napisał(a):
A ja kolejny raz zadam naiwne pytanie dlaczego? Przecież te zasoby same się identyfikują zwracając w DNS rekord "AAAA" obok zwykłego "A".
a i fajnie, czyli jest punkt zaczepienia, a to teraz ja zadam naiwne pytanie ;), a czy taki inteligentny router jak MT umie sobie z tym poradzić i skierować ruch tam gdzie trzeba ?
Albo Ty albo Twój dostawca musi wiedzieć o routingu do IPV6. Zatem na routerze głównym masz ipv4 i ipv6 i znasz np. bgp lub masz tunel ipv6. Ale IMHO posiadanie bgp z ipv4 /6 jest rozsądnym rozwiązaniem ;( Jak masz "nie swoje" ip, to wypadało by zapytać dostawcę czy "przepuści" twoje ipv6 w świat....
Ja pod koniec miesiaca będę odpalał bgp dla IPV6, zoabczymy ja kto bedzie działało tylko do testów. Potem sie zobaczy ;( _______________________________________________ lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
Ja mam u siebie od jakiś 2 miesięcy tak odpalone BGP V4 i v6 na 1 maszynie działa OK ip route i ip -6 route to 2 różne bajki bird i bird6 działają równolegle. Główny router bawi się i IPv4 i IPv6 nie ma z tym problemów na laptopie jak mam i V4 i V6 to IPv6 jest priorytetowo jakoś traktowane jak coś może iść i v6 i v4 to na 99% poleci po v6. Jak nie ma v6 to leci v4 żadnej ingerencji po prostu działa.
A problemem we wdrażaniu jest to, że ISP nie bawią się w v6 bo nie ma contentu, a znów dostawcy nie bawią sie w v6 bo nie ma odbiorców :)
Tak na szybko ip -6 route | wc -l 16225
W dniu 2014-01-02 12:25, Arturz napisał(a):
W dniu 2014-01-02 12:01, Piotr Polok pisze:
W dniu 2014-01-02 11:53, Rafał Ramocki napisał(a):
A ja kolejny raz zadam naiwne pytanie dlaczego? Przecież te zasoby same się identyfikują zwracając w DNS rekord "AAAA" obok zwykłego "A".
a i fajnie, czyli jest punkt zaczepienia, a to teraz ja zadam naiwne pytanie ;), a czy taki inteligentny router jak MT umie sobie z tym poradzić i skierować ruch tam gdzie trzeba ?
Albo Ty albo Twój dostawca musi wiedzieć o routingu do IPV6. Zatem na routerze głównym masz ipv4 i ipv6 i znasz np. bgp lub masz tunel ipv6. Ale IMHO posiadanie bgp z ipv4 /6 jest rozsądnym rozwiązaniem ;( Jak masz "nie swoje" ip, to wypadało by zapytać dostawcę czy "przepuści" twoje ipv6 w świat....
Ja pod koniec miesiaca będę odpalał bgp dla IPV6, zoabczymy ja kto bedzie działało tylko do testów. Potem sie zobaczy ;(
z samym routingiem na ruterze brzegowym niema problemu, problem jest na etapie urządzenia klienckiego które musi zdecydować jakim kanałem realizować ruch czy IPv4 czy IPv6 ...
W dniu 2014-01-02 12:31, Piotr Polok pisze:
W dniu 2014-01-02 12:25, Arturz napisał(a):
W dniu 2014-01-02 12:01, Piotr Polok pisze:
W dniu 2014-01-02 11:53, Rafał Ramocki napisał(a):
A ja kolejny raz zadam naiwne pytanie dlaczego? Przecież te zasoby same się identyfikują zwracając w DNS rekord "AAAA" obok zwykłego "A".
a i fajnie, czyli jest punkt zaczepienia, a to teraz ja zadam naiwne pytanie ;), a czy taki inteligentny router jak MT umie sobie z tym poradzić i skierować ruch tam gdzie trzeba ?
Albo Ty albo Twój dostawca musi wiedzieć o routingu do IPV6. Zatem na routerze głównym masz ipv4 i ipv6 i znasz np. bgp lub masz tunel ipv6. Ale IMHO posiadanie bgp z ipv4 /6 jest rozsądnym rozwiązaniem ;( Jak masz "nie swoje" ip, to wypadało by zapytać dostawcę czy "przepuści" twoje ipv6 w świat....
Ja pod koniec miesiaca będę odpalał bgp dla IPV6, zoabczymy ja kto bedzie działało tylko do testów. Potem sie zobaczy ;(
z samym routingiem na ruterze brzegowym niema problemu, problem jest na etapie urządzenia klienckiego które musi zdecydować jakim kanałem realizować ruch czy IPv4 czy IPv6 ...
A nie jest tak, że jak przychodzi zapytanie IPV4 dns to odpowiada DNS rekordem A A jak przyjdzie IPV6 to rekordem AAA?? Nie znam się, to pytam. Co jak z IPV6 przyjdzie pytanie do DNS a tam jest wpis TYLKO A??
IMHO mój router musi przeroutować ruch dla takiego klienta do zasobów ipv4.
W dniu 02.01.2014 12:41, Arturz pisze:
A nie jest tak, że jak przychodzi zapytanie IPV4 dns to odpowiada DNS rekordem A A jak przyjdzie IPV6 to rekordem AAA?? Nie znam się, to pytam. Co jak z IPV6 przyjdzie pytanie do DNS a tam jest wpis TYLKO A??
pawel@patt-K50IN ~ $ host google.pl google.pl has address 217.168.141.106 [ciach] google.pl has IPv6 address 2a00:1450:4008:800::1018 google.pl mail is handled by 20 alt1.aspmx.l.google.com. google.pl mail is handled by 30 alt2.aspmx.l.google.com. google.pl mail is handled by 40 alt3.aspmx.l.google.com. google.pl mail is handled by 10 aspmx.l.google.com. google.pl mail is handled by 50 alt4.aspmx.l.google.com.
no... nie
To jest fakt. Wedle mojego doswiadczenia dual-stack only. U nas dziala pieknie. Wypuscilem sobie takze ipv6 do domu via vpn - i jak sobie siedze to juz coraz wiecej serwisow dziala over ipv6. Pozdrawiam.
W dniu 2014-01-02 13:00, Łukasz Matys napisał(a):
To jest fakt. Wedle mojego doswiadczenia dual-stack only. U nas dziala pieknie. Wypuscilem sobie takze ipv6 do domu via vpn - i jak sobie siedze to juz coraz wiecej serwisow dziala over ipv6.
Dzięki za te informacje, rozumiem zatem że się jednak da w miarę sensowny sposób wdrożyć równolegle IPv4 oraz IPv6, zatem dla samej idei jest sens to robić. Biorąc pod uwagę poprzedzającą dyskusję pytanie w jakim zakresie należałoby dostosować LMSa, a wiadomo czym prostsze rozwiązania tym lepsze ;).
Najprostsze rozwiązanie to takie, które będzie spójne z obecnym kodem. Np. obecny kod dosyć szeroko wykorzystuje wbudowane w MySQL funkcje INET_NTOA i INET_ATON. Niestety ich odpowiedniki dla IPv6 pojawiają się dopiero w MySQL 5.6 więc wprowadzenie obsługi IPv6 wprowadziłoby zależności do komponentów których w wielu dystrybucjach jeszcze niema. Ja wiem, że można zainstalować bezpośrednio z mysql.com, ale nie jest to optymalne rozwiązanie.
W dniu 2 stycznia 2014 13:24 użytkownik Piotr Polok toplek@polok.plnapisał:
W dniu 2014-01-02 13:00, Łukasz Matys napisał(a):
To jest fakt.
Wedle mojego doswiadczenia dual-stack only. U nas dziala pieknie. Wypuscilem sobie takze ipv6 do domu via vpn - i jak sobie siedze to juz coraz wiecej serwisow dziala over ipv6.
Dzięki za te informacje, rozumiem zatem że się jednak da w miarę sensowny sposób wdrożyć równolegle IPv4 oraz IPv6, zatem dla samej idei jest sens to robić. Biorąc pod uwagę poprzedzającą dyskusję pytanie w jakim zakresie należałoby dostosować LMSa, a wiadomo czym prostsze rozwiązania tym lepsze ;).
-- pozdrawiam Piotr Polok _______________________________________________ lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
W dniu 02.01.2014 13:32, Rafał Ramocki napisał(a):
Najprostsze rozwiązanie to takie, które będzie spójne z obecnym kodem. Np. obecny kod dosyć szeroko wykorzystuje wbudowane w MySQL funkcje INET_NTOA i INET_ATON. Niestety ich odpowiedniki dla IPv6 pojawiają się dopiero w MySQL 5.6 więc wprowadzenie obsługi IPv6 wprowadziłoby zależności do komponentów których w wielu dystrybucjach jeszcze niema. Ja wiem, że można zainstalować bezpośrednio z mysql.com [2], ale nie jest to optymalne rozwiązanie.
A najbardziej optymalne to i tak PostgreSQL ;-)
Wiesz, gdyby nie to że sam od lat używam MySQL i narosło wokół tego tyle rzeczy, że nie za bardzo jest jak to ruszyć to sam bym optował za porzuceniem MySQL :)
W dniu 2 stycznia 2014 13:38 użytkownik Tomasz Chiliński < tomasz.chilinski@chilan.com> napisał:
W dniu 02.01.2014 13:32, Rafał Ramocki napisał(a):
Najprostsze rozwiązanie to takie, które będzie spójne z obecnym kodem. Np. obecny kod dosyć szeroko wykorzystuje wbudowane w MySQL funkcje INET_NTOA i INET_ATON. Niestety ich odpowiedniki dla IPv6 pojawiają się dopiero w MySQL 5.6 więc wprowadzenie obsługi IPv6 wprowadziłoby zależności do komponentów których w wielu dystrybucjach jeszcze niema. Ja wiem, że można zainstalować bezpośrednio z mysql.com [2], ale nie jest to optymalne rozwiązanie.
A najbardziej optymalne to i tak PostgreSQL ;-)
-- Pozdrawiam Tomasz Chiliński, Chilan
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
W dniu 02.01.2014 13:47, Rafał Ramocki pisze:
Wiesz, gdyby nie to że sam od lat używam MySQL i narosło wokół tego tyle rzeczy, że nie za bardzo jest jak to ruszyć to sam bym optował za porzuceniem MySQL :)
MySQL to tak durna baza, że jeśli ipv6 miało być tylko w postgresie to bym zadał sobie ten trud przejścia.
Nie nazwałbym jej durną. PG jest oczywiście potężniejszy, ale mam bazy +100G tak w PG jak i w MySQL (nie LMS). Obie mają swoje wady i zalety. Wiele psów wieszanych na MySQL to pozostałości po początkujących samoukach dla których MySQL to pierwsza baza bo po prostu działa out-of-the-box. Znajomy też optymalizował jednego MySQL na którym wieszano psy za powolność na solidnej maszynie z RAID10 na SAS i 16G RAM podczas gdy z konfiguracją w zasadzie nic nie zrobiono od momentu instalacji. (MySQL skonfugrownay jak na 16M Ram nie jak na 16G).
W dniu 02.01.2014 14:22, Rafał Ramocki pisze:
Nie nazwałbym jej durną. PG jest oczywiście potężniejszy, ale mam bazy +100G tak w PG jak i w MySQL (nie LMS). Obie mają swoje wady i zalety. Wiele psów wieszanych na MySQL to pozostałości po początkujących samoukach dla których MySQL to pierwsza baza bo po prostu działa out-of-the-box. Znajomy też optymalizował jednego MySQL na którym wieszano psy za powolność na solidnej maszynie z RAID10 na SAS i 16G RAM podczas gdy z konfiguracją w zasadzie nic nie zrobiono od momentu instalacji. (MySQL skonfugrownay jak na 16M Ram nie jak na 16G).
uczyłem się na oracle, interbase. Bazy w firmie od chipsów były i 100G, w banku nawet większe ;)
Ostatnio dostałem białej gorączki jak musiałem odtworzyć bazę mysql z "kopii zapasowej", żadna inna baza nie udaje kopii zapasowych...
Przenoszalność bazy to druga "pięknie" działająca opcja. Opcjonalnie też przenoszą się funkcje,procedury składowane, triggery o uprawnieniach nie wspomnę (grr).
Pytanie jak te "kopie" i przenoszenia były robione i czy aby na pewno autor rozwiązania przeczytał dokumentację? he? :)
W dniu 2 stycznia 2014 14:36 użytkownik Paweł Rohde pawel@rohde.plnapisał:
W dniu 02.01.2014 14:22, Rafał Ramocki pisze:
Nie nazwałbym jej durną. PG jest oczywiście potężniejszy, ale mam bazy
+100G tak w PG jak i w MySQL (nie LMS). Obie mają swoje wady i zalety. Wiele psów wieszanych na MySQL to pozostałości po początkujących samoukach dla których MySQL to pierwsza baza bo po prostu działa out-of-the-box. Znajomy też optymalizował jednego MySQL na którym wieszano psy za powolność na solidnej maszynie z RAID10 na SAS i 16G RAM podczas gdy z konfiguracją w zasadzie nic nie zrobiono od momentu instalacji. (MySQL skonfugrownay jak na 16M Ram nie jak na 16G).
uczyłem się na oracle, interbase. Bazy w firmie od chipsów były i 100G, w banku nawet większe ;)
Ostatnio dostałem białej gorączki jak musiałem odtworzyć bazę mysql z "kopii zapasowej", żadna inna baza nie udaje kopii zapasowych...
Przenoszalność bazy to druga "pięknie" działająca opcja. Opcjonalnie też przenoszą się funkcje,procedury składowane, triggery o uprawnieniach nie wspomnę (grr).
-- pozdrawiam [ Paweł Rohde ]
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
Witam. Nie jestem projektantem baz, ani zaawansowanym userem mysql'a, ale faktycznie takze sie kiedys na tym zlapalem ze w mysql backup to nie backup. Przeciez to powinno z marszu zrzucac takze funkcje a nie same dane ;-).
To tak jakby zrobic backup pliku excela, ale bez makr - i uzytkownik powinien o tym jeszcze pamietac...tutaj jest porazka. Pozdrawiam.
Da sie to zrobic bez wielkich kombinacji, brakuje tylko wsparcia w lmsie, by mozna bylo ciachac podsieci i przypisywac cpe klientow. Pozdrawiam.
Witam Panow. Nie zgodze sie. PPPoE duzo ulatwia. Jezeli ktos uzywa koncentratora pppoe (w moim przypadku np routerboard ccr), to limit predkosci mamy np za pomoca simple queue na interfejsie pppoe. Zatem czy jest tam ipv4, czy ipv6, a za 100 lat ipv16 - nie ma to znaczenia.
Idac dalej, mamy wdrozony testowo dual-stack, klienci maja jako CPE routerboardy mikrotika. Za pomoca sesji pppoe wstrzykujemy np /56 (min zalecenie od ripe) na interfejsie pppoe, i klientowi odpalamy autokonfiguracje na 'lan'ie'. Klient ma ipv4 i ipv6 - i wszystko w temacie. (na upartego mozna tez zrobic prefix delegation, ale moim zdaniem tracimy wowczas kontrole nad adresami ktore uzywa dany klient). W przypadku 'framed-ipv6-prefix' mamy koniec problemow z logowaniem polaczen klientow. Dany klient ma na stale /56 i dziekuje.
Czekam tylko az bede mogl podac z radiusa do koncentratora pppoe 'Framed-IPv6-Prefix - Ipv6 prefix assigned for the client.' Powinno pojawic sie w LMS'ie cos takiego jak 'wrutowany prefix ipv6 do cpe klienta'. Klikamy, generujemy sobie dla radiusa odpowiednie atrybuty dla sesji pppoe klienta.
Pozdrawiam.
W dniu 02.01.2014 12:56, Łukasz Matys napisał(a):
Witam Panow. Nie zgodze sie. PPPoE duzo ulatwia. Jezeli ktos uzywa koncentratora pppoe (w moim przypadku np routerboard ccr), to limit predkosci mamy np za pomoca simple queue na interfejsie pppoe. Zatem czy jest tam ipv4, czy ipv6, a za 100 lat ipv16 - nie ma to znaczenia.
Idac dalej, mamy wdrozony testowo dual-stack, klienci maja jako CPE routerboardy mikrotika. Za pomoca sesji pppoe wstrzykujemy np /56 (min zalecenie od ripe) na interfejsie pppoe, i klientowi odpalamy autokonfiguracje na 'lan'ie'. Klient ma ipv4 i ipv6 - i wszystko w temacie. (na upartego mozna tez zrobic prefix delegation, ale moim zdaniem tracimy wowczas kontrole nad adresami ktore uzywa dany klient). W przypadku 'framed-ipv6-prefix' mamy koniec problemow z logowaniem polaczen klientow. Dany klient ma na stale /56 i dziekuje.
Czekam tylko az bede mogl podac z radiusa do koncentratora pppoe 'Framed-IPv6-Prefix - Ipv6 prefix assigned for the client.' Powinno pojawic sie w LMS'ie cos takiego jak 'wrutowany prefix ipv6 do cpe klienta'. Klikamy, generujemy sobie dla radiusa odpowiednie atrybuty dla sesji pppoe klienta.
Moim zdaniem można temat IPv6 rozwiązać w ten sposób, że dotychczasowo przypisany w LMS IPv4 potraktować jako część adresu sieci IPv6 (młodsze 32-bity adresu sieci IPv6).
Pozdrawiam.
-- Matys Łukasz mobile: (+ 48) 504257944 gg: 6808288
Witam. Bralem to pod uwage, niestety wowczas opcja 'porzadnego adresu planu' upada. Jezeli ktos zaczyna ipv6 bez adres planu to nie zycze powodzenia ;-).
Notka od ripe,
'3. OPTIONS WITHOUT AN ADDRESS PLAN
Small, flat organisations that do not have an internal organisational structure (with several departments within the organisation being authorised to assign IP addresses) or technical structure (distinguishing between various categories of use types and networks) can work without an address plan, instead assigning a random free IPv6 address as network host.
A disadvantage is that it can be difficult to recognise networks based on their address because this method lacks structure. For this reason, we recommend preparing an address plan.'
Uzywajac adres planu, ktory oparty jest na dzien dobry na typach uslug, lub lokalizacjach (lepiej na uslugach, wowczas optymalniej mozna zakladac filtry w korze), nie da sie tego dobrze zrobic korzystajac z 'direct ipv4 to ipv6 links'.
Pozdrawiam.
W dniu 2014-01-02 12:56, Łukasz Matys pisze:
Witam Panow. Nie zgodze sie. PPPoE duzo ulatwia. Jezeli ktos uzywa koncentratora pppoe (w moim przypadku np routerboard ccr), to limit predkosci mamy np za pomoca simple queue na interfejsie pppoe. Zatem czy jest tam ipv4, czy ipv6, a za 100 lat ipv16 - nie ma to znaczenia.
Tak , w tym przypadku. Co jak ktos ma osobną maszynkę do limitowania??
Idac dalej, mamy wdrozony testowo dual-stack, klienci maja jako CPE routerboardy mikrotika. Za pomoca sesji pppoe wstrzykujemy np /56 (min zalecenie od ripe) na interfejsie pppoe, i klientowi odpalamy autokonfiguracje na 'lan'ie'. Klient ma ipv4 i ipv6 - i wszystko w temacie. (na upartego mozna tez zrobic prefix delegation, ale moim zdaniem tracimy wowczas kontrole nad adresami ktore uzywa dany klient). W przypadku 'framed-ipv6-prefix' mamy koniec problemow z logowaniem polaczen klientow. Dany klient ma na stale /56 i dziekuje.
Dlaczego /56 a nie /64 - przecież klientowi INDYWIDUALNEMU TO POWINNO WYSTARCZYĆ. Co innego firma wtedy jest to zrozumiałe. /56 to bodajże 256 /64.
Jak ktoś nie jest LIR, to ile dają ?? /48 / 40 /32 ??
1. Mam inne zdanie na ten temat: - kazde ewentualne dokladanie prefixow klientowi to komplikacja i zbedny overhead routingu w korze - klient moglby pociachac /64, ale wowczas zapomnij o autokonfiguracji na wiekszosci urzadzen koncowych
2. No i chyba wypada sluchac RFC, a nie tworzyc wlasne teorie ;-).
"However, RFC 61771 (also known as Best Current Practice 157) changes this, and recommends using an address block / prefix size tailored to the end user's needs. It also recommends against giving out single addresses. For instance, a / 48 is much more than a home user needs, but a / 64 only allows for a single subnet, which may be limiting, if not immediately, then in the future. So
a / 56 or / 60 may be more appropriate for consumers."
Jak ktos nie jest LIR, to na potrzeby swojej organizacji dostajesz IPv6 PI /48, a dla klientow osobna pule IPv6 PA od LIR'a tyle ile potrzeba. Pozdrawiam.
W dniu 02.01.2014 13:16, Łukasz Matys pisze:
Jak ktos nie jest LIR, to na potrzeby swojej organizacji dostajesz IPv6 PI /48, a dla klientow osobna pule IPv6 PA od LIR'a tyle ile potrzeba. Pozdrawiam.
Myślę, że to podejście RIPE też blokuje wprowadzanie IPv6, bo np. ja nie będąc lirem mam opory przed braniem PA od kogoś...
Nic na to nie poradzisz, policy jest takie ze PI nie mozesz dac end userowi. Nie wierze ze jakis LIR odwazylby sie kombinowac - RIPE od razu by go wyprostowalo. Pozdrawiam.
W dniu 02.01.2014 13:30, Łukasz Matys pisze:
Nic na to nie poradzisz, policy jest takie ze PI nie mozesz dac end userowi. Nie wierze ze jakis LIR odwazylby sie kombinowac - RIPE od razu by go wyprostowalo. Pozdrawiam.
To do czego służy wniosek o PI-IPv6 jeśli nie właśnie dla klientów?, LIR nie dostaje PI tylko alokację na potrzeby swojej infrastruktury i PA klientów.
On 02 Jan 2014, at 14:21, Robert Rakowski robert@actus-info.pl wrote:
W dniu 02.01.2014 13:30, Łukasz Matys pisze:
Nic na to nie poradzisz, policy jest takie ze PI nie mozesz dac end userowi. Nie wierze ze jakis LIR odwazylby sie kombinowac - RIPE od razu by go wyprostowalo. Pozdrawiam.
To do czego służy wniosek o PI-IPv6 jeśli nie właśnie dla klientów?, LIR nie dostaje PI tylko alokację na potrzeby swojej infrastruktury i PA klientów.
Tutaj trzeba rozróżnić dwa pojęcia wg podejścia społeczności RIPE do tematu adresów.
Adresy mają dwa statusy:
- allocated - assigned
Status ALLOCATED ma blok adresów który jest przydzielany dla LIRa (PA) na jego potrzeby (bez rozróżnienia czy to infrastruktura LIRa czy sieć klienta LIRa), ten status nie oznacza że adresy są w użyciu a tylko sam fakt przydziału.
Status ASSIGNED oznacza że adresy ktore ten assignment pokrywa są w użyciu.
Patrząc od strony LIRa, dostaje on pule adresow (PA - domyślnie /32 w IPv6) z statusem ALLOCATED (który jest też w bazie RIPE). Z tej większej puli przydziela sobie siec np. /48 dla swojej infrastruktury i tworzy dla tego /48 obiekt w bazie RIPE z opisem kto używa adres i nadaje mu status ASSIGNED, tak samo przydziela klientowi podsieć robi dokładnie to samo czyli przydziela podsieć np. /56 i następnie tworzy obiekt w bazie RIPE z opisem kto używa i statusem ASSIGNED. I tak powoli przydziela do użytku sieci z swojej alokacji aż do momentu gdy alokacja zostaje wyczerpana więc prosi o następną od RIPE NCC pokazując w bazie RIPE jak dotychczas przydzielał adresacje jako dowód.
Teraz, różnica pomiędzy PI a PA jest taka że PI to ASSIGNMENT a PA to ALLOCATION. Adresacja PI jest dla podmiotów/osób które chcą niezależności adresacji od swojego dostawcy dla swojej infrastruktury. Głównym użytkownikiem adresacji PI są jakiekolwiek firmy lub organizacje ale nie dostawcy Internetu. Jeżeli chodzi o IPv6 dostawca ktory ma PI nie może jej przydzielić nikomu innemu ponieważ jego adresacja ma już status ASSIGNED i przydzielenie jej części innemu podmiotowi oznacza SUBASSIGNEMENT a to jest zabronione ponieważ oznacza że ta sama adresacja jest używana w dwóch miejscach. Aktualny dokument RIPE-552 (http://www.ripe.net/ripe/docs/ripe-552) w punkcie 7 ma specjalnie zaznaczone że "The PI assignment cannot be further assigned to other organisations". Jak to wygląda wizualnie można zobaczyć w materiałach szkoleniowych RIPE NCC (http://www.ripe.net/lir-services/training/material/IPv6-for-LIRs-Training-Co... strona 13).
Ktoś może powiedzieć pewnie że w IPv4 można było przydzielać _adresy_ klientom z puli PI. Jasne, będzie miał racje, ale tutaj wychodzą różnice pomiędzy IPv6 a IPv4. W IPv4 PI można było przydzielić klientowi _adres_ (a klient robi NAT) a jeden adres można uważać za część swojej infrastruktury (pule dla DSL czy nawet LAN, poprostu każdy klient ma jeden adres na routerze który zazwyczaj jest kontrolowany przez dostawce). Niestety w IPv6 nie przydzieli się klientowi jeden _adres_, zawsze przydziela się podsieć a wtedy ta sieć jest kontrolowana przez klienta i to jest uważane za SUBASSIGNEMENT i jest zabronione. Hostmasterzy bardzo na to zwracają uwagę i nie polecałbym nikomu naginać rzeczywistość bo "przyjaciel" waszej firmy może do RIPE NCC zglosić nadużycie i wtedy schody.
PS LIR też może otrzymać PI i wielu LIRow prosi o to aby mieć jasne rozróżnienie co jest ich infrastrukturą a co przydzielają klientom.
ok, z tymi assigned allocated, co jeśli klientowi nie dam podsieci, tylko kilka kolejnych adresów? te adresy będę kontrolował ja, nikt inny.
W dniu 7 stycznia 2014 15:05 użytkownik Andrzej Wolski taihen@taihen.org napisał:
On 02 Jan 2014, at 14:21, Robert Rakowski robert@actus-info.pl wrote:
W dniu 02.01.2014 13:30, Łukasz Matys pisze:
Nic na to nie poradzisz, policy jest takie ze PI nie mozesz dac end userowi. Nie wierze ze jakis LIR odwazylby sie kombinowac - RIPE od razu by go wyprostowalo. Pozdrawiam.
To do czego służy wniosek o PI-IPv6 jeśli nie właśnie dla klientów?, LIR nie dostaje PI tylko alokację na potrzeby swojej infrastruktury i PA klientów.
Tutaj trzeba rozróżnić dwa pojęcia wg podejścia społeczności RIPE do tematu adresów.
Adresy mają dwa statusy:
- allocated
- assigned
Status ALLOCATED ma blok adresów który jest przydzielany dla LIRa (PA) na jego potrzeby (bez rozróżnienia czy to infrastruktura LIRa czy sieć klienta LIRa), ten status nie oznacza że adresy są w użyciu a tylko sam fakt przydziału.
Status ASSIGNED oznacza że adresy ktore ten assignment pokrywa są w użyciu.
Patrząc od strony LIRa, dostaje on pule adresow (PA - domyślnie /32 w IPv6) z statusem ALLOCATED (który jest też w bazie RIPE). Z tej większej puli przydziela sobie siec np. /48 dla swojej infrastruktury i tworzy dla tego /48 obiekt w bazie RIPE z opisem kto używa adres i nadaje mu status ASSIGNED, tak samo przydziela klientowi podsieć robi dokładnie to samo czyli przydziela podsieć np. /56 i następnie tworzy obiekt w bazie RIPE z opisem kto używa i statusem ASSIGNED. I tak powoli przydziela do użytku sieci z swojej alokacji aż do momentu gdy alokacja zostaje wyczerpana więc prosi o następną od RIPE NCC pokazując w bazie RIPE jak dotychczas przydzielał adresacje jako dowód.
Teraz, różnica pomiędzy PI a PA jest taka że PI to ASSIGNMENT a PA to ALLOCATION. Adresacja PI jest dla podmiotów/osób które chcą niezależności adresacji od swojego dostawcy dla swojej infrastruktury. Głównym użytkownikiem adresacji PI są jakiekolwiek firmy lub organizacje ale nie dostawcy Internetu. Jeżeli chodzi o IPv6 dostawca ktory ma PI nie może jej przydzielić nikomu innemu ponieważ jego adresacja ma już status ASSIGNED i przydzielenie jej części innemu podmiotowi oznacza SUBASSIGNEMENT a to jest zabronione ponieważ oznacza że ta sama adresacja jest używana w dwóch miejscach. Aktualny dokument RIPE-552 (http://www.ripe.net/ripe/docs/ripe-552) w punkcie 7 ma specjalnie zaznaczone że "The PI assignment cannot be further assigned to other organisations". Jak to wygląda wizualnie można zobaczyć w materiałach szkoleniowych RIPE NCC (http://www.ripe.net/lir-services/training/material/IPv6-for-LIRs-Training-Co... strona 13).
Ktoś może powiedzieć pewnie że w IPv4 można było przydzielać _adresy_ klientom z puli PI. Jasne, będzie miał racje, ale tutaj wychodzą różnice pomiędzy IPv6 a IPv4. W IPv4 PI można było przydzielić klientowi _adres_ (a klient robi NAT) a jeden adres można uważać za część swojej infrastruktury (pule dla DSL czy nawet LAN, poprostu każdy klient ma jeden adres na routerze który zazwyczaj jest kontrolowany przez dostawce). Niestety w IPv6 nie przydzieli się klientowi jeden _adres_, zawsze przydziela się podsieć a wtedy ta sieć jest kontrolowana przez klienta i to jest uważane za SUBASSIGNEMENT i jest zabronione. Hostmasterzy bardzo na to zwracają uwagę i nie polecałbym nikomu naginać rzeczywistość bo "przyjaciel" waszej firmy może do RIPE NCC zglosić nadużycie i wtedy schody.
PS LIR też może otrzymać PI i wielu LIRow prosi o to aby mieć jasne rozróżnienie co jest ich infrastrukturą a co przydzielają klientom. -- Andrzej Wolski aka Taihen mailto/xmpp: taihen@taihen.org
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
On 07 Jan 2014, at 19:49, Marcin marcin@nicram.net wrote:
ok, z tymi assigned allocated, co jeśli klientowi nie dam podsieci, tylko kilka kolejnych adresów? te adresy będę kontrolował ja, nikt inny.
Nie wiem jak chciałbyś klientowi przydzielić w IPv6 kilka kolejnych adresów. W IPv4 nie jest to problemem i możesz uważać te parę adresów jako własna infrastruktura, tak długo jak nie jest to podsieć.
W dniu 2014-01-02 13:22, Paweł Rohde pisze:
W dniu 02.01.2014 13:16, Łukasz Matys pisze:
Jak ktos nie jest LIR, to na potrzeby swojej organizacji dostajesz IPv6 PI /48, a dla klientow osobna pule IPv6 PA od LIR'a tyle ile potrzeba. Pozdrawiam.
Myślę, że to podejście RIPE też blokuje wprowadzanie IPv6, bo np. ja nie będąc lirem mam opory przed braniem PA od kogoś...
Ale jako LIR płacisz "fajne pieniążki" do RIPE. A jak cię nie stać, to RIPE ma to w ...............
W dniu 02.01.2014 13:33, Arturz pisze:
W dniu 2014-01-02 13:22, Paweł Rohde pisze:
W dniu 02.01.2014 13:16, Łukasz Matys pisze:
Jak ktos nie jest LIR, to na potrzeby swojej organizacji dostajesz IPv6 PI /48, a dla klientow osobna pule IPv6 PA od LIR'a tyle ile potrzeba. Pozdrawiam.
Myślę, że to podejście RIPE też blokuje wprowadzanie IPv6, bo np. ja nie będąc lirem mam opory przed braniem PA od kogoś...
Ale jako LIR płacisz "fajne pieniążki" do RIPE. A jak cię nie stać, to RIPE ma to w ...............
nie będąc lirem też płacę za obiekty
W dniu 2014-01-02 13:35, Paweł Rohde pisze:
W dniu 02.01.2014 13:33, Arturz pisze:
W dniu 2014-01-02 13:22, Paweł Rohde pisze:
W dniu 02.01.2014 13:16, Łukasz Matys pisze:
Jak ktos nie jest LIR, to na potrzeby swojej organizacji dostajesz IPv6 PI /48, a dla klientow osobna pule IPv6 PA od LIR'a tyle ile potrzeba. Pozdrawiam.
Myślę, że to podejście RIPE też blokuje wprowadzanie IPv6, bo np. ja nie będąc lirem mam opory przed braniem PA od kogoś...
Ale jako LIR płacisz "fajne pieniążki" do RIPE. A jak cię nie stać, to RIPE ma to w ...............
nie będąc lirem też płacę za obiekty
A "odrobinkę" mniej ;-P
W dniu 2014-01-02 13:16, Łukasz Matys pisze:
- Mam inne zdanie na ten temat:
- kazde ewentualne dokladanie prefixow klientowi to komplikacja i zbedny overhead routingu w korze
- klient moglby pociachac /64, ale wowczas zapomnij o autokonfiguracji na wiekszosci urzadzen koncowych
- No i chyba wypada sluchac RFC, a nie tworzyc wlasne teorie ;-).
"However, RFC 61771 (also known as Best Current Practice 157) changes this, and recommends using an address block / prefix size tailored to the end user's needs. It also recommends against giving out single addresses. For instance, a / 48 is much more than a home user needs, but a / 64 only allows for a single subnet, which may be limiting, if not immediately, then in the future. So
a / 56 or / 60 may be more appropriate for consumers."
Jak ktos nie jest LIR, to na potrzeby swojej organizacji dostajesz IPv6 PI /48, a dla klientow osobna pule IPv6 PA od LIR'a tyle ile potrzeba. Pozdrawiam.
Acha. Dzięki. Zatem poczytam ;( Zatem indywidualny /56, firma /48 (/52)??
Ja podjalem decyzje ze u nas en-user/mala-firma bedzie mial /60. A duza firma ubiega sie o swoje /48 i nie masz problemu w adres planie. Pozdrawiam.
Nie próbowałem wdrażać, dlatego może moje pytanie wyda Ci się naiwne. Dlaczego muszą być dwa koncentratory? Czy nie może działać w trybie dual-stack? (jedna sesja, dwa protokoły)
W dniu 2 stycznia 2014 11:24 użytkownik Piotr Polok toplek@polok.plnapisał:
W dniu 2014-01-02 11:05, Robert Rakowski napisał(a):
W dniu 02.01.2014 10:15, Piotr Polok pisze:
W dniu 2014-01-02 09:56, Robert Rakowski napisał(a):
W dniu 02.01.2014 09:00, Piotr Polok pisze:
W dniu 2014-01-02 08:36, Robert Rakowski napisał(a):
Problemem nie są wdrożenia po stronie nazwijmy to hostów, tylko po stronie serverów, gdyż jeśliby ta adresacja działała po stronie serverów to naturalną rzeczą byłaby migracja ISP na IPv6 i tym sposobem pozbycie się NATów, naturalnie jedno wymusiło by drugie ;) ...
Teraz spójrz z punktu widzenia utrzymania serwera, i ISP/hostingu
utrzymującego infrastrukturę. Po co wdrażać IPv6 skoro użytkownicy i tak się łączą po IPv4 :).
Migracja musi się zacząć od strony serverów, gdyż nie będzie takiego klienta który będzie chciał internet na IPv6 bo większość internetu po prostu nie będzie działać. Tutaj jest pole do popisu dla UKE aby wymusiła działanie na zarządzających serverami ;). Jednak zgadzam się jest to trochę patowa sytuacja.
Patrząc od strony jakiejś racjonalności to rozwiązaniem byłoby przydzielanie klientowi podwójnej adresacji równolegle IPv4 oraz IPv6. Wtedy można by powiedzieć że po naszej (ISP) stronie IPv6 jest wdrożone choć funkcjonalności nie ma ;).
Wszystko oczywiście zależy od przyjętej koncepcji konfiguracji sieci, jednak z różnych powodów technicznie wydaje się to trudne/skomplikowane do wdrożenia, no chyba że jest jakiś prosty i mało obciążający maszyny pomysł, którego nie widzę ...
Przyznam od jakiegoś czasu przygotowuję się do przydzielania podwójnej
adresacji. Większym problemem niż po co i jak po stronie ISP może być po stronie klienta. Większość znanych mi routerów domowych ma takie wsparcie dla ipv6, że najwyżej markerem na obudowie można skonfigurować. :)
u nas wszyscy klienci mają dzierżawione od nas routery Mikrotika, więc ze wsparciem IPv6 niema problemu, ale i tak technicznie jest to trudne: -musiałyby być 2 koncentratory PPPoE jeden co rozdaje IPv4, drugi IPv6, -shapper który tnie klientom pasmo musiałby ciąć po adresie MAC, niezależnie od tego jaki ma adres IP, -klient musiałby mieć 2 klienty PPPoE pobierające adresy z różnych 'service', -routing na urządzeniu klienta musiałby wiedzieć jakie zasoby sieciowe są dostępne na IPv4 a jakie po IPv6, tak aby wiedzieć gdzie kierować ruch.
wygląda na to że ostatni wymóg dyskwalifikuje tą koncepcję, czy masz jakiś inny pomysł na to ?
-- pozdrawiam Piotr Polok
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
W dniu 2014-01-02 08:02, Piotr Polok pisze:
W dniu 2014-01-02 07:46, Arturz napisał(a):
W dniu 2014-01-01 22:05, Piotr Polok pisze:
W dniu 2014-01-01 22:01, Marcin napisał(a):
W dniu 1 stycznia 2014 21:56 użytkownik Piotr Polok toplek@polok.pl napisał:
Jest ku temu jakaś podstawa prawna, czy to jest po prostu prośba prezesa UKE ?
Taka sama podstawa prawna jak robienie raportu SIIS, czyli przekazywanie danych, które po kliknięciu "wyślij" robią się danymi publicznymi i każdy może o nie UKE poprosić a te musi je podać - ot taka podstawa prawna.
Reasumując niema wymogu wdrożenia IPv6 ;).
Powiedz jeszcze, że SIIS olewasz?? Niestety IPV6 powinniśmy posiadać. Potem to i chociazby nat (ew. tunel) z tego zrobić, ale mieć trzeba ;(
Nie ma znaczenia czy olewam czy nie, jak dla mnie pośpiechu niema gdyż i tak jest to bezużyteczne na ten moment.
Nigdzie nie twierdze że jest inaczej niż Ty piszesz ;) Raczej chodzi mi, o to aby "coś" mieć na wypadek kontroli.
W dniu 2014-01-02 08:47, Arturz napisał(a):
W dniu 2014-01-02 08:02, Piotr Polok pisze:
W dniu 2014-01-02 07:46, Arturz napisał(a):
W dniu 2014-01-01 22:05, Piotr Polok pisze:
W dniu 2014-01-01 22:01, Marcin napisał(a):
W dniu 1 stycznia 2014 21:56 użytkownik Piotr Polok toplek@polok.pl napisał:
Jest ku temu jakaś podstawa prawna, czy to jest po prostu prośba prezesa UKE ?
Taka sama podstawa prawna jak robienie raportu SIIS, czyli przekazywanie danych, które po kliknięciu "wyślij" robią się danymi publicznymi i każdy może o nie UKE poprosić a te musi je podać - ot taka podstawa prawna.
Reasumując niema wymogu wdrożenia IPv6 ;).
Powiedz jeszcze, że SIIS olewasz?? Niestety IPV6 powinniśmy posiadać. Potem to i chociazby nat (ew. tunel) z tego zrobić, ale mieć trzeba ;(
Nie ma znaczenia czy olewam czy nie, jak dla mnie pośpiechu niema gdyż i tak jest to bezużyteczne na ten moment.
Nigdzie nie twierdze że jest inaczej niż Ty piszesz ;) Raczej chodzi mi, o to aby "coś" mieć na wypadek kontroli.
Jeśli niema wymogu prawnego to i nie mają czego kontrolować, nie upieram się że tego ma nie być, tylko że niema pośpiechu bo i tak funkcjonalność nie będzie funkcjonalna ;)
Mieliśmy jakiś czas temu kontrole UKE, w prawdzie w temacie dokumentacji, jednak o IPv6 nie wspominali. Pomijając poprawną dokumentację to oczekiwali wskaźników jakościowych takich jak na przykład tutaj: http://www.polineo.pl/wskazniki_jakosciowe.php
uczestnicy (13)
-
Andrzej Wolski -
Arkadiusz Szlękowski -
Arturz -
Marcin -
Paweł Rohde -
Piotr Polok -
Przemysław Bryniak -
Rafał Ramocki -
Robert Rakowski -
Sławomir Paszkiewicz -
Tomasz Chiliński -
Tomasz Chiliński -
Łukasz Matys