[AlexUkr]

Дело в том, что в случае с IPv6 создатели стандарта не просто продумали всё очень далеко наперёд, более того, они предусмотрели даже вероятность своей собственной ошибки. Именно поэтому раздача IPv6-адресов ограничена подсетью /3: если через 50 лет вдруг окажется, что текущий суперпродуманный план присвоения IPv6 адресов по какой-то причине дал трещину, то просто распечатают ещё одну /3 и для неё уже придумают другой план, учитывающий изменившиеся обстоятельства.

 

Но скорее всего, даже этого делать не придётся, потому что на крайний случай всегда можно будет начать раздавать домашним юзерам не /56, а /60, и тогда количество возможных подсетей увеличится в 16 раз, а этого уж точно хватит всем. Но даже в самом-самом-самом худшем случае, раздавать всего лишь по /64 на абонента никто не собирается, потому что наличие у каждого абонента нескольких подсетей - это одна из фундаментальных идей IPv6.

Изменено 3 марта, 2011 пользователем AlexUkr

[evd]

Если сейчас велят, что автонастройка работает при 64 и короче бит сети, то будет куча софта, где это вшито намертво...

Ну во-первых, не велят, а рекомендуют. От classfull network design отказались как только осознали его непрактичность. Текущие рекомендации по IPv6 вполне обоснованы, в том числе в отношении "квантования" по /64. (Ну да, замучаешься считать количество знаков в числе адресов /64, но и число таких "квантов" - ничем не меньше). Изменятся обстоятельства - поменяется и практика "квантования"

 

И во-вторых, st_re, ну какое отношение к вашему прогнозу про 15 лет жизни IPv6 имеет тот прискорбный факт, что старое железо знает только старые стандарты? К тому же, в наш век железки приходится менять с сумашедшей частотой совсем не по этой причине

Изменено 3 марта, 2011 пользователем evd

[AlexUkr]

st_re, если ваш психологический барьер насчёт раздачи /56 на каждого домашнего абонента действительно такой уж серьёзный, раздавайте им по /60. Это вполне поддерживаемый стандартами вариант (как раз одна шестнадцатеричная цифра). 16 подсетей - это тоже неплохо, а в вашей /32 подсети такая нумерация позволит подключить уже не 16, а целых 268 миллионов абонентов.

[ipaddr.ru]

http://www.circleid.com/posts/ip_blocklists_email_and_ipv6/

Вот тут показаны некоторые мнения по поводу блеклистинга в SMTP over IPv6. Так сказать, рассмотрение проблемы не на сетевом, а на сеансовом уровне.

[alks]

Вообщем все ясно - всем частникам даем /56

 

http://www.circleid.com/posts/ip_blocklists_email_and_ipv6/

Вот тут показаны некоторые мнения по поводу блеклистинга в SMTP over IPv6. Так сказать, рассмотрение проблемы не на сетевом, а на сеансовом уровне.

забавно, сразу возникает аналогичный вопрос про обратную зону DNS, как прописывать в ней адреса, только тех кому на самом деле это нужно?

[rm_]

сразу возникает аналогичный вопрос про обратную зону DNS, как прописывать в ней адреса, только тех кому на самом деле это нужно?

В идеале - возможность клиенту в личном кабинете указать DNS-сервер для делегации.

Если это не получается, следующий вариант - автогенерация.

Пример: http://member.wide.ad.jp/~fujiwara/v6rev.html

Кажется есть модули с аналогичной функциональностью также для BIND и PowerDNS.

Изменено 4 марта, 2011 пользователем rm_

[alks]

rm_ спасибо большое

[nomo]

Самое тяжёлое в IPv6 поначалу, это привыкнуть к с виду безумнейшему разбазариванию адресов. ;)

Человек смотит глазами BASIC на программирование в C. В итоге получаются программы с исходником в одну строку,

операторами, разделёнными точкой с запятой, изобилующим использованием goto.

Дабы сэкономить свой /32 будет выдавать клиенту по /128. :)

[nomo]

http://www.circleid.com/posts/ip_blocklists_email_and_ipv6/

Вот тут показаны некоторые мнения по поводу блеклистинга в SMTP over IPv6.

IETF кроме приведённых 3-х вариантов решения проблемы блокировки спама, забывает ещё об одном, the Ultimate, так-сказать, варианте ---- отказаться от использования SMTP и перейти на протокол с авторизацией отправителя. Хотя и решение с отказом от релеинга почты через IPv6 мне тоже кажется верным.

[ipaddr.ru]

Это как-то слишком Ultimate, я считаю. Речь идет только о замене сетевого уровня. Протокол-то может на любой сети теоретически работать.

