Я написав це минулого року як внутрішній довідковий документ, коли деякі наші інженери заплуталися, коли його попросили ввести адреси IPv6 у DNS. Я спеціально не звертався до DNS, але, мабуть, стурбованість полягала у форматі адрес, а не в тому, щоб "зрозуміти", як вони працюють. Можливо, воно буде корисним і для інших:
Отже, перше, що слід визнати, це те, що IPv6-адресатори виглядають некрасиво. Вони роблять.
Але я думаю, що це лише тому, що ми не звикли мати справу з ними і не розуміємо, що вони означають на дуже низькому рівні, як це робимо з IPv4 адресами. Я думаю, що пройде деякий час, щоб з ними заспокоїтись, але нам треба десь почати.
Ще одна важлива річ, яку потрібно пам’ятати, це те, що адреси IPv4 - це 32-бітні числа, а адреси IPv6 - 128-бітні номери. Коли маршрутизатор маршрутизує або брандмауер фільтрує, вони роблять це, виходячи з цього числа. Те, як людина обирає відображати це число, є абсолютно довільним і здебільшого є лише традицією. Отже, весь цей електронний лист пояснює, як люди вирішують представляти ці цифри - машини не байдужі, це все біти для них.
Адреса IPv4 - 32 біти або чотири байти. Ми вважаємо «справжніми» IP-адресами лише метод, який став стандартним для представлення цього бітового рядка, розділення бітів на 4 8-бітні групи, що представляють кожні 8 біт у вигляді десяткового числа, та відокремлення цих десяткових чисел у цьому період. Отже, візьміть випадкову IP-адресу 172.30.154.249. Коли маршрутизатор "думає" про цю IP-адресу, він дійсно думає про це так:
10101100000111101001101011111001
Що ми можемо перекласти вниз у власну форму:
10101100 = 172
00011110 = 30
10011010 = 154
11111001 = 249
Іноді ви також можете бачити це як чисте десяткове число:
10101100000111101001101011111001 = 2,887,686,905
Навряд чи хтось використовує цю форму за призначенням (*), але це історично допустимий спосіб написання адреси IPv4. Насправді ця форма використовується в RFC821, який визначав SMTP в 1982 році. Якщо ви хочете вручну направляти пошту на певну машину замість DNS, ви можете використовувати два різних типи літералів. Першою була знайома форма "пунктирного квадратика" в дужках ("user @ [172.30.154.249]"). Другий - це використання десяткової форми IP-префікса зі знаком фунта ("user @ # 2887686905").
Все вищесказане було лише для того, щоб забезпечити основу для перекладу ваших знань про те, як працюють адреси IPv4 на адреси IPv6. Так само, як IPv4 - це 32-бітове число, адреси IPv6 - це 128-бітні числа. АРІН призначив МОЮ ПРАВИЛЬНУ КОМПАНІЮ (**) діапазон IP 2311: FD67 / 32. Для того, щоб мати приклад для роботи, я буду використовувати IP 2311: FD67 :: AC1E: 9AF9.
Отже, ось рядок, що представляє цей ip6:
00100011000100011111110101100111000000000000000000000000000000000000000000000000000000000000000010101100000111101001101011111001
Якби ми представляли ці бітові рядки так, як ми робимо бітові рядки IPv4 (перетворюємо кожен 1-байтний фрагмент у десятковий, окремо кожен із періодом), ми отримаємо наступне:
35.17.253.103.0.0.0.0.0.0.0.0.172.30.154.249
У цьому є кілька проблем. Перший полягає в тому, що він схожий на прикольний номер IPv4, що не дуже добре, ви хочете отримати надійний спосіб розмежувати їх. Інша полягає в тому, що це багато інформації, багато кількості та багато порожнього місця. Отже, обидві проблеми вирішуються за допомогою іншого сепаратора (двокрапка (:) замість періоду (.)) Та повторення байтів у шістнадцятковій, а не у десятковій. Там, де IPv4 відокремлює 8-бітові фрагменти, представлені у десятковій частині, з періодами, IPv6 відокремлює 16-бітні шматки, відокремлені двокрапками. Отже ось розбивка нашого IPv6 прикладу IP:
0010001100010001 = 2311
1111110101100111 = FD67
0000000000000000 = 0
0000000000000000 = 0
0000000000000000 = 0
0000000000000000 = 0
1010110000011110 = AC1E
1001101011111001 = 9AF9
2311:FD67:0:0:0:0:AC1E:9AF9
У ньому все ще багато білого простору, тому існує припущення, що найбільший рядок нулів можна опустити і зобразити подвійною двокрапкою. Отже, вищезазначений IP може бути записаний:
2311:FD67::AC1E:9AF9
Я цього не бачив багато, але, як я розумію, існує також акуратна умова, яка дозволяє останньому 32-бітовому записуватися як префіксований пунктир, що дозволяє легко розпізнавати застарілі адреси під час міграції з IPv4 на IPv6 . Отже, як ви, мабуть, помітили, моя адреса прикладу IPv6 закінчується тими ж 32 бітами, що повністю містить мій приклад IPv4. Це особливо корисно, коли ви пишете в цьому стилі. У такому випадку мій додаток IPv6 виглядатиме так:
2311:FD67::172.30.145.249
Щоб повернутись туди, де я почав з IPv6, я згадав, що нам призначено 2311: FD67 / 32. / 32 - це трохи маска, як і в IPv4 адресах. Це по суті означає, що нам було статично призначено перші 32 із 128 біт в IPv4-адресі, яку ми могли створити. Оскільки 2311: FD67 - 32 біти, це означає, що кожна IP-адреса, яку ми створюємо з цього діапазону, почне саме з цього.
Інакше кажучи, так само, як 172.17 / 16 можна вважати "кожен IP між 172.17.0.0 і 172.17.255.255", 2311: FD67 / 32 можна вважати як "кожен IP між 2311: FD67: 0: 0: 0: 0: 0: 0 і 2311: FD67: FFFF: FFFF: FFFF: FFFF: FFFF: FFFF ".
Я думаю, що ми пройдемо багато часу, перш ніж ми почнемо переходити до IPv6, але сподіваюся, що це пояснення допоможе вам почуватись комфортніше користуватися ними та посилатися на них.
Знову ж таки, дуже важливо зрозуміти єдине, про що я тут говорю, - це буквально, як записати IPv6-адресу. Здається, що в схемі нумерації маршрутизації тощо вбудовано багато інтелекту, що я ще не розумію поки що, тому все, на що я можу звернутись, це те, як це виглядає =).
(*) Я бачив десяткове представлення IPv4 в деяких програмних налагодженнях, але я майже впевнений, що це помилка чи лінь, я думаю, що в коді С було набагато зручніше швидко друкувати 32-бітове ціле число, ніж це було відформатуйте крапковий пунктир для друку.
(**) Я проігнорував назву своєї компанії та префікс