Топалов

рема, кожна опція конфігурації має значення за замовчуванням. Це гарантує постійну розпізнаваність пакетів LCP.

У інформаційному полі PPP інкапсулюється тільки один пакет LCP, де

поле протоколу PPP показує тип c021			(протокол контролю ланки LCP).
Табл. 5 Загальний формат пакетів протоколу LCP
0 1 2 3 4 5 6 7	8 9 10 11 12 13	16 17 18 19 20 21 22 23 24
	14 15	25 26 27 28 29 30 31
Код	Ідентифікатор	Довжина		Дані ...

Поля передаються зліва направо. Поле "Код" - один октет, задає вид пакету LCP. Коли пакет отриманий з невизначеним полем "Код", передається пакет "Скидання коду".

Значення поля "Код" протоколу LCP визначаються в найбільш пізньому виданні "Assigned Numbers" RFC [3]. Нині цей документ визначає наступні величини:

1– Запит конфігурації.

2– Підтвердження конфігурації.

3– Непідтвердження конфігурації.

4– Скидання конфігурації.

5– Запит роз'єднання.

6– Підтвердження роз'єднання.

7– Скидання коду.

8– Скидання протоколу.

9– Запит ехо-сигналу.

10– Відповідь ехо-сигналу.

11– Запит скидання.

Поле "Ідентифікатор" містить один октет і забезпечує відповідність запитів відповідям. Коли пакет отриманий з недійсним полем "Ідентифікатор", він скидається без дії на автомат.

Поле "Довжина" (два октети) вказує довжину пакетів LCP, включаючи поля "Код", "Ідентифікатор", "Довжина" і "Дані". Довжина не повинна перевищувати величину MRU для ланки передачі даних.

Октети поза діапазоном поля "Довжина" розглядаються як доповнення і ігноруються при прийомі. Коли пакет отриманий з недійсним значенням поля "Довжина", пакет скидається без дії на автомат.

Поле "Дані" містить нуль або більше за октети, як показано в полі "Довжина". Формат поля "Дані" визначається полем "Код".

3.6. Опції конфігурації протоколу LCP

Опції конфігурації протоколу LCP дозволяють модифікувати величини, встановлені за замовчуванням, для зв'язку "точка-точка". Якщо опції конфігу-

131

рації не включені в пакет "Запит конфігурації", то для цієї опції конфігурації використовується значення, прийняте за замовчуванням.

Деякі опції конфігурації можуть бути внесені в список більше, ніж один раз. В результаті цього вони визначаються у відповідності c кожним таким описом конфігурації (жодна з опцій конфігурації в цій специфікації не може бути внесена в список більше, ніж один раз).

Кінець списку опцій конфігурації визначається полем "Довжина" пакетів

LCP.

Якщо не визначено інакше, то усі опції конфігурації застосовуються в напівдуплексному режимі, в приймальному напрямі зв'язку з точки зору відправника запиту конфігурації.

Опції вказують додаткові можливості або вимоги додатка, який вимагає опції. Додатку, який не сприймає яку-небудь опцію, слід взаємодіяти з тим, яке підтримує усі опції.

Для кожної опції визначено значення за замовчуванням, яке дозволяє каналу правильно функціонувати без узгодження опцій, хоча, можливо, з менш оптимальним виконанням. Для опцій в запиті конфігурації посилати значення за замовчуванням не вимагається. Узагальнений формат опцій конфігурації показаний нижче.

Табл. 6 Узагальнений формат опцій конфігурації протоколу LCP

0 1 2 3 4 5 6 7	8 9 10 11 12 13 14 15	16 17 18 19
Тип	Довжина	Дані...

Поля передаються зліва направо. Поле "Тип" містить один октет і вказує тип опцій конфігурації. Нині значення поля "Тип" протоколу LCP визначені в останньому виданні "Assigned Numbers" RFC [3].

Табл. 7 Значення поля "Тип" протоколу LCP

0 Резерв

1 Максимальний розмір блока (MRU - Maximum - Receive - Unit) на прийомі

3 Протокол автентифікації (Authentication - Protocol)

4 Протокол якості (Quality - Protocol)

5 Magic-номер

7 Стискування полів протоколу (Protocol - Field - Compression)

8 Стискування адресних і контрольних полів (Address and Control Field Compression)

Поле "Довжина" містить один октет і вказує довжину опції конфігурації, включаючи поля "Тип", "Довжина" і "Дані". Якщо опція конфігурації, що погоджується, отримана при запиті конфігурації, але з недійсною або нерозпізнаною довжиною, то слід передати непідтвердження конфігурації, яке включає бажані опції конфігурації з відповідною довжиною і даними.

