Dotaz: IPv6 - 6to4, radvd a problem se strankami www.nic.cz

[hermelin]

Zdravim

Chtel jsem se zeptat zda nekdo netusite v cem je problem, ze po nastaveni 6to4 na routeru podle navodu http://www.nic.cz/6to4/ a spusteni radvd demona, prestaly fungovat stranky www.nic.cz (i www.dnssec.cz) pro PC vnitrni site (ktere IPv6 pouzivaji). Jinak ipv6.google.com jede bez problemu, www.ipv6-test.com take v poradku.

Pokud na routeru zadam:

nc6 www.nic.cz 80

tak mi to vypise html kod.

Kdyz to ale udelam na stanici za routerem tak to nevypise nic. Dalsi zajimavosti je: ping6 www.nic.cz funguje jak na routeru tak na stanicich ale IP6 adresa je na kazdem jina (pritom oba pouzivaji stejny DNS server).

router:

64 bytes from 2002:d91f:cd32::1: icmp_seq=1 ttl=64 time=15.1 ms

stanice:

64 bytes from 2001:1488:0:3::2: icmp_seq=1 ttl=63 time=16.4 ms

Hledal bych chybu v radvd.conf, DNS nebo firewallu ale me zarazi to ze nefunguji pouze stranky od nic.cz jinak ostatni ipv6 stranky chodi bez nejmensiho problemu.

Diky za pomoc

---

---

Odpovědi

[NN]

2002 je 6to4 prefix, neni to nahodou tvoje brana..

NN

[hermelin]

Neni - je to ip NICu - 217.31.205.50

[pavlix]

To se nevylučuje, spíš naopak.

[pavlix]

A pardon, neprohlédl jsem ji pořádně, a není NIC (Network Interface Card) jako NIC (CZ.NIC).

[Jarda]

Já jsem při něčem podobném snižoval MTU pro IPv6 rozhraní (sit0):

ip link set dev sit0 mtu 1280.

Pak se to zlepšilo, dnssec.cz je ok, ale nic.cz se stále nedostanu...

[Jarda]

Sorry, kecám. Jde nix.cz (panáček se směje a má zelenou ), nic.cz a dnssec.cz nejdou.

[hermelin]

Tak to mas uplne stejny problem jako ja. Ted jenom zjistit v cem je zakopany pes. NIX mam taky uplne v pohode (zeleneho panacka )

Vypada opravdu pouze na problem z IPv6 siti NICu.

A mam dalsi novinku - dokonce mi ze vnitrniho PC nejde ani whois ceskych domen

[pavlix]

Teoreticky, můžu mít problém s routováním do 6to4. Ale v tom případě by bylo nejlepší jim napsat, a třeba se i odkázat na diskuzi, pokud ji někdo od nich nenajde sám. Takové věci se tu občas řeší.

Pak je tu ještě (snad i větší) šance, že je něco špatně nakonfigurováno u tebe a holt se to projevuje jen v některých případech.

Doporučuju zkusit tcpdump na vnějším rozhraní routeru a postnost sem všecko, co se týká ICMP(v6).

[hates]

Hlasim uplne stejny problem. Tak a ted jdu hledat v cem je zakopany pes

[pavlix]

Moc mě zajímá ten DUMP.

[hermelin]

Prave abych neotravoval na NICu tak jsem se nejprve zeptal tady jestli ma nekdo podobny problem

Co se tyka tcpdump tak na vnejsim rozhrani se neda IPv6 dumpovat kdyz to jde skrze IPv4 tunel.

Na internim to vypada nejak takto

20:30:56.281690 IP6 fe80::21d:60ff:fe74:xxxx > ff02::1: ICMP6, router advertisement, length 56
20:31:01.427932 IP6 fe80::21d:60ff:fe74:xxxx > ff02::1: ICMP6, router advertisement, length 56
20:31:02.711026 IP6 xxxx:xxxx:xxx:1:18c4:74c1:xxx:769.1041 > 2002:d91f:cd32::1.http: S 7522974:7522974(0) win 16384 <\mss 1440>
20:31:02.745220 IP6 fe80::21d:60ff:fe74:xxxx > ff02::1:xxxx:769: ICMP6, neighbor solicitation, who has xxxx:xxxx:xxx:1:18c4:74c1:xxxx:769, length 32
20:31:02.745698 IP6 xxxx:xxxx:xxxx:1:18c4:74c1:xxxx:769 > fe80::21d:60ff:fe74:xxxx: ICMP6, neighbor advertisement, tgt is xxxx:xxxx:xxx:1:18c4:74c1:xxxx:769, length 32
20:31:02.745714 IP6 2002:d91f:cd32::1.http > xxxx:xxxx:xxx:1:18c4:74c1:xxxx:769.1041: S 2414926498:2414926498(0) ack 7522975 win 5680 <\mss 1420>
20:31:02.746235 IP6 xxxx:xxxx:xxx:1:18c4:74c1:xxxx:769.1041 > 2002:d91f:cd32::1.http: . ack 1 win 17040
20:31:02.746294 IP6 xxxx:xxxx:xxx:1:18c4:74c1:xxxx:769.1041 > 2002:d91f:cd32::1.http: P 1:455(454) ack 1 win 17040
20:31:02.789017 IP6 2002:d91f:cd32::1.http > xxxx:xxxx:xxx:1:18c4:74c1:xxxx:769.1041: . ack 455 win 6432
20:31:05.800936 IP6 fe80::21d:60ff:fe74:xxxx > ff02::1: ICMP6, router advertisement, length 56

[pavlix]

Co se tyka tcpdump tak na vnejsim rozhrani se neda IPv6 dumpovat kdyz to jde skrze IPv4 tunel.

Já měl za to, že mi to tcpdump (nevím verzi) rozklíčoval až na IPv6.

20:31:02.711026 IP6 xxxx:xxxx:xxx:1:18c4:74c1:xxx:769.1041 > 2002:d91f:cd32::1.http: S 7522974:7522974(0) win 16384 <\mss 1440>

1041 se mi zdá jako neuvěřitelně nízký port na klientskou stranu.

Podle všeho má www.nic.cz dvě IPv6 adresy:

$ host www.nic.cz
www.nic.cz has address 217.31.205.50
www.nic.cz has IPv6 address 2002:d91f:cd32::1
www.nic.cz has IPv6 address 2001:1488:0:3::2

Z toho jedna je 6to4 odpovícající veřejné IPv4, že.

Jestli správně chápu RFC 3484, tak by počítač se zdrojovou 6to4 adresou měl preferovat cílovou adresu 6to4, což aspoň na straně klienta preferuje.

Rule 5: Prefer matching label.

If Label(Source(DA)) = Label(DA) and Label(Source(DB)) <> Label(DB), then prefer DA. Similarly, if Label(Source(DA)) <> Label(DA) and Label(Source(DB)) = Label(DB), then prefer DB.

