Я %username% из России с IPv6

Купи VPS за пять баксов, поиграйся с нативным ipv6 и успокойся.

ipv6 сейчас не нужен

ЭР-Телеком (бренд: ДОМ.РУ)

выдаёт каждому клиенту подсеть /64 — через протокол DHCPv6-PD-over-PPPoE

Есть ли прирост скорости скачивания в торрент сетях, например

в торрентах — только одинажды (за много месяцев) встретил пира тоже с NativeIPv6 как и я (остальные это — либо Teredo , либо 6to4).

а в web — скорость ровно одинаковая как на IPv4. судя по всяким Вконтактам и Википедиям.

а ещё есть интересный баг в маршрутизаторах (маршрутизаторах, которые якобы поддерживают IPv6) — баг под названеим «чёрная дыра»..

то есть если хотите IPv6 то придётся делать маршрутизатор своими руками :-)

(ping чуть-чуть быстрее на пару милисекунд — думаю это связано с отсутствие PDI на стороне провайдера. в случае IPv6)

а то в Яндексе находятся разная инфа для прессы

[sarcasm]в Bing же надо искать :-D[/sarmasm]

а ещё есть интересный баг в маршрутизаторах (маршрутизаторах, которые якобы поддерживают IPv6) — баг под названеим «чёрная дыра»..

то есть если хотите IPv6 то придётся делать маршрутизатор своими руками

можно по подробнее? найти не получается

а ещё есть интересный баг в маршрутизаторах (маршрутизаторах, которые якобы поддерживают IPv6) — баг под названеим «чёрная дыра»..

поподробнее напишу про этот баг. проявляется так:

протокол TCP не может корректно определить максимальный размер IP-пакета (pmtu).

и как следствие любая TCP-сессия в случайный момент — может зависнуть [случайный пакет слишком большого размера пропадает, а его пересылка занова снова-и-снова не увенчивается успехом.. TCP-сессия на этом и зависает].

в случае HTTP — для пользователя это будет выглядеть как будто определённая часть HTTP-запросов работают, а определённая часть HTTP-запросов записают (ну это логично так как HTTP работает поверх TCP :)).

при этом характерная черта — это ситуация когда встречаются некоторые сервера HTTP-запросы к которым всегда НЕ будут зависать :) .. для тех кто не был знаком ранее с «чёрной дырой» — такие сервера могут слегка ввести в замешательство ("почему связь именно с ними ни когда не зависает в отличии от других серверов?" — может подумать человек не знакомый с этим феноменом :)).

вот как раз [написал] :-)

на GNU/Linux чтобы не создавалось «чёрных дыр» — нужно:

ip6tables -w -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

(это нужно только в ситуации когда маршрутизатор соединяет две сети с разным размером пакетов)

А вообще, твоей конечной железке какая разница нативный ли у нее ipv6 или туннелируется? У меня был 6in4 туннель, в плане работы ни плюсов, ни минусов не заметил (если не считать «особенностей» работы оффтопика в дуалстеке). В ipv6-инете сейчас людей столько же, сколько и в i2p, так что пока ждемс, когда он придет в массы.

ну если ты в Этой Стране, а тунель в Америки, то лэтенси соединения будет плохой

Я все таки подразумевал туннель до твоего инет-провайдера; а с чем-нибудь вроде http://he.net/ задержки действительно будут.

Поэтому надо 6to4 использовать нормальный, а это возможно только с белым IP :)

Есть ли прирост скорости скачивания в торрент сетях

С каких рыжиков он должен появиться?

Заметил что вначале обращение идет по ipv6 адресу, а уже потом по ipv4, скажем если обратиться к какому-либу sitename напрямую. Так что создается обманчивое впечатление что ipv6 уже поддерживается везде.

Есть, мой домашний дает. Не пользуюсь.

а в web — скорость ровно одинаковая как на IPv4

А с чего ей быть другой ? Это ровно те же самые каналы.

ping чуть-чуть быстрее на пару милисекунд — думаю это связано с отсутствие PDI

