[Irsi]

Всё равно это не проблема: функции IPv6-файрвола будут встроены в домашние роутеры точно также, как сейчас в них встроен NAT. Кто захочет закрыть порты - всегда сможет сделать это в настройках роутера. Но это будет со временем, а на первых порах про открытость портов IPv6 можно вообще не беспокоиться: вирусняку нужен эффек массовости, а пока IPv6 работает только в "заповедных зонах", разработчикам малвари вкладывать в него силы смысла нет.

Еще раз по буквам - NAT отключить нельзя, SPI - можно! Посему SPI неизбежно будет отключен юзверем при первой же проблеме или даже просто "профилактически"! Самое страшно - что это реально решит проблему! Вспомните как все хомячки упорно отключали UAC - наберите в гугле "как отключить в висте" и посмотрите ЧТО отключали в первую очередь. :) А заодно я хочу попросить поднять руки у кого на компе еще не отрублем встроенный виндовый фаервол. Или вспомнить как макинтоиды маниакально отрубали sudo... Примеров таких - вагон и маленькая тележка, та же одна строчка на перл - очень показательна.

[s.lobanov]

И будьте спокойны, в этих файрвола будут две отдельные кнопки "отключить файрвол совсем" и "отключить файрвол совсем и даже на портах 135, ..., ...". Не дураки люди, подумают об этом. Это вполне решаемые вопросы, из-за них никто отказываться от внедрения IPv6 не собирается.

А будет ли? А вдруг производители cpe'шок захотят срубить $$ и скажут, что ipv6 stateful firewall(и/или любой другой функционал относительно ipv6) нельзя реализовать(якобы не хватает аппаратных ресурсов или железка снята с поддержки и т.д. и т.п.)? Всё-таки не на всё можно залить *wrt. Будете менять такие железки или превращать их из L3 в тупые L2(и при этом не понятно что делать с IPv4)?

 

С точки зрения предоставления услуг шпд и получения $$ с этого пока не видно никаких преимуществ ipv6 над ipv4. Есть смысл тестировать всё железо на предмет совместимости с ipv6(и влиять на решения о закупках нового оборудования взависимости от результатов тестов), поэтому технические специалисты могут занять себя этим делом без угрызения совести, что тратят рабочее время на ерунду.

[Irsi]

Да даже если и будет там SPI с кучей кнопок - отключить, отключить совсем, отключить полностью, вырубить вообще все нафиг это не поможет. Собственно я высказался, писать еще раз лень - http://juick.com/Irsi/1271667

Добавлю только что в этих "руководствах для чайников" будет написано куда тыкать чтоб отключить SPI полностью. А если этого будет сделать нельзя - появятся "патчики" которые это делают. И разумеется половина этих патчиков будет делать и еще кое-что... чего юзверям знать не обязательно. Был один ботнет на линаксовых роутерах-мыльницах? При таком развитии событий их будет гораздо больше...

[Aliech]

Ожидаем ботнет на цисках-Ынтерпрайсах?

[Irsi]

Ожидаем ботнет на цисках-Ынтерпрайсах?

Ничего умного сказать не можешь, а хочется хоть что-нибуть сказать? Это невозможно и дело тут вовсе не в разнице в софте и железе между циской и китайской мыльницей-роутером с линаксом (хотя она конечно же огромна) - дело тут в том что мыльницами с линаксом управляют чайники типа тебя, а цисками - специалисты типа меня. А вот эта разница - уже принципиальна.

[AlexBT]

Цифровой коммунизм приближается: "Заходите люди добрые, берите все что хотите!"

Осталось привить коммунистическую идеологию каждому человеку Земли - не возжелай чужого - и можно жить при открытых дверях и окнах!

[mukca]

В общем и целом - конечно же вы правы. В данном конкретном случае - нет. NAT вполне успешно реализует некоторый базовый функционал фаервола... неполный и ограниченный разумеется, но... с более сложным простой юзер не сладит раз, два - этот базовый и ограниченный функционал отрезает возможности организации очень большого класса сетевых атак среди которых весьма много... неприятных.