[st_re]

Кстати тут подумалось.. А что бы не давать ipv6 с номером в первой группе полученном из номера страны.. ну скажем 2001 - штаты, 2007 Россия, 2046 - Швеция итд... (когда Китаю не хватит его /16, выдать ему 3086, 4086 итд.) Всякие geoip упростились бы до предела. В принципе можно было бы и дальше 2007:495x::.... правда тогда пришлось бы операторам давать не /32 а /48 (ну а на конечного пользователя можно и /96)...

 

всяко-разно варианты определения страны один хрен востребованы. А так все чисто и прозрачно.... уж коли IP хоть чем жуй..

 

ну ладно, поздно, уже поделили.

[st_re]

nomo не далее как несколько дней назад отловили нескольких абонентов от имени которых с разных сильно внешних IP рассылали спам.. через наш релай с их (наших абонентов) честными паролями. Судя по потоку спама через АОЛ, полезшему месяц или около того назад, это начало массового применения авторизованного по ворованным паролям релеинга (единичные случаи бывали и раньше, но сейчас оно стало более массовым.).. прикажете не брать почту с серверов AOLа от пользователя AOLа (да не важно по какому там протоколу, SMTP только транспортный протокол, предложите любой другой) ? И не важно, подпишет ли тот сервер письмо по дороге или нет, авторизуется он у меня или нет.

 

Поймали абонента на хостинге, которому на сайт залили php, вызвали его несколько раз и.. стерли php. Ну а сама php разослала по много писем.

 

Или спама во всяких ICQ подобных сетях не водится ? там, как бы, все авторизуются.

 

Авторизация абонента не панацея. она воруется. Вон, умудряются вирусом платежки в банк слать, с подписью по ЦП. (ну да, разгильдяйство со стороны подписывающих, но найдите абонента - не разгильдяя, смотрящего за безопасностью ?). Капчи-хренапчи тоже обходятся при должном желании со стороны желающего.

[SLon26]

http://www.circleid.com/posts/ip_blocklists_email_and_ipv6/

Вот тут показаны некоторые мнения по поводу блеклистинга в SMTP over IPv6.

IETF кроме приведённых 3-х вариантов решения проблемы блокировки спама, забывает ещё об одном, the Ultimate, так-сказать, варианте ---- отказаться от использования SMTP и перейти на протокол с авторизацией отправителя. Хотя и решение с отказом от релеинга почты через IPv6 мне тоже кажется верным.

Вы видимо не читали http://www.rhyolite.com/anti-spam/you-might-be.html :)

[ipaddr.ru]

Кстати тут подумалось.. А что бы не давать ipv6 с номером в первой группе полученном из номера страны.. ну скажем 2001 - штаты, 2007 Россия, 2046 - Швеция итд... (когда Китаю не хватит его /16, выдать ему 3086, 4086 итд.) Всякие geoip упростились бы до предела. В принципе можно было бы и дальше 2007:495x::.... правда тогда пришлось бы операторам давать не /32 а /48 (ну а на конечного пользователя можно и /96)...

 

всяко-разно варианты определения страны один хрен востребованы. А так все чисто и прозрачно.... уж коли IP хоть чем жуй..

 

ну ладно, поздно, уже поделили.

Никто вам не мешает прописывать в IPv6 адресе номер договора абонента.

[rm_]

отказаться от использования SMTP и перейти на протокол с авторизацией отправителя

Your post advocates a

 

(X) technical ( ) legislative ( ) market-based ( ) vigilante

 

approach to fighting spam. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state before a bad federal law was passed.)

 

( ) Spammers can easily use it to harvest email addresses

( ) Mailing lists and other legitimate email uses would be affected

( ) No one will be able to find the guy or collect the money

( ) It is defenseless against brute force attacks

( ) It will stop spam for two weeks and then we'll be stuck with it

(X) Users of email will not put up with it

( ) Microsoft will not put up with it

( ) The police will not put up with it

( ) Requires too much cooperation from spammers

(X) Requires immediate total cooperation from everybody at once

(X) Many email users cannot afford to lose business or alienate potential employers

( ) Spammers don't care about invalid addresses in their lists

( ) Anyone could anonymously destroy anyone else's career or business

 

Specifically, your plan fails to account for

 

( ) Laws expressly prohibiting it

(X) Lack of centrally controlling authority for email

( ) Open relays in foreign countries

( ) Ease of searching tiny alphanumeric address space of all email addresses

( ) Asshats

( ) Jurisdictional problems

( ) Unpopularity of weird new taxes

( ) Public reluctance to accept weird new forms of money

(X) Huge existing software investment in SMTP

