Ами мотивацията е основана на разликата между "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" конфигуриране.
Целта на прилагането и на двата метода е да се даде избор на клиентите, без да ги ограничаваме само с единия метод. Двата метода не интерферират между себе си (освен в много особени случаи). Те позволяват и навлизане в проблемите на използване на двата режима за хост конфигурация не само за администраторите, но и за крайните потребители, което е и една от основните цели.