132

Поле "Дані" містить нуль або більше за октети і включає інформацію, що відноситься до опції конфігурації. Формат і довжина поля "Дані" визначаються полями "Довжина" і "Тип". Коли поле "Дані" визначено завдовжки так, що воно тягнеться до кінця інформаційного поля і далі, увесь пакет скидається без дії на автомат.

Максимальний розмір блока, що приймається Цю опцію конфігурації можна посилати, щоб повідомити одноранговий

об'єкт, що додаток може отримати пакети великих розмірів, або просити, щоб одноранговий об'єкт посилав менші пакети. Максимальний розмір блоку (MRU - Maximum Receive Unit), що приймається, за замовчуванням складає 1500 октетів. Якщо потрібно пакети менших розмірів, на прийомі має бути здатність отримувати повне 1500-октетне інформаційне поле.

Ця опція використовується для вказівки можливості додатка. Одноранговому об'єкту максимізувати свої можливості не вимагається. Наприклад, коли вказано, що MRU складає 2048 октетів, одноранговому об'єкту не вимагається посилати пакет з 2048 октетуми. Одноранговий об'єкт не вимагає непідтвердження конфігурації, щоб вказати, що він посилатиме тільки пакети з меншими розмірами, оскільки додаток завжди вимагатиме забезпечення принаймні 1500октетних розмірів.

Табл. 8 Формат опції конфігурації MRU

0	1	2 3
0 1 2 3 4 5 6 7	8 9 10 11 12 13 14 15	16 17 18 19 20 21 22 23 24 25
		26 27 28 29 30 31
Тип	Довжина	MRU

Поля передаються зліва направо. Поле "Тип" має значення, рівне 1. Поле "Довжина" набуває значення, рівного 4. Поле "MRU" містить два октети і визначає максимальне число октетів в інформаційному полі і полі заповнення. Сюди не включаються заголовок кадру, поле протоколу, контрольна сума (FCS), біти або байти прозорості.

3.7. Протокол автентифікації

Для деяких каналів може знадобитися, щоб одноранговий об'єкт підтвердив свою достовірність перед дозволом обмінюватися пакетами протоколу мережного рівня. Ця опція конфігурації забезпечує спосіб узгодження типу протоколу встановлення достовірності. За замовчуванням, встановлення достовірності не потрібно.

Додаток не повинен включати декілька опцій конфігурації протоколу автентифікації (AP - Authentication Protocol) в пакетах "Запит конфігурації". Замість цього, йому слід спробувати спочатку задати найбільш бажаний протокол. Якщо опції цього протоколу не підтверджуються, тоді додатку слід спробувати погоджувати наступний найбільш бажаний протокол в наступному запиті конфігурації.

Додаток, посилаючи запит конфігурації, може вказувати, що йому потрібно автентифікацію однорангового об'єкту. Якщо додаток посилає підтвер-

133

дження конфігурації, то воно погоджується підтвердити достовірність із вказаним протоколом. Додатку, одержуючому підтвердження конфігурації, слід чекати підтвердження одноранговим об'єктом своєї достовірності за погодженим протоколом.

Немає ніяких вимог того, щоб автентифікація була повнодуплексною або щоб один і той же протокол використовувався в обох напрямах. Допускається використання різних протоколів у різних напрямах.

Табл. 9 Формат опції конфігурації протоколу автентифікації

0	1	2 3
0 1 2 3 4 5 6 7	8 9 10 11 12	16 17 18 19 20 21 22 23 24 25
	13 14 15	26 27 28 29 30 31
Тип	Довжина	Протокол автентифікації	Дані...

Поля передаються зліва направо. Поле "Тип" набуває значення, рівного 3. Поле "Довжина" не менше 4 октетів. Поле "Протокол автентифікації" включає два октети і вказує бажаний протокол автентифікації. Величини цього поля - завжди ті ж самі, що і в Поле протоколу PPP для того ж самого протоколу автентифікації.

Нині значення поля "Протокол автентифікації" визначено в останньому виданні "Assigned Numbers" RFC [3].

Табл. 10 значення поля "Протокол автентифікації"

Величина в 16ковому вигляді

C023 -

C223 -

Протокол

Протокол встановлення достовірності пароля PAP (Password

Authentication Protocol);

Протокол автентифікації запиту діалогу CHAP (Challenge Handshake

Authentication Protocol).

Поле "Дані" містить нуль або більше за октети і включає додаткові дані, як визначено відповідним протоколом.

3.8. Протокол якості