( ) Susceptibility of protocols other than SMTP to attack

( ) Willingness of users to install OS patches received by email

( ) Armies of worm riddled broadband-connected Windows boxes

( ) Eternal arms race involved in all filtering approaches

(X) Extreme profitability of spam

( ) Joe jobs and/or identity theft

( ) Technically illiterate politicians

(X) Extreme stupidity on the part of people who do business with spammers

( ) Dishonesty on the part of spammers themselves

( ) Bandwidth costs that are unaffected by client filtering

( ) Outlook

 

and the following philosophical objections may also apply:

 

( ) Ideas similar to yours are easy to come up with, yet none have ever

been shown practical

( ) Any scheme based on opt-out is unacceptable

( ) SMTP headers should not be the subject of legislation

( ) Blacklists suck

( ) Whitelists suck

( ) We should be able to talk about Viagra without being censored

( ) Countermeasures should not involve wire fraud or credit card fraud

( ) Countermeasures should not involve sabotage of public networks

(X) Countermeasures must work if phased in gradually

( ) Sending email should be free

( ) Why should we have to trust you and your servers?

( ) Incompatiblity with open source or open source licenses

( ) Feel-good measures do nothing to solve the problem

( ) Temporary/one-time email addresses are cumbersome

( ) I don't want the government reading my email

( ) Killing them that way is not slow and painful enough

 

Furthermore, this is what I think about you:

 

(X) Sorry dude, but I don't think it would work.

( ) This is a stupid idea, and you're a stupid person for suggesting it.

( ) Nice try, assh0le! I'm going to find out where you live and burn your

house down!

[Dyr]

Коллеги, расскажите про поднятие Teredo-relay у себя в сети. Я что-то не совсем понимаю, как диапазон адресов 2001: в этом случае роутить, он же не из нашего inet6num?

А если бы кто ещё и рассказал про опыт поднятия IPv6 туннелей с Juniper, вообще был бы всемерно признателен.

[ipaddr.ru]

К вопросу о борьбе со спамом - я только что получил спам over IPv6 транспорт. Впервые, надо заметить.

