IPv6 за крайни потребители в учебните заведения

[vesso]

Колеги,

Мисля, че е време да направим някакво обобщение в мрежите на кои висши учебни заведения се алокират динамично или статично IPv6 адреси за крайни потребители. За сега знам за ПУ, в СУ имаме също голямо покритие на потребителиите с такива адреси. Добре е тези, които имаме опит, да помогнем на другите учебни заведения да въведат IPv6 за крайни потребители. Мисля, че няма да стане веднага, но важно е да има желание и конкретни действия.

Истината е, че IPv6 ще навлезе масово тогава, когато започнем да обменяме съдържание по него, а това няма как да стане без крайните потребители и техния интерес към обмен на съдържание.

Ще се радвам да има отклик по темата и да помогна с каквото мога. Ако сте заинтересовани от въвеждането на този адресен протокол при вас, пишете във форума.

[atanas]

Имате ли идея за инструмент, с който да се прави мониторин на IPv6 трафика? Това ще полезна информация за нас до колко сме успяли да вдъхновим хората. Ако говорим за съдържание по IPv6 си мисля за някое p2p приложение, което на първо (че и на второ) време да върви само по IPv6, но без ограничения.

[vesso]

Много се радвам, че Наско се обади по темата, защото знам, че той е ангажиран с прилагането на IPv6 на "последната" миля, т.е. до потребителите.

Ако правилно разбирам въпроса, целта е да споделим как извършваме мониторинг на трафика в посока "какво количество от общия трафик е по адресен протокол IPv6". В момента ние нямаме пусната подобна система за отчитане, но имаме идея за такава. В момента целия пакетен трафик се отчита заедно, без разделяне по адресен протокол, чрез Cacti. Оттам нататък нещата силно зависят от конкретните платформи за маршрутизация, от които ще получаваме данни за пакетния трафик през SNMP (или друг протокол/метод) за извличане на данни. При нас се използва Linux за платформа на маршрутизаторите и там най-уместно е броенето на IPv6 пакетите и трафика да се прави с позволяващо правило на пакетния филтър ip6tables. На основната на FORWARD веригата, могата да се напаравят страхотно специфични правила за отчитане на IPv6 трафика по адрес, протокол, порт, TCP сесия, hoplimit, източник и цел на пакета и т.н. Това изисква малко пипане по Cacti конфигурациите, разбира се. Нещата могат да се направят и под *BSD платформа чрез pf.

Що се касае до анализ на конкретни сесии, извадка за характера на трафика и прочие, може да се използва Wireshark. Той има IPv6 поддръжка при анализа, както е описано в неговата Wiki страница http://wiki.wireshark.org/IPv6. Освен това, Wireshark има добра прозоречна среда за GNOME (Wireshark-GNOME), която е доста удобна, но пък от друга страна кой ще е този, който ще пусне X и GNOME Desktop на маршрутизатор (?!). Да, може да се насочи трафика към файл и след това този файл да се анализира върху система с X и GNOME, но това е offline анализ. Също така много удобен за анализ инструмент е tcpdump, ако работите разбира се с Linux или *BSD базирани платформи за маршрутизатори. Най-лесното начало е:

# tcpdump ip6

и ще получите резюме за преминаващите IPv6 пакети. За по-голяма специфичност - man tcpdump. Само да напомня за тези, които четат това, че tcpdump използва libpcap. Това е критична по отношение на сигурността библиотека и ако не си актуализирате системата редовно и своевремено, по-добре не пускайте tcpdump или друго приложение, използващо libpcap. Wireshark също използва libpcap!

[iliev]

Само да отбележа, че Wireshark включва и много удобен command-line инструмент в лицето на tshark:

http://www.wireshark.org/docs/man-pages/tshark.html

Аз лично винаги го предпочитам пред tcpdump, разбира се, при положение, че е инсталиран.

[atanas]

