Опубликован: 30.07.2013 | Доступ: свободный | Студентов: 1862 / 145 | Длительность: 24:05:00
Лекция 9:

Управление групповым трафиком

Оказавшись в списке исключений, запись об источнике вызывает его блокировку, а значит, потенциальное уменьшение трафика в канал. Это желанное для маршрутизатора состояние, и нет причин прерывать его по тайм-ауту. Если вдруг у источника снова возникнет слушатель, он заявит о себе отчетом. Такова модель MLD: слушатели группы обязаны напоминать о себе, а в MLDv2 и о своем выборе источников, так как по умолчанию маршрутизатор не продвигает групповой трафик в канал. Следовательно, на записях в списке исключений таймер остановлен.

С другой стороны, список исключений — атрибут исключающего режима фильтра, а в этом режиме маршрутизатор и близко не может подойти к своей заветной мечте, а именно заблокировать все источники, потому что ему дозволено блокировать только перечисленные N из них, а остальные 2^{128}-N беспрепятственно шлют пакеты группе. Это настоящий кошмар для маршрутизатора! Поэтому в его интересах перевести фильтр группы во включающий режим, как только исчезнут слушатели в исключающем режиме. Маршрутизатор не ведет их поименного списка, и ему остается снова положиться на таймер. Это так называемый "таймер фильтра" (Filter Timer) на записи о группе. Он активен только в исключающем режиме и перезапускается по приходу отчета IS_EX или TO_EX, поскольку такой отчет говорит, что на канале все еще есть слушатели группы в исключающем режиме. Но если интервал этого таймера истечет, у маршрутизатора будет полное право переключить фильтр во включающий режим за отсутствием слушателей группы в исключающем режиме.

Однако, как маршрутизатор ни стремится свести трафик группы на нет, он обязан допускать источники к группе по требованию ее слушателей. В частности, ему не пристало самовольно блокировать те источники, о которых недавно были отчеты IS_IN, TO_IN или ALLOW. Поэтому, переводя фильтр группы во включающий режим, маршрутизатор обязан позаботиться, чтобы новый список включений заранее содержал в себе, по меньшей мере, все записи о желательных источниках; ведь иначе они окажутся заблокированы по умолчанию. Выходит, что накапливать эту информацию фильтр должен заранее, еще в исключающем режиме. Понадобится ли для этого новый список источников в памяти маршрутизатора? Попробуем обойтись уже доступным списком требований, если он сможет играть обе роли. В принципе, маршрутизатору ничто не мешает сохранять записи о желательных источниках в этом же списке. Вопрос только в том, насколько оправдано хранить оба вида информации в одном списке: записи о желательных источниках и записи о тех источниках, которые маршрутизатор пытается заблокировать. Чтобы предотвратить путаницу, заметим такое простое свойство "собираемого" нами механизма: если пришел отчет IS_EX или TO_EX, то фильтр останется в исключающем режиме как минимум на протяжении интервала своего таймера. Если этот интервал будет, скажем, равен тайм-ауту записи об источнике, то у слушателей во включающем режиме будет еще достаточно времени, чтобы снова заявить о своем выборе источников в ответ на периодические запросы маршрутизатора. Поэтому маршрутизатор, получив отчет IS_EX или TO_EX, вправе вычистить из списка требований все записи, кроме текущих кандидатов на блокировку [§7.2.3 RFC 3810].

Выше мы позволили себе вольность говорить о работе таймеров маршрутизатора в обыденных терминах "давно" и "недавно". В общем, понятно, что "недавно" — это пока интервал таймера не истек, а какой таймер, следует из контекста. Тем не менее, нам явно следует добавить определенности в эту картину. Мы сошлись на том, что у каждой группы есть два вида таймеров.

