IPv4 фрагментира у транзиту; IPv6 уместо тога шаље поруку о превеликом пакету

Неуспеси IPv6 много чешће се приписују протоколу него величини пакета која их је изазвала. Две фамилије заиста различито поступају са превеликим пакетом, а тунел је оно што ту разлику чини важном. IPv4 рутери смеју да фрагментирају пакет када правила то дозвољавају, док IPv6 рутери не смеју да фрагментирају у транзиту уопште. IPv6 то уместо тога каже пошиљаоцу, и од пошиљаоца се очекује реакција. Све што после пође наопако произлази из тога да ли та порука стиже.

Шта ради свака фамилија

Табела је механизам у четири реда, и један ред објашњава већину забуне.

IPv6 нема фрагментацију у транзиту ни DF заставицу коју треба очистити, зато нема на шта да се ослони када је пакет превелик. Пошиљаоцу мора да се каже, и пошиљалац мора у то да верује.

Тунел тихо сужава пут

VPN додаје спољна заглавља, а у шифрованом случају и податке о интегритету, пре него што пакет напусти домаћина. Унутрашњи пакет може да стане у MTU интерфејса који види, док спољни пакет прелази границу следеће везе, и зато се то прво појављује у тунелу. Намерно снизите MTU тунелског интерфејса или стисните TCP MSS на путу, и запишите који број сте изабрали и зашто.

Трошак ESP зависи од режима и алгоритама, зато је исправан MTU тунела прорачун, а не конвенција. Шта год да изаберете, мора да остави места за пун унутрашњи IPv6 пакет од 1280 бајтова, јер свака IPv6 веза мора толико да носи. Тунел који не може да носи 1280 бајтова IPv6 није проблем подешавања; то је покварен пут за ту фамилију. Управо то ограничење нестаје када се вредност MTU копира из поставке само са IPv4.

Зашто се симптом показује као застој

Неуспех није чиста грешка, и зато се погрешно дијагностикује. TCP руковање се заврши, мали одговори стигну, и веза се заглави чим почне велики одговор или велико отпремање, јер су то први пакети довољно велики да буду одбачени. SSH се повеже и затим се заглави на првом великом излазу, а заглавље странице се учитава док тело никада не заврши.

Ако се ICMPv6 поруке о превеликом пакету филтрирају, пошиљалац то никада не сазна и стално понавља исту величину. То је црна рупа, а не спор пут, и њен потпис је поновљива граница величине, а не случајан губитак. Дозволити одговарајући контролни саобраћај део је исправне IPv6 поставке, а не услуга.

Не искључујте поруке од којих зависи ваш сопствени пут и затим резултат не описујте као квар IPv6. Исти аргумент важи за IPv4 поруке Fragmentation Needed, које су једнако непопуларне код аутора заштитних зидова и једнако неопходне.

Измерите границу, затим поправите слој

Проверавајте уместо да нагађате: користите заставицу don't-fragment на IPv4 и фиксне величине терета на IPv6, и забележите где се одговори заустављају. ping -M do -s 1472 и ping -6 -s 1400 су довољни да утврде облик проблема, а tracepath пријављује откривени MTU пута дуж трасе.

Затим поправите слој који поседује број: MTU тунелског интерфејса, стискање MSS за TCP, или сам пут. RFC 8200 је референца за IPv6 правило, и чита се краће од инцидента који спречава.

Тестирајте фамилију коју апликација стварно користи, јер име са двоструким стеком може да одговори на једној фамилији, а не на другој, а апликација може да пређе после промене мреже. Запишите адресу коју сте тестирали, јер резултат према A запису не говори ништа о AAAA запису.

Третирајте границу величине као доказ

Поновљива граница величине је један од ретких мрежних кварова који се тачно репродукује, при истом броју бајтова, са истог извора, сваки пут. То је чини даром, а не загонетком, и такође значи да поправка може да се провери уместо да се у њу нада.

Упишите у тикет откривени MTU, MTU тунела који сте конфигурисали и тест који је доказао разлику. Следећа особа ће срести исту аритметику на другој вези.