Return-Path: <fnknn@hotmail.com>
Received: from mbe.prov.ru (mail.prov.ru [IPv6:2a00:1820:0:1820::2])
        (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
        (Client did not present a certificate)
Message-ID: <CF095E3A1EEA4A52AE4E6CD54F90ACBD@lroymhr>
From: =?koi8-r?B?58HMyc7BIOIu?= <fnknn@hotmail.com>
To: =?koi8-r?B?8C4g8y4=?= <rui@nextmail.ru>

[nomo]

Это как-то слишком Ultimate, я считаю.

Почему? Таким образом мы сузим проблему управляемости базой данных чёрных списков (ведь именно об этом пишет автор статьи) с O(количество IPv6 адресов) до O(количество доменов). К тому же скоринг по доменной части выйдет гораздо точнее чем по префиксу IPv6.

 

Кстати тут подумалось.. А что бы не давать ipv6 с номером в первой группе полученном из номера страны.. ну скажем 2001 - штаты, 2007 Россия

Так никто не мешает. Необходимо создать National Internet Registry: http://www.ripe.net/ripe/docs/ripe-512#definitions.

И, кстати, почему 2001 ---- США, 2007 ---- Россия? ISO-3166 Country Code России ---- 643, США ---- 840. Соответственно Data Country Code для России ---- 250, для США ---- 310.

 

прикажете не брать почту с серверов AOLа от пользователя AOLа?

Ну, если вы желаете продолжать кушать кактус, никто не может помешать вам это делать.

 

Вы видимо не читали http://www.rhyolite.com/anti-spam/you-might-be.html :)

Действительно, сего опуса не читал. Дык ведь в статье речь идёт немного о другом:

 

Bumping the IP address from 32 bits to 128, bumping the 4 billion up to a billion billion billion or so — the number doesn't matter, at that point — makes it infeasible to keep a list of bad addresses. There are enough addresses there to allow the bad guys to use a new one every time, so we'd never see repeats.

Your post advocates a

 

(X) technical ( ) legislative ( ) market-based ( ) vigilante

 

approach

Эти страшилки давно известны и как-то совсем не пугают. "Alienate potential employers", ха-ха. Не дошёл e-mail? Бывает. Ради бога, есть Skype, ICQ, факс, телефон. В конце-концов go to Post Office. Было бы желание.

[st_re]

прикажете не брать почту с серверов AOLа от пользователя AOLа?

Ну, если вы желаете продолжать кушать кактус, никто не может помешать вам это делать.

 

Ок, перефразирую, "прикажете не брать сообщения ICQ с сервера ICQ" ну или для разнообразия "персональные сообщения с форума NAG.RU с сервера forum.nag.ru". проблема спам овер smtp стоит исключительно по причине популярности SMTP. Не будет SMTP будет хрен_те_знает_что_за_TP. Оно не важно. Поменяется цвет кактуса. при желании обмениваться сообщениями там рано или поздно появится спам. Чем популярнее будет система обмена, тем более там будет спама. мне нравится этот кактус, если Вам нравится другой, то на вкус и цвет все фломастеры разные, это Ваше право жрать другой кактус.

 

Транспорт даже не вторичен. от третичен. И от того, был ли авторизован клиент отправивший спам, оно не зависит что это таки спам.

[nomo]

Ок, перефразирую, "прикажете не брать сообщения ICQ с сервера ICQ" ну или для разнообразия "персональные сообщения с форума NAG.RU с сервера forum.nag.ru".

Лёг сервер ICQ ---- лежит всё ICQ. Лёг SMTP-сервер AOL ---- отряд не заметил потери бойца.

 

от того, был ли авторизован клиент отправивший спам, оно не зависит что это таки спам.

Вы статью почитайте. Там IETF борется за то, чтобы размер БД чёрного списка был manageable. В случае отправки спама по SMTP с sdkfljdkfg@dfpoir.com нужно парсить envelope и запихивать в базу данных все IP Received. В случае авторизации этого "sdkfljdkfg" в базу нужно будет запихнуть всего один e-mail, т. к. спамить от произвольного имени станет невозможно.

[st_re]

первым делом в ресивед будут появляться microsoft.com, whitehouse.gov и подобные им... ресивед, кроме последнего (того, который свой) , он как бы не trusted, туда все что угодно вставляется, как и в поле фром... количество попертых емейлов-паролей, если приспичит кому, будет огромно. В большинстве своем абонент на слова "у вас вирус" сообщает "а мне не мешает". (ну до тех пор пока вирус не начинает спрашивать про заплатить сообщением на весь экран). У меня есть хостеры, которым пароль на доступ к их сайту менялся раза по 2 в году, по причине "поперли".. Были абоненты которые сами заливали уже затрояненый сайт.

 

Да и вообще, была идея прописывать легитимные источники почты для домена (SPF). И ? в 99% случаев такой записи нету (ну или там написано +алл). чтобы метод был действенным, его нужно применять массово.

 

 

[SLon26]

А что за проблема в существующей схеме блек листов блеклистить /64 ? Записей конечно станет больше, за счет выхода из за ната кучи затроянненых машин, но размеры блек листов и сейчас только растут.

http://tools.ietf.org/html/draft-levine-iprangepub-01 - в этом черновике это уже и описанно, на рассылке spamassassin'a обсуждали его

[ipaddr.ru]

Это как-то слишком Ultimate, я считаю.

Почему? Таким образом мы сузим проблему управляемости базой данных чёрных списков (ведь именно об этом пишет автор статьи) с O(количество IPv6 адресов) до O(количество доменов). К тому же скоринг по доменной части выйдет гораздо точнее чем по префиксу IPv6.

Для меня - хотя бы потому, что я через SMTP over IPv6 решаю сейчас обратную задачу - увеличение доли трафика IPv6 в интернете.

[nomo]

У меня есть хостеры, которым пароль на доступ к их сайту менялся раза по 2 в году, по причине "поперли"..

Аналогичная ситуация. У некоторых умудрялись и по 3 и по 4 раза за год уводить пароли.

 

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

Правильно.

 

я через SMTP over IPv6 решаю сейчас обратную задачу - увеличение доли трафика IPv6 в интернете.

Оригинально. Вы идеалист. :)

 

А я скорее всего отключу SMTP на IPv6 интерфейсах, мне всё больше кажется эта альтернатива достаточно сбалансированным ответом.

Изменено 4 марта, 2011 пользователем nomo

[netime]

сразу возникает аналогичный вопрос про обратную зону DNS, как прописывать в ней адреса, только тех кому на самом деле это нужно?

В идеале - возможность клиенту в личном кабинете указать DNS-сервер для делегации.

Если это не получается, следующий вариант - автогенерация.

Пример: http://member.wide.ad.jp/~fujiwara/v6rev.html

Единственно правильный вариант обратная зона в личном кабинете.(хотя бы по требованию - 5-6% абонентов).

автогенерация для домохозяек им пофиг.

 

и

DNS-серверЫ

 

 

И, кстати, почему 2001 ---- США, 2007 ---- Россия?

8-1... межд. тел. код США

8-7....межд. тел. код России

Изменено 4 марта, 2011 пользователем netime