Скорее с мощностью (и архитектурой) маршрутизаторов и размером BGP таблицы. А сейчас это 500151 в IPv4 и 18125 в IPv6. У правильных алгоритмов обработки это проблемы вызывать не должно бы, а вот у не очень правильных - не знаю. Но 18125 - это временно. 15 лет назад и в v4 было не больше.

А с чего ей быть другой ? Это ровно те же самые каналы.

ну и откуда я знаю почему на практике скорость могла БЫ быть другой? :-)

теория конечно как обычно всё упрощает и не учитывает нюансы.

а нюансы могли быть.. например:

1. вдруг(!) для IPv6 и для IPv4 — web-сайты используют разные физические frontend-сервера. (это не так. но могло бы быть так, для «странных» web-сайтов). :-)

2. для IPv6 не используется DPI (Deep Packet Inspection), а для IPv4 используется DPI. если это так [а в ДОМ.РУ это именно так — это я уже выяснил], то ни что не мешает провайдеру в будущем устранить этот «недочёт» :-)

3. ещё что-то, что могло бы вдруг выясниться на практике.. :-)

у меня ipv6, как уже писали эр-телеком, плюсы увидел, скорсоть перестала падать вечером

то ни что не мешает провайдеру в будущем устранить этот «недочёт»

Больше скажу: закон мешает НЕ устранить. :-)

скорсоть перестала падать вечером

Не представляю, как это возможно, кроме как за счёт тормозов на упомянутом DPI. Это надо смотреть, как оно там сделано у них... Но это не плюс IPv6, а чья-то недоработка. :-)

Скорее с мощностью (и архитектурой) маршрутизаторов и размером BGP таблицы. А сейчас это 500151 в IPv4 и 18125 в IPv6.

это довольно примечательные данные.. да.

а может быть такое (спрашиваю, просто. не утверждаю) — что всё дело в FlowLabel ?

в IPv4 ведь нет FlowLabel ?

просто подключение ipv6 далеко спрятано в кабинете, и у большинства он не подключён ещё.

и зачем это сейчас нужно?

и у большинства он не подключён ещё.

Не имеет значения, если оборудование используется одно и то же и каналы одни и те же. А это на 99.9% именно так.

я просто заметил, раньше в выходные и вечером с 19-23 часов падала скорость со 80 до 40-45 мбит/c, после подключения ipv6 скорость остаётся на 80 и выше. возможно что всё же каналы разные.

например чтобы иметь бесплатно внешний ip а не за 300 рублей в месяц.

Я тоже про это думал, и мне кажется провайдеры бесплатным это не сделают. Хотя матчасть я невкурил

Еще как нужен. Можно раздать всем устройствам по белому адресу. Использую IPv6 уже третий год, наверное, правда, не нативный. http://prostovpn.org/

Действительно, у dom.ru нет DPI на IPv6. Да и вообще, некоторые сайты уже давно используют IPv6 именно для обхода блокировки.

С MTU все должно быть нормально, если ваш провайдер не блокирует ICMPv6. Clamp-mss-to-pmtu совершенно не обязателен, хоть и экономит иногда один пакет.

Я тоже про это думал, и мне кажется провайдеры бесплатным это не сделают.

На этапе тестирования, для подопытных кроликов - не сложно. Но нужно. Потом, конечно, это кончится. Но небольшое количество первых может остаться в шоколаде.

Можно раздать всем устройствам

И каждому таракану на каждую лапку тоже. Беда в том, что NAT ещё и защита, а с IPv6 и раздачей реальных IP твоим утюгом будет управлять ХЗ кто. Так что не спиши использовать /64. Сделай NAT всё равно.

Все ясно с вами.

Почитайте, пожалуйста, для чего нужен NAT, и почему он не является средством защиты.

Все ясно с вами.

Почитайте, пожалуйста, для чего нужен NAT, и почему он не является средством защиты.

