Нашёл более свежие RFC на данную тему, и… в общем, ваша правда, ValdikSS описал единственный работающий способ, который как в IPv4.
Пункт в RFC 3484 bis про выбор адреса на основании некст-хопа так никуда и не ушёл.
Судя по RFC 7157, время прошло, а проблема так и не решена. Один из подходов — ввести таблицы маршрутизации с source-destination. Т.е. то, что сейчас делает PBR. Но опять, статус сугубо экспериментальный, и даже если это будет, то не скоро.
Есть другие подходы — LISP, например, но идеальных нет. У некоторых есть большое желание сделать NPT (NAT66), но это всё обычно отметается по религиозным соображениям.
В общем, прошу прощения за дезинформацию, обещанный простой multihoming так и не запилили. Жаль.
Не совсем так. В теории было обновление RFC 3484, в котором, среди прочего, добавляется правило «Ходи через того, кто тебе дал этот префикс». Однако судя по дате (2011), ждать, что это работает здесь и сейчас, не приходится. Поэтому используем запасной вариант — PBR по адресу источника.
Есть ещё одна тонкость, что выдаваемый провайдером префикс в случае сбоя нужно старить (рекламировать с нулевым lifetime), и с этим тоже могут быть проблемы.
Эффект примерно такой же, как и в случае двух провайдеров и сервера, который спрятан за NAT. Со стороны провайдера А он виден со своим префиксом, а со стороны провайдера Б — со своим. В зависимости от того, какой адрес выдаёт DNS — через такой линк клиент к вам и будет отправлять запрос.
Маршрутизация обратного трафика настраивается чуть проще, потому что в IPv6 для ответного трафика уже по адресу источника понятно, через какого из провайдеров отправлять. В случае с NAT тоже обходится: транслируем в разные приватные адреса или в разные порты.
Это если максимально ужаться, сделать Point-to-point и воспользоваться такой возможностью. В тексте скорее для иллюстрации, что обычным методом хоть заужимайся, но адреса расходуются.
Ну во-первых, можно, да. Но в RFC по Link-local для IPv4 написано, если правильно помню, что не следует использовать эти адреса при наличии нормальных и допускается их использовать, если приспичило.
Во-вторых, берём две циски и делаем следующий трюк:
R1#ping 10.0.0.2 source 169.254.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
Packet sent with a source address of 169.254.0.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms
R2#ping 169.254.0.1 source 10.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 169.254.0.1, timeout is 2 seconds:
Packet sent with a source address of 10.0.0.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms
А ещё Деда Мороза не существует
Что касается приватных адресов, то да, можно, см. выше.
Соглашусь, что это может так восприниматься. Просто вы в курсе, как это можно сделать в IPv4, а другие нет. И в IPv4 подобные штуки были сугубо опциональны, а в IPv6 это нормально, рекомендуется или даже требуется.
В любом случае, во имя Великой Справедливости добавил эту информацию в статью.
Скажу честно, что я это чудо тоже вживую не видел, пока только по диагонали просмотрел configuration guide. И кого спрашивал — тоже не видели. Но вопрос хороший, надо будет на досуге поразбираться.
Перечитал и понял, что не понял глобально-уникального ;) смысла комментария.
Варианты трактования:
1) IPv6 не нужен. Безблагодатный холивор, и если так, то уточню — маркетингом IPv6 не занимаюсь. Цель статьи — рассказать про особенности и «странности» IPv6, а не давать ему оценки.
2) Тёртых спецов ничего не удивляет и не пугает. Ну да, на то они и специалисты. Чтобы не было обид со стороны специалистов, немного переписал вступление. С другой стороны, статья не совсем для них, потому что объясняются основы основ IPv6.
3) ???
Не обязательно, но будем надеяться. Вообще в IPv6 на бумаге город-сад, развитой социализм и так далее. К сожалению, некоторые вещи на практике работают, а некоторые нет от слова «совсем».
В плане мультихоума как раз не всё гладко, потому что проблемы с ним фундаментальные. И в IPv6, если правильно помню, где-то до середины 2000-х была одна логика, а потом всё переосмыслили. Провайдеронезависимые (PI) адреса те же впихнули, хотя изначально планы были не допустить фрагментации адресного пространства как в IPv4.
Можно хоть сколько адресов, и в этом как раз вся соль.
Опять же, никто не запрещает вам поставить а) красивые адреса link-local или б) красивые MAC-адреса вида 02:00:00:00:00:01, как в предыдущей статье, чтобы не только link-local, но и все остальные адреса были такими.
Вопрос с предпочтением между IPv4 и IPv6 тонкий. В DNS у сайтов с IPv6 будут две записи — А и АААА, соответственно дальше уже ПО на компьютере решает, что использовать. Сейчас общая тенденция такая: либо IPv6 предпочитается, либо соединения отправляются одновременно, а там смотрим, кто ответил и кто быстрее.
По глобальным настройкам в Windows 7 есть вот такой KB. В частности там два «фиксика» — на приоритет IPv6 и наоборот IPv4.
По вопросам:
1. Общая рекомендация — если не используем, то отключаем, но это по соображениям безопасности. А так можете в те же торренты зайти и посмотреть, что там IPv6-пиры есть.
2. Для представителей Рос-трам-парам-надзоров — нельзя, и точка, и дальше читать не нужно. Для остальных — в IPv6 можно много чего, и в том числе многие ограничения не работают.
Могу посоветовать подключить себе домой IPv6-туннель, через того же Hurricane Electric — бесплатно и познавательно. Статьи где-то в округе были, но ссылки под рукой нет. Если будет нужно, могу и об этом написать.
MAC-адрес у интерфейса уникальный в пределах сегмента сети. В других сегментах такой же MAC может быть на любом устройстве.
Простой пример: ваш провайдер привязывается к MAC-адресам, а вы хотите поставить беспроводной роутер для раздачи трафика.
Способ 1: звоним в техподдержку, просим перепривязать.
Способ 2: заходим с компьютера на веб-интерфейс роутера, находим функцию «Clone MAC», делаем «тынц», и всё работает. На внешнем интерфейсе роутера будет такой же MAC, как у вашего компьютера.
На здоровье! Продолжение уже скоро, плюс есть более далёкая цель — несколько заметок по безопасности для IPv6 — ради которой на самом деле всё это и затевалось.
Из забавного: изначально MAC-48 и EUI-48 обозначали разные вещи и даже считались разными адресными пространствами. Позднее в IEEE передумали и сказали, что это все неправильно произносят EUI-48 как MAC, и вообще это одно и то же.
Ещё забавнее, что IPv6 делали до того, как IEEE приравняла MAC-48 и EUI-48. И вообще-то в стандарте записано, что MAC-48 -> EUI-64 делается с помощью вставки FF FF, а EUI-48 -> EUI-64 использует FF FE.
То есть разработчики IPv6 «накосячили», перепутав один вариант с другим. А потом IEEE их приравняла, и ошибка перестала быть ошибкой.
Пункт в RFC 3484 bis про выбор адреса на основании некст-хопа так никуда и не ушёл.
Судя по RFC 7157, время прошло, а проблема так и не решена. Один из подходов — ввести таблицы маршрутизации с source-destination. Т.е. то, что сейчас делает PBR. Но опять, статус сугубо экспериментальный, и даже если это будет, то не скоро.
Есть другие подходы — LISP, например, но идеальных нет. У некоторых есть большое желание сделать NPT (NAT66), но это всё обычно отметается по религиозным соображениям.
В общем, прошу прощения за дезинформацию, обещанный простой multihoming так и не запилили. Жаль.
Есть ещё одна тонкость, что выдаваемый провайдером префикс в случае сбоя нужно старить (рекламировать с нулевым lifetime), и с этим тоже могут быть проблемы.
Маршрутизация обратного трафика настраивается чуть проще, потому что в IPv6 для ответного трафика уже по адресу источника понятно, через какого из провайдеров отправлять. В случае с NAT тоже обходится: транслируем в разные приватные адреса или в разные порты.
Ну во-первых, можно, да. Но в RFC по Link-local для IPv4 написано, если правильно помню, что не следует использовать эти адреса при наличии нормальных и допускается их использовать, если приспичило.
Во-вторых, берём две циски и делаем следующий трюк:
А ещё Деда Мороза не существуетЧто касается приватных адресов, то да, можно, см. выше.
В любом случае, во имя Великой Справедливости добавил эту информацию в статью.
Варианты трактования:
1) IPv6 не нужен. Безблагодатный холивор, и если так, то уточню — маркетингом IPv6 не занимаюсь. Цель статьи — рассказать про особенности и «странности» IPv6, а не давать ему оценки.
2) Тёртых спецов ничего не удивляет и не пугает. Ну да, на то они и специалисты. Чтобы не было обид со стороны специалистов, немного переписал вступление. С другой стороны, статья не совсем для них, потому что объясняются основы основ IPv6.
3) ???
В плане мультихоума как раз не всё гладко, потому что проблемы с ним фундаментальные. И в IPv6, если правильно помню, где-то до середины 2000-х была одна логика, а потом всё переосмыслили. Провайдеронезависимые (PI) адреса те же впихнули, хотя изначально планы были не допустить фрагментации адресного пространства как в IPv4.
Опять же, никто не запрещает вам поставить а) красивые адреса link-local или б) красивые MAC-адреса вида 02:00:00:00:00:01, как в предыдущей статье, чтобы не только link-local, но и все остальные адреса были такими.
По глобальным настройкам в Windows 7 есть вот такой KB. В частности там два «фиксика» — на приоритет IPv6 и наоборот IPv4.
По вопросам:
1. Общая рекомендация — если не используем, то отключаем, но это по соображениям безопасности. А так можете в те же торренты зайти и посмотреть, что там IPv6-пиры есть.
2. Для представителей Рос-трам-парам-надзоров — нельзя, и точка, и дальше читать не нужно. Для остальных — в IPv6 можно много чего, и в том числе многие ограничения не работают.
Могу посоветовать подключить себе домой IPv6-туннель, через того же Hurricane Electric — бесплатно и познавательно. Статьи где-то в округе были, но ссылки под рукой нет. Если будет нужно, могу и об этом написать.
Простой пример: ваш провайдер привязывается к MAC-адресам, а вы хотите поставить беспроводной роутер для раздачи трафика.
Способ 1: звоним в техподдержку, просим перепривязать.
Способ 2: заходим с компьютера на веб-интерфейс роутера, находим функцию «Clone MAC», делаем «тынц», и всё работает. На внешнем интерфейсе роутера будет такой же MAC, как у вашего компьютера.
Ещё забавнее, что IPv6 делали до того, как IEEE приравняла MAC-48 и EUI-48. И вообще-то в стандарте записано, что MAC-48 -> EUI-64 делается с помощью вставки FF FF, а EUI-48 -> EUI-64 использует FF FE.
То есть разработчики IPv6 «накосячили», перепутав один вариант с другим. А потом IEEE их приравняла, и ошибка перестала быть ошибкой.