W przypadku IPv4 „zaciskanie” protokołu TCP MSS (urządzenie sieciowe edytujące wartość MSS w nagłówku TCP) może pomóc, gdy nie działa wykrywanie maksymalnej jednostki transmisji na ścieżce. (np. gdy ICMP jest blokowany gdzieś na ścieżce). Ponieważ w IPv6 nie występuje fragmentacja, nadal mamy „pakiet zbyt duży” ICMPv6, aby zasygnalizować początkowy punkt końcowy.
Czy istnieją jakieś wskazówki dotyczące blokowania protokołu TCP MSS przez IPv6?
Cóż, technicznie fragmentacja może się zdarzyć w IPv6; To jest artykuł w Wikipedii na ten temat.
Ta strona Juniper jest nieco stary, ale to pokazuje, że można zacisnąć się MSS dla TCP przez IPv6 na Junos samo jak byś w IPv4 przy użyciu tego samego polecenia tcp mss. To samo pokazano w tym artykule dla Cisco IOS 15, używając tradycyjnego adjust-msspolecenia ip tcp .
Możesz więc skonfigurować blokowanie MSS, jeśli PMTUD nie działa tak, jak powinno być w części twojej sieci, w przeciwnym razie powinieneś upewnić się, że pomagasz w wygładzaniu działania PTMUD w sieci, aby blokowanie MSS nie było wymagane ( Rozumiem, że nie zawsze jest to twoja kontrola).
Aktualizacja
Oto link do nowszego artykułu Junos dla Junos 10x zamiast 9, nie mogę znaleźć jednego dla 11 i nie jestem teraz przed 11, ale spodziewam się, że będzie tak samo.
Zdecydowanie istnieją przypadki - zwykle obejmujące tunele IPv6-w-IPv4 w pewnym momencie na ścieżce - gdzie nawet jeśli PMTUD działa poprawnie, negocjacja MSS kończy się niepowodzeniem. W takim przypadku sesja TCP może rozpocząć się poprawnie (ponieważ pakiety SYN / ACK są małe), ale nie docierają żadne pakiety danych (ponieważ te pakiety są zbyt duże dla tunelu). W tym przypadku MSS zaciskanie na drugim końcu pomogłoby, ale nie jest pod kontrolą „ofiary” czekającej na pakiety. Rozwiązaniem awaryjnym jest ustawienie dla obu stron MTU IPv6 na 1280, który powinien przejść przez dowolny tunel.
źródło