С MTU все должно быть нормально, если ваш провайдер не блокирует ICMPv6. Clamp-mss-to-pmtu совершенно не обязателен, хоть и экономит иногда один пакет.

я сам точно не знаю почему, но однако у меня по началу тоже было мнение что вероятнее всего нет обязательной необходимости в ... TCPMSS --clamp-mss-to-pmtu

однако время от времени Facebook и Wikipedia — web-страницы зависали. именно время от времени (а не каждый раз). например это могло произойти при первой попытке зайти на них, но зависание пропадало после закрытия вкладки web-браузера и открытия вкладки поновой.

и даже когда это случалось — всё равно я не хотел верить в то что мне требуется ... TCPMSS --clamp-mss-to-pmtu.

почему так было?

просто мне казалось (точнее — хотелось надеяться) что протокол TCP достаточно умный чтобы догадаться до того чтобы он сам понял бы что нужно уменьшить размер своих пакетов :-) ..

однако зависания есть зависания (говоря про зависания Facebook и Wikipedia )..

и эти факты зависания — оказались слишком объективными для моего субъективного сознания.

например я мог проснуться утром, открыть браузер и точно заранее знать что «сейчас я первый раз за сёдняшний день открою Wikipedia и этот сайт у меня точно зависнит (не загрузится доконца)».

ну и в итоге я всё-таки попробовал ... TCPMSS --clamp-mss-to-pmtu .. и О ЧУДО! ну вы поняли... :-)

вообщем, примерно чуть больше двух недель, я был без clamp-mss-to-pmtu .. и да — это был ад :-D

Так вы посмотрите в wireshark, быть может, ваш провайдер или роутер режет ICMPv6.

знать бы ещё как этим wireshark пользоваться , и что именно там искать :-)

Должны быть ICMPv6 пакеты Fragmentation needed. Именно это и подстраивает MTU. Если их нет, а загрузка страницы зависла, и идет ретрансляция пакетов, то точно, кто-то по пути режет ICMPv6.

ммм... интересно..

а кто эти «Fragmentation needed» отсылать должен? маршрутизатор, который связывает две сети (Ethernet:1500 => PPPoE:1492) ?

если да — то значит не важно режет ли провайдер что-то или не режет (маршрузитатор «Ethernet:1500 => PPPoE:1492» находится не на стороне провайдера).. правильно понимаю?

то есть — провайдера мы винить не можем точно.. (виноваты либо маршрутизатор который в квартире, либо компьютеры в локальной сети?)

а может ли быть такое что IPv6-протокол вообще не поддерживает фрагментацию как таковую (то есть такого IPv6-пакета как «Fragmentation needed» — например существуеть не может?) ?

даже не знаю что и думать теперь:

вот сейчас убрал (временно) из ip6tables маршрутизатора правило tcp flags:0x06/0x02 TCPMSS clamp to PMTU

и затем позапускал на клиентском-компьютере — несколько раз wget -6 -O- 'https://vk.com' — и из них — ни разу не было ни одного зависания.

(хотя этой зимой помню примерно 10% зависало...)

интересно всё это.

неужели зимой я попал на какой-то баг ядра. :-)

придётся теперь пару недель посидеть так и поисследовать...

Прошу прощения, это в ICMP он называется «Fragmentation needed» (т.к. в IPv4 есть фрагментация), а в ICMPv6 он называется «Packet too big».

Может резать и провайдер. Ведь обычно получается, что пакет запроса достаточно маленький (меньше 1460 байт: 1500 MTU - 40 IPv6 HEADER), чтобы уйти одним пакетом, и уходит, а когда вам сервер начинает отвечать, то он отвечает максимально возможным пакетом, скажем, 1460 байт, и если ICMPv6 зарезан, то ваш роутер просто не сможет ответить серверу, что пакет слишком большой, и сервер будет старатся переслать пакет так, как будто он был потерян, снова и снова.

Но если клиент попытается отправить слишком большой пакет, а у вас на роутере PPPoE, то отвечать клиенту должен роутер, да.

всем устройствам по белому адресу

