Tue, Feb 08, 2011 at 16:29:41, gul wrote about "Re: [uanog] Изя всё.":
Ты представляешь в обозримом будущем v6-only ресурс? Которому настолько начхать на v4-пользователей, что он не озаботился покупкой себе v4-адреса?
Ну вообще-то такие уже существуют. Ссылки не приведу, но есть. Есть и такие, которые дают сильно облегчённый доступ через v6 и обычный через v4. Разумеется, это не гугл и не новостной сайт.
А провайдер для доступа к такому ресурсу делает у себя нат для пользователей, не поддерживающих ipv6? Не верится.
Пользователям, не поддерживающим v6, невозможно даже адресовать такой ресурс, поэтому такие варианты не рассматриваем. Можно обсуждать только доступ с v6 клиента на v4 сервер через NAT.
И это всё из-за того, что IPv6 разрабатывали в 1992-1995, когда и проблемы перехода выглядели иначе, да и сам IPv4 ещё не был повсеместно распространён.
Да, я об этом писал - что v6 начал разрабатываться ещё тогда, когда в v4 были классы сетей. И несколько принципиальных моментов основы v6 (как те же 128 бит адреса) вообще не имеют _никакого_ обоснования в основе.
На мой взгляд, правильнее было бы расширить адресное пространство, сохраняя обратную совместимость (я об этом уже писал у себя в блоге),
И как именно ты предлагаешь это сделать?
как asn16 расширили до asn32, или как time_t может быть 64-битным без всяких потрясений.
Плохие примеры. Для ASN32 расширение потребовало переделки софта всех участников, которые хотели полноценно видеть эти номера; а остальные получали какие-то огрызки, которые примерно соответствуют тому, как получилось с v4/v6. Расширение time_t до 64 бит сломало совместимость всех бинарных форматов, которые сохраняли время, и потребовало переходников с конвертерами. Ты не видишь его проблем только потому, что на самом деле мы этого переполнения не достигли. (Вообще, если отвлечься на time_t, то это клинически неудачная идея. Для представления времени точнее секунды, а это сейчас принципиально важно для большого количества случаев, мы должны хранить 12 байт, в то время как все альтернативные варианты хранят 8. Например, NT time имеет практически достаточную точность (100нс) и при этом представление 58 тысяч лет, если без знака. В Unix или храним микросекунды, тогда 12 бит теряется на ровном месте, или наносекунды, которые никто реально не умеет мерять на практически значимых платформах - 2 бита просто теряем, и ещё 10 забиваем мусором. Если мне придётся разрабатывать двоичный протокол с передачей времени, я там буду использовать именно NT time.)
Я не вижу в этом ни одной серьёзной проблемы,
Ты скажи, как именно ты собрался это реализовывать, и должны ли текущие реализации знать, что это уже не обычный IPv4 на 32 бита или нет, и как именно. Причём на всех уровнях. Например, как ты представляешь себе вместить 48 или 64 бита в struct sockaddr_in?
а при этом большинство проблем, которые возникают с IPv6, не возникли бы.
Слабо верится. Любое расширение - это несовместимость. IPv6 имеет одну принципиально важную основу: оно исходит из подхода "помирать, так с музыкой" - простите, "если ломать, то так, чтобы хватило надолго и всерьёз и не надо было ломать в ближайшие 10 лет". А что ты предложишь?
В первую очередь, не нужно было бы делать отдельную сетку, с отдельными BGP и таблицами роутинга,
Не отдельными? А какая цена замены 32->64?
с двумя разными адресами у пользователей и у сайтов, получать отдельные блоки адресов, практически полностью переписывать работу с сокетами в софте... И тогда через 2-5 лет (при поддержке вендоров) действительно мог бы состояться плавный переход на IPng, а на старые IPv4-адреса обращали бы внимания не больше, чем сейчас на шестизначные номера icq.
А так, как оно сделано в IPv6 - проблемы будут ещё и через 10, и через 20 лет, потому что не видно механизма, каким образом IPv4 может куда-то деться. IPv6 не заменит IPv4, равно как метро не заменит автомобили.
См. IPv4-compatible и IPv4-mapped адреса. IPv4 включается в IPv6 как частный случай. Но протокол всё равно надо менять, ты в рамках того же не сможешь включить более 32 бит не меняя формат пакета. -netch-