Только не надо преписывать мне высказываний о том что якобы NAT это золотая пуля защиты и т.д. Нет - разумеется это не так. Но без него будет гораздо хуже чем сейчас. Да его можно заменить другими средствами. Но самый главный недостаток этих средств заключается в том что их можно отключить. Что и будет сделано 95% юзверей, вместо их настройки под их нужды. Последствия оного я думаю очевидны.

+100500

 

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

 

также с adsl. у кого модем работает бриджем более уязвимые для атак с инета чем у кого настроен модем роутером..

[mukca]

Ну а сейчас он в такой ситуации включает UPnP, и вся "безопасность" NAT-а идёт коту под хвост... Даже нет, UPnP и включать не надо: у современных роутеров он по умолчанию включен.

вредоносная программа должна уметь пользоваться UPnP

 

вредоносная программа должно попасть на комп.

как правило попадает через дыры в нетбиосе который в свою очередь не работает за натом :D

 

Всё равно это не проблема: функции IPv6-файрвола будут встроены в домашние роутеры точно также, как сейчас в них встроен NAT. Кто захочет закрыть порты - всегда сможет сделать это в настройках роутера. Но это будет со временем, а на первых порах про открытость портов IPv6 можно вообще не беспокоиться: вирусняку нужен эффек массовости, а пока IPv6 работает только в "заповедных зонах", разработчикам малвари вкладывать в него силы смысла нет.

уже предвижу кучу мануалов на всяких форумах в инете не работает то на таком то роуторе с ип 6 выключите вот это

а не работает то а вы пробовали выключить вот это

 

или уже забыли виндовс брандмауэр и UAC ???

[sirmax]

Прекращайте Ирси отвечать, это ж тролль.

[Aliech]

Прекращайте Ирси отвечать, это ж тролль.