Jinak s nativní adresou se připojuju bez problémů na obojí:

$ nc -6 -v 2001:1488:0:3::2 80
Connection to 2001:1488:0:3::2 80 port [tcp/http] succeeded!
$ nc -6 -v 2002:d91f:cd32::1 80
Connection to 2002:d91f:cd32::1 80 port [tcp/http] succeeded!

Takže pokud to nefunguje pouze lidem se 6to4, problém může být buď u CZ.NIC, nebo na straně lidí s 6to4. Doporučuju radši zkouknout IPv4 i IPv6 firewall, případně udělat test s oběma vypnutými.

Ještě bych zkusil traceroute6. Pak stojí za zkoušku dávat volbu -s programu ping6 a zkusit jak velký paket projde. Případně dokonce zkusmo snížit MTU u nějakého klienta a otestovat s nižším.

Ale určitě bych se nebál komunikovat i s CZ.NIC.

[pavlix]

Dočasně jsem si nastavil 6to4 na stroji, kde je globální IPv4 i IPv6.

Dopadlo to následovně:

$ ping6 2002:d91f:cd32::1
PING 2002:d91f:cd32::1(2002:d91f:cd32::1) 56 data bytes
64 bytes from 2002:d91f:cd32::1: icmp_seq=1 ttl=64 time=5.04 ms
64 bytes from 2002:d91f:cd32::1: icmp_seq=2 ttl=64 time=5.24 ms
64 bytes from 2002:d91f:cd32::1: icmp_seq=3 ttl=64 time=3.38 ms

23:20:25.193391 IP6 2002:54f6:a172::1 > 2002:d91f:cd32::1: ICMP6, echo request, seq 1, length 64
23:20:25.198372 IP6 2002:d91f:cd32::1 > 2002:54f6:a172::1: ICMP6, echo reply, seq 1, length 64
23:20:26.194743 IP6 2002:54f6:a172::1 > 2002:d91f:cd32::1: ICMP6, echo request, seq 2, length 64
23:20:26.199919 IP6 2002:d91f:cd32::1 > 2002:54f6:a172::1: ICMP6, echo reply, seq 2, length 64
23:20:27.196190 IP6 2002:54f6:a172::1 > 2002:d91f:cd32::1: ICMP6, echo request, seq 3, length 64
23:20:27.199508 IP6 2002:d91f:cd32::1 > 2002:54f6:a172::1: ICMP6, echo reply, seq 3, length 64

Tzn, zafungovala preference 6to4 adresy.

Pokud jde o HTTP...

# nc -6 -v 2002:d91f:cd32::1 80
nc: 2002:d91f:cd32::1 (2002:d91f:cd32::1) 80 [www] open

23:27:11.036775 IP6 2002:54f6:a172::1.44379 > 2002:d91f:cd32::1.www: Flags [S], seq 2763135321, win 5680, options [mss 1420,sackOK,TS val 180153199 ecr 0,nop,wscale 4], length 0
23:27:11.041637 IP6 2002:d91f:cd32::1.www > 2002:54f6:a172::1.44379: Flags [S.], seq 1393182434, ack 2763135322, win 5632, options [mss 1420,sackOK,TS val 1644033031 ecr 180153199,nop,wscale 7], length 0
23:27:11.041805 IP6 2002:54f6:a172::1.44379 > 2002:d91f:cd32::1.www: Flags [.], ack 1, win 355, options [nop,nop,TS val 180153201 ecr 1644033031], length 0
23:27:14.829449 IP6 2002:54f6:a172::1.44379 > 2002:d91f:cd32::1.www: Flags [F.], seq 1, ack 1, win 355, options [nop,nop,TS val 180154148 ecr 1644033031], length 0
23:27:14.833638 IP6 2002:d91f:cd32::1.www > 2002:54f6:a172::1.44379: Flags [F.], seq 1, ack 2, win 44, options [nop,nop,TS val 1644033411 ecr 180154148], length 0
23:27:14.833771 IP6 2002:54f6:a172::1.44379 > 2002:d91f:cd32::1.www: Flags [.], ack 2, win 355, options [nop,nop,TS val 180154149 ecr 1644033411], length 0

Takže u mě žádný problém.

Testuju s konfigurací:

# ip -6 address | grep 2002
    inet6 2002:54f6:a172::1/16 scope global 
# ip -6 route | grep 2002
2002::/16 dev sit0  proto kernel  metric 256  mtu 1480 advmss 1420 hoplimit 0

Je to nevyužitý počítač s Debianem squeeze (testing).

[hermelin]

Nevim jestli si spravne rozumime.

Me to na routeru kde je tunel nastaveny take funguje ale uz to nefunguje na vnitrnich stanicich za routerem kdyz je spusteny radvd reps. kdyz vnitrni stanice ziskavaji IP6 skrze radvd.

[pavlix]

Pravda, byl jsem unavený, vyzkouším.

[pavlix]

Z IPv6-only klienta konfigurovaného pomocí radvd:

test:~# ping6 -c 1 www.nic.cz
PING www.nic.cz(2002:d91f:cd32::1) 56 data bytes
64 bytes from 2002:d91f:cd32::1: icmp_seq=1 ttl=63 time=4.26 ms