Первый из них — это таймер одного источника данной группы. Во включающем режиме MLDv2 он играет ту же роль, что и таймер всей группы в MLDv1, а именно позволяет маршрутизатору определить, что пора блокировать трафик, так как его больше никто не принимает. Разница только в том, что маршрутизатор MLDv1 оперировал целыми группами, тогда как его "потомок" в MLDv2 работает тоньше и управляет отдельными источниками, вещающими группе. Поэтому, когда срабатывает такой таймер, в MLDv1 маршрутизатор удалил бы запись о группе, а в MLDv2 он удаляет вместо этого запись об одном источнике. Когда фильтр INCLUDE(A) опустеет, будет пора удалить и всю запись о группе, так что отельный таймер группы здесь не требуется.

Насколько большой интервал понадобится таймеру источника? Этот таймер перезапускается по приходу отчета, что данный источник интересен какому-то слушателю данной группы, и поэтому интервал должен быть таким, чтобы заведомо перекрыть период между отчетами; ведь иначе состояние фильтра группы будет неустойчивым, фильтр станет "хлопать". Пока слушатели не меняют своего состояния, их отчеты вызывает маршрутизатор, высылая периодические запросы. Это довольно дорогая операция, так как, в теории, все слушатели канала должны в ответ сообщить свои фильтры в отчетах IS_IN или IS_EX, поэтому период между запросами, QI (Query Interval), должен быть довольно большим, по умолчанию 125 секунд [§9.2 RFC 3810].

Вдобавок одиночный запрос мог не дойти до некоторых слушателей, скажем, из-за сбоя или перегрузки канала. Тем не менее, есть надежда, что какой-то из последующих запросов все-таки дойдет, и поэтому маршрутизатор должен подождать, как минимум, еще несколько интервалов QI, прежде чем объявить источник невостребованным и удалить его запись. Сколько всего раз надо передать сообщение, чтобы оно наверняка дошло, — это параметр RV (Robustness Variable), зависящий от ненадежности канала, по умолчанию 2 [§9.2 RFC 3810]. Такой повтор защитит от RV-1 потерь. Наконец, слушатели не ответят на запрос все хором, а сделают случайные паузы, чтобы распределить нагрузку на канал. Верхняя граница такой паузы — параметр QRI (Query Response Interval), по умолчанию 10 секунд [§9.3 RFC 3810].

В результате, пока сеть стабильна, интервал таймера источника должен быть не менее чем QI \times RV+QRI; по умолчанию выходит 260 секунд. Этот интервал обозначают MALI (Multicast Address Listening Interval) [§9.4 RFC 3810].

Интервал QI входит в MALI ровно RV раз, а не RV - 1, и вот почему. Нам никто не гарантирует, что возникновение записи об источнике совпадает с отправкой периодического запроса. Поэтому до ближайшего запроса придется подождать, самое большее, время QI. Затем следует RV - 1 интервалов длиной QI, когда запрос повторяется. Поэтому всего выходит RV интервалов длины QI.

Чем пренебрегает формула для MALI? (Задержкой канала.)

Но вот, представим себе, маршрутизатор получает отчет, который дает ему повод усомниться в некоторых записях, к примеру, отчет BLOCK. В ответ маршрутизатор начинает активную проверку этих записей запросами, ограниченными группой и списком источников. Эквивалентом этого сценария в MLDv1 был приход сообщения "итог". Чтобы справиться с проверкой поскорее, не жертвуя при этом достоверностью результатов, маршрутизатор передает запрос LLQC раз (Last Listener Query Count, по умолчанию равен RV [§9.9 RFC 3810]), но делает между передачами лишь короткие паузы длиной LLQI (Last Listener Query Interval), по умолчанию 1 секунда [§9.8 RFC 3810]. При этом слушатели задерживают свои отчеты на короткое случайное время от 0 до LLQI. В такой схеме самое позднее, когда может прийти отчет, это спустя время LLQI\times LLQC от начала проверки, что по умолчанию составляет 3 секунды. Для этого интервала принято обозначение LLQT (Last Listener Query Time) [§9.10 RFC 3810]. И нет смысла устанавливать таймер источника во время проверки на больший интервал.

Нам трудно избавиться от навязчивой мысли, что аббревиатуру LLQT следует произносить так: "Lil’ cutie".