Да знают тут и так все, что он - троль... Пусть пишет, читать интересно, до чего человек может дойти (=

 

Irsi, то есть ты считаешь, что заделать ботнет на кисках - не реально? Даже гипотетическая возможность отсутствует?

Изменено 20 марта, 2011 пользователем Aliech

[AlexBT]

Сломать можно что угодно, даже киску. Нужно только захотеть ...

[Irsi]

Aliech, я считаю что ты пишешь безграмотную фигню, на чтение которой не стоит тратить времени.

[Aliech]

Aliech, я считаю что ты пишешь безграмотную фигню, на чтение которой не стоит тратить времени.

Но ведь читаешь же! Вот в чём вся соль!

 

Потому что не можешь пройти мимо такого "богохульства" (=

Изменено 20 марта, 2011 пользователем Aliech

[Irsi]

Aliech, я считаю что ты пишешь безграмотную фигню, на чтение которой не стоит тратить времени.

Но ведь читаешь же! Вот в чём вся соль!

 

Потому что не можешь пройти мимо такого "богохульства" (=

Это было последнее собщение, которое я прочитал. :)

[Deac]

50 лет с момента внедрения?

Именно так.

 

Лет 10 отсилы, но думаю, уже через годика два достаточно созреет v6 и нужно будет немного двигаться в его направлении.

Х.з. м.б.

 

Лучший источник информации, ИМХО - драфты RFC http://www.ietf.org/1id-abstracts.html

 

Там среди прочего есть вот такой:

 

Network Working Group Joe Greco

Request for Comments: [nnnn] sol.net Network Services

Category: Experimental April 1, 2010

Expires March 2011

 

IPv4 Future Allocation Is Limited Unless Registries Expand

 

Status of this Memo

 

Distribution of this memo is unlimited.

 

By submitting this Internet-Draft, each author represents that any

applicable patent or other IPR claims of which he or she is aware

have been or will be disclosed, and any of which he or she becomes

aware will be disclosed, in accordance with Section 6 of BCP 79.

 

Internet-Drafts are working documents of the Internet Engineering Task

Force (IETF), its areas, and its working groups. Note that other groups

may also distribute working documents as Internet-Drafts.

 

Internet-Drafts are draft documents valid for a maximum of six months

and may be updated, replaced, or obsoleted by other documents at any

time. It is inappropriate to use Internet-Drafts as reference material

or to cite them other than as "work in progress."

 

The list of current Internet-Drafts can be accessed at

http://www.ietf.org/1id-abstracts.html

 

The list of Internet-Draft Shadow Directories can be accessed at

http://www.ietf.org/shadow.html.

 

Abstract

 

The momentum of the currently deployed IPv4 network has resulted

in a slower transition to IPv6 than expected, and IPv4 address

reserves may soon be exhausted. This memo defines an additional

class of IPv4 space which may be deployed as an interim solution.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Greco, Joe Expires March 2011 FORMFEED[Page 1]

 

 

 

 

 

Internet Draft IPv4 Class F Space April 1, 2010

 

 

Table of Contents

 

1. Introduction ....................................................2

2. Classful Addressing .............................................2

2.1. Expansion via Classful Addressing ..........................3

2.2. Impact on existing infrastructure ..........................3

2.3. Negative aspects to extending IPv4 lifetime ................4

2.4. Positive aspects to extending IPv4 lifetime ................4

2.5. Adjusted estimated IPv4 depletion date .....................4

2.6. Impact on IPv6 adoption ....................................4

3. Security Considerations .........................................5

4. IANA Considerations .............................................5

5. References ......................................................5

5.1. Informative References .....................................5

5.2. Acknowledgements ...........................................5

 

1. Introduction

 

The current Internet addressing scheme has been reasonably successful

at providing an Internet capable of providing network services to

users. However, because of massive growth and the increasing number

of networks being connected to the Internet, an ongoing shortage of

network numbers has brought us close to the point where assignable

IPv4 prefixes are exhausted. To combat this, the Internet is

currently undergoing a major transition to IPv6. Despite the looming

exhaustion of IPv4 space [iPv4_Report], IPv6 adoption rates have been

slower than expected. Policy suggestions to extend the availability

of IPv4 have ranged from reclamation of unused legacy IPv4

delegations [iCANN_feb08] to the use of carrier-grade NAT to place

most customers of service providers on RFC1918 space [Nishitani].

 

We propose a different solution to the problem.

 

RFC 1365 [RFC1365] and RFC 1375 [RFC1375] suggest some possible

methods for implementing additional address classes. While classful

addressing is now considered obsolete, the use of class to refer to a

particular portion of the IPv4 address space is still useful for that

purpose. Allocations within this space are expected to conform to

existing CIDR allocation guidelines. By allocating an additional

class, we gain a substantial amount of IP space.

 

 

 

 

 

 

 

 

 

 

 

Greco, Joe Expires March 2011 FORMFEED[Page 2]

 

 

 

 

 

Internet Draft IPv4 Class F Space April 1, 2010

 

 

2. Classful Addressing

 

Classful addressing was introduced in RFC 791 [RFC791], providing

Class A, B, and C spaces. RFC 1700 [RFC1700] defines Class D and E,

and we derive the resulting table:

 

Leading Network

Class Bits Bits Range

------ ------- ------- -----

A 0 8 .0.n.n.n-127.n.n.n

B 10 16 128.n.n.n-191.n.n.n

C 110 24 192.n.n.n-223.n.n.n

D 1110 undef 224.n.n.n-239.n.n.n

E 1111 undef 240.n.n.n-255.n.n.n

 

2.1. Expansion via Classful Addressing

 

While classful routing is generally no longer relevant, it provides

us with a useful clue about how to proceed. The prepending of a new

leading bit provides access to additional IP space, and so it would

seem to be a reasonable short-term fix to define a new class, Class

F, giving us:

 

Leading Network

Class Bits Bits Range

------ ------- ------- -----

A 0 8 0.n.n.n-127.n.n.n

B 10 16 128.n.n.n-191.n.n.n

C 110 24 192.n.n.n-223.n.n.n

D 1110 undef 224.n.n.n-239.n.n.n

E 1111 undef 240.n.n.n-255.n.n.n

F 10000 undef 256.n.n.n-511.n.n.n

 

This theoretically offers up to a few hundred more /8 assignments

that IANA would delegate to registries as an interim solution.

 

2.2. Impact on existing infrastructure

 

Currently deployed equipment may not be able to cope with an expanded

range within the first octet. In particular, a router might fail to

observe the additional leading bit. Such a scenario would

effectively map network 257/8 into 1/8 on that device. Such a

limitation can be carefully worked around through an allocation

strategy that avoids currently occupied space in the Class A through

C spaces. For example, 1/8 and 5/8 are currently IANA reserved

space, 7/8 is assigned to DoD, and other various networks are

unrouted or unoccupied as well. This suggests that 261/8 and 263/8

would be good targets for immediate allocation.

 

 

 

Greco, Joe Expires March 2011 FORMFEED[Page 3]

 

 

 

 

 

Internet Draft IPv4 Class F Space April 1, 2010

 

 

2.3. Negative aspects to extending IPv4 lifetime

 

IPv4 lifetime estimates have frequently been incorrect. This has

been one factor that had led to sluggish momentum in adopting IPv6,

and has not generated sufficient urgency to move from IPv4 to IPv6.

Artificially extending IPv4's available space with this proposal

would be likely to slow IPv6 adoption rates, at least somewhat, as

many decision makers would interpret the expansion of the IPv4 free

pool as a compelling reason to avoid unnecessary near-term investment

in migration to IPv6.

 

2.4. Positive aspects to extending IPv4 lifetime

 

The cost of upgrading or replacing many networking devices globally

is extremely high. A quick survey of contemporary networking devices

suggests that even many current devices are incapable of supporting

IPv6. The world is clearly not entirely ready for IPv6, and

therefore IPv4 can be expected to be a requirement for many more

years.

 

Further, IPv6 renders it almost impossible to memorize IP addresses,

which places undue burden on network engineers and analysts. Setting

up a newly configured device virtually demands a cut-and-paste

capable interface under IPv6.

 

Finally, IPv6 is designed to waste a few billion v4 Internets worth

of IP addresses for every autoconfigured ethernet. There are

virtually endless IP addresses that will never be used, and the

untapped potential wasted by IPv6 is depressing. IPv4, on the other

hand, will ultimately be pushed to its technical limits, with triple-

NAT becoming commonplace as service providers seek to optimize

available space. This will be very exciting and will also help to

keep network engineers gainfully employed.

 

2.5. Adjusted estimated IPv4 depletion date

 

The current RIR allocation rate is approximately 12 /8's per year.

This rate has grown slowly over time, and is estimated to be at least

20 /8's within five years. Extrapolation using conservative

estimates suggests that Class F space would be exhausted around April

1st, 2020.

 

2.6. Impact on IPv6 adoption

 

There has been much concern expressed about the slow adoption rate of

IPv6. In a situation where IPv4 space was nearly depleted, the slow

rate would be of great concern. However, by implementing Class F

space as outlined in this document, it should be clear that depletion

 

 

 

Greco, Joe Expires March 2011 FORMFEED[Page 4]

 

 

 

 

 

Internet Draft IPv4 Class F Space April 1, 2010

 

 

need not be imminent, and in 2020, when there are finally 5,000

routes in the IPv6 table and Class F space is depleted, another

clever solution will need to be devised.

 

3. Security Considerations

 

There are no security considerations relevant to this document.

 

4. IANA Considerations

 

No actions are required from IANA as result of the publication of

this document. Implementation of the proposal contained herein may

require some action, however.

 

5. References

 

5.1. Informative References

 

[iPv4_Report] Huston, G., "IPv4 Address Report", 2009,

<http://www.potaroo.net/tools/ipv4/index.html>.

 

[iCANN_feb08] ICANN, "ICANN Recovers Large Block of Internet Address

Space", February 2008,

<http://www.icann.org/en/announcements/announcement-2-10feb08.htm>.

 

[Nishitani] Nishitani, T., Yamagata, I., et. al., "Common Functions

of Large Scale NAT", draft-nishitani-cgn-03.

 

[RFC791] Information Sciences Institute, USC, "DARPA Internet Program

Protocol Specification", RFC 791, September 1981.

 

[RFC1365] Siyan, K., "An IP Address Extension Proposal", RFC 1365,

September 1992.

 

[RFC1375] Robinson, P., "Suggestion for New Classes of IP Addresses",

RFC 1375, October 1992.

 

[RFC1700] Reynolds, J. and Postel, J., "Assigned Numbers", RFC 1700,

October 1994.

 

 

 

5.2. Acknowledgements

 

The author would like to offer a special note of thanks to Robert E.

Seastrom <rs at seastrom.com> for pointing out that this would be

Class F space.

 

 

 

 

Greco, Joe Expires March 2011 FORMFEED[Page 5]

 

 

 

 

 

Internet Draft IPv4 Class F Space April 1, 2010

 

 

Authors' Addresses

 

Joe Greco

sol.net Network Services

P.O. Box 16

Milwaukee, WI 53201-0016

 

Phone: +1-888-830-2216

URI: http://www.sol.net/~jgreco

EMail: rfc-apr1 at 4ac18e35.biz.jgreco.net

 

 

Это конечно черновик и будет ли он принят - неизвестно, но пуект 2.5 такое положение не отменяет.

Т.е. ВЫДАЧА IPv4 закончится в 2020 г. ну и минимум 10 лет оно потом ещё проживёт.

 

[none7]

Category: Experimental April 1, 2010

F 10000 undef 256.n.n.n-511.n.n.n

EMail: rfc-apr1 at 4ac18e35.biz.jgreco.net

 

Изменено 21 марта, 2011 пользователем none7

[rm_]

Deac

Internet Draft IPv4 Class F Space April 1, 2010

 

Это конечно черновик и будет ли он принят - неизвестно, но пуект 2.5 такое положение не отменяет.

Т.е. ВЫДАЧА IPv4 закончится в 2020 г. ну и минимум 10 лет оно потом ещё проживёт.

Нда, а я вот читаю и думаю, вы сами на эту шутку купились, или это такой тончайший стёб над всеми присутствующими :)

[Deac]

Гы! ;)

 