На деяких лініях зв'язку вимагається визначати, коли і як часто канал втрачає дані. Цей процес називається контролем якості каналу зв'язку. Існує опція конфігурації, яка забезпечує узгодження типу «Протоколу якості» (QP – Quality – Protocol) каналу зв'язку. За замовчуванням контроль якості зв'язку не здійснюється.

Додаток, посилаючи запит конфігурації, вказує, що воно чекає отримати від однорангового об'єкта інформацію відповідно до протоколу контролю якості вказаного типу. Якщо додаток посилає підтвердження конфігурації, тоді воно

134

погоджується послати інформацію відповідно до вказаного протоколу. Додатку, одержуючому підтвердження конфігурації, слід чекати від однорангового об'є- кта підтвердження вибору протоколу.

Немає ніяких вимог того, щоб контроль якості бути в повнодуплексним або щоб один і той же протокол використовувався в обох напрямах. Допускається використання різних протоколів у різних напрямах.

Табл. 11 Формат опції конфігурації ―Протоколу якості‖

0	1	2 3
0 1 2 3 4 5 6 7	8 9 0 1 2 3 4 5	6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Тип	Довжина	Протокол якості	Дані...

Поля передаються зліва направо. Поле "Тип" має значення, рівне 4. Поле "Довжина" не менше 4 октетів.

Поле "Протокол якості" містить два октети і вказує бажаний протокол, контролюючий якість зв'язку. Значення цього поля - завжди ті ж, що і в Поле протоколу PPP для того ж самого протоколу контролю.

Нині значення поля "Протокол якості" визначені в останньому виданні

"Assigned Numbers" RFC [3].

Табл. 12 Значення поля "Протокол якості"

Величина в 16-надцятковому вигляді	Протокол
C025	Повідомлення якості каналу зв'язку LQR
	(Link Quality Report)

Поле "Дані" включає нуль або більше за октети і містить додаткові дані, як визначено відповідним спеціальним протоколом.

3.9. Magic-номер

Ця опція конфігурації забезпечує метод виявлення зациклених ланок і інших аномалій рівня ЛПД. Вона може вимагатися деяким іншим опціям конфігурації, таким як опції конфігурації «Протоколу якості». За замовчуванням magic-номер не узгоджується, і там, де він міг би використовуватися, вставляється нуль.

Перш, ніж ця опція конфігурації знадобиться, додаток повинен вибрати свій magic-номер. Рекомендується, щоб magic-номер був вибраний випадковим чином, щоб забезпечити з дуже високою вірогідністю його унікальність.

Унікальні випадкові числа можуть виходити з серійних номерів машин, інших адрес апаратних засобів мережі, часу дня і так далі. Особливо хороші такі випадкові значення, як точні виміри часу між фізичними подіями типу прийому пакетів на інших пов'язаних мережах, часу відповіді сервера або швидкос-

135

ті введення символів користувача-людини. Бажано, щоб одночасно використовувалося стільки джерел, скільки можливо.

Коли запит конфігурації з опцією конфігурації magic-номери отриманий, даний magic-номер порівнюється з magic-номером останнього запиту конфігурації, посланого одноранговому об'єкту.

Якщо два magic-номери різні, то зв'язок не є зацикленим, і magic-номер слід підтвердити. Якщо два magic-номери рівні, тоді можливо, але не обов'язково достовірно, що зв'язок зациклився і що цей запит конфігурації фактично той, що був посланий востаннє. Щоб в цьому переконатися, треба послати непідтвердження конфігурації, визначаючи інше значення magic-номери. Не слід посилати одноранговому об'єкту новий запит конфігурації, поки ситуація не нормалізується (до тих пір, поки не буде отримано непідтвердження конфігурації або таймер рестарту не обнулиться).

Прийом непідтвердження конфігурації з magic-номером, відмінним від того, що був в останньому непідтвердженні конфігурації, посланому одноранговому об'єкту, доводить, що зв'язок не є зацикленим, і вказує унікальний magic-номер. Якщо magic-номер дорівнює присланому в останньому непідтвердженні конфігурації, вірогідність зациклення зв'язку збільшена, і має бути вибраний новий magic-номер. У будь-якому випадку, новий запит конфігурації не можна посилати з новим magic-номером.

Якщо ланка дійсно зациклена, ця послідовність (передача запиту конфігурації, отримання запиту конфігурації, передача непідтвердження конфігурації, отримання непідтвердження конфігурації) повторюватиметься багато разів. Якщо зв'язок не зациклений, ця послідовність може відбуватися кілька разів, але вірогідність цього надзвичайно мала. Ймовірніше, що magic-номери, вибрані у будь-якому одноранговому об'єкті, швидко розрізнятимуться, завершуючи цей ланцюжок. Наступна таблиця показує вірогідність повторень при припущенні, що обидва закінчення каналу зв'язку вибирають magic-номери з абсолютно однаковим розподілом:

Табл. 13 Вірогідність повторень пакетів

Число повторень	Вірогідність
1	1/2**32= 2.3 E – 10
2	1/2**32**2 = 5.4 E – 20
3	1/2**32**3 = 1.3 E – 29

Для забезпечення цієї розбіжності потрібно хороші джерела унікальних і випадкових чисел. Якщо таке джерело унікальності не може бути знайдене, рекомендується, щоб ця опція конфігурації не допускалася; запити конфігурації з опціями не слід передавати, а будь-які опції конфігурації magic-номерів, які посилає одноранговий об'єкт, мають бути або підтверджені, або скинуті. В цьому випадку зациклені ланки не можуть надійно виявлятися додатком, хоча вони можуть все ще бути виявлені одноранговим об'єктом.

136

Якщо додаток передає запит конфігурації з опцією конфігурації magicномери, то воно не повинне відповідати скиданням конфігурації при отриманні запиту конфігурації з опцією конфігурації magic-номери. Тобто, якщо додаток бажає використовувати magic-номери, тоді воно повинне дозволяти те ж одноранговому об'єкту. Якщо додаток отримує скидання конфігурації у відповідь на запит конфігурації, то це може означати, що зв'язок не зациклений і що одноранговий об'єкт не використовуватиме magic-номери. В цьому випадку, додатку слід діяти, неначе узгодження було успішним (неначе воно отримало підтвердження конфігурації).

Magic-номер може використовуватися, щоб виявити зациклені ланки під час нормальної роботи, а також впродовж узгодження опцій конфігурації. Пакети протоколу LCP "Запит ехо-сигналу", "Відповідь ехо-сигналу" і "Запит скидання" мають поле "Мagic-номер". Якщо magic-номер був успішно погоджений, то додаток повинен передати ці пакети з полем magic-номери, що має значення погодженого magic-номери.

Поле magic-номера цих пакетів слід розглядати при прийомі. Усі отримані поля magic-номери мають дорівнювати нулю або унікальному magic-номеру однорангового об'єкту залежно від того, погоджував або ні одноранговий об'єкт magic-номер.

Прийом поля magic-номера, рівного погодженому місцевому magicномеру, вказує на зациклення ланки. Прийом magic-номера, відмінного від погодженого місцевого magic-номера, погодженого magic-номера однорангового об'єкту або нуля, якщо одноранговий об'єкт не погодив його, вказує на те, що зв'язок був конфігурований для комунікацій з іншим одноранговим об'єктом.

Процедури для відновлення від будь-якої події - не визначені і можуть змінюватися від додатка до додатка. Має бути прийнята подія LCP "Виключення", наступна подія – "Відкриття" - почне процес повторного встановлення зв'я- зку, який не може завершитися, доки не буде усунено зациклення і погоджений magic-номер. Інший шлях у разі зациклення ланки – повинні почати передаватися пакети LCP "Запит ехо-сигналу", доки відповідна відповідь ехо-сигналу не буде отримана, вказуючи на припинення зациклення.

3.10. Стискування поля протоколу

Ця опція конфігурації забезпечує метод узгодження стискування полів протоколу PPP (PFC – Protocol – Field – Compression). За замовчуванням усі застосування повинні передати пакети з двохоктетними полями протоколу PPP.

Номери полів протоколу PPP вибрані, так що деякі їх значення можуть бути стиснуті в один октет. Щоб повідомити одноранговий об'єкт, що додаток може отримати такі одиноктетні поля протоколу PPP, посилається спеціальна опція конфігурації.

Поле протоколу використовує механізм розширення, що відповідає механізму розширення ISO 3309 для полів адреси; найменш значущий біт (LSB – Least Significant Bit) кожного октету використовується для вказівки на розши-

137

рення поля протоколу. Двійковий "0" в якості LSB вказує, що поле протоколу триватиме в наступному октеті. Присутність двійкової одиниці в якості LSB свідчить про те, що цей октет поля протоколу – останній.

Помітимо, що до поля може бути приєднане будь-яке число нульових октетів, і двійкове значення буде тим же самим (наприклад, ось два двійкові пред-

ставлення числа 3: 00000011 і 00000000 00000011).