Интервал LLQI входит в LLQT ровно LLQC раз, а не LLQC + 1, потому что первый запрос в серии уходит немедленно. Затем следует LLQC - 1 интервалов повтора и, наконец, еще один интервал отведен на случайную задержку отчетов слушателями.

Выходит, что в зависимости от ситуации оптимальный интервал таймера может быть длинным (MALI) или коротким (LLQT). Выбрать подходящий интервал довольно просто, если действовать по вот какой процедуре:

  • По умолчанию маршрутизатор устанавливает таймер источника на длинный интервал (MALI).
  • Когда маршрутизатор передает первое сообщение в серии запросов Q(Г,S), ограниченных данной группой Г и списком источников S, он понижает значение таймера на каждом источнике группы Г из списка S до LLQT, если оно выше LLQT.

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

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

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

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

Пока конфигурация слушателей постоянна, это должен быть длинный интервал (MALI), так как подготовка к переходу EXCLUDE\toINCLUDE включает в себя накопление записей в списке требований, а для этого каждый слушатель во включающем режиме должен получить возможность высказаться отчетом IS_IN в ответ на последний из периодических запросов маршрутизатора.

Но возможна и ситуация, когда маршрутизатор получает повод немедленно усомниться в целесообразности исключающего режима. Таким поводом служит отчет TO_IN, косвенно говорящий об уменьшении числа слушателей группы в исключающем режиме. Получив его, маршрутизатор должен каким-то образом проверить, не упало ли оно до нуля. С этой целью маршрутизатор шлет серию из запросов Q(Г), ограниченных только группой, но не списком источников, пытаясь вызвать отклик слушателей группы в исключающем режиме за время LLQT. Наряду с ними ответят и все остальные слушатели группы, так что время подготовки к вероятному переходу EXCLUDE\toINCLUDE, если он произойдет ввиду отсутствия ожидаемого отклика, можно смело сократить до LLQT.

По итогам наших рассуждений составим процедуру управления интервалом таймера фильтра — она оказывается практически такой же, как у таймера источника:

  • По умолчанию маршрутизатор устанавливает таймер фильтра на длинный интервал (MALI).
  • Когда маршрутизатор передает первое сообщение в серии запросов Q(Г), ограниченных только данной группой Г, он понижает значение таймера фильтра группы Г до LLQT, если оно выше LLQT.

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

Любопытно отметить, что в приведенных нами процедурах можно даже не упоминать режим работы фильтра, потому как в исключающем режиме маршрутизатор не упоминает источники из списка исключений в запросах Q(Г,S), а во включающем режиме ему никогда не потребуется запрос Q(Г).

Тем не менее, на практике будут нелишними дополнительные проверки, что поведение разных компонентов одной реализации отвечает ожиданиям разработчиков.

Таким образом, у каждой разновидности запроса MLDv2 своя отдельная роль. Все они собраны в Табл. 8.4.

Таблица 8.4. Разновидности запросов MLDv2
Разновидность Обозначение Когда шлется Роль
Общий запрос Q(::) При старте маршрутизатора, затем периодически. Выяснить текущее состояние дел на канале.
Запрос, ограниченный группой Г Q(Г) Когда уменьшается число слушателей группы в исключающем режиме. Выяснить, остались ли у данной группы слушатели в исключающем режиме.
Запрос, ограниченный группой и списком источников Q(Г, S) Когда уменьшается число слушателей группы, заинтересованных в данных источниках S. Выяснить, востребованы ли все еще в данной группе данные источники.

И вот, наконец, мы готовы составить свод правил для маршрутизатора MLDv2 в Табл. 8.5.