Нашлись внимательные... :)

 

Но в каждой шутке есть доля... шутки.

Я не зря заострил внимание на п. 2.5, раздача остатков IPv4 реально займёт лет 10, где то быстрее, где то медленнее, но в целом до 2020 можно жить вполне спокойно.

Процесс мониторится постоянно, например здесь:

http://www.facebook.com/pages/IPv4-Countdown/162683847102050

 

[MATPOC]

Сети у провайдера в общем виде бывают двух типов:

 

1. L2 + BRAS в центре (PPOE, L2TP)
2. L3 + полисер на границе (PPTP, ISG, SCE, и т.д.)

В сети "L3 + полисер" обычная практика - один MAC от клиента, MAC привязывают к IPv4 (коммутатор доступа, в крайнем случае в центре сети). Для привязки IP к MAC нужно, чтобы коммутаторы доступа позволяли это делать. Сейчас у нас таких коммутаторов немного. Что означает масштабные затраты по замене парка.

 

Допустим, что ISP решил дать клиенту IPv6 со всеми "прелестями", в том числе много MAC от клиента. Это приводит к увеличению MAC адресов в таблицах коммутаторов (или BRAS) как минимум в 1.5-2 раза. И на некоторых уже установленных железках это приведёт к переполнению таблицы MAC адресов.

 