При використанні вузькосмугових каналів бажано економити пропускну спроможність, посилаючи якомога менше надмірних даних. Опції конфігурації стискування поля протоколу є компромісом між вимогами простоти додатка і ефективністю використання пропускної спроможності. При успішному узгодженні для стискування поля протоколу до одного октету може використовуватися механізм розширення ISO 3309. Велику частину пакетів можна стискувати, оскільки протоколи даних призначаються зі значенням поля протоколу, меншим, ніж 256.

Стискуті поля протоколу не повинні передаватися, якщо ця опція конфігурації не була погоджена. Після узгодження, додаток повинен приймати пакети PPP з одиноктетними або двохоктетними полями протоколу, і не повинно робити відмінності між ними.

Поле протоколу ніколи не стискується при посилці будь-якого пакета LCP. Це правило гарантує однозначне розпізнавання пакетів LCP. Коли поле протоколу стиснуте, поле FCS рівня ЛПД розраховується не за початковим, а за стиснутим кадром.

Табл. 14 Формат опції конфігурації стискування полів протоколу PPP

0	1
0 1 2 3 4 5 6 7	8 9 0 1 2 3 4 5
Тип	Довжина

Поля передаються зліва направо. Поле "Тип" - 7 октет. Поле "Довжина" -

2октету.

3.11Стискування полів адреси і контролю

Ця опція конфігурації забезпечує метод узгодження стискування полів адреси і контролю (ACFC - Address and Control Field Compression) ЛПД. За замовчуванням усі застосування повинні передавати кадри з полями адреси і контролю відповідно до правил створенням кадрів ЛПД.

Оскільки ці поля мають постійні значення для каналів точка-точка (point - to - point), їх легко стискувати. Ця опція конфігурації посилається для інформування однорангового об'єкту про те, що додаток може отримати стиснуті поля адреси і контролю. Якщо отриманий стислий кадр, а стискування полів адреси і контролю не було погоджене, то додаток може скинути кадр без повідомлення.

Поля адреси і контролю не мають бути стиснуті при посилці будь-якого пакета LCP. Це правило гарантує однозначне розпізнавання пакетів LCP. Коли

138

поля адреси і контролю стислі, поле FCS рівня ЛПД розраховується не по початковому, а по стислому кадру.

Табл. 15 Формат опції конфігурації стискування полів адреси і контролю

0	1
0 1 2 3 4 5 6 7	8 9 0 1 2 3 4 5
Тип	Довжина

Поля передаються зліва направо. Поле "Тип" - 8 октет. Полі "Довжина" - 2 октета.

4. Налаштування PPPoE клієнт в ОС Windows XP/2003 (вбудований в ОС)

Основні етапи створення РРРоЕ з'єднання:

1.Пуск -> Панель управління -> Мережні підключення -> Створення нового підключення.

2.Вибираємо підключення через високошвидкісне підключення.

3.Далі вказати назву підключення «pppое».

4.Далі «Не набирати номер для попереднього підключення».

5.Далі вказати IP адресу запущеного PPPОЕ сервера.

6.Ввести логін, пароль вказаний у файлах авторизації сервера (pap-secrets або chap-secrets).

7.З'єднання готове.

5. Домашнє завдання

Вивчити ключові питання.

Підготувати протокол виконання лабораторної роботи. Навести приклад заголовка РРР фрейма.

Дати короткі письмові відповіді на контрольні питання.

6.Контрольні питання

1.Основні завдання, вирішувані протоколом РРР ?

2.Які функції рівня LCP ?

3.Які функції рівня NCP ?

4.Дайте коротку характеристику методу автентифікації протоколу РРР ?

7.Лабораторне завдання

1.Запустити програмний аналізатор протоколів Wireshark.

2.Включити режим захоплення пакетів.

139

3.Встановити РРРоЕ з'єднання з сервером, логін і пароль запитаєте у ви-

кладача.

4.Зупинити режим захоплення пакетів в Wireshark.

5.Проаналізуйте процес встановлення РРР, занесіть в протокол усі пакети які брали участь в цьому процесі в розширеному виді.

6.Зробіть висновки.

8. Список посилань

1.Perkins D. Requirements for an Internet Standard Point-to-Point Protocol. RFC 1547 // IETF. – 1993. – 21 p.

2.Mamakos L. A Method for Transmitting PPP Over Ethernet (PPPoE). RFC 2516 / L. Mamakos, K. Lidl, J. Evarts, D. Carrel , D.Simone and R. Wheeler // IETF. – 1999. – 17 p.

3.Arberg P., IANA Considerations for PPP over Ethernet (PPPoE). RFC 4937 / Arberg P., Mammoliti V. // IETF. – 2006. – 6 p.

140