Розбір заголовків розширень IPv6, що містять невідомі розширення

113

Я пишу дуже простий чистий фільтр, і потрапляю туди, де хочу проаналізувати заголовки IPv6, щоб відповідати таким речам, як типи ICMPv6, номери портів TCP / UDP тощо.

Тож я читаю про формат пакету IPv6 поглиблено, і мені начебто ... ну ... мені начебто довелося читати його знову і знову, щоб переконатися, що я насправді читав його правильно. Мені здається, що ви повинні почати з 40-байтового фіксованого заголовка і подивитися на його наступне поле заголовка. Тоді вам слід подивитися на наступне поле заголовка наступного заголовка тощо, як пов’язаний список, поки не досягнете кінця. Якщо є корисна навантаження, вона буде наступною.

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

Це вражає мене як дивний, можливо, навіть заєць, придуманий дизайном. Що робити, якщо я зіткнувся з нерозпізнаним типом заголовка розширення? Що мені робити? Я не знаю його довжини. Я думаю, що мені доведеться викинути пакет і заблокувати його, оскільки в мережевому фільтрі, що дозволяє пакету наскрізь, було б зловмиснику можливість ухилитися від чистого фільтра, включаючи фіктивний тип заголовка. Але це означає, що якщо протокол буде коли-небудь розширений, кожен окремий фрагмент програмного забезпечення для розбору заголовка IPv6, коли-небудь написаний, повинен бути одночасно оновлений, якщо потрібно використовувати нове розширення.

Тож як я можу проаналізувати заголовки IPv6, якщо я не знаю розширень, які вони використовують? Як я можу пропустити заголовок невідомого розширення, оскільки не знаю його довжини?

networking ip ipv6

— АдамІєріменко
джерело

10

Виходячи з цього питання, схоже, я не дурний, і так, я читаю це право: додати новий заголовок розширення до IPv6 неможливо (в реальному світі). stackoverflow.com/questions/9847923 / ...

— AdamIerymenko

10

І так, також здається, що для обчислення довжини заголовка потрібен перехід пов'язаного списку: stackoverflow.com/questions/14762193/… Не зрозумійте мене неправильно. IPv6 є приголомшливим і дуже потрібним. Але це все ще здається кістковим.

— АдамІєріменко

3

Специфікація (зв'язана у головному коментарі) говорить, що маршрутизатори не повинні дивитись на заголовки, тому не має значення, які заголовки ви додаєте. Лише вузол призначення повинен дивитись на заголовки.

— Андерс Е. Андерсен

2

Лише зауваження: "зачіска з волоссям" - це доволі заплутане написання, і слід віддавати перевагу "заєць-мізки" (джерело: tfd )

— pzkpfw

2

Наскільки існує лише одне правильне написання, яке є "зайцеподібним".

— Алан Б

33

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

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

Маршрутизатори можуть маршрутизувати такі пакети, адже все, що їм потрібно, - це заголовок маршрутизації. Гаджети з глибоким оглядом пакетів і подібні подібні потрібно знати багато, але тоді все одно їх доля.

Відредаговано, щоб додати: Цей дизайн означає, що середні скриньки можуть змінювати лише те, що вони знають. Якщо середня скринька бачить заголовок, якого він не знає, у нього є лише два варіанти: відхилити або передати далі. У IPv4 він також може видалити невідоме розширення та передати решту. IMO ця властивість робить дизайн швидше, ніж менш розширюваним.

— арнт
джерело

97

Що робити, якщо я зіткнувся з нерозпізнаним типом заголовка розширення?

Від RFC 2460 :

Якщо в результаті обробки заголовка потрібен вузол для переходу до наступного заголовка, але значення Наступного заголовка в поточному заголовку не розпізнається вузлом, він повинен відкинути пакет і надіслати повідомлення проблеми проблеми параметри ICMP до джерела пакету зі значенням коду ICMP 1 ("зустрічається нерозпізнаний тип наступного заголовка") та поле вказівника ICMP, що містить зміщення нерозпізнаного значення у вихідному пакеті. Аналогічну дію слід здійснити, якщо у будь-якого заголовка, крім заголовка IPv6, вузол зустрічає значення нуля Наступний заголовок.

— Олівер Чарльворт
джерело

15

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

— АдамІєріменко

8

Наявність можливості ігнорувати невідомі заголовки призведе до набагато складніших питань. (Що робити, якщо проміжні проксі-модифіковані заголовки TCP без знання інкапсулюючого заголовка ESP?) У цьому випадку простота перемагає "розширюваність"!

— jman

4

@Max IPv6 має достатньо буквально адрес, щоб призначити їх кожному атомові на Землі. Немає кількості підключених до Інтернету тостерів, які б виснажили цей простір.

— Тайлер Макенрі

8

@Max Я не скажу, що нам ніколи не потрібен IPv7, але з IPv6 у нас є достатньо адресного простору, щоб надати кожному кубічному міліметру в атмосфері Землі (130 000 км вгору) унікальну адресу ... 100 000 разів. Отже, я маю на увазі, як тільки ми почнемо колонізувати інші галактики, нам може бути про що турбуватися, але до цього ми повинні бути досить хорошими.

— cincodenada

4

Відсутній контекст:

With one exception, extension headers are not examined or processed by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header.

— Tobu

28

Додавати новий заголовок розширення до IPv6 неможливо (в реальному світі).

Неправильно, оскільки:

Відхиляти може лише хост призначення на основі нерозпізнаних заголовків розширень (за винятком одного виключення, згаданого у питанні, яке ви пов’язали )
Якщо ваш новий заголовок розширення якимось чином необов’язковий (краще було б), ви отримаєте помилку ICMP щодо цього і зможете спробувати ще раз без нього.

— Андреас Кльокнер
джерело

1

І ви впевнені, що цей пакет ICMP перейде через NAT до фактичного відправника?

— Декстер

5

@Dexter ipv6 вб'є NAT ... сподіваємось

— Янус Троельсен

2

@Dexter: Ці пакети ICMP повинні надходити з кількох причин. Наприклад, якщо MTU труби зменшився (можливо, інкапсуляція пакету трапилася через PPPoE або VPN), а пакет, що надсилається, занадто великий, пакет ICMP повернеться, кажучи, що пакет занадто великий.

— Білл Лінч

4

@JanusTroelsen не всі діляться вашими сподіваннями.

— Декстер

4

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

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

— Майкл Хемптон
джерело