Про NAT как защиту клиента от сетевых атак выше уже говорилось.

 

Ну и неготовность биллинга - это уже тоже обсуждалось.

[rm_]

MATPOC

в сети провайдера кол-во MAC не увеличится, по-прежнему будет один (ЦПЕшечка), на которую провайдер даёт по DHCPv6-PD префикс, а уже она в локалку позади себя раздаёт всё что угодно. Вы бы хоть немного матчасть поизучали, прежде чем панику разводить.

Если не даёт покоя биллинг и тыды и тыпы, поставьте 6rd как сделал ЗСТТК, и ваш глупый v4-only биллинг даже ничего не заметит.

[MATPOC]

в сети провайдера кол-во MAC не увеличится, по-прежнему будет один (ЦПЕшечка), на которую провайдер даёт по DHCPv6-PD префикс, а уже она в локалку позади себя раздаёт всё что угодно. Вы бы хоть немного матчасть поизучали, прежде чем панику разводить.

Если не даёт покоя биллинг и тыды и тыпы, поставьте 6rd как сделал ЗСТТК, и ваш глупый v4-only биллинг даже ничего не заметит.

"ЦПЕшечка" с поддержкой IPv6 у клиента откуда возьмётся? Провайдер подарит?

[rm_]

MATPOC

Гм, а вы не задаётесь вопросом, откуда у абонента возьмётся, например, компьютер?