не нужно.

TCP-рукопожатие *всегда* начинается с самого большого пакета?

если ответ «да» — то значит в таком случае не может TCP-сессия зависнуть посередине своей работы..? да?

TCP-сессия она должна либо не начаться вообще, либо если началась то уже значит работать как следует...

...верно?

если это всё так — то значит похоже мои зимние зависания соединений на IPv6 — были не из-за pmtu , похоже ... :-)

TCP-рукопожатие *всегда* начинается с самого большого пакета?

Размер MSS устанавливается максимальный, а данные внутри пакета не обязательно должны быть равны MSS.

получается что рукопожатие всё-таки может пройти нормально. из-за того что размер пакетов рукопожатия меньше чем максимальный..

а потом в середине TCP-сессии вдруг появится большой пакет (и в этом случае <что-то> должно произойти — либо по <хорошему-сценарию>, либо по <плохому-сценарию>)

правильно?

если так — то я слегка обеспокоен на тему того — что станет с порядковыми номерами пакетов? как они будут перестроены занова? как это изменение порядковых номеров пакетов — станет возможным в случае <хорошего-сценария>?

а потом в середине TCP-сессии вдруг появится большой пакет (и в этом случае <что-то> должно произойти — либо по <хорошему-сценарию>, либо по <плохому-сценарию>)

Он ближе к началу сессии, все-таки, но, в целом, верно.

если так — то я слегка обеспокоен на тему того — что станет с порядковыми номерами пакетов? как они будут перестроены занова? как это изменение порядковых номеров пакетов — станет возможным в случае <хорошего-сценария>?

Да такие же будут, не перестроятся. Сообщение о большом пакете же не в TCP-сессии шлется, а через ICMPv6 (или просто ICMP для IPv4).

если так — то я слегка обеспокоен на тему того — что станет с порядковыми номерами пакетов? как они будут перестроены занова? как это изменение порядковых номеров пакетов — станет возможным в случае <хорошего-сценария>?

Да такие же будут, не перестроятся. Сообщение о большом пакете же не в TCP-сессии шлется, а через ICMPv6 (или просто ICMP для IPv4).

вот — пресдтавим — установилась TCP-сессия, пошли некоторые пакеты..

..может быть даже перый пакет прошёл успешно (HTTP-заголовок уместился в размер менее 1400)..

и вдруг роутер «роняет» слишком большой пакет и отсылает клиентскому компу ICMPv6-пакет о том что был "слишком большой размер пакета. следующий раз шли не более чем 1490"

что происходит дальше?

клиенту значит теперь нужно посылать пакеты — более маленького размера, но часть пакетов уже отослана (часть из них «уранилась», а часть прошла успешно).

конечно клиент знает какие именно пакеты дошли а какие не дошли. загадка не в этом :) ..

но у каждого из дошедщих пакетов были свои номера.

и у каждого НЕ дошедшего пакета — *тоже* были тоже свои номера.

послать новые пакеты с такими же номерами как и у недошедших пакетов — нельзя — так как теперь нужен более маленький размер пакетов, а следовательно их количество должно быть больше чем количество пакетов которые не смогли дойти.

например если были отосланы пакеты:

... ... ...
000111 [успешно, так как пакет маленький]
000112 [не успешно, так как пакет слишком большой]
000113 [не успешно, так как пакет слишком большой]
000114 [не успешно, так как пакет слишком большой]
000115 [успешно, так как пакет маленький]
... ... ...

то мы не можем просто уменьшить пакеты 112,113,114 так как теперь нужно не 3 пакета а уже 4 пакета.

как TCP способен справится с этой задачей?

может быть какая-то внеочередная синхронизация TCP-сессии должна произойти для того чтобы занова перестроить номера отсылаемых пакетов?

Честно говоря, я не готов ответить на этот вопрос. Надо бы провести эксперимент, что ли. Вопрос интересный.

Вот эта программа «wireshark».. Я должен в ней разобраться и сам поставить нужные эксперименты :-)