Нашето уни радио (Радио Неко - http://radio.uni-plovdiv.bg) stream-ва по и IPv6 от самото му начало - 09.03.2007. Не е профи като Алма Матер, но за това пък децата му се кефят, аз също

[iliev]

И не пускате Бареков също... Kudos за което!

[iliev]

Иначе, по-сериозно, на доста места пуснахме IPv6 по опорните маршрутизатори още през 2005-та. Наистина, нямам пълна информация докъде е стигнало по-нататък "проникването" на протокола, и би било доста интересно да се разбере това.

[vesso]

В момента всички факултети в кампус "Лозенец" на Софийския Университет разполагат с IPv6 на "последна миля". Текущото състояние на адресацията включва "stateless" конфигуриране, който извършваме с radvd. След празниците ще започнем въвеждането на DHCPv6, а така също на multicast NTP. Много скоро ще пуснем IPv6 на "последна миля" и за хуманитарните факултети.

[atanas]

Любопитна ми е мотивацията ви за въвеждане на DHCPv6 след като сте пуснали radvd.

[vesso]

Ами мотивацията е основана на разликата между "stateless" и "statefull" конфигурация на хоста в IPv6.

Какво дава на клиентите "stateless" конфигурацията на хост в IPv6. Ами дава твърде малко. Обикновено цялата автоконфигурация в "stateless" режим протича като двустадиен процес: (i) получаване на адресен префикс и (ii) получаване на "router" адрес. Radvd предоставя само информация за префикса, чрез знанието на който стека на клиента да си помогне в процеса на генериране на глобалния динамичен адрес. Получаването на префикса става след мултикаст запитване от страна на клиентския стек. Чрез друго мултикаст запитване клиентът иска да получи "router" адреса в локалния сегмент. Изключително уязвим е вторият етап. Всяка машина, достъпна за мултикаст запитванията на клиента за "router" и обявила в стека си условия за "forward" на IPv6, може да отговори, че е маршрутизатор и да бъде избрана за next-hop хост по подразбиране, Вече имахме такъв прецедент, при който се стигна до липса на маршрутизация на изходящите от клиентите пакети. Първият етап обаче също е уязвим назависимо, че неговатя уязвимост е по-малко използваема за саботажи. Говоря за това, че има голямо сходство между локалния адрес (local link) и глобалния динамичен адрес. Причината е в алгоритъмът за генериране на глобалния динамичен IPv6 адрес. Съгласно този алгоритъм, генерирането на глобален динамичен IPv6 адрес става с т.нар. префиксно допълнение, което е вече направено за локалния IPv6 адрес. Ето как изглежда илюстрирано това:

Code: Select all

inet6 fe80::211:2fff:fe44:a1cb/64 scope link
inet6 2a01:288:8001:1:211:2fff:fe44:a1cb/64 scope global dynamic

За генериране на локалния адрес е използван префикса fe80::/64, а за глобалния 2a01:288:8001:1::/64. На първия ред е генерираният локален IPv6 (local link) адрес, а на втория е генерирания глобален динамичен IPv6 адрес. Забележете префиксното допълнение (211:2fff:fe44:a1cb) и как то се съдържа в генерирания от стека глобален IPv6 адрес (след като radvd е съобщил на клиента префикса 2a01:288:8001:1::/64). От друга страна префиксното допълнение съдържа част от MAC адреса на мрежовия адаптор, на който се присвоява генерирания адрес - последните 6 цифри от него (в случая 44:a1:cb). Излиза така, че от хост в Интернет, само при "засичане" на глобалния адрес на хоста, може да се получи информация за локалния адрес или за MAC адреса, което е полезно при извършване на атаки срещу инфраструктурата в дълбочина. Съществува начин за противодействие на това. Става дума за "temporary address". Това е втори адрес (конфигурира се на мрежовия адаптор успоредно с глобалния динамичен адрес), допълнително генериран от стека на клиента (освен глобалния динамичен адрес) и не страда от описания по-горе недостатък. По подразбиране стека използва "temporary" адреса в "src" полето на изходящите от клиента пакети. Например Windows XP и Windows Vista използват такъв адрес при автоконфигурация. Linux и *BSD базираните системи по принцип не използват "temporary" адреси.

От друга страна, звучи доста разточително (дори на фона на голямата размерност на адресните префикси в IPv6), да се използват по два адреса на всеки клиентски адаптор. Да не говорим, че самият "stateless" метод е също разточителен. Той изисква работа с /64 префикси, а това си е живо разхищение на адреси.

За момента "stateless" конфигурацията предоставя префикс и маршрут по подразбиране. За да намери клиентския хост услугите в мрежата, трябва да има вграден софтуер за "zeroconf", който да сканира локалната мрежа за често използвани услуги. "Zeroconf" включва серия от методи за откриване на различните услуги в мрежата, чрез "Service Discovery" софтуер. Под Linux и *BSD може за тези нужди може да се използва Avahi. Неудобствата при извършване на "zeroconf" са много, защото има много "draft" документи за директорийно откриване на услуги в локална мрежа, но не всички са приложени в клиентския софтуер, има различно третиране на услугите и начина им на откриване и т.н. Например, все още няма ясен и приложим метод за разкриване на рекурсивни DNS сървъри, защото те обикновено трябва да се указват по unicast, а не са достъпни по multicast. За момента повечето прилагащи "stateless" метода в IPv6 не се сблъскват с трудността на намирането на подходящите рекурсивни DNS сървъри от страна на клиентите. Причината е, че в съвремените условия на навлизане на IPv6 в употреба, клиентите работят в "dual-stack" режим, при който получават записите за сървъри за имена чрез някаква хост конфигурация по IPv4 (например DHCP). Това обаче изобщо не работи при една изцяло IPv6 мрежа, без "dual-stack" режим на работа. А ние трябва да предвиждаме и такова бъдеще...



Използването на DHCPv6 е "statefull" метод за конфигурация на хоста в IPv6. Удобстовото в случая е, че клиентският хост получава информация за набор от услуги пълно и по-бързо, без да се налага клиента да реализира "zeroconf". Това значи, че могат да се рекламират unicast услуги лесно и пълноценно (например рекурсивни DNS сървъри). DHCPv6 има много по-голяма специфичност при префиксното задаване и не е нужно да се заделя цял /64 префикс, може да се използва например /102 или /96, или по-голяма специфичност. Друга възможност е използването на профили за хостовете - даден хост може да има различен маршрутизатор по подразбиране, може да му се задава "temporary" адрес и прочие.

Не на последно място, чрез DHCPv6, в един етернет сегмент могат да съжителстват много IPv6 префикси, което няма как да стане чрез "stateless" конфигуриране.

Целта на прилагането и на двата метода е да се даде избор на клиентите, без да ги ограничаваме само с единия метод. Двата метода не интерферират между себе си (освен в много особени случаи). Те позволяват и навлизане в проблемите на използване на двата режима за хост конфигурация не само за администраторите, но и за крайните потребители, което е и една от основните цели.