--- www.nic.cz ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 4.266/4.266/4.266/0.000 ms
test:~# nc6 -v www.nic.cz 80
nc6: 2002:d91f:cd32::1 (2002:d91f:cd32::1) 80 [www] open
^C
test:~# curl -v -I http://www.nic.cz/
* About to connect() to www.nic.cz port 80 (#0)
*   Trying 2002:d91f:cd32::1... connected
* Connected to www.nic.cz (2002:d91f:cd32::1) port 80 (#0)
> HEAD / HTTP/1.1
> User-Agent: curl/7.18.2 (i486-pc-linux-gnu) libcurl/7.18.2 OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.8 libssh2/0.18
> Host: www.nic.cz
> Accept: */*
> 
< HTTP/1.1 200 OK
HTTP/1.1 200 OK

Pro jistotu přidávám i dump:

10:27:23.585264 IP6 2002:54f6:a172:1:70a1:63ff:fe33:cb6 > 2002:d91f:cd32::1: ICMP6, echo request, seq 1, length 64
10:27:23.589410 IP6 2002:d91f:cd32::1 > 2002:54f6:a172:1:70a1:63ff:fe33:cb6: ICMP6, echo reply, seq 1, length 64
10:27:30.165737 IP6 2002:54f6:a172:1:70a1:63ff:fe33:cb6.47610 > 2002:d91f:cd32::1.80: Flags [S], seq 3032584461, win 5760, options [mss 1440,sackOK,TS val 190057990 ecr 0,nop,wscale 4], length 0
10:27:30.170167 IP6 2002:d91f:cd32::1.80 > 2002:54f6:a172:1:70a1:63ff:fe33:cb6.47610: Flags [S.], seq 1676351567, ack 3032584462, win 5632, options [mss 1420,sackOK,TS val 1647994945 ecr 190057990,nop,wscale 7], length 0
10:27:30.170235 IP6 2002:54f6:a172:1:70a1:63ff:fe33:cb6.47610 > 2002:d91f:cd32::1.80: Flags [.], ack 1, win 360, options [nop,nop,TS val 190057991 ecr 1647994945], length 0
10:27:31.547976 IP6 2002:54f6:a172:1:70a1:63ff:fe33:cb6.47610 > 2002:d91f:cd32::1.80: Flags [F.], seq 1, ack 1, win 360, options [nop,nop,TS val 190058336 ecr 1647994945], length 0
10:27:31.552831 IP6 2002:d91f:cd32::1.80 > 2002:54f6:a172:1:70a1:63ff:fe33:cb6.47610: Flags [F.], seq 1, ack 2, win 44, options [nop,nop,TS val 1647995083 ecr 190058336], length 0
10:27:31.552927 IP6 2002:54f6:a172:1:70a1:63ff:fe33:cb6.47610 > 2002:d91f:cd32::1.80: Flags [.], ack 2, win 360, options [nop,nop,TS val 190058337 ecr 1647995083], length 0
10:27:33.306395 IP6 2002:54f6:a172:1:70a1:63ff:fe33:cb6.47611 > 2002:d91f:cd32::1.80: Flags [S], seq 1878728742, win 5760, options [mss 1440,sackOK,TS val 190058775 ecr 0,nop,wscale 4], length 0
10:27:33.309709 IP6 2002:d91f:cd32::1.80 > 2002:54f6:a172:1:70a1:63ff:fe33:cb6.47611: Flags [S.], seq 514882641, ack 1878728743, win 5632, options [mss 1420,sackOK,TS val 1647995259 ecr 190058775,nop,wscale 7], length 0
10:27:33.309802 IP6 2002:54f6:a172:1:70a1:63ff:fe33:cb6.47611 > 2002:d91f:cd32::1.80: Flags [.], ack 1, win 360, options [nop,nop,TS val 190058776 ecr 1647995259], length 0
10:27:33.310356 IP6 2002:54f6:a172:1:70a1:63ff:fe33:cb6.47611 > 2002:d91f:cd32::1.80: Flags [P.], seq 1:163, ack 1, win 360, options [nop,nop,TS val 190058776 ecr 1647995259], length 162
10:27:33.315637 IP6 2002:d91f:cd32::1.80 > 2002:54f6:a172:1:70a1:63ff:fe33:cb6.47611: Flags [.], ack 163, win 53, options [nop,nop,TS val 1647995259 ecr 190058776], length 0
10:27:33.815006 IP6 2002:d91f:cd32::1.80 > 2002:54f6:a172:1:70a1:63ff:fe33:cb6.47611: Flags [P.], seq 1:474, ack 163, win 53, options [nop,nop,TS val 1647995309 ecr 190058776], length 473
10:27:33.815118 IP6 2002:54f6:a172:1:70a1:63ff:fe33:cb6.47611 > 2002:d91f:cd32::1.80: Flags [.], ack 474, win 427, options [nop,nop,TS val 190058902 ecr 1647995309], length 0
10:27:33.816673 IP6 2002:54f6:a172:1:70a1:63ff:fe33:cb6.47611 > 2002:d91f:cd32::1.80: Flags [F.], seq 163, ack 474, win 427, options [nop,nop,TS val 190058903 ecr 1647995309], length 0
10:27:33.820684 IP6 2002:d91f:cd32::1.80 > 2002:54f6:a172:1:70a1:63ff:fe33:cb6.47611: Flags [F.], seq 474, ack 164, win 53, options [nop,nop,TS val 1647995310 ecr 190058903], length 0
10:27:33.820787 IP6 2002:54f6:a172:1:70a1:63ff:fe33:cb6.47611 > 2002:d91f:cd32::1.80: Flags [.], ack 475, win 427, options [nop,nop,TS val 190058904 ecr 1647995310], length 0

Takže bych řekl, že to bude konfigurační problém na tvojí straně, CZ.NIC má zdá se vše v pořádku, tedy až na DNS.

/etc/radvd.conf používám jednoduchý (br1 protože virtuální stroj na bridge):

interface br1
{
        AdvSendAdvert on;
        prefix 2002:54f6:a172:1::/64
        {
                AdvOnLink on;
                AdvAutonomous on;
        };
};

Důležité routy na routeru (na testování 6to4 netřeba default, stačí 2002::/16):

2002:54f6:a172:1::/64 dev br1  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 0
2002::/16 dev sit0  proto kernel  metric 256  mtu 1480 advmss 1420 hoplimit 0

Zkoušel jsi ten traceroute(6), jak jsem ti radil, nebo se namáhám zbytečně?

[pavlix]

To DNS u CZ.NIC prosím ignorujte, to mi v komentáři zůstalo omylem a problémy s DNS byly jen chvilkové, příčina byla ve špatných routách u mě.

[hermelin]

Ne nesnazis - diky moc za ochotu.

z routeru:

traceroute to www.nic.cz (2001:1488:0:3::2) from 2002:5892:cb9::1, 30 hops max, 24 byte packets
 1  2002:c058:6301::1 (2002:c058:6301::1)  14.59 ms  14.942 ms  16.866 ms
 2  2001:1488::1 (2001:1488::1)  14.852 ms  15.582 ms  14.712 ms
 3  2001:1488::1 (2001:1488::1)  15.23 ms !S  17.289 ms !S  14.87 ms !S

ze stanice (bohuzel ted nejsem na miste a bezi pouze XP):

Vypis trasy k www.nic.cz [2001:1488:0:3::2]
1 1ms < 1ms < 1ms  2002:58xx:xxxx::1
2 15ms 15ms 15ms 2002:c058:6301::1
3 17ms  16ms 16ms 2001:1488::1
4 * * * Vyprsel casovy limit zadosti

[pavlix]

Nechtěl jsem být nepříjemný, ale ten traceroute byl celkem důležitý.

Zatím příčinu nevidím, ale pro ukázku posílám ještě jak vypadá ping na tcpdumpu na vnějším rozhraní. Prosím ověřit, jestli se lišíme.

13:20:35.487988 IP 84.246.161.114 > 217.31.205.50: IP6 2002:54f6:a172:1:70a1:63ff:fe33:cb6 > 2002:d91f:cd32::1: ICMP6, echo request, seq 10, length 64
13:20:35.492198 IP 217.31.205.50 > 84.246.161.114: IP6 2002:d91f:cd32::1 > 2002:54f6:a172:1:70a1:63ff:fe33:cb6: ICMP6, echo reply, seq 10, length 64
13:20:36.490012 IP 84.246.161.114 > 217.31.205.50: IP6 2002:54f6:a172:1:70a1:63ff:fe33:cb6 > 2002:d91f:cd32::1: ICMP6, echo request, seq 11, length 64
13:20:36.496011 IP 217.31.205.50 > 84.246.161.114: IP6 2002:d91f:cd32::1 > 2002:54f6:a172:1:70a1:63ff:fe33:cb6: ICMP6, echo reply, seq 11, length 64
13:20:37.491306 IP 84.246.161.114 > 217.31.205.50: IP6 2002:54f6:a172:1:70a1:63ff:fe33:cb6 > 2002:d91f:cd32::1: ICMP6, echo request, seq 12, length 64
13:20:37.496492 IP 217.31.205.50 > 84.246.161.114: IP6 2002:d91f:cd32::1 > 2002:54f6:a172:1:70a1:63ff:fe33:cb6: ICMP6, echo reply, seq 12, length 64

Tedy samozřejmě mimo mé a tvé veřejné adresy, ta se lišit musí.

[pavlix]

traceroute to www.nic.cz (2001:1488:0:3::2) from 2002:5892:cb9::1, 30 hops max, 24 byte packets
 1  2002:c058:6301::1 (2002:c058:6301::1)  14.59 ms  14.942 ms  16.866 ms
 2  2001:1488::1 (2001:1488::1)  14.852 ms  15.582 ms  14.712 ms
 3  2001:1488::1 (2001:1488::1)  15.23 ms !S  17.289 ms !S  14.87 ms !S

A, tak přecijen něco. Je tam špatná adresa.

Při pingu ze stroje s 6to4 na jiný stroj, který má alespoň jednu 6to4 adresu, se má vybrat cíl 6to4, už jsem o tom výše psal.

Doporučuju HTTP zkusit přímo na IP, například:

test:~# curl -g -I http://[2002:d91f:cd32::1]/
HTTP/1.1 302 Found
Date: Sat, 29 Jan 2011 12:29:58 GMT
Server: Apache/2.2.8 (Ubuntu) mod_fastcgi/2.4.6 mod_python/3.3.1 Python/2.5.2 mod_ssl/2.2.8 OpenSSL/0.9.8g
Location: http://www.nic.cz/
Content-Type: text/html; charset=iso-8859-1

Jinak na skrývání IPv4 uvnitř IPv6 už se můžeš vykašlat, stejně jsi ji už jednou zapomněl. Spíš tam pak nahoď nějaký stavový firewall, na IPv4 i IPv6 a u toho, co otevřeš si hlídej klíče/hesla.

[hermelin]

K tem IP - ne ze bych chtel pred Vama neco tajit ale spis az to zindexuje nejakej chytrej vyhledavac aby nebyly vsude na netu moje prefixy apod

Curl na routeru:

curl -g -I http://[2002:d91f:cd32::1]/
HTTP/1.1 302 Found
Date: Sat, 29 Jan 2011 12:54:36 GMT
Server: Apache/2.2.8 (Ubuntu) mod_fastcgi/2.4.6 mod_python/3.3.1 Python/2.5.2 mod_ssl/2.2.8 OpenSSL/0.9.8g
Location: http://www.nic.cz/
Content-Type: text/html; charset=iso-8859-1

Curl na stanici

curl -g -I http://[2002:d91f:cd32::1]/
HTTP/1.1 302 Found
Date: Sat, 29 Jan 2011 12:52:47 GMT
Server: Apache/2.2.8 (Ubuntu) mod_fastcgi/2.4.6 mod_python/3.3.1 Python/2.5.2 mod_ssl/2.2.8 OpenSSL/0.9.8g
Location: http://www.nic.cz/
Content-Type: text/html; charset=iso-8859-1

Takze to slape dobre. Me prijde jako kdyby se stranky NICu neustale smerovali sami do sebe (vlezu na nic.cz a tam se udelal redirect na nic.cz atd atd) protoze prohlizec chybu nehodi - pouze se porad snazi nacist stranku.

Jeste me napadlo: nemuze byt problem v tom ze je to za dvojnasobnym NATem ? Ale me proste udivuje to ze ipv6 funguje vsude ok jenom u nic.cz pres ktery jsem vlastne tunelem pripojeny to nejde.

[pavlix]

Takze to slape dobre. Me prijde jako kdyby se stranky NICu neustale smerovali sami do sebe (vlezu na nic.cz a tam se udelal redirect na nic.cz atd atd) protoze prohlizec chybu nehodi - pouze se porad snazi nacist stranku.

To je jen redirect z IP adresy na pojmenovanou stránku, to je v pořádku.

Zkus to samé, ale bez parametru -I, případně, pokud se nic zajímavého nedozvíš, přijdej -v. Já už mám teďka podezřejní, že se zařídne odpověď od CZ.NIC někde u Volného. Jak to funguje na IPv4? Vypisuje něco "iptables -L -t mangle"?

Jeste me napadlo: nemuze byt problem v tom ze je to za dvojnasobnym NATem ? Ale me proste udivuje to ze ipv6 funguje vsude ok jenom u nic.cz pres ktery jsem vlastne tunelem pripojeny to nejde.

Takhle, 6to4 funguje na veřejné adrese. Takže záleží na typu NATu. Za dvojtou čistou maškarádou by to třeba nefungovalo, ale vůbec.

Co je přesně v tomhle případě myšleno dvojtým NATem a proč se vůbec řeší souvislost NAT a 6to4? 6to4 jako takové totiž za NATem funguje/nefunguje, podle toho, jestli NAT doručuje protokol 41 (IPv6 in IPv4). IP maškaráda tradičně řeší pouze TCP, UDP, přidružené chybové zprávy a ICMP ECHO, ne zapouzdřené IPv6.

[hermelin]

curl -g http://www.nic.cz
^C
root@exchg:/opt# curl -g http://[2002:d91f:cd32::1]/
<\!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<\html><\head>
<\title>302 Found<\/title>
<\/head><\body>
<\h1>Found<\/h1>
<\p>The document has moved <\a href="http://www.nic.cz/">here<\/a>.<\/p>
<\hr>
<\address>Apache/2.2.8 (Ubuntu) mod_fastcgi/2.4.6 mod_python/3.3.1 Python/2.5.2 mod_ssl/2.2.8 OpenSSL/0.9.8g Server at 2002:d91f:cd32::1 Port 80<\/address>
<\/body><\/html>

Dvojnasobny natem myslim ze je ADSL modem na kterem je nastaveno aby vsechno prichozi smeroval na vnitrni IP kde je nas router, pres ktery je pripojena vnitrni sit (trosku takovy hybrid). Kdyby neslo 6to4 vubec tak to vubec neresim a prikladam tomuhle ale me zarazi ze vse funguje ok a je problem pouze s nic.cz

[pavlix]

Dvojnasobny natem myslim ze je ADSL modem na kterem je nastaveno aby vsechno prichozi smeroval na vnitrni IP kde je nas router, pres ktery je pripojena vnitrni sit (trosku takovy hybrid).

To by mělo jít přežít.

curl -g http://www.nic.cz
^C
root@exchg:/opt# curl -g http://[2002:d91f:cd32::1]/
<\!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">

No jo, to je pořád o tom, že na těch holých IP není nic zajímavého.

Ještě bych zkusil "curl -v http://www.nic.cz/". Měl by ukázat, že se spojilo a zůstat viset až při čekání na data.

Pokud problém zůstane, až půjde ping6 na tvůj router (což mi nejde), nezbývá než kouknout na toto vlákno, začít prudit poskytovatele, a případně hledat workaround pro IPv6. Ale jestli je to tak, tak nejspíš ADSL modem ten workaround dělá aspoň pro IPv4, jinak bys měl problémy i s tím.

Ale dokud nejde ani ten ping, není vůbec jasné v čem je problém. Ten ping by to chtělo napravit.

Kdyby neslo 6to4 vubec tak to vubec neresim a prikladam tomuhle ale me zarazi ze vse funguje ok a je problem pouze s nic.cz

Tak vyzkoušej další, třeba i ipv6.google.com info.nix.cz, apod.

[hermelin]

root@exchg:~# curl -v http://www.nic.cz/
* About to connect() to www.nic.cz port 80 (#0)
*   Trying 2002:d91f:cd32::1... connected
* Connected to www.nic.cz (2002:d91f:cd32::1) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.21.0 (x86_64-pc-linux-gnu) libcurl/7.21.0 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.15 libssh2/1.2.5
> Host: www.nic.cz
> Accept: */*
> 

Jinak ping uz by ti mel jit. Nicmene nic.cz stale nefunguje. Je to fakt divny

[pavlix]

Chmm, tak to nebude MTU, ale problém s 6to4 osobně.

Jinak ping uz by ti mel jit.

Tož to mi už jde, z nativní adresy :).

Ale z toho 6to4 mi to pořád nejde, nemáš to zakázané na firewallu?

19:13:26.875829 IP 84.246.161.114 > 88.146.a.b: IP6 2002:54f6:a172::1 > 2002:5892:xyz::1: ICMP6, echo request, seq 15, length 64
19:13:27.875768 IP 84.246.161.114 > 88.146.a.b: IP6 2002:54f6:a172::1 > 2002:5892:xyz::1: ICMP6, echo request, seq 16, length 64
19:13:28.875802 IP 84.246.161.114 > 88.146.a.b: IP6 2002:54f6:a172::1 > 2002:5892:xyz::1: ICMP6, echo request, seq 17, length 64
19:13:29.875822 IP 84.246.161.114 > 88.146.12.185: IP6 2002:54f6:a172::1 > 2002:5892:xyz::1: ICMP6, echo request, seq 18, length 64
19

Z mojí veřejné adresy chodí na tvojí veřejnou adresu IPv4 paket se zapouzřeným IPv6 paketem s ICMPv6 hlavičkou. A žádné odpovědi se mi nedostane. Ale není důvod, aby to k tobě nedošlo.

Není tak, že blokuješ 6to4 pakety, které jdou z cizích IPv4 adres?

[hermelin]

Tak ted sem na firewalu povolil protokol 41 jak pro INPUT tak FORWARD

[pavlix]

Tak to je základ, to jsi měl mít od začátku :D, teda na INPUT, pokud vím, FORWARD by neměl být potřeba.

Zajímavý je, že k tobě posílám a zpátky dostávám pakety, co mají dohromady 1500B.

[hermelin]

Ja sem to zkousel i s vypnutym firewalem - ale nez si zkousel pingy tak jsem to vsechno dal zpatky do puvodniho stavu Takze ted je to zase otevreny pro 6to4

[pavlix]

A co ten nic.cz?

[hermelin]

nic.cz stale nefunguje

[pavlix]

Tak zkus 2002:54f6:a172::1, jak ping, tak curl -g -v.

[hermelin]

root@exchg:~# ping6 2002:54f6:a172::1
PING 2002:54f6:a172::1(2002:54f6:a172::1) 56 data bytes
64 bytes from 2002:54f6:a172::1: icmp_seq=1 ttl=63 time=27.3 ms
64 bytes from 2002:54f6:a172::1: icmp_seq=2 ttl=63 time=21.4 ms
64 bytes from 2002:54f6:a172::1: icmp_seq=3 ttl=63 time=23.6 ms
64 bytes from 2002:54f6:a172::1: icmp_seq=4 ttl=63 time=21.9 ms
^C
--- 2002:54f6:a172::1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 21.449/23.590/27.392/2.344 ms


root@exchg:~# curl -g -v 2002:54f6:a172::1
* getaddrinfo(3) failed for 2002:54f6:a172::1
* Couldn't resolve host '2002:54f6:a172:'
* Closing connection #0
curl: (6) Couldn't resolve host '2002:54f6:a172:'
root@exchg:~# curl -g -v http://[2002:54f6:a172::1]
* About to connect() to 2002:54f6:a172::1 port 80 (#0)
*   Trying 2002:54f6:a172::1... connected
* Connected to 2002:54f6:a172::1 (2002:54f6:a172::1) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.21.0 (x86_64-pc-linux-gnu) libcurl/7.21.0 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.15 libssh2/1.2.5
> Host: [2002:54f6:a172::1]
> Accept: */*
> 
< HTTP/1.1 200 OK
< Date: Sat, 29 Jan 2011 19:12:05 GMT
< Server: Apache/2.2.16 (Debian)
< Last-Modified: Sat, 29 Jan 2011 19:07:50 GMT
< ETag: "9c5-9b5-49b00e621c0af"
< Accept-Ranges: bytes
< Content-Length: 2485
< Vary: Accept-Encoding
< Content-Type: text/html
< X-Pad: avoid browser bug
< 
aaaaaa222222SSSSSS2222222SSSS2a22222SSSSSSSS22aaaaaaaa222222SS222aaaZaaZZZZ
2222aaaaS2222222222222222SS2SS22222SSXXXSSXSSXSSSXXXXXSSXSXXXXXX7XSSSSSSS22
2222222aaaZZa222222a222222SS22a22SSX77rrr777X77XXXSSSSSXSSXSSSXXXSXSS22S222
22a2222aaaaaaa22222aaaZZa2aa2aa2222SSSSXXXSSSSXXXXXXSXSXXSSSSXSSSXX7X22SSS2
22222a222222222222aaaZZZZZaaZaaZZZaaaa2a2SSSSSSSXSXXXXXXXXSX7;..,;20X77XXXS
2SSSSSXSSSSSSSSSSSSSS2222aa2222aaaaaa222222SSX7X777XXXX7r:   aMMMMBS7XX7XXX
SSSSSSXXSXXSSX7:,::i:.:rXSSSSSS22222a2SSXX7XXX77rr;i,    :WMMM@r.,;XSSSSS22
S22a222S2222XirWMMMMMM@a:;XSSXXXSSXXXX77;ii:,,,:...:rX0MMMMZ: ,;XSS2S222222
SSSS22aaa22X,2MMMWWW@@MMM2.:i:,,.    ..i7ZB@MMMMMMMMMMMM07 :7SaaaZZaaaaa222
XSXSXXS2S7: rMMZWWWWWWW@MMMB0MMMMMMMMMMMMMMM@WMW@@W@@@@WMMZaZ8888ZZaa2222S2
rrr;77rriXMMMMMWWWWWWWWWWWMMMM@W@M@@@@@@WWWWWBWW@WW@8ZW@MXS0B00088ZZZZaaaa2
;;iiiii:;ZX;,8MMWWW@@MMMMMMMM@W@WWWWB0@
08a222SS22aZZZZ2BMir7r   MMMMBBWWBBBBWWWWWWMMM0,:;rr7XXXXXX777rr77XX7X77X7X
0WWWBB088888ZZ8ZSZMMM8MMMMM@WWWWBBWW@WWWWWMM2,ir7r7r77XXX77rr;;;rr7XXSS2222
SSSaaaZZZaaa22222X;rWMMMMWWWWWWWWWWWWWWWWWMB;r77XXXXS2222SSX77rr;rr7XXX2aZa
SSSSSSXXXXX7XXXX777;. XWMMM@WW@@@@WWWWWWMMM22a22222222222SSXX7rrrrrr7XXSSSS
2222SXXXX7XXX7XXXXXX7ri  i0M@@MWMMMMM@MMMBZZ0B000000088ZZZZZZZZZaaa22SSSSXS
22aaZZ8Z888808888ZZZZaa2X:MZMMW ..78WMMZrXSSS2222aaaaaZZZZZZZZaZaaa222SS2SS
2SXXSS22aaZ880000BBBBB088S2BWMMXaX7 ;Mii7rr;;;i;;;;;;;rr777r7r7r7rrr7rr77XX
888ZZZZa2SSX77XXSSXSSSSS2SX7    8SrXMr;XX77r77rrrr;;;;;rrrr77r7r7rrrr;rr;i;
Z8088ZZZZZZ22SSSSSXX7777rrrXai 7270Mr72aZZZZ888888888ZZZaSSXSXSSSX7r;i::;rS
aaaSS2222aaaaaaZaZZZ888888Z88M; .MMrrSSXXXS2aaa2aaaa2S77rrrr777X77XXX2a888Z
XXX7X77rrr7XXS222222aZZZ8ZZa7@2: 7M,;;;;iiii::,::,,...,:,.,::i;r;rr7X2ZZa22
XXr;ii::iiii;r777rrr7ri::iir,M,S MMZXS2Zaaa22SXX77777XS222222aaa2SXX777r7XX
X77r;rr7XXXSSSSSXS22XrrXSa80Z080,  2Z8aaaZZ880BBWWWWWWWWWWWWWW@WWWWWB08ZZZZ
i,:iirrrrr7rrrrr7a:;MMM@WBB0000WMW  i8Z22aaa8Z888Z888000BBB88ZZZZ0BBW@MMMMB
822SXXaZa2XX77777Z    rMM@8Z880BMM: :XBZaaa22222ZZZZZaa222XXXXXXXXXXXS2aZZ2
8WaSSr77XX2Z0@@@WMMX     7MM@0ZZZ:M2 ;0Z8aSX7r;7XaZaS77r;rXX2aa2SSXXXSSX7r;
   ;;7X;:ii.:..7SZ8BWZ;     ;2S77  XB SiX;;rrr;ii;i::,::;r;7X;iii::,,.... ,
282X,  ..2a8W8Sr.,;a8WMMM@,    2BMW22@. 72a22S22a2aZZ8082;i;:,:iir7XSSXriii
,:SZ,7. i:i  .    ;.,.i7rSWMMMr  ,2B0iM  ,8SSSSXrr7777XXS22a2aZZ8880ZSXX280
  .  rZMZS8  r:.7  ri   ,     ;08Z  r8SBZ :;X7SaZ80Z227r:...     .,. ,ir7X2
BBZZX7;2;.a8XSSr8000Z@MMMMW0082i ;8WX:70SMSSaa:iii;;rXX7X0MM@BB0Za2S77rr7rX

* Connection #0 to host 2002:54f6:a172::1 left intact
* Closing connection #0
root@exchg:~# curl -g -v 2002:54f6:a172::1
* getaddrinfo(3) failed for 2002:54f6:a172::1
* Couldn't resolve host '2002:54f6:a172:'
* Closing connection #0
curl: (6) Couldn't resolve host '2002:54f6:a172:'

[pavlix]

No ten curl se samotnou adresou smysl nemá, ale ten s http očividně funguje a ten obrázek má přes 2000 bajtů.

[pavlix]

Nicmene nic.cz stale nefunguje. Je to fakt divny

Ale vrací minimálně potvrzovací paket :). Takže to zas nahrává tom MTU. Totální bordel, protichůdné příznaky. Něco jako zácpa s průjmem zároveň :D.

[pavlix]

Bezva, teď už na tebe pingám, měnil jsi něco?

[hermelin]

jj firewall je povolenej

[hermelin]

ale www.nic.cz porad nic (ja uz z toho versuju)

[hermelin]

A jeste pro upresneni jak je nastavene routovani

ip -6 route show
::/96 via :: dev sit0  metric 256  mtu 1480 advmss 1420 hoplimit 0
2002:xxxx:xxxx:1::/64 dev br0  metric 1024  mtu 1500 advmss 1440 hoplimit 0
2002::/16 dev sit0  proto kernel  metric 256  mtu 1480 advmss 1420 hoplimit 0
2000::/3 via ::192.88.99.1 dev sit0  metric 1024  mtu 1480 advmss 1420 hoplimit 0
fe80::/64 dev eth0  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 0
fe80::/64 dev br0  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 0
fe80::/64 dev eth1  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 0
fe80::/64 dev sit0  proto kernel  metric 256  mtu 1480 advmss 1420 hoplimit 0
default dev sit0  metric 1024  mtu 1480 advmss 1420 hoplimit 0

[pavlix]

2002:xxxx:xxxx:1::/64 dev br0 metric 1024 mtu 1500 advmss 1440 hoplimit 0 2002::/16 dev sit0 proto kernel metric 256 mtu 1480 advmss 1420 hoplimit 0

Tady s tím rozdílem v MTU a MSS si musí ty stroje v pohodě poradit, ale je zajímavé vědět, jestli za tím není nějaké ADSL... což v tvém případě (pardon za využití nechtěně zveřejněného údaje) zřejmě je.

Dost možná, že tvůj poskytovatel nereaguje správně na příliš velké pakety a zatímco režie 20B na IPv4 hlavičku tunelovaných paketů je OK (širší trasa je u tebe, tvůj router jistě chyby vrací), u té 8B režie bych se ani nedivil, kdyby to neprošlo.

Zkusil bych testovat s natvrdo nastaveným MTU 1492 místo 1500 proti ADSL modemu. MTU sit0 by mělo automaticky vyjít o 20 bajtů nižší. Můžeš postnout default route pro IPv4?

Vnitřní síť by teoreticky měla zůstat jaká je. Kdyby to nešlo, tak bych zkusil vnitřní síti nastavit MTU stejné jako má tunel, ale je potřeba vždy nastavovat na všech zařízeních stejného linku, jinak bude síť blbnout.

Je to docela velká alchymie a bez vyzkoušení (nemám ADSL, nemám stejného poskytovatele, nemám tedy kde) se můžu lehce splést. Navíc osobně jsem tenhle problém řešil na IPv4-only síti a vyřešil zadáním TCPMSS pravidla do mangle tabulky.

2000::/3 via ::192.88.99.1 dev sit0  metric 1024  mtu 1480 advmss 1420 hoplimit 0

Tohle je celkem ok, až na to, že 1480+20 přes ADSL (1492) neprojde a bohužel ne všude si to poradí samo.

Ale podle aktuálního standardu se má dávat default route pro ::/0, stejně jako se to dělalo na IPv4. Do budoucna se počítá s možným vyhrazením dalšího rozsahu.

default dev sit0  metric 1024  mtu 1480 advmss 1420 hoplimit 0

A... tady ta default (::/0) je, takže dohromady to dělá bordel.

Myslím, že místo těchto dvou pravidel by mělo být pouze to, které doporučuje i CZ.NIC v návodu:

default via ::192.88.99.1 dev sit0

Je to taková změť spousty drobných pro danou situaci neškodných konfiguračních nedostatků, plus ta chyba při vybírání správné adresy z DNS, plus tradiční problémy s poskytovateli ADSL připojení, že se nakonec můžou nějaké chyby zkombinovat a projevit se i jednoduchém příkladě s www.nic.cz, kde by to správně mělo fungovat už jen tím, že funguje 6to4, radvd a forwarding. A lehčeji se to přehlédne.

[hermelin]

Ano je to skrz ADSL - to neni nic tajneho Nastavil jsem tedy na rozhrani k ADSL 1480 Zkusil jsem pro sit nastavit mtu 1280.

Problem stale stejny

default route:

default via 192.168.254.1 dev eth1
eth1: <\BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1480 qdisc htb state UNKNOWN qlen 16
    link/ether 00:00:1c:dc:45:7f brd ff:ff:ff:ff:ff:ff

[pavlix]

Mohl by to být problém s MTU z druhé strany tak jak jsem ho párkrát řešil, ale nikdy jsem neměl možnost si to prohlédnout přímo u zdroje potíží u providera.

Když už je tvá adresa IPv6 bráný známá, zkouším na ni IPv4 i IPv6 ping. IPv4 ping projde, IPv6 ne. Buď pečlivě filtruješ jen IPv6 pingy, nebo je něco špatně.

Takže si to shrnmě, říkal jsi něco o dvojitém NATu, což mi s 6to4 dohromady nejde. Je třeba to prozkoumat.

Jde ti ping (či HTTP HEAD) na www.nix.cz, obě adresy, i z klientů, ale nejdou ti dotazy na celé stránky (ukazuje na problémy s MTU na zpětné cestě).

Mně jde cokoliv na www.nix.cz, ale jsem na MTU 1500 u Wifi poskytovatele, který nemá problémy se ******** typu ADSL.

Ale nejde mi na tebe obyčejný ping6 na 6to4 adresu tvého routeru, přesněji řečeno, nedostávám žádnou odpověď. Requesty odcházejí po 6to4, což zase s MTU nemá společného vůbec nic. Když je posílám z nativní IPv6, dopadne to stejně.

Takže... buď máš něco bloklého u sebe (IPv4 firewall, IPv6 firewall), nebo něco blokuje volný. Ale každopádně na tebe jde udělat IPv4 ping a nejde úspěšně udělat IPv6 ping uvnitř IPv4 paketu.

Pokud se někde po cestě účastní NAT, může být stejně tak příčinou všech potíží. Přecijenom je to ošklivý hack a ne routing, bez ohledu na četnost jeho užití.

[hermelin]

Ok - vyzkousim jeste nejake experimenty na zaklade tveho konecneho vysledku a uvidim. Urcite pokud neco objevim dam vedet. Opravdu diky moc za tvuj cas a ochotu.

[pavlix]

Popravdě, jsem nemocný a necítím se ještě úplně na seriózní práci, proto mám tolik času prudit po diskuzích a pomáhat v poradně :).

[hermelin]

To je od tebe hezky

Taky by si mohl klidne koukat na Novu a na pomoc ostatnim se vy...

Jeste jednou diky moc.

[pavlix]

Viděl jsem pár posledních dílu, hysterek (alias Ulice), létajících aut (alias Kobra 11), něco ze zpravodajství... to už budu radši vrtat do těch diskuzí :D.

[xHire]

Dalsi zajimavosti je: ping6 www.nic.cz funguje jak na routeru tak na stanicich ale IP6 adresa je na kazdem jina (pritom oba pouzivaji stejny DNS server).

router:

64 bytes from 2002:d91f:cd32::1: icmp_seq=1 ttl=64 time=15.1 ms

stanice:

64 bytes from 2001:1488:0:3::2: icmp_seq=1 ttl=63 time=16.4 ms

xhire@fusinka ~ $ host www.nic.cz
www.nic.cz has address 217.31.205.50
www.nic.cz has IPv6 address 2001:1488:0:3::2
www.nic.cz has IPv6 address 2002:d91f:cd32::1

[pavlix]

I tak je to zajímavé, vzhledem k RFC 3484.

[Milan Beneš]

Ahoj, obávám se, že 6to4 relay bude problematický vždycky. Odchozí data půjdou nejspíš přes relay na CZ.NIC, ovšem příchozí se můžou vracet přes jinou mašinu. Víc je třeba na http://www.root.cz/clanky/6to4-nejjednodussi-cesta-k-ipv6/nazory/. Sám za sebe bych raději doporučil tunel, mě se osvědčil SixXS.

[Ondrej 'SanTiago' Zajicek]

Rozumny ISP provozujici nativni IPv6 by mel mit vlastni odchozi 6to4 branu (coz je v podstate jeden radek do routovaci tabulky). Pak jdou od nej prichozi data (z hlediska uzivatele 6to4) optimalni cestou.

Oproti tomu u beznych tunnel brokeru jdou data vzdy nejakou naprostou oklikou. Napr. zminovany SixXS (AFAIK) nema PoP v CR, takze pro ceske uzivatele pristup k ceskym serverum pak beha prez zahranici, coz muze dost navysovat latenci. S 6to4 mam pres IPv6 na Lupu nebo web NIXu RTT ~ 6 ms. To by slo se SixXS jen tezko.

[Milan Beneš]

Rozumím, nicméně u mě byla volba polofunkční 6to4 s nízkou latencí, nebo tunel do Holandska...

[hermelin]

No me jde spis o to ze se chci s IPv6 seznamit a vyuzivam hlavne CZ internet. A tak jsem vyzkousel doporuceny navod a zarazilo me ze prestali fungovat stranky nic.cz. Tak me zajima v cem je problem.

[pavlix]

V tvé konfiguraci sítě v kombinaci s tvým poskytovatelem.

[pavlix]

Teda, pravděpodobně... ještě pár testů u sebe udělám.

[rastos]

Túto diskusiu sledujem po očku odkedy vznikla a keďže som si dnes našiel chvíľu na experimentovanie tak chcem niečo pridať.

Ja som si IPv6 skúšal rozbehnúť pár týždňov dozadu podľa http://6to4.version6.net/?show_ip=&lang=en_GB a teraz zisťujem, že je to vlastne to isté ako radí NIC.CZ až na to, že 6to4.version6.net radí na konci vyskúšať ping6 2001:ad0::1. A ten mi nikdy nešiel (hoci ping na ipv6.google.com prejde). Dnes som pátral po príčine a zistil som, že ICMP echo-request pakety odchádzajú, ale ako odpoveď na ne prichádzajú pakety z 192.88.99.1 a s protokolom 47. Čo je 47? GRE - Generic Routing Encapsulation. Nikdy predtým som na takú potvoru nenarazil. Tie pakety blokoval môj firewall a keď som ich povolil, tak ne môj systém odpovie ICMP paketom "destination port unreachable". Možno to bude súvisieť s tým, že moje jadro hovorí "# CONFIG_NET_IPGRE is not set". Zatiaľ som neskúšal tú voľbu povoliť.

Takže riešenie nemám, len tip pozrieť sa, či niečo podobné nenastáva aj u vás.

Mimochodom to čo tu zaznelo, že

Odchozí data půjdou nejspíš přes relay na CZ.NIC, ovšem příchozí se můžou vracet přes jinou mašinu.

je pravda, ale myslím, že tomu pomohlo iptables pravidlo s -m state --state ESTABLISHED,RELATED

[hermelin]

Ping na ping6 2001:ad0::1 mi neprojde - ani pri uplne vypnutem firewallu. A logovani firewallu mi pise

IN=eth1 OUT= MAC=00:00:1c:dc:45:7f:00:1b:fc:03:f1:a0:08:00 SRC=192.88.99.1 DST=192.168.254.254 LEN=124 TOS=0x00 PREC=0x00 TTL=242 ID=12990 DF PROTO=47 

a dalsi zajimava vec kdyz je nastaveny firewall

iptables -A INPUT -i eth1 -p 41 -m state --state RELATED,ESTABLISHED -j ACCEPT

tak na stanice za routerem neprojde ping6 www.nic.cz ale projde ping6 ipv6.google.com

logovani firewalu pise

IN=eth1 OUT= MAC=00:00:1c:dc:45:7f:00:1b:fc:03:f1:a0:08:00 SRC=217.31.205.50 DST=192.168.254.254 LEN=124 TOS=0x00 PREC=0x00 TTL=57 ID=0 DF PROTO=41 

pokud nastavim

$IPTABLES -A INPUT -i eth1 -p 41 -j ACCEPT 

tak projde ping6 jak na www.nic.cz tak na ipv6.google.com

Ale jak rikam - jiz jsem testoval s uplne vypnutym firewallem resp. vsechno povoleno a stejne bez uspechu

[pavlix]

iptables -A INPUT -i eth1 -p 41 -m state --state RELATED,ESTABLISHED -j ACCEPT

tak na stanice za routerem neprojde ping6 www.nic.cz ale projde ping6 ipv6.google.com

Rozdíly hledej tcpdumpem na vnějším rozhraní :).

tak projde ping6 jak na www.nic.cz tak na ipv6.google.com

Ale jak rikam - jiz jsem testoval s uplne vypnutym firewallem resp. vsechno povoleno a stejne bez uspechu

To mě právě fascinuje. Že ti v určitou chvíli jde ping na všecho, dokonce tobě posílám i přes tvé ADSL pakety velikosti 1500 (jestli správně počítám), a dostávám takové zpátky, což by mělo vyloučit problémy s MTU.

Na tvym místě bych už kotaktoval CZ.NIC, protože mají více zkušeností... ale problém podle mě nebude ani přímo u nich, ale někde mezi váma.

[hermelin]

Tak uspěšně vyřešeno díky velké pomoci Jaromíra Talíře z NICu.

Nastaveni na routeru:

ip tunnel add sit0 mode sit remote any                                
ip link set dev sit0 mtu 1472 up                                      
ip -6 address add 2002:xxxx:xxxx::1/16 dev sit0                        
ip -6 route add default via ::192.88.99.1 dev sit0                    
ip -6 address add 2002:xxxx:xxxx:1::1/64 dev br0        

Nastaveni radvd.conf:

interface br0 {                                                                 
        AdvSendAdvert on;                                                       
        MinRtrAdvInterval 3;                                                    
        MaxRtrAdvInterval 10;                                                   
        AdvLinkMTU      1472;                                                   
        prefix 2002:xxxx:xxxx:1::/64 {                                           
                AdvOnLink on;                                                   
                AdvAutonomous on;                                               
                AdvRouterAddr on;                                               
        };                                                                      
                                                                                
};     

Jeste jednou diky vsem za pomoc.

[pavlix]

Popravdě zkusit snížení MTU už jsem ti párkrát poradil :), ale ta diagnostika mi úplně nešla.

Můžeš ho ještě poprosit, ať pošle vysvětlení, proč přesně to nefungovalo, pokud nějaké má?

[hermelin]

Mas pravdu - nekolikrat si me na nej upozornoval. Dokonce prvni odpoved tady k tomu dotazu me smerovala uplne presne nicmene mi to nefunguje s jinym mtu nez 1472, coz jsem nasel az na odkazovanych strankach (mozna diky memu ADSL modemu).

Odpovedi z NICu me smerovaly http://www.wlug.org.nz/6to4 a http://backreference.org/2010/06/27/quick-and-dirty-ipv6-with-6to4/

A udajne uz samo o sobe je zajimave ze mi 6to4 funguje kdyz jsem za natem

[pavlix]

Tak, tys mě celou dobu ubezpečoval, že první NAT je 1:1, což by čistě teoreticky fungovat mělo. Ale pravda je, že NAT dělá na síti bordel a vznikají takový situace jako to, co jsme testovali my.

[hermelin]

Ano NAT 1:1 byl mezi ADSL modemem a routerem - a za routerem pak byl klasicky NAT 1:N. Ale jak rikam ani sem necekal ze na tom hybridu to pojede ale kdyz uz to slapalo jak ma tak mi nejel www.nic.cz a zajimalo me v cem je problem. A ejhle jsou na internetu skvely odbornici kteri poradi

Jeste jednou vsem moc diky