Таблица 8.5. Правила обработки отчетов маршрутизатором MLDv2
Текущее состояние Отчет Новое состояние Запросы Удалить Таймеры
INCLUDE(A ) ALLOW( B) INCLUDE(A\cup B) - - (B )=MALI
INCLUDE(A ) IS_IN(B ) INCLUDE(A\cup B) - - ( B)=MALI
INCLUDE(A ) TO_IN( B) INCLUDE(A\cup B) Q(Г,A\backslash B) - ( )=MALI
Комментарий: Текущий фильтр пропускает только источники из множества . Поэтому все три отчета, по сути, требуют расширения этого множества до A\cup B. На записях, о которых получена свежая информация, перезапускается таймер. Отчет TO_IN(B) также вызывает запрос насчет прочих допущенных источников, Q(Г,A\backslash B), потому что это может быть сигнал о сокращении или изменении, а не расширении множества принимаемых источников. Отчет IS_IN(B) такого запроса не вызывает, потому что он сам пришел в ответ на какой-то запрос, во избежание зацикливания протокола.
INCLUDE(A) BLOCK(B) INCLUDE(A) Q(Г,A\cap B) - -
Комментарий: Поскольку текущий фильтр пропускает только источники из множества A , подмножество уже заблокировано, и остается рассмотреть только A\cap B. Маршрутизатор не может немедленно заблокировать его, так как его потенциально принимают другие слушатели, поэтому сейчас он ограничивается запросом Q(Г,A\cap B).
INCLUDE(A) IS_EX(B) EXCLUDE(A\cap B, B\backslash A) -  A\backslash B ( B\backslash A)=0, (фильтр)=MALI
INCLUDE(A) TO_EX(B) EXCLUDE(A\cap B, B\backslash A) Q(Г,A\cap B)  A\backslash B ( B\backslash A )=0 ,(фильтр)=MALI
Комментарий: Прежде всего, маршрутизатор должен перевести фильтр в исключающий режим, так как обнаружился слушатель в этом режиме. Все источники, кроме множества A , уже были заблокированы, поэтому сейчас можно смело блокировать такую часть B : B\cap (\backslash A)=B(\backslash A. Таймеры этих записей останавливаются, так как у списка исключений один таймер на весь фильтр; он как раз запускается. Остаток B , то есть A\cap B, немедленно блокировать нельзя, но его можно подвергнуть проверке, сохранив в списке требований. Тем не менее, запрос об источниках A\cap B можно послать, только если отчет — об изменении фильтра (TO_EX), а не о его текущем состоянии (IS_EX), потому что последний сам пришел в ответ на какой-то запрос. Источники A \backslash B в новом состоянии допущены по умолчанию, и записи о них можно вообще удалить.
EXCLUDE(X,Y ) ALLOW(A) EXCLUDE(X\cup A, Y\backslash A) - - (A)=MALI
EXCLUDE(X,Y) IS_IN(A) EXCLUDE(X\cup A, Y\backslash A) - - (A)=MALI
EXCLUDE(X,Y) TO_IN(A) EXCLUDE(X\cup A, Y\backslash A) Q(Г,X\backslash A ), Q(Г) - (A)=MALI

Комментарий: Здесь мы знакомимся со второй ролью списка требований X, когда он накапливает включающие записи на случай перехода фильтра во включающий режим. Поэтому недостающие записи добавляются в список требований путем объединения множеств X и A. На всех записях, о которых получена свежая информация, перезапускается таймер. В то же время элементы A удаляются из списка исключений, который сокращается до  Y\backslash A. Ведь отчет требует прекратить блокировку A, и это должно произойти немедленно, так как погрешность фильтра допустима только в сторону разрешения источников.

Отчет IS_IN запросов не вызывает, так как сам вызван запросом. Напротив, отчет TO_IN вызывает запрос насчет тех элементов X, о которых нет свежей информации: X за исключением A. По большому счету, он нужен, чтобы список X не рос за счет устаревших записей. Кроме того, отчет TO_IN потенциально означает, что число слушателей в исключающем режиме уменьшилось, потому что один из них перешел во включающий режим. Чтобы проверить, остались ли они вообще, маршрутизатор шлет еще один запрос без уточнения источников, то есть ограниченный только группой: Q(Г). Хотя в этом случае запрос Q(Г, X\backslash A) может показаться избыточным, он нужен для координации таймеров между маршрутизаторами канала — о ней мы скоро поговорим.

EXCLUDE(X,Y) IS_EX(A) EXCLUDE( A\backslash Y, Y\cap A) - ( X\backslash A, Y\backslash A ) ( A\backslash X\backslash Y )=MALI,(фильтр)=MALI
EXCLUDE(X,Y) TO_EX(A) EXCLUDE( A\backslash Y, Y\cap A) Q(Г, A\backslashY )  X\backslash A, Y\backslash A ) ( A\backslash X\backslash Y )=MALI, (фильтр)=MALI