Почему удивляет, что для использования некоторой технологии абоненту нужно иметь оборудование с её поддержкой?

Я понимаю, что CPE как таковую имеет далеко не каждый, у многих в сеть провайдера включён сразу их ПК, и уже он раздаёт интернет для остальных девайсов - но ведь в этом случае даже проще.

И да, некоторые провайдеры раздают/продают при подключении и потом поддерживают CPE с преднастроенной прошивкой.

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

[MATPOC]

Гм, а вы не задаётесь вопросом, откуда у абонента возьмётся, например, компьютер?

Почему удивляет, что для использования некоторой технологии абоненту нужно иметь оборудование с её поддержкой?

То есть говорим клиенту, что он обязан выкинуть/продать уже имеющийся у него CPE и купить CPE с поддержкой IPv6? А что клиент ответит?

 

Я понимаю, что CPE как таковую имеет далеко не каждый, у многих в сеть провайдера включён сразу их ПК, и уже он раздаёт интернет для остальных девайсов - но ведь в этом случае даже проще.

У нас таких - единицы. Потому как для большинства клиентов в сто раз проще купить железку, чем самому настраивать ПК для раздачи интернета по квартире.

 

MATPOC

И да, некоторые провайдеры раздают/продают при подключении и потом поддерживают CPE с преднастроенной прошивкой.

Можно пример такого провайдера? За исключением проприетарных DOCSIS или отживающих свой век xDSL.

 

Впрочем, это уже начинает походить на маленький флейм и уход в частности. Основное Ваше возражение о повышении количества MAC адресов в сети провайдера - наличие у клиента CPE с поддержкой IPv6.

Изменено 21 марта, 2011 пользователем MATPOC

[rm_]

То есть говорим клиенту, что он обязан выкинуть/продать уже имеющийся у него CPE и купить CPE с поддержкой IPv6?

Если хочет использовать IPv6 ("и уже сегодня получить личную подсеть белых адресов совершенно бесплатно") - да.

Не хочет - пусть остаётся с серым IPv4 позади провайдерского NAT44, и без v6.

 

Впрочем, это уже начинает походить на маленький флейм и уход в частности. Основное Ваше возражение о повышении количества MAC адресов в сети провайдера - наличие у клиента CPE с поддержкой IPv6.

Я не понял, а вы что предлагаете в качестве альтернативы?

Включать домашнюю локалку клиента в сеть провайдера (и оттуда в IPv6-интернет) тупым L2-коммутатором? Это безумие.

[none7]

Я не зря заострил внимание на п. 2.5, раздача остатков IPv4 реально займёт лет 10, где то быстрее, где то медленнее, но в целом до 2020 можно жить вполне спокойно.

Вы об этом?

Class F space would be exhausted around April 1st, 2020.

Да и не всё ли ровно когда IPv4-адреса кончатся в мире? России адреса выдаёт RIPE, а у них адреса должны закончится ещё до 2012.