Комментарий: Безопасно блокировать можно только пересечение  Y\cap A , так как только насчет этого подмножества есть консенсус слушателей. Остаток Y , то есть  Y\backslash A , нужно немедленно разблокировать, потому что он интересен данному слушателю. Остальную часть A , то есть  A\backslash Y , надо сначала проверить запросом, если мы имеем дело с отчетом об изменении состояния (TO_EX).

При этом роль списка требований меняется: он снова хранит записи о проверяемых источниках, кандидатах на блокировку, а все прочие записи из него удаляются. Подмножество  X\backslash A уходит из списка требований, потому что в новых условиях у него больше нет шансов на блокировку: слушатель хочет его принимать. В то же время, подмножество  X\cap A остается в списке требований, потому что это по-прежнему кандидат на блокировку.

На вновь добавленных записях, которых раньше не было в списке требований (это  A\backslash X\backslash Y ), запускаются таймеры. В случае TO_EX они устанавливаются на интервал, равный текущему значению таймера фильтра. Почему так? Пока фильтр работает в исключающем режиме, его таймер отсчитывает время до желанного момента, когда маршрутизатор сможет заблокировать почти все источники. Поэтому таймер фильтра неявно "тикает" на всех источниках, которые сейчас не занесены в или и потому разрешены по умолчанию. Ради сохранения информации об актуальности таких записей, мы должны скопировать значение таймера фильтра в таймер такого источника, когда мы создаем о нем явную запись в списке требований . Именно это здесь и происходит: сохранение накопленной информации.

Случай IS_EX особенный. Если маршрутизатор получил сообщение IS_EX, то есть заявление об уже существующем состоянии слушателя, и подмножество  A\backslash X\backslash Y не пусто, то это значит, что маршрутизатор потерял синхронизацию со слушателем. Хотя такое может произойти, например, когда маршрутизатор едва только включился в работу, или же после сбоя канала, наиболее вероятная причина — что маршрутизатор сам удалил эти записи из списка требований, чтобы проверить другие источники. Скажем, именно это произойдет, если на канале несколько слушателей в исключающем режиме, фильтры которых не совпадают: список требований станет "осциллировать". (Убедитесь в этом, изучив сценарий, когда один слушатель блокирует множество {1,2}, а другой — {2,3}.) Так или иначе, маршрутизатор не может доверять своим текущим сведениям и устанавливает таймеры новых записей на длинный интервал MALI. Кроме того, маршрутизатор не шлет запрос, ограниченный группой и списком источников, так как отчет IS_EX уже вызван каким-то запросом.

У нас есть гипотеза, что установка ( A\backslash X\backslash Y )=(фильтр) и в этом случае не вызвала бы никаких проблем. Исследуйте ее, если будет время и желание.

Наконец, оба отчета свидетельствуют, что у группы есть как минимум один слушатель в исключающем режиме, а значит, надо перезапустить таймер фильтра на длинный интервал MALI.

EXCLUDE(X,Y) BLOCK(A) EXCLUDE(X\cup ( A\backslash Y),Y) ( Q(Г, A\backslash Y ) - ( A\backslash X\backslash Y )=(фильтр)
Комментарий: Это правило похоже на предыдущее, TO_EX. Часть множества A, возможно, уже заблокирована фильтром Y, поэтому изменения касаются только подмножества  A\backslash Y . Как обычно, вместо его непосредственной блокировки следует запрос о нем. Тем не менее, отчет BLOCK может исходить от слушателя в любом режиме, и поэтому маршрутизатор только добавляет недостающие элементы в список требований X путем объединения множеств, а не сбрасывает его до  A\backslash Y . По той же самой причине таймер фильтра продолжает отсчет времени, а не перезапускается; ведь отчет BLOCK не доказывает, что есть слушатели в исключающем режиме. Если его интервал вскоре истечет, фильтр перейдет во включающий режим, а в список включений попадут все желательные источники, потому что список требований не сбрасывался до проверяемого подмножества, а объединялся с ним. Так маршрутизатор избежит нежелательной блокировки источников при переключении фильтра. Об установке таймеров на источниках см. предыдущее обсуждение TO_EX. В отличие от правила TO_EX, здесь список исключений Y не требует немедленных изменений. Дело в том, что объявление вида TO_EX(A) говорит, что данному слушателю интересны все источники кроме перечисленных во множестве A, а значит, их надо немедленно разблокировать. В то же время, объявление BLOCK(A) не несет в себе такого строгого требования.

В отличие от правила TO_EX, здесь список исключений не требует немедленных изменений. Дело в том, что объявление вида TO_EX(A) говорит, что данному слушателю интересны все источники кроме перечисленных во множестве A, а значит, их надо немедленно разблокировать. В то же время, объявление BLOCK(A) не несет в себе такого строгого требования.

Заданием для читателя будет изобразить и проанализировать диаграммы Эйлера, отвечающие этим правилам.

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

А обладают ли отчеты свойствами коммутативности и транзитивности? (Повод подумать.)

Все отчеты кроме IS_EX и TO_EX обладают свойством аддитивности: если данный список источников разбить, скажем, на два подсписка и послать их в разных отчетах, то окончательное состояние маршрутизатора окажется тем же самым. Зачем это может пригодиться, догадаться несложно: если отчет о данной группе содержит так много источников, что сообщение превышает MTU канала, его можно разбить на несколько сообщений поменьше. Однако для IS_EX и TO_EX этот трюк не работает. Как тогда быть? Приемлемым решением будет передать только часть списка одним сообщением [§5.2.15 RFC 3810]. Ведь маршрутизатор MLD вправе ошибаться в разрешительную сторону, если это необходимо, а опустить часть источников в отчете IS_EX или TO_EX, значит, допустить их к группе.

Подсчитайте, сколько источников может уместиться в одно сообщение MLDv2, когда MTU канала равно минимально возможному значению 1280 байт. (Подсказка: учесть опцию "сигнал маршрутизатору. Ответ: {1280[MTU]-40[IP]-8[HopByHop-RtrAlert]-28[MLDv2]} div 16 = 75.)

Оказывается, что сложность правил MLDv2 (а также IGMPv3) обусловлена, главным образом, поддержкой слушателей в режиме EXCLUDE(A), где множество A не пусто. Рассмотрите упрощенный протокол LW MLDv2 (облегченный MLDv2), где слушатель может принимать или избранные источники (INCLUDE(A)), или все источники подряд (EXCLUDE( \varnothing)), но не может блокировать избранные источники. В этом случае правила маршрутизатора становятся намного проще, потому что ему больше не нужно вести список исключений. Самое удивительное, что маршрутизатор LW MLDv2 может быть совместим со слушателями MLDv2, потому что в MLD допустима погрешность в сторону разрешения источников. Маршрутизатору LW MLDv2 достаточно рассматривать любые отчеты IS_EX(A) или TO_EX(A) как просьбу разрешить все источники, то есть IS_EX( \varnothing) или TO_EX( \varnothing), соответственно. Если вы не справитесь с этим заданием самостоятельно, обратитесь к [RFC 5790].

Сергей Субботин
Сергей Субботин

"Теоретически канал с адресацией EUI 64 может соединить порядка 2^63 "

запись вида 2^63  не понятна и отнимает время на попытку ее осмыслить.

ее можно заменить например на записи вида  264  или 1,8 * 1019

 

Павел Афиногенов
Павел Афиногенов

Курс IPv6, в тексте имеются ссылки на параграфы. Разбиения